critique

步骤

步骤 1：准备

收集有关待评审界面的背景信息：它要实现什么目标、谁会使用它，以及在哪里可以找到相关源文件。如果存在 .impeccable.md 或 .github/copilot-instructions.md 中的 ## Design Context 区块，现在就阅读，了解品牌和受众。阅读现有的设计系统（CSS / 令牌 / 主题，以及一个有代表性的组件），确保评审依据的是项目自身的规范，而非通用默认标准。

步骤 2：收集评估结果

启动两项独立评估。两者都不得查看对方的输出，以避免偏见。

仅在获得授权且条件允许时，才将各项评估分别委派给独立的子 Agent。条件允许时，使用当前环境提供的子 Agent 或委派机制。子 Agent 应以结构化文本返回发现。此时不要向用户输出发现。

否则，按顺序完成两项评估，并在阅读扫描输出前记录设计评审结果。说明报告采用了隔离 Agent，还是在单一上下文中按顺序评审；绝不可声称并未实现的独立性。除非用户要求保持运行，否则在报告前停止仅为本次评审启动的任何服务。

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

评估 A：大模型设计评审

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

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

评估以下维度：

设计独特性：构图、交互和视觉语言是否根植于本产品，还是可以原样用于无关产品？必须在查看扫描输出前作出判断；某种视觉模式本身并不构成缺陷。

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

认知负荷（参考 认知负荷）：

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

情感历程：

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

Nielsen 启发式原则（参考 启发式评分）： 为适用的启发式原则打 0-4 分。对于确实不适用的原则，标记为 n/a 并说明原因，例如简单营销页面无需专家级快捷操作。最高分为已评分原则数量的四倍；绝不可将 n/a 视为零分或满分。

返回结构化发现，涵盖：设计独特性结论、启发式评分、认知负荷评估、有效之处（2-3 项）、优先问题（3-5 项，说明问题是什么、为何重要以及如何修复）、次要观察，以及发人深省的问题。

评估 B：自动化模式扫描

使用可用工具，对 AI 垃圾内容特征和一般设计质量问题进行确定性扫描。

静态文件扫描（可访问源文件时）：

读取 HTML、JSX、TSX、Vue 或 Svelte 文件，并搜索以下模式：

• 渐变文字（bg-gradient + bg-clip-text、WebkitBackgroundClip）
• 玻璃拟态（backdrop-blur、bg-white/10、叠加层上的 bg-opacity）
• 主视觉指标布局（孤立的大号数字、独立显示的 text-6xl 及以上统计数据）
• 通用 AI 配色（将 #6366f1、#8b5cf6、#f59e0b 用作未自定义的主色）
• 相同的卡片网格（grid-cols-3 中重复出现 3 个或更多结构相同的卡片）
• 冗余文案（替代文本重复可见文本、标签与占位文本内容相同）
• 弹跳缓动（动画类中的 bounce、elastic）
• 彩色背景上的灰色文字
• 嵌套卡片（卡片内含卡片）

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

如果项目配置了 lint 或设计检查工具（查看 package.json 脚本），请运行该工具。否则，使用浏览器开发者工具检查实时页面的视觉效果。新建一个标签页；不要重复使用现有标签页。为标签页添加以下标记：

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

返回：包含文件位置和数量的扫描结果，以及注明的任何误报。

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

综合两项评估，形成一份报告。不要简单地将两者拼接起来。将发现融会贯通，指出 LLM 评审与检测器在哪些方面结论一致、检测器发现了哪些 LLM 遗漏的问题，以及哪些检测结果属于误报。

请以设计总监的视角组织反馈。直接指出问题，不要委婉其辞——开发者需要诚实的反馈，才能交付出色的设计；含糊或有所保留的意见只会浪费大家的时间。

设计健康度评分

请参阅 heuristics-scoring

以表格形式给出 Nielsen 的 10 项启发式原则评分：

