design-review

design-review 概览

design-review 是做什么的

design-review 是一个设计 QA skill，用来在真实代码库里抓视觉不一致、间距问题、层级问题、AI-slop 模式以及交互细节上的拖沓感，然后通过反复验证逐步修正。它特别适合那些希望一个 design-review skill 能从“这儿感觉不对”推进到具体源码改动和前后对比验证的团队。

谁应该使用它

当你需要一个有 UX 思维的 agent 去审查现有界面、打磨实现细节，或者 review 一个已经写进代码里的 UI 时，就该用 design-review skill。它很适合产品设计师、前端工程师，以及在应用中工作、并且更看重视觉一致性而不是从零生成新布局的 agent。

它有什么不同

和一个通用的 UX Audit 提示词不同，这份 design-review 指南是按工作流来设计的：它既能识别问题，也能做原子级修复，并重新检查结果。它还支持 plan-mode 分离，这在你想先 review、后实现，而不是立刻改代码时尤其重要。

如何使用 design-review skill

安装并路由任务

先通过你的 skills manager 使用 design-review 的安装命令，然后把 agent 指向包含待 review UI 的 repo。如果你在 plan mode 下工作，路由到 /plan-design-review；如果你希望直接改代码，就使用 skill 中描述的 active review 路径。

给 skill 正确的输入

一个好的 design-review 使用提示词会明确写出屏幕、用户流程，以及你最在意的失败点。更好的写法是：“Review checkout modal 在移动端的间距、层级和按钮清晰度，然后修复最严重的问题。” 不够好的写法是：“把这个弄得更好看。” 前者给了 skill 目标、约束和成功条件。

先读这些文件

如果你想判断这个 design-review guide 是否真的适合自己，先读 SKILL.md，如果仓库里有生成模板文件，再看 SKILL.md.tmpl。同时也要检查 repo tree 里的 prompt-routing 或 helper 约定，因为这个仓库的重点是 skill 正文，而不是配套脚本或文档。

按 review 循环来跑

把 skill 放进短周期里使用：检查、修补、验证、重复。让它说明改了什么、为什么改，并且最好每一轮只处理一类问题，比如排版、间距或交互延迟。这样可以让 review 更聚焦，也更容易发现回归问题。

design-review skill 常见问题

design-review 只适合最终润色吗？

不是。design-review skill 适合线上页面润色、代码库清理，以及类似 UX Audit 的检查场景——前提是视觉质量已经存在，但还需要进一步收紧。它在早期概念发散阶段不如在修复和验证已实现界面时好用。

我需要是设计师才能用吗？

不需要，但你得把屏幕和问题讲清楚。不是设计背景的人，如果能明确说明哪里不对、用户是谁、成功应该长什么样，通常比笼统地要求重设计更容易得到好结果。

它和普通提示词有什么区别？

普通提示词可能只会给出建议；design-review 则是围绕在代码里找问题、修改问题并检查结果来组织的。如果你只想要建议，这个 skill 可能超出需求；如果你想要可衡量的 UI 修复，它会更合适。

什么时候不该用 design-review？

如果任务纯粹是战略层面、品牌层面，或者只是内容本身而没有界面可检查，就先别用它。若你无法访问代码库，或者改完后也不能通过截图验证结果，它也不是很合适，因为这个 skill 的价值来自迭代式验证。

如何改进 design-review skill

先明确一个具体的 review 目标

design-review 的最佳效果来自窄范围目标：一个页面、一个组件，或一个用户流程。把视口、设备场景和核心关注点说清楚，比如“桌面端 settings page，重点看对齐和可扫读性”或“移动端 pricing card，重点看点击清晰度”。

告诉它要优化什么

如果你最在意一致性、可访问性、转化表达、还是交互速度，就一开始直接说出来。这样 design-review skill 才能在多个冲突修复方案里做取舍，尤其是在某个改动会提升一方面、却削弱另一方面的时候。

留意常见失败输入

常见的弱输入包括“make it cleaner”“improve the design”“audit everything”。这类提示词会引出范围过大、信号很低的输出。更强的输入会明确缺陷类型、组件范围，以及允许改动的幅度，这样可以减少不必要的编辑，也能让 design-review 的使用循环更有效。

用证据迭代

第一轮之后，继续要它列出剩余的 top issues、实际修改了哪些 files，以及截图里还能看到哪些回归。如果结果已经接近但还不够，就用更明确的约束细化 brief：keep layout unchanged、do not alter color palette，或者 only fix hierarchy and spacing。