当代码可以自动生成,规范才是新的源码

很多程序员都有过这样的时刻。

深夜十一点，群里突然有人 @你：

“这个接口是不是改过返回字段？”“为什么线上行为和文档不一样？”

你打开代码仓库翻了半天，发现三件事：

• 代码里确实改过逻辑
• 文档没改
• 调用方按旧文档写的

最后大家得出一个经典结论：

“文档已经不可信了，直接看代码吧。”

在传统的软件开发里，这几乎是一个默认现实： 代码才是唯一真实的东西（Code is the source of truth）

但在 AI Coding Assistant 越来越普及的今天，这件事开始发生微妙的变化。

当开发者可以通过一句 Prompt 就生成一段功能代码时，新的问题出现了：

如果代码是 AI 写的，那么什么才是系统真正的“源头”？

越来越多团队开始把答案放在 Spec（规范） 上，而不是代码本身。 这种开发方式被称为：

Spec-Driven Development（规范驱动开发，SDD）。

简单来说，就是：

先定义系统应该如何行为，再让代码去实现这个行为。

在实践中，使用 SDD 的团队通常会落在三种不同模式上：

使用SDD的方式被分为三类：

1. Spec-first 在“规范优先”开发中，会在编码之前编写规范，以指导初始实现。一旦代码生成后，规范可能被维护，也可能不被维护——其主要价值在于它所提供的初始清晰性。

2. Spec-anchored 在“规范锚定”开发模式中，规范与代码在整个系统生命周期中并行维护。任何行为的更改都需要同时更新规范和代码，以保持二者同步。

3. Spec-as-source 在“规范即源码”开发模式中，规范是唯一由人类直接编辑的工件。代码完全由规范生成，绝不应手动修改。任何行为上的更改，都必须通过修改规范并重新生成代码来实现。

 SDD(Spec-Driven Development)流程

各个阶段都会输出明确的交付物，用来约束和指导下一个阶段，这形成了一个从意图到实现的责任链。

阶段1: Specify 主要解决“这个软件用来做什么”的问题。 良好的Spec应该有以下这几个特征：

1. 聚焦于行为，只描述发生了什么而不描述怎么做
2. 可测试。每条需求都可以被验证
3. 不含糊。不同的读者对它有相同的解释
4. 完整性。足够的完整，包含了必要的场景。

阶段2: Plan 主要解决“我该如何构建它”的问题。 根据上一步的Spec作为输入，Plan过程会产生包含了架构、数据模型、接口和技术选择的详细的技术方案。也就是说Spec描述了意图，Plan声明了实现的约束，这里面既包含功能性约束，也包含了包括性能、安全性和可扩展性在内的非功能性约束。 Plan阶段连接了”What”和”How”。

阶段3: Implement 这个阶段根据Plan将Spec变成可以工作的code。在传统的软件开发过程中，这个阶段会耗费较多的精力。在SDD中，这个阶段被很大程度上的自动化了，但仍然需要人的监督。 Plan会被分解成具体的、可以被review的任务。然后任务会被AI或者开发者实现。代码会被review以确保它符合Spec以及Plan。同时单元测试也会被编写出来。 SDD的一个重要原则是在小规模、可验证的增量下展开。工作被分解成可以独立交付的、可测试的、小片段功能。这确保了较频繁的人工确认和尽早的识别drift（实现与Spec/Plan之间的漂移）。也使得较为容易的在各个agent的上下文窗口中处理被分解过的复杂Spec。

阶段4: Validate 这个阶段回答了至关重要的结论性的问题：“代码是否满足了spec？” 这个阶段结合了自动验证和人工的判断。 这个阶段包含了运行自动化的单元测试、集成测试场景测试，以及对非功能性需求的review和咨询程序员的意见等。 如果经过验证发现代码与spec不匹配，要么修改代码、要么更新spec。但是无论如何，都要确保spec仍然是权威和可信的。

SDD如何增强AI编码Agent

