Impeccable Critique 深度指南：双 Agent 设计评审、Nielsen 启发式评分与快照趋势追踪

/impeccable critique 是 Impeccable 技能集中负责"设计评估"的命令：它先锁定一个稳定的评审目标，再以两个互相隔离的评估通道（LLM 设计审查 + 确定性检测器/浏览器证据）交叉取证，最终合成一份设计总监视角的结构化评审报告，并把本次运行持久化为可追踪趋势的快照，最后带着针对性问题询问用户下一步改进方向。读完本文，你将掌握这套评审流程的完整执行协议——从目标 slug 解析、双 Agent 编排、认知负荷与 10 条 Nielsen 启发式评分，到报告交付、快照持久化与趋势读取，并能结合仓库源码理解 critique-storage 的底层实现原理。

该命令的官方定位在 command-metadata.json 中有明确描述：从 UX 视角评估设计，覆盖视觉层级、信息架构、情感共鸣、认知负荷与整体质量，输出量化评分、基于人物角色的测试、自动化反模式检测与可执行反馈；当你希望"review / critique / evaluate / give feedback on a design or component"时使用。本文将这条命令的完整协议（见 reference/critique.md）逐层展开，并深入其 Rust 实现与 CLI 契约。

命令定位与一次完整运行的全貌

一次 critique 运行由六个连续阶段组成，每一阶段的产物都是下一阶段的输入：

1. Setup：解析目标为具体文件路径或 URL，确认 slug，读取 .impeccable/critique/ignore.md。
2. Assessment Orchestration：把评估 A（设计审查）与评估 B（检测器/浏览器证据）分派给两个隔离的子 Agent。
3. Generate Combined Critique Report：合成两份评估为一份结构化评审报告（聊天响应是主交付物）。
4. Deliver the Report：先把完整报告写进聊天响应，再做任何持久化工作。
5. Persist the Snapshot：将报告写入 .impeccable/critique/，供 /impeccable polish 继承优先问题，并读取趋势。
6. Ask the User：以 2–4 个锚定具体发现的针对性问题收尾（或输出 Questions skipped: <reason>）。

关键心法：聊天响应是主交付物，快照只是本次运行的归档。报告若只存在于 .impeccable/critique/ 目录里，这次运行等于什么都没产出。

硬性不变量：评审质量的底线

在开始之前，先明确 critique 协议中不可妥协的约束。违反任何一条都构成一次失败的评审运行：

• 双评估通道必须齐全：评估 A（设计审查）与评估 B（检测器/浏览器证据）都必需。
• 隔离优先：只要会话暴露了 sub-agent / Task 工具，A 与 B 就必须作为两个隔离的子 Agent 运行。在当前上下文中内联运行"可能可行"，但不被允许，属于降级运行；仅当不存在任何子 Agent 工具（或用户明确拒绝）时才允许内联。
• 降级必须显式声明：任何降级原因下，报告首行必须是横幅 ⚠️ DEGRADED: single-context (<reason>)。静默的降级评审 = 失败的评审。
• 顺序约束：评估 A 必须在检测器发现进入父级合成上下文之前完成——检测器输出是确定性的，但它会锚定判断。
• 检测器不可跳过：除非 impeccable detect 缺失或在真实尝试后崩溃，否则跳过一次检测器 = 一次失败的评审运行。
• 可查看目标需要浏览器检查（当浏览器自动化可用时）。
• 后台服务器纪律：仅为评审可视化启动的本地服务器必须后台运行、记录停止方式，并在最终报告前停止（除非用户要求保留）。
• 不得虚构覆盖层：除非脚本注入成功且检测器在页面内运行过，否则不得声称存在用户可见的 overlay。
• 问题必须是响应的最后一件事：先写完整个报告再提问，问题之后不再有任何内容。结构化问题之后的散文会被系统暂扣，直到用户作答——所以把报告写在问题之后，读起来就像评审从未运行过。
• 收尾完整：一次运行必须以"针对性问题"或字面的 Questions skipped: <reason> 行结束；报告不是终点，收尾才是。否则 polish 无优先问题可继承。

Setup：解析目标与确认 slug

第一步是把用户意图解析为具体的文件路径或 URL。文档给出的映射示例：

• "the homepage" → site/pages/index.astro 或 index.html
• "the settings modal" → 对应的主组件文件
• "this page" → 当前 URL 或源文件

协议建议：当源码路径与 dev-server URL 指向同一界面时，优先使用源码路径——端口会漂移，路径不会。

第二步是确认目标的 slug 是稳定可生成的：

.trae-cn/skills/impeccable/scripts/impeccable critique-storage slug "<resolved-path-or-url>"

后续每个命令都可以直接接受解析后的目标，内部推导出同样的 slug；永远不要手写 slug。若该命令以非零码退出，本次运行跳过持久化与趋势，但评审继续。

