prd

PRD Writing

写 / 改 / 重构 / 统一口径 需求文档时遵循本 skill。

1.1. 需要查产品体系 / 模块定位 / 业务领域知识 → 读 references/example-domain.md（示例文件，用户应替换为自己产品的领域知识）。 1.2. 需要完整反例 / 正例对照 → 读 references/examples.md（正文只留极简示例，多场景对照在那里）。 1.3. 动笔前 / 交付前检查清单 → references/checklist.md。 1.4. HTML 原型生成 → 用 html-prototype skill（视觉规范在那里，本 skill 只管文档）。

一、写作流程

2.1. 先确认上下文

动笔前只拉与当前任务直接相关的最小上下文：

1. MEMORY.md。
2. 当前系统 / 相关 PRD / 现有需求文档。
3. 涉及的同类模块（对齐口径用）。

不展开冗长背景考古。

2.2. 锁定对象粒度

写细节前先回答清楚：

1. 这是新对象，还是现有对象下的新类型 / 新能力？
2. 入口在哪一层？一级菜单、二级页、详情页、弹窗，还是已有流程中的一步？
3. 用户操作链路是什么？
4. 复用现有页面框架，还是新增页面？
5. 哪些现状约束不能打破？

新模块设计前，先拉通同层已有模块的概念边界，确认定位不与已有模块重叠。例如系统已有"结构化字段"类型模块，新模块就别再用同一抽象，要找自身独特定位。

以上不清楚之前，不要急着列字段表或算法。

2.3. 文档骨架

Planning / Roadmap PRD：

1. 需求概述。
2. 菜单结构 / 页面结构 / 产品结构。
3. 需求详情。
4. Roadmap。

Feature PRD：

1. 背景。
2. 目标。
3. 竞品对比。
4. 入口与结构定位。
5. 页面与交互。
6. 字段设计。
7. 规则 / 边界 / 异常处理。
8. 涉及 Agent / 算法时：后端与算法交互流程 + 算法处理流程。
9. 数据埋点 / 上线前确认 / 上线后观测。

数据类 PRD（看板 / 列表 / 详情）：

1. 需求概述（背景 / 目标）—— 涉及组默认不写；确需跨组协调时作者自己补。
2. 入口与产品结构。
3. 功能需求。
   1. 功能清单。
   2. 页面流转。
   3. 各页面 / 区域详情（按下方「层次原则」组织）。
   4. 指标口径定义（数据看板必备）。
4. 数据埋点。
5. 上线前确认 / 上线后观测。
6. 历史数据影响 / 与老系统迁移对照（迁移类必备）。

层次原则：按「页面 → 区域 → 模块 → 分支」逐层下钻，不要把不同层级的模块平铺到同一层。范例见 references/examples.md。

不写「方案价值」「范围说明」章节。功能边界由功能清单本身（列出本期做什么）隐含表达。

不写非功能 / 性能类需求：不写「非功能需求」表（性能 / 兼容性 / 可用性 SLA）、不在「上线后观测」放性能监控项（首屏 P95 之类）。上线后观测只留使用类（PV/UV、查询 / 导出 / 配置等操作频次）。性能 SLA 研发自有标准，PRD 不背书。

功能需求章节内部顺序：

1. 功能清单（overview table，列出所有模块及引用节号）。
2. 页面流转 / 跳转。
3. 各功能模块详情节（按功能清单顺序逐一展开）。

不要跳过功能清单和页面流转直接进详情。

2.4. 需与线上一致的内容：去抓，不要猜

迁移类需求、或正文要求"与线上一致"的要素（指标 ⓘ tooltip、线上既有文案 / 口径 / 命名），不要猜、不要拿别处口径浓缩顶替——抓线上原文：

1. 用 chrome-devtools MCP（默认）或可选高速工具 browser-cap（装了 BROWSER_CAP_DIR 才有），登录后台、打开目标页。
2. evaluate_script 在已渲染页面执行 JS 抓 DOM；多数 tooltip 文案在隐藏节点 / 属性里，直接读 DOM 即可，不必真 hover；读不到再派发 hover 事件。
3. 一字照搬线上，名实矛盾也照抄 + 标注"待确认是否纠正"，不替线上圆话。措辞看着不合当前页也照抄：那也是该页自己的正版线上文案——照抄进 ⓘ 文案列，不要删列、不要质疑它是 bug、不要花轮次考据"像是从 X 页 copy 来的"（那是钻牛角尖）。名实存疑只口头跟 PM 提一句，文案本身原样进表。

