Your Next Store 的 critique 技能：写给 AI Agent 的十维度 UX 设计评审方法

本文围绕 yournextstore（Your Next Store，一个 AI-Native 的开源 Next.js 电商模板）中 .agents/skills/critique/SKILL.md 这个"设计批评（design critique）"技能展开。读完你可以完整掌握：该技能的 frontmatter 调用模型、它依赖的 frontend-design 反模式清单、十个 UX 评审维度的具体检查问题、固定的批评报告结构（含 What/Why/Fix/Command 四字段），以及这套方法论在本仓库中如何用 app/globals.css 的 OKLCH 色板、app/palette.test.ts 的 WCAG AA 断言和 lib/contrast.ts 的对比度计算被源码级地佐证与落地。

技能定位：frontmatter 与调用模型

critique 是一个标准的 Agent 技能（SKILL.md 格式）。其 frontmatter 声明了身份与调用方式：

---
name: critique
description: Evaluate design effectiveness from a UX perspective. Assesses
  visual hierarchy, information architecture, emotional resonance, and
  overall design quality with actionable feedback.
user-invokable: true
args:
  - name: area
    description: The feature or area to critique (optional)
    required: false
---

见 SKILL.md 的 frontmatter。可以从中读出三点关键信息：

• user-invokable: true：该技能可以由用户直接作为命令触发（即 /critique），而不需要 Agent 自行决定是否使用；
• 参数 area 可选：调用时可以指定"要批评的功能区域"（例如购物车、商品详情页），不传则对整个界面做整体批评；
• 职责是"评审"而非"实现"：技能正文开篇要求"以设计总监（design director）的身份给出反馈"，评估界面是否作为一个被设计的体验真正有效工作，而不只是技术上能跑（原文：evaluating whether the interface actually works—not just technically, but as a designed experience，见 SKILL.md）。

从 skills-lock.json 看，critique 的注册来源是 pbakaus/impeccable（sourceType: github），并带有 computedHash 做内容指纹锁定。该文件同时注册了 frontend-design、audit、polish、quieter、colorize 等十余个技能——这批技能共同构成了 critique 报告里"建议改用哪个命令修复"的白名单基础，下文会展开。

执行顺序：先加载 frontend-design，再做批评

critique 正文在维度检查之前给出了一条硬性的前置指令：

First: Use the frontend-design skill for design principles and anti-patterns. （先使用 frontend-design 技能获取设计原则与反模式。）

见 SKILL.md。这意味着 critique 不是一个自包含的规则集，而是引用型技能：它的"AI 味检测"维度直接复用 frontend-design/SKILL.md 中全部 DON'T 条款作为判定依据。仓库内确实存在这个被引用的技能本体 .agents/skills/frontend-design/SKILL.md，其核心是：

1. 确定大胆的审美方向（brutally minimal、editorial/magazine、art deco 等），拒绝"每次都收敛到同样的安全选择"；
2. 六类 DO/DON'T 审美准则，每类都挂接一份参考文档：
   • Typography → reference/typography.md（禁用 Inter/Roboto/Arial 等泛滥字体，拒绝用等宽字体冒充"技术感"）；
   • Color & Theme → reference/color-and-contrast.md（用 OKLCH 而非 HSL；禁用"深底青色 + 紫蓝渐变 + 霓虹强调"的 AI 色板、渐变文字、发光暗色模式）；
   • Layout & Space → reference/spatial-design.md（禁止"万物皆卡片"、相同卡片网格、hero metric 布局模板、处处居中）；
   • Visual Details（拒绝装饰性 glassmorphism、单边粗色边框、装饰性 sparkline、通用地面投影圆角矩形）；
   • Motion → reference/motion-design.md（只动 transform/opacity，禁用 bounce/elastic 缓动）；
   • Interaction / Responsive / UX Writing → 对应 interaction-design.md、responsive-design.md、ux-writing.md。

frontend-design 还定义了整套体系的"终极质检"——AI Slop Test（见 SKILL.md）：

如果你把这个界面给别人看并说"这是 AI 做的"，对方会立刻信吗？如果会，那就是问题。一个有辨识度的界面应让人问"这怎么做出来的？"而不是"这是哪个 AI 做的？"

AGENTS.md 也把 frontend-design 写进了 Agent 工作流规范：做前端设计时必须调用该技能来获得"独特的、生产级的前端体验"。可以说，critique 是"生成侧规范（frontend-design）"在"验收侧"的镜像。

十维度评审框架