slug 的生成规则在 target_slug.rs 中有完整实现：先将目标转为小写，把 /、\、. 及非法字符替换为 - 并折叠连字符，得到 kebab 形式；长度不超过 50 字符（SLUG_MAX）时原样使用，超过时截断尾部并追加 SHA-256 摘要的前 8 位十六进制（tail-<hash8>），保证不同长目标不会坍缩为同一 slug。URL 目标取 hostname + pathname 生成 slug；文件目标则解析为相对于当前工作目录的路径。仓库还保留了 legacy_slug_from_target（截断 50 字符且无哈希后缀）用于兼容旧版本生成的快照——这正是 critique_storage.rs 测试中"长目标能找回并关闭 pre-hash 快照"的原因。

第三步：读取 .impeccable/critique/ignore.md（如果存在）。匹配其中的发现将静默丢弃——这是评审唯一消费的先前运行输入。

评估编排：两个隔离的子 Agent

将评估 A 与评估 B 分派给两个独立的子 Agent，二者互不可见对方输出，合成之前不向用户展示任何发现。

子 Agent 门禁（所有 harness 通用）：

• 只要会话暴露了 sub-agent / Task 工具，默认且强制以两个隔离、并行的子 Agent 运行 A 与 B；不要因为"内联更快"而内联。
• "不可用"只有一种含义：本会话未暴露任何 sub-agent / Task 工具（或在询问型 harness 上用户拒绝）。它不意味着"不方便"。
• 仅当子 Agent 确实不可用时才顺序降级：完成并记录评估 A → 运行评估 B → 合成 → 输出降级横幅。
• 无论走哪条路径，都要在报告头声明（见下文"报告头来源声明"）。跳过子 Agent 且无横幅，是该命令最常见的失败方式。

如果浏览器自动化可用，每次评估各开一个新标签页；即使已有标签页正好停在目标 URL，也绝不复用。

评估 A：设计审查（Design Review）

评估 A 需要阅读相关源文件，并在浏览器自动化可用时目视检查实时页面——以设计总监的思维工作。它要在看到检测器输出之前完成以下判断：

• 设计特异性（Design specificity）：构图、交互与视觉语言是否扎根于本产品？换一个无关产品能否原样套用？此判断必须在看到检测器输出前做出。
• 整体设计（Holistic design）：层级、信息架构、情感匹配、可发现性、构图、排版、色彩、可访问性、状态、文案与边界情况。
• 认知负荷（Cognitive load）：参照文档内联的认知负荷评估部分，报告检查清单失败项以及可见选项 > 4 的决策点。
• 情感旅程（Emotional journey）：峰终定律（peak-end rule）、情感低谷、在高风险时刻的安抚设计。
• Nielsen 启发式：参照启发式评分指南，为全部 10 条启发式打 0–4 分；模式适用性规则允许时，将不适用项标记为 n/a 而非强行给分。

返回内容：设计特异性裁决、启发式分数、认知负荷、情感旅程、2–3 个优点、3–5 个优先问题、人物角色红旗、次要观察与挑衅性问题。

评估 B：检测器 + 浏览器证据（Detector + Browser Evidence）

评估 B 运行内置检测器与浏览器可视化证据，且必须保持与评估 A 隔离直到两者都完成。

CLI 扫描

.trae-cn/skills/impeccable/scripts/impeccable detect --json [target]

• 将标记文件/目录作为 [target] 传入；不要传入纯 CSS 文件。
• 对 URL 目标，跳过 CLI 扫描、直接使用浏览器可视化。
• 对超大树（500+ 可扫描文件），缩小范围或先询问用户。
• 退出码 0 = 干净；2 = 有发现。这一契约在 cli.rs 中有精确实现：0 Scan completed with no primary findings，2 Scan completed with primary findings（advisories 可能仍被列出）。实现还会在存在操作失败时优先返回操作失败码。
• 若检测器入口缺失或加载失败，报告"确定性扫描不可用"，继续浏览器/人工审查。

浏览器可视化

对可查看目标，只要浏览器自动化可用就必须进行浏览器可视化。本地文件使用 localhost dev/static URL；除非可用浏览器明确支持 file:// 工作流，否则避免它。Overlay 流程：

1. 打开新标签页并导航。优先使用 harness 原生的浏览器/浏览器画布截图路径，而不是手写 Playwright/Puppeteer 脚本；仅当没有暴露原生浏览器工具时才退回自定义脚本。
2. 预检可变注入：通过设置 document.title 并追加 <script> 标签来验证。只读的 evaluate API 不算数。
3. 若不可变（mutation 不可用）：跳过 live server、浏览器展示与注入，报告 fallback 信号。
4. 若可变：启动 .trae-cn/skills/impeccable/scripts/impeccable live-server --background，尽可能展示浏览器，标注为 [Human]，滚动到顶部，注入 http://localhost:PORT/detect.js，等待 2–3 秒，读取 impeccable 控制台消息，然后停止 live server。
5. 对多视图目标，在 3–5 个代表性页面上注入。

返回内容：CLI 发现 JSON/计数、浏览器控制台发现（如适用）、误报、以及被跳过/失败的浏览器步骤及具体原因。

在评估 B 返回可用的 CLI 发现后直接复用它们；除非评估 B 失败、被截断或遗漏了计数/规则名/文件位置，否则不要在父上下文中重跑 impeccable detect。

生成综合评审报告

