5 人 7 天干完 20 人数周的活：Spec-Driven Development 如何重新定义 AI 编程
原文链接5 人 7 天干完 20 人数周的活：Spec-Driven Development 如何重新定义 AI 编程
原文链接：https://mp.weixin.qq.com/s/hVizUucsy8rwFOUR-VZ6wA 作者：王砚舒（彦纾），阿里云开发者 发布时间：2026-05-09
摘要
一篇关于 Spec-Driven Development（SDD）的深度长文。核心理念：人定义 WHAT，AI 实现 HOW——将 Spec 作为唯一真实来源，代码是其派生产物。案例：5 人 7 天用 Qoder 开发 QoderWork，完成传统 20 人数周的工作量。文章覆盖 SDD 完整流程、Spec 写作方法论、工具生态、实战数据、vs Vibe Coding 对比、五大陷阱、三级光谱演进。
核心案例："5 人 7 天"时间线
| 时间 | 阶段 | 关键动作 |
|---|---|---|
| DAY 0 | 只写 Spec | 定义 MVP 边界、拆解模块、撰写 Spec、汇入 Repo Wiki。零行代码 |
| DAY 1-2 | 架构开发 | Skill 驱动并行推进，Quest 模式多任务同时执行，系统骨架成型 |
| DAY 3-4 | 增量迭代 | 发现需求/BUG → 立即写增量 Spec → Quest 执行 → 人 Review PR |
| DAY 5-6 | Dogfooding | 用 QoderWork 早期版本测试自身，正反馈循环 |
| DAY 7 | 发布上线 | — |
关键启示：真正的关键手在 DAY 0——花一整天写 Spec，看似什么都没做，实则把人类思考固化为导航系统，决定了后面六天的一切。
SDD 的起源：多方同时收敛
2025 年多个方向同时收敛到这个理念：
- Karpathy 的 Vibe Coding（2025.2.2）作为反面参照，暴露了"不管代码只管 vibes"的问题
- GitHub Spec Kit：agent-agnostic 的 SDD 工具链
- AWS Kiro：首个内置 SDD 工作流的 IDE
- Fission-AI OpenSpec：轻量迭代路线
- 阿里 QoderWork：Quest 模式实践 SDD 规模化执行
这不是某个团队的灵光一闪，而是 AI 编程发展到当前阶段的结构性需求。
Microsoft 的评价："SDD is version control for your thinking."——传统版本控制管代码演变，SDD 管思考的演变历史。
SDD 四阶段模型
Specify（规格定义）→ Plan（方案规划）→ Implement（代码实现）→ Validate（验证确认）
| 阶段 | 主导者 | 核心产出 | 关键动作 |
|---|---|---|---|
| Specify | 人 | spec.md | 定义问题、边界、成功标准 |
| Plan | 人 + AI | plan.md | 架构选型、模块划分、接口定义 |
| Implement | AI | 代码 + 测试 | 按 plan 逐任务实现 |
| Validate | 人 + AI | 测试报告 | 自动化测试 + 人工 Review |
核心原则：人定义 WHAT，AI 实现 HOW。
三文件体系（Spec Kit 核心设计）
spec.md — 需求规格（唯一真实来源）
回答"做什么"和"为什么做"，不涉及"怎么做"。六要素：
- Problem Statement：定义为什么做
- Success Metrics：可测试的成功标准（如"P95 < 50ms"而非"系统应该很快"）
- User Stories：谁在什么场景下用
- Acceptance Criteria：怎么验证
- Non-Goals：明确"什么不做"
- Constraints：技术约束
plan.md — 架构方案
基于 spec.md 生成，AI 起草、人审核修改。包含架构决策、模块划分、接口契约、风险评估。
tasks.md — 任务清单
原子任务拆解，每个任务对应可独立验证的交付物。
constitution.md — 不可变的项目原则
项目级"宪法"，所有 Spec 必须遵守：API 设计规范、安全约束、代码质量标准、基础设施规范。价值：把团队技术决策固化为 AI 的"潜意识"。
好 Spec vs 坏 Spec
坏 Spec： "系统需要一个快速的搜索功能。搜索结果应该相关且准确。界面要美观易用。"——模糊、遗漏边界、缺乏理由、混入 HOW。
好 Spec： "搜索 API 响应 P95 < 200ms，Top-5 相关性准确率 > 85%，支持中英文混合查询。不实现语义搜索，不支持附件内容。"——可测试、边界清晰。
粒度检验标准： "用不同技术栈实现这个 Spec，Spec 是否仍然有效？"如果换了底层实现（Redis ↔ PostgreSQL）Spec 就失效，说明混入了 HOW。
实战经验： 淘特团队发现 Spec 需要 3-5 次迭代才合格。这看似低效，实则把传统开发中"开发到一半发现需求有问题"的代价前移到了成本最低的阶段。
工具生态
| 工具 | 定位 | 核心特点 | 适用场景 |
|---|---|---|---|
| Spec Kit (GitHub) | Agent-agnostic 框架 | 三文件体系 + constitution | 通用项目 |
| OpenSpec (Fission-AI) | 轻量迭代工具 | 在对话中迭代完善 Spec | 小型快速迭代 |
| Kiro (AWS) | SDD-native IDE | 完整 IDE 集成 | AWS 生态 |
| QoderWork (阿里) | Quest 执行引擎 | Spec + Quest 并行执行 | 阿里生态 |
实战数据
成功
- API 变更周期缩短 75%
- 人工精炼 Spec 可减少 LLM 代码错误 50%
- Stripe 通过 Harness Engineering（含 SDD）交付 1,300 个 AI PR，没有引发系统性问题
警示
- 无 Spec 约束时，45% 的 AI 生成代码含安全漏洞（Veracode 2025）
- AI 编程时代代码重复率 4 年增长 4 倍（GitClear，2.11 亿行代码）
SDD vs Vibe Coding
Vibe Coding（Karpathy 2025.2.2）：用自然语言描述需求，让 AI 全权处理，不要读代码。
| 维度 | Vibe Coding | SDD |
|---|---|---|
| 核心假设 | AI 能理解你的意图 | AI 需要明确规格才能正确执行 |
| 启动速度 | 极快 | 较慢（需先写 Spec） |
| 可维护性 | 差 | 好（Spec 即文档） |
| 安全性 | 差（45% 漏洞率） | 较好 |
| 适用规模 | 小项目（< 1000 行） | 中大型项目 |
| 天花板 | 三个月墙 | 取决于 Spec 体系质量 |
"三个月墙"： 兴奋期 1-3 月（高产出）→ 平台期 4-9 月（新功能破坏旧功能）→ 衰退期 10-15 月（代码无人能维护，不如重写）。
根本原因：Vibe Coding 是零上下文的编程。项目膨胀后 AI 装不下全貌，开始基于局部信息做决策。SDD 的 Spec 是代码的压缩表示——10 万行代码的项目，Spec 可能只有几千行。
务实策略（混合）： 探索阶段用 Vibe Coding 快速试错 → 决定做就立刻补 Spec → 正式开发严格 SDD。
五大陷阱
- 过度规格化：Spec 比代码还长，退化为"用自然语言写伪代码"
- 规格腐烂：代码迭代十几个版本，Spec 还停在 V1
- 规格官僚化：改个按钮颜色也走全流程
- 虚假信心：有 Spec 就放松代码审查——Spec 替代的是需求文档，不是 Code Review
- 工具复杂性：为做好 SDD 引入过多工具链
回应"SDD 是瀑布模型"批评
批评有一定道理，但结论错误：
- SDD 的 Spec 是活的，不是死的——随时可增量更新
- 迭代粒度是单个功能模块，不是整个项目
- Spec 从编写到被 AI 实现可能只需几小时/几分钟
存在瀑布化风险，但这是实践问题不是方法论问题。
SDD 三级光谱演进
| 级别 | 名称 | 状态 | 特征 |
|---|---|---|---|
| L1 | Spec-First | 当前主流 | 编码前写 Spec，但可能漂移 |
| L2 | Spec-Anchored | 先进实践 | Spec 和代码持续同步，测试强制执行一致性 |
| L3 | Spec-as-Source | 未来愿景 | 人只编辑 Spec，代码完全由 AI 生成和维护 |
核心结论
SDD 的本质价值：它不让 AI 变聪明，它让 AI 变可控。 当 AI 越来越强大时，真正需要操心的是能不能驾驭它。答案：把精力放在定义 WHAT——因为 WHAT 永远是人类的领地。