错误信息用自然语言说明问题
别名: 错误信息 · 自然语言 · 报错文案 · 问题表征
概念解释
错误识别、诊断与恢复（error recognition, diagnosis, and recovery）的第一层是让人看懂发生了什么：错误信息应说明哪个动作失败、系统检测到的条件是什么、对用户结果有何影响。自然语言不是口语化堆砌，而是用用户任务中的对象和状态陈述事实——判断一句报错是不是自然语言，标准不是它听起来客气与否，而是用户能不能不查文档就把这句话对应回自己刚才做的那个动作。
机制
用户要先在头脑里建立一个"问题表征"才能着手修复，这个表征本质上是在缩小可能原因的假设空间。技术词、模糊的"操作失败"或指责式文案不会缩小这个空间，反而会把它撑大——用户不知道失败属于输入、权限、网络还是系统故障中的哪一类，只能在这几类之间反复试错，而试错行为本身通常发生在用户已经因为任务被打断而处于轻度焦虑的状态下，试错成本因此被放大。自然语言的作用是替用户完成"系统内部状态到任务事件"的翻译，把检测到的技术差异直接陈述成任务语言，例如"信用卡被发卡行拒绝"而不是"支付网关返回码 402"——这一步翻译原本是用户自己要做的推理工作，报错文案把它提前做完了，假设空间因此从"猜一个大类"直接收窄到"确认一个具体事实"。
边界
自然语言不能虚构确定性。原因未知时应说明已知事实、影响范围和下一步，而不是编造一个听起来合理但未必真实的原因（比如系统其实不知道是不是网络问题，却写"网络不稳定"）——编造原因比说"原因未知"更危险，因为用户会按错误的原因去排查，浪费的是他们自己的时间。安全、隐私和法律限制可能不允许公开具体细节，例如登录失败时不应明确说"该邮箱未注册"以防止账户枚举攻击，这种场景下该做的是把可以公开的部分（重试路径、求助渠道）讲清楚，而不是被这条原则逼着暴露不该暴露的信息。文案也需要随本地化重新审校，直译容易丢失自然语言原本具备的任务贴合度。
怎么落地
- 用固定模板写错误：发生了什么、影响了什么、原因（若已知且可公开）、现在能做什么，四项按此顺序摆放，不要打乱。
- 使用用户任务词汇，避免内部服务名、异常类名和抽象状态码出现在主文案里。
- 区分输入错误、权限不足、网络中断、系统故障和外部方拒绝这五类，因为它们对应的用户下一步动作完全不同，混在一起写等于没有分类。
- 验证办法：做故障回放测试，向参与者展示报错界面后立即让他们用自己的话复述"刚才发生了什么、接下来打算怎么做"，凡是复述不出来或说错分类的，就是文案没有完成翻译工作。