SDD规范驱动开发：让规格成为唯一真相
本章要点
上一节我们认识了 TDD——用测试为 AI 导航，在代码生成之前先定义好"怎么验证"。测试解决了代码层面的正确性问题，但还有一个更上层的挑战没有解决：当项目规模增大，当代码需要长期维护，当团队里不止你一个人时，如何确保 AI 一直在构建"正确的东西"，而不只是"正确地构建东西"？
这一节，我们要认识一种能够解决这些问题的方法论——SDD（Spec-Driven Development，规范驱动开发）。
读完这一节，你会获得：
- 理解什么是"规格"（Spec），以及为什么它比提示词更重要
- 掌握 SDD 的核心工作流：从需求到规格，从规格到代码
- 认识三款主流的 SDD 工具——GitHub 的 Spec Kit、Fission-AI 的 OpenSpec，以及 AWS 的 Kiro
- 学会根据项目类型和团队需求，在三款工具之间做出合理选择
当"感觉"不够用的时候
让我们想象一个场景。你正在用 Vibe Coding 的方式开发一个项目，需求是"给用户做一个订单管理系统"。你打开 Claude Code，开始描述想法，AI 很快生成了第一个版本。你说"感觉差不多"，继续让它加功能。
三天之后，你回头看这份代码，发现：
订单的状态流转是 AI 在某次对话里自己决定的，你当时没有仔细看，现在已经不记得是哪次了；支付模块和库存模块之间的数据结构不一致，因为它们是在两个不同的上下文窗口里生成的，AI 各做各的；你叫同事来协作，他看了半天代码，一头雾水，问你"这个字段到底什么意思"，你只能说"AI 写的，我也不太确定"。
这不是你的失误，这是 Vibe Coding 方式的结构性局限。当你把需求散落在一次次对话里，当每次新的上下文都让 AI "重新理解"了一遍你的意图，代码就会慢慢变成一个没有人真正说得清楚其全貌的混乱系统。
SDD 的出发点，就是解决这个问题。它的核心洞见只有一句话：写代码之前，先把你想要什么写清楚，让这份"清楚"成为整个项目的唯一真相。
什么是"规格"
"规格"这个词，翻译自英文的 Specification，简称 Spec。在传统软件工程里，这往往是一份厚重的需求文档，产品经理写了几十页，工程师读都不想读。但在 AI 编程的语境下，Spec 的含义更轻盈，也更精准。
一份好的 AI 时代的 Spec，不是产品需求文档（PRD）的升级版，而是一份能让 AI 精确行动的上下文容器。它至少包含三个维度的信息：
第一，你要构建什么——不是模糊的愿景，而是具体的功能边界。不是"做一个用户管理系统"，而是"用户可以注册、登录、修改个人信息；管理员可以查看用户列表并封禁账号；密码使用 bcrypt 加密存储"。
第二，约束是什么——技术栈、架构风格、性能要求、安全要求。不是"用 Python 写"，而是"使用 FastAPI + PostgreSQL，遵循 RESTful 设计，接口响应时间在正常负载下不超过 200ms"。
第三，接受标准是什么——你怎么判断 AI 的实现是"对的"。这一点最常被人忽略，也最关键。因为如果你说不清"什么叫做对"，AI 就只能猜。
把这三个维度写清楚，你就有了一份 Spec。它可以很长，也可以只有几百字——关键不在于篇幅，而在于把你脑子里隐性的决策，变成写在文件里的显性规则。
规格与提示词的区别
你可能会问：这跟给 AI 的提示词有什么本质区别？
区别在于持久性和可传递性。一段提示词，在那次对话结束后就消失了。下次你开一个新的对话窗口，AI 不记得你上次说了什么。而一份 Spec 存在于你的代码仓库里，任何时候都可以被任何工具、任何人、任何 AI 读取。
更重要的是，Spec 是可以被人类审查的。在代码生成之前，你、你的同事、你的老板，都可以读这份 Spec，确认"我们想要的就是这个"。一旦规格被审查确认，代码就成了规格的产物——如果代码出了问题，你不是去查代码，而是去查规格哪里写得不够精确。
这种思维方式的转变，是 SDD 最深刻的地方：调试规格，而不是调试代码。
SDD 的核心工作流
了解了"规格"是什么，我们来看 SDD 的工作流是如何把规格变成代码的。尽管不同工具有不同的实现方式，但核心流程基本遵循四个阶段：
需求 → 规格（Spec）→ 计划（Plan）→ 任务（Tasks）→ 实现（Implement）
阶段一：编写规格（Spec）
这是整个流程中最需要人类深度参与的环节。你和 AI 一起，把你的需求转化为一份结构化的规格文档。AI 会帮你提问、帮你发现你没有想清楚的地方，但最终的规格需要你来确认。这一阶段结束时，你手里有一份写清楚了"要什么"和"约束是什么"的文件。
阶段二：生成计划（Plan）
有了规格，AI 开始思考"怎么做"。它会根据你的技术约束，生成一份实现计划：需要用哪些库、数据库结构怎么设计、模块之间的接口是什么样的、需要哪些外部服务。这份计划是规格的延伸，你仍然需要审查它，确保技术决策是你认可的。
阶段三：拆分任务（Tasks）
有了计划，AI 把实现过程拆分成一个个可执行的任务。每个任务都足够小，小到一个独立的 AI 会话可以完成，并有清晰的"完成标准"。任务之间有明确的依赖关系，按顺序执行不会相互冲突。
阶段四：执行实现（Implement）
最后，AI 按照任务列表，一个任务一个任务地生成代码。由于规格和计划已经做了大量的上下文铺垫，这一阶段的代码质量远比直接 Vibe Coding 要稳定，出现方向性错误的概率也大大降低。
整个流程的关键在于：每个阶段都有人类审查的检查点，你在确认之前不会进入下一个阶段。这就是 SDD 和 Vibe Coding 最根本的差异——不是"走一步看一步"，而是"想清楚再走"。
Spec Kit：GitHub 为 AI 时代打造的开源工具包
2025 年 9 月，GitHub 正式开源了 Spec Kit——一套专门为规范驱动开发而设计的工具包。它的诞生背景，和我们前面描述的痛点完全吻合：随着 AI 编程代理越来越强大，开发者发现"描述需求、拿到代码"这个流程看起来运转良好，但产出的代码经常"看起来对，就是跑不起来"或者"解决了部分问题，但偏离了真正的意图"。
Spec Kit 的核心设计理念是：让规格成为工程流程的中心，而不是让代码库成为默认的规格。
Spec Kit 的组成
Spec Kit 包含三个主要组件：
Specify CLI，一个命令行工具，负责在你的项目里初始化 SDD 的脚手架。安装之后，它会在项目根目录创建一个 .specify 目录，这里存放所有的规格文档、计划文件和任务列表。
一套 Slash 命令模板，这是 Spec Kit 最核心的部分。它为 AI 代理定义了一组标准化的斜杠命令，每个命令对应 SDD 流程的一个阶段：
/speckit.specify——引导 AI 和你一起编写需求规格/speckit.plan——基于规格生成技术实现计划/speckit.tasks——把计划拆分成可执行的任务列表/speckit.implement——按照任务列表执行实现/speckit.clarify——在实现前检查规格中的模糊之处/speckit.analyze——分析规格中的潜在不一致性
一个"宪法"（Constitution）机制，这是 Spec Kit 特别有意思的设计。你可以在项目里定义一份"技术宪法"——关于你们团队的技术标准、架构原则、编码规范的权威文档。所有 AI 生成的计划和代码，都会以这份宪法为基础进行约束。这意味着如果你的团队规定"所有 API 必须使用 TypeScript，错误处理必须用 Result 类型"，AI 就不会偷偷用 JavaScript 或者抛出裸异常。
Spec Kit 的适用场景
Spec Kit 特别适合规模中等以上的全新项目（greenfield）。当你要从零开始构建一个有着清晰功能边界的系统时，Spec Kit 的四阶段流程能最充分地发挥作用——你有足够的空间把规格写得细致，计划做得扎实，然后让 AI 按图施工。
从实际使用来看，Spec Kit 生成的规格文档通常在 800 行左右——信息量很大，覆盖也很全面，但也意味着你需要在前期投入相当多的时间来编写和审查。如果你在做一个小功能或者快速验证的原型，这个投入可能并不划算。对于小功能、快速原型、或者改动已有代码库的情况，这个代价可能超过它带来的收益。
OpenSpec：专为存量代码而生的规格框架
如果说 Spec Kit 是为全新项目量身打造的，那么 OpenSpec 解决的就是另一个更普遍、也更棘手的场景：你已经有了一个运转中的代码库，现在要往里加新功能。
OpenSpec 是由 Fission-AI 发布的开源框架，在 2025 年下半年亮相，入选了 Y Combinator W2026 批次，GitHub Stars 在短短数月内便积累至数万颗。它的核心概念被描述为"意图的版本控制"（version control for intent）——就像 Git 管理代码的变化一样，OpenSpec 管理你对系统"打算做什么"的变化。
OpenSpec 的三阶段状态机
OpenSpec 把每一次功能开发都抽象成一个严格的三阶段流程：
提案（Proposal）→ 应用（Apply）→ 归档（Archive）
提案阶段：在动一行代码之前，你首先创建一份"提案"。提案里描述你想要做什么变更，并且用 Delta 标记（ADDED、MODIFIED、REMOVED）明确标注每一个变化相对于现有系统是"新增"、"修改"还是"删除"。提案文件存放在 openspec/changes/ 目录下。只有当人类审查并批准了这份提案，AI 才被允许开始生成代码。
应用阶段：提案获批后，AI 根据提案内容实现代码。由于提案已经明确标注了哪些部分会变更，AI 不会"不小心"修改你没有预期它去动的代码，也不会在实现过程中偷偷做出超出提案范围的决定。
归档阶段：功能实现并通过验证后，这份提案被归档，对应的规格从 changes/ 目录合并进 specs/ 目录，成为系统当前状态的一部分，留存备查。
"意图的版本控制"是什么意思
这个概念值得多解释几句。
在传统开发里，我们用 Git 记录代码的历史。你可以随时看到代码在某一天是什么样的，是谁改的，为什么改。但 Git 记录的是"代码做了什么"，不记录"我们当初为什么这样做"。
OpenSpec 补足了这个空缺。当你用 OpenSpec 管理一个项目时，你可以随时打开 openspec/specs/ 目录，看到系统当前状态的完整规格描述；你可以打开 openspec/changes/ 目录，看到正在进行中的变更提案；你可以翻看归档记录，看到每一次变更的决策过程。这套历史，是代码库之外的另一层文档——它记录的不是代码，而是"意图"。
这对于存量代码库尤为珍贵。当一个新同事加入团队，或者六个月后你自己回头看代码，OpenSpec 的规格目录能告诉你"这个系统是被怎么设计的，为什么这样设计"，而不只是留下一堆让人猜测的代码。
OpenSpec 的适用场景
OpenSpec 特别适合改动已有系统的场景。它的 Delta 标记机制，天然适合描述"在现有基础上加什么、改什么、去掉什么"，而不是从头描述整个系统。
另一个适合 OpenSpec 的场景是需要严格变更管控的团队。它的提案审批机制让每一次功能开发都有明确的人类审查点，AI 在未获批准前不会产出任何代码，这对于有合规要求或者历史遗留系统的团队来说是很实用的保障。
OpenSpec 的规格文档相对精简，大约在 250 行左右，远比 Spec Kit 的 800 行要轻量。这意味着更低的前期投入，更容易审查，也更容易在快节奏的迭代中保持规格的及时更新。
Kiro：AWS 把规范驱动内建进了 IDE
如果说 Spec Kit 是一套工具包，OpenSpec 是一个轻量框架，那么 Kiro 代表的是 SDD 方向的另一种探索：把规范驱动的理念直接内建进 IDE 本身。
Kiro 是 AWS 于 2025 年 7 月公开预览的 agentic IDE，基于 VS Code 内核（Code OSS）构建，同年 11 月正式发布。和 Spec Kit、OpenSpec 不同，Kiro 不是插件，也不是 CLI 工具——它是一个完整的开发环境，SDD 的工作流被嵌入进了 IDE 的核心体验。你不需要在终端执行命令、不需要手动维护目录结构，打开 Kiro，工作流就在你眼前。
Kiro 的三份规格文件
Kiro 把每一次功能开发的规格拆分成三个相互关联的文件，统一存放在项目的 .kiro/specs/ 目录下：
requirements.md 负责捕捉"要做什么"。Kiro 引导你用自然语言描述功能，然后自动将其转化为标准化的用户故事格式，验收标准采用 EARS（Easy Approach to Requirements Syntax）标注法写成，让需求可以被精确验证，而不只是模糊描述。
design.md 负责呈现"如何做"。Kiro 会分析你的现有代码库，生成一份技术架构文档——用什么技术方案、数据如何流转、模块如何划分。这份文档在代码生成之前交给你审查，你可以修改、补充，确认之后才继续。
tasks.md 负责"具体怎么走"。有了前两份文档，Kiro 将实现过程分解为一个个具体的编码任务，每个任务都有清晰的完成标准。任务完成一个，状态更新一个，进度可见。
Steering Files 与 Agent Hooks
Kiro 还有两个值得单独说说的机制。
Steering Files 存放在 .kiro/steering/ 目录下，是你给 Kiro 的持久性项目知识——你的技术规范、命名约定、API 设计原则，以及任何"这个项目里我们怎么做事"的规则。Kiro 在每次生成代码时都会读取这些文件，你不需要在每次对话里重复解释项目背景。这和 Spec Kit 的"宪法"机制目的相同，但实现更轻量，Markdown 文件，放进去就生效。
Agent Hooks 是 Kiro 最有特色的功能。你可以用自然语言定义事件驱动的自动化规则，例如："每当 API 接口定义文件被修改时，自动检查测试是否需要更新"；"每次提交代码前，检查代码是否符合 design.md 里的架构约定"。这些规则像 GitHub Actions 一样运行，但在你的本地开发环境里，由 AI 执行。Agent Hooks 让规格不只是开始时写下的文档，而是贯穿整个开发过程的活性约束。
Kiro 的适用场景
Kiro 对愿意采用新 IDE 的团队来说是三款工具里体验最完整的——规格编写、审查、代码生成全部发生在同一个工作空间，没有工具切换的摩擦。对 AWS 生态有深度依赖的团队，也会发现 Kiro 的整合更顺手。
它也适合对 SDD 刚开始入门的学习者。相比 Spec Kit 需要理解 CLI 工具和目录结构，Kiro 的 IDE 界面更有引导性，一步一步带你完成规格的每个阶段。
权衡在于：Kiro 是一个独立的 IDE，意味着迁移成本比工具包类方案要高。如果你的团队已经深度使用某个 IDE，切换到 Kiro 需要认真评估。
三款工具的对比与选择
了解了这三款工具，我们来把它们放在一起比较一下：
| Spec Kit | OpenSpec | Kiro | |
|---|---|---|---|
| 发布方 | GitHub | Fission-AI（YC W2026） | AWS |
| 产品形态 | CLI + 模板工具包 | 轻量开源框架 | 完整 agentic IDE |
| 发布时间 | 2025 年 9 月 | 2025 年下半年 | 2025 年 7 月预览，11 月正式版 |
| 最适合 | 全新项目（greenfield） | 改动已有项目（brownfield） | 新项目或已有项目，AWS 生态团队 |
| 规格体量 | 约 800 行，信息全面 | 约 250 行，轻量精简 | 三文件结构，按需自动生成 |
| 核心机制 | 四阶段流程 + 宪法约束 | 三阶段状态机 + Delta 标记 | 三规格文件 + Agent Hooks |
| 工具集成 | Copilot、Claude Code、Gemini CLI | 支持 21 款 AI 编码工具 | 内建于 IDE 本身 |
| 变更管控 | 阶段性检查点 | 强制提案审批 | Hooks 可自动触发检查 |
| 规格动态性 | 静态，需手动更新 | 静态，需手动更新 | Hooks 可联动触发规格相关任务 |
从这张表里可以看出一些规律：Spec Kit 和 OpenSpec 都是工具包形态，规格文件完全静态，需要人来保持更新；Kiro 则通过 Agent Hooks 机制，让规格在某种程度上与开发过程保持联动。但 Kiro 的代价是迁移成本——你需要切换到一个新的 IDE。
在实际选择时，一个简单的判断框架是：如果你在起手式且在意引导体验，选 Kiro；如果你在起手式且不想换 IDE，选 Spec Kit；如果你在已有系统上继续迭代，选 OpenSpec。当然，这三者并不互斥，一个中大型项目完全可以在初始阶段用 Spec Kit 或 Kiro 建立规格体系，在后续持续迭代阶段用 OpenSpec 管理每一次变更提案。
SDD 是不是"回到了瀑布开发"
在社区里，有人批评 SDD 的思路和几十年前的"瀑布模型"如出一辙：先写完整需求，再开始开发，中间不允许改。这个批评值得认真回应。
我认为，SDD 和瀑布开发有一个本质的不同：代码的生成成本。
在瀑布时代，写需求规格要花几个月，但写代码也要花几个月。一旦需求写完了，很少有人愿意改，因为改需求意味着后续所有的开发工作都可能要重来。整个流程的代价，让它天然趋向"一次性规划到位"。
在 AI 编程时代，生成代码的成本无限接近于零。你改一个规格里的设计决策，让 AI 重新生成对应模块，可能只需要几分钟。规格的修改成本仍然是人类的思考成本，但实现的修改成本已经被 AI 大幅压缩。这意味着 SDD 并不要求你第一次就把规格写完美，它鼓励你快速迭代规格，再让代码跟上来。
这是一种螺旋上升，而不是从高处泼下来一桶水。
SDD 与 Vibe Coding 的关系
最后，有一点需要说清楚，避免误解：SDD 不是 Vibe Coding 的对立面，而是 Vibe Coding 的升级。
更准确地说，SDD 并不是要消灭"感觉"和"氛围"，而是要给它加上脚手架。你写规格的过程，本身就可以是一个 Vibe 的过程——你和 AI 闲聊你的想法，AI 帮你整理成结构化的文档，你调整、补充，来回几轮。只是在这个 Vibe 的过程结束时，你手里多了一份"已确认的规格"，而不只是一串转瞬即逝的对话记录。
从某种意义上说，SDD 是对 Vibe Coding 的一种馈赠：它让你不用放弃 AI 协作的流畅感，却能同时拥有传统工程的可控性。
小结
这一节，我们认识了 SDD（规范驱动开发）的核心思想：在 AI 开始动手之前，先把"想要什么"、"约束是什么"和"接受标准是什么"写清楚，让这份规格成为整个工程的唯一真相。
我们学习了 SDD 的四阶段工作流：规格 → 计划 → 任务 → 实现，以及每个阶段为什么都需要人类审查的检查点。
我们认识了三款主流的 SDD 工具。Spec Kit 是 GitHub 开源的四阶段流程工具包，适合全新项目，通过"宪法"机制确保技术决策的一致性。OpenSpec 是 Fission-AI 开源的提案审批框架（入选 YC W2026），适合存量代码库，用"意图版本控制"的方式记录每一次变更的来龙去脉。Kiro 是 AWS 推出的完整 agentic IDE，把 SDD 工作流内建进开发环境，通过 Agent Hooks 机制让规格在整个开发过程中持续发挥作用。
Spec Kit 和 OpenSpec 的规格都是静态的，需要人来保持更新。Kiro 的 Hooks 机制在一定程度上缩小了规格与实现之间的落差，但无论哪款工具，背后都坚守着同一个价值观：在 AI 越来越强大的时代，人类的审查和确认，是不该外包给自动化的事。
下一节，我们会把这一章学到的所有方法论放在一起——Vibe Coding、TDD、SDD——讨论如何根据项目类型、团队规模和任务特点，选择最适合的工作流组合。
练习
思考题 1：规格的颗粒度
回想一个你最近做过的小项目或者功能，试着用 SDD 的思维框架重新描述它：
- 你要构建的功能是什么（功能边界）？
- 技术约束是什么（技术栈、架构、性能要求）？
- 接受标准是什么（怎么判断实现是"对的"）？
你会发现，把这三个问题回答清楚，比你想象的要难。正是这种"难"，揭示了 Vibe Coding 模式下你通常在隐性假设些什么。
思考题 2：选择工具
下面几个场景，你认为更适合用 Spec Kit、OpenSpec 还是 Kiro？请说明理由：
- 你要从零开始开发一个个人博客系统，希望有工具引导你一步步完成规格
- 你要在已有的电商平台上增加"商品评论"功能
- 你要帮一个运行了三年的内部管理系统修复一个复杂的数据统计 Bug
- 你要搭建一个全新的数据分析仪表板给老板汇报用，团队深度使用 AWS 服务
实践题 3：动手写第一份规格
挑选一个小功能（比如"一个允许用户上传头像并显示的功能"），尝试用纯文字的方式写一份 SDD 规格：
- 先不借助任何工具，自己写一版
- 再把你的初稿贴给 Claude Code 或 Cursor，让 AI 帮你提问："我还没想清楚的地方有哪些？"
- 根据 AI 的追问，完善你的规格
完成后，对比第一版和最终版，你会直观感受到 AI 在"发现隐性假设"方面的价值。
讨论题 4：规格是中间产物还是最终产物
这一节提到，业界对"规格的地位"有两种不同观点：有人认为规格只是驱动代码生成的中间产物，代码才是唯一真相；也有人认为规格是最终真相，代码只是规格的编译产物。
你认为哪种观点更合理？在什么条件下，代码是真相？在什么条件下，规格更应该是真相？