critique

critique skill 概览

critique skill 是做什么的

critique skill 是一套结构化的 UX 评审流程，用来评估页面、功能或组件作为“被设计出来的体验”是否成立，而不只是看 UI 能不能用。它会推动模型检查视觉层级、信息架构、情绪语气、认知负荷和可用性启发式，再把这些判断转成具体反馈，而不是停留在空泛的主观看法上。

谁适合安装 critique

这个 critique skill 很适合设计师、前端工程师、产品团队，以及经常需要快速获得 UX 审核式反馈的 AI 构建者。尤其当你手上有截图、线上页面或已经做好的组件，并且想要比一句泛泛的“你觉得这个设计怎么样？”更犀利、更有诊断性的评审时，它会特别有用。

最适合解决的任务

当你的真实需求是：“告诉我这个界面为什么有效或失效，用户会卡在哪里，我应该优先改什么？”时，就该用 critique。它很适合设计评审、上线前检查、AI 生成 UI 的清理优化，以及重视优先级判断而不只是美观度的 UX Audit 类 critique 流程。

这个 skill 的不同之处

critique 最大的差异点在于它有明确立场，不是中性的泛评。它不会停在宽泛的设计评论上，而是会明确检查 “AI slop” 模式、使用启发式评分，并建议基于 persona 的测试方式。因此，相比普通的 critique prompt，它的输出更像诊断结果，也更容易复用和复现。

使用前必须知道的依赖关系

这个 skill 在实际使用中并不是独立可用的。它自己的说明要求先使用 /frontend-design skill，并遵循那个 skill 的上下文收集流程。如果当前还没有设计上下文，仓库还要求先运行 /teach-impeccable，再进入 critique。这个依赖关系，是采用前最需要先搞清楚的门槛。

如何使用 critique skill

安装上下文与仓库路径

critique skill 位于 pbakaus/impeccable 仓库的 .agents/skills/critique 目录下。如果你使用 skill loader，就从该仓库安装，并选择 critique skill。如果你的环境支持直接基于仓库加载 skill，可指向：

• pbakaus/impeccable
• skill: critique

如果你想在安装前手动检查内容，建议先看：

• .agents/skills/critique/SKILL.md
• .agents/skills/critique/reference/cognitive-load.md
• .agents/skills/critique/reference/heuristics-scoring.md
• .agents/skills/critique/reference/personas.md

第一次安装 critique 前务必先读

不要把它当成一个即插即用的 prompt 片段。这个 skill 默认你已经有前置设计上下文。仓库把 /frontend-design 标记为必需项，并要求在运行 critique 之前，先按它的协议完成上下文收集。跳过这一步，输出质量通常会明显下降，因为模型缺少目标、受众和界面意图这些关键前提。

critique skill 需要什么输入

如果想把 critique 用好，最好提供：

• 要评审的界面区域
• 截图或清晰的视觉描述
• 产品目标
• 目标用户
• 用户想完成的核心任务
• 平台、品牌、无障碍、转化目标等约束条件

只有最少输入也能跑，但当模型明确知道“什么才算成功”时，critique 的质量会高很多。

最佳调用方式

这个 skill 给出的参数提示是 [area (feature, page, component...)]。实际使用时，最好传入明确范围，例如：

• critique checkout page
• critique onboarding modal
• critique dashboard sidebar
• critique pricing page for UX Audit

像这样指定范围，比起笼统地说“critique my app”，通常能得到更可执行的反馈。

把模糊需求改写成高质量 critique prompt

弱一点的请求：

• “Critique this UI.”

更好的请求：

• “Critique this settings page for UX Audit. The goal is to help first-time users enable notifications without confusion. Audience is non-technical SMB owners. Prioritize visual hierarchy, cognitive load, and whether the main action is obvious.”

为什么这个写法更有效：

• 它说明了用户是谁
• 它说明了任务是什么
• 它说明了成功标准
• 它告诉 skill 该优先看什么

实际工作流建议

一个实用的 critique guide 流程通常是：

1. 先用 /frontend-design 收集上下文。
2. 说明产品目标和用户任务。
3. 把具体的页面、功能或组件交给 critique。
4. 要求按严重程度分组输出问题。
5. 第一轮评审后，再让它在工程限制或品牌限制下给出修订建议。

相比把 critique 和 redesign 一次性混在同一轮里，这种流程更稳定，也更可靠。

critique skill 擅长评估什么

从仓库内容来看，critique skill 最强的地方包括：

• 识别泛化、套路化的 AI 生成 UI 模式
• 评估层级和信息清晰度
• 发现认知过载
• 应用启发式评分
• 用相关 persona 对流程进行压力测试

所以它很适合做分诊：那些看起来很精致，但实际上仍然让用户失败的界面，往往能被它抓出来。

如何用好 reference 文件

这些 reference 文件的重要性，比表面看起来更高。

reference/cognitive-load.md 能帮助模型区分“任务本身就复杂”和“设计把事情做复杂了”这两件事，因此往往会带来更准确的改进建议。

reference/heuristics-scoring.md 提供了一个跨 Nielsen heuristics 的 0–4 评分框架。如果你需要在多个页面之间做可比性评审，它会很有帮助。

reference/personas.md 最好有选择地使用。优先挑 2–3 个真正符合目标用户的 persona，而不是每次都硬套全部五个。