#	Heuristic	Score	Key Issue
1	系统状态可见性	?	[具体发现，若表现良好则填「不适用」]
2	系统与现实世界的匹配	?
3	用户控制与自由	?
4	一致性与标准	?
5	错误预防	?
6	识别而非回忆	?
7	灵活性与效率	?
8	美观与极简设计	?
9	错误恢复	?
10	帮助与文档	?
总计		??/[适用最高分]	[评级区间]

只有当界面在相应启发式原则上不存在实质问题时，才可给 4 分。生产级界面的常见分数范围为 20-32，通常存在一些不足。

设计独特性结论

从这里开始。 这个成果看起来是专为该产品设计的吗？

设计评估：给出扫描结果之前的评估。说明设计是否协调、结构是否可与其他类别的产品互换，以及是否错失了体现产品个性的机会。

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

浏览器证据：描述检查过的页面和实际结果。只有在注入成功且检测器在页面中运行时，才能声称发现了可见叠加层。如果没有创建叠加层，请报告普通截图或人工检查的结果，并说明哪些步骤无法执行或尚未测试。

总体印象

用一段话说明哪些方面有效、哪些方面失败，以及最大的改进机会。

做得好的地方

指出 2-3 个做得好的方面，并说明具体元素名称、可见行为及其有效的原因。

优先问题

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

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

• [P?] 问题是什么：清楚说明问题
• 为什么重要：说明这会如何伤害用户或削弱目标
• 修复方案：说明如何处理（具体可行）
• 建议命令：说明可以用哪个可用的技能或命令来解决

Persona 警示

请参阅 personas

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

对于每个选定的 Persona，逐步分析其主要用户操作，并列出发现的具体警示：

Alex（高级用户）：未检测到键盘快捷键。完成主要操作需要点击 8 次。强制弹出模态框进行引导。用户极有可能中途放弃。

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

具体说明。指出哪些确切的元素和交互无法满足各 Persona 的需求。不要写泛泛的 Persona 描述；要说明哪些地方出了问题。

次要观察

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

每个优先问题都必须说明相关元素、对用户的影响和修复方案。次要观察仅限于有明确位置或来源引用的发现。

值得思考的问题

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

• “如果让主要操作更加醒目，会怎样？”
• “一定要设计得这么复杂吗？”
• “更有信心的设计会是什么样子？”

第 4 步：询问用户

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

根据以下方向提问（结合具体发现进行调整；不要提出泛泛的问题）：

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

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

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

4. 限制条件（可选；仅在相关时提问）：如果发现的问题涉及多个区域，询问是否有不可更改的部分。例如：“是否有任何部分需要保持原样？”避免计划触及用户认为已经完成的部分。

提问规则：

• 每个问题都必须指向报告中的具体发现。绝不要泛泛地问“你的受众是谁？”。
• 最多提出 1-3 个问题；如有可用的 harness 结构化提问机制，请使用。只询问会影响结果且尚未明确的范围或意图；保留现有授权。
• 先呈现报告，再提问，以便用户评估这些发现。
• 提供具体选项，不要提出开放式问题。
• 如果发现的问题很明确（例如只有 1-2 个清晰的问题），请跳过提问，直接进入第 5 步。

第 5 步：建议行动

收到用户的回答后，根据用户在第 4 步表达的优先级和范围，提供按优先级排序的行动摘要。

操作摘要

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

1. /command-name：简要说明要修复的问题（包含批评结果中的具体上下文）
2. /command-name：简要说明（包含具体上下文） ...

推荐规则：

• 仅推荐当前环境中实际可用的命令或技能
• 首先按用户说明的优先级排序，然后按影响排序
• 每项的描述都应包含足够的上下文，说明命令应关注的内容
• 将每个优先问题对应到适当的命令
• 跳过不会解决任何问题的命令
• 如果用户选择了有限范围，则只包含该范围内的项目
• 如果用户将某些区域标记为禁止修改，则排除会涉及这些区域的命令
• 如果推荐了任何修复措施，请将润色／清理步骤作为最后一项建议

呈现摘要后，告诉用户：

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

修复后重新运行 /critique，查看分数是否提高。