规范驱动开发，到底行不行？

SpecKit 在GitHub上有77,000颗星。AWS围绕规范驱动开发构建了 整个IDE。Tessl融资1.25亿美元，承诺规范而非代码应该成为真相来源。

宣传很清晰：停止凭感觉编码，写一份合适的规范，让代理执行。工程师们很喜欢。这感觉像严谨。感觉像是大人终于入场了。

然后 有人在真实项目上测试了它。慢了十倍。更多仪式。同样的bug。

整个行业围绕一个理念构建了整个生态系统：如果我们给AI代理足够详细的规范，他们就能产出可工作的软件。这和行业在外包、离岸开发以及所有试图用文档替代理解的模型上的赌注是一样的。写得足够清楚，另一边的某人（或某物）就会完美执行。

如果没人读Confluence页面，就没人会读你的.specify文件夹。而读它的代理会错过文档遗漏的所有内容。

我知道这一点，因为我亲自试过。在个人项目上，规范驱动开发感觉很有希望。单独环境。没有竞争的利益相关者。没有变化的需求。我写了规范，指向代理，输出是合理的。在孤立环境中，这种方法是有效的。

然后我想了想在工作中尝试会怎样。你正在构建的API在sprint中期发布了破坏性变更。安全审计在规范提交后使认证流程无效。客户基于你没被邀请参加的董事会会议重新确定了路线图优先级。事情不仅在迭代之间动态变化，在单个工单内也是如此。

我意识到规范驱动开发只在你不需要它的环境中有效。当你独自一人且需求稳定时，规范只是和自己的对话。一旦加入团队、竞争的优先级和现实世界的波动性，规范在第一次站会之前就过时了。

1、7.5亿美元押注一个已解决的问题

让我们具体看看2025年发生了什么。

GitHub在9月发布了SpecKit。它搭建了一个.specify目录，包含分阶段流程：指定、计划、任务、实现。它支持23个AI代理平台。它包含一个"宪法"文件，定义了代理必须遵循的原则。工程社区视之为礼物。

几周内，SpecKit就有了维基百科页面。Thoughtworks将规范驱动开发列入技术雷达。LinkedIn Learning制作了课程。会议演讲出现了。"规范驱动开发：凭感觉编码的终结"成为DevLand 2026的真实演讲标题。

AWS随后推出了Kiro，一个以规范驱动开发为核心范式的VS Code分支。规范驱动一切：包含验收标准的需求、设计文档和实现任务。超过250,000开发者在预览期间使用了它。

然后是Tessl，由前Snyk CEO创立。他们采取了最极端的立场：代码是生成的产物，规范是维护的来源。代码文件被标记为// GENERATED FROM SPEC - DO NOT EDIT。他们以7.5亿美元估值融资1.25亿美元。他们有21名员工。仍处于测试阶段。

开源生态系统爆炸了。BMAD-METHOD模拟了19个命名代理角色：BA Mary、PM Preston、架构师Winston、开发者Devon。OpenSpec采用极简Markdown方法。GSD声称三个开发者能产出八个人的产出。到2026年3月，该领域已有超过30个框架被映射。

叙事是统一的：凭感觉编码是疾病，规范是解药。

只是解药不管用。

2、当你实际测试时会发生什么

Scott Logic的工程师在真实代码库上运行了SpecKit。不是待办事项应用。不是周末项目。一个有真实约束的生产系统。仅规范阶段就生成了2,500行Markdown，包括一份406行的"研究文档"，告诉了他们关于自己技术栈已经知道的事情。实现仍然有bug。整个过程大约花了迭代提示的10倍时间。他们的结论是："我不认为这是一个可行的过程，至少在其最纯粹的形式下不是。"

Fowler/Bockeler分析在Kiro上发现了类似结果。对于一个小bug修复，Kiro生成了四个用户故事和十六个验收标准。他们形容这像是"用大锤砸核桃"。更糟的是，代理完全忽略了部分规范，尽管有明确指令不要重复代码，还是生成了重复代码。

Augment Engineer记录了一个团队，仅仅为了在页面上显示日期就产出了1,300行Markdown。他们的结论是："我们重新发明了大设计前置。我们只是用Markdown替换了Word文档，用LLM替换了项目经理。"

Marmelab的工程团队独立得出了相同结论。他们的博文标题说明了一切：《瀑布流反击》。SDD试图将开发者从软件开发中移除。这是瀑布流犯过的同样错误，失败原因也一样。最重要的信息在构建过程中浮现，而不是之前。

甚至行为驱动开发的先驱Gojko Adzic 也发表了看法。他称SDD为"瀑布流的复仇或BDD被带到了新高度"。

而SpecKit本身呢？开发者开始询问项目是否仍在积极维护。功能正悄悄被GitHub Copilot的原生计划模式吸收。启动这场运动的工具可能正在变成它本应补充的产品的一个功能。

3、为什么规范作为代理输入会失败

SDD社区对这些失败的回应是可预见的：规范不够好。写更好的规范。更详细。添加更多验收标准。给代理更多上下文。

这没有抓住重点。规范对于共享上下文、能追问、能读懂言外之意的人类之间的沟通是好的。问题在于用规范作为人类和AI代理之间的接口。这是模型崩溃的地方。

AI代理精确执行规范所说的内容。它不能问"设计师同意这个流程了吗？"它不能标记"这与DevOps关于部署管道说的有冲突"。它不能感知在规范提交40分钟后Slack讨论串中需求已经改变。它按字面理解文档，产出符合文字而非意图的代码。