将两份评估合成为单一报告，而不是简单拼接。要把发现交织起来：指出 LLM 审查与检测器哪里一致、检测器抓住了哪些 LLM 漏掉的问题、哪些检测器发现是误报。

聊天响应是主要的用户可见交付物。在聊天中呈现完整的结构化评审，不要用摘要加链接替代。报告以设计总监的口吻组织：

报告头来源声明

报告第一行必须声明评估的运行方式，让降级永不沉默：

• 双 Agent：Method: dual-agent (A: <agent-id> · B: <agent-id>)
• 降级：⚠️ DEGRADED: single-context (<reason, e.g. no sub-agent tool exposed>)

设计健康评分（Design Health Score）

以下面这张表呈现 10 条 Nielsen 启发式的分数：

#	Heuristic	Score	Key Issue
1	Visibility of System Status	?	[specific finding or "n/a" if solid]
2	Match System / Real World	?
3	User Control and Freedom	?
4	Consistency and Standards	?
5	Error Prevention	?
6	Recognition Rather Than Recall	?
7	Flexibility and Efficiency	?
8	Aesthetic and Minimalist Design	?
9	Error Recovery	?
10	Help and Documentation	?
Total		??/[applicable max]	[Rating band]

适用上限是实际评分启发式数量的 4 倍：全部 10 条适用时为 /40，两条为 n/a 时是 /32。永远不要在一个部分集上打印 /40。

诚实地打分：4 分意味着真正出色。现实中大多数界面落在 20–32/40。

模式适用性：在 Persuade 与 Experience 表面（落地页、营销活动、作品集、作品集系列）上，启发式 7（灵活性与效率）和 10（帮助与文档）可以打 n/a，任何确实无法适用于当前表面的启发式亦然。在 Score 单元格中写 n/a 并附一行理由，然后把总分重归一化到适用上限（例如两条 n/a 时是 24/32），使评级带保持成比例。持久化的快照必须记录适用上限与被打为 n/a 的启发式。

设计特异性裁决（Design Specificity Verdict）

从这里开始。 这个结果看起来是为本产品定制创作的，还是品类通用、可互换的？

• LLM 评估：你对设计特异性的无锚定判断。覆盖整体连贯性、结构雷同、品类可互换的选择、错失的产品性格机会。
• 确定性扫描：总结自动化检测器发现了什么，给出计数与文件位置。指出检测器抓住而你没发现的额外问题，并标记误报。
• 可视化覆盖层（若注入成功）：告诉用户覆盖层现在可见于浏览器中的 [Human] 标签页，并高亮检测到的问题；总结控制台输出报告了什么。若尝试了浏览器可视化但注入失败，说明没有可靠的用户可见覆盖层，并报告 fallback 信号。

总体印象（Overall Impression）

一句简短的直觉反应：什么有效、什么无效、最大的单个机会是什么。

做得好的地方（What's Working）

高亮 2–3 件做得好的事，具体说明为什么它们有效。

优先问题（Priority Issues）

按重要性排序的 3–5 个最具影响力的设计问题。每个问题用 P0–P3 严重性标注（定义见下文"问题严重性 P0–P3"）：

• [P?] What：清晰命名问题
• Why it matters：它如何伤害用户或破坏目标
• Fix：如何处理（要具体）
• Suggested command：哪条命令能解决它（可选自：/impeccable adapt, animate, audit, bolder, clarify, colorize, critique, delight, distill, document, harden, layout, onboard, optimize, overdrive, polish, quieter, shape, typeset）

人物角色红旗（Persona Red Flags）

从参考部分自动选择与本界面类型最相关的 2–3 个人物角色（使用选择表）。若 RULES.md 包含 impeccable init 生成的 ## Design Context 部分，还要根据受众/品牌信息生成 1–2 个项目特定人物角色。

对每个选中的人物角色，走一遍主要用户操作并列出具体红旗，例如：

Alex（高级用户）：没有检测到键盘快捷键。主操作需要 8 次点击的表单。强制模态引导。高流失风险。

Jordan（首次用户）：侧边栏纯图标导航。错误消息中的技术行话（"404 Not Found"）。无可见帮助。会在第 2 步放弃。

要具体：点名导致每个人物角色失败的精确元素与交互。不要写泛化的人物角色描述，要写他们遇到什么而失败。

次要观察（Minor Observations）

值得处理的较小问题的快速记录。

值得思考的问题（Questions to Consider）

可能解锁更好解决方案的挑衅性问题：

• "如果主操作更突出会怎样？"
• "它有必要感觉这么复杂吗？"
• "一个自信的版本会是什么样？"

记住：直接，含糊的反馈浪费所有人的时间；具体，"submit 按钮"而不是"某些元素"；既说哪里错了、也说为什么对用户重要；给出具体建议，彻底删掉"consider exploring..."；无情地排序，如果什么都重要，就什么都不重要；不要软化批评，开发者需要诚实的反馈才能交付出色的设计。

交付报告：先聊天，后持久化

在任何持久化工作之前，先把完整报告写进聊天响应。这是交付物，其下的所有内容都是记账。

