critique

critique skill 概览

critique skill 是做什么的

critique skill 是一套结构化的 UX 与产品设计评审流程，用来把页面、功能或组件当作真实用户体验来评估，而不只是把它看成视觉稿。它会引导模型检查视觉层级、信息架构、情绪语气、认知负荷、可用性启发式原则，以及不同 persona 的使用阻力，并进一步把这些判断转化为可执行的反馈。

谁适合安装 critique

这个 critique skill 特别适合已经有界面、原型或已上线产品的产品设计师、前端工程师、创始人和 AI 构建者。如果你想要的不是泛泛的“帮我看看这个 UI”，而是更有判断力的评审，它会很合适。尤其是在做 critique for UX Audit、上线前设计 QA，或者想判断一个界面是否显得套路化、令人困惑、信息过重时，这个 skill 很有价值。

它真正要解决的问题

大多数用户并不只是想听一些主观看法，他们真正想知道的是：

• 目前最先伤害体验的问题是什么
• 这个 UI 看起来是否过于雷同，或者像“AI-generated”
• 哪些问题只是表面美观问题，哪些会真正阻碍转化
• 在没有完整设计团队的情况下，该如何排优先级去修

这个 skill 就是围绕这类实际需求设计的。它把 critique 定位成决策工具，而不是风格点评。

这个 critique 有什么不同

它最明显的差异，在于非常强调上下文，以及内置了“AI slop detection”这一步。它不会一上来就停留在表层反馈，而是先要求设计背景信息，并且明确检查界面里是否出现了 2024–2025 常见的 AI 产品套路，比如通用化的卡片网格、过度发光的暗色主题、层级薄弱、以及看起来像模板拼出来的构图。

它也不只是单一视角的点评，而是把以下几种分析方式结合在一起：

• design-director 风格的 critique
• cognitive load 分析
• heuristic scoring
• 基于 persona 的测试

采用前必须知道的限制

critique 并不是完全独立可用的。仓库里把 frontend-design 设为必需依赖，用来提供原则与上下文收集；如果当前还没有设计上下文，还要求先运行 teach-impeccable。如果你想找的是零准备、装完就能直接用的 critique，这条依赖链是采用前最需要先了解的事。

如何使用 critique skill

先把上下文装好，再依赖 critique

这个仓库把 critique 放在 .claude/skills/critique 下，而且 skill 文本里明确依赖 /frontend-design。实际使用时，最好安装完整的 impeccable skill 集，而不是把这个文件夹当成一个孤立的 prompt 文件来用。

如果你的 skill runner 支持 GitHub skill 安装，建议直接从仓库安装，然后确认 critique、frontend-design 和 teach-impeccable 都可用。

先看这几个文件，再决定是否安装

如果你想快速判断值不值得装，优先看这些文件：

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

这条阅读路径基本能让你迅速看清核心信息：前置条件、评审工作流、评分模型，以及它做用户测试时采用的视角。

critique skill 需要哪些输入

当你提供以下信息时，critique skill 的表现会明显更好：

• 界面材料：截图、mockup、URL 或组件说明
• 评审范围：页面、流程、modal、dashboard、onboarding、settings 等
• 用户的核心目标
• 产品背景与目标用户
• 约束条件：mobile/desktop、B2B/B2C、accessibility、conversion、技术限制

如果没有这些上下文，模型依然可以对布局和美观做评论，但无法判断这个界面是否真的适合要完成的任务。

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

弱 prompt：

• “Critique this UI.”

更强的 critique 用法：

• “Use the critique skill on this onboarding flow. The product helps finance teams close books faster. Primary goal: get a first report generated in under 5 minutes. Audience: mid-market accounting teams. Constraint: desktop web app, dense data is acceptable but first-time clarity matters. Please evaluate AI-slop signals, hierarchy, cognitive load, heuristic score, and test it as a first-timer and power user.”

之所以后者效果更好，是因为它给了这个 skill 明确的优化目标，而不只是丢给它一个对象让它随便评价。

按仓库要求完成前置准备

