开放输入把失败的归因引向用户自己说得不好

概念解释

检索无结果时，人会说「库里没有」；按钮点了没反应，人会说「这个功能坏了」。开放输入失败时，更常出现的第一句是「是不是我问得不对」。提示失败的自我归因（self-attribution of prompt failure）是开放通道特有的责任倾斜：因为输入看起来是用户写的自然语言，输出不好就被读成写作失败，而不是系统在这一类任务上的能力失败。

它不处理错误提示写不具体——那是系统侧说不清。这里处理的是人把因果放在哪一边。

机制

Weiner 的归因理论里，可控的内部原因最容易被抓来解释失败。措辞显然比模型权重更可控，也更内部。界面还在配合：光标、草稿、发送键都强调「这是你的话」；模型一侧通常没有对等的「这次我动用了哪项能力、哪项没接上」。于是失败的唯一可编辑对象是那句提示。人改写、加词、换敬语，像在改作文，而不是在换工具。

自我归还有短期适应价值：改表述有时真的能救。代价是能力失败被系统性地编码成用户技能问题。产品日志里看到的是「提示质量低」，看不见「这类任务成功率本就低」。用户则停止报告缺陷，因为缺陷已经被他们私了成自己不会说话。

怎么研究

在一次受控失败后做归因访谈或迫选：是我的表述、是系统不会、是任务本身不合理、是随机波动。失败要用同一套下游拒绝制造，不让真实能力差成为混淆。自变量：入口形态（开放框 vs 点选任务）、失败文案是否提到「能力限制」、用户先前是否成功过一次。因变量：内部/外部归因比例、是否继续改写同一句、是否去找别的功能、是否提交反馈。

实验室里若主试站在旁边，社会期许会把归因推向「我没说清」。远程无主试、失败文案保持中性，更接近产品里的私了。

边界

专家用户和提示工程师已经把「调提示」当成正式技能，自我归因是工作方法，不一定是误伤。系统若用「我无法做 X」明确把失败标成能力拒答，归因会外移。图形界面混排的产品里，人仍可能把失败怪到按钮上。高风险专业场景（医疗、法律）里，外部归因更强，因为后果不允许「再改一句试试」。这条不覆盖同义句分叉之后形成的口令迷信。

怎么落地

• 失败回复先切分两类：能力拒答（「这类请求我做不了」）与理解不确定（「我按 A 理解了，若你要的是 B……」）。前者禁止建议「换个说法再试」。
• 不要在空状态或错误态放「提示写得越好，结果越好」作为唯一叙事。那是在预先把失败签给用户。
• 提供「这不是我想要的」且不要求改写提示：选项可以是换任务类型、收窄范围、或转人工/规则路径。
• 验证：安排一次你们确定做不到的请求，看失败后的第一动作是改措辞、换入口，还是放弃。若改措辞占大多数，且事后访谈仍说「我没问对」，归因已经被开放输入吸走。

延伸

• 同组：L2.01.1 开放输入不提示能力范围 · L2.01.2 用户不知道该怎么说是主要门槛 · L2.01.3 表述差异会导致结果差异 · L2.01.4 空白输入框不传达任何能力边界，用户的第一句话本质上是猜测 · L2.01.6 同义表述得到不同结果，用户会误以为存在需要背诵的固定说法 · L2.01.7 开放性使功能无法被枚举，产品的能力清单不再可完整展示 · L2.01.8 开放输入的错误提示难以具体，因为系统并不知道用户原本想做什么
• 相邻：L1.06 AI 失败的优雅降级 · L5.03 信任校准 · L2.15 指令的歧义与澄清追问
• 站内检索：self-attribution of prompt failure · causal attribution · user-blaming interface