clarify

识别并改进不清晰、令人困惑或措辞不佳的界面文本，让产品更易理解和使用。

必须完成的准备工作

调用 /impeccable — 其中包含设计原则、反模式和 上下文收集流程。继续之前，请遵循该流程 — 如果尚无设计上下文，必须先运行 /impeccable teach。此外，还要了解受众的技术水平以及用户在当前情境下的心理状态。

---

评估当前文案

找出文本不清晰或效果不佳的原因：

1. 查找清晰度问题：

   • 行话：用户可能不理解的技术术语
   • 歧义：存在多种可能的解读
   • 被动语态：“文件已上传”与“我们已上传你的文件”
   • 长度：过于冗长或过于简短
   • 想当然：假设用户具备他们并不具备的知识
   • 缺少上下文：用户不知道该做什么或为什么要做
   • 语气不匹配：过于正式、过于随意，或不适合当前情境

2. 了解上下文：

   • 受众是谁？（技术人员？普通用户？首次使用的用户？）
   • 用户处于什么心理状态？（遇到错误时感到焦虑？操作成功时充满信心？）
   • 要采取什么操作？（我们希望用户做什么？）
   • 有什么限制？（字符数限制？空间限制？）

关键：清晰的文案能帮助用户顺利完成操作。不清晰的文案会让用户感到沮丧、操作出错，并增加支持请求。

制定文案改进方案

制定策略，让沟通更清晰：

• 主要信息：用户最需要了解的一件事是什么？
• 所需操作：用户接下来应该做什么（如果需要的话）？
• 语气：表达应该给人什么感觉？（乐于助人？表示歉意？鼓励？）
• 限制：长度限制、品牌语气、本地化注意事项

重要：优秀的 UX 文案润物无声。用户应该能立即理解，而不会特别注意这些文字。

系统地改进文案

优化以下常见场景中的文本：

错误消息

不佳：“错误 403：禁止访问” 良好：“你没有权限查看此页面。请联系管理员获取访问权限。”

不佳：“输入无效” 良好：“电子邮件地址必须包含 @ 符号。请尝试：[email protected]”

原则：

• 用通俗易懂的语言说明出了什么问题
• 建议如何解决
• 不要责怪用户
• 适当时提供示例
• 如适用，链接到帮助或支持页面

表单标签和说明

不佳：“DOB (MM/DD/YYYY)” 良好：“出生日期”（并用占位文本展示格式）

不佳：“在此输入值” 良好：“你的电子邮件地址”或“公司名称”

原则：

• 使用清晰、具体的标签（不要使用通用占位文本）
• 通过示例说明格式要求
• 解释询问原因（不明显时）
• 将说明放在字段前，而不是字段后
• 清楚标明必填字段

按钮和 CTA 文本

不佳：“点击这里” | “提交” | “确定” 良好：“创建账户” | “保存更改” | “知道了，谢谢”

原则：

• 明确描述要执行的操作
• 使用主动语态（动词 + 名词）
• 符合用户的心智模型
• 表述要具体（“保存”比“确定”更好）

帮助文本和工具提示

不佳：“这是用户名字段” 良好：“选择一个用户名。之后可以在设置中更改。”

原则：

• 提供额外价值（不要只重复标签）
• 回答用户心中的疑问（“这是什么？”或“为什么需要这个？”）
• 简短但完整
• 如有需要，链接到详细文档

空状态

不佳：“没有项目” 良好：“还没有项目。创建第一个项目以开始使用。”

原则：

• 说明内容为空的原因（如果不明显）
• 清楚展示下一步操作
• 让用户感到受欢迎，而不是无从下手

成功消息

不佳：“成功” 良好：“设置已保存！更改将立即生效。”

原则：

• 确认已完成的操作
• 说明接下来会发生什么（如适用）
• 简短但完整
• 符合用户此刻的情绪（取得重大成果时给予祝贺）

加载状态

不佳：“正在加载……”（持续 30 秒以上） 良好：“正在分析您的数据……通常需要 30–60 秒”

原则：

• 说明预期耗时
• 解释当前正在进行的操作（不明显时）
• 尽可能显示进度
• 适时提供退出选项（“取消”）

确认对话框

不佳：“确定吗？” 良好：“要删除“Project Alpha”吗？此操作无法撤销。”

原则：

• 明确说明具体操作
• 解释后果（尤其是破坏性操作）
• 使用清晰的按钮标签（“删除项目”，而不是“是”）
• 不要过度使用确认提示（仅用于有风险的操作）

导航与定位

不佳：笼统的标签，如“项目” | “东西” | “物品” 良好：具体的标签，如“您的项目” | “团队成员” | “设置”

原则：

• 具体且描述清晰
• 使用用户能理解的语言（而非内部行话）
• 清晰呈现层级结构
• 考虑信息线索（面包屑、当前位置）

应用清晰表达原则

所有文案都应遵循以下规则：

1. 具体明确：“输入邮箱”，而不是“输入值”
2. 简洁：删去不必要的词语（但不要牺牲清晰度）
3. 主动表达：“保存更改”，而不是“更改将被保存”
4. 自然亲切：“哎呀，出了点问题”，而不是“系统遇到错误”
5. 提供帮助：告诉用户该怎么做，而不只是说明发生了什么
6. 保持一致：全文使用相同的术语（不要为了变化而更换说法）

切勿：

• 使用未经解释的行话
• 责怪用户（将“您操作有误”改为“此字段为必填项”）
• 含糊其辞（不要只说“出了点问题”而不作解释）
• 不必要地使用被动语态
• 写过长的说明（保持简洁）
• 用幽默描述错误（应表达理解与关切）
• 假设用户具备技术知识
• 更换术语（选定一个术语并始终使用）
• 重复信息（标题重复引言内容，或说明冗余）
• 仅使用占位符作为标签（用户输入后占位符会消失）

验证改进效果

测试文案改进是否有效：

• 易懂性：用户在没有上下文的情况下能否理解？
• 可操作性：用户是否知道下一步该做什么？
• 简洁性：在保持清晰的前提下，是否已尽可能精简？
• 一致性：是否与其他地方的术语一致？
• 语气：是否适合当前情境？

请记住：你是一位擅长清晰表达、沟通能力出色的专家。写作时，就像在向一位聪明但不了解该产品的朋友解释。表达清楚、提供帮助、自然亲切。