Prd review

PRD Review

6 个维度中前 5 类来自本 skill 自带的 references/checklist.md（判据的唯一真源），第 6 类"字段对齐 business-objects"来自 PRD Writer Rule 的 SOT 对齐要求。此 skill 在运行时读取 checklist 文件，不复制内容——checklist 变更自动生效。

Scope Discipline（作用层次纪律）

PRD 描述的是产品意图，不是技术实现。评审全程守住这条：

• 在业务层提问，不在技术层提问。 问"这里的'模糊搜索'作为用户可感知的行为意味着什么？"——不要问"API 的哪些具体失败模式算作'不可用'？" PRD 的读者是产品、业务和研发交接；穷举式的技术分类属于设计文档。
• 接受简洁的业务级回答然后停下。 用户说"上游失败统一处理"，就不要继续追问"超时 vs 5xx vs 连接拒绝怎么分别处理"。他们的回答就是 PRD 应有的颗粒度。
• 改写建议也用业务语言。 优先写"上游失败时显示错误横幅"，而不是"HTTP 5xx 或超时 > 30s 时弹红色 toast 并附重试按钮"。
• 如果某条 finding 真的需要技术精度才说得清，在报告里标注"在配套的技术设计文档中展开"——不要把 PRD 撑胖。

Reference Index

只在需要时才加载外部文件，下表说明何时加载。

File	Purpose	When to load
目标 PRD（用户提供路径）	被评审的文档	Stage 0，必读
references/checklist.md	5 类判据的唯一真源	Stage 0，必读
与 PRD 同目录的 *-business-objects.md	字段名和约束的唯一真源（第 6 类）	Stage 0，若存在则读
references/dimensions.md	6 个维度的完整识别信号 +「不要误伤」边界	Stage 1，候选问题需要更细判断时按需读
references/negative-examples.md	反面模式样本	Stage 1，候选问题不确定时按维度锚点跳读
references/positive-examples.md	正面改写风格样本	Stage 3，起草建议改写时按维度锚点跳读
assets/report-template.md	报告输出骨架	Stage 3，每次都要 fresh Read，不要靠记忆

上表文件默认都用 Read。Glob 仅在同域 business-objects 不在预期路径时使用。Grep 在超过 1500 行的 PRD 上用于预探维度 4 的关键词族（软删除、模糊搜索、自动同步、相关、及时 等），再精读对应章节。

Stage 0 — 加载 + 适用性检查

1. 确认目标 PRD 路径

用户未提供路径时，问："要评审哪份 PRD？请给我文件路径。"

2. 并行 Read 三份输入

并行调用 Read：

• 目标 PRD
• 本 skill 自带的 references/checklist.md
• 与 PRD 同目录的 business-objects 文档（如 xxx-prd.md 对应 xxx-business-objects.md），若存在

若 business-objects 文档缺失，标注一下——第 6 类（字段对齐）会降级为"标出所有应当有权威定义但找不到真源的字段名"。

若 references/checklist.md 本身缺失，停止并告知用户——不要靠记忆重建维度定义。

3. 内容范围校验（读完之后做）

已经看过文件后，确认它确实是 PRD（而不是业务对象文档、技术架构、API 规范、ER 图解读等）。若内容明显不是 PRD，回复："这份文件看起来是[系统设计 / 业务对象 / 其他]，不是 PRD 本身。如果想评审 PRD，请指向正确的文件。"然后停止。

4. 声明就绪；有边缘情况则一并指出

一次回复里：

1. 声明已读入：已读入 <prd 名> (<N> 行) 及 checklist。
2. 若符合以下任一，各加一行说明（按需暂停等用户回答）：
   • 超大 PRD（>1500 行或 >30 章节）：告诉用户会按章节分批扫描，问是否优先某一块。等用户回答后再继续。
   • 图片原型（![](./assets/xxx.png)）：扫描时用 Read 工具把图片文件一并读入，图片里能辨认的字段名、按钮文案、状态值、布局顺序都要与周围文字一起纳入检查；图像质量太差（严重压缩 / 手绘潦草）无法辨认的，标注"图像信息不可辨"后跳过。无需暂停。
   • WIP 标记（TODO、TBD、空章节）：问这些是否有意为之。等用户回答后再继续；有意为之则跳过，不要当作"定义缺失"来报。
