---
name: spec-review
description: 在团队开发之前审查 PRD、产品规格或功能简报：找出含糊的措辞、缺失的状态（空状态、加载中、出错、无权限）、缺失的成功指标、缺失的灰度发布和回滚方案，并以第一次使用的用户身份逐步走一遍流程。返回按严重程度排序的阻断问题和待澄清问题。当有人发来 PRD 或需求文档，要求评审、把关、提意见、找漏洞，或者问“这个可以开发了吗？”时使用。
---

# 需求规格评审

当工程师、设计师和测试人员各自根据一份规格做出来、测出来的是同一个东西时，这份规格才算可以开发。评审要找的就是他们会产生分歧的地方，以及没人写下来的状态。先以第一次使用的用户身份走一遍流程，再看需求列表：漏洞会在走流程时暴露出来。

## 适用场景

- 工程团队根据 PRD 或规格做估算、开始开发之前。
- 规格修改过，需要再看一遍。
- 某个功能上线后出了意外，想更严格地检查下一份规格。
- 不适用于根据笔记写规格：用 prd-from-notes。也不适用于审查已完成的页面或文案：用 landing-copy-review 或设计评审。

## 需要准备

- 规格或 PRD 的文字，包括所有设计稿说明。
- 目标用户是谁（如果规格里没写）。如果没有，就以没有受过任何培训的首次用户身份来评审，并注明“[假设]”。
- 可选：截止日期和团队，便于判断范围。

## 步骤

1. **以首次用户的身份走一遍流程。** 从用户进入的地方开始（邮件链接、导航菜单、空账户），逐步讲述：他们看到什么、必须做什么决定、点了什么。凡是规格没说明接下来出现什么的地方，记为一个漏洞。凡是会让新用户困惑的按钮文字或问题，也记下来。
2. **检查每个页面的状态。** 对每个页面或组件，检查：空状态（首次使用、无结果）、加载中、出错、部分数据、无权限和成功。NN/g 建议，空状态要显示系统状态、教用户怎么开始，并提供直达任务的路径；数据还在加载时，绝不显示“暂无记录”。错误提示应该醒目、用通俗的语言、给出建设性的指引，并保留用户已输入的内容。
3. **找出含糊的词。** 标出“快”“容易”“简单”“直观”“应该”“等”“和/或”“一些”“按需”。每个都需要一个数字、一份清单或一个决定。标出任何两位读者会用不同方式测试的需求。
4. **检查规则和限制。** 谁可以做这件事？最多多少个？达到上限时会怎样？上线时，现有的数据和用户怎么办？如果缺失的答案会改变数据模型，就是阻断问题。
5. **检查指标。** 必须有一个与问题挂钩的主要指标、一个基线、一个目标，以及衡量方法。如果要统计的事件还不存在，那就是规格缺失的一项需求。
6. **检查灰度发布和回滚。** 是否放在功能开关后面？谁先看到（内部、一定比例、某个用户群）？什么指标会触发回滚，能否不发版就关掉？Martin Fowler 关于功能开关的指南区分了发布开关、按比例逐步放量和紧急关闭开关；紧急关闭开关必须能快速切换，不需要重新发版。
7. **排序并写出问题。** 阻断 = 团队无法开发或测试，或者会危及数据或信任。应修改 = 会导致返工或混乱。小问题 = 措辞。每条问题都引用规格原文，说明为什么重要，并提出修改方案或问题。

## 输出格式

