点击关注上方公众号，发现更多精彩内容等你来发现

大家好，我是靈吾靈，专注于AI技术前沿分享，用最接地气的话讲最前沿的科技是我的专长，让每个人都能玩转AI是我的初心~

前言

大家刚开始用 AI写代码的时候，应该都会遇到这种情况：

• 满怀期待地让AI写代码，结果它理解错了需求，写了一堆你不想要的功能；

• 或者你想让它改个小地方，结果它把整个文件都改乱了；

• 又或者几轮对话后，AI完全忘了你最初想要什么，代码越改越偏......

网上有一个在社区传播比较广的图，肯定能命中各位的曾经遇到的窘境，也揭露了当下 AI 辅助编程不一定能很好的理解你特定的需求。

（ps: 从LINUX DO 社区而来虚构的图，非真实的排名情况，大家当乐子看看就行了）

归根结底，这不是 AI 的能力不行，而是 AI 辅助开发工具和人之间的协同问题：由于缺乏精确的描述，AI 尽管能力很强，它也没法精准知道你到底想干什么，所以只能靠猜....

这也是当下Vibe Coding的弊端，尽管市面上AI IDE工具提供了类似Cursor Rules、CLAUDE.md、AGENTS.md  、Agents Skills...........其实这些配置项解决的代码本身规范、质量问题，约束大模型生成代码乱来，规范AI 行为的手段，但是距离通过需求生成适合的代码还有很大的距离。

规范驱动开发（Spec-Driven Development， SDD） 是当前AI辅助编程领域兴起的一种新兴开发范式。它颠覆了传统「代码先行」的模式，将规范（Spec） 置于开发流程的核心。

其核心理念是，在编写或生成代码之前，首先构建一份结构化的规范文档，并由AI编码代理（Agent）根据这份规范来生成、验证和迭代代码。

SDD的诞生背景：AI 编程的发展史

阶段 1：AI-assisted coding

2022年底 GPT 刚“出圈”时，行业里并没有像今天的「Vibe Coding」那样统一的称呼，也有可能是安德烈·卡帕斯 (Andrej Karpathy)还没有掌握起名的技巧，所以没有一个像“Vibe Coding”那样被普遍接受的专有名词。

但大家默认把“让 AI 帮你写/补代码”统称为 AI 辅助编程（AI-assisted coding）。它主要分两条线：

1. 代码补全（Copilot 模式）
   GitHub Copilot 2021 年已内测，2022 年 6 月正式公开，在编辑器里敲几行，AI 自动续写函数、整块逻辑，甚至帮你写单元测试。当时最流行的说法就是“copilot 帮我写代码”，以至于“Copilot”几乎成了 AI 补全的代名词
2. 对话式生成（Chat 模式）2022 年 11 月 ChatGPT 发布后，很多人把需求直接贴进聊天框，让 GPT 一次性吐出完整脚本，再复制粘贴回本地运行。那时大家口语里只说“用 ChatGPT 写代码”，没有专门术语，但已经具备后来 Vibe Coding 的雏形——自然语言驱动、不细看实现、快速试错

这个阶段我也参与过，当年的情况跟今年 2025 年的Vibe Coding爆火一样，但是各大厂商不断发布很多 vscode 的 AI 辅助编程插件，在你追我赶。当时我还写过两篇测评文章呢：

1. AI编程助手：手把手教你部署私人的ChatGPT应用
2. 如何正确使用AI编程助手让工作效率翻倍

也就是 2024 年年初的事情，当时的安装在 VS Code各种插件现在是一点也用不上了。

这个阶段也暴露出一些问题：

• 局限于局部优化：只能帮助完成单个方法或代码片段，无法理解整体业务逻辑
• 缺乏上下文理解：不了解项目的架构规范和代码风格
• 无法应对复杂需求：对于跨多个类、多个模块的需求无能为力

这个阶段让我总结的话，我不会使用AI-assisted coding,这个名字太笼统，表达不够准确，相反我会用以下两个范式命名：Tab Coding（用 tab 无限续写编码）或者Chat Coding（对话式生成编码）

阶段 2：Vibe Coding

Vibe Coding (中文翻译为氛围编程)这个名字从籍籍无名到每个程序员都在谈论，应该是从 Andrew Karpathy（前特斯拉人工智能总监，OpenAI 的创始成员之一）的这条推特开始的。

大家有兴趣可以去了解的他的原文对Vibe Coding的理解，基于原文内容，我提炼一下Andrew Karpathy 对于 vibe coding 的定义如下：

1. and forget that code even exists: 忘记有代码的存在。
2. I barely even touch the keyboard:几乎不手动参与编程，再小的错误也通过 AI 来修复而不是手动更改。
3. I don't read the diffs anymore:AI 写的代码不再 review，只看结果，不满意的话继续对话。
4. but still quite amusing.：对于一次性的项目来说，并不糟糕，并且相当有趣。

