让 AI 写错误提示：先说清当前状态，再给能做到的恢复动作
“操作失败，请稍后重试”很短，却没有回答用户最着急的问题：刚才的内容还在吗，现在该做什么？让 AI 写错误提示时，先提供真实状态，比先挑选亲切语气更重要。文案再好，也不能把未知结果写成已经确定。
AI生成概念配图
给模型一张状态卡，而不只给错误码
微软官方错误消息指南建议说明发生了什么、对用户的结果以及可采取的办法，并避免责怪用户。本文把这些原则变成 AI 起草流程。状态卡至少包含触发条件、系统确知的原因、操作结果、数据保存位置，以及产品实际提供的恢复动作。
以虚构应用“叶签便笺”为例：用户点击保存时网络请求超时，当前文字仍在页面内，但没有本地草稿功能，服务器是否收到请求尚未确认。此时不能写“保存失败，内容已安全备份”，也不能把超时直接解释成用户网络断开；两种说法都超出了已知事实。
同一个错误码也可能需要不同提示
这个状态的提示可以是：“尚未确认是否保存成功。当前内容仍显示在此页面，请先复制备份，再重新检查保存状态。”只有产品确有“检查状态”入口，才把它做成按钮。若没有，就先列为产品缺口，由负责人确定可行路径，不能让 AI 写出一个不存在的功能。
另一个状态若已确认服务器拒绝超长内容，提示应说明上限与当前长度的处理办法；若用户只有查看权限，则解释需要编辑权限，并提供已存在的申请入口。不要把这三种状态都改成“网络异常”。具体原因不同，可行的恢复动作也不同。
可复用模板：事实、提示、按钮对应
可复用模板：根据以下状态卡起草错误提示，分别输出简短标题、正文、主按钮、次按钮和帮助入口。只使用已经确认的原因、保存状态与可用功能；未知项明确标出。说明每句话依据哪个字段，不责怪用户，不保证尚未验证的恢复结果。若缺少安全可行的下一步，列出产品需要补充的信息。
让 AI 同时指出容易误导的词。例如“重新提交”可能让用户以为首次一定没有成功；“你的文件太大”可以改成具体限制；“永久丢失”必须有充分依据。对用户没有帮助的内部堆栈不必塞进正文，可以用可复制的问题编号连接支持记录，前提是编号机制真实存在。
在真实错误状态里读一遍、点一遍
用测试环境分别触发超时、权限不足和输入超限，核对文字与实际状态是否一致。然后点提示提供的按钮，检查是否保留当前输入、是否回到正确页面、是否会重复执行有副作用的操作。看到错误提示后能继续任务，才算恢复流程走通，不只是文案看起来友好。
还要检查文字出现的位置和持续时间。如果保护当前输入的建议只闪现一瞬，用户来不及读就失去内容，文案正确也没有完成任务。长说明可以放入帮助内容，但“保存尚未确认”这类影响下一步判断的关键信息，应在当前错误状态中直接可见。
也让不了解实现细节的人读一遍，问他现在认为发生了什么、接下来会做什么。若理解与系统行为不一致，先改状态解释和动作，再调整语气。AI 可以提供几版措辞与发现歧义，但保存保证、重试条件和权限规则必须由实际产品验证，不能靠模型推断补齐。