规范（Specifications）充当超级提示（super-prompts），将复杂问题拆解为与各个智能体上下文窗口相匹配的模块化组件。 研究显示，经过人工优化过的规范（specifications）可以显著提升LLM生成代码的质量，同时降低50%的错误率。这种增强效应在可扩展场景中尤为明显：规范（specifications）使智能体能够在互不重叠的任务上并行执行，并通过编排机制处理依赖关系。团队可以在规范层面对工作进行划分，使多个 AI 智能体能够同时实现不同组件而互不干扰。 挑战仍然存在，包括大语言模型（LLM）的非确定性——即使是结构化的规范，也可能导致不同的输出结果。诸如基于性质的测试（Property-Based Testing，PBT）等技术通过自动验证规范中的不变量在不同实现变体下是否得到满足，从而应对这一问题。 一种新兴的方法涉及“自规范（self-spec）”机制，即由大语言模型在生成代码之前先自行编写规范。智能体首先根据高层级提示生成一份规范，然后由人类对其进行审阅和完善，之后再由同一个或另一个智能体依据该规范进行实现。这种方式在规划与执行之间建立了明确的分离，从而在代码编写之前就能发现对需求的误解。事实上包括Antigravity在内的多种AI编程工具现在就是这样做的。

工具和框架

多种工具支持以规范驱动的开发，从传统的测试框架到现代的 AI 辅助工具包均涵盖在内。

支持Spec-Driven Development的工具和框架

1. BDD框架 经典格式是 Gherkin，它使用包含 Given / When / Then 子句的结构化场景：

Feature: Shopping Cart  Scenario: Adding item to empty cart    Given the cart is empty    When I add item "Widget" to the cart    Then the cart should contain 1 item    And the item should be "Widget"

1. API Specification工具 一旦API确定了，前端后端可以同时工作。
2. AI辅助SDD工具 新兴工具将 AI 编码工作流明确围绕规范进行结构化设计，认识到相比于一次性“直接把这个代码写出来”的提示方式，采用包含显式中间产物的多步骤提示能够产生更好的结果。例如：Github Spec Kit, Amazon Kiro和Tessl等。 其中Tessl采用了更加仅仅的方式：“规范即源码”（spec-as-source），即规范是被维护的工件，代码从其重新生成。Tessl 代表了“规范即新源代码”这一新兴理念——开发者从不直接编辑生成的代码，而是修改规范，然后重新生成代码。

这些工具共享一个共同的见解：将规划与实施分离，使智能体能够在限定的边界内专注于执行，从而减少松散提示的AI编码所面临的非确定性问题。

例子

1. 规范锚定开发模式：

• 先定义OpenAPI规范的接口，之后前后端研发各自根据接口规范同步开发。
• 产品经理用自然语言写Gherkin场景，描述预期行为。开发者用这些场景生成可执行的测试。只有当测试通过时，才代表这个feature已经完成。从而规避产品经理、QA和开发人员对于特性“完成”的理解不一致。

1. 规范即源码(Spec-as-source)开发模式：

• 一家汽车零部件供应商需要开发符合 ISO 26262 安全认证要求的发动机控制软件。手工编码极易出错，而认证过程要求将每一行代码与具体需求建立可追溯的对应关系——当代码为人工编写时，这一过程极为耗时。 该团队采用 MathWorks Simulink将控制算法建模为包含状态机的模块图。该模型即为唯一规范：工程师在模型层面进行仿真与验证，在任何代码生成之前即能发现算法错误。一旦模型通过仿真验证，便使用经过认证的代码生成器从模型自动生成代码。 模型到代码的生成过程本身也已获得认证，因此生成的 C 代码在行为上与模型规范完全一致。工程师绝不直接修改生成的代码；若需更改控制逻辑，他们仅需修改模型并重新生成代码。这一机制确保了经过验证的模型与最终部署的代码从构建之初就完美一致。 这种方法体现了“规范即源码”理念的最严格形式：规范（Simulink 模型）是唯一由人类修改的工件，实现（C 代码）则完全自动生成。在嵌入式系统中，SDD（规范驱动开发）结合大语言模型生成与形式化验证，以确保满足安全关键系统的合规性要求，充分证明了在汽车、航空航天等错误代价高昂的领域中，规范如何保障系统的精确性与可靠性。

重新定义开发者的工作

SDD（规范驱动开发）从根本上重塑了“软件开发者”的含义。开发者的工作重心正从手工编写代码，转向规范的设计与管理、AI 生成内容的审查，以及对高层次架构的专注。这一转变有望大幅提升开发效率，但也带来了新的挑战——包括规范的长期维护、工具链的深度掌握，以及在何种情况下信任 AI 输出的判断力。