critique 要求对界面在以下十个维度上逐一评估（完整问题清单继承自 SKILL.md）：

1. AI Slop Detection（最关键，CRITICAL）

这是全文标注"最重要的检查"的维度。要求把设计对照 frontend-design 技能中所有 DON'T 条款过一遍——它们是 AI 生成作品的"指纹"。原文列出的典型 tells（特征）包括：

• AI 色板（cyan-on-dark、purple-to-blue gradients、neon accents）；
• 渐变文字（gradient text）；
• 带发光强调色的暗色模式（dark mode with glowing accents）；
• 玻璃拟态（glassmorphism）；
• hero metric 布局（大数字 + 小标签 + 支撑性统计）；
• 相同的卡片网格（icon + heading + text 无限重复）；
• 泛用字体（generic fonts）。

判定标准即上文引用的"AI made this"测试：别人一听就信，说明设计失败。

2. Visual Hierarchy（视觉层级）

• 视线是否首先落在最重要的元素上？
• 是否存在清晰的"主操作"？能否在 2 秒内被找到？
• 尺寸、颜色、位置是否正确地传达了重要性？
• 本应不同权重的元素之间是否存在视觉竞争？

3. Information Architecture（信息架构）

• 结构是否直觉化？新用户能否理解组织方式？
• 相关内容是否被逻辑地分组？
• 是否一次给出的选项过多（认知过载）？
• 导航是否清晰且可预测？

4. Emotional Resonance（情感共鸣）

• 这个界面唤起什么情绪？这是有意的吗？
• 是否与品牌人格匹配？
• 它是否呈现出它应当呈现的气质——可信赖、亲切、高端、 playful？
• 目标用户是否会觉得"这是为我准备的"？

5. Discoverability & Affordance（可发现性与示能）

• 可交互元素是否"明显可交互"？
• 用户是否需要说明书才知道下一步做什么？
• hover/focus 状态是否提供有用的反馈？
• 是否存在应当更显眼却被藏起来的功能？

6. Composition & Balance（构图与平衡）

• 布局是平衡的还是令人不适地偏重？
• 留白是"有意设计"还是"剩下的空白"？
• 间距与重复是否形成视觉节奏？
• 不对称是"设计出来的"还是"手误"？

7. Typography as Communication（排版即沟通）

• 字级层级是否清楚表达"先读什么、再读什么"？
• 正文是否舒适（行长、行距、字号）？
• 字体选择是否强化品牌/语气？
• 各级标题之间是否有足够对比？

8. Color with Purpose（有目的的用色）

• 颜色是用来"沟通"的，还是仅仅"装饰"？
• 色板是否整体协调？
• 强调色是否把注意力引向正确的对象？
• 色盲用户是否也能读懂含义（不只是技术上达标——意义是否依然传达）？

9. States & Edge Cases（状态与边界）

• 空状态：是引导用户行动，还是只说"这里什么都没有"？
• 加载状态：是否降低了感知等待时间？
• 错误状态：是否有用且不指责用户？
• 成功状态：是否确认结果并引导下一步？

10. Microcopy & Voice（微文案与语气）

• 文案是否清晰、简洁？
• 听起来是否像一个"人"（这个品牌应该有的那个人）？
• 标签与按钮是否无歧义？
• 错误文案是否帮助用户修正问题？

这十个维度与姊妹技能 prettify 的迭代打分表（Visual hierarchy / Typography / Spacing & rhythm / Color & contrast / Depth & texture / Detail & richness / Consistency / Mobile fidelity）高度同构——prettify 的循环是"截图 → 按 rubric 批评 → 做一处针对性修改 → 再截图"，critique 就是这个循环中"批评"环节的独立、完整形态：它输出报告，然后停止。

批评报告：六段式固定结构

critique 的产出不是零散意见，而是一份"设计总监式"的结构化报告，顺序不可调换（SKILL.md）：

Anti-Patterns Verdict（反模式裁决）

必须从这里开始。 给 Pass/Fail 结论：这个界面看起来是否像 AI 生成的？逐条列出来自 frontend-design 技能反模式章节的具体 tells，"要残酷地诚实"。

Overall Impression（整体印象）

一段直觉层面的快速反馈：什么有效、什么无效、以及唯一最大的机会点。

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

挑出 2–3 处做得好的细节，并具体说明"为什么它有效"。

Priority Issues（优先问题）

3–5 个影响最大的设计问题，按重要性排序。每个问题必须给出四个字段：

