clarify

clarify skill 概览

clarify skill 是做什么的

clarify skill 用来改进表达不清的 UX 文案，包括标签、辅助说明、空状态、引导文案、确认提示，尤其擅长处理错误信息。它适用于这样一种场景：用户之所以困惑，不是因为界面缺少功能，而是因为文案本身让产品更难理解。

clarify for UI/UX Design 最适合哪些场景

clarify for UI/UX Design 特别适合产品设计师、UX writer、前端团队、PM，以及在发布前审查界面文案的 AI agents。它最有价值的前提是：页面或流程已经存在，当前任务是让措辞更清晰、更可执行，并且更贴合用户所处的具体情境。

真实要解决的问题

用户安装 clarify，并不只是为了“重写文案”。他们真正想解决的是更棘手的实际问题：为什么一条提示会失效、用户最可能误解什么、该补多少上下文、当下应该用什么语气，以及怎样改写文案，才能让用户毫不犹豫地采取下一步行动。

clarify 与通用提示词的差异

clarify skill 的核心差异在于流程，而不是单次改写效果。它不是一个随意输入“帮我写得更好听”的自由提示，而是会推动你按结构化方式审查：

• 用户的技术水平
• 用户当前的心理状态
• 用户接下来需要执行的动作
• 当前文案缺失了哪些上下文
• 具体属于哪类清晰度问题，例如术语过重、语义歧义、隐含前提过多，或语气不匹配

因此，当你关注的是功能性理解，而不只是风格润色时，clarify skill 会比宽泛的 copy-polish prompt 更有用。

使用前的重要注意点

采用 clarify 最大的阻碍，是它依赖前置设计上下文。这个 skill 明确要求先有 /frontend-design，如果还没有设计上下文，它会要求你先运行 /teach-impeccable。所以从技能安装层面看，clarify install 很简单；但最终输出质量，取决于你能否一开始就提供产品、用户群体和界面情境这些关键信息。

如何使用 clarify skill

clarify install 与调用方式

从仓库片段来看，clarify 是一个可由用户直接调用的 skill，并带有参数提示 [target]。实际使用时，建议从 pbakaus/impeccable 仓库安装，然后把 clarify 用在具体的页面、流程、组件或文案块上，而不是丢给它一个模糊的“帮我优化整个产品文案”的请求。

更实用的安装方式通常是：

• 从 https://github.com/pbakaus/impeccable 添加这个 skill
• 调用 clarify 时指定明确目标，例如某个 modal、checkout error、onboarding step 或 settings page

如果你的环境支持按名称安装 skill，就使用仓库 URL 加上 clarify 的 skill 路径；如果不支持，就导入整个仓库的 skill 集合，然后直接调用 clarify。

先看这个文件

优先查看：

• SKILL.md

在当前提供的目录树里，这个 skill 没有看到额外的 README.md、metadata.json、rules 或资源文件夹。这意味着大部分真正有用的使用说明都集中在 SKILL.md 里，它不像大型 skill 那样还有很多隐藏的实现细节可供挖掘。

使用 clarify skill 前必须准备的上下文

在让 clarify 重写任何文案之前，先整理好这些信息：

• 当前的准确文案
• 它出现在 UI 的什么位置
• 目标用户是谁
• 用户当下大概率处于什么心理状态
• 用户下一步应该做什么
• 是否存在产品或行业限制

这一步很关键，因为 clarify skill 判断的是“情境中的清晰度”，而不是脱离上下文的字面表达。哪怕改写后技术上没错，只要忽略了紧迫感、信任感或用户能力差异，依然可能失败。

为什么 frontend-design 依赖很关键

clarify usage 明确串联到 /frontend-design。这说明该 skill 默认前面已经完成了设计原则梳理和上下文采集流程。如果你跳过这一步，输出可能在语言上更顺，但仍然不符合流程、信息层级或用户目标。

如果当前还没有设计上下文，这个 skill 会要求你先运行 /teach-impeccable。建议把它当成必需的前置准备，而不是可有可无的润色步骤。

什么样的输入能得到最佳结果

最有效的输入，特点是具体且边界清晰。例如可以这样提供信息：