必须这样做，因为替代做法是该命令最常见的失败方式：报告只被撰写一次、直接写进持久化 heredoc，运行以一份"没人读过的完美归档"结束。把报告写进文件不算交付。如果报告只存在于 .impeccable/critique/，这次运行什么都没产出。

持久化也不是运行的终点。之后响应继续：趋势行与收尾。

持久化快照：让 polish 继承优先问题

报告定稿后，写入 .impeccable/critique/，让用户可回溯、让 /impeccable polish 无需复制粘贴即可接手优先问题。

如果 Setup 阶段的 slug 为 null（目标含糊或指向根级），跳过本步骤。

1. 把正文写到临时文件，以便管道传给 helper。使用完整的评审报告（启发式表、设计特异性裁决、优先问题、人物角色红旗、次要观察与问题），但在"Ask the User / Recommended Actions"之前停住。这是上面已交付报告的副本，供后续命令阅读；它不是交付。如果你发现自己第一次写报告是在这个 heredoc 里，说明你跳过了"交付报告"，回去发送它。

2. 通过 IMPECCABLE_CRITIQUE_META（JSON）传结构化元数据，然后运行写命令：

   IMPECCABLE_CRITIQUE_META='{"target":"<user phrasing>","total_score":<n>,"max_score":<n>,"na_heuristics":"<comma-separated numbers, or empty>","p0_count":<n>,"p1_count":<n>}' \
     .trae-cn/skills/impeccable/scripts/impeccable critique-storage write "<resolved target>" <body-file>
   

   max_score 是启发式表中的适用上限（每条启发式都适用时为 40），这样后续运行就能区分重归一化的总分与完整总分。对本地文件目标，helper 还会记录精确的内容指纹（sha256），使 polish 无需依赖 Git 状态或时间戳即可区分"被评估的字节"与"后来的编辑"。helper 打印它写入的绝对路径，把文件留在磁盘上——polish 负责关闭它，本次运行不负责。

   底层实现在 critique_storage.rs：write 子命令从环境变量读取元数据后，以 now_filename_stamp()（2026-05-12T18-30-00Z 形式）为前缀、slug 为后缀生成快照文件名，并用 create_new(true) + 固定宽度 ~0001 冲突后缀做独占创建——同一 UTC 秒内第二次 critique 不会覆盖历史（见 snapshot_name_accepts_collision_suffix 测试）。快照正文以 YAML frontmatter（slug、timestamp、target_identity、target_fingerprint、total_score、max_score 等）开头，target_identity 以 file:<resolved path> 或 url:<origin+pathname> 标识目标。

3. 写尝试完成后删除临时正文文件，无论成功失败。若删除失败，在最终输出中简要提及 temp-file cleanup failed: <reason>，但不要阻塞评审。

4. 读取趋势获取上下文：

   .trae-cn/skills/impeccable/scripts/impeccable critique-storage trend "<resolved target>" 5
   

   返回最近 5 条 frontmatter 条目（含刚写入的那条）的 JSON 数组。trend 实现会同时搜索当前 slug 与 legacy slug（仅当快照的 target_identity 匹配时才纳入 legacy），按路径排序后取最后 N 条（默认 5），见 critique_storage.rs。

5. 在报告之后、问题之前，向用户可见输出追加一行：

   Trend for <slug> (last 5 runs): 24 → 28 → 32 → 29 → 32 (out of 40) Wrote .impeccable/critique/<filename>.

   读取每条趋势条目的 max_score。所有条目共享一个上限时，按上例一次性说明；不同时，为每个分数打印各自的分母（24/32 → 30/40），并注明各次运行的启发式集合不同、此趋势行不是同类比较。旧条目缺失 max_score 时按 40 处理。若这是该 slug 的首次运行，趋势只有一个分数，说明："First run for this target, no trend yet."

6. 关闭运行。进入"向用户提问"，发出问题，或在计数允许时输出 Questions skipped: <reason> 行。在此之前运行都不算完成。持久化是记账，清理不是结束；停在这里会让用户拿到一份报告却没有前进方向，也让 /impeccable polish 没有可继承的优先问题。

这是 fire-and-forget：不要向用户展示 helper 的 JSON 输出，只展示人类可读的趋势行与写入路径。此处的失败不应阻塞其余流程——打印错误并继续。

向用户提问：用发现锚定下一步

在展示发现之后，基于实际发现使用针对性问题。直接询问你无法推断的内容；这些答案将塑造行动计划。

在承载报告的同一条消息中提问，报告写在前面、问题放最后。不要把两者拆到不同轮次：以报告结束的轮次就是结束的轮次，问题永远不会到达。消息内的顺序很重要，因为结构化问题之后的散文会被暂扣直到用户作答。

问题沿这些方向展开（根据具体发现调整，不要问泛化问题）：

1. 优先级方向：基于发现的问题，询问用户此刻最关心哪类。例如："我发现视觉层级、色彩使用与信息过载三方面有问题。我们应该先攻哪个？"给出最相关的 2–3 个问题类别作为选项。
2. 设计意图：若评审发现语调失配，询问是否有意为之。例如："这个界面感觉冷冰冰、很企业化。这是预期语调，还是应该更温暖/更大胆/更有趣？"根据能修复发现问题的方向给出 2–3 个语调选项。
3. 范围：询问用户想承担多少。例如："我发现了 N 个问题。想全部处理，还是聚焦前 3 个？"给出"仅前 3 个 / 全部 / 仅关键问题"等范围选项。
4. 约束（可选，仅当相关）：若发现触及许多区域，询问是否有任何部分是禁区。例如："哪些部分要保持原样？"这能防止计划触碰用户认为已完成的部分。