• What：清楚命名问题（"提交按钮"，而不是"某些元素"）；
• Why it matters：它如何伤害用户或削弱目标；
• Fix：具体怎么做；
• Command：应该用哪个命令去修（优先从 /animate、/quieter、/optimize、/adapt、/clarify、/distill、/delight、/onboard、/normalize、/audit、/harden、/polish、/extract、/bolder、/critique、/colorize 中选择，或选你确信已安装的其他技能）。

这个命令白名单并非凭空而列：与 skills-lock.json 的注册名逐一对得上——animate、quieter、optimize、adapt、clarify、distill、delight、onboard、normalize、audit、harden、polish、extract、bolder、colorize 全部在锁定文件中有 source: pbakaus/impeccable 与 computedHash 记录。技能同时规定"可以推荐你确信存在的其他已安装技能，但绝不发明命令"。

Minor Observations（次要观察）

值得处理的小问题，快速列出即可。

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

用挑衅式问题解锁更好的解法，原文给出的示例：

• "如果主操作更突出会怎样？"
• "这个界面真的需要这么复杂吗？"
• "它'自信的版本'会是什么样子？"

报告原则：六条"Remember"

报告生成之后，critique 用六条原则约束输出质量（SKILL.md），这六条本身就是 AI 写设计反馈时最容易违反的地方：

1. Be direct——含糊的反馈浪费所有人的时间；
2. Be specific——说"the submit button"，不说"some elements"；
3. 同时说明错在哪里以及为什么对用户重要；
4. 给具体建议，而不是"可以考虑探索一下……"；
5. 无情地排优先级——如果什么都重要，那就什么都不重要；
6. 不要软化批评——开发者需要诚实的反馈才能交出好设计。

对照姊妹技能 audit 的"NEVER"清单（不解释影响就不报告、不混用严重级别、不跳过正面发现、不给泛化建议、不遗忘排序、不报告未验证的误报），可以看出 critique 与 audit 共用同一套"质量审计纪律"：critique 侧重体验与设计质量，audit 侧重可访问性、性能、主题、响应的系统扫描，两者都以"Anti-Patterns Verdict"作为报告开篇。

仓库源码如何佐证这套评审标准

critique 的维度是"方法论"，而 yournextstore 仓库里有一批可执行的实现，让"设计评审"从主观意见变成可验证的工程事实。

颜色维度：WCAG AA 不是口头要求，而是测试断言

维度 8（Color with Purpose）追问"色板是否协调""色盲用户是否仍能读懂"。本仓库的回答是机械化的：

• app/globals.css 用 OKLCH 定义亮/暗两套 token：:root 中 --foreground: oklch(0.145 0 0)、--muted-foreground: oklch(0.52 0 0) 等；.dark 中 --background: oklch(0.145 0 0)、--muted-foreground: oklch(0.708 0 0) 等——与 frontend-design 的 color 参考文档"Stop using HSL, use OKLCH"（color-and-contrast.md）完全一致。:root 块内还留有设计注释："The tint is the design; this lightness clears AA on --muted/--secondary"，即色相偏移是设计意图，只调整明度来过 AA。
• app/palette.test.ts 对 :root 与 .dark 中的 10 组"文字 token × 表面 token"（foreground/background、muted-foreground/muted、primary-foreground/primary 等）逐一断言对比度 ≥ 4.5（WCAG AA）。注释明确："主题会 fork 这份文件，所以检查放在这里，而不是评审人的眼睛里"。
• 计算内核是 lib/contrast.ts：parseCssBlock 用括号配对（而非正则）解析 CSS 块，resolveColor 支持 #hex、rgb()/rgba()、hsl()/hsla()、oklch() 与 var(--x) 链（上限 10 跳，带 fallback），contrastRatio 按 WCAG 2.x 相对亮度公式计算，半透明前景会先对背景做 alpha 合成（contrast.ts）。不支持的语法（color-mix()、light-dark()、颜色关键字）刻意返回 null——lib/contrast.test.ts 有对应测试——这样"解析不了"会大声失败，而不是悄悄跳过、掩盖一次对比度回归。
• AGENTS.md 解释了失败后的修复方向：移动文字 token 的明度（亮面上调暗、暗面上调亮），保留色相染色；pre-commit 钩子在暂存 app/globals.css 时会强制运行 bun test app/palette.test.ts（AGENTS.md）。

对 critique 的启示很直接：维度 8 里"它是否真的通过了"这类问题，在本仓库可以用 bun test 一条命令给出证据。

