---
title: 第 10 章 Spec-Driven Development：从访谈到验收
seo:
  title: "Spec-Driven Development 实战指南"
description: "全面讲解 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 / 创业者 / 程序员通用：

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

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

## 10.4 SPEC.md 最小模板

最小但可执行的 SPEC：

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

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

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

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

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

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

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

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

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

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

## 10.5 Spec、规则与 Skill 的边界

| **内容** | **Spec** | **规则文件** | **Skill** |
|----|----|----|----|
| **本次功能目标** | 主位置 | 只写索引 | 读取 Spec |
| **项目永久约束** | 引用 | 主位置 | 遵守 |
| **可复用研究 / 实施方法** | 简述 | 可引用 | 主位置 |
| **验收用例** | 主位置 | 写必跑总则 | 可生成与执行 |
| **单次未决策项** | 主位置 | 不要写 | 可提醒收敛 |
| **强制自动动作** | 不负责 | 只写原则 | 交给 Hook / CI |

## 10.6 从 Spec 到多 Agent 任务树

| **任务** | **输入** | **可写范围** | **输出** | **验证** |
|----|----|----|----|----|
| **现状研究** | Spec + 仓库 | 只读 | 架构与冲突报告 | 引用真实文件与命令 |
| **接口实现** | 确认后的接口段 | backend/api/\*\* | 代码 + 单元测试 | contract / integration tests |
| **前端实现** | 接口契约 + 设计 | frontend/\*\* | 页面 + 状态处理 | 浏览器、截图、a11y |
| **安全审查** | Spec 权限段 + Diff | 只读 | 严重度与证据 | 复现 / 静态规则 |
| **端到端验证** | 可运行构建 | 测试与脚本目录 | 回归报告 | 正常、异常、权限、性能 |

## 10.7 Spec 变更控制

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

## 10.8 最常见的失败模式

| **失败** | **为什么** | **修正** |
|----|----|----|
| **Spec 写得很长但不可测** | 只有功能描述，没有成功条件 | 每条核心需求配至少一个可执行验收 |
| **没有非目标** | Agent 自动补全“完整产品” | 明确本期不做、不可改和后续候选 |
| **研究与实现混在一条长会话** | 中间假设污染执行 | 研究产物固化后新开会话实施 |
| **实现后不回填** | 无人知道哪些需求真正验证 | 状态与证据链接写回 Spec |
| **架构完全交给 Agent** | 责任与长期约束缺位 | Agent 给备选，人类记录决策 |
| **并行任务没有契约** | 多 Agent 产物无法合并 | 先定接口、所有权、合并顺序和主集成人 |