critique

步骤

步骤 1：准备

调用 /impeccable，其中包含设计原则、反模式和Context Gathering Protocol。继续之前，请遵循该协议。如果尚无设计上下文，必须先运行 /impeccable teach。此外，还要了解：界面试图实现什么目标。

步骤 2：收集评估结果

发起两项独立评估。两项评估都不应看到另一项的输出，以避免偏见。

你应该将每项评估分别委派给不同的子 Agent，以确保独立性。使用环境提供的 Agent 启动机制（例如 Claude Code 的 Agent 工具或 Codex 的子 Agent 启动机制）。子 Agent 应以结构化文本返回调查结果。此时不要向用户输出调查结果。

如果当前环境不支持子 Agent，请按顺序完成每项评估，并在继续之前将调查结果写入内部笔记。

标签页隔离：如果可以使用浏览器自动化，每项评估都必须新建自己的标签页。绝不要重复使用现有标签页，即使其中一个标签页已打开正确的 URL 也不例外。这样可以避免两项评估相互干扰页面状态。

评估 A：大模型设计评审

阅读相关源文件（HTML、CSS、JS/TS）；如果可以使用浏览器自动化，还要直观检查线上页面。为此新建一个标签页；不要重复使用现有标签页。导航后，通过设置文档标题为以下内容来标记标签页：

document.title = '[LLM] ' + document.title;

像设计总监一样进行评估。评估以下方面：

AI 套路检测（关键）：这看起来是否像其他所有 AI 生成的界面？对照 impeccable 技能中的所有禁用项进行检查。检查 AI 配色、渐变文字、暗色光晕、玻璃拟态、主视觉指标布局、雷同的卡片网格、通用字体，以及其他所有典型特征。测试方法：如果有人说“这是 AI 做的”，你会不会立刻相信？

整体设计评审：视觉层级（视线流向、主要操作是否清晰）、信息架构（结构、分组、认知负荷）、情感共鸣（是否符合品牌和受众？）、可发现性（交互元素是否显而易见？）、构图（平衡、留白、节奏）、排版（层级、可读性、字体选择）、色彩（用途是否明确、是否协调、是否易于访问）、状态与边缘情况（空状态、加载中、错误、成功）、微文案（清晰度、语气、实用性）。

认知负荷（参阅 cognitive-load）：

• 执行认知负荷 8 项检查清单。报告未通过项数：0-1 = 低（良好），2-3 = 中等，4+ = 严重。
• 统计每个决策点可见选项的数量。如果 >4，请标记。
• 检查是否采用渐进式披露：是否只在需要时才呈现复杂内容？

情感历程：

• 这个界面会唤起什么情绪？这是有意为之的吗？
• 峰终定律：最强烈的时刻是否积极？体验的结尾是否令人满意？
• 情绪低谷：检查高风险时刻（付款、删除、提交）是否会引发焦虑。是否有设计干预措施（进度指示器、安抚文案、撤销选项）？

Nielsen 启发式评估（参阅 heuristics-scoring）： 对 10 项启发式原则逐项按 0-4 分评分。报告中将展示这些评分。

以结构化形式返回调查结果，涵盖：AI 套路评估结论、启发式评分、认知负荷评估、做得好的方面（2-3 项）、优先问题（3-5 项，包含问题是什么、为什么以及如何修复）、次要观察，以及具有启发性的问题。

评估 B：自动检测

运行捆绑的确定性检测器，该工具会标记 25 种特定模式（AI 垃圾内容的迹象 + 通用设计质量问题）。

CLI 扫描：

npx impeccable --json [--fast] [target]

• 将 HTML/JSX/TSX/Vue/Svelte 文件或目录作为 [target] 传入（即任何包含标记语言的内容）。不要传入仅包含 CSS 的文件。
• 对于 URL，请跳过 CLI 扫描（它需要 Puppeteer）。改用浏览器可视化。
• 对于大型目录（200 个以上可扫描文件），使用 --fast（仅正则表达式，跳过 jsdom）
• 对于 500 个以上文件，缩小范围或询问用户
• 退出代码 0 = 无问题，2 = 发现问题

