② 需求澄清 · 对齐靶心
这一步干什么
Section titled “这一步干什么”客户说“我们想要个 AI 助手”——这句话里有真需求、有伪需求、有领导的意思、有上次项目的怨气。需求澄清就是把这句话变成可验证、可排序、可拒绝的东西。
方法要点：
- 澄清前置到下次沟通之前。带着结构化的问题清单和重写好的故事去见客户，而不是空手去“再聊一聊”。
- 把原话重写成用户故事：「作为<角色>，我想要<功能>，以便<价值>」——写不出来的部分就是假设，假设必须标注并拿到下一次验证。
- 每条故事给出「最小可演示版本」。演示物是最好的澄清工具：“我下周给你看个东西”比“我们再开一次需求会”推进快十倍。
- 用例要排优先级。3–5 个候选场景在此收敛为 1–2 个首攻用例，排序标准回到第 ① 步的痛点强度 × 可行性 × 见效速度。
这一步结束时你手里应该有：1–2 个首攻用例的故事卡（含假设清单）+ 一份待客户拍板的澄清问题清单。
何时进入下一步：客户对“演示时会看到什么”达成一致。何时退回：发现痛点本身站不住——退回 ① 重新观察，成本远低于建完再退。
Prompt 怎么用见总览卡 Prompt 2 · 模糊需求澄清工作坊。
学科基础 · 敏捷
Section titled “学科基础 · 敏捷”西牛贺洲 · 敏捷——用户故事、INVEST、验收标准是这一步的学科底盘。
系统内功 · FDE 知识库
Section titled “系统内功 · FDE 知识库”| 读什么 | 解决什么 |
|---|---|
| 问题框定 | 从“业务问题”到“可动手问题”的转译 |
| 需求工程 | 需求捕获、分析与管理的方法全集 |
| 用例定义 | 一个“好用例”长什么样 |
| 用例优先级 | 多场景收敛时的排序框架 |
| 现场情形：客户说想要 AI | “我们想要 AI”这类原话的标准应对剧本 |
- AI 用户故事拆分：10 个可复制 Prompt — 尤其 Prompt 9：把客户原话重写成带假设标注的用户故事
现场检查清单
Section titled “现场检查清单”- 用例质量清单 — 首攻用例过一遍再投入探针
止损条件：如果客户拒绝为任何一条假设拍板，说明你的盟友结构有问题——回到干系人分析，而不是替客户做决定。