critique

critique 概览

critique 是做什么的

critique skill 帮你从 UX 视角评估一个界面、功能、页面或组件，而不是只给出笼统的“看起来不错”之类反馈。它面向需要结构化 UI/UX Design critique skill 的人：产品设计师、创始人、PM、偏 QA 视角的评审者，以及必须说明哪里有效、哪里无效、为什么如此的 AI agents。

它实际会做什么

这个 critique skill 重点关注视觉层级、信息架构、情绪共鸣、认知负荷、启发式检查，以及可执行的建议。它真正要完成的工作不只是判断对错，而是支持决策：识别阻力、给质量打分，并输出能指导下一轮设计迭代的反馈。

最适合什么场景

当你的需求是 review、evaluate、audit 或 compare 一个设计产物，并且你希望有一套可重复的方法，而不是一个泛泛的 prompt 时，就适合用 critique。只要设计上下文是可用的，而且评审需要兼顾用户目标、约束条件和交互质量，它就很合适。

主要决策因素

这个 repo 更偏向深度 critique 工作，而不是随口点评。它的差异点在于：先收集上下文、做独立评估、基于 persona 测试，以及以评分为导向的评价方式。也正因为如此，当你在意降低评审偏差，并把观察结果转成具体产出时，critique 会特别有用。

如何使用 critique skill

安装 critique skill

skill 中记录的安装路径是通过 skills manager：npx skills add pbakaus/impeccable --skill critique。当你希望这个 skill 进入你的 agent 工作流，而不是临时复制进一次性 prompt 里时，就用这个 critique 安装步骤。

传入正确的输入

critique 的使用模式要求你提供一个要 review 的具体对象，比如功能、页面或组件。argument-hint 说得很明确：要给一个聚焦的目标，不要丢进整个产品大杂烩。好的输入示例是：“Critique the checkout shipping step for first-time mobile users” 或 “Critique this dashboard filter panel for cognitive load and clarity.”

先看对的文件

如果想快速理解 critique 的使用方式，先读 SKILL.md，再看那些决定评估质量的辅助参考文件：reference/cognitive-load.md、reference/heuristics-scoring.md 和 reference/personas.md。这些文件会告诉你这个 skill 如何评分、关注什么，以及需要模拟哪些用户视角。

用完整的 prompt 结构

更好的 prompt 会同时给出设计目标、受众、平台和变更内容。比如：Critique this onboarding modal for new enterprise admins. Goal: reduce abandonment. Context: desktop web, step 2 of 4, copy and layout were changed yesterday. 这样一来，skill 才有足够信号避免泛泛而谈，而是聚焦真实的失败模式。

critique skill 常见问题

critique 只适用于 UI/UX Design 吗？

不是。它最适合 UI/UX Design，但凡是存在层级、清晰度和交互质量问题的类界面体验，也都可以用它来 review。如果没有可评估的用户流程或布局，那么 critique skill 很可能不是合适的工具。

critique 和普通 prompt 有什么不同？

普通 prompt 往往只会产出主观评论。critique skill 多了一套方法：上下文收集、独立评估、persona 测试和打分机制。这种结构让输出更容易被信任、比较和落地。

需要设计专业背景才能用吗？

不需要。critique skill 对初学者也有帮助，因为它提供了一个清晰的评审框架。最关键的是提供足够上下文：这个界面是做什么的、给谁用、什么算成功。没有这些信息，即使 critique skill 本身很强，也还是会滑向泛泛的反馈。

什么时候不该用 critique？

不要把它用于纯技术排障、只看品牌而没有交互设计成分的 review，或者没有交互元素的内容编辑。若你只是想要一个快速、主观、不要评分也不要论证的意见，它也不适合。

如何改进 critique skill

给 skill 更清晰的 brief

质量提升最大的一步，就是把上下文补足。要包含目标界面、用户类型、设备和业务目标。Critique the pricing table 太弱；Critique the pricing table for SaaS buyers comparing plans on mobile, with the goal of increasing qualified trial starts 就好得多。

提供证据，而不只是观点

如果你已经知道哪里不对劲，就直接说明位置和原因。提到具体的流程步骤、文案标签、状态，或者看起来有问题的截图区域。这样 critique 才会聚焦在真实可用性问题上，而不是把明显的表面改动重新讨论一遍。

留意常见失败模式

最常见的问题是对产物描述不够具体，导致输出变成大而空的评论。另一个问题是只说“给点反馈”，却不说明用户任务；这样 critique 只能自己猜意图。对于 UI/UX Design 的 critique 来说，如果你把用户必须完成的主要动作，以及无障碍、移动端表现、时间压力等约束一起写清楚，评审质量会明显更高。

在第一轮之后继续迭代

先用第一轮 critique 把高风险问题和润色问题分开，再只针对最高风险区域重新运行 skill。第二轮最好改成更窄的问题，比如只看层级、文案清晰度或认知负荷，而不是让 skill 把所有内容再 review 一遍。