状态与微文案维度：仓库里的真实样本

维度 9/10 检查空状态、错误文案。仓库里有可直接引用的样本，例如：

• 购物车空状态："Your cart is empty"（app/cart/cart-sidebar.tsx）；
• 商品列表过滤空结果："No products match these filters."（app/products/page.tsx、app/category/[...slugs]/page.tsx）；
• 搜索空结果："No results"（app/search/page.tsx）。

对照 ux-writing.md 的空状态公式（承认现状 → 说明填满它的价值 → 给出明确行动），这些单句空状态正好是 critique 会点名"只说 nothing here、没有引导行动"的典型评审对象——方法论与仓库样本互为注脚。

主题切换：light/dark/system 的工程处理

components/theme-toggle.tsx 基于 next-themes 提供 Light/Dark/System 三态切换，并用纯 CSS 类切换图标（Sun className="size-5 dark:hidden" / Moon className="hidden size-5 dark:block"），注释说明这是为了"服务器与客户端标记一致，避免 hydration 闪烁"。暗色变体由 app/globals.css 的 @custom-variant dark (&:is(.dark *)) 驱动。critique 评估"暗色模式是设计决定还是偷懒的发光黑底"时，这套 token + 变体的结构就是检查起点：暗色不是反转的亮色，而是另一组独立声明的 token（与 color-and-contrast.md 的"Dark Mode Is Not Inverted Light Mode"一致）。

与 prettify / audit 的分工

从源码结构看，三个技能构成一条流水线：

• critique：整体诊断 + 结构化报告，每个问题映射到一个修复命令，不改代码；
• audit（.agents/skills/audit/SKILL.md）：明确写着 "Don't fix issues - document them"，负责 a11y/性能/主题/响应式的系统性扫描并按严重级分层；
• prettify（.agents/skills/prettify/SKILL.md）：拿到批评后进入"截图（320/768/1280px）→ 批评 → 只改一处 → 再截图验证，变差就回滚"的迭代环，默认 5 轮，禁止重排布局、禁止改文案、每轮只做一个高杠杆改动。

实战工作流

在 yournextstore 仓库中使用 critique 的完整链路：

bun dev            # 启动开发服务器（端口 3000），critique 需要可访问的运行界面

1. 调用技能：以 /critique（整体）或 /critique <area>（针对某功能区域）触发；技能先加载 frontend-design 的 DON'T 清单作为判定基准；
2. 阅读报告：从 Anti-Patterns Verdict 的 Pass/Fail 开始，再看 Priority Issues 的排序——每个问题都有 What / Why it matters / Fix / Command 四字段，可以直接作为任务拆解依据；
3. 按映射的 Command 分派修复：例如色板问题走 /colorize，节奏问题走 /quieter，收尾细节走 /polish——所有命令都在 skills-lock.json 中有注册记录，不存在凭空推荐的命令；
4. 用工程手段复验：bun test 会顺带执行 palette.test.ts 的 WCAG AA 断言；bun run audit <url> 对运行中的 URL 做 Lighthouse 性能 + 可访问性审计（AGENTS.md 与 AGENTS.md 的验证清单要求 accessibility ≥ 0.98 且无新增失败项）。

边界与适用前提

• critique 是评审技能：它生成报告并映射修复命令，自身不修改代码；仓库为只读模板，修复动作发生在你的门店分支上；
• 它依赖 frontend-design 技能提供判定标准——两者都需在 .agents/skills/ 下存在（当前仓库已同时包含，且 skills-lock.json 对来源 pbakaus/impeccable 做了哈希锁定）；
• 维度 1（AI Slop Detection）引用的"AI 特征清单"时效上锚定在 2024–2025 年间的 AI 生成界面惯例，作为反模式指纹使用，而非对任何具体产品的指控；
• 报告质量受"六条 Remember"约束——直白、具体、说明用户影响、给具体修复、无情排序、不软化批评——这是该技能对"AI 输出常见设计反馈"本身的一组元层面防御。

综合来看，critique 技能把"设计总监的评审"拆成了可复现的工件：一份固定的十维度问题清单、一份固定的六段式报告模板、一张与已安装技能严格对齐的命令白名单；而 yournextstore 又用 OKLCH token、bun test 对比度断言与 Lighthouse 审计把其中可量化的部分（对比度、可访问性）从"批评"变成了"断言"，这正是该项目"为 AI 开发而建"理念在设计质量环节的具体体现。