利用澄清提问消除需求歧义

需求歧义是返工的主要来源之一。与其让代理猜测后推倒重来，不如在动手前锁定关键决策点。本节梳理高频歧义来源、主动澄清的提问方法、代理反问时的响应原则，以及如何把澄清结论沉淀为后续约束，让多轮协作少走弯路。

一、高频歧义点与不问的代价

歧义类型	需要锁定的内容	不问清的后果
目标行为不明	期望的最终行为、输入输出与成功表现	实现方向偏离，整轮返工
边界条件缺失	异常输入、空值、并发、性能与兼容范围	只覆盖主路径，上线后暴露边界缺陷
技术选型未定	采用既有方案还是新方案、是否允许新增依赖	代理自选实现，与项目技术栈不符
风格与规范不清	命名、结构、错误处理、注释等遵循哪套约定	产出风格割裂、难以合并维护
验收口径模糊	以测试、构建还是特定行为作为完成标准	双方对"完成"理解不一致，反复拉扯
范围归属不清	哪些属于本轮、哪些留待后续	范围膨胀，主线任务被次要工作挤占

二、主动澄清的提问步骤

1. 列出歧义清单：在下达任务前先找出影响结果方向的关键不确定项，按"不锁定就会做错"的优先级排序。
2. 给出有限候选：对每个关键决策提供两到三个可选项及其取舍（改动成本、风险、兼容影响），避免开放式空问。
3. 结合约束做选择：依据项目现状、资源限制与优先级锁定方案，并说明选择理由，便于代理贯彻。
4. 把结论写回任务：将澄清结论并入目标与约束段，形成明确指令；书面化结论胜过口头默契。

三、代理反问时如何高效响应

• 一次答全相关约束：针对反问给出明确选择与边界，避免挤牙膏式补充拖慢迭代。
• 说明取舍依据：给出选择背后的约束（如兼容性、维护成本、时间窗口），帮助代理处理未被问到的相邻细节。
• 区分探索与写入：只读性质的调研、方案梳理可以在保守起步姿态下先进行；涉及修改文件、安装依赖、联网或删除等写入动作，应在方案确认、审批与沙箱姿态明确后再执行。
• 前提不再随意变更：一旦锁定关键决策，后续轮次不反复推翻；确需变更应作为明确调整并评估对已完成部分的影响。

四、把澄清结论沉淀下来

• 并入后续轮指令：已确认的决策在后续每轮任务中沿用，防止会话推进后被稀释遗忘。
• 可复用约定归入项目规则：反复出现的决策（技术栈偏好、命名规范、禁止事项）适合沉淀到项目指令层面，减少每次口头重复。
• 记录被否决方案：简要保留"为什么不选某方案"，避免后续轮次又提出已排除的方向。
• 澄清与验证联动：把关键澄清结论转写为可检验的验收项，使"达成共识"能够被测试或行为结果证实。

五、FAQ

问题	处理建议
是否什么都要先问再动手	区分方向级与细节级问题：影响方向、选型、验收的先澄清；纯实现细节可在方案中给出建议由人工确认。
代理没反问是否就代表需求清楚	不代表；代理可能按默认假设推进，关键决策点仍应由人工主动锁定并写明。
候选方案如何给得专业	每个候选附成本、风险、兼容性与适用前提，让选择基于权衡而非偏好。
澄清后又冒出新歧义怎么办	判断是否属于本轮范围；属于则补充澄清并确认，超出本轮则单独立项，避免打断当前收敛节奏。

六、动手练习

• 练习：选一个过去返工过的任务，对照六类歧义点复盘漏问了哪些决策；为其中两项写成"候选方案—取舍—结论—验收"的澄清记录，用于下一次同类任务。