浏览器可视化（当浏览器自动化工具可用且目标是可查看的页面时）：

叠加层是供用户使用的视觉辅助工具。它会在用户的浏览器中直接突出显示问题。不要滚动页面来截取叠加层的屏幕截图。请改为读取控制台输出，以编程方式获取结果。

1. 启动实时检测服务：

   npx impeccable live &
   

   记下打印到标准输出的端口（自动分配）。使用 --port=PORT 固定端口。
2. 新建标签页并导航到页面（本地文件请使用开发服务器 URL，也可以使用直接 URL）。不要重复使用现有标签页。
3. 使用 javascript_tool 为标签页添加标签，方便用户辨认：

   document.title = '[Human] ' + document.title;
   

4. 滚动到顶部，确保注入前页面已滚动到最顶部
5. 使用 javascript_tool 注入（将 PORT 替换为步骤 1 中的端口）：

   const s = document.createElement('script'); s.src = 'http://localhost:PORT/detect.js'; document.head.appendChild(s);
   

6. 等待 2-3 秒，让检测器渲染叠加层
7. 使用 read_console_messages 和模式 impeccable 读取控制台结果。检测器会以 [impeccable] 前缀记录所有发现。不要滚动页面来截取叠加层的屏幕截图。
8. 清理：完成后停止实时服务：

   npx impeccable live stop
   

对于多视图目标，请在 3-5 个有代表性的页面上注入。如果注入失败，则仅使用 CLI 结果继续。

返回：CLI 发现（JSON）、浏览器控制台发现（如适用）以及记录的误报。

第 3 步：生成综合评审报告

将两项评估综合成一份报告。不要简单拼接。将各项发现融会贯通，指出 LLM 评审与检测器意见一致之处、检测器发现而 LLM 遗漏的问题，以及检测器发现中的误报。

请以设计总监的视角组织反馈：

设计健康评分

请参阅 heuristics-scoring

将 Nielsen 的 10 项启发式评分列为表格：

#	启发式原则	评分	关键问题
1	系统状态的可见性	?	[具体发现，或在表现良好时填“无”]
2	系统与现实世界的匹配	?
3	用户控制权与自由度	?
4	一致性与标准	?
5	错误预防	?
6	识别而非回忆	?
7	灵活性与效率	?
8	美观与极简设计	?
9	错误恢复	?
10	帮助与文档	?
总分		??/40	[评级区间]

评分务必诚实。4 分代表确实出色。大多数真实界面的得分为 20-32 分。

反模式评估

从这里开始。 看起来像是 AI 生成的吗？

LLM 评估：自行评估 AI 垃圾内容的迹象。涵盖整体美感、布局雷同、构图泛泛，以及缺少个性化表达的机会。

确定性扫描：总结自动检测器的发现，包括数量和文件位置。指出检测器发现而你遗漏的其他问题，并标记任何误报。

视觉叠加层（如使用了浏览器）：告知用户，叠加层现在显示在其浏览器的 [Human] 标签页中，并突出显示检测到的问题。总结控制台输出报告的内容。

整体印象

简要说说直观感受：哪些方面有效、哪些方面不理想，以及最重要的改进机会。

做得好的方面

指出 2-3 项做得好的内容。具体说明它们为何有效。

优先问题

按重要性排序，列出影响最大的 3-5 个设计问题。

每个问题都要标注 P0-P3 严重级别（严重级别定义请参阅 heuristics-scoring）：

• [P?] 问题：清楚地指出问题
• 为何重要：说明这会如何影响用户或损害目标
• 修复方案：说明如何处理（具体明确）
• 建议命令：可以处理此问题的命令（从以下选择：/animate、/quieter、/shape、/optimize、/adapt、/clarify、/layout、/distill、/delight、/audit、/harden、/polish、/bolder、/typeset、/critique、/colorize、/overdrive）

用户画像警示

请参阅 personas

自动选择与此界面类型最相关的 2-3 个用户画像（使用参考文档中的选择表）。如果 .github/copilot-instructions.md 包含来自 impeccable teach 的 ## Design Context 部分，也要根据受众／品牌信息生成 1-2 个项目专属用户画像。