你不是在做规范。你是在做一个需要经过设计师、DevOps工程师、产品经理和利益相关者讨论的需求。这些人对"完成"的样子持有不同的心理模型。设计师从用户流程思考。DevOps从部署约束思考。产品从业务结果思考。你的规范将所有这些视角扁平化为一个声音：你的声音。然后你把这个扁平化的文档交给代理，期望它产出整个团队能交付的东西。

即使你写了你能想象到的最全面的规范并提交到仓库，你也不会期望你的设计师、DevOps工程师和产品经理打开.specify文件夹审查你要喂给代理的内容。他们有自己的工具、自己的工作流、自己的上下文。规范变成了你和LLM之间的合同，没有其他人签字。

然后是规范腐化。在传统开发中，过时的规范令人恼火。在规范驱动的代理开发中，过时的规范是危险的。代理会自信地执行过时的需求。它不会标记偏差。它不会问事情是否已经改变。它会生成符合一个不再符合现实的文档的代码。而且它做得很快。

这正是在敏捷时代杀死全面文档的相同失败。我们学到了这个教训。我们写了下来。显然，也没人读那个文档。

4、现实世界中什么有效

问题不是AI代理是否需要结构。它们需要。凭感觉编码是混乱的。问题是结构从哪里来。

规范驱动开发说：先写下来，然后交给代理。但真实项目是动态的。需求在工单内变化。范围在迭代内变化。周二的一通客户电话改变了你在周一规划的功能。周四出现的部署约束使你在周三喂给代理的架构无效。SDD假设稳定性。真实团队在持续运动中运作。

处理这种现实的工作流从对话而非文档中给代理结构。

开同步会。设计、DevOps、产品、任何对需求有上下文的人。告诉他们你在录会议。在通话中尽可能收集信息。设计师说"那个流程对屏幕阅读器会崩溃"。DevOps负责人说"我们不能在金丝雀设置后面部署那个"。产品基于销售团队昨天报告的内容改变了范围。所有这些都很重要。这些都不会在规范中，因为写规范的人不知道要包含它。

会后，用LLM把会议记录整理成可读格式。做出的决定。识别的约束。团队达成一致的验收标准。标记的开放问题。和代码库一起提交。不是作为规范。作为团队实际达成一致的结构化记录。

然后分配工作。无论团队使用什么看板。每个工单都填写清晰的规范、验收标准和完成定义，直接从结构化会议记录中提取。

没人打开40页的规范文档。每个人都读分配给自己的工单。

这才是"规范"实际所在：在工程师已经阅读的工作自然单元中。你没有移除文档。你把它移到人们实际会看的地方。

对于每个工单，自己写提示。在工单描述旁边描述需要做什么。使用工具：Superpowers用于实现规划，Serena用于代码库感知编辑，以及堆栈需要的任何MCP服务器。提示就是规范，限定在一个任务，由参与决策的人编写。

并明确提示模型在做出决策或完成部分实现时进行文档记录。每个选择的权衡。每个选择的方法优于替代方案。不是作为规范。作为追踪。

然后你开始注意到：事情按照实际讨论的内容运作。而不是按照某人想象的需求运作。当事情在迭代中变化时，就像它们总是会的那样，追踪捕获了转折点。规范只会是错的。

5、追踪改变一切

当事件发生时，你不仅有代码需要调试。你有完整的追踪记录，说明发生了什么以及为什么问题可能存在。

团队决定方法的会议。指定验收标准的工单。实现功能的提示。解释为什么选择这种方法而非另一种的决策日志。每一步都可追溯到人类对话，而不是在第一行代码写出来之前就已过时的生成文档。

想想你今天如何调试。出了问题。你打开规范。你把它和实现比较。你试图找出它们在哪里分道扬镳。但规范是两周前写的，在范围改变之前，在三场不同的对话重塑需求之前。你在比较一个幻想文档和现实，想知道是哪一个在撒谎。

有了决策追踪，你跟随线索。结构化会议记录告诉你团队同意了什么。工单告诉你验收标准。决策日志告诉你实现过程中做了什么权衡以及为什么。你可以将bug追溯到确切的假设，并看到做出那个假设的对话。

规范只会默默地错。追踪告诉你代码如何演进以及为什么的故事。

这就是在拥抱AI的同时让自己保持在流程中的意义。当你写规范并交给代理时，你把自己从过程中移除了。当代码回来时，你在审计别人的工作。你是审查者，不是构建者。

当你参加会议、写提示、捕获决策时，你嵌入在工作中。你在上下文中与AI协作，带着这段代码为什么存在以及它应该做什么的完整历史。你在流程中，不是从外面看。

6、Confluence的回调

SpecKit有77K星。Kiro获得250K开发者。Tessl获得7.5亿美元。一年内映射了30个框架。会议演讲。维基百科页面。全套仪式。

而它们在解决Confluence在2005年就解决的问题。给工程师一个结构良好的地方写没人读的东西。

SDD工具永远无法解决的是：一个人写下来的东西和跨职能团队实际需要交付之间的差距。再多的结构化Markdown也无法弥合这个差距。规范永远是一个人的理解。工作需要每个人的。

讽刺的是，AI在这个过程中确实有用。不是作为你规范的读者。作为你对话的结构化者、决策的记录者、推理的追踪者。AI在你工作流中的最佳角色不是替代人类对齐步骤。而是使那个步骤的输出可检索、结构化和永久化。

规范驱动开发运动问了正确的问题：我们如何给AI代理产出有用代码所需的结构？他们只是回答错了。结构不是来自工作开始前一个人写的文档。它来自文档本应替代的对话。

你的代理不需要规范。它需要你只有在场时才能获得的上下文。

规范是你和LLM之间的合同，没有其他人签字。

原文链接: Spec-Driven Development Is Waterfall in Markdown

汇智网翻译整理，转载请标明出处