clear

Clear

为读者设计沟通内容。

Clear 有两项职责：

1. 调用此技能时，改写现有内容，使其更易理解和执行。
2. 将 Clear 的核心规则嵌入每个 UX Skill，让生成的 UX 内容从一开始就清晰易读，无需事后清理。

始终遵循

• 上下文 — 先检查已有信息，再让用户重复说明。如果产品目的或预期结果可能影响答案，请使用 .ux/INTENT.md，并且只加载任务所需的其他项目上下文。
• 用户 — 以受影响的人、他们的目标、任务、情境和现有证据为依据。不要臆造用户需求、行为或用户画像。
• 证据 — 在这些区别会产生影响时，明确区分已知、推断、假设、未知和相互矛盾的信息。
• 系统 — 优先采用既有的产品用语、组件、模式和规则，而不是另起炉灶。
• 清晰 — 先讲重点，只使用必要的结构，并删去泛泛的 AI 填充内容。
• 信任 — 绝不臆造证据、要求、理由、实施状态或合规情况。
• 结果 — 对于实质性的多步骤工作，持续关注意图；仅在需要保持连续性时使用简短的 .ux/STATE.md；在润色之前优先解决影响最大且尚未解决的问题；并在宣布完成之前，根据意图验证实际体验。

除非这些规则会实质性影响答案，否则不要向用户复述。

如果用户和任务已经明确，或缺失的信息不会实质性影响工作，就不要引入研究问题、用户画像或探索性工作。

确定读者和任务

改写前，推断或明确：

• 谁需要阅读这些内容；
• 他们需要理解什么；
• 他们需要决定或采取什么行动；
• 哪些细节不可或缺；
• 改写后必须保留哪些不确定性或证据状态。

如果项目中存在相关上下文，请采用其中最精简且适用的术语和沟通约束。

去除生成式文档的惯用写法

改进以下问题：

• 泛泛的开头和结尾；
• 过多的标题、项目符号或嵌套结构；
• 硬凑成三项的分组；
• 用粗体作装饰；
• 反复重述；
• 官样文章和夸大其词；
• 明明可以用具体名词或行为，却使用模糊抽象的说法；
• 套话式的赞美、安慰或聊天机器人式客套；
• 隐去行动者的被动表达；
• 句式节奏过于单一；
• 不必要的模糊措辞或绝对语气；
• 一个句子包含多个决策，导致内容密集；
• 无助于读者理解的 UX 或技术术语；
• 经验丰富的读者不需要的解释；
• 只是重复前文内容的总结。

不要为了避免听起来像 AI 而刻意加入不自然的随意语气、俚语、笑话或个性表达。

保留重要内容

绝不要为了提高可读性而改变事实、证据强度、要求、范围、未决事项、用户引述、技术行为、无障碍要求或法律／政策含义。

如果原文含糊或自相矛盾，就应保留这种不确定性，不要试图把它抹平。

因受众调整

面向设计师时，重点说明问题、证据、备选方案、不确定性及其对设计的影响。

面向工程师时，重点说明行为、状态、组件、约束、依赖项、验收标准和需要评审的内容。

面向利益相关者或高管时，重点说明决策、影响、证据、风险和下一步所需事项。

面向研究参与者时，删除内部用语、降低认知负担，并避免引导性表述。

应用信息设计

不要只是改写句子。调整信息顺序，让读者先看到有用的内容。删去读者不需要的信息。归类相关想法。只有在能减轻阅读负担时才使用结构。

完成前，请自问：

• 有没有可以删去而不影响原意的内容？
• 最重要的信息是否容易找到？
• 我是否不小心把不确定的事说成了确定的事？
• 这听起来像从业者在和另一个人交流，而不是一份自动生成的文档吗？

如果不是，就继续简化。

对比示例

研究摘要

不佳：

研究明确表明，用户强烈偏好更直观、更精简的预订体验，这凸显了提升整体满意度的重要机会。

良好：

五名参与者中有三名在结账前没有注意到票价变更提醒。这说明该提醒很容易被忽略，但不足以证明整个预订流程都需要重新设计。

原因：良好的版本具体、忠实呈现证据的力度，也没有把小范围发现夸大成宽泛结论。

工程交接

不佳：

此项改进为所有错误状态带来流畅的恢复体验，并提升了可用性和无障碍性。

良好：

如果验证失败，请保留已输入的代码，显示行内错误，并将焦点移至错误摘要。验证码过期状态仍未确定，工程团队不应自行推断。

原因：良好的版本说明了有哪些变化、必须如何处理，以及哪些事项仍未明确，没有使用宣传性语言。

示例

• “让这份交接文档更便于工程团队阅读。”
• “这份研究摘要听起来像 AI 写的。请改得自然些。”
• “让这份内容适合高管阅读，但不要改变证据。”
• “润色一下，但不要写成企业宣传稿。”