05 第一篇 · 先搞懂：为什么、是什么、选什么

为什么是 spec-kit

在 spec-kit、OpenSpec、BMAD、AI-DLC 和 Kiro 原生 spec 这五个候选中，本手册选择 spec-kit 作为主干。它的强制力不如 AI-DLC，安装和产物也比 OpenSpec、Kiro 原生 spec 多；但按八类标准逐项比较，除了 AI-DLC，它的覆盖面最完整，而且可以按任务大小增减命令。

这个选择不等于把缺口忽略掉。spec-kit 常用的手动命令路径仍靠 agent 和人遵守阶段顺序，需求到代码和测试也没有完整追溯。需要强制的部分，要分别放进 CI、合并规则或额外的执行时阻断。

5.1 五个候选的检查结果

下面的”完整”表示方案有直接承接这项标准的模板、命令或流程；“部分”表示只覆盖其中一段，或者仍要靠项目自行约定；“缺”表示主流程里没有对应机制。这里比较的是能力覆盖，不代表这些能力已经形成硬门。

把关标准spec-kitOpenSpecBMADAI-DLCKiro 原生 spec
需求唯一 ID + 双向可追溯部分：需求有编号，没有内置 RTM部分：增量规格有结构，没有内置 RTM部分：需求有编号，没有完整 RTM完整：需求编号和追溯关系由流程维护部分：需求分条记录，没有双向追溯
需求与验收条件的结构化表达完整：用户故事带 Given-When-Then 场景完整：需求带场景格式和结构校验完整：用户故事和验收条件有固定结构完整：用户故事和验收条件有编号与质量规则完整：需求使用 EARS 句式
what 与 how 分离完整：规格与计划分开完整：规格与设计分开完整：需求与架构产物分开完整：需求阶段与设计阶段分开完整：需求、设计和任务分开
规格质量门完整：澄清、检查表和一致性分析分成独立命令部分：校验器检查规格结构完整：有多视角评审流程完整：各阶段有检查和独立评审部分：有需求分析和阶段检查点
测试即验收证据 + 变更检测部分：任务可以要求测试，基线比较要自行补缺：主流程没有测试基线保护部分：工作流要求验证，没有测试变更保护部分：有测试合同和验证记录，不保护测试源码缺：主流程没有测试基线保护
规格版本化 + 多视角评审部分：产物可进 git，评审门要自行配置部分：增量规格和归档可版本化，评审靠外部流程完整：规格版本化并有多视角评审完整：阶段产物、评审结论和后续变更都有记录部分：产物可版本化，检查点仍靠人确认
带验收条件的任务分解部分：任务按用户故事组织，单项任务不一定带独立验收条件部分：任务清单承接规格，单项任务的验收条件要自行补完整：故事拆成带验收条件的任务完整：实现步骤与需求、验收条件关联部分：任务从需求生成，单项任务的验收条件要自行补
非功能需求单列共享完整：constitution 和 preset 承载共享约束部分：可以放进项目配置，主流程没有单独质量门部分：项目上下文承载共享约束完整：非功能需求单独维护并进入后续阶段部分：共享约束由 steering 承载，不属于 spec 本身

spec-kit 的优势是覆盖面：八类标准都有承接点，其中 what 与 how 分离、结构化验收场景、规格质量命令和共享约束可以直接使用。主要缺口也很具体：没有双向追溯矩阵，任务不保证逐项带验收条件，测试基线和变更检测要由项目补上。

执行机制要另看。相同的模板和检查，如果只靠 agent 记得运行，仍然属于约定。

候选常用路径怎样推进程序能检查或阻断什么仍可绕过的部分
spec-kit人逐个调用规格、计划、任务和实现命令校验脚本能检查产物；specify workflow run 模式可以按工作流执行阶段门手动命令路径没有统一的阶段状态门；检查未接入 CI 时可以跳过
OpenSpecagent 按变更流程维护增量规格规格校验失败可以返回错误码并接入 CI校验器不负责阻止 agent 提前实现
BMADagent 按角色和工作流产出、评审故事流程状态可以记录进度阶段推进主要靠提示词和人工确认
AI-DLC引擎按阶段状态推进未批准计划时拒绝写项目代码；保护审计记录和已评审的流程产物应用代码和测试源码不在这些保护范围内
Kiro 原生 specagent 依次生成需求、设计和任务阶段检查点会要求人确认确认动作本身不是运行时写入阻断