问题规则：

• 每个问题必须引用报告中的具体发现，永远不要问泛化的"你的受众是谁"。
• 最多 2–4 个问题，尊重用户的时间。
• 提供具体选项，而不是开放式提示。
• 仅当报告列出的 优先问题少于 3 个时才允许跳过。计数，不要凭感觉判断发现"直截了当"。达到 3 个及以上时，问题是强制的。

最终问题门禁。用户可见响应必须要么包含针对性问题，要么携带字面行 Questions skipped: <reason> 并注明允许跳过的计数。每个问题必须包含 2–3 个与评审发现实际绑定的具体答案选项。不要只以开放式问题结尾，也不要两者皆无：在报告后停下、什么也没问、也没打印跳过行，是该命令最常见的失败方式。

推荐行动：把优先级映射到命令

收到用户答案后，给出反映其优先级与范围的行动总结。

Action Summary

按优先级列出推荐命令：

1. /command-name：要修复什么（来自评审发现的具体上下文）
2. /command-name：简要描述（具体上下文） ...

推荐规则：

• 只从 /impeccable adapt, animate, audit, bolder, clarify, colorize, critique, delight, distill, document, harden, layout, onboard, optimize, overdrive, polish, quieter, shape, typeset 中推荐命令。
• 先按用户声明的优先级排序，再按影响排序。
• 每条描述要携带足够上下文，让命令知道该聚焦什么。
• 将每个优先问题映射到合适的命令；跳过会解决零问题的命令。
• 若用户选择了有限范围，只包含该范围内的条目；若用户标记了禁区，排除会触碰那些区域的命令。
• 若推荐了任何修复，以 /impeccable polish 作为最后一步收尾。

呈现总结后告诉用户：

You can ask me to run these one at a time, all at once, or in any order you prefer.

Re-run /impeccable critique after fixes to see your score improve.

参考材料：评审深度上下文的三个支柱

以下部分原先是独立参考文件（cognitive-load.md、heuristics-scoring.md、personas.md），如今内联在 critique 参考中，让评审流程的所有深度上下文集中一处。

认知负荷评估（Cognitive Load Assessment）

认知负荷是使用界面所需的总心智努力。超载的用户会犯错、受挫、离开。认知负荷分三类：

• 内在负荷（Intrinsic Load）——任务本身：用户要做的事固有的复杂度，无法消除，但可以结构化。管理方式：把复杂任务拆成离散步骤；提供脚手架（模板、默认值、示例）；渐进披露（只展示当前所需，隐藏其余）；将相关决策分组。
• 外在负荷（Extraneous Load）——糟糕的设计：由不良设计选择造成的心智努力，要无情地消除，这是纯粹的浪费。常见来源：需要心智映射的混乱导航、迫使猜测含义的模糊标签、争夺注意力的视觉杂乱、阻止学习的模式不一致、意图与结果之间多余的步骤。
• 相关负荷（Germane Load）——学习努力：用于建立理解的心智努力，这是好的认知负荷，通向精通。支持方式：渐进披露逐步揭示复杂度、奖励学习的连贯模式、确认正确理解的反馈、通过行动而非文字墙教学。

认知负荷检查清单（8 项）

• [ ] 单一焦点：用户能否在无竞争元素干扰下完成主任务？
• [ ] 分块：信息是否以可消化的分组呈现（每组 ≤4 项）？
• [ ] 分组：相关项是否在视觉上聚合（邻近、边框、共享背景）？
• [ ] 视觉层级：屏幕上什么最重要是否一目了然？
• [ ] 一次一件事：用户能否在进入下一个决策前聚焦单一决策？
• [ ] 最少选择：决策是否简化（任何决策点 ≤4 个可见选项）？
• [ ] 工作记忆：用户是否需要在当前屏幕回忆上一屏的信息才能行动？
• [ ] 渐进披露：复杂度是否只在需要时才揭示？

计分：统计失败项。0–1 失败 = 低认知负荷（好）；2–3 = 中等（尽快处理）；4+ = 高认知负荷（需要关键修复）。

工作记忆规则

人类同一时刻只能在工作记忆中容纳 ≤4 项（Miller 定律的 Cowan 2001 修订版）。在任何决策点，统计用户必须同时考虑的离散选项、动作或信息条数：≤4 项在限制内、可管理；5–7 项逼近边界，考虑分组或渐进披露；8+ 项超载，用户会跳过、误点或放弃。

实际应用：操作按钮——1 个主按钮、1–2 个次按钮，其余收进菜单；导航菜单——≤5 个顶级项；长文——单一阅读路径，相关链接收进文末单个区块而非散落文中；文档侧边栏——每级 ≤4 个可见同级选择；作品集与画廊索引——每屏一个决策（打开哪个作品），而不是把筛选、排序、标签控件一次全摆出来。

