澄清式提问

提问是一个动作，它有价格。

人们很容易把「问一下」当成保守的默认选项：最坏也不过是烦到了谁。这笔账有三处算错了，而第三处正是会把产品拖垮的那处。

• 延迟，而且并不对称。交互式智能体问一句，代价是几秒。后台运行或定时运行问一句，代价是直到下一次有人来看之间的那段空档——常常是几个小时，有时是整个运行的余下部分，因为问题落进了一个没人盯着的队列。同样一个问题，取决于这个循环跑在哪里，代价能差上三个数量级。
• 注意力，那才是稀缺的输入。回答要让人切回一个他之所以托付出去、正是为了不用再抱着的任务。一个十分钟的任务里问两次，代价就可能超过亲手做一遍——而那恰恰是用户心里真正在做的比较。
• 信任，它不对称，而且重建得很慢。用户会把频繁的提问读作「这东西离不了人」，然后以缩小托付范围来回应。一个什么都要问的智能体，最终会收敛到什么都不被用来做；而这在遥测里呈现出来的样子是用量下滑，不是「澄清提问有问题」。

闸门是两个判断，而且都与置信度无关。

模型的不确定度是个糟糕的触发器，既因为它校准很差，也因为它答非所问——见不确定性与校准。模型可以对一件无关紧要的事真心没底，也可以对那个会让你赔上一个生产库的读法泰然自若。改用后果来设闸门，按顺序做两道判断：

• 这处歧义承重吗？几种说得通的读法，会导向实质不同的工作吗？「报告要 Markdown 还是 HTML」通常不会——挑一个，说清挑了哪个。而「删掉过期记录」里的过期可能指三十天也可能指三年时，绝对会。
• 走错的那条岔路难撤回吗？一次能靠改一处就撤回的猜错，那叫草稿。一次会发出邮件、划走钱、或者删掉一张表的猜错，不叫草稿。这正是人在回路用来设审批关卡、影响半径用来划定范围的同一根轴。

两者皆真，就问。承重但可撤回：带着一个说明出来的假设往下做——这是那个很大的中间格，而把它默认成「问」正是最常见的那处设计错误。不可撤回但不承重：你手上的不是一个问题，而是一次确认，那是另一种交互，代价也不同。两者皆否：不吭声，往下做。

真要问，就问一次、问在前头、问得能答。

大多数被归咎于「澄清式提问」的痛苦，其实是问题设计得糟糕。四条规则就够了。

• 凡是能查到的，都别问。一个智能体本可以用一次工具调用回答掉的问题，是缺陷而不是礼貌——「用哪个数据库？」而配置里恰好只有一个连接，就是那个经典例子。先从环境里解析，只去问意图，因为意图是唯一没写在任何地方的东西。
• 攒到前头一起问。三个问题一起问，代价是一次打断；三个问题散在二十分钟里，代价是三次，而且第三次到达时人早已走开。往前多想一步，好在动手之前就知道自己要什么——这正是「规划」的大半意义所在，见规划与终止。
• 带上一个默认值。「除非你另有说法，我按过期＝早于 90 天来处理」这句话，沉默可以回答，一个字也可以回答。而一句敞开的「你指的是什么？」是让人替你去把选项一一列出来，而那正是被托付给你的活儿。
• 要的是决定，不是规格书。给出两三条具体岔路，连同各自的后果。人否决一个错选项的能力，远强于从零产出一份完整规格的能力，而这样的交换一轮就能结束。

协议层面恰好为这种形状提供了支持：MCP 的 elicitation 允许服务端在调用中途请求一段具体的、带 schema 类型的输入，而不是失败或者瞎猜——见采样与诱导输入。难的从来不是机制，而是「何时启用它」这条策略。

另一条路是「说明出来的假设」，而它必须可见。

对于「可撤回但承重」这个占多数的格子，正确动作是决断并声明：带着一个具名的假设往下做，把它放在结果被阅读的地方，并让推翻它的成本很低。写在输出第一行的假设，读者花两秒，智能体分文不花；同样一个假设若是悄悄做掉的，等到它被证明是错的那天，就和一次幻觉分不出彼此。

• 把假设记成结构化输出，而不是埋在答案中段的散文——它们该紧挨着结果，也该进入 trace，好让评审者不必重读全文就能扫过一遍。这和智能体 UX 模式关于展示中间状态的论证是同一个。
• 把推翻做成一步。「用 --since=3y 重跑一次」是一个带出口的假设；「把整份报告重新生成」不是。
• 量对东西。澄清提问率是个虚荣指标，光靠调提示词的语气就能把它压到零或推到一。真正要紧的两个数是：由未言明的假设引发的返工，以及在一个问题前被放弃的运行——前者告诉你问得太少，后者告诉你问得太多，而健康的系统两者都会有一点。

延伸阅读：人在回路讲审批关卡，不确定性与校准讲置信度为何会误导，等待与延迟 UX讲在智能体决定「不问」的那段时间里，人看到的是什么。