clarify

识别并优化不清晰、令人困惑或写得不好的产品文案，让产品更易于理解、更值得信任，也更便于用户采取行动。

必须完成的准备工作

阅读 frontend-design，并遵循其中的 Context Gathering Protocol。复用现有上下文，只询问影响重大的信息缺口。此外，还要了解：受众的技术水平、用户在当前情境下的心理状态，以及你是在撰写新文案还是编辑现有文案。

涉及标签、错误提示、空状态、确认信息和界面微文案时，请查阅 ux-writing reference。 文案问题涉及讨好式措辞、含糊其辞的进度描述、同意措辞、取消措辞、升级压力，或任何应更坚定、诚实的界面内容时，请查阅 interface honesty。 文案调整取决于验证行为、摘要、正确输入示例或可恢复模式，而不只是措辞时，请查阅 error-recovery。 涉及通知、提醒、徽章、摘要、提示或通知设置时，请查阅 status communication。 涉及标题、落地页、功能页、引导流程中的承诺、生命周期消息、市场平台列表或 CTA 策略时，请查阅 marketing copywriting。 通过有针对性的编辑步骤优化现有文案，而非整体重写时，请查阅 copy editing sweeps。 页面各部分衔接生硬、标记过多或有 AI 写作感，或需要改善段落之间的流畅度时，请查阅 natural copy transitions。 在为常规 React/Tailwind 界面添加辅助文案或说明之前，请先查阅 self-evident interface design；更好的解决方案往往是调整结构、默认值、约束或即时反馈。

---

评估现有文案

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

1. 找出清晰度问题：

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

2. 了解上下文：

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

重要提示：清晰的文案能帮助用户顺利完成任务。不清晰的文案会带来挫败感、错误和支持请求。

优化文案

制定清晰沟通的策略：

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

将这份通用文本参考作为标签/值结构和以阅读为导向的文本规则的权威来源，然后在此技能中应用文案方面的改进。

如果任务范围超出界面微文案，请使用营销文案写作来收集合适的定位背景、选择更有力的结构并强化 CTA。

如果你正在改进现有文案，请执行文案编辑检查，通过多轮聚焦修改来改进，而不是一次漫无目标地重写。

如果各部分之间的文案衔接不畅，请使用自然文案过渡，优化提示引导、问题衔接、证据过渡和 CTA 衔接，避免添加填充内容。

如果 UI 需要大量说明性文案，请先使用直观易懂的界面设计，判断是否可以通过布局、分组、控件选择、默认值、限制或预览来消除困惑。

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

重要：优秀的 UX 文案不会引人注意。用户应该能立即理解，而不会留意到这些文字。

系统地改进文案

优化以下常见区域的文本：

标签、值与易读性

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

优先使用：

• 12 left in stock，而不是 In stock: 12
• 3 bedrooms，而不是 Bedrooms: 3
• 如果上下文已足够清楚，就直接显示 [email protected]，不再额外添加“Email”标签

原则：

• 如果值或上下文本身已能说明含义，标签应作为最后的选择
• 如果合并标签和值能让内容更易于快速浏览，就应合并
• 标签确有必要时，除非用户会优先查找标签，否则应将其视为辅助内容
• 在信息密集的技术表格、规格说明和设置中，标签可能比值更值得强调

错误消息

不好：“Error 403: Forbidden” 好：“你没有权限查看此页面。请联系管理员获取访问权限。”

不好：“Invalid input” 好：“电子邮件地址必须包含 @ 符号。请尝试：[email protected]”

原则：

• 用通俗语言解释出了什么问题
• 建议如何解决
• 不要责怪用户
• 在有帮助时提供示例
• 如适用，链接至帮助或支持页面

表单标签与说明

不好：“DOB (MM/DD/YYYY)” 好：“出生日期”（通过占位符显示格式）

不好：“Enter value here” 好：“你的电子邮件地址”或“公司名称”

原则：

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

按钮与 CTA 文案

不好：“Click here” | “Submit” | “OK” 好：“创建账户” | “保存更改” | “知道了，谢谢”

原则：

• 具体描述要执行的操作
• 使用主动语态（动词 + 名词）
• 符合用户的心智模型
• 表述要具体（“保存”优于“OK”）

帮助文本与工具提示

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

原则：

• 提供额外价值（不要只是重复标签）
• 回答隐含的问题（“这是什么？”或“为什么需要填写？”）
• 简短但完整
• 必要时链接到详细文档

空状态

不佳：“没有项目” 良好：“还没有项目。创建你的第一个项目即可开始。”

原则：

• 说明为空的原因（如果不明显）
• 清楚地指出下一步操作
• 营造友好的氛围，不要让用户无从下手

成功消息

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

原则：

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

加载状态

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

原则：

• 说明预期耗时（需要多久？）
• 说明正在进行的操作（如果不明显）
• 尽可能显示进度
• 适当时提供退出选项（“取消”）

确认对话框

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

原则：

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

导航与路径指引

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

原则：

• 具体、描述清晰
• 使用用户能理解的语言（而非内部术语）
• 清楚地体现层级
• 考虑信息气味（面包屑、当前位置）

应用清晰表达原则

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

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

切勿：

• 使用未经解释的术语
• 责怪用户（将“你操作错误”改为“此字段为必填项”）
• 表述含糊（只说“出了点问题”，却不作解释）
• 不必要地使用被动语态
• 写过长的解释（保持简洁）
• 用幽默表达错误（应表现出同理心）
• 假设用户具备技术知识
• 随意更换术语（选定一个术语并始终使用）
• 重复信息（标题重复介绍内容、解释冗余）
• 仅用占位符作为标签（用户输入后占位符就会消失）
• 当值本身已能表达含义时，仍强行将所有数据写成固定的 label: value 格式

验证改进效果

测试文案改进是否有效：

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

请记住：你是清晰表达方面的专家，沟通能力出色。写作时，想象你正在向一位聪明、但不熟悉该产品的朋友解释。表达清晰、乐于助人、自然亲切。