[AI/软件工程学/开发模式] Spec-Driven Development : (文档)规约驱动开发

1 Spec-Driven Development : (文档)规约驱动开发

定义

  • 阿里巴巴等公司（连同 GitHub、AWS 等）近一年在推的【规约驱动开发】，就是 Spec-Driven Development（SDD）—— 把 "规格说明（Specification）" 当作唯一真理源，先写清楚 "做什么、为什么做、做到什么程度算完"，再让 AI 去实现 "怎么做"；代码、测试、文档都从规格派生。

它本质上是为 AI 编程时代重新设计的一套 "人机工程契约"。
规格（Specification）是唯一真理源，代码、测试、文档都是它的派生产物 —— 人定义 WHAT，AI 实现 HOW。
作为2025–2026 年 AI 编程领域最热的方法论之一，阿里巴巴（淘系/阿里云/Qoder）是主要推动者之一

它到底是怎么来的

  • SDD 不是某个公司 "发明" 的新名词，而是 2025 年多个方向同时收敛的结果。触发点是 Karpathy 2025 年 2 月提出的 Vibe Coding——"忘掉代码，只凭感觉描述需求，让 AI 全权处理"。它做个人原型效率极高，但社区很快发现一个规律：项目进入第 3-9 个月就会出现 "三个月墙"——AI 上下文窗口装不下全部代码，开始基于局部信息做决策，新功能不断破坏旧功能，代码没人能维护。

  • 随后各方几乎同时给出了同一个答案：GitHub 于 2025 年 8 月开源 Spec Kit（三文件体系 + constitution，支持 Copilot/Claude/Gemini），AWS 推出内置 SDD 工作流的 IDE Kiro，Fission-AI 走轻量路线的 OpenSpec，而 阿里巴巴把这条路径在企业级落地推到了极致—— 淘系技术团队、阿里云 Qoder、通义灵码都在推。

  • 推荐文献

在SDD方面，阿里巴巴具体做了什么

  • 淘特导购团队（2025.12）：发布了《AI 编码实践：从 Vibe Coding 到 SDD》，完整复盘了 "代码补全 → Agent Coding → Rules 约束 → SDD（SpecKit）" 的演进路径，也诚实承认 SDD 落地门槛高、工具链不成熟、历史代码难集成，最终采用 "轻量技术方案模板 + Rules + Agent Coding" 的融合策略。

AI编码实践：从Vibe Coding到SDD - CSDN 2025.12

  • 阿里云 QoderWork（2026.05）："5 人 7 天开发 QoderWork" 案例 ——DAY 0 不写一行代码、全员写 Spec，DAY 1-6 由 Qoder Quest 并行执行，AI 自动写代码提 PR、人只做 Review，完成传统 20 人数周的活。阿里技术

5 人 7 天干完 20 人数周的活：Spec-Driven Development 如何重新定义 AI 编程 - 腾讯新闻/阿里技术 2026.05

  • 通义灵码 Lingma Qoder：上线了官方 "Spec 驱动模式"，流程为需求澄清 → 生成 Spec（需求描述 / 设计方案 / 任务拆分）→ 执行。阿里云帮助中心

Spec 驱动模式 - 阿里云 2026.05

  • 集团层面：MPD 2026 大会开设专题《从 vibe coding 到 spec coding》，出品人是阿里 AI Code Review 负责人李峥峰和阿里平台技术部总监许晓斌，阿里云开发者社区同期涌现大量 SDD 工程实践文章，有文章直接以 "氛围编程走远，规格驱动开发降临" 为题。MPD阿里云开发者社区

氛围编程走远，规格驱动开发降临 - 阿里云/开发者社区 2025.11

为什么现在火：一条清晰的演进时间线

  • 2025.02 Vibe Coding（Karpathy）走红："忘掉代码"，自然语言驱动。原型快，但暴露"三个月墙"
  • 2025.08 GitHub 开源 Spec Kit：三文件体系 + constitution，把 SDD 变成可落地工具链
  • 2025 底 阿里淘系发布实践文章：从代码补全→Agent Coding→Rules→SDD（SpecKit）
  • 2026.05 阿里 QoderWork 案例："5 人 7 天完成 20 人数周的活"，SDD 规模化执行
  • 2026 MPD 大会专题"从 Vibe Coding 到 Spec Coding"（阿里李峥峰/许晓斌出品），上升为集团级研发方向

SDD 怎么做：四阶段流程与人机分工 | 仓库里的"文件宪法"（GitHub Spec Kit / SpecKit 体系）（必读）

