编码前的规格评审检查清单

大多数规格评审只是走过场。三个人扫一眼文档，有人写一句"LGTM"，然后所有人带着同样的模糊地带继续往前走。真正的规格评审，会抓住那些一周之后会让你付出代价的东西。下面这份清单，是我在放任何规格通过评审之前都会过一遍的。

发布于 2026-02-25 · ✓ 已更新 2026-05-11 · 阅读约 7 分钟 · 作者：Spec Coding 编辑团队 · 审校：编辑政策

规格评审到底是为了什么

规格评审不是一个点头盖章的仪式。它是发现"缺了什么"最便宜的时机。每一个活到实现阶段的模糊点，解决成本大约要多花 10 倍；每一个活到 QA 阶段的模糊点，要多花 50 倍。评审这五分钟，是为了省下后面的五个小时。

如果一个评审者走出会议后只觉得"这文档写得挺好"，那这次评审多半已经失败了。一次好的评审，产出的是一份待修项清单，不是掌声。

这份清单，按风险分组

我把检查项按"模糊在哪里最痛"来分组。范围和决策归属放在最前面——它们暴露最大的错位。接下来是验收标准和边界情况，也就是实现环节最容易自己编故事的地方。再后面是上线和回滚，它决定了凌晨两点一次糟糕的发布能不能被叫停。

范围与决策

• 目标是以用户结果或系统结果来描述的，而不是一份功能清单吗？
• 是否明确写下了至少两到三个非目标？
• 范围变更是否有一个具名的负责人——是具体的人，不是某个团队？
• 规格是否点出了对这次评审范围之外的团队或系统的依赖？

验收标准

• QA 是否能只凭 AC 写出测试用例，而不需要回过头问作者任何问题？
• AC 是否写成 Given/When/Then（或者另一种显式的输入-触发-结果格式）？
• 每一条 AC 是否同时包含正常路径和至少一条失败路径？
• 性能预期是否以数字表达（延迟、吞吐、预算），而不是用"快"这样的形容词？

边界情况与失败模式

• 遇到重复请求、网络重试或部分失败时会发生什么？
• 用户持有过期数据或过期会话时会发生什么？
• 输入边界——空值、最大长度、unicode、负数——会发生什么？
• 多个客户端并发写入时会发生什么？

上线与回滚

• 是否有一个带明确百分比或用户群组的灰度方案，而不是一句"逐步放量"？
• 回滚阈值是否用具体数字告警表达，而不是"看起来不对劲就滚"？
• 回滚具体是指代码回退、配置开关、任务暂停，还是数据修复？这几种方式的响应时间相差一个数量级。
• 如果是数据库变更，迁移是否向前兼容，让旧代码还能继续跑？

评审到底应该怎么跑

异步跑。同步的规格评审，往往会演变成作者在现场讲解——而这意味着文档本身并不是自包含的。如果作者还要解释，那规格已经违背了自己的目标之一。

我实际在用的流程是这样：

• 作者在希望签字前 48 小时发出规格。时间再短，评审者会觉得被赶，然后随手放行。
• 评审者在文档里留评论，每个关切独立一个线程。用上面那份清单——需要的话直接把问题复制粘贴过去。
• 作者对每个线程书面回复。"已修复"是不够的；到底改了什么？改在哪一节？
• 第二轮。懒散的第一轮评审会在这一步露馅。如果第二轮没有发现任何新关切，那第一轮大概率过得太浅。

代表规格还没准备好的红旗

下面这些模式，我现在看到就会退回：

• "合理"这个词。比如"合理的错误处理"或"合理的性能"。要么定义它，要么删掉它。
• 验收标准里的被动语态。"系统会被通知"——被谁通知？怎么通知？在什么时限内？主语和时机，必须具体。
• 只描述功能，没有数据模型。如果规格里没有 schema，哪怕只是关键字段，实现阶段也会自己编。
• 完全没提错误状态。每一条正常路径至少对应三个错误状态。没写下来，就会在生产环境被发现。
• 提到了跨团队依赖却没有归属。"支付团队会暴露一个 API"——那边具体是谁同意的？什么时候同意的？

评审本身不应该做的事

• 不要争论实现选择。AC 清晰的前提下，让工程去选路径。在规格评审里评审实现，就是在给评审加戏。
• 不要有条件地批准。"LGTM，只要你加上 X"——你是在批准一份还没做的工作。退回修改，重新评审。
• 不要因为作者资深就盖章放行。资深作者照样会漏掉东西；这正是我们要做评审的原因。

退回修改 vs. 升级决策

