内容写作 编辑复核
产品微文案与错误提示复核
检查按钮、空状态、错误提示和引导文案是否清楚、可操作且不把系统责任推给用户。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名UX 文案编辑。请在不改变产品行为的前提下优化微文案，明确用户现在发生了什么、能做什么和什么时候可以重试。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 文案所在状态、用户目标和系统事实
2. 问题描述、下一步动作和恢复路径
3. 按钮、占位符、空状态和确认提示改写
4. 无障碍、翻译和长度风险
5. 需要产品或工程补充的状态
输入变量：
- 现有文案（{{copy}}）：提供文案及其所在页面或状态。
- 用户目标（{{user_goal}}）：说明用户正在完成什么任务。
- 系统行为（{{system_behavior}}）：提供真实错误、重试和权限行为。
- 语言环境（{{locale}}）：说明语言、字符限制和地区。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 改写前先确认系统真实行为，文案不能承诺不存在的恢复路径。
- 用真实设备检查长文案、截断和读屏体验。
WHEN IT FITS
适用判断
适合这些情况
- 产品里的提示语和错误信息由多人写，风格和清晰度不一。
- 用户在某些环节反复出错，怀疑是文案没说清。
- 你能提供实际的界面文案和上下文。
换个做法更好
- 你要定义的是整体语气：用《品牌语气校准器》。
- 问题出在交互流程而非文案：改文案掩盖不了流程问题。
- 你只有文案列表没有上下文：判断不了它出现在什么场景。
FAILURE MODES
常见翻车与修正
- 错误提示改得更友好了，但用户还是不知道该怎么办。
友好不等于有用。要求每条错误提示必须包含发生了什么和下一步该做什么，做不到的标注需要产品补充信息。
- 提示里暴露了内部错误码或技术细节。
要求面向用户的文案不含堆栈、内部服务名和原始错误码，需要排查的信息放到可展开的详情或日志里。
- 改写后文案变长，在按钮或提示条里放不下。
把实际的字数限制写进输入，要求每条标注字符数并在限制内。
ACCEPTANCE
怎么判断输出合格
- 每条错误提示都说清了发生什么和下一步做什么。
- 没有暴露内部技术细节和错误码。
- 长度符合实际的界面限制。
- 同类场景的措辞在产品内保持一致。
SAFETY BOUNDARY
使用边界
- 错误提示不能暴露系统内部信息，路径、堆栈和数据库字段名要从文案里去掉。
- 涉及删除、支付和授权的确认文案改动前要走一次实际流程验证，措辞歧义会造成误操作。