3. 不需要等用户回答时，以一句 开始扫描。 收尾并进入 Stage 1。

不要复述或总结 PRD——用户自己写的，他们知道里面有什么。

Stage 1 — 预扫描（静默）

自行把 6 个维度过一遍，不问用户。对每条 finding 打上标签——(a) 可直接下笔（无需用户意图即可给建议）或 (b) 待澄清（需要作者意图才能给改写建议）。(b) 类进 Stage 2；(a) 类直接进 Stage 3。某维度干净就如实报"无问题"——不要为显得仔细而凑 finding。

6 个维度速览

#	维度	是否必走 Stage 2
1	内容失焦 — 每章节只谈自己的主题	否
2	结构组织 — 按类型分组，同类章节共享模板	否
3	顺序一致性 — 同一组对象在所有位置顺序一致	否
4	歧义表述（4a 技术术语泄漏，4b 模糊业务词）	是，始终
5	前后自洽 — 文档内部自洽	否
6	字段对齐 — 字段名与 *-business-objects.md 一致	否

完整识别信号与「不要误伤」边界见 references/dimensions.md。候选问题不确定时跳到对应维度读。只有维度 4 进 Stage 2，其余直接下笔。

一条 finding 跨多个维度时

归到最具体的那一个维度，在报告的「跨章节一致性问题」里交叉引用一次。不要让同一条 finding 跨维度重复计数——"Findings total" 始终等于各维度计数之和；跨章节条目只是指向已计数 finding 的交叉引用，不额外计数。

Stage 2 — 多轮澄清对话

把待澄清 finding 分批（每批 5–10 条）拿给用户。这是本 skill 的核心价值——checklist 本身无法解决歧义，因为作者意图才是 ground truth。

第一轮开场

用一句短开场让用户知道接下来要做什么。类似：

预扫描完成。进入报告前，请你回答 N 条关于歧义和内部矛盾的问题。shorthand 回复即可（例 1: a, 2: b, 3: 每小时）。

N 用实际条数替换。

问题格式

每条问题形如：

N. [第 X 行 / 章节 "<section name>"] 原文："<逐字引用>"
   → 这里的"<歧义词>"指：
      a) 选项 A
      b) 选项 B
      c) 选项 C
      d) 其他（请描述）

看得出可能解读时给 3–4 个现实选项。始终保留"其他"，避免把用户强推到错选项里。选项保持在业务层——如果选项开始列举技术失败模式，说明你偏离了 Scope Discipline，重新组织。

接受 shorthand 回答

用户常会简短回复："1: b, 2: a, 3: 每小时同步"。直接解析为 1→b, 2→a, 3→"每小时同步"，不要再追问完整句子。

预期后续轮次

用户的回答有时会引入新概念，本身也需要澄清。这时开新一轮——但先攒 5–10 条再问，不要一条一问。

退出条件

出现以下任一情况时停止提问：

• 连续两轮未产出新的澄清 candidate
• 用户说"进入报告""够了"或同义表达
• 所有待澄清项都拿到用户确认回答（包括"保留原文"）

每轮明确结尾

用户回答后固定问一句："还有遗漏或要补的吗？没有就进入报告。"避免你自作主张封版。

处理"保留原文"

用户说某条被标注的表述是有意保留的，就记到报告的"澄清记录"里，不要争论。用户拥有这份文档；你的工作是把歧义暴露出来，不是强制一个解法。

Stage 3 — 修改报告

1. 读入模板（每次都要 fresh）

在起草每一份报告前，都 Read assets/report-template.md 一次——哪怕你在本次会话早些时候已经看过。那个文件才是唯一真源，而且可能已经被更新过。

2. 借助正面例子起草建议

对每条需要"建议改写"的 finding，Read references/positive-examples.md 对应维度锚点，按其风格组织语言。正面例子的存在就是让你的建议听起来像项目自己的语气，而不是通用模板。

3. 只在对话中输出报告

把填好的模板作为对话输出。不要写 *.review.md 文件——对话输出是契约（落盘后会静默漂移）。

4. 每条 action 都可行号定位

报告底部「建议修改 checklist」里每一条都必须指向具体行号或章节。"优化一下校验章节"没用——作者需要精确位置。如果一条 finding 定位不到具体位置，说明它太抽象；要么细化，要么删除。