这个 skill 的说明写得很明确：先运行 /frontend-design，并遵循它的上下文收集流程。如果还没有设计上下文，就在 critique 之前先跑 /teach-impeccable。也就是说，设计上的预期工作流是：

1. 收集设计上下文
2. 理解这个界面到底想完成什么
3. 围绕这个目标运行 critique
4. 返回有优先级的反馈

如果跳过第 2 步，输出通常会变得比较泛，因为模型无法分辨“有意的信息密度”与“糟糕的设计”之间的区别。

用 critique 做 UX Audit 更合适

如果你的场景是 critique for UX Audit，不要只说“给点反馈”。更好的要求是：

• 按严重程度列出主要问题
• 给出 heuristic scoring 摘要
• 指出用户最可能流失的节点
• 标出不同 persona 的失败模式
• 提供具体的 redesign 建议

这样能把结果从“评论”推进到更接近 audit 级别的输出，方便利益相关方直接采取行动。

这个工作流实际上在检查什么

结合仓库内容来看，critique skill 最擅长检查的是：

• AI-generated 设计的同质化问题
• 视觉层级问题
• 认知过载
• 信息架构薄弱
• 交互模式不清晰
• 可用性启发式缺口
• 界面语气与用户需求不匹配

因此，它更适合评估已经上线或足够接近真实使用场景的 UI，而不是拿来做从零开始的概念脑暴。

推荐的 critique 使用流程

一个实用的工作流如下：

1. 收集界面截图和目标
2. 说明用户类型与成功标准
3. 用 critique 聚焦某个具体区域，而不是一次性审整个产品
4. 先看最严重的 3 个问题
5. 在澄清约束后，再要求给出修订建议
6. 对下一个流程重复

实际经验上，按页面或按 flow 使用 critique skill，通常比一次性要求它评整个产品更有信号、更有结论。

如何把请求范围收得更合适

好的范围：

• signup flow
• pricing page
• analytics dashboard
• settings panel
• empty state
• mobile checkout

不好的范围：

• “the whole app”
• “our design system”
• “everything on the website”

这个 skill 的分析颗粒度比较细，一旦范围过大，输出就容易变浅。把评审区域收窄，通常能明显提升具体性和优先级判断。

能提升输出质量的实用技巧

想让 critique 用起来更准，最好补上这些信息：

• 一句话说明业务目标
• 一句话说明用户的紧迫性
• 一句话说明什么叫成功
• 任何你不希望模型“顺手改掉”的已知约束

例如：

• “This page exists to get a team admin to invite coworkers immediately after signup. Speed matters more than education. We cannot remove required compliance messaging.”

这种输入能帮助 skill 分辨哪些是真问题，哪些只是必要复杂度。

critique skill 常见问题

critique 比普通 UX prompt 更好吗？

通常是的，前提是你想要一种可重复的评审方法。critique skill 的价值不在于它有什么神奇审美，而在于它内置了清晰结构：前置上下文、反模式检测、heuristic scoring、cognitive load 框架，以及 persona 测试。普通 prompt 也许能给出不错的意见，但一致性更差，也更容易滑向泛泛表扬。

critique 对新手友好吗？

大体上友好，但有一个前提：它依赖 frontend-design，有时还需要 teach-impeccable。新手当然也能用 critique，但要预期自己得先花几分钟理解它的预期工作流，而不是什么都不准备就直接丢一个 prompt 进去。

什么情况下 critique 不适合用？

以下场景建议跳过这个 critique skill：

• 你需要的是代码生成，而不是设计评审
• 你只有模糊的产品想法，还没有界面
• 你当前更需要的是品牌策略或文案
• 你完全提供不了任何用户或产品上下文

它当然也能只对视觉做点评，但那并不是它最有差异化优势的地方。

critique 只能评审已经打磨好的 UI 吗？

不是。它同样可以用于 wireframe、粗略 mock 和早期组件，尤其适合看层级和认知负荷。但如果要做 persona 测试和 heuristic scoring，前提还是交互模型要足够可见，才能让判断更可信。