常见认知负荷违规

1. 选项墙（The Wall of Options）：一次性呈现 10+ 个无层级的选项。修复：按类别分组、高亮推荐项、用渐进披露。
2. 记忆桥（The Memory Bridge）：用户必须记住步骤 1 的信息才能完成步骤 3。修复：在需要处保持相关上下文可见或重复它。
3. 隐藏导航（The Hidden Navigation）：用户必须建立位置的心智地图。修复：始终显示当前位置（面包屑、激活态、进度指示器）。
4. 行话屏障（The Jargon Barrier）：技术或领域语言迫使翻译努力。修复：用平实语言；领域术语不可避免时内联定义。
5. 视觉噪声底（The Visual Noise Floor）：每个元素视觉权重相同，无突出项。修复：建立清晰层级——一个主元素、2–3 个次元素、其余弱化。
6. 不一致模式（The Inconsistent Pattern）：相似操作在不同地方行为不同。修复：标准化交互模式，同类操作 = 同类 UI。
7. 多任务需求（The Multi-Task Demand）：界面要求同时处理多个输入（阅读 + 决策 + 导航）。修复：排序步骤，让用户一次做一件事。
8. 上下文切换（The Context Switch）：用户必须穿梭于屏幕/标签页/弹窗间收集单一决策所需的信息。修复：把每个决策所需信息放在一起，减少来回。

启发式评分指南（Heuristics Scoring Guide）

在 0–4 标尺上为 Nielsen 的 10 条可用性启发式打分。要诚实：4 分意味着真正出色，而不是"够好"。

1. 系统状态可见性（Visibility of System Status）

通过及时、恰当的反馈让用户始终了解正在发生什么。检查：异步操作期间的加载指示器、用户操作（保存/提交/删除）的确认、多步流程的进度指示器、导航中的当前位置（面包屑、激活态）、表单校验反馈（内联而非仅在提交时）。

Score	Criteria
0	无反馈；用户在猜测发生了什么
1	反馈稀少；多数操作无可见响应
2	部分；有些状态被传达，仍有重大缺口
3	良好；多数操作给出清晰反馈，少量缺口
4	出色；每个动作都有确认，进度始终可见

2. 系统与真实世界的匹配（Match Between System and Real World）

说用户的语言，遵循真实世界惯例，信息以自然、合乎逻辑的顺序出现。检查：熟悉的术语（无未解释的行话）、与用户预期一致的信息逻辑顺序、可识别的图标与隐喻、适配目标受众的领域语言、自然的阅读流（左到右、上到下的优先级）。

Score	Criteria
0	纯技术行话，对用户陌生
1	大多令人困惑；需要领域专长才能导航
2	混杂；有些平实语言，有些行话泄漏
3	大多自然；偶尔术语需要语境
4	全程流利地说用户的语言

3. 用户控制与自由（User Control and Freedom）

用户需要一条无需冗长对话即可离开非预期状态的清晰"紧急出口"。检查：撤销/重做、表单与弹窗上的取消按钮、返回安全点的清晰导航（主页、上一步）、轻松清除筛选/搜索/选择、逃离长或多步流程。

Score	Criteria
0	用户被困；不刷新无路可走
1	退出困难；必须找到晦涩路径逃脱
2	有些出口；主流程可逃，边界情况不能
3	控制良好；用户可退出并撤销多数操作
4	完全控制；撤销、取消、返回、Esc 无处不在

4. 一致性与标准（Consistency and Standards）

用户不应怀疑不同的词、情境或动作是否意味着同一件事。检查：全程一致的术语、处处相同操作产生相同结果、遵循平台惯例（标准 UI 模式）、视觉一致（色彩、排版、间距、组件）、一致的交互模式（相同手势 = 相同行为）。

Score	Criteria
0	处处不一致；感觉像缝合的不同产品
1	许多不一致；相似事物看起来/行为不同
2	部分一致；主流程一致，细节分叉
3	大多一致；偶尔偏差，无困惑
4	完全一致；连贯的系统，可预测的行为

5. 错误预防（Error Prevention）

比好的错误消息更好的是从一开始就防止问题的设计。检查：破坏性操作前确认（删除、覆盖）、防止无效输入的约束（日期选择器、下拉框）、减少错误的智能默认值、防止误解的清晰标签、自动保存与草稿恢复。

Score	Criteria
0	错误易犯；到处无护栏
1	防护稀少；一些输入被校验，多数没有
2	部分预防；常见错误被拦，边界情况漏过
3	良好预防；多数错误路径被主动阻断
4	出色；通过智能约束几乎不可能出错

6. 识别优于回忆（Recognition Rather Than Recall）

最小化记忆负荷。让对象、动作与选项可见或易取回。检查：可见选项（不埋在隐藏菜单）、需要时的上下文帮助（tooltip、内联提示）、最近项与历史、自动补全与建议、图标上的标签（而非纯图标导航）。

Score	Criteria
0	重度记忆；用户必须记住路径与命令
1	大多回忆；许多隐藏特性，少量可见线索
2	有些辅助；主动作可见，次要特性隐藏
3	良好识别；多数可发现，少量记忆需求
4	一切可发现；用户永不需要记忆