听听这词的原话，按这原话理解，Vibe Coding 就不是个好词，所以刚开始的时候大家觉得Vibe Coding生成的代码非常不可控，无法参与复杂项目的开发，这个怀疑很合理！

不知道为何，目前确实发展到只要是通过 AI 工具来辅助编程，或者是通过 AI 来编写代码的方式，都统一称为 Vibe Coding 了。

2025 年 AI编程爆火，各大厂商在不断Vibe Coding的氛围下，纷纷卷起智能体，各类的编程工具和终端编程工具涌现。Qoder、CatPaw、Antigravity、Kiro、Claude Code Cli、Gemini Cli等等，如果用一个更合适词代替Vibe Coding ，应该是：

Agentic Coding！！！

当然这些都是我的愚见，我们继续说回Vibe Coding的阶段带来的问题：

1. 需求碎片化： 需求散落在几十条对话里，没有一份清晰、可回溯的说明文档。上下文一旦被截断，AI 就“失忆”，后续生成很难保持一致。
2. 代码延续性差： 同样的想xx业务，第二次让AI实现时，生成的代码风格完全不同。每次生成的代码都像抽卡，类似功能的实现方式五花八门，维护成本高。
3. 代码风格不一致： AI不了解项目的代码规范，导致生成的代码风格和存量代码不一致。
4. 团队协同性差： 不同开发者写的Prompt差异大，生成的代码质量参差不齐，新手写的Prompt过于简单，AI生成的代码质量差，陷入纠错时间成本大，老手写的Prompt详细但冗长，难以复用，缺乏统一的Prompt模板和最佳实践
5. 协作成本极高： 团队成员之间很难共享“AI 之前到底聊了什么”。换人接手，几乎只能从代码和 commit message 倒推需求。

正因如此，规范驱动开发（Spec-Driven Development， SDD）， 就这样自然而然的出现了。SDD的兴起，直接源于对当前主流AI编程模式——“氛围编码”（Vibe Coding）的深刻反思与纠偏。

阶段 3：Spec Coding

Spec Coding并没有像Vibe Coding那样由某一个人明确提出并命名。

不过，从2025年下半年开始，OpenAI 的研究员 Sean Grove 在多个场合强调了“规范（Spec）”在 AI 编程中的核心地位，并提出了类似“Prompt Engineering is Dead, Everything is A Spec”的观点。

他主张通过结构化、可验证的规范来指导 AI 生成代码，从而提升代码质量和可维护性。

规范驱动开发（Spec-Driven Development， SDD） 为Spec Coding这个阶段的编码提供了理论基础和新范式。

Spec Coding的核心理念：在Coding之前，先准备详细的“说明书”。

这份说明书包括：

项目整体规范、需求文档、技术方案设计、编码流程设计、任务拆解清单、验收标准

通过约束规范、计划先行来缩减AI的发挥空间，用“流水线”式的作业换取更可靠的执行结果。

大胆预测，Spec Coding这个阶段编码新范式会在 2026 年爆火，可能会出现更好的开源工具，更好的理论支持、更完善的编辑器支持、更成熟的工作流支持等等。

SDD 是什么？

引用Martin Fowler网站里面的一句话。

规范驱动开发是指在编写代码之前，先编写一份“规范”（即先编写文档），然后再使用人工智能进行开发。

规范驱动开发（Spec-Driven Development， SDD） 在写任何一行代码之前，先让“要做什么、为什么这样做、做到什么程度算完成”以规范文档的形式沉淀下来，并且这份文档既能给人看，也能直接喂给 AI 作为执行依据。

SDD的核心理念：

1. 规格是唯一真理源（Single Source of Truth）
   1. 所有的代码、测试、文档都从规格生成
   2. 规格即文档，文档永不过期
2. 设计先于实现
   1. 先用自然语言描述"做什么"（规格）
   2. 再让AI生成"怎么做"（代码）
3. 可测试性内建
   1. 规格中明确定义测试用例
   2. 自动生成完整的单元测试

SDD 不是全新的概念

从概念上，SDD很接近Requirement Specification（需求规格说明书），这个是正统软件工程的标准做法，但是很难被真正地良好落地实施。

它更像是软件工程“先想清楚再动手”这一古老智慧在AI时代的回归。

区别在于：

• 过去写文档是痛苦的、低效的，所以很多人不愿意做
• 现在AI可以辅助甚至自动生成Spec，成本大幅降低

SDD的主流解决方案

目前，SDD的实践主要通过一系列工具落地，它们各自代表了不同的设计哲学和适用场景。

方案 1：GitHub Spec-Kit

一套帮助你开始实践 Spec-Driven Development 的工具包

适合人群：适合"产品+研发"都自己干的程序员

由GitHub推出的开源CLI工具包，强调“规范即代码工件”和全流程治理。

它提供从宪法制定、规范定义、计划生成到任务拆解、代码实现的全套结构化命令，流程严谨，适合对标准化、可审计性要求高的大型团队和项目。

