critique

评审

结合上下文和意图评审工作，而非依据个人喜好。

始终遵循

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

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

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

确定评审依据

检查产物以及最少量的相关 .ux/ 上下文、证据、设计系统模式、无障碍规则、已知限制和过往决策。如果评审的是实现，同时检查实际代码或差异，以及预期的 UX 来源。

如果目标不明确，先说明谨慎推断的目标，再据此评审；若不这样做会导致评审产生误导，则只提出必要的问题。

从相关角度评审

只采用与这项工作相关的角度：

• 用户目标和任务是否清晰；
• 证据和缺乏依据的假设；
• 信息层级和认知负担；
• 交互行为、分支、中断和恢复；
• 状态是否完整；
• 内容和术语；
• 无障碍和包容性使用；
• 一致性和设计系统契合度；
• 工程或服务依赖；
• 相关的信任、隐私或后果。

必要时进行比较

比较多个选项时，根据实际问题确定重要的决策标准，并用相同标准评估每个选项。不要把比较变成单纯的外观评比。“都不选”也是有效建议。

检查实现偏差

当产物是代码或 PR 时，检查 UX 行为是否发生变化或消失：状态、恢复、持久化、内容、设计系统使用、焦点和键盘行为，或验收意图。

差异不能证明运行时行为。说明仍需验证的内容，不要把推断说成事实。

优先处理评审发现

优先指出可能导致失败、用户被排除、损失、误解或重大实现偏差的问题。润色问题放在后面。

指出具体行为或元素，解释其重要性，并建议改进方向。避免使用“改善层级”这类含糊的评论，却不说明具体问题。

如果工作表现出色，就少花些篇幅肯定。不要为了找问题而凭空制造问题。

约束

仅凭视觉或代码检查，不要声称符合无障碍标准。不要臆造研究结果。没有证据时，不要为了新颖而偏离既有系统模式。

对比示例

不好：

改善视觉层级，让 CTA 更醒目，简化表单，并考虑无障碍设计。

好：

必填的出行日期尚未通过验证，主要操作却已显示为可用。这会造成虚假的可操作感：表单尚未准备就绪，用户就可以尝试继续。请在日期有效前禁用该操作，或尽早显示验证信息，让用户在提交前清楚地知道需要修正什么。

原因：好的评审指出了具体行为，解释了其后果，并给出了改进方向，而不是泛泛地提供设计建议。

示例

• “在展示给工程团队之前，帮我审查一下。”
• “给我一份严格的评审意见。”
• “根据用户问题比较这两种方案。”
• “根据预期体验审查这个 PR。”