在全新项目（greenfield）中，开发者逐渐演变为架构师，他们通过规范而非代码来设计系统。他们的核心任务转向需求发掘、约束定义和验收标准的制定——专注于“做什么”（what），而非“如何做”（how）。他们不再是逐行实现逻辑的编码者，而是系统意图的定义者和验证者，用精确、可执行的规范引导自动化工具生成可靠软件，从而将人类的创造力释放到更高层次的系统思维与安全保证中。

AI 代理负责将规范翻译为实现代码，但人类仍需对规范是否准确捕捉真实需求负最终责任。

换句话说：AI 可以精准地“执行”，但无法真正“理解”业务意图。即使生成的代码完美匹配规范，若规范本身遗漏关键场景、扭曲用户需求或误读安全约束，整个系统依然可能失败。因此，开发者、领域专家和系统架构师的角色并未消失——他们转变为“规范的守护者”与“意图的翻译者”，必须以严谨的态度定义、验证并迭代规范，确保 AI 所生成的一切，始终根植于真实世界的需求与价值。

在已有项目（brownfield）与遗留系统中，SDD（规范驱动开发）催生了一种全新的工作范式：在修改之前，先将现有行为编码为规范。通过从遗留代码中逆向提取规范，团队可以系统性地验证现代化改造是否完整保留了关键功能，同时剔除那些未文档化、潜在危险的“隐性行为”。此时，规范不再只是设计蓝图，更成为连接旧系统与新实现之间的行为契约与对齐基准。

这一方法的应用场景覆盖了软件开发生命周期的全光谱：

在全新项目（greenfield）中，规范指导开发的起点，从源头构建可验证、可追溯的系统； 在遗留系统的功能扩展中，规范充当“行为快照”，确保新增功能不会破坏已有逻辑； 在嵌入式与安全关键系统中，规范是满足 ISO 26262、DO-178C 等标准的基石，确保自动生成的代码在每一处细节上都精确无误。 无论在哪种场景下，开发者的核心角色都发生了根本性转变：

从“代码生产者”转变为“规范作者”与“AI 协调者”。

他们不再在编辑器中逐行敲击，而是在建模工具中精炼逻辑、在仿真中验证意图、在评审中确认AI生成的合规性。他们的价值不再体现为代码行数，而在于以精确、可验证、可维护的规范，赋能机器构建可靠系统——人类负责定义“对的方向”，AI负责“完美执行”。

何时使用SDD

规范驱动开发（Spec-Driven Development, SDD）并非适用于所有场景。与任何开发实践一样，它也伴随着成本与收益的权衡：

成本包括：前期规范投入（时间与沟通）、工具链建设与学习曲线、团队对规范严谨性的持续纪律要求；

收益则体现为：更高的系统清晰度、更强的可验证质量、更优的长期可维护性，以及在复杂或安全关键系统中对一致性与可靠性的保障。

决定是否采用 SDD 的关键，在于精准识别其增益是否能超越其开销。下图所提供的决策框架，正是为开发者与团队提供结构化判断依据：  当使用 AI 编程助手时，SDD 能带来显著价值，因为规范可以消除迫使 AI 猜测的歧义，从而大幅提升输出质量。

对于复杂需求，SDD 使利益相关方能够在代码编写之前验证系统是否真正满足其要求。

在有多名维护者的系统中，规范可作为持久存在的文档，即使团队成员更替，系统行为依然清晰可溯。

对于集成密集型系统，API 规范支持并行开发，有效预防集成失败。

在受监管领域，通常强制要求从需求到实现的可追溯性，而 SDD 天然满足这一要求。

在遗留系统现代化改造中，SDD 的价值尤为突出——通过从既有行为中提取规范，团队能够以高度信心进行洁净重构，彻底摆脱历史代码的包袱。

然而，在某些情境下，SDD 可能属于过度设计。 可以抛弃的原型无需投入规范编写，因为其最终将被丢弃，投入的精力将无从回收。 对于个人开发、短期项目，若仅有一名开发者且无长期维护需求，则规范带来的额外开销很可能超过其带来的收益。 在探索性编程阶段，过早制定规范反而会限制学习与发现——当你尚不清楚要构建什么时，僵化的规格会束缚创造力。 对于需求明确、结构简单的 CRUD 应用而言，只需极简规范即可；若需求几乎不可能被误读，详尽规范只会徒增成本，却无实际价值。