7. 灵活性与使用效率（Flexibility and Efficiency of Use）

对新手不可见的加速器能加快专家交互。检查：常用操作的键盘快捷键、可定制的界面元素、最近项与收藏、批量/成组操作、不使基础复杂化的高级用户特性。

Score	Criteria
0	一条僵化路径；无快捷键或替代
1	灵活性有限；主路径替代方案少
2	有些快捷键；基本键盘支持，批量操作有限
3	良好加速器；键盘导航，有些定制
4	高度灵活；多路径、高级特性、可定制

8. 美学与极简设计（Aesthetic and Minimalist Design）

界面不应包含无关或很少需要的信息。每个元素都应服务于一个目的。检查：每一步只显示必要信息、引导注意力的清晰视觉层级、有目的的色彩与强调使用、无争夺注意力的装饰杂乱、聚焦、整洁的布局。

Score	Criteria
0	压倒性；一切平等争夺注意力
1	杂乱；噪声太多，难以找到重点
2	有些杂乱；主内容清晰，外围有噪声
3	大多干净；聚焦的设计，轻微视觉噪声
4	完美极简；每个元素都挣得自己的像素

9. 帮助用户识别、诊断并从错误中恢复（Help Users Recognize, Diagnose, and Recover from Errors）

错误消息应使用平实语言、精确指出问题、并建设性地建议解决方案。检查：平实语言的错误消息（不给用户错误码）、具体的问题识别（"Email 缺少 @" 而非"无效输入"）、可操作的重试建议、靠近问题源显示错误、非阻塞式错误处理（不抹掉表单）。

Score	Criteria
0	晦涩错误；代码、行话或根本没有消息
1	模糊错误；"出了点问题"且无指引
2	清晰但不帮忙；说出问题但不说修复
3	带建议的清晰；识别问题并提供下一步
4	完美恢复；精确定位问题、建议修复、保留用户工作

10. 帮助与文档（Help and Documentation）

即使没有文档系统也可用，帮助仍应易找、面向任务、简明。检查：可搜索的帮助或文档、上下文帮助（tooltip、内联提示、引导导览）、面向任务的组织（而非面向特性）、简明可扫读的内容、不离开当前上下文即可访问。

Score	Criteria
0	任何地方都无帮助
1	帮助存在但难找或无关
2	基础帮助；FAQ 或文档存在，非上下文
3	良好文档；可搜索，大多面向任务
4	出色的上下文帮助；在正确时刻给出正确信息

分数汇总

总分上限：40 分（10 条启发式 × 4 上限）。

Score Range	Rating	What It Means
36–40	Excellent	仅需细微打磨；可以发布
28–35	Good	基础扎实，处理薄弱区域
20–27	Acceptable	用户满意前需要重大改进
12–19	Poor	需要重大 UX 改造；核心体验破损
0–11	Critical	需要重设计；当前状态不可用

当启发式被标为 n/a 时，上限低于 40；按百分比而非原始数字读带（90%+ Excellent，70%+ Good，50%+ Acceptable，30%+ Poor，以下 Critical）。24/32 是 75%，即 Good。

问题严重性（P0–P3）

Priority	Name	Description	Action
P0	Blocking	完全阻止任务完成	立即修复；这是 showstopper
P1	Major	造成显著困难或困惑	发布前修复
P2	Minor	恼人，但有变通方案	下一轮修复
P3	Polish	宜修但无真实用户影响	有时间就修

提示：在两个级别间犹豫时问自己："用户会为此联系支持吗？"会，则至少 P1。

基于人物角色的设计测试（Persona-Based Design Testing）

通过 5 个不同用户原型审视界面。每个人物角色暴露单一"设计总监"视角会错过的不同失败模式。用法：选择与所评审界面最相关的 2–3 个人物角色，以每个人物角色走一遍主要用户操作，报告具体红旗而非泛化担忧。

1. 不耐烦的高级用户："Alex"

画像：同类产品专家。期待效率，讨厌被手把手教。会找快捷键，否则离开。 行为：跳过所有引导与说明；立即寻找键盘快捷键；尝试批量选择、批量编辑与自动化；对感觉不必要的强制步骤受挫；任何事显得慢或被说教都会放弃。 测试问题：Alex 能否在 60 秒内完成核心任务？常用操作有键盘快捷键吗？引导能完全跳过吗？弹窗支持 Esc 关闭吗？存在"高级用户路径"（快捷键、批量操作）吗？ 红旗（具体报告）：强制教程或不可跳过的引导；主操作无键盘导航；无法跳过的慢动画；本应批量却一次一个的工作流；低风险操作的多余确认步骤。

2. 困惑的首次用户："Jordan"

画像：从未用过此类产品。每一步都需要指引，宁可放弃也不自己搞清楚。 行为：仔细阅读所有说明；点击任何不熟悉的东西前犹豫；不断寻找帮助或支持；误解行话与缩写；对任何标签采取最字面的解读。 测试问题：首个操作在 5 秒内是否显然清晰？所有图标都有文字标签吗？决策点有上下文帮助吗？术语是否假设先验知识？每一步都有清晰的"返回"或"撤销"吗？ 红旗：无标签的纯图标导航；无解释的技术行话；无可见帮助选项或指引；完成操作后的下一步含糊；操作成功无确认。

