评估 SDD 方案的八类标准
方案的形态和约束强弱，只能说明它大致怎样组织工作。评估一个具体方案，还要看它设了哪些检查、每道检查防的是哪种翻车，以及由什么机制执行。
八类标准防的是跑偏需求和自称已完成。编造接口和字段不归它们管，靠的是动手前核实：接口、字段和现有行为是否存在，要进代码和运行环境确认。评估时要分开记录”有没有”和”怎样强制”；写进文档的要求，要有工具检查或拦截才算门禁。
4.1 八类把关标准
每一类都要回答三个问题：它防哪种翻车，具体产物或动作是什么，哪一部分能由工具检查。强制力越高，跳步的空间越小，等待、配置和恢复成本也会增加。
-
需求唯一 ID + 双向可追溯。 每条需求有稳定的编号，并与设计、任务、实现产物和测试建立关联。正向追溯用来检查需求有没有落地，反向追溯用来判断某个产物的变更会影响哪些需求。需求工程里通常用追溯矩阵（RTM）表示这组关系。候选方案还要能维护这些关联，找出断链和过期记录。
-
需求与验收条件的结构化表达。 EARS 用有限句式约束需求文本；Given-When-Then 用前提、事件和预期结果描述行为场景；INVEST 是判断用户故事质量的检查表，不规定句式。它们分别从表达、行为和故事质量上压缩歧义。句式和字段可以用 lint 检查；验收条件是否完整表达了意图，仍需要人或独立评审者判断。
-
what 与 how 分离。 规格写要做什么、什么结果算完，技术实现放进设计或计划。这能防止需求过早绑定某个实现，也方便单独审查需求是否正确。候选方案如果用两个阶段或文件承载 what 和 how，还要检查实现阶段能否绕过未确认的需求。
-
规格质量门。 写代码前，检查规格有没有歧义、遗漏和前后矛盾。Spec Kit 把澄清、需求质量检查表和跨产物一致性分成了独立命令，其中 checklist 把自己定义为”需求文本的单元测试”。这些检查能暴露未定义的场景和冲突；能跳过的命令只起评审辅助的作用。
-
测试即验收证据 + 变更检测。 能写成可执行行为的验收条件，先观察它失败，再写实现让它通过。这样的测试才能作为独立于 AI 自我报告的验收证据。测试单独提交或记录哈希，建立的是一条可比较的基线，文件照样能改。要保护这份证据，至少要在合并前比较测试与已批准基线；如果方案声称能在执行时禁止修改，还要实测文件工具和 shell 写入是否都会被拒绝。
-
规格版本化 + 多视角评审。 规格进 git，和代码一起保留历史、查看差异和进行评审。评审可以包括作者自查、队友 PR 审查和独立 AI 审查，具体层次跟着项目风险走。版本控制记录变化，规格和代码是否同步要另查；要强制评审，还需要 PR 规则或工作流状态门。
-
带验收条件的任务分解。 大规格拆成可以独立实现、独立验证的任务，每个任务带着它要满足的验收条件。这能缩小单次改动和验证范围。每个任务还要能反查需求，并给出可执行的完成判据。
-
非功能需求单列共享。 性能、安全、合规要求和团队通用技术标准，可以抽成共享文件，避免每个规格重复维护。要检查任务是否显式引用这份文件，或工具的加载机制是否真会把它放进当前上下文。性能阈值、安全扫描和合规规则是否被遵守，还要由测试、lint 或评审确认。
把八类标准并排后，可以先用下表快速筛查：
| 把关标准 | 防哪种翻车 | 可检查或强制的部分 |
|---|---|---|
| 需求唯一 ID + 双向可追溯 | 跑偏需求（漏做，变更影响不清） | ID 格式可 lint，断链可由追溯工具检查 |
| 需求与验收条件的结构化表达 | 跑偏需求（意图含糊，场景漏写） | 句式可 lint，语义覆盖靠评审 |
| what 与 how 分离 | 跑偏需求（需求被实现细节绑定） | 可分文件或阶段，跳步要另设门 |
| 规格质量门 | 跑偏需求（歧义、遗漏和矛盾进入实现） | 可用检查表和一致性分析，是否必须运行另查 |
| 测试即验收证据 + 变更检测 | 自称已完成（验收证据被改写） | 基线和差异可检查，执行时禁改必须实测 |
| 规格版本化 + 多视角评审 | 跑偏需求、自称已完成（规格与代码漂移，单一视角漏判） | git 保留差异，PR 或状态门可卡批准 |
| 带验收条件的任务分解 | 自称已完成（完成边界不清） | 模板可要求关联需求和验收条件 |
| 非功能需求单列共享 | 跑偏需求（通用要求遗漏或冲突） | 加载可检查，遵守情况靠测试、lint 或评审 |
4.2 审批门与审计留痕
审批门管阶段之间谁来确认。规格未确认就不进设计，设计未批准就不进实现。有的流程只提醒人停下检查；有的工作流会验证批准状态，没有通过就拒绝进入下一阶段。硬门能减少跳步，也会引入等待和异常恢复成本。
审计留痕管的是事后能否重建过程。有效记录至少要回答：谁在什么时候，根据哪个版本的产物，批准了什么。git 提交和 PR 能记录文件差异与评审结果，但不一定记录 agent 的每个动作，也不一定能证明批准者当时看到的具体内容。是否需要更细的事件日志和签证，由风险、协作方式和合规要求决定。
评估审批门时，要尝试不批准直接进入下一阶段。评估审计留痕时，从一次已批准的变更反查批准人、当时的产物版本和后续改动。记录答不上来的部分，按缺失记。
4.3 三种强制层次
同一类标准可以由不同机制执行。评估时按实际机制归入下列三层：
| 强制层次 | 什么时间拦 | 判定方法 |
|---|---|---|
| 执行时阻断 | agent 调用写入工具或 shell 时，hook、沙箱或编排器拒绝动作 | 实际尝试越界写入，确认所有写入路径都被拦下 |
| CI 或合并门阻断 | 改动已经发生，在提交或合并前检查 | 篡改基线、断开追溯或绕过测试，确认变更无法合并 |
| 约定 | 没有自动拦截，由人和 agent 按文档执行 | 检查规则是否进入任务上下文，并由评审查遗漏 |
以测试变更为例，哈希和单独提交只能建立基线。CI 比较基线后可以拒绝合并，但不阻止 agent 在本地修改文件。要算执行时阻断，必须证明文件工具、shell 重定向和其他可写通道都会被拒绝。带哈希的合同、名为 freeze 的功能，也要实测过才能归入这一层。
按这套标准评估方案时，每一格都要留下具体机制、证据来源和绕过结果。通过标准是：每个”有”和”强制”都能指向官方文档、源码或一次实测。
本章小结
八类标准检查方案用哪些控制防跑偏需求和自称已完成；审批门和审计留痕检查谁来确认、事后能否还原。对每项能力再区分执行时阻断、CI 或合并门阻断与约定，才能比较候选方案的实际约束力。
参考与出处
- 自动化双向需求追溯是需求追溯实践之一：Jama Software
- EARS 的用途、句法和需求模式：Alistair Mavin 的 EARS 官网
- Given-When-Then 描述前提、事件和预期结果：Cucumber 的 Gherkin 参考
- INVEST 是用户故事的质量检查表：Bill Wake 的原始说明
- what 与 how 分离、共享非功能需求、评审、带验收条件的任务分解：Allegro 的 SDD 实践总结
- Spec Kit 对规格一致性和检查表的定义：Spec-Driven Development 说明、checklist 命令模板