黄金法则：采用足以消除您所处情境中歧义的最低限度规范严谨性。 初期使用 AI 辅助开发时，采用规范优先（spec-first）； 对于长期运行的生产系统，采用以规范锚定（spec-anchored）； 仅当代码生成工具成熟且可信赖时，才采用规范即源代码（spec-as-source）。

常见陷阱

团队在采用 SDD 时，常会遭遇一些可预见的挑战，若不加以应对，将削弱其核心价值：

• 过度规范（Over-specification）

当团队撰写的规范过于详尽，近乎伪代码时，就陷入了过度规范的陷阱。这恰恰违背了 SDD 的核心理念——即清晰区分“做什么”（what）与“怎么做”（how）。如果你的规范读起来像代码，那就走偏了：你过早锁定了实现细节，放弃了规范应有的抽象优势，也丢失了它作为沟通与设计桥梁的价值。

• 规范腐化（Specification Rot）

在“以规范为锚点”的模式中，若代码变更后未同步更新规范，规范将与真实系统逐渐脱节，沦为失效的文档，最终瓦解团队信任。应对之道是：通过自动化测试强制校验规范与代码的一致性——一旦出现偏差，测试立即失败，使“偏离”变得可见、可感知，而非悄然累积、无人察觉。

• 规范官僚化（Specification as Bureaucracy）

当规范从“促进清晰理解的工具”沦为“必须填完的表格”时，它就变成了流程的枷锁。如果规范流程只增加负担、却无实质提升理解或质量，团队要么敷衍了事、要么彻底放弃。记住：规范应是消除歧义所需的最小集，而非追求面面俱到的文档工程。

• 工具复杂性过载（Tooling Complexity）

尤其在使用 AI 辅助工具时，团队可能被生成的海量产物淹没——冗长的开发计划、琐碎的任务清单、中间文档堆积如山。应对方法是：从极简起步，仅在工具能明确提升效率或质量时才引入复杂性，切忌盲目追随“花哨流程”——那只是流程主义，而非工程实践。

• 虚假安全感（False Confidence）

这是最隐蔽也最危险的陷阱：一个“通过”的规范测试，并不保证软件是正确的，它只保证软件忠实执行了规范。如果规范本身有误，代码将一丝不苟地实现一个错误的系统。

规范需要像代码一样被严谨评审——它们不是万能药，不能取代对需求的深度思考、对用户情境的洞察和人类的判断力。

✅ 最终真理：SDD 的价值不在于写得多，而在于写得对；不在于自动化多强，而在于人是否真正理解。

规范是镜子，不是拐杖——它反映心智，而非替代思考。

SDD与传统的设计文档的区别

核心差异：

传统的设计文档是建议性的——开发人员阅读后，自行编写代码，期望尽量贴合文档。

而 SDD 规范是强制性的——如果代码与规范偏离，测试将失败；在“规范即源码”（spec-as-source）模式下，代码甚至会自动重生，而非人工手动修改。

► 传统文档：“请参考这个，尽量做到。”

► SDD 规范：“你不准偏离——要么通过测试，要么重新生成。”

这不仅是流程的升级，更是责任与一致性的范式转变：

不再是“人记不记得文档”，而是“系统自动验证你是否遵守”；

不再是“代码可能偏离设计”，而是“代码就是设计的直接体现”。

这就是 SDD 能消除歧义、阻止腐化、重建信任的根本所在——让正确的行为变得容易，错误的行为变得不可能。

总结

随着软件系统日益复杂，人工智能能力不断增强，核心问题已从“我该写什么代码？”转变为“我该提供什么样的规范？”那些掌握规范驱动开发（SDD）的团队，能够在保持复杂系统所必需的清晰性与可追溯性的同时，更充分地发挥人工智能工具的价值。SDD 提供了一种系统性回答这一问题的框架——将“规范”而非“代码”确立为软件开发的核心产出物。

更多人工智能技术分享，关注微信公众号 小明的IT世界