Spec Coding (SDD) 完全指南：AI 编程的大规模工程化之路

TL;DR: 如果说 Vibe Coding 让你"跑得快"，那么 Spec Coding (Spec-Driven Development, SDD) 关心的是"跑得远"。它在 2026 年的核心论点是：在 AI 辅助的工作里，长期资产正从代码转向规格——那份被审查、被版本化、生成代码必须满足的文档。OpenSpec 是实践这一范式的一个流行、且不绑定具体工具的框架。本文讲清这个范式、走一遍工作流，并诚实地说明它保证什么、不保证什么。

引言：当"感觉"不再足够

在 2025 年，许多开发者报告 Vibe Coding 带来了显著提速。但随着项目规模增长，一组熟悉的问题也随之而来：逻辑散落在无数文件中、难以察觉的回归 Bug、以及越来越厚的 AI 生成技术债。

这份不安背后是有数据的。GitClear 2025 年的报告分析了 2.11 亿行改动代码（作者提交时间跨 2020–2024 年），发现"复制粘贴"的代码行从占改动的 8.3% 升至 12.3%（相对增长约 48%），而"移动"的代码——GitClear 用作重构的代理指标——从 2021 年占改动行的 25% 降到 2024 年的不足 10%。2024 年是复制粘贴首次超过移动代码的年份。（来源：GitClear《AI Copilot Code Quality 2025》；数据为 2020–2024 年口径。）

仔细看，这是代码如何被改动的趋势，而非对质量的直接测量——但它与很多团队的体感吻合。Spec Coding（规格驱动开发） 是一种回应：不是给 AI 踩刹车，而是给它的产出装上铁轨。

什么是 Spec Coding？

核心思想：规格是首要产物

这一框定在近期文献中已有表述——例如一篇 2026 年的预印本《Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants》（arXiv，投稿至 AIware 会议）主张把规格当作首要产物，代码作为被生成或被验证的次级产出。这是一种正在被讨论的研究框定，而非既定的行业标准——但它把这一转变刻画得很到位。

在这一范式中，程序员的工作重点从"手写逻辑"转向**"编写、审查和维护规格说明书"**。

三个核心原则

1. 单一事实来源 (SSOT)：规格文档是需求的合法定义，代码应与规格对齐。
2. 约束驱动 (Constraint-Driven)：AI 在规格设定的边界内创作，而非自由即兴发挥。
3. 可回溯性 (Traceability)：理想情况下，生成的代码能追溯到规格中的具体条款——这正是让审查和审计变得可行的关键。

这些是方法所优化的目标，不是白拿的保证。可回溯性只在你持续保持规格与代码同步时才成立；规格不会自我执行。

OpenSpec：一个流行且不绑定工具的框架

OpenSpec 是 Fission-AI 推出的开源框架（MIT 协议），它把 SDD 原则落地为可操作的工具链。其声明的核心哲学：

→ fluid not rigid        （流动，而非僵化）
→ iterative not waterfall （迭代，而非瀑布）
→ easy not complex        （简单，而非复杂）
→ built for brownfield    （适用于已有项目）
→ scalable from personal projects to enterprises （从个人到企业可扩展）

为什么要一个规格层？ AI 编程助手很能干，但当需求的唯一记录是聊天历史时，结果不可预测。OpenSpec 添加了一个轻量级规格层，确保在写代码之前先对要做什么达成共识。

快速安装：

npm install -g @fission-ai/openspec@latest
cd your-project
openspec init

（依据 2026-07 的 OpenSpec README 核验；opsx: 命令命名空间是当前版本，取代了更早的 CLI 形式。命令名和安装细节可能随版本变化，请以 README 为准。）

Spec Coding 的核心工作流 (SDD Workflow)

SDD 将开发拆分为若干清晰阶段，形成一个以审查为中心的闭环。在 OpenSpec 中，这个闭环的核心通过几条斜杠命令运行：

1. 定义规格 — /opsx:propose

使用 /opsx:propose "你的想法" 启动一个新变更。OpenSpec 会生成一组制品：

2. 审查制品

你审查 AI 生成的制品，确认理解准确。OpenSpec 没有僵化的阶段门——你可以随时修改任何制品。这一审查步骤正是该方法价值所在；跳过它，"规格驱动"就退回成了"氛围驱动"。

3. 逐任务执行 — /opsx:apply

AI Agent 按 tasks.md 中的清单逐任务执行，每次只读取一个任务及其相关的规格上下文。收窄上下文往往能减少跑偏和幻觉——更小、更锋利的 Prompt 给模型编造的空间更少——但这并不能消除错误，所以测试与审查仍然适用。

4. 验证对齐

通过自动化测试和规格比对，确认产出物是否符合第一步定义的验收标准。注意那个常见陷阱：生成的测试可能通过，却在断言错误的东西，所以要读关键路径上的断言。

5. 归档变更 — /opsx:archive

将已完成的变更归档到 openspec/changes/archive/ 目录，附上时间戳，让决策以可读记录的形式留存，而不是随会话蒸发。

Vibe Coding vs. Spec Coding：对比

二者是互补的。一种常见做法：先用氛围探索一个功能，等它值得保留时，再写规格并对照重新生成。

竞品对比：OpenSpec vs. Spec Kit vs. Kiro

（定位与能力为 2026 年中口径；三者都在快速演进，标准化选型前请重新核实。）

一个值得纠正的说法：Kiro 常被描述为"只能用 Claude"，但到 2026 年中，它已通过 Amazon Bedrock 提供多种模型，包括非 Claude 选项。选型请依据它与你技术栈的契合度，而不是一句过时的概括。

SDD 在哪里有帮助——又在哪里没有

1. 降低（而非治愈）歧义

许多 AI 错误源于上下文模糊。一份精确的规格会收窄模型的推理路径，配合小步执行，往往能提高可用产出的命中率。它并不保证正确性——网上看到的任何具体"成功率"百分比，如果不附带可复现的方法论，都值得怀疑。诚实的说法是定性的：输入更锋利、明显的失误更少、验证依然是必须的。

2. 知识的持久化

在纯 Vibe Coding 中，项目知识存在于易逝的对话历史里。在 SDD 中，它存在于 specs/ 目录和归档中。换一个 AI 模型，新模型也能通过阅读规格快速进入状态——这是一个真实、实用的好处。

3. 日渐成熟的工具生态

OpenSpec 的文档列出支持 20+ 主流 AI 编程助手（Cursor、Claude Code、Windsurf、Copilot、Trae 等）；GitHub 发布了 Spec Kit；AWS 发布了 Kiro。多个独立厂商向规格驱动工作流收敛，本身就是这一模式有生命力的信号。

4. 合规与可审计性

对于金融、医疗等受监管领域，一份被维护的"规格-代码"映射是审计的有力辅助——它给审查者一条从需求到实现的可追溯链路。它是合规的强力工具，虽然并非团队满足审计要求的唯一途径。

结语：从"写代码"到"编规格"

Spec Coding 把工程师的角色从"每一行的作者"重新框定为"代码必须满足的规格的作者"。判断力并没有消失——它集中到了规格和审查里。像 OpenSpec 这样的框架用几条命令就让这个模式变得可用，但真正让它奏效的纪律，是你装不上的那部分：写清晰的规格，并真的去审查 Agent 产出的东西。

想看它如何端到端落地？请阅读实战篇：Spec Coding 实战：用 OpenSpec 构建生产级 AI 开发流。

相关阅读：

• Vibe Coding 实战指南：从 Cursor 到 Claude Code
• MCP 协议完全指南：连接 AI 与现实世界的桥梁
• Harness Engineering: AI 时代的工程范式