```markdown
# 需求规格评审：[规格名称]

**结论：** [可以开发 / 修完阻断问题后可以开发 / 还不能开发] — [一句话原因]

## 首次用户流程走查
1. [步骤：用户看到什么、做什么] — [漏洞或“清楚”]

## 阻断问题
| # | 规格原文 | 问题 | 修改方案或问题 |
|---|---|---|---|
| B1 | “[引用]” | [为什么阻断] | [建议] |

## 应修改
| # | 规格原文 | 问题 | 修改方案或问题 |
|---|---|---|---|

## 缺失的状态
| 页面 | 空状态 | 加载中 | 出错 | 无权限 | 备注 |
|---|---|---|---|---|---|
| [页面] | [已覆盖 / 缺失] | ... | ... | ... | [备注] |

## 指标与发布
- 主要指标：[有 / 缺失] — [备注]
- 灰度发布：[有 / 缺失] — [备注]
- 回滚触发条件和紧急关闭开关：[有 / 缺失] — [备注]

## 小问题
- [措辞]
```

## 示例

**输入（节选）：** “用户可以邀请自己的会计，权限为只读。邀请应该简单。只读用户不能编辑。我们会衡量使用率。1 号对所有人上线。”

**输出：**

```markdown
# 需求规格评审：只读席位

**结论：** 还不能开发 — 没有定义状态，指标无法衡量，上线后没有退路。

## 首次用户流程走查
1. 所有者寻找邀请入口 — 规格没说在哪个页面；漏洞。
2. 所有者输入邮箱 — 规格没说如果该邮箱已经是成员会怎样；漏洞。
3. 会计打开邀请邮件 — 没有规定邮件内容；漏洞。
4. 会计进入应用 — 他们首先看到什么？一个空的仪表盘会被理解为“坏了”；漏洞。

## 阻断问题
| # | 规格原文 | 问题 | 修改方案或问题 |
|---|---|---|---|
| B1 | “不能编辑” | 导出算编辑吗？评论呢？两位工程师会给出不同答案。 | 列出允许的操作：查看、导出 [待确认]，其他都不允许。 |
| B2 | “1 号对所有人上线” | 没有功能开关，没有回滚触发条件。一个权限漏洞就会暴露所有账户。 | 放在功能开关后面，先对内部账户上线，再放量到 10% [本技能的默认值]；加一个紧急关闭开关。 |
| B3 | “我们会衡量使用率” | 没有事件、基线或目标。 | 每周统计至少有 1 个已接受只读邀请的账户数；目标待定。 |

## 应修改
| # | 规格原文 | 问题 | 修改方案或问题 |
|---|---|---|---|
| S1 | “邀请应该简单” | 无法测试。 | “所有者在团队页面点击 3 次以内即可发出邀请。”[本技能的建议] |
| S2 | （无） | 没有限制只读席位的数量。 | 决定一个上限，或写明“不设上限”。 |

## 缺失的状态
| 页面 | 空状态 | 加载中 | 出错 | 无权限 | 备注 |
|---|---|---|---|---|---|
| 团队页面的邀请 | 不适用 | 缺失 | 缺失 | 缺失 | 非所有者看到什么？ |
| 会计看到的第一个页面 | 缺失 | 缺失 | 缺失 | 不适用 | 需要一句“您的权限为只读”的提示 |

## 指标与发布
- 主要指标：缺失 — 见 B3。
- 灰度发布：缺失 — 见 B2。
- 回滚触发条件和紧急关闭开关：缺失 — 见 B2。

## 小问题
- “会计”和“只读用户”指的是同一个角色；选一个。
```

## 发送前检查

- [ ] 流程走查从真实用户进入的地方开始，覆盖到成功为止的每一步。
- [ ] 每条问题都引用了规格原文，遗漏的内容写“（无）”。
- [ ] 每个阻断问题都有修改方案或直接的问题。
- [ ] 状态表覆盖了规格中提到的每个页面。
- [ ] 指标、灰度发布和回滚都标明了有或缺失。
- [ ] 你建议的默认值（比例、点击次数）标为建议，而不是规格本身的内容。

## 常见错误

- 只审查需求列表。大多数漏洞藏在步骤之间，所以先走流程。
- 列出 40 条小问题。阻断问题放在最前面；小问题最多 5 条。
- 重写规格。指出漏洞并提出建议；修改由作者负责。