别再把软件写两遍：规范驱动开发与重写的终结
为什么软件一直被写两遍——一遍写在规范里，一遍写成代码——以及为什么第二遍终于要消失了。
在软件开发中，如果做对了，我们必须把软件写两遍：先写成详细规范，说清楚软件究竟该做什么，然后再写成让这些规范活起来的代码。但有个残酷的事实：第一遍很少做对。
流程之所以经常崩坏，是因为编写详尽规范很耗时，而团队很少能在前期就把所有必要细节都捕捉下来。这导致缺口、假设和昂贵的返工。结果是软件项目经常超预算、错过期限，让所有人都很沮丧。
把软件写两遍的隐性成本
要理解为什么把软件写两遍是必要的却很少做好，我们把两个阶段拆开看：
1. 第一遍：自然语言规范
软件被写的第一遍，我们其实根本没在写代码。那是在创建需求、用户故事和设计文档——用自然语言写。团队在这里描述软件该如何运作、用户能做什么、体验该是什么样。
但问题在这里：没有任何团队有把所有细节都写下来的余裕。产品经理常常必须赶激进的时间表——有些项目甚至根本没有专职产品经理。他们画出粗线条，但关键功能和交互被漏掉了。正如史蒂夫·乔布斯那句名言，「伟大的产品由 5000 个小决定构成」，可在大多数项目里，我们并没有在前期做出那些决定。它们被留给开发者之后去解读，而这就引出了第二步。
2. 第二遍：把规范翻译成代码
规范一交接出去，工程师就要负责把那些描述变成能运作的代码。但当第一「遍」不完整时，开发者被迫用想象力去填空。假设被做出，而尽管工程师可能很懂技术，他们可能并不掌握产品愿景的全貌。
这就是问题浮出水面的地方：
- 漏掉的细节导致摩擦：当产品团队没有说明某个重要功能或使用场景时，开发者只能猜或者即兴发挥。这经常导致做出来的功能不符合预期。
- 假设导致返工：当开发者去填空时，他们可能以与产品愿景不一致的方式构建功能，导致项目后期出现大规模返工。
- 互相指责变得不可避免：当期限滑坡、预算超支时，团队开始推卸责任。产品团队指责工程「没搞懂」，工程则指着产品的规范不清。
结果是一连串问题，导致错过时间表、超支预算和不令人满意的产出。Standish Group 的 CHAOS 研究多年来一直追踪到：大多数软件项目超预算并错过交付日期。麦肯锡与牛津大学的一项研究发现，大型 IT 项目平均超预算 45%、超时 7%，交付的价值却比预期少 56%——而且 17% 的大型 IT 项目糟糕到威胁公司本身的存续。
显然，这个流程里有什么坏掉了。
这套做法现在有了名字
在大多数人还在争论提示词的时候，业界为它定下了一个术语：规范驱动开发。先写需求、约束和成功标准。把那份规范当作事实来源。让 agent 对着它构建。
GitHub 发布了 Spec Kit。AWS 发布了 Kiro。BMAD-METHOD、OpenSpec 和 Tessl 都做了各自的尝试。Martin Fowler 写过。这种收敛不是巧合——当整个赛道在同一时间发现同一个失败模式时，就会发生这种事。
而那个失败模式，就是上面描述的那个。以提示词开局的工具完全跳过了第一遍。它们直奔第二遍，猜测规范从未做出的每一个决定。这对演示没问题，对产品是毁灭性的。
规范驱动开发并没有消除第一遍。它让第一遍成为唯一需要人类判断的那一遍。
新的第一遍：真的能写完的规范
变化在这里。没人写完整规范的原因，从来不是他们不想——而是这份工作太慢，不值得。花几周做调研，产出一份在第一个 sprint 接触现实时就过期的文档。所以团队画粗线条，把那 5000 个小决定留着之后一次一个解读地去发现。
当起草一份规范需要几小时而不是几个月时，算术就反过来了。你可以负担得起做到详尽。功能需求、视觉设计、数据模型、边界情形——在任何人打开编辑器之前就被捕捉下来，而且便宜到你学到新东西时可以随时修订。
最后这点很重要。一份不能被便宜修订的规范，在现实到来的那一刻就变成谎言。这和按 API-first 构建背后是同一种直觉：在任何人写屏幕之前先把承重决策做对，剩下的自然会跟上。
新的第二遍：代码生成，而不是翻译
一旦规范完整，第二遍就不再是翻译问题。它变成生成问题。标准语言——JavaScript、TypeScript、Python。标准框架——React、Next.js。真实的代码，以工程师已经熟悉的形态，从一份已经做完每一个决定的文档中推导出来。
差别不是开发者干得更快了。差别是他们停止做那件从来不属于工程的事——机械地复述别人已经做好的决定。
下游会改变什么
三件事同时改变：
- 第一遍被写完了：当规范工作花费几小时而不是几个月时，团队可以负担在前期做出那些小决定，而不是在评审里发现它们。
- 没人再去填空：从一份完整规范生成的代码，不需要任何人去猜产品团队是什么意思。猜测一直是缺陷的来源。
- 返工停止累积：意图与实现从一开始就对齐。过去是重写的事，现在变成对规范的一次编辑。
写软件的未来：自然语言
只要有人在交付软件，这份工作就要求把它写两遍：一遍用自然语言，一遍用代码。第二遍从来不是有价值的那部分。它是我们缴的过路费，因为没有别的路。
这就是下一代 AI 应用构建器围绕其组织的那个动作：先清晰，后代码。把应用描述成蓝图，把架构做对，让代码对着它生成。不是绕过定义工作的捷径——而是终于把它做好的理由。
现在有另一条路了。软件本来就该只写一遍。
延伸阅读
这套做法的完整指南：规范驱动开发。以提示词开局的那一代为什么跳过了这一步，见 vibe coding 违背了它的承诺；取而代之的是什么，见 vibe coding 之后是什么。
常见问题
什么是规范驱动开发？ 规范驱动开发是指在生成任何代码之前先写下需求、约束和成功标准，并把那份规范当作 AI agent 对之构建的事实来源。它在 2025 年出现，是对完全跳过定义步骤的「提示词优先」工作流的直接回应。
规范驱动开发与写传统需求文档有什么不同？ 文档是同一个想法；经济学不同。传统规范贵到让团队只写粗线条，把其余留到代码评审时发现。当一份规范只需几小时而不是几个月、并且可以便宜修订时，它就值得写完——也值得保持更新。
哪些工具支持规范驱动开发？ GitHub Spec Kit、AWS Kiro、BMAD-METHOD、OpenSpec 和 Tessl 是被点名的实现，而 Cursor 通过规则文件支持一个更轻量的版本。它们的主要差别在于规范与代码的绑定有多紧——它是驱动一次生成、与代码并行演进，还是你唯一编辑的产物。
规范驱动开发会拖慢团队吗？ 它移动了工作，而不是增加工作。规范里捕捉的那些决定，是无论如何都会有人做的决定——要么在前期刻意做出，要么之后由开发者或模型在猜测中隐含做出。第二条路正是返工的来源。
如果代码是从规范生成的，开发者会怎样？ 机械复述别人决定的那部分消失了。关于架构、取舍、正确性以及「不该造什么」的判断没有消失。那些一直都是需要工程师的部分。