Spec Kit 的工作流非常"重"，但也非常完整：

Spec Kit 的核心哲学：先把"做什么"和"为什么"想透，再考虑"怎么做"。

方案 2：OpenSpec

专为“增量开发”而生的轻量框架

适合人群：维护中大型项目的开发者，它不针对人，针对是旧项目开发。

由Fission AI团队开源，其设计哲学专为解决在已有代码库上进行安全、可审计的迭代。其工作流围绕“变更提案”展开，强调团队对齐和风险控制，非常适合维护遗留系统的团队 。

OpenSpec 的工作流

OpenSpec vs Spec Kit 的核心区别：

方案 3：Amazon Kiro

轻量灵活的代理式集成开发环境（Agentic IDE）

Kiro定位为个人开发者或小团队的快速原型与开发加速器。

它采用固定的“需求（Requirements）→ 设计（Design）→ 任务（Tasks）”三步工作流，每个步骤对应独立的Markdown文档。

Kiro强调高度的自动化，内置了“代理钩子”（Agent Hooks）功能，可以在文件保存等事件发生时自动运行任务，交互自然，上手门槛低，适合追求开发速度和敏捷迭代的场景。

它是相对成熟以Spec Coding为规范落地的 IDE工具，非常好用，是 Cladue Code 的小弟，内置所有Cladue Code的模型。

国内的编程工具Qoder阿里巴巴的里面的Quest Mode的任务模式也是想做 SSD 规范，但是还是差强人意，感觉就像加强版的Plan模式，还非常耗 Token。

归纳总结

Spec Kit和OpenSpec并不互斥，可以根据项目阶段灵活组合：

1. 用 Spec Kit 完成项目从 0 到 1 的搭建， 它 = 产品经理 + 架构师 + 程序员的三合一，适合从 0 到 1 想清楚再动手。
2. 项目稳定后，切换到 OpenSpec 管理后续迭代。存量项目的变更管理专家，适合需求明确、快速执行的场景。

SDD的问题与挑战

虽然SDD带来了价值，但在实践中也遇到了一些明显的问题：

问题1：规格编写门槛高

现象：编写高质量的规格说明需要较强的抽象能力和文档编写能力

影响：对于简单需求，写规格的时间甚至超过直接写代码

• 新手往往写不好规格，过于技术化或过于模糊
• 规格模板虽然有，但如何填写仍需要经验
• 不合格的规格对后面的代码实现影响

问题2：Spec Kit工具链不成熟

无论是Spec Kit还是OpenSpec都在发展中，技术的不断迭代和实践， 能带来很多现实问题：

1. 规格解析不准确
   1. AI有时无法正确理解规格中的复杂逻辑
   2. 需要用非常精确的语言描述，稍有歧义就可能理解错误
2. 代码生成质量不稳定
   1. 相同的规格，不同时间生成的代码质量差异大
   2. 有时生成的代码过于冗长，有时又过于简化
3. 增量更新困难
   1. 规格修改后，很难做到只更新变化的部分
   2. 往往需要重新生成整个文件，导致手工修改的部分丢失

问题3：与现有代码库集成困难

SDD更适合从零开始的新项目,不适合在旧项目上践行

• 历史代码缺乏规格说明，无法纳入SDD体系
• 新老代码风格混杂，维护成本反而增加
• 团队一部分人用SDD，一部分人用传统方式，协作困难

问题4：学习成本高

• 写出合格的第一份规格说明，平均需要3-5次迭代
• 老员工接受度较低，认为"还不如直接写代码快"，这个就是很难推行的原因之一

总结

SDD是一场静默的范式革命, 在 AI 的加持下，它正在让 Vibe Coding 变得更加严谨，更加工程化，更加符合AI 时代的开发范式。

但是 Spec Coding新范式的道路还任重而道远，因为相比Vibe Coding的自由自在，Spec Coding的模式无疑会让开发更难受，受到很大的限制，大家抵触的心理也会增加，以前没有 AI 加持，大家对于 SDD 的模式也很抵触的，需求文档的增加，意味增加了很多沟通成本，现在就算AI 加持，本质不会变，只是沟通的对象由人转移到 AI 模型上

不同的项目应该有不同的方式来处理，对于偏Vibe Coding快速落地的项目，应该更加考虑产品的可用性，弱化代码细节；

对于复杂度高，或者需要准确性不能出错的项目，不管是Vibe Coding还是Spec Coding都一定要自己review所实现的代码，让代码变得可控，不然后续就很难维护了。

后续有时间继续更新 SDD 的实践案例，规划中会包括但不限于：

• OpenSpec 的实践案例（现有代码中进行增量规范驱动开发）
• GitHub Spec-Kit 的实践案例

免责声明:本文仅供技术交流学习使用,请遵守相关法律法规。文中提到的工具和方法仅作为技术探讨,不构成任何使用建议。