开放输入的错误提示难以具体，因为系统并不知道用户原本想做什么

概念解释

表单校验可以写「电话少了一位」，因为字段的合法集合事先已知。开放输入失败时，系统往往只知道「这次没交出合格产物」，不知道合格产物本该是什么。意图未知的报错（underspecified NL error）指的是：错误讯息无法指向那个缺失的目标，只能指向过程（超时、拒答、格式坏了）或指向用户（「请换一种问法」）。具体性丢失不是文案写得懒，是目标变量从未被观测。

人把失败怪到自己措辞上，是归因偏向。这里是另一头：即便产品想把失败说清楚，也缺少「你本来要的是 X」这一个 X。

机制

确定性界面的错误来自对已知模式的偏离：类型检查、必填、权限。生成界面的「错误」常常是评价函数不通过，或模型自己决定拒答，而评价函数用的金标准并不在用户那句话里。没有金标准，诊断就无法命名失败的维度——是对象错了、粒度错了、还是根本不该走生成。于是文案退回到全称量词：「出了点问题」「我可能理解错了」。

更糟的是流畅的错答根本不触发错误通道。报错模块只能在系统承认失败时发言；开放输入的多数危害是未承认的失败。于是仅存的几次真报错，还因为缺少意图而说不利落，用户对错误通道的信任再降一档。

怎么研究

收集三类失败：显式拒答、格式/工具调用崩溃、以及人类判定不合格但系统当成功交出的输出。让另一组人只看产品给出的错误文案（第三类则看「无报错」），重建「用户本来想做什么」和「下一步该怎么改」。自变量：文案是否包含系统当时采用的假设、是否列出 2–3 个可能意图、是否展示已尝试的检查。因变量：重建意图的准确率、用户改下一句的成功率、把无报错错答识别为失败的比例。

金标准必须来自任务说明书，不能事后从失败提示反推——否则是在测阅读理解，不是在测错误通道。

边界

任务被界面钉死时（「翻译成德文」「把这列求和」），意图已知，报错可以重新具体，这条弱化。工具调用若返回结构化错误码（权限、配额、schema），过程侧的具体性可以很高，仍解决不了「你到底要哪一种摘要」。创意探索里没有「错」，报错通道本就不该出现。这条也不覆盖帮助文档或示例如何展示能力。

怎么落地

• 报错先复述系统实际采用的假设（对象、格式、成功标准），再谈失败。没有假设就不要假装诊断。
• 当意图无法唯一确定时，用两三个互斥的可能目标让人点选，而不是请人「说清楚一点」。点选是在补那个缺失的 X。
• 把「看起来像成功、评价不通过」接到同一套失败通道上，不要只在崩溃时说话。
• 验证：拿十条真实失败，遮住原提示，只留报错，让没参与设计的人写出「用户想做什么、该改哪里」。若多数写不出比「再试一次」更具体的动作，错误通道仍不知道那个 X。

延伸

• 同组：L2.01.1 开放输入不提示能力范围 · L2.01.2 用户不知道该怎么说是主要门槛 · L2.01.3 表述差异会导致结果差异 · L2.01.4 空白输入框不传达任何能力边界，用户的第一句话本质上是猜测 · L2.01.5 开放输入把失败的归因引向用户自己说得不好 · L2.01.6 同义表述得到不同结果，用户会误以为存在需要背诵的固定说法 · L2.01.7 开放性使功能无法被枚举，产品的能力清单不再可完整展示
• 相邻：L1.06 AI 失败的优雅降级 · L2.15 指令的歧义与澄清追问 · L4.13 代理的失败上报与求助
• 站内检索：underspecified NL error · intent-unknown failure · generative error message