Spec Driven Development：AI 编码 Agent 的边界与陷阱

Spec Driven Development 解决了什么（又破坏了什么）

AI coding agent 很强大，但它们有一种漂移的倾向。放任不管的话，它们会重新诠释模糊的 prompt，悄悄扩大范围，交付一段技术上能跑但实际上没人要过的代码。Spec Driven Development（规范驱动开发）试图通过让规范（spec）而不是 prompt 成为 agent 工作的信息来源来解决这个问题。它确实有效。但问题在于：很多采用这种方式的团队不过是用聊天机器人绑定的瀑布流开发流程重新搭了一遍。本文会分析七阶段工作流中哪些部分真正有价值，哪些部分纯属走形式。

Spec Driven Development 真正改变的是什么

Spec Driven Development 将信息来源从 prompt 切换到了规范文件。Agent 必须以规范为权威文档，而不是以你对 Slack 消息的解读为权威文档。在实践中，这意味着一个七阶段流水线：Constitution（章程）→ Specify（详述）→ Clarify（澄清）→ Plan（规划）→ Tasks（任务）→ Implement（实现）→ Analyze（分析）。每个阶段之间都有一个人工审核关卡（review gate），而这个关卡就是整个机制的核心。正是它阻止了一个 agent 自信地带着错误解读跑偏三个小时才被人发现。

以下是每个阶段的大致职责：

Constitution：项目的通用规则（约定、约束、一以贯之的事项）。

Specify：实际的需求，细节充分到两个人能从中构建出相同的东西。

Clarify：将任何模糊的内容转化为可测试、无歧义的验收标准。这正是 EARS notation 发挥作用的地方。你要写出来的东西要让 agent 完全无法误读。我构建 agent system prompt builder 的原因之一，就是受够了反复看到 agent 把用英文写的需求读错。

Plan：将 Specify 和 Clarify 的输出拆解成实际的工作顺序。

Tasks：agent（或你自己）要执行的单个工作单元。

Implement：agent 写代码。

Analyze：有人在代码发布之前而不是之后对照规范检查输出。这是大多数团队跳过或敷衍了事的阶段，而这恰恰是好的测试策略真正发挥作用的地方，因为如果没有人对照真实行为来验证而只是在看 diff 凭肉眼看，那么 Analyze 这个阶段就毫无价值。

一个模糊的需求（比如"用户不能太频繁地登录"）经过 Clarify 阶段用 EARS 风格的验收标准转化之后，会变成这样：

Given a user has attempted to log in 5 times within 1 minute
When the user attempts to log in again
Then the system shall block the login attempt and return a rate limit error

这就是全部的诀窍。Agent 无法像反驳"加点限流"那样反驳这句话。

图示：一幅横向流程图，展示七阶段 Spec-Driven Development 流水线：constitution → specify → clarify → plan → tasks → implement → analyze，每个阶段之间有一个勾选标记的审核关卡。

工具格局：Spec Kit vs Kiro vs 什么工具都不用

GitHub Spec Kit 是开源的、MIT 许可的，以 CLI 为优先的工具包，将规范视为 agent 的实际可执行信息来源。如果你的团队希望自己掌控工作流，并且已经习惯于在现有环境里拼接 CLI 工具，它是一个很合适的选择。

AWS Kiro 采取了相反的做法：它是一个围绕 spec driven development 从零构建的完整 agentic IDE，而不是你附加上去的 CLI。Kiro 于 2026 年 5 月 7 日达到国际正式可用（GA），发售时带有团队计划、CLI 和基于属性的规范测试。在 GA 日期之前，它已经在预览阶段吸引了超过 25 万名开发者，并且在大约 90 天内获得了超过 10 万个候补名单注册，这说明在工具跟上之前市场对这种工作流的需求就已经真实存在了。如果你希望纪律由 IDE 本身强制执行，而不是靠你自己维护的组件拼凑出来，Kiro 是更好的选择。

然后是第三种选择：完全不使用专用工具，只用一份写得好的 AGENTS.md 或等效的上下文文件，加上人工审核纪律。这对小型项目确实有效。只是当超过两三个人在接触同一个 agent 工作流时，它无法给你 Kiro 或 Spec Kit 免费提供的强制执行力。

这套方法真正失效的地方

这是大多数文章会跳过的一部分：Thoughtworks 将 spec driven development 放在了 Technology Radar 的 Assess 环，而不是 Adopt 环。这是一个"谨慎推进"的信号，而不是背书。这条评级的真正批评是具体的：这种实践会在项目中把文档工作量翻倍——当每个阶段都被当作强制性的形式主义而非在任务真正需要时才动用的工具时，情况尤其如此。

看一个信号。如果你的团队在为一个两小时的任务写详尽无遗的规范，为一行 CSS 修复跑每个阶段关卡，并把人工审核步骤当作橡皮图章而非真正的检查，那么你们做的就不再是 spec driven development 了。你们做的是加了 AI coding agent 的瀑布流开发，而且让流程变慢了却没让它变得更安全。

各个阶段应该能缩小到适合小任务、放大到适合真正有风险或模糊的任务。对所有事情施加相同的仪式感的团队，会在一个月内讨厌这个工作流，而且说实话，他们有理由讨厌它。那是流程问题，不是 spec driven development 本身的问题。

如何运行这套方法而不把它变成文书工作

根据任务的实际风险来缩放各个阶段。一个微小的改动配一行规范直接进入 implement。真正模糊或高风险的改动才走完整的七个阶段，包括所有关卡。不要对两者跑同一份清单。

保持 constitution 文件短小且有观点。它应该包含你日常真正执行的规则，而不是没人会在第一周之后读完的 aspirational 愿望清单。

永远不要跳过人工审核关卡。这个工作流中其他一切都是围绕这一个机制展开的流程，而它才是真正的安全网。这也正是正确接线 agent 工作流比人们预期的更重要的地方：如果关卡只是一个 Slack 通知，没人会在第二天早上才去读，那你就建立了一个工作流却跳过了它本应提供的安全机制。

在 Clarify 和 Plan 阶段特意用 EARS 风格写验收标准。它在这两个阶段价值最大，因为它迫使歧义在 agent 开始生成代码之前就暴露出来，而不是在你已经审查一份自己都没完全理解的 PR 之后才出现。

总结

Spec Driven Development 是对一个真实问题的真实修复：agent 在模糊 prompt 上漂移，交付没人要过的范围。它不是一阵风，也不会消失。但它也不是判断流程何时值得付出成本的替代品。从这套方法中获益最多的团队，把七个阶段当作一个旋钮，根据风险调大或调小，而不是当作对每个 ticket 无条件执行的 checklist。

如果你在为团队搭建这套方法，想要在 constitution 文件或关卡设计定型变成形式主义之前有人帮你再看一眼，这正是我承接的工作类型。

如果你团队的设置跟上述不同，留言告诉我，很好奇大家在生产环境中实际跑的是哪些变体。