面向 UX Audit 的 critique 好 prompt

如果你的目标是做 critique for UX Audit，建议直接要求结构化输出，例如：

• top 5 usability risks
• heuristic scores with brief evidence
• likely failure points for chosen personas
• highest-priority fixes first
• what to keep unchanged

这种格式更适合直接交给团队使用，通常不需要你再额外重写一遍。

哪些误用会拉低输出质量

最常见的误用，是在没有界面、没有截图、也没有任务上下文的情况下，直接索要设计反馈。另一个常见问题，是拿 critique skill 去从零生成全新 UI。这个 skill 更擅长评估和排序现有问题，而不是凭空发明完整设计系统。

critique skill 常见问题

critique 对新手友好吗？

友好，但前提是你至少提供基础上下文。新手只要给出一个页面和一个用户目标，通常就能很快得到价值。如果没有这些信息，critique skill 可能会听起来很专业、很有权威感，但实际却没击中真正的产品问题。

它真的比普通的 critique prompt 更好吗？

通常是的。价值不只在措辞，而在它内置的评审框架：AI slop 检测、认知负荷分析、启发式评分和 persona 测试。这让 critique usage 相比通用 prompt 更稳定，也更一致。

我一定需要先用 frontend-design skill 吗？

基本上是的。仓库把它标为必需项。如果你希望 critique install 从第一天就能发挥作用，最好把它和 /frontend-design 搭配使用，而不是单独使用。

哪些输入材料效果最好？

最理想的输入是截图、已经渲染的页面、原型，或者带有明确任务上下文的详细界面描述。单独给代码帮助不大，除非 UI 行为已经被描述清楚，或者能直接看见界面效果。

什么情况下不该用 critique？

当你需要下面这些能力时，不建议用 critique：

• 深入到代码层面的实现评审
• 单独完成无障碍合规审计
• 基于 analytics 的转化诊断
• 在没有现有界面的前提下做完整重设计

它本质上是一个偏 UX 的评估器，不是各类专项审计的替代品。

critique 能比较多个设计方案吗？

可以。如果你明确要求 comparative scoring 和 tradeoffs，它很适合做并排评审。关键是给每个方案提供相同的任务背景和受众上下文，这样比较才公平。

如何改进 critique skill 的使用效果

不要只给界面，要把界面目标也告诉模型

想提升 critique 结果，最有效的一件事，就是说明这个界面到底要达成什么目标。仓库里也明确要求这么做。一个画面再漂亮，如果核心任务不清晰，依然可能失败；而这个 skill 本来就是为抓出这类问题而设计的。

要求输出包含严重程度、证据和修复建议

如果你希望结果能直接推动行动，可以要求 critique skill 按下面格式输出：

• issue
• why it matters
• evidence in the UI
• severity
• recommended fix

这样可以避免空泛评论，也更方便团队做优先级判断。

选择真正匹配目标受众的 persona

只有在 persona 选得准时，persona 测试的价值才会明显提高。例如：

• onboarding 场景选 first-time user
• 高密度 dashboard 场景选 impatient power user
• 金融或高风险操作流程选 anxious user

如果每次都把所有 persona 全部套上，反而会稀释 critique 的判断力度。

用具体约束强化弱 prompt

一个更强的 critique guide prompt，通常会包含这类约束：

• mobile-only
• brand cannot change colors
• must keep current information architecture
• engineering team can only make low-effort fixes this sprint

约束越明确，给出的建议通常越现实、越能落地。

留意最常见的失败模式

最典型的失败模式，是输出看起来很会说、很有设计感，但没有真正连到用户任务上。如果第一轮结果太泛，可以继续追问：

• “Which issue most likely blocks task completion?”
• “What would confuse a first-time user in the first 10 seconds?”
• “Which recommendation has the highest impact with lowest implementation effort?”

谨慎使用启发式评分

评分很适合做比较和排优先级，但也容易制造一种“精确到数字”的假象。最好要求每个分数下面都附上简短证据。这样能让 critique skill 始终锚定在可见的 UI 问题上，而不是变成随意打分。

把 critique 分成两轮运行

一种高质量的工作流是：

1. 第一轮：诊断问题
2. 第二轮：在真实约束下细化解决方案

把诊断和重设计拆开，通常能让结论更清晰，也更值得信任。

第一轮 critique 之后，继续喂回修正信息

第一轮跑完后，可以继续补充：

• 对用户的修正判断
• 修改后状态的截图
• 模型忽略掉的约束
• 团队认同或不认同的发现点

当你把 critique skill 当作一个可迭代的评审者，而不是一次性裁判时，它的表现通常会更好。

把它用在最有优势的场景里

这个 critique skill 最有价值的地方，是那些表面看起来很 polished、但可能暗藏 UX 问题的界面：AI 生成 landing page、dashboard、onboarding flow、settings panel，以及信息密度高的功能界面。在这些场景里，它的反模式识别和认知负荷分析，最能带来额外的信息增益。

采用前先想清楚这个 tradeoff

这个 tradeoff 很直接：critique 能比普通 prompting 提供更严格、更成体系的 UX 反馈，但前提是你愿意提供上下文，并接受它这种有明确框架和判断标准的工作方式。如果你只想快速要一个轻量、临时性的看法，普通 prompt 可能更快；如果你要的是可复用、可比较的 critique for UX Audit，那这个 skill 会更合适。