• current text: “Authentication failed”
• surface: login form error under password field
• audience: non-technical SaaS users
• mental state: frustrated, trying to get back into work quickly
• desired action: retry password, reset if needed
• constraint: do not imply the email is wrong for security reasons

这类输入会比下面这种请求得到更好的结果：

• “Improve this error message”

如何把模糊请求改成高质量的 clarify prompt

较弱的写法：

• “Make our onboarding copy clearer.”

更好的写法：

• “Use clarify on step 2 of onboarding. Current copy: ‘Configure your workspace for enhanced collaboration efficiency.’ Audience: first-time small business users with low technical confidence. Mental state: curious but impatient. Goal: get them to invite teammates. Constraint: keep headline under 8 words and body under 20 words.”

更好的版本，能给 clarify skill 足够的信息去判断术语问题、上下文缺失、行动是否清楚，以及语气是否合适。

clarify 可能重点检查什么

根据 SKILL.md，这个 skill 会系统性检查：

• 用户可能看不懂的术语
• 含义不清或可能被多重解读的表达
• 模糊责任主体的被动语态
• 过长或过短的文案
• 对用户知识水平的错误假设
• 没有交代发生了什么、下一步该做什么的上下文缺失
• 与当前场景不匹配的语气

这很有价值，因为它能帮助你提前判断：clarify skill 最擅长抓哪些类型的问题。

clarifiy usage 的推荐工作流

一个实用的流程是：

1. 先运行 /frontend-design 并收集上下文。
2. 一次只选一个目标界面，不要直接覆盖整个 app。
3. 粘贴当前的准确文案。
4. 明确用户对象、心理状态和期望的下一步动作。
5. 先让它做诊断，再让它给出改写。
6. 用 UI 空间限制和产品约束复核输出。
7. 在 success、loading、failure 等相邻状态里一起测试修改后的文案。

相比一上来就要求直接改写，这个顺序通常更能帮助你做出正确决策。

先要诊断，再做最终改写

如果你想把 clarify guide 用得更高效，第一步先问：

• 哪里不清楚
• 用户可能会误解什么
• 缺了哪些必要上下文
• 当前语气是否适合这个时刻

然后再让它给候选写法。这样可以避免过早进入重写，也能帮助你判断问题究竟出在措辞、信息架构，还是系统反馈本身缺失。

clarify for UI/UX Design 最适合的使用场景

这个 skill 特别适合处理：

• 没说明发生了什么、也没告诉用户下一步该做什么的错误信息
• 依赖内部术语的标签文案
• 默认用户已经知道背景知识的 onboarding instructions
• 方向模糊、帮助不大的 empty states
• 技术上准确但阅读负担大的 settings descriptions
• 无法有效建立信心的 confirmation 和 success messages

clarify 不适合的情况

不要期待 clarify 能解决以下问题：

• 更深层的 UX flow 问题，例如界面结构本身就让人迷惑
• 不能进行实质修改的法务或合规文案
• 清晰度已经足够、只是做品牌语气打磨的场景
• 未单独检查翻译限制时，就直接拿去做 localization-ready writing

如果真正的问题出在交互设计，而不是措辞，那么应该先修正流程，再使用 clarify。

clarify skill 常见问题

clarify skill 对新手友好吗？

是的，前提是你至少能提供当前文案和基本上下文。但新手最常跳过的，恰恰是最难也最关键的部分：说明目标用户是谁、以及用户当下处于什么状态。缺少这些信息时，clarify 仍然可以把句子改得更顺，但未必能稳定提升可用性。

使用 clarify 需要整个 impeccable repo 吗？

你主要需要的是 clarify 这个 skill，以及它依赖的上下文能力。从当前可见的目录树看，这个 skill 只暴露了 SKILL.md，没有太多额外仓库材料需要事先研究。真正关键的是，你要能访问 /frontend-design，必要时还要能运行 /teach-impeccable。

clarify 与直接让 AI 重写文案有什么不同？

普通 prompt 往往优化的是“看起来更 polished”。而 clarify skill 更适合你需要 AI 去检查理解风险的时候：比如术语负担、隐含前提、语义歧义、缺失的下一步提示，以及真实用户场景下的语气是否合适。