如果缺口或模糊点是作者多想一会儿就能补上的，就退回修改。如果是范围或优先级上的分歧，需要经理级别来拍板，就升级决策。如果你分不清是哪一种，那多半是披着"模糊"外衣的升级问题。

怎么知道这次评审是真的起作用了

判断标准不是规格看上去漂亮不漂亮。是 QA 能不能不用在 Slack 上追着作者就开始写测试；是实现跑起来之后，能不能连续两天以上没人来问作者要文档里的澄清。

事后看还有第二个信号：那些事故和返工，能不能回溯到一个当初没进规格的决策？如果评审做得好，这条曲线会往下走。

现场笔记：真正救下发布的评审意见

有价值的规格评审意见应该具体到作者可以直接修，不需要再开一轮会。某次 checkout 改动里，最关键的评论不是“重试怎么办”，而是下面这段：

阻塞项：
当前规格定义了 POST /checkout，但没有定义幂等性。
请补充：
- idempotency key 从哪里来
- 重复请求返回什么
- 超时后重试如何处理
- payment capture pending 时客服看到什么状态

这一条评论直接改变了实现方案，也让 QA 多了四条测试。规格评审清单应该追求的就是这种可执行程度。

评审时看什么

这篇文章适合用在编码前最后一次规格评审时。别从“原则”聊起，直接拿一条真实改动来对照，看看规格里还缺什么。

• 区分阻塞项和偏好项。
• 记录团队接受了哪些风险。
• 给每个未解决评论负责人和日期。
• 确认测试、样例、查询或发布控制已经有位置。

评审结束不应该只留下“LGTM”。它应该留下能被实现和 QA 继续追踪的东西。

例子：如果回滚方案缺失，评审意见不要写“建议考虑回滚”，而要写“阻塞：补充开关、迁移回退、负责人和预计恢复时间”。这样评论才会推动规格变更，而不是变成礼貌提醒。

落地例子

订阅升级工单不能只看有没有测试。清单要问：当前计费周期如何处理，分摊费用是否出现在发票上，哪个事件表示升级完成，客服说明里如何解释收费，降级回滚是否可行。任何一个问题没答案，代码都会替产品做决定。

评审意见也要具体到可修改的条目。不要写“这里需要更清楚”，要写“补充 proration 公式、发票展示字段和失败回滚规则”。

清单最好不要超过一页。真正要挡住的是会造成返工或事故的缺口：验收标准不可测试、失败路径缺失、数据迁移无回滚、发布没有停止阈值。其他偏好可以记录，但不要把它们包装成阻塞项。

可复制产物：规格写作片段

当工单看似清楚但还缺验收语言时使用。它要求作者写出角色、触发、结果和证据。

规格写作评审片段：编码前的规格评审检查清单

本次要做的决策：
- 把模糊需求改写成可以由工程和 QA 共同判断的验收条款。

责任人检查：
- 产品责任人：
- 工程责任人：
- QA 或运维评审：

范围边界：
- 本次包含：
- 本次不包含：
- 仍需确认的假设：

验收证据：
- 测试或 fixture：
- 日志、指标或截图：
- 人工复核步骤：

写作边界：避免模糊动词，每条验收标准都要有可见的通过或失败信号。

评审追问：
- 没参加需求会的人还会误解哪里？
- 哪个证据能证明这次改动足够安全，可以发布？

旗舰使用路径

这是 Spec Coding 用来承接「编码前评审门禁」主题的核心参考页之一。建议把它放到真实工单、PR 或发布评审里使用，而不是只当背景文章阅读。

• 适合从这里开始：实现准备开始，团队需要一份能拦住风险的检查表。
• 建议复制：评审门禁和已接受风险记录。
• 需要附上的证据：范围、回滚、测试和未解假设都有明确批准。
• 搭配使用：规格评审清单 与 下载资源。

旗舰页使用路径：
- 在计划或评审时打开本文。
- 把对应产物复制到工单或 PR。
- 用自己的系统、责任人和失败模式替换示例值。
- 如果证据行仍为空，就不要进入实现。

二次审阅记录：清单必须能拦住某件事

这次复看时，我把重点放在“拒绝条件”上。不能阻止实现的清单，只是阅读材料。文章应该让评审者能有依据地说不，而不是靠感觉说“我不放心”。

可直接复制的阻断语：
- 阻断，直到回滚触发条件写明指标和责任人。
- 阻断，直到 AC-3 有 fixture 或人工验证步骤。
- 阻断，直到 API 调用方列表补全。
- 阻断，直到非目标明确排除历史数据迁移。

编辑复核记录

复核日期：2026-04-29。本次补充了可复用产物，按相关主题 Hub 检查了文章定位，并收紧下一步链接，让页面更像可操作参考，而不是孤立长文。