第 10 章 Spec-Driven Development：从访谈到验收

全面讲解 Spec-Driven Development 的八步法、采访提示、SPEC 模板、任务树、变更控制与常见失败模式等实战实践、交付方法与技巧。

Spec-Driven Development 的核心不是多写一份文档，而是让需求、实现、测试、评审和回滚围绕同一份可版本化事实源。

10.1 为什么 Agent 时代更需要 Spec

• Agent 执行速度变快，模糊需求造成的返工和错误也会更快放大。
• 多个会话、工具和人并行时，聊天历史无法充当稳定合同。
• Spec 把目标、非目标、数据、接口、权限、验收、风险和决策固定下来。
• 验证失败时，可以判断是实现错误、规格错误还是环境错误。
• 完成后，Spec 可继续支撑回归、发布说明、培训和后续迭代。

10.2 一套可复制的八步法

1. 先采访：让 Agent 一次提出 5–10 个高价值问题，不立刻实现。
2. 最小研究：读取现有代码、官方文档、竞品、限制和历史决策。
3. 写 Spec：明确目标、非目标、角色、流程、数据、权限、接口和验收。
4. 做决策：将未决项、备选方案、owner 和截止时间显式化。
5. 拆任务树：按里程碑、依赖、可写范围、验证与合并顺序拆分。
6. 新会话实施：从干净的 Spec 与仓库状态开始；复杂任务使用 worktree。
7. 持续回填：每个需求标记 Not started / Implemented / Verified / Blocked / Changed。
8. 收尾：回归、发布、回滚、文档和规则沉淀；记录规格偏差。

10.3 采访式起手提示

PM / 创业者 / 程序员通用：

我想做【功能 / 产品】。先不要给方案或写代码，请采访我。
一次提出不超过 10 个最关键问题，至少覆盖：
- 目标用户与核心场景
- 业务成功标准与技术成功标准
- 非目标范围
- 现有系统、数据与依赖
- 角色、权限与敏感数据
- 正常、异常、空数据和边界流程
- 时间、成本与上线限制
- 最大风险与回滚要求

收到回答后，先列：已确认事实 / 假设 / 待决策，
再生成 SPEC.md 草案和验收清单。

10.4 SPEC.md 最小模板

最小但可执行的 SPEC：

# 1. 背景与问题
为什么做？解决谁的什么问题？

# 2. 目标与成功标准
- 业务目标
- 用户目标
- 技术目标
- 可测量成功标准

# 3. 非目标
本次明确不做什么。

# 4. 角色与用户流程
角色、入口、主流程、异常流程。

# 5. 功能需求
FR-1 ...
FR-2 ...

# 6. 数据、接口与权限
输入 / 输出 / 数据模型 / 外部依赖 / 鉴权 / 审计。

# 7. 验收标准
Given / When / Then；正常、空、错误、权限、性能。

# 8. 风险、回滚与监控
风险、降级、回滚、发布后观察指标。

# 9. 任务树与状态
里程碑、owner、依赖、验证、状态。

# 10. 决策记录
日期、决策、理由、备选、影响。

10.5 Spec、规则与 Skill 的边界

10.6 从 Spec 到多 Agent 任务树

10.7 Spec 变更控制

• 实现中发现新需求，不要直接扩大代码范围；先写变更、影响和是否本期处理。
• 验收标准改变时记录决策日期、提出人、原因和对已完成工作的影响。
• Agent 发现规格冲突时应停止对应部分并标记 Needs decision，而不是自行选择。
• 发布后将实际行为、已知限制和监控结果回填，避免 Spec 成为过时理想状态。

10.8 最常见的失败模式