可以只拿一个组件来用 critique 吗？

可以，只要这个组件在真实上下文中承担明确任务。像 filter panel、modal、table 或 form，都适合用 critique。关键是你要说明它出现在哪里、谁在使用它，以及用户试图完成什么。

我应该期待什么样的输出？

一个好的 critique 输出，应该包含：

• 主要 UX 风险
• 严重程度或优先级
• 这些问题为什么重要
• 可以改什么的具体示例
• 明确区分表层 polish 问题和结构性 UX 问题

如果结果大多只是一些形容词，那大概率是 prompt 里缺少了上下文。

如何改进 critique skill 的使用效果

给 critique 一个成功指标，不要只给一张界面图

想最快提升 critique 输出质量，最有效的方法就是说明你希望用户最终达成什么结果。比如，“Review this dashboard” 就明显弱于 “Review this dashboard for whether a new manager can spot blockers in under 30 seconds.” 成功指标会让后续所有判断都更聚焦。

提供目标用户和产品成熟度

同一个界面，可能会是：

• 对高熟练度操作用户来说很合适的密集型 B2B 工具
• 对第一次上手的消费者来说不合适
• 对内部工具来说可以接受
• 对高端面向客户的产品来说偏弱

如果你把受众和成熟度说清楚，critique skill 就能评估权衡，而不是默认套用主流 UX 建议。

明确指定要测哪些 persona

仓库里提供了多个 persona，但并不是每次都全部相关。做 critique for UX Audit 时，最好直接指出最重要的是哪些用户类型，例如：

• first-timer
• power user
• cautious admin

这样可以避免输出把注意力分散到无关的失败模式上。

第一轮之后强制它做优先级排序

一个常见失败模式是：列了很长一串观察，却没有决策价值。完成第一轮 critique 后，继续追问：

• “Which 3 issues most threaten task completion?”
• “Which issue is most likely to reduce trust?”
• “What should be fixed before launch versus later?”

这样才能把分析推进成行动计划。

明确告诉模型必须遵守哪些约束

如果你的界面必须保持以下特征：

• data-dense
• enterprise-looking
• compliant
• on-brand
• mobile-first
• low-engineering-effort

那就直接说清楚。否则，critique 很容易给出“看起来更干净”但实际上并不落地的 redesign 建议。

留意不要对“AI slop”过度矫正

这个 critique skill 的一个优势，是能识别千篇一律的 AI 风格设计。但也不要因此走向另一个极端：为了显得不一样，就把所有现代常见模式都删掉。更好的问题应该是，这个设计是否既有辨识度又适合任务，而不只是“跟别人不一样”。可以把这一部分当作识别懒惰同质化的工具，然后再用可用性去验证修正方案。

用前后版本迭代来提升输入质量

最佳实践通常是：

1. 先对当前设计运行 critique
2. 应用或模拟 2–3 个重大修改
3. 再对修订版运行 critique
4. 比较主要风险是否真的下降

把它当成迭代式设计闭环来用，而不是一次性判决，这个 skill 的价值会大很多。

critique 输出发虚，常见原因有哪些

通常是下面这些信息缺了一项或多项：

• 没有用户目标
• 没有产品上下文
• 范围过大
• 没有约束条件
• 没有足够可供检查的界面材料质量
• 只是让它说“thoughts”，而不是给出明确的评审结构

把这些补齐之后，这份 critique guide 的可执行性通常会明显提升。

一份更强的 critique 使用 prompt 模板

可以直接用这样的 prompt：

• “Use the critique skill on [area].
• Product: [what the product does]
• Audience: [who this is for]
• Primary task: [what the user needs to do]
• Success metric: [what success looks like]
• Constraints: [platform, compliance, technical, brand]
• Review for: AI-slop signals, hierarchy, cognitive load, heuristics, and 2 relevant personas.
• Output: top issues, severity, why they matter, and concrete fixes.”

这个模板和仓库希望 critique 运作的方式高度一致，通常也会比开放式提问产出更高质量的结果。