针对每个选定的用户画像，逐步梳理其主要用户操作，并列出发现的具体警示：

Alex（高级用户）：未发现键盘快捷键。完成主要操作需要点击 8 次。被迫接受模态引导。用户流失风险高。

Jordan（首次使用者）：侧边栏中的导航只有图标。错误消息包含技术术语（“404 Not Found”）。没有可见的帮助信息。用户会在第 2 步放弃。

具体说明哪些元素和交互让每个用户画像受阻。不要写笼统的用户画像描述；要指出具体的问题所在。

次要观察

简要记录值得处理的较小问题。

值得思考的问题

提出能够启发更好解决方案的问题：

• “如果主要操作更加醒目，会怎样？”
• “这里真的需要如此复杂吗？”
• “更令人安心的版本会是什么样？”

请记住：

• 直截了当。含糊的反馈会浪费所有人的时间。
• 具体明确。说“提交按钮”，而不是“某些元素”。
• 说明问题所在，以及它为何会影响用户。
• 给出具体建议，而不只是说“可以考虑探索……”
• 严格确定优先级。如果所有事情都重要，那就没有什么真正重要。
• 不要弱化批评。开发者需要坦诚的反馈，才能交付出色的设计。

第 4 步：询问用户

呈现发现后，根据实际发现提出有针对性的问题。直接询问用户你无法推断的信息。用户的回答将影响行动计划。

根据具体发现调整问题，可参考以下方向（不要照搬泛泛的问题）：

1. 优先方向：根据发现的问题，询问用户目前最重视哪一类。例如：“我发现了视觉层级、色彩运用和信息过载方面的问题。我们应该先处理哪一项？”提供排名靠前的 2-3 个问题类别供选择。

2. 设计意图：如果评审发现风格调性不匹配，询问这是否是有意为之。例如：“界面给人的感觉冷淡而商务。这是预期的调性吗？还是应该更温暖／大胆／活泼？”根据问题的解决方向，提供 2-3 种调性选择。

3. 范围：询问用户想处理多少内容。例如：“我发现了 N 个问题。你想全部处理，还是只关注最重要的 3 个？”提供范围选项，例如“仅处理前 3 个”“处理所有问题”“仅处理关键问题”。

4. 限制条件（可选；仅在相关时询问）：如果发现的问题涉及多个方面，询问是否有任何部分不能改动。例如：“是否有任何部分应保持现状？”这样可以避免计划改动用户认为已经完成的内容。

提问规则：

• 每个问题都必须提及报告中的具体发现。不要提出“你的受众是谁？”之类的泛泛问题。
• 最多提出 2-4 个问题。尊重用户的时间。
• 提供具体选项，不要提出开放式问题。
• 如果发现很明确（例如，只有 1-2 个清晰的问题），则跳过提问，直接进入第 5 步。

步骤 5：推荐操作

收到用户的回答后，根据用户在步骤 4 中提出的优先级和范围，呈现按优先级排序的操作摘要。

操作摘要

根据用户的回答，按优先级列出推荐的命令：

1. /command-name：简要说明要修复的问题（结合评审结果中的具体情况）
2. /command-name：简要说明（结合具体情况） ...

推荐规则：

• 仅推荐以下命令：/animate、/quieter、/shape、/optimize、/adapt、/clarify、/layout、/distill、/delight、/audit、/harden、/polish、/bolder、/typeset、/critique、/colorize、/overdrive
• 先按用户明确提出的优先级排序，再按影响排序
• 每项的说明应提供足够的背景，让命令知道应关注什么
• 将每个优先问题对应到合适的命令
• 跳过不会解决任何问题的命令
• 如果用户选择了有限范围，则仅包含该范围内的项目
• 如果用户将某些区域标记为不可触及，则排除会涉及这些区域的命令
• 如果推荐了任何修复操作，最后一步以 /polish 结束

呈现摘要后，告诉用户：

你可以让我逐项运行这些命令、一次全部运行，也可以按任意顺序运行。

修复后重新运行 /critique，查看评分提升。