SDD：规格驱动开发

SDD（Spec-Driven Development，规格驱动开发，中文也常被通俗称作"规范驱动开发"）是本系列的核心主线。它主张：AI 动笔写代码之前，必须先理解并遵循一份明确的"规格说明书"。

一、为什么需要 SDD

传统的 AI 代码生成，依赖模型对自然语言的概率性理解，本质是一场"猜谜游戏"。简单任务尚可，但面对需长期维护的复杂项目，它的不可预测、风格不一致、潜在漏洞就成了致命短板。

SDD 借鉴了传统软件工程"设计先行"的思想：

先把事情写清楚，再让 AI 和代码围着这份"写清楚的东西"去执行。

一句更接地气的话：AI 时代真正该先写的，往往不是代码，而是规格。

二、Spec 到底是什么

Spec 是 Specification 的缩写。它不是"随手写两句说明"，而是对以下内容的结构化表达：

• 需求目标
• 业务边界
• 异常流程
• 验收标准
• 技术约束

如果说 TDD 关注"代码行为是否正确"，那 SDD 关注的是"我们到底要构建什么"。

三、SDD 解决的核心问题

在没有 SDD 时，需求边界往往散落在：聊天记录、脑海记忆、Jira 描述、会议纪要、PR 评论里。这正是 AI 在复杂项目里最容易出问题的地方——对代理来说，看不见 = 不存在。

SDD 做的事：

• 让需求不再只存在于对话里；
• 让规格成为仓库里的资产；
• 让多人、多轮、多代理共享同一份意图；
• 让代码、测试、文档围绕同一份规格演化。

其本质一句话：先定义意图，再让代码围绕意图生长。

四、常见误区：SDD ≠ 瀑布 + 厚文档

很多团队一听"规格驱动"就想到厚厚的文档、低效审批。这恰恰是 AI 时代最该避免的误解。今天好的 SDD 形态是：

• 轻量：不是写几十页，而是把最容易返工的决定提前说清楚；
• 结构化：机器可解析；
• 和代码库一起版本化：spec 进仓库；
• 人与代理都能读。

五、三大落地框架（"三剑客"）

SDD 是理念，真正把理念落地的，是下面这些工具。它们设计哲学迥异：

工具	核心定位	最大优势	适合场景	是否开源
Spec Kit（GitHub）	企业级规范治理工具链	有"项目宪法"，强制 AI 守规矩	团队协作、标准化、合规要求高	✅ 开源
OpenSpec	棕地（存量）项目安全迭代框架	变更可审计、隔离，不破坏老代码	维护遗留系统、风险控制	✅ 开源
Kiro（AWS）	代理式 IDE，快速原型神器	自动化钩子，全程近乎不用手动操作	个人 / 小团队、快速迭代、UI 原型	IDE 本体非开源

补充：社区里还有 Tessl 等平台也在推 SDD 理念，主张"规格即源码"。三者共同指向同一未来：AI 编码不再是黑盒魔法，而是可预测、可管理的工程能力。

三剑客工作流差异（以"加一个用户过滤搜索"为例）

Spec Kit：/speckit.specify → (澄清对话) → /speckit.implement → /speckit.analyze
           产 spec.md，"宪法"强制包含单元测试；流程严谨、产出可靠，但环节较多。

Kiro：    自然语言对话 → Claude 生成任务规划 → /kiro:generate → 自动触发 lint/test
           对话驱动、自动化程度高，速度极快，团队规范约束相对宽松。

OpenSpec：/openspec:proposal → /openspec:review → /openspec:apply（隔离目录）→ archive
           先出"变更提案 + Delta"，审查通过才生成，变更隔离、可审计，最安全。

六、环境搭建与最小示例

下面给出两个开源框架的安装与初始化命令（命令来自各自官方文档；因需联网拉取仓库与依赖，请在本地终端执行，本教程不代跑其控制台输出）。

1. Spec Kit + AI 编码代理

前置：已安装 Python 与 uv。

# 环境：PowerShell / 终端
pip install uv
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

初始化一个项目并选择所用的 AI 工具（如 claude）：

mkdir my-app; cd my-app
specify init my-app --ai claude

初始化成功后，项目里会出现 .specify/ 目录（含 spec / plan / tasks 模板）。随后在 AI 编码助手的对话框里，用 /speckit.constitution、/speckit.specify、/speckit.plan、/speckit.tasks、/speckit.implement 等系列斜杠命令，按"宪法 → 规格 → 计划 → 任务 → 实现"推进。

🕳️ 你可能会遇到的坑：uv tool install ... --from git+... 依赖能访问 GitHub。若公司网络代理受限，可改用 pip install specify-cli，或先镜像仓库再本地安装。装完在终端里敲 specify --help 能列出子命令，才算装好。

2. OpenSpec

前置：Node.js ≥ 20。

# 环境：PowerShell / 终端
npm install -g @fission-ai/openspec@latest

在一个已有项目里初始化：

cd my-project
openspec init

之后用 /openspec:proposal、/openspec:review、/openspec:apply、openspec archive 等命令，按"提案 → 审查 → 隔离生成 → 归档合并"推进。OpenSpec 每次变更会留下几类结构化中间产物：

• proposal.md：为什么要改
• design.md：准备怎么改
• tasks.md：拆成哪些执行步骤
• spec delta：相对旧系统，这次需求到底变了什么

3. Kiro

从官方下载安装 Kiro IDE，在其中装好 AI 编码代理插件，导入项目规则文件（steering / hooks 配置），即可用自然语言对话驱动"规划 → 生成 → 自动 lint/test"的流程。

七、选型建议

场景	推荐	理由
企业级项目、多人协作	Spec Kit	有"宪法"治理，确保 AI 产出符合规范
快速原型、小团队迭代	Kiro	自动化程度高，聊天交互效率最高
维护老项目、风险控制	OpenSpec	变更隔离、可审计，不破坏现有代码
混合（原型 + 维护）	Kiro + OpenSpec	用 Kiro 做原型，用 OpenSpec 安全合并回主线

八、本章小结

• SDD = 先把需求 / 边界 / 验收标准写成结构化规格，再驱动 AI 实现、测试与评审。
• 它补的是 Vibe Coding 的"边界漂移"和 TDD 的"不定义意图"两块短板。
• 落地三剑客：Spec Kit（治理）、OpenSpec（安全迭代）、Kiro（快速原型）。

九、下一步

• 继续阅读：人机协作与工作流，看规格之后如何把执行也工程化。