clarify 擅长处理错误信息吗？

是的。错误状态正是它最强的适用场景之一，因为这个 skill 会明确追问用户的心理状态和下一步动作。相比泛泛地要求“写一条更友好的错误信息”，它更容易产出真正有用的改写。

clarify 只适合 microcopy 吗？

不是。它也能帮助优化简短说明和界面引导文案。不过它最适合的是边界明确的 UI 文本，而不是长篇营销页面或内容设计系统。

什么时候不该安装 clarify？

如果你的核心需求是视觉设计评审、IA 重构，或长文档内容策略，就不建议做 clarify install。只有当产品界面里的“措辞清晰度”才是真正瓶颈时，它才值得安装。

如何改进 clarify skill 的使用效果

提供给 clarify 更好的上下文，而不是更多文本

想更快提升 clarify 输出质量，最有效的方法不是塞更多文案，而是给更清楚的约束：

• 准确的 UI 位置
• 字数或字符限制
• 用户专业程度
• 用户情绪状态
• 期望动作
• 禁止出现的表述或法律限制

只有在额外上下文会改变理解方式时，更多周边文案才有帮助。

把诊断和改写拆开

先让 clarify 给出简短的问题清单，再要求最终文案。这样你能先看清问题究竟是歧义、上下文不足，还是语气不匹配。只有先把失败类型说清楚，后续改写才会更准。

明确当前发生了什么，以及用户接下来该做什么

很多低质量输出，根本原因是模型不知道用户下一步应该做什么。所以务必同时提供：

• 刚刚发生了什么
• 用户现在应该做什么

例如，“payment failed” 这个信息本身是不完整的；除非 skill 知道正确动作是 retry、update card、contact support，还是 wait，否则它很难写对。

把 mental state 明确写出来

这个 skill 对用户心理状态的权重，比很多类似工具都高，这也是它最实用的杠杆之一。“用户压力很大且被卡住了”和“用户只是随手看看 settings”应该得到完全不同的文案。如果省略这点，输出的语气就很可能只是泛泛地“友好”，而不是真正有帮助。

让它给出带取舍的多个方案

可以要求它提供 2 到 4 个版本，并明确不同优先级，例如：

• 最短版本
• 最能安抚用户的版本
• 最强调行动的版本
• 最适合非技术用户的白话版本

这样你比较的是“清晰度取舍”，而不是把单个改写结果直接当成最终答案。

留意常见失效模式

clarify skill 仍然可能表现不佳，常见原因包括：

• 只润色措辞，却没有补上缺失上下文
• 文案更友好了，但具体性反而下降
• 把用户其实需要看到的技术术语也一并删掉
• 生成的文字长度超出 UI 组件可承载范围
• 只改了单条字符串，导致与相邻状态不一致

这些通常首先是输入问题，而不只是模型能力问题。

迭代时带上真实 UI 约束

第一轮结果出来后，再把请求收紧，例如：

• “Keep label under 24 characters”
• “Do not mention internal system names”
• “Must be understandable at 8th-grade reading level”
• “Should not blame the user”
• “Preserve security ambiguity around account existence”

做到这一步，clarify guide 才会从编辑层面的润色，走向真正可上线的生产级使用。

把 clarify 和相邻页面一起审

如果用户会连续经历一串界面，就不要只单独优化其中一条消息。应该把触发条件、消息本身，以及下一步操作一起审查。即使某一行错误提示已经很清楚，如果周围的 CTA label 或 helper text 仍然模糊，整体体验依然会失败。

建一个可复用的 prompt 模板

如果团队会反复使用 clarify for UI/UX Design，建议建立固定模板，至少包含：

• target surface
• current copy
• audience
• mental state
• desired action
• constraints
• ask: diagnose first, then rewrite

这样既能减少不同评审之间的不一致，也能显著降低把这个 skill 用好的门槛。

用真实用户证据提升 clarify 输出

如果你手头有 support tickets、usability notes，或用户误读文案的实际案例，把它们一并提供给 clarify。当它面对的是“已经观察到的真实困惑”，而不是“假设中的困惑”时，改写质量通常会明显更高。