因此，不能把 spec-kit 的所有用法都归为提示词门。workflow 模式可以由程序执行阶段门；本手册采用的手动命令组合则没有统一的阶段状态门。AI-DLC 的区别在于，阶段状态、审批和产物保护本来就是核心流程的一部分，不需要项目再把这些机制拼起来。

五个候选都没有在执行时锁住测试源码。AI-DLC 的评审冻结只管流程产物；计划审批记录的测试说明和测试合同也不等于测试文件本身不可修改。

5.2 AI-DLC 的强项与代价

AI-DLC 把流程治理做得最完整：

这些机制管的是阶段有没有被跳过、批准后流程产物有没有变化。它们不保护应用代码和测试源码。

代价也来自这套结构。会话要携带更多阶段产物，写代码前需要更多人工确认。官方 issue 里有用户反馈：V2 达到相同结果时消耗的 token 多于 V1；前期阶段持续占用主会话，需要反复压缩；自动暂停依赖的上下文占用信号在 Kiro 上拿不到。这些是使用者报告，说明了需要关注的成本，不代表每个项目都会遇到相同程度的问题。

如果项目需要引擎保护审批状态、流程产物和操作记录，并且能承担额外的交互与上下文成本，可以优先考虑 AI-DLC。正式合规仍要按具体控制要求检查权限、留存和防篡改机制；有审计日志不等于已经满足合规要求。

5.3 选 spec-kit 的理由

spec-kit 首先胜在覆盖面。它没有 AI-DLC 的原生 RTM 和审计引擎，但结构化需求、what 与 how 分离、规格质量检查、任务分解和共享约束都有对应产物或命令。用 git、PR 和 CI 承担审批与留痕的项目，不必先引入一套更重的流程引擎。

它的命令也可以拆开组合。较小的功能可以只走规格、计划、任务、实现和收敛检查；风险更高或边界不清的功能，再增加澄清、检查表和一致性分析。任务分档可以直接复用这种组合方式，不需要为每种任务另造一套流程。

缺口可以局部补。spec-kit 提供 bug、assess、git 等扩展，preset 可以承载组织级标准；社区目录还有追溯、EARS 格式检查和评审门扩展。社区扩展不由官方审查，采用前仍要读源码并锁定版本。

这也划出了它的适用边界。项目只需要轻量规格和结构校验时，OpenSpec 或 Kiro 原生 spec 的负担更小；项目把引擎级审批和详细审计放在首位时，AI-DLC 更合适。spec-kit 适合处在两者之间、愿意用现有 git 和 CI 补强门禁的项目。

5.4 代价和补法

代价补法补到哪一层
本手册采用手动命令组合，阶段门可以跳过（workflow 模式能执行阶段门，但产物和命令更多）在 CI 中分别检查必需产物、规格校验结果、需求到任务的映射和测试结果；分支规则拒绝不合格的改动合并门，不是本地执行时阻断
没有测试源码保护先记录测试失败，再实现；测试单独提交；合并前比较测试与已批准基线。需要 agent 在本地会话里不能修改测试时，要另建写入阻断，并覆盖文件工具、shell 重定向等写入通道基线比较属于合并门；额外的写入控制才属于执行时阻断
没有需求到代码和测试的双向追溯一致性分析先检查规格、计划和任务之间的覆盖；再用追溯清单或机器可读清单，把需求 ID 连到代码位置和测试。需要原生 RTM 时考虑 AI-DLC一致性分析只补到任务，完整链路要另建
社区扩展没有官方审查安装前读源码，固定版本；升级时重新检查权限、脚本和生成的命令供应链检查，不能替代功能验收

CI 只能执行结果稳定、能返回明确状态的检查。AI 给出的一致性分析可以进入评审，但不能直接当成确定性硬门；要阻止合并，还要把必需文件、ID 映射、测试结果等条件写成脚本或现成校验器能判断的规则。

这些补法也不能阻止 agent 在本地会话里改文件。CI 和分支规则保证的是问题改动进不了主分支。需要当场拒绝写入时，必须另加 hook、沙箱或编排器，并测试所有写入通道。

5.5 从 AI-DLC 吸取的经验

AI-DLC 有三项做法可以放进 spec-kit 流程。

这三项做法不依赖 AI-DLC 的引擎，可以落实到任务分档、命令组合和评审记录中。

本章小结

选择 spec-kit，依据是八类标准的覆盖面和命令的可组合性，不是它有最强的流程门。手动命令路径仍靠约定推进，追溯、测试基线和合并门要另外补；如果项目需要引擎级审批和审计，应优先评估 AI-DLC。

参考与出处