一个需求评审开了四十分钟，问题问了一堆：要不要支持批量？要不要加导出？以后会不会多语言？会后开发按"全都要"实现，工期翻倍，而实际上线后批量功能的使用次数是零。
澄清不足会返工，澄清过度会做无用功能。两者的分界不在"问得多细"，而在这个问题会不会改变实现方式——不改变实现的问题，问得再多也只是收集愿望。
1. 三类问题的价值不同
| 类型 | 例子 | 是否影响实现 |
|---|---|---|
| 边界问题 | 并发上限是多少 | 是，影响方案与容量 |
| 定义问题 | "活跃用户"怎么算 | 是，影响数据口径 |
| 愿望问题 | 以后要不要支持多语言 | 通常否，属于路线 |
三类的处理方式也不同：边界问题必须当场问清（答案直接影响方案），定义问题必须落到具体口径（否则数据两套），愿望问题只记录不追问。把三者混在一起讨论，往往是最会表达的人主导了范围。
第三类最容易被当成澄清，实际上它是需求收集。把它混进澄清环节，结果是把未来的可能性当成现在的约束——而"以后可能"这种前提，永远无法被证伪。
2. 澄清的目标是消除歧义，不是穷举可能
| 目标 | 做法 | 产出 |
|---|---|---|
| 消除歧义 | 把模糊词换成可判定的表述 | 验收标准 |
| 确认边界 | 问极端与失败情形 | 分支清单 |
| 明确排除 | 问"这次不做哪些" | 范围声明 |
第三项最有效，也最少被问。问"这次不做哪些"比问"还要做什么"更能收敛范围，因为它迫使对方做出取舍，而不是把所有愿望都列进来。
// 三种问法的收敛效果差异
弱："这个功能还需要什么？" → 得到愿望清单
中："这个功能在什么情况下不能用？" → 得到边界
强："这次明确不做的是哪三项？" → 得到范围
3. 五个必须问清的结构性问题
| 问题 | 影响什么 |
|---|---|
| 谁用、多久用一次 | 性能与体验优先级 |
| 数据从哪来、准不准 | 可行性 |
| 出错时希望怎样 | 异常路径与兜底 |
| 结果给谁看、用来做什么决定 | 精度与口径 |
| 什么时候必须能用 | 范围与分期 |
这一项可以问得更具体："这个数如果差了 5%，会有什么后果"。答案为"没事"的，精度要求可以放宽；答案为"会被追问"的，就必须定义口径与校验方式。
第四项常被跳过：同一个数字给不同的人看，口径不同。运营要的是趋势，财务要的是可对账，两者对精度的要求差一个数量级。
第五项决定"能不能砍范围"：如果时间点有硬约束（活动、合规），范围就必须可砍；如果时间可谈，范围可以保。
4. 澄清到什么程度停
| 停止信号 | 含义 |
|---|---|
| 再问下去答案都是"都行" | 对方没有更强的偏好 |
| 新问题不改变实现方案 | 已到收益边界 |
| 问题转向未来路线 | 越界，应转入规划 |
| 答案需要数据才能确定 | 转为实验或埋点 |
让"代为决定"变得可追溯的做法很简单：在文档里写"由技术侧决定"，并写明决定内容。它既是边界，也是将来争议时的依据。
// 代为决定的记录形态
决定：失败行保留 30 天（业务未给要求，按存储成本与常见审计周期取 30 天）
可调整：如后续需要更长保留期，改一个配置项即可，无需改代码
第一个信号最实用：当对方开始说"都行""你看着办"，说明剩下的问题对他没有区别，继续问只会消耗耐心。此时正确做法是替对方做决定，并把决定写进文档。
第二个信号更硬：如果一个问题的两种答案对应同一套代码，那它不该占用澄清时间。
// 澄清终止的判据：三个问题连着问下去
Q: 如果并发到 1000 会怎样？ A: 不太可能到
Q: 如果数据超出一年呢？ A: 都行，你定
Q: 以后要不要对接别的系统？ A: 以后再说
→ 三个答案分别对应"边界已明确""可代为决定""越界"，可以停止
澄清还有个时间维度的问题：问得太早和太晚都浪费。太早，对方还没想清楚，得到的答案会在下一轮被推翻；太晚，方案已经成型，问题变成"能不能改"。合适的时机是"业务目标明确、实现方式未定"之间那个窗口。
5. 把澄清结果变成可验证的东西
澄清如果没有产出物，等于没有发生。
| 产出 | 作用 |
|---|---|
| 验收标准（可判定的句子） | 上线时能判断是否完成 |
| 范围声明（做与不做） | 后续变更的基准 |
| 边界清单（极端与失败情形） | 测试用例来源 |
| 待确认项（带责任人与时间） | 不遗漏未决问题 |
第四项容易被当成"还没想清楚"，实际上它是澄清的正常产物。把所有问题都当场问清是不现实的，正确做法是把未决项记录下来，标明谁在什么时候确认。
// 澄清产出：四块，缺一块就会在实施期返工
acceptance:
- "单次导入 1 万行在 60 秒内完成"
- "导入失败时给出失败行号与原因"
scope:
do: ["CSV 导入", "失败行导出"]
not_do: ["Excel 导入", "定时导入"] // 这一栏最有价值
boundaries:
- "文件大于 50MB 时拒绝并提示"
- "同一文件重复导入视为幂等"
pending:
- question: "失败行是否需要保留 30 天"
owner: "业务方 A"
due: 2026-11-20
6. 排错：五种"澄清了还是返工"
| 现象 | 成因 | 处理方向 |
|---|---|---|
| 上线后说"不是这个意思" | 验收标准不可判定 | 把模糊词换成条件 |
| 工期翻倍 | 把愿望当约束 | 明确 not_do |
| 反复改口径 | 精度需求未确认 | 问"用来做什么决定" |
| 测试用例写不出 | 边界清单缺失 | 补极端与失败情形 |
| 未决项上线才想起 | 没有 pending 清单 | 记录责任人与时间 |
把形容词换成条件的做法有固定套路：给出度量、给出阈值、给出测量方式。三步都给出，才算可验收。
// 形容词 → 验收标准的转换
"快" → 单次查询 P99 ≤ 800ms，在 100 万行数据量下测得
"稳定" → 连续 7 天无 P1，错误率 ≤ 0.1%
"友好" → 失败时给出可操作提示（含失败原因与下一步建议）
"准确" → 与源数据逐条比对差异为 0，抽样 1 万条
第一项的根因通常是形容词："快""稳定""友好"都不是验收标准。"60 秒内完成"才是。
7. 边界：什么情况不必深挖
| 场景 | 为什么 | 做法 |
|---|---|---|
| 内部工具、使用者就是自己 | 需求由实现者定义 | 直接做 |
| 已有同类功能可参照 | 惯例明确 | 对齐既有做法 |
| 试验性功能 | 结果会推翻需求 | 只定验收，不定细节 |
| 极小改动（一行配置） | 无歧义空间 | 不做评审 |
还有一条与会议形式有关的边界：澄清不该在一次会上完成。多数需求需要"看一遍数据再问"，所以更有效的方式是两轮：第一轮收集问题，回去看数据，第二轮只确认未决项。一次会议问到底，往往得到的是"现场能想到的答案"，而不是"真实的答案"。
判断口径一句话：这个问题的答案会不会改变代码结构。会，必须问清；不会，问与不问的差别只是文档完整度。
8. 自测
- 三类问题中哪一类常被误当成澄清？为什么"以后可能"这种前提无法被证伪？
- 问"这次不做哪些"为什么比问"还要做什么"更能收敛范围？
- 五个结构性问题里，哪一项决定"能不能砍范围"？哪一项常被跳过且影响口径？
- 澄清终止的两个硬信号是什么？对方开始说"都行"时正确做法是什么？
- 澄清的四类产出分别解决什么问题？为什么"待确认项"是正常产物而非缺陷？
- 为什么"快""稳定""友好"不能作为验收标准？替换方法是什么？