WebFetch 抓不到（SPA 空壳、无登录态）。完整浏览器接管 / 验收流程见 feature-acceptance skill。

二、通用排版规则

这四条贯穿全文，每条都附「为什么」——理解了原因才能在边界场景自己判断，而不是机械套规则。

3.1. 短句子 + 有序序号是基线

PRD 全文（正文、字段表说明列、操作逻辑、注释、blockquote）一律短句子。

1. 每条 ≤ 30 字，超过就拆。
2. 复合长句一律拆成有序序号。
3. 子条件用中文括号 1）2）3） 内联，避免多层 markdown 嵌套。
4. 不写隐含的系统行为（"阻止查询""联动刷新"这种从校验失败语义就能推出的行为）。

极简对照：

✗ 点击查询时，超 90 天则阻止并提示 X，结束时间早于开始也阻止并提示 Y，通过则刷新全页。
✓ **点击「查询」时**：
  1. 时间 >= 90 天，提示「X」
  2. 结束时间：1）早于开始，提示「Y」。2）等于开始，提示「Z」
  3. 满足全部验证项，校验通过

为什么：短句让评审快速断句，序号让评审精确指代到某条。复合长句让人漏掉关键边界，口径事故就藏在并列从句里。这是强偏好，不要软化。

3.2. 分项内容全部用有序序号，不用 bullet

PRD 正文里任何分项内容都用有序数字序号 1./2./3.，子项嵌套也用 1./2./3.，不用 - / * bullet。

含「分组标题层」：像校验里按字段分组（"同义词组名称""标准词"）、操作按场景分组这种分组标题本身也要序号，不能用 - 当分组项。从最外层到最内层全是数字序号，整份文档（含示例代码块）不出现任何 - / * 作分项符号。例：

1. **同义词组名称**：
   1. 为空时，提示"..."
   2. 超过 50 字符时，提示"..."
2. **标准词**：
   1. 某行为空时，提示"..."

这条同样适用于「表格单元格内」：表格说明 / 口径 / 校验 / 操作类列里任何分条的值都用 1./2./3. + <br> 显式分隔；不准粘成一段、用句号 / 分号连接、或粗体标签平铺堆砌。

判断标准：单元格里出现 ≥ 2 个粗体小标题，或 ≥ 2 个语义独立句子，就换成编号格式。

为什么：评审要能精确指代到某条（"第 6.3.2 个例子"），bullet 做不到。表格里粗体平铺，运营分不清边界。强偏好，违反等于口径事故。

完整反例 / 正例（含表格单元格编号对照）见 references/examples.md →「分项序号」。

3.3. 不主动加用户没要求的解释性 / 重申性提示语

只写用户明确要求的内容，不要为"让读者理解"擅自加解释性 blockquote、复述性提示、衍生性总结。

典型反例：重申矩阵已表达的事实 / 已在标题说过的正文又重述 / 无歧义的跨节引用 / 非关键风险的「注意」callout。

正文不写"为什么这么做"的目的 / 理由描述：如"加粗高亮便于运营人员快速定位""默认近 7 天方便用户对比""分组展示提升可读性"。需求只描述行为本身（"好评率、差评率加粗 + 颜色高亮"），不解释意图。

正文不写数据 / 文案来源与对齐说明：如"ⓘ 文案取自线上 X 页""与线上一致""口径沿用老系统，待确认""按 3.7 浓缩"。来源是写作过程，不进交付文档。线上既有的命名 / 口径矛盾若需提请确认，口头告诉 PM，不写进正文。

正文不写章节导读 / 定位元说明：如"本节是唯一口径源""3.3 / 3.4 只负责展示，以本节为准""下表汇总所有指标"。章节归属和优先级靠结构本身表达，引用处写"见 3.7.2"即可。

正文不写计数 / 分类括号注释：如"（共 11 张）""（4 项，无环比）""（3 项，含环比）"。数量读者数得出；无环比 / 含环比在指标口径总表「环比方向」列已表达。展示类章节只用有序序号列出支持指标，不加这类括号。