苏格拉底式需求收敛

苏格拉底式需求收敛

学习目标

读完本章后，你将能够：

• 理解为什么编码前必须进行需求探索而非直接动手
• 设计”一次一问”的对话策略，避免信息过载
• 构建 2-3 个方案的对比框架，含权衡和建议
• 实现分段审批流程：按复杂度分节展示设计，逐节获取确认
• 判断项目是否需要分解为多个子项目

核心概念

为什么需要编码前的门控

AI Agent 的默认行为是”收到请求 → 立即实现”。这种冲动导致：

1. 未检验的假设：Agent 基于自己的理解直接动手，而非验证用户的需求
2. 过度工程：Agent 倾向于添加用户不需要的功能和抽象
3. 方向错误：在错误的假设上花费大量 token 和上下文

需求收敛的目的不是写完美的文档，而是在动手之前确保”做正确的事”。

七步流程

一次一问原则

每条消息只提出一个问题。如果话题需要更多探索，拆成多条消息。

为什么：

• 多个问题同时提出会导致用户遗漏部分问题
• Agent 无法区分用户回答了哪个问题
• 用户容易在多个问题中选择最简单的回答，而非最深思熟虑的

多选项优于开放式：

• “你需要用户登录吗？“比”你的认证策略是什么？“更容易回答
• 但当多选项不适用时，开放式问题也可以

规模评估与项目分解

在深入细节之前，先判断项目规模：

• 合适规模：一个子系统的功能变更 → 直接 brainstorm
• 过大：包含多个独立子系统（如”构建带聊天、文件存储、计费的平台”）→ 先分解

分解方法：

1. 识别独立的子项目（各自的输入输出是什么）
2. 确定构建顺序（哪些依赖哪些）
3. 对第一个子项目走完整的 brainstorm → spec → plan → implement 循环
4. 每个子项目获得独立的 spec → plan → implement 周期

分段审批

设计不是一次性呈现，而是按复杂度分节：

• 直白的部分：几句话
• 复杂的部分：200-300 字
• 每节呈现后询问”这部分看起来对吗？”
• 准备好回退和澄清

分段审批的价值在于：用户在早期就能发现方向错误，而不是读完整个设计才发现根基就错了。

设计隔离原则

好的设计将系统分解为具有独立 purpose 的单元：

• 每个单元有清晰的单一职责
• 通过定义良好的接口通信
• 可以不依赖内部实现而被理解和测试

两个检验问题：

1. 不看内部实现，能理解这个单元做什么吗？
2. 改变内部实现，不会破坏消费者吗？

如果答案是否定的，边界需要重新设计。

问题与规避

陷阱	表现	对策
”这太简单不需要设计”	Agent 跳过 brainstorming 直接写代码	Hard-Gate：每个项目必须经过此流程，设计可以短到几句话但不能省略
问题轰炸	一次性抛出 5-6 个问题	强制”一次一问”规则，用 TodoWrite 跟踪待探索话题
设计过长	一次性呈现 2000 字设计	分段呈现，每节 200-300 字以内，逐节审批
占位符残留	设计文档中包含 TBD/TODO	自审阶段扫描并修复所有占位符
范围蔓延	brainstorming 过程中不断增加新需求	定期回顾最初的目标，新增需求作为后续迭代
终端状态错误	brainstorming 后直接调用 frontend-design 等实现 Skill	唯一的下一步是 writing-plans

设计取舍

为什么提出 2-3 个方案而不是直接给推荐方案？

直接给推荐方案会让用户误以为这是”唯一合理的做法”。呈现 2-3 个方案：

• 让用户看到权衡和取舍
• 暴露 Agent 自己可能忽略的选项
• 建立信任（用户感受到被尊重而非被决定）

但选项过多（5+ 个）会导致决策疲劳，所以限制在 2-3 个。

为什么设计文档要写入文件而非仅对话中呈现？

• 对话历史会被压缩/截断，文件是持久的
• 文件可被后续的计划编写 Skill 引用
• 文件可被代码审查者作为参考基准
• 文件提交到 git，变更历史可追溯

补充：Agent Skills 的四阶段门控规格工作流

来源：Addy Osmani / agent-skills v0.6.1，skills/spec-driven-development/SKILL.md，commit 6ce0298

agent-skills 项目将编码前门控细化为四阶段门控工作流，每个阶段必须通过人工验证后才进入下一阶段：

SPECIFY ──→ PLAN ──→ TASKS ──→ IMPLEMENT
   │          │        │          │
   ▼          ▼        ▼          ▼
 Human      Human    Human      Human
 reviews    reviews  reviews    reviews

阶段	核心产出	验证方式
SPECIFY	规格文档（六大核心区域）	人工审查并批准
PLAN	技术实现计划（组件、顺序、风险）	人工确认可行性
TASKS	离散可执行任务（含验收标准）	人工确认任务粒度
IMPLEMENT	按任务逐一实现	每个任务通过测试验证

规格六大核心区域

规格文档必须覆盖以下六个区域：

1. Objective — 构建什么、为什么、用户是谁、成功的样子
2. Commands — 完整的可执行命令（含标志），不是工具名
3. Project Structure — 源码、测试、文档的目录布局
4. Code Style — 用一个真实代码片段展示风格，优于三段描述
5. Testing Strategy — 框架、测试位置、覆盖率期望、测试级别
6. Boundaries — 三层系统：Always / Ask First / Never

边界三层系统（Boundaries Three-Tier）

这是 agent-skills 提出的需求收敛后行为约束模式：

层级	含义	示例
Always	无条件执行	提交前运行测试、遵循命名约定、验证输入
Ask First	需要人工确认	数据库 schema 变更、添加依赖、修改 CI 配置
Never	绝对禁止	提交密钥、编辑 vendor 目录、未经批准删除失败测试

成功标准重构法

将模糊需求转化为可测试条件的模式：

需求："让仪表盘更快"

重构后的成功标准：
- 仪表盘 LCP < 2.5s（4G 连接）
- 初始数据加载 < 500ms
- 加载期间无布局偏移（CLS < 0.1）
→ 这些是正确的目标吗？

规格是活文档

• 决策变更时：先更新规格，再实现
• 范围变更时：新增或裁剪的功能反映到规格中
• 提交规格：规格与代码一起在版本控制中
• 在 PR 中引用：每个 PR 链接回其实现的规格部分

与七步苏格拉底流程的关系

现有的七步苏格拉底流程（探索 → 提问 → 方案对比 → 分段审批 → 设计文档 → 自审 → 转计划）聚焦于需求发现阶段。四阶段门控工作流将需求发现后的工作延伸为完整的规格 → 计划 → 任务 → 实现链路。两者的关系：

苏格拉底七步流程（需求发现）
        ↓
四阶段门控（SPECIFY → PLAN → TASKS → IMPLEMENT）
        ↓
增量实现 + TDD

陷阱

• “规格会拖慢速度” → 15 分钟的规格防止数小时的重做。15 分钟内的瀑布胜过 15 小时的调试。
• “需求反正会变” → 这正是规格应该是活文档的原因。过时的规格仍然好过没有规格。
• “用户知道自己要什么” → 即使是清晰的请求也有隐式假设。规格的作用就是暴露这些假设。

---

参考来源

• Paul, R. (1990). Critical Thinking: What Every Person Needs to Survive in a Rapidly Changing World — 苏格拉底式提问的分类与应用
• YAGNI 原则 (You Aren’t Gonna Need It) — XP 方法论中的简洁设计原则
• DRY 原则 (Don’t Repeat Yourself) — Hunt & Thomas, The Pragmatic Programmer