背景
软件开发的本质，是将开发人员的思想，转换为机器中可执行的代码。准确和高效，是软件开发过程中永恒的目标。
在软件工程发展的历史长河中，效率提升始终是一条主线。从文本编辑器到各类强大的IDE，从单体系统到微服务架构，从瀑布式开发到敏捷研发，一代代工程师为了更快地实现软件价值而前赴后继，这才有了我们现在这个星河璀璨的智能互联世界。
近几年来，随着AI在软件开发场景被广泛运用，软件研发的效率提升，被按下了加速键。
最早出现的是AI代码补全工具，将深度学习应用于代码补全，提供单词或单行级别的补全建议。后来以GitHub Copilot的出现为标志，AI编程助手可以根据注释生成整个函数，结合上下文推断开发者意图。这两年随着Vibe Coding的出现，开发者通过自然语言描述软件意图，由AI去完成具体实现，在一轮轮迭代对话中完成开发目标。
Vibe coding对于个人项目或者一次性项目，是非常合适的提效方式，但是对于企业级场景的代码开发，由于缺乏规范和约束，难以满足企业级代码可靠性和可维护性的要求。
于是规范驱动编程(Spec-Driven Development，SDD)被提出，其核心思想在于，在领域规范的指导下，通过多轮对话迭代，生成符合企业标准的代码。不同于以代码为中心的传统开发模式，SDD把规范(Spec)作为开发过程中的核心资产。
SDD原理
SDD定义了一个严谨的开发流程，强制要求在编码之前，明确定义系统设计意图(Spec)。通过这样的方式，LLM 的角色从“不确定的创造者”转变为“受约束的执行者”。
传统的开发范式以代码为唯一事实来源(Single Source of Truth)，强调可工作的软件胜于详尽的文档 。在AI agent的帮助下，代码产出的成本极大降低，使得我们可以实现从传统开发范式向SDD开发范式的迁移，把Spec作为唯一事实来源。每一次变更，先修改Spec，然后AI agent基于新的Spec更新代码。编程理念从talk is cheap , show me the code，转变为code is cheap, show me the spec。
SDD能够在企业级代码开发中取得成功，有以下几个原因：
- 在设计之初，强制将模糊的需求拆解成具体的功能点，进一步定位为具体的实现任务，通过限制每个任务的范围，使得AI agent在实现代码时，可以聚焦在较小的上下文窗口，确保AI可以高概率输出高质量代码。
- 开发者角色发生了深刻演变，不再是单纯的代码编写者，而是系统架构的设计者和系统功能的验证者，这种左移策略，可以让开发者在实现功能实现之初，就点关键架构设计点和功能验证点，进行深度透彻地思考。
- 将功能规范(Spec)和技术实现解耦，通过Spec描述系统的本质复杂性，而不必陷入具体的技术实现细节。这种解耦允许工程师实现功能的快速迭代，甚至是底层技术栈迁移之类的大规模重构。
SDD实现
本文以Github Spec Kit(Speckit)为例，介绍SDD理念工程化落地实现。
整体架构
Spekit 的物理架构由两部分组成：一个轻量级的命令行界面（Specify CLI）和一套跨代理兼容的模板库。
| 目录结构 | 角色 | 包含内容 |
|---|---|---|
.specify/templates/ |
蓝图层 | 规范模板、技术计划模板、任务分解模板 |
.specify/memory/ |
知识层 | constitution.md 项目宪法，记录长期治理准则 |
.specify/scripts/ |
自动化层 | 跨平台的初始化脚本（Bash/PowerShell） |
七阶段工作流
Speckit通过七个关键命令，引导开发者完成意图到实现的闭环：
-
/constitution : 该命令在Speckit启动之初运行一次，用于制定本项目不随功能变化而改变的基础原则。AI会引导用户完成制定项目的核心原则、技术栈、架构约束、开发流程，生成的constitution.md会作为后续所有命令的上下文。
-
/specify 与 /clarify: /specify 负责生成功能规范
spec.md。开发者输入初始的功能需求描述，AI负责拆解成相应的User Story 和 功能需求，后续用户通过/specify 命令，和AI一轮轮沟通具体的需求实现细节，直至双发达成一致。 -
/plan:负责生成技术方案文档，制定技术实施计划。用户可以通过可AI的交互，调整方案选型和技术实现细节。
-
/tasks:确定具体的开发任务列表，通过review task列表，对开发任务进行查漏补缺。后续可以执行 /analyze命令，分析项目约束是否被遵循、功能点是否都已经被覆盖。
-
/implement: 根据任务清单，逐项生成代码。每完成一个任务，就勾选任务把状态设置为已完成，防止后续重复劳动。
Spectkit的工作流，和我们日常的需求开发流程相契合，按需求收集、PRD设计、技术方案设计、开发事项拆解&排期、编码开发、测试验证的步骤执行，这也从侧面说明，传统的软件开发流程，有其内在的科学性。
具体实现
每个Spec命令，都以Markdown文本文件的形式，被安装到 /commands目录下面供Agent调用。
以speckit.specify.md 文件为例，其整体流程分为以下7步：
| 步骤 | 做什么 | 实现要点 |
|---|---|---|
| 1. 生成短名 | 从描述里提炼 2–4 个词作为 feature 短名 | 用「动作+名词」、保留技术词（OAuth2、API 等），保证可读且唯一性友好 |
| 2. 分支与目录 | 决定新 feature 的编号和分支/目录 | git fetch → 在 远程分支、本地分支、specs/ 目录 里找同短名下的最大编号 N → 用 N+1；然后只执行一次 create-new-feature.sh，传入 --number、–short-name 和描述，拿到脚本输出的 JSON（含 BRANCH_NAME、SPEC_FILE 等） |
| 3. 加载模板 | 读 .specify/templates/spec-template.md | 确定 spec 必须包含的章节和占位符，保证输出结构一致 |
| 4. 执行规格生成逻辑 | 解析描述 → 提取概念 → 填 spec 内容 | 顺序：解析输入 → 提取 actors/actions/data/约束 → 对不明确处做合理默认或打 [NEEDS CLARIFICATION: …]（最多 3 处）→ 填用户场景与测试 → 功能需求（可测试）→ 成功标准（可度量、技术无关）→ 关键实体 → 输出「SUCCESS」 |
| 5. 写 spec | 把生成内容写入 SPEC_FILE | 按模板结构写，保留章节顺序和标题，占位符换成从「用户描述」推导出的具体内容 |
| 6. 质量校验 | 用 checklist 检查 spec 质量 | 在 FEATURE_DIR/checklists/requirements.md 建检查清单；逐条对照检查；不通过则改 spec 并重验（最多 3 轮）；若有 [NEEDS CLARIFICATION]，则以固定格式向用户提问（含选项表），根据用户选择更新 spec 后再校验 |
| 7. 收尾报告 | 汇报完成情况 | — |
specify 命令的实现中，会专注于描述用户诉求和为什么需要这样设计，不会设计具体的技术栈、API和代码结构。
SDD实战
以一次日常需求 HTTP接口签名服务 开发为例，介绍一下SDD的具体实践。整体实践流程如下图所示：
- 需求澄清阶段：
经过10轮的需求澄清，逐步细化需求，明确了需求的具体细节，产出了AI可处理的prd spec.md。每次澄清都有明确的记录，将需求变动同步更新到文档中，避免了传统开发模式中，需求变更难以追溯，以及需求和实现不匹配的问题。
最终产出的需求文档结构：
1 | spec.md (需求规格) |
- 方案计划阶段
该阶段产出了具体的技术方案文档plan.md，文档中进行了清晰的模块
划分，遵循了各个层级之间的依赖关系，避免了传统流程中可能存在的技术方案细节确实、依赖关系混乱等问题。
技术方案后续被拆分成了72个具体的开发任务，记录在task.md中。明确记录了任务之间依赖关系、任务的归属User Story 信息，并持续追踪任务的完成状态。避免了流程中，任务管理可能存在的不够细致、依赖关系不清晰等问题。
最终产出的任务格式：
1 | - [x] T014 [US1] Create RequestSignature domain model |
- 具体实现阶段
AI agent在本阶段高效完成各个任务的开发编码工作，同时通过执行完备的单元测试，保障代码质量，生成了规范的接口使用文档，和完整的使用指南，方便前端开发对接。
最终生成代码的统计数据：
1 | 总代码行数: 2039行 |
如何用好SDD
生产级准确性
Vibe coding的核心痛点在于：
- 上下文的缺失。AI能看到的，只是当前应用中有限的内容，并不清楚团队的编码规范、历史需求的设计决策依据。
- 知识的碎片化。大量领域知识，沉淀在开发人员的脑海里，零散且难以传递给AI。
- 长期可维护性。随着项目中AI生成的代码越来越多，工程师对代码的掌控越来越低，很容易出现代码熵值过高，无法持续演进的情况。
在SDD实践过程中，我们需要：
- 给AI提供充分和清晰的上下文内容，帮助AI生成准确的代码。
- 把Spec作为核心资产和唯一事实源头，所有的迭代演化围绕Spec进行。
- 通过严格的代码审核和充分的自动化测试，持续保障项目代码的高质量。
追求10x效率
SDD带来的效率提升，体现在以下几个方面：
- 首先是开发效率的提升，AI工具产出代码的速度比人类工程师要快。
- 接着是沟通成本的下降，产品经理、后端工程师、前端工程师、测试工程师，都可以围绕spec进行沟通，大家可以聚焦于问题定义，而非具体的实现代码。
- 更重要的是能力边界的打破，团队中各个角色的成员，都可以对spec进行修改，职责边界变得模糊，能力边界得到放大。项目开发不再卡在资源排期等待，各个角色可以并行开发。
技术创新不仅改变了个体的工作方式，使得10x效率工程师成为可能，更重要的是改变了团队协作模式和能力边界，期待未来出现10x效率的工程研发团队。
SDD的限制
SDD并不是一劳永逸的终极方案，有其固有的限制：
- 规范无法描述整个系统。依然有很多的隐性上下文，无法通过规范来描述。提供了规范，也不代表AI就能完整而准确地理解，上下文的长度不代表思考的深度。
- 规范的维护也需要成本。规范未必比代码更容易维护，依赖于体系化的架构能力，实际上对工程师的能力提出了更高的要求。如果不把规范作为唯一事实源头，那么需要同时维护规范和代码的迭代演进，反而引入了更多的gap，增加了维护的负担。
- 审核的成本更高。除了要审核大量的AI代码，发现其中隐藏的问题之外，还需要审核规范文档，确保需求被清晰准确地定义。
虽然SDD模糊了团队人员的能力边界，但并不意味着出现了全能开发者，现代软件工程的角色分工的价值并未发生动摇：
- 产品经理用AI辅助需求文档起草，但是需要自己执行需求决策判断。
- 架构师用AI辅助产出技术方案，但是需要自己做出核心的架构决策。
- 开发任务通过AI加速编码，但是方案设计和代码审查依然需要人来完成。
- 测试人员运行AI生成的测试用例，但是依然需要对整体的质量风险进行把关。
AI帮助开发者完成了机械编码工作，让开发者有更多的精力，能够更多地投入到思考和决策中去，这些事项随着AI的发展，重要性更加凸显。
进一步思考
没有银弹，但有铅弹
在欧洲的古老传说中，银弹(silver bullet)可以用来杀死可怕的狼人，一枪毙命。
在著名的《人月神话》一书中，作者布鲁克斯在《没有银弹》这一篇，论述了没有任何技术或者方法，可以使软件工程的生产力在十年内提升十倍。软件开发活动有一些本质性的问题难以解决：
- 复杂性(complexity):软件要解决的问题，有其本质的内在复杂度，依赖于人为的抽象化智能活动。
- 隐匿性(invisibility): 未完成软件是看不见的，代码实现的过程中包含着很多隐性的知识，这带来了极大的沟通成本。
- 配合性(conformity): 大型软件系统中，各个子系统的接口必须保持协同一致，并随着时间和环境的演变持续迭代。
- 易变性(changeability)：软件所应用的环境，会快速变化，这要求软件也需要持续演进。
AI时代，这些本质性问题依然存在，不过随着SDD这样的新范式出现，我们开始有了新的应对方式：
- 对于固有的本质复杂性，可以结合AI工具辅助分析和学习。
- 对于隐匿性，通过围绕spec建设核心资产，使得开发过程的各个角色，基于相同的技术语言进行讨论，极大降低沟通成本。
- 对于配合性，AI比人类更加擅长遵循协议规范。
- 对于易变性，AI可以帮助我们更快速地对需求变化做出响应，并且把变化历史沉淀到spec中以便追踪。
在新的SDD研发范式下，生产力能够大幅提升，纵使依然没有银弹，但至少我们可以拥有铅弹。
人和AI的关系
工程师会被AI替代么？
目前来看，AI很擅长解决解决中小规模的需求，能够高效产出可在生产环境运行的代码，但是至少在核心架构设计、重要技术选型、代码质量和功能验证方面，目前AI无法替代人类完成。人类能够完成的系统化深度思考，随着AI的发展显得更加重要。
AI能力的快速发展，也要求个人进行迭代升级，打破旧的自我，将AI擅长的部分交给AI，最后剩下的，就是自己的核心不可替代能力。
当我们在试图用替代这个词，来描述人类和AI之间的关系时，问题的定义本身就错了，工程师和AI不是非此即彼的竞争关系。也许AI能够帮助我们做什么 ，才是一个正确的问题。主动拥抱AI，把AI作为朋友，才能让自己持续进步。
还有一个更好的问题：我们能够帮助AI做什么 ，如何才能更加深刻地理解AI的原理和工作模式，通过Context engineering、MCP tool、Skill等手段充分释放AI的能力，是这个时代每一位工程师的必修课。
未来展望
SDD标志着软件工程在AI时代的一次重要演进，设计意图被提取出来，沉淀为持久化、可执行的资产，为解决AI代码的熵增问题，提供了坚实的基础。
展望未来，为了使AI更加高效地产出可靠的生产级代码，我们需要：
- 持续投资建设高质量的知识底座，把公共规约、项目领域知识注入到AI agent的上下文。持续迭代更新这些知识资产，并记录变更。
- 尝试不依赖人工拆解功能需求，而是让AI直接阅读PRD，生成相应的多个spec，并行开发。
- 度量SDD的提效指标，收集相关数据和工程团队反馈，持续优化相关实践。
SDD为AI coding的实践，指明了方向，如黑暗中的一座灯塔，引领我们驶向AGI的星辰大海。