撰写错误信息文案时，许多人习惯直接扔一句“给我写几条友好的错误提示”给大模型。结果往往不理想——输出空洞、风格混乱、技术细节错位。模型根本不清楚这文案是用于前端弹窗还是后端日志，更别提是否需要包含操作指引或错误码。
核心问题来了：到底该不该提供参考样例？答案是：应该提供。但必须满足三个关键条件。
方法一：提供样例，且样例必须源自你的真实产品界面
直接复制1～2条当前系统已上线、用户反馈良好的错误文案，放在提示词最前面。例如：
- 输入：“上传超时 → 输出：【上传中断】网络不稳定，30秒内自动重试，也可手动点击‘重试’。”
- 输入：“权限不足 → 输出：【无访问权限】您当前账号未开通此功能，联系管理员开通后即可使用。”
这样做，Gemini能快速对齐你的语气颗粒度、括号用法、动词强度和信息分层逻辑，输出风格瞬间统一。
方法二：不提供完整样例，但强制指定结构模板
如果手头还没有沉淀出可用的样例，那就用结构来替代。明确要求每条文案必须包含三部分：【状态标识】+【原因简述】+【用户可执行的操作】。而且，【状态标识】统一使用中文方括号加粗关键词，比如【格式错误】、【连接超时】。【禁止省略‘用户可执行的操作’，哪怕只是‘请刷新页面’】
方法三：用反向排除规则替代样例
连一条现成文案都拿不出来时，直接写清楚什么绝对不能出现：“禁止使用‘抱歉’‘不好意思’等弱化责任的词汇；禁止出现英文术语如‘404’‘timeout’；禁止建议用户‘联系技术支持’——所有问题必须在本地可解决。”这比空泛地说“要友好”有效十倍。
提供样例时最常见的误区
第一步：检查样例是否真实上线过
千万不要使用设计稿里的文案，也不要使用测试环境中临时编写的提示。Gemini会把样例当作事实基准，如果样例本身存在歧义，比如写了“请稍候重试”，但实际按钮名称是“立即重试”，模型就会把这种矛盾原封不动地继承下来。
第二步：确认样例覆盖了你需要生成的全部类型
假设你要批量生成5类错误文案，例如网络类、权限类、格式类、超限类、服务不可用类，结果只提供了2条网络类的样例。那么Gemini就会把剩下3类全部往“网络不稳定”的方向靠，输出变成“【服务不可用】网络信号弱，请检查Wi-Fi”。【每类错误至少提供1条对应样例，否则宁愿不使用样例】
第三步：删除样例中的内部业务符号
像“#ERR-207”、“[APP_V3.2]”这类内部标记必须清除。Gemini不会自动识别这些是占位符还是必需字段，很可能直接照搬到新文案中，导致线上报错。