规范驱动开发：整个赛道收敛到的那套做法
每一个严肃的 AI 编码工具都在彼此相差约一年的时间里发布了同一项能力——而这种事几乎从不偶然发生。
2025 年，有趣的问题是模型变得多好。2026 年，有趣的问题是你交给它们什么。
GitHub 发布了 Spec Kit。AWS 发布了 Kiro，一个围绕这个想法建起的 IDE。BMAD-METHOD、OpenSpec 和 Tessl 各自做了尝试。Cursor 通过规则文件到达了同一个地方。Martin Fowler 发表了对这些实现的比较。当六个独立团队在十二个月内收敛到同一个答案时，他们不是在互相抄。他们是在撞同一面墙。
这面墙现在有了名字。解法也有了。
规范驱动开发到底是什么
在生成任何代码之前，先写下需求、约束和成功标准。把那份文档当作事实来源。让 agent 对着它构建。
就这样。这不是新想法——这就是需求工程，业界花了三十年把它做得很糟，然后基本因为「太慢」而放弃了。变的不是概念。变的是经济学。
规范过去写起来贵、维护更新也贵，这意味着大多数团队只写粗线条，其余全在代码评审里发现。当开发者反正要花三周来构建那个功能时，这是一笔理性的交换。当生成变快之后，它就不再理性了，因为现在规范才是慢的那部分——而慢的那部分正是所有判断所居住的地方。
它是为对抗哪种失败模式而被发明的
以提示词开局的工具完全跳过规范。你描述一个结果，工具产出某个像它的东西，而描述没有覆盖到的每一个决定，都由生成器无声地做出。
哪些决定？那些最终被证明重要的。邮箱地址是否唯一，以及在什么范围内唯一。一个被取消的账户仍然能看到什么。两个人同时编辑同一条记录时会发生什么。那个列表在有一万行之前是否需要分页。
没人问过这些问题，所以没人回答过——但应用对每一个都有答案，是从一个从未包含你的业务的上下文里推断出来的。
同样的动态出现在每一个跳过定义步骤的工具里。它是 70% 问题背后的机制：进展停滞不是因为剩下的活儿难，而是因为它被一个几百代生成之前隐含做出的架构决策挡住了，而那个决策不把系统拆开就再也改不动了。
不这样做会发生什么，数据在此
DORA 的 2025 年《State of AI-assisted Software Development》是目前最清晰的一份读物。90% 的技术从业者现在在工作中使用 AI，超过 80% 相信它提高了自己的生产力。而更高的 AI 采用率同时与软件交付吞吐量的上升以及软件交付不稳定性的上升相关联。
交付更快。维持运转更差。两者同时。
GitClear 对 6.23 亿次代码变更的 2026 年分析显示了损害的形状。相对 2023 年基线：重复代码块上升 81%，提交内复制粘贴从 2022 年的 9.4% 攀升到 2026 年上半年的 15.7%，掩盖错误的结构上升 47%。同时跨文件函数调用——代码复用的最佳可得代理指标——下降 35%，重构活动从 2022 年占变更的 21% 崩塌到 2026 年的 3.8%。
开发者现在复制粘贴的可能性大约是重构的五倍。2022 年这个比例是反过来的。
这些都不是模型质量问题。这是当生成廉价、而结构不是任何人明确职责时会发生的事。
三种投入程度
不是每个人说这件事时都指同一个意思，而这些差别在实践中很重要。Martin Fowler 的框架是我见过最干净的。
规范优先（spec-first）。 你写规范、从它生成，然后手工维护代码。规范驱动初始构建，然后逐渐变成历史文档。最容易采用，保证最弱——半年后，那份文档描述的是一个已经不存在的系统。
规范锚定（spec-anchored）。 规范与代码一起演进。改规范，重新生成受影响的部分，让两者都保持更新。需要更多纪律，回报是那份文档一直可信。
规范即源（spec-as-source）。 规范是你唯一编辑的产物。代码是输出，就像编译出的二进制文件是输出——你不会去手打补丁。保证最强，也是团队工作方式上最大的一次跃迁。
大多数自称在做规范驱动的团队，做的是规范优先。相对于闭着眼睛提示词，这是真实的改进，而它也是那个会安静腐化的版本。
什么该进规范
有用的检验标准：如果生成器不得不去猜，它就该进这份文档。
- 数据模型。 实体、关系、基数、什么让一条记录唯一、删除时会发生什么。这是价值最高的一节，也是最常被跳过的一节。
- 用户类型与权限。 有哪些人、每一类能看到和做什么、在边界上会发生什么。
- 不变量。 绝不能被违反的规则，平实地陈述。不是「优雅地处理错误」——那是一个愿望，不是一条约束。
- 成功标准。 你将如何知道这东西能用，其表述要具体到「它到底能不能用」的分歧是可裁决的。
什么不该进：生成器比你更擅长选择的实现细节。一份点名变量名的规范不是规范，它是配了更差工具的代码。
所有人都搞错的那部分
规范只有在除了散文之外的某处被强制执行时才有用。
如果一条约束只活在文档里，它就是一条建议。生成器读过它一次，而在它触碰的第十四个文件里，它可能遵守了也可能没遵守。约束需要落到系统会检查的地方：not-null 和 unique 放在数据库里而不是表单处理器里；类型放在边界上而不是注释里；授权作为系统会求值的策略，而不是某人记得写下的一个条件。
这就是「规范驱动开发作为一套做法」和「规范驱动开发作为一种文档体裁」之间的差别。文档是你如何做决定。强制执行是你如何守住那个决定。
如何判断你是否真的在做它
四个问题，而它们故意让人不舒服。
- 出问题时，你改代码还是改规范？ 如果答案总是代码，那你顶多是规范优先，而那份文档已经过期了。
- 一个新人能读规范并预测系统行为吗？ 如果他必须读代码才能知道，那份规范是摘要，不是源。
- 规范里有什么是系统无法违反的吗？ 如果每条规则都是散文，那一条都没有被保证。
- 你评审的是规范还是 diff？ 评审几千行生成的代码是演戏。趁争论还便宜的时候，去争论那份文档。
这让工具处在什么位置
大多数当前实现是专门针对代码生成的规范驱动。它们产出一份规范并对之生成一个实现，而它们操作的产物是一个代码库。
更难的版本把同样的逻辑扩展到整个应用——数据模型、API 接触面、认证边界、界面——这样规范覆盖的不只是代码做什么，而是系统是什么。这正是 Archie 的蓝图阶段，也是我为什么把它描述为「应用于整个技术栈而非某个仓库的规范驱动开发」。范围不同，原则相同：生成之前先定义。
理性的人对这件事该推进到多远存在分歧。没有一个严肃的人在主张往回走。
它的代价
把判断提前，在项目的第一周更慢，在之后的每一周更快。这份代价是真实的，而且恰恰是在动能感觉最有价值、竞争对手正在交付某个可见东西的那一刻支付的。会有一些 sprint，让跳过这一切的团队看起来在赢。
纪律也会腐化。写下约束不如看着界面出现来得享受，评审文档也不如评审代码那么令人满足。这些习惯在期限压力下被侵蚀，而那正是让它们重要的同一份压力。
而它确实不适用于一切。如果你这个周末在验证一个想法并打算把结果扔掉，那就扔掉。对生命周期只有两天的软件，这些都不值得做。
这件事为什么留下来了
此前每一次让团队先写规范的尝试都失败了，而它失败的理由很正当：规范是压在真正工作之上的额外开销。你写完文档，然后还是得把东西造出来。
现在这笔交易变了。现在文档就是大部分工作，而构建才是便宜的那部分。六个独立团队在彼此相差一年内注意到这件事，是因为这是模型变好之后显而易见的后果。
这套做法不是赢下了一场辩论。是经济学在它脚下移动了。
延伸阅读
最初的诊断：vibe coding 违背了它的承诺。这个赛道接下来去了哪里：vibe coding 之后是什么。同一个论点应用于整个系统：从第一原理出发的 AI-first 软件设计。以及同一想法更早的表述：别再把软件写两遍。
常见问题
什么是规范驱动开发？ 在生成任何代码之前先写下需求、约束和成功标准，并把那份规范当作 AI agent 对之构建的事实来源。它在 2025 和 2026 年出现，是对跳过定义步骤的「提示词优先」工作流的直接回应。
它与传统需求文档有什么不同？ 概念相同；经济学不同。传统规范贵到让团队只写粗线条，其余在实现过程中发现。当起草一份只需几小时而不是几个月、并且可以便宜修订时，它就值得写完，也值得保持更新。
哪些工具支持规范驱动开发？ GitHub Spec Kit、AWS Kiro、BMAD-METHOD、OpenSpec 和 Tessl 是被点名的实现，而 Cursor 通过规则文件支持一个更轻量的版本。它们的主要差别在于规范与代码绑定得有多紧——它是驱动一次生成、与之并行演进，还是你唯一编辑的产物。
规范驱动开发的三种程度是什么？ 规范优先，规范驱动初始构建而你手工维护代码。规范锚定，规范与代码一起演进。规范即源，规范是你唯一编辑的东西而代码被视为输出。大多数在实践它的团队做的是规范优先。
规范驱动开发会拖慢团队吗？ 它重新安置了工作，而不是增加工作。规范里的决定要么在前期刻意做出，要么之后由生成器在猜测中隐含做出，而第二条路正是返工的来源。它在第一周更慢，之后更快。
规范里该放什么？ 任何生成器否则不得不去猜的东西：带关系和唯一性规则的数据模型、用户类型与权限、绝不能被违反的不变量，以及具体到足以裁决分歧的成功标准。把生成器比你选得更好的实现细节留在外面。
规范驱动开发与 AI-first 设计是一回事吗？ 规范驱动开发是「生成之前先定义」这套做法。AI-first 设计是更广的一组架构后果，还覆盖约束在哪里被强制执行、你以什么顺序做决定，以及在人类消费方之外同时为 agent 消费方设计。