SDD 的标准流程是 Specify → Plan → Implement → Validate 四阶段（实践派还会拆出 Clarify 澄清、Tasks 任务化，形成七阶段模型）阿里云开发者社区。配套的文件体系是关键：

  • constitution.md 项目宪法

主导：人（架构师）
不可变原则：技术栈、编码规范、安全约束、质量标准。把团队决策固化成 AI 的"潜意识"，跨版本长期有效

  • spec.md 需求规格/规格定义

主导：人
唯一真理源、只写"做什么"，不写具体技术。
好 Spec 的六要素：问题陈述、成功指标/成功标准、用户故事、验收标准、Non-Goals、边界/约束。
判断粒度有个经典检验："换一个技术栈实现，这份 Spec 是否仍然成立？" 成立 = 合格的 WHAT；不成立 = 你把 HOW 混进去了。

  • plan.md 技术方案/方案规划

主导：人 + AI
架构选型、模块划分、接口契约；AI 起草、人审核修改
把 spec 翻译成架构、API、表结构、技术选型。粒度检验：换技术栈后 spec 仍成立 = 没把 HOW 混进 WHAT

  • tasks.md 任务清单/代码实现

主导：AI
拆成可独立验证的原子任务，每任务只改 1–2 个文件、有明确验收方式，AI 逐个执行
按 tasks.md 逐任务实现：写代码、写测试、跑编译、自纠错、提交 PR，人只做 Review

  • Validate/验证确认

主导：人 + AI
对照 spec 逐条验收 + 回归测试 + 人工审查；不通过则回退到 Clarify 或 Plan

为什么必须换范式：Vibe Coding 撞上"三个月墙"

  • Vibe Coding（无约束）
  • AI 靠上下文猜测意图，项目一大就乱
  • 无文档、无边界，代码"复制粘贴式"膨胀
  • Veracode 2025：无 Spec 约束时 45% AI 生成代码含安全漏洞
  • 代码重复率 4 年增长 4 倍（GitClear）
  • 天花板：1–3 个月兴奋期后进入维护崩溃
  • SDD（规格约束）
  • Spec 是代码的"压缩表示"，AI 读完即懂全局
  • 人工精炼 Spec 使 LLM 代码错误减少 ~50%
  • API 变更周期缩短 75%（arXiv 金融实践）
  • Stripe 用 Harness/SDD 交付 1,300 个 AI PR 未失控
  • Microsoft 点评："SDD is version control for your thinking"

生态与演化方向

  • 工具生态

GitHub Spec Kit（通用框架）
OpenSpec（轻量迭代）
AWS Kiro（内置 SDD 的 IDE）
阿里 QoderWork/通义灵码 Spec 模式
Tessl

  • 三级光谱

L1 Spec-First（先写后写码，主流）
→ L2 Spec-Anchored（测试锚定一致性）
→ L3 Spec-as-Source（人只编辑 Spec，代码像"编译"一样生成）

  • 已知陷阱

过度规格化（退化成伪代码）
规格腐烂（Spec 与代码脱节）
规格官僚化（改按钮也要全流程）
虚假信心（Spec 不能替代 Code Review）
工具过度复杂

效果与争议（客观视角）

  • 支持方的数据：人工精炼 Spec 可使 LLM 代码错误减少约 50%；金融领域 API 变更周期缩短 75%；Stripe 用该方法交付了 1,300 个 AI PR 而未失控。

  • 反对与陷阱：它被批评为 "Markdown 版的瀑布模型"；实践中最常见的坑是过度规格化（退化成伪代码）、规格腐烂（Spec 与代码脱节）、规格官僚化（改个按钮也走全流程）、以及虚假信心（Spec 替代不了 Code Review）。

Thoughtworks 技术雷达 2025 年底把 SDD 放在 "值得研究" 的 Assess 环。

  • 我的判断：SDD 本质是 API-First、Design by Contract、TDD 这些老方法在 AI 时代的重述，不是什么玄学。

它对中大型、多人协作、需要长期维护的项目价值明显 —— 因为 AI 写代码已经足够快，瓶颈从 "怎么写" 变成了 "写之前有没有讲清楚"。
对个人探索型小项目，直接 Vibe Coding 仍然更划算，不必为了 SDD 而 SDD。

SDD驱动开发的关联开源项目（必读）

核心 SDD 框架（“五框架”中的主力）

  • GitHub Spec Kit | ⭐ 134k | MIT Lic

