> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 规范驱动开发，到底行不行？ - URL: https://www.hubwiz.com/blog/spec-driven-development-does-it-really-work/ - Published: 2026-03-20T10:31:55.000Z - Updated: 2026-03-20T10:31:55.000Z - Description: SpecKit在GitHub上有77K星。Scott Logic测试后发现它慢了10倍。行业从Confluence什么都没学到。 - Author: admin - Tags: INDUSTRY, #Import 2026-10-14 14:41 [*SpecKit*](https://github.com/github/spec-kit?ref=hubwiz.com) 在GitHub上有77,000颗星。AWS围绕规范驱动开发构建了 [整个IDE](https://kiro.dev/?ref=hubwiz.com)*。*[Tessl融资1.25亿美元](https://fortune.com/2024/11/14/tessl-funding-ai-software-development-platform/?ref=hubwiz.com)，承诺规范而非代码应该成为真相来源。 宣传很清晰：停止凭感觉编码，写一份合适的规范，让代理执行。工程师们很喜欢。这感觉像严谨。感觉像是大人终于入场了。 然后 [*有人在真实项目上测试了它*](https://blog.scottlogic.com/2025/11/26/putting-spec-kit-through-its-paces-radical-idea-or-reinvented-waterfall.html?ref=hubwiz.com)。慢了十倍。更多仪式。同样的bug。 整个行业围绕一个理念构建了整个生态系统：如果我们给AI代理足够详细的规范，他们就能产出可工作的软件。这和行业在外包、离岸开发以及所有试图用文档替代理解的模型上的赌注是一样的。写得足够清楚，另一边的某人（或某物）就会完美执行。 如果没人读Confluence页面，就没人会读你的`.specify`文件夹。而读它的代理会错过文档遗漏的所有内容。 我知道这一点，因为我亲自试过。在个人项目上，规范驱动开发感觉很有希望。单独环境。没有竞争的利益相关者。没有变化的需求。我写了规范，指向代理，输出是合理的。在孤立环境中，这种方法是有效的。 然后我想了想在工作中尝试会怎样。你正在构建的API在sprint中期发布了破坏性变更。安全审计在规范提交后使认证流程无效。客户基于你没被邀请参加的董事会会议重新确定了路线图优先级。事情不仅在迭代之间动态变化，在单个工单内也是如此。 我意识到规范驱动开发只在你不需要它的环境中有效。当你独自一人且需求稳定时，规范只是和自己的对话。一旦加入团队、竞争的优先级和现实世界的波动性，规范在第一次站会之前就过时了。 ## 1、7.5亿美元押注一个已解决的问题 让我们具体看看2025年发生了什么。 [*GitHub在9月发布了SpecKit*](https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/?ref=hubwiz.com)。它搭建了一个`.specify`目录，包含分阶段流程：指定、计划、任务、实现。它支持23个AI代理平台。它包含一个"宪法"文件，定义了代理必须遵循的原则。工程社区视之为礼物。 几周内，SpecKit就有了[维基百科页面](https://en.wikipedia.org/wiki/Spec-driven%5Fdevelopment?ref=hubwiz.com)*。*[Thoughtworks将规范驱动开发列入技术雷达](https://www.thoughtworks.com/en-us/insights/blog/agile-engineering-practices/spec-driven-development-unlocking-2025-new-engineering-practices?ref=hubwiz.com)。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个框架被映射*](https://medium.com/@visrow/spec-driven-development-is-eating-software-engineering-a-map-of-30-agentic-coding-frameworks-6ac0b5e2b484?ref=hubwiz.com)。 叙事是统一的：凭感觉编码是疾病，规范是解药。 只是解药不管用。 ## 2、当你实际测试时会发生什么 [Scott Logic的工程师](https://blog.scottlogic.com/2025/11/26/putting-spec-kit-through-its-paces-radical-idea-or-reinvented-waterfall.html?ref=hubwiz.com)在真实代码库上运行了SpecKit。不是待办事项应用。不是周末项目。一个有真实约束的生产系统。仅规范阶段就生成了2,500行Markdown，包括一份406行的"研究文档"，告诉了他们关于自己技术栈已经知道的事情。实现仍然有bug。整个过程大约花了迭代提示的10倍时间。他们的结论是："我不认为这是一个可行的过程，至少在其最纯粹的形式下不是。" [Fowler/Bockeler分析](https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html?ref=hubwiz.com)在Kiro上发现了类似结果。对于一个小bug修复，Kiro生成了四个用户故事和十六个验收标准。他们形容这像是"用大锤砸核桃"。更糟的是，代理完全忽略了部分规范，尽管有明确指令不要重复代码，还是生成了重复代码。 [Augment Engineer](https://augmentengineer.com/your-spec-driven-workflow-is-just-waterfall-with-extra-steps/?ref=hubwiz.com)记录了一个团队，仅仅为了在页面上显示日期就产出了1,300行Markdown。他们的结论是："我们重新发明了大设计前置。我们只是用Markdown替换了Word文档，用LLM替换了项目经理。" Marmelab的工程团队独立得出了相同结论。他们的博文标题说明了一切：[*《瀑布流反击》*](https://marmelab.com/blog/2025/11/12/spec-driven-development-waterfall-strikes-back.html?ref=hubwiz.com)。SDD试图将开发者从软件开发中移除。这是瀑布流犯过的同样错误，失败原因也一样。最重要的信息在构建过程中浮现，而不是之前。 甚至行为驱动开发的先驱Gojko Adzic [也发表了看法](https://www.linkedin.com/pulse/spec-driven-development-revenge-waterfall-bdd-taken-gojko-adzic-imquf?ref=hubwiz.com)。他称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](https://github.com/obra/superpowers?ref=hubwiz.com)用于实现规划，[Serena](https://github.com/oraios/serena?ref=hubwiz.com)用于代码库感知编辑，以及堆栈需要的任何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](https://medium.com/@iamalvisng/spec-driven-development-is-waterfall-in-markdown-e2921554a600?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处