实现前的规格评审清单

规格评审不是走形式，它决定了团队是在编码前解决争议，还是在联调和上线时补票。

快速结论

评审时至少确认范围边界、验收标准、依赖、测试映射、灰度策略和回滚动作。缺少这些内容，代码评审和发布审批都会变成兜底场。

Review Checklist
- Scope agreed
- Acceptance mapped to tests
- Dependencies confirmed
- Stop-loss threshold named
- Rollback steps rehearsed

规格评审效果更好的前提是：每个角色提出各自职责范围内的专属问题，而不是所有人审查同一层面。以下角色专属问题让 15 分钟评审更加精准。

产品经理：规格目标是否与 PRD 意图完全一致？非目标是否明确到足以防止范围蔓延？验收标准集是否匹配 PRD 中的成功指标？灰度排期是否与发布计划对齐？
技术负责人/高级工程师：规格中是否有未计入的缺失依赖？API/DB 变更是否引入向后兼容风险？边界情况列表是否涵盖系统已知的失败模式？在数据变更的情况下，回滚策略在技术上是否可行？
QA 工程师：每条验收标准是否可在不追问的情况下转化为测试用例？错误码和响应体是否具体到可断言？所有与该功能交互的角色的权限路径是否均已测试？生产中是否有监控能够检测到边界情况失败？

如果评审时间不足，PM 和 QA 的问题应优先于工程问题。范围和可测试性失败是事后返工最常见的根源。工程未知项通常可以在实现中以较低代价解决，而范围或可测试性缺口的代价更高。

并非规格中的每个缺口都应阻塞实现。有些缺口风险较低，可以在编码过程中解决；有些风险高，必须优先解决。区分标准在于：该缺口是否影响一个实现开始后无法安全重新讨论的决策。

"有条件推进"的前提是明确的：条件被书面记录，有责任人，有在发布门控前的解决日期。未文档化的条件是隐藏风险，而非被管理的风险。

规格不应在实现过程中悄悄改变。当实现揭示某条验收标准因技术约束、依赖行为或 API 消费者的新信息而无法按原文实现时，变更必须重新经过评审，而不只是在文档中更新。

保持规格与实现同步的代价很低——一条评论和一条通知。而在不更新文档的情况下发布与商定规格有出入的实现，代价极高：QA 对着旧规格测试，PM 宣布未构建的功能，生产事故的溯源规格与已部署行为不符。

一次有效评审不只是“大家同意了”。会议结束时至少应留下四类证据：已确认的范围和非目标、每条验收标准对应的测试方式、被接受的风险及其责任人、发布和回滚条件。没有这些证据，后续代码评审很难判断实现是否偏离了原始意图。

如果团队使用 AI 编码工具，还应把最终规格版本作为提示上下文，并明确禁止实现非目标内容。这样模型输出可以围绕已评审范围工作，而不是根据模糊标题自动补全未经确认的功能。

把这份清单加进下一个sprint的需求评审会。会前发给PM、开发和QA，会上逐条检查。如果某项说不清楚，在编码启动前补上——而不是留到测试阶段发现。

评审后建议把阻塞项和有条件推进项分开记录。阻塞项没有解决前不应启动实现；有条件推进项必须有负责人、截止时间和发布前验证方式。

更新日期：2026-03-10

一次有效的规格评审不应该只留下“通过”或“不通过”。它应该留下更新后的 Spec、明确的阻塞项、被接受的风险、责任人、补充测试，以及进入实现前必须完成的下一步。否则评审意见很容易散落在会议纪要或聊天记录里。

如果某个问题暂时无法解决，可以把它标成条件通过：写清谁负责补证据、什么时候补、没有补上会阻止哪一步。这样评审门禁才不会变成口头提醒。

评审结束后，所有未关闭的问题都应进入可追踪系统：issue、PR checklist、测试计划或发布清单。每个动作需要负责人、截止时间和验证方式。没有这些字段，评审结论很容易在实现阶段重新变成口头约定。

如果某项风险被接受，也要写清接受原因和适用范围。这样发布后回看时，团队能区分“已知并接受的权衡”和“没有被发现的遗漏”。

本指南涵盖 实现前的规格评审清单，面向 Spec-First 工程团队。示例为说明性场景，非生产代码。