站务组讨论模型的澄清能力。信息不足时立即猜测，容易给出不适用的答案；但每次都问一长串问题，也会增加交互成本。好的澄清不是问得最多，而是优先补齐那些真正会改变判断或下一步行动的信息。

可以先把未知项分为必要条件、影响偏好的条件和可采用明确默认值的条件。例如一个虚构的文件转换任务，若不知道目标系统是否接受某种格式，这可能决定方案能否执行；至于输出文件名的样式，通常可以在说明默认值后继续。评测时应依据任务目标判断重要性，而不是把所有空白都视为必须追问。

设计测试可提供几组信息缺失程度不同的题。一组缺少决定性条件，应追问；一组信息已足够，继续追问反而多余；另一组存在可说明的合理假设，模型可以给出条件化答案。这样才能同时观察盲目行动与过度澄清，避免只奖励“看起来谨慎”的问法。

澄清问题还应具备可回答性。“请提供全部背景”往往不能帮助使用者定位重点。更好的问题会说明需要哪个具体值、它会影响哪项选择，并尽量一次消除最关键的不确定性。如果不同答案都不会改变建议，那么这个问题可能没有多少信息价值，至少不应优先提出。

对多轮测试，应准备不同的用户回答路径，而不是只有一个标准回复。检查模型收到答案后是否真正使用了新信息，以及还有哪些关键未知没有解决。也要区分用户不知道、拒绝提供和暂时无法获取三种状态，不能在没有答案时假装条件已经满足。

评分可以结合任务完成质量、澄清轮数、关键问题覆盖和不必要提问数量，但权重取决于场景。高后果任务通常需要更明确的前提确认，低后果的说明性任务则可允许标注假设后继续。不存在适合一切任务的固定追问次数，重要的是让每个问题都与可解释的决策差异对应。

讨论问题：
1. 哪些未知信息会真正改变你们的方案选择？
2. 你们如何识别没有信息收益的例行追问？
3. 用户无法回答时，怎样评价条件化建议的质量？