https://github.com/github/spec-kit
agent 无关的 CLI，三文件体系 + constitution，通用性最强、star 最高

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z
specify init my-project --integration copilot
cd my-project
specify extension add bug
  • OpenSpec | ⭐ 67.8k（半年 +863%，增长最快） | MIT Lic

https://github.com/Fission-AI/OpenSpec
轻量迭代路线，spec delta 增量审查，适合中小项目与个人

image

npm install -g @fission-ai/openspec@latest

cd your-project
openspec init
    /opsx:propose "your idea"
    ...

openspec view

image

image

  • 核心理念
→ 流体而非刚性  
→ 迭代式而非瀑布式  
→ 简单而非复杂  
→ 专为现有项目而建，而非仅限于新项目  
→ 可从个人项目扩展至企业级应用
  • BMAD-METHOD | 多角色 Agent 框架（最重） | ⭐ 52.8k | 基于 MIT Lic，但有调整

https://github.com/bmad-code-org/BMAD-METHOD
Brainstorm/Architect/Dev 等角色模拟团队，适合中大型、长期项目

image

npx skills add bmad-code-org/BMAD-METHOD
或: codex plugin marketplace add bmad-code-org/bmad-plugins
  • Task Master/任务编排引擎（增速放缓 +18%）| ⭐ 28.1k

https://github.com/eyaltoledano/claude-task-master
PRD → 依赖任务图 → 执行验证；商业化转向后增长失速

claude mcp add taskmaster-ai -- npx -y task-master-ai

相邻生态（不是纯 SDD，但解决同一问题）

  • Superpowers | ⭐ 284k

https://github.com/obra/superpowers 、
Superpowers 是一套完整的软件开发方法论，适用于您的Coding Agent，它建立在一组可组合的技能和一些初始指令之上，以确保您的代理能够使用这些技能和指令。
Claude Code skills 库：强制 TDD、头脑风暴、子 agent 分治，“给 AI 上工程纪律”

image
image

  • GSD / get-shit-done | ⭐ 64.6k

https://github.com/gsd-build/get-shit-done
meta-prompting + context engineering，执行优先的另一极
注意： 2026.06.27 已停止维护

  • cc-sdd / codex-spec

gotalab/cc-sdd（~12K⭐）· shenli/codex-spec（~8K⭐）
面向 Claude Code / Codex CLI 的社区轻量 SDD 工具

  • SDD-Research_Agent

github.com/NyaRu-Kiss/SDD-Research_Agent
阿里云社区《SDD 工程法实战》配套源码，七阶段流程的参考实现

基于SDD模式的开发项目

  • SSD-Research Agent

https://github.com/NyaRu-Kiss/SDD-Research_Agent
Research Agent 是一个面向复杂问题的研究型智能体应用。用户提交研究任务后，系统会生成研究计划和待回答问题，调用模型与外部检索/网页阅读服务收集资料，整理可追溯的证据并生成研究报告。任务的状态、进度、来源、证据、执行 trace 和报告都可以通过 Web 界面、HTTP API 或 CLI 查看和干预。
项目采用前后端分离架构：后端负责任务编排、持久化和外部服务调用，前端负责任务列表、详情、计划编辑、实时进度和执行 trace 展示。研究执行使用 LangGraph，检查点与业务数据统一存储在 PostgreSQL 中。

https://gitee.com/hezoo/yxai/blob/master/SPEC.md
此项目不完全算是 SSD 驱动开发的项目。

总结

  1. 是啥：规约驱动开发（SDD）就是 "先写清规格、再让 AI 写代码"—— 规格是唯一真理源，代码只是它的派生产物，人定义 WHAT、AI 实现 HOW。

  2. 为啥火：Vibe Coding 在个人项目里好用，但在大项目里会撞 "三个月墙"（代码失控、无文档、重复率暴涨），SDD 是业界给出的约束方案，2025 年下半年 GitHub/AWS/ 阿里几乎同时发力，阿里是把它推到企业级落地最狠的一家（淘系 SpecKit、QoderWork "5 人 7 天"、通义灵码 Spec 模式、MPD 大会专题）。

  3. 值得知道：它不玄学，就是老方法（TDD/Design by Contract）的 AI 时代重述；但落地时最常见的坑是 Spec 写得太细（变伪代码）、Spec 和代码脱节（规格腐烂）、以及以为有了 Spec 就不用 Review 了。

Y 推荐文献

X 参考文献

posted @ 2026-09-10 12:24  数据知音  阅读(66)  评论(0)    收藏  举报