clarify

识别并改进不清晰、令人困惑或写得不够好的产品文案，让用户更容易理解、信任并采取行动。

必须完成的准备工作

用户通过 /clarify 启动此工作流。此技能启用后，加载 $frontend-design——其中包含设计原则、反模式和上下文收集协议。继续之前，务必遵循该协议——如果尚无设计上下文，必须先加载 $setup。此外，还要了解：受众的技术水平、用户在当前情境下的心理状态，以及你是在撰写新文案还是编辑现有文案。

有关标签、错误提示、空状态、确认信息和界面微文案，请参阅 UX 写作参考。 如果文案问题涉及刻意营造亲切感、含糊其辞的进度用语、同意措辞、取消措辞、升级压力，或任何应当更加明确、诚实的界面文案，请参阅 界面诚信。 如果文案修改取决于验证行为、摘要、正确输入示例或可恢复性模式，而非仅仅取决于措辞，请参阅 错误恢复。 如果措辞涉及通知、提醒、徽章、摘要、提示或通知设置，请参阅 状态沟通。 如果涉及标题、落地页、功能页、引导流程中的承诺、生命周期消息、市场列表或行动号召策略，请参阅 营销文案撰写。 如果要通过有针对性的编辑逐步改进现有文案，而不是彻底重写，请参阅 文案编辑检查。

---

评估现有文案

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

1. 查找清晰度问题：

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

2. 了解上下文：

   • 受众是谁？（技术人员？普通用户？首次使用的用户？）
   • 用户处于什么心理状态？（遇到错误时感到焦虑？成功时充满信心？）
   • 需要采取什么行动？（我们希望用户做什么？）
   • 有哪些限制？（字符数限制？空间限制？）
   • 这是界面微文案、营销文案、引导文案，还是生命周期文案？
   • 我们是在撰写全新文案，还是编辑现有文案？

重要：清晰的文案能帮助用户顺利完成操作。不清晰的文案会让用户感到沮丧、导致错误并增加支持请求。

改进文案

制定更清晰的沟通策略：

请参阅文本层级与可读性，了解标签/值规则、对齐方式、链接强调方式，以及何时应移除、合并、弱化标签或有意突出标签。

将这份通用文本参考作为标签/值结构和阅读导向文本规则的权威依据，然后在此基础上应用本技能中特定于文案的改进方法。

如果任务不仅限于界面微文案，请使用营销文案撰写，了解恰当的定位背景、选择更有力的结构，并优化行动号召。

如果你正在改进现有文案，请执行文案编辑检查，分阶段聚焦修改，而不是一次性进行毫无侧重的重写。

• 主要信息：用户需要了解的最重要的一件事是什么？
• 需要采取的行动：用户接下来应该做什么（如果需要的话）？
• 语气：应该给人什么感觉？（有帮助？表示歉意？鼓励？）
• 限制条件：长度限制、品牌语气、本地化考量

重要：优秀的 UX 写作会隐于无形。用户应该能立即理解内容，而不会注意到文字本身。

系统地改进文案

从以下常见方面优化文本：

标签、值与易读性

有时，最清晰的文案改动就是完全移除标签。

推荐：

• 使用 还剩 12 件，而不是 库存：12
• 使用 3 间卧室，而不是 卧室：3
• 如果上下文已经足够明确，则只写 [email protected]，无需额外添加“邮箱”标签

原则：

• 如果值或上下文已经能说明问题，标签应作为最后的选择
• 如果合并标签和值能让内容更易于快速浏览，就将它们合并
• 必须使用标签时，除非用户会先查找标签，否则应将其作为辅助内容
• 在密集的技术表格、规格或设置中，标签可能比值更值得强调

错误消息

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

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

原则：

• 用通俗易懂的语言说明出了什么问题
• 建议如何修复
• 不要责怪用户
• 在有帮助时提供示例
• 如果适用，添加帮助/支持链接

表单标签与说明

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

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

原则：

• 使用清晰、具体的标签（而非通用占位符）
• 用示例展示格式要求
• 说明询问原因（如果原因并不显而易见）
• 将说明放在字段前，而不是字段后
• 清楚标明必填字段
• 对于表单，标签仍然很重要——通常不能省略

按钮与行动号召文本

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

原则：

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

帮助文本与工具提示

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

原则：

• 提供有价值的信息（不要只重复标签）
• 回答用户隐含的问题（“这是什么？”或“为什么需要这个？”）
• 保持简洁，但内容完整
• 如有需要，链接到详细文档

空状态

不佳：”没有项目” 良好：”还没有项目。创建你的第一个项目，开始使用吧。”

原则：

• 说明为空的原因（如果原因并不显而易见）
• 清楚展示下一步操作
• 营造欢迎感，不要让用户无从继续

成功消息

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

原则：

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

加载状态

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

原则：

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

确认对话框

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

原则：

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

导航与定位

不佳：使用“项目” | “东西” | “内容”等泛泛的标签 良好：使用“你的项目” | “团队成员” | “设置”等具体标签

原则：

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

应用清晰原则

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

1. 具体明确：“输入邮箱”，而不是“输入值”
2. 简洁：删去不必要的词语（但不要牺牲清晰度）
3. 使用主动语态：“保存更改”，而不是“更改将被保存”
4. 自然亲切：“哎呀，出了点问题”，而不是“遇到系统错误”
5. 提供帮助：告诉用户该做什么，而不只是说明发生了什么
6. 保持一致：始终使用相同的术语（不要为了求变化而换说法）
7. 少用标签：如果用户可以从上下文或格式中理解含义，就省去多余的标签
8. 弱化辅助标签：除非用户正在查找字段名或规格名称，否则视觉重点应放在主要内容上

切勿：

• 使用未经解释的行话
• 责怪用户（将“你出错了”改为“此字段为必填项”）
• 含糊其辞（不要只说“出了点问题”，却不作解释）
• 不必要地使用被动语态
• 写过长的解释（应简洁）
• 在错误提示中开玩笑（应表达体谅）
• 假设用户具备技术知识
• 变换术语（选定一个术语并始终使用）
• 重复信息（标题不要复述引言，也不要提供多余的解释）
• 只用占位符作为标签（用户输入后占位符会消失）
• 当值本身足以表达含义时，不要强行将所有数据都套入固定的 label: value 格式

验证改进效果

测试文案改进是否有效：

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

请记住：你是清晰表达方面的专家，沟通能力出色。像向一位聪明但不了解该产品的朋友解释那样写。表达清晰、乐于助人、自然亲切。