3. 依赖无障碍的用户："Sam"

画像：使用屏幕阅读器（VoiceOver/NVDA）、纯键盘导航。可能有低视力、运动障碍或认知差异。 行为：线性 Tab 浏览界面；依赖 ARIA 标签与标题结构；无法看到 hover 态或纯视觉指示器；需要足够的色彩对比（最低 4.5:1）；可能将浏览器缩放至 200%。 测试问题：整个主流程能否纯键盘完成？所有交互元素可聚焦且焦点指示可见？图片有有意义的 alt 文本？文本色彩对比符合 WCAG AA（4.5:1）？屏幕阅读器会播报状态变化（加载、成功、错误）吗？ 红旗：无键盘替代的纯点击交互；缺失或不可见的焦点指示；仅靠色彩传达含义（红 = 错误，绿 = 成功）；无标签的表单字段或按钮；无扩展选项的限时操作；破坏屏幕阅读器流程的自定义组件。

4. 审慎的压力测试者："Riley"

画像：有条不紊地推动界面越过快乐路径。测试边界情况、尝试意外输入、探测体验缺口。 行为：刻意测试边界情况（空状态、长字符串、特殊字符）；用意外数据提交表单（emoji、RTL 文本、超长值）；通过返回、流程中刷新、多标签打开来破坏工作流；寻找 UI 承诺与实际行为间的不一致；有条理地记录问题。 测试问题：边界处会发生什么（0 项、1000 项、超长文本）？错误状态优雅恢复还是把 UI 留在破损状态？流程中刷新会发生什么，状态保留吗？有没有看起来能用但产出损坏结果的特性？UI 如何处理意外输入（emoji、特殊字符、从 Excel 粘贴）？ 红旗：看起来能用但静默失败或产出错误结果的特性；暴露技术细节或让 UI 停留在破损状态的错误处理；显示无用的空状态（"No results"且无指引）；刷新或导航丢失用户数据的工作流；界面不同部位相似交互之间的行为不一致。

5. 分心的移动用户："Casey"

画像：在外单手用手机。频繁被打断。可能网络较慢。 行为：只用拇指；偏好屏幕底部操作；流程中被打断稍后返回；频繁切换应用；注意力有限、耐心低；尽可能少打字，偏好点按与选择。 测试问题：主操作在拇指区（屏幕下半部）吗？离开再返回状态保留吗？慢网络（3G）下可用吗？表单能用自动补全与智能默认值吗？触控目标至少 44×44pt 吗？ 红旗：重要操作位于屏幕顶部（拇指够不到）；无状态持久化，标签切换或被打断就丢失进度；本可用选择却要求大段文本输入；每页加载重型资源（无懒加载）；触控目标过小或过于接近。

选择人物角色

Interface Type	Primary Personas	Why
Landing page / marketing	Jordan, Riley, Casey	第一印象、信任、移动端
Dashboard / admin	Alex, Sam	高级用户、无障碍
E-commerce / checkout	Casey, Riley, Jordan	移动端、边界情况、清晰度
Onboarding flow	Jordan, Casey	困惑、打断
Data-heavy / analytics	Alex, Sam	效率、键盘导航
Form-heavy / wizard	Jordan, Sam, Casey	清晰度、无障碍、移动端

项目特定人物角色

若 RULES.md 包含 impeccable init 生成的 ## Design Context 部分，则从中为受众与品牌信息派生 1–2 个额外人物角色：

1. 阅读目标受众描述
2. 识别 5 个预定义人物角色未覆盖的主要用户原型
3. 按此模板创建人物角色：

##### [Role]: "[Name]"

**Profile**: [从 Design Context 派生的 2-3 个关键特征]

**Behaviors**: [基于所描述受众的 3-4 个具体行为]

**Red Flags**: [会疏远这类特定用户的 3-4 件事]

仅当存在真实的 Design Context 数据时才生成项目特定人物角色；不要编造受众细节；无上下文时使用 5 个预定义人物角色。

把 critique 放入更大的工作流

critique 属于 Impeccable 命令体系的 Evaluate 类别（见 SKILL.md 的命令表）。它与技术审计 audit 互补：audit 关注可访问性、性能、响应式等工程质量，critique 关注 UX 视角的视觉层级、信息架构、情感与认知负荷。它也与 polish 闭环：critique 持久化的快照让 polish 无需复制粘贴即可继承优先问题，而修复后重跑 critique 即可看到分数上升——这正是"评估 → 修复 → 复评"循环在 Impeccable 中的标准姿势。启动器本身（scripts/impeccable）是一个无需 Node 的自包含二进制启动脚本，按 $IMPECCABLE_BIN → 同目录平台二进制 → ~/.impeccable/bin → 版本固定缓存 → PATH → 校验下载的顺序解析引擎，配合 IMPECCABLE_SKILL_DIR 让引擎能找到 reference 文档与命令元数据。