UI 上线前怎么走查？13.6 万 Star 的 design-review 把审美题变成证据题

页面做完了，按钮能点，接口也没报错。可准备提 PR 的时候，还是会有人说一句最难接的话。

「看着有点不对。」

这句话讨厌，不是因为它错，而是因为它没有坐标。到底是标题层级抢戏、间距没规律、移动端挤成一团，还是交互慢半拍？如果问题说不清，后面的修改就很容易变成一轮轮换颜色、调圆角、再换颜色。

最近看到 garrytan/gstack 里的 design-review，我觉得它值得被单独拎出来。它不负责从零生成一个好看的页面，干的是更适合交付前的活，找视觉不一致、间距、信息层级、常见的模板感和慢交互，然后逐项修复，再拿前后截图复核。

截至 10 月 8 日，这个仓库在 GitHub 上有 135,750 个 Star。这不是它一定适合你的理由，却说明很多人已经被同一件事卡过，页面不是不能跑，而是缺一个把「感觉」翻成可验证问题的环节。

上图是 GitHub 公开社交卡，不是本文实测截图。

我没有在本文里实际运行这套设计走查流程，也不会把它写成一次虚构的改版战报。下面只基于公开说明，聊一个更实用的问题。

做完页面后，什么情况下值得从「帮我看下好不好看」升级到一次正式的设计走查？

它解决的不是审美不足，而是验收语言不足

一个常见误会是，设计 QA 等于找个很会审美的 Agent 来挑毛病。

不完全是。

真正麻烦的地方在于，产品、设计和工程师经常在看同一个页面，却各自在脑中用不同的尺子。产品盯转化路径，设计在看重心和节奏，工程师关心组件有没有复用。到头来大家说出来的话常常只剩「再精致一点」。

design-review 的公开约定里有一个很对的顺序，先做视觉审计，问题会覆盖视觉一致性、留白、层级、界面里那种说不清的批量生成感，以及交互是否迟缓。随后才进入修复，而且每次修复要用前后截图重新验证。

这顺序很重要。截图不是为了留档好看，而是把「我觉得」钉到具体画面上。比如把「卡片有点乱」换成下面这种说法。

首屏的三个操作入口权重接近，用户第一眼无法判断主操作。把主操作拉开尺寸和对比度，次操作退回文字按钮后，再比较同一视口截图。

前一句几乎无法分工，后一句可以交给任何人执行，也能在下一张截图里判断有没有变好。

这也是我更愿意把它当成「设计 QA」而不是「美化工具」的原因。它把 UI 的讨论，从品味竞争拉回了可观察的用户任务。

哪三类页面最该跑一次

第一类是 AI 刚帮你搭完的管理后台、落地页或内部工具。它们往往没有明显 bug，却很容易出现同一种症状，标题、卡片、按钮都各自正确，放在一起就像三套组件库临时拼桌。此时最有价值的不是再让 Agent「做得高级一点」，而是先截一张桌面图和一张移动端图，找出重复的视觉语法到底哪里没对上。

第二类是刚合并了大改动的核心流程。注册、付款、创建项目、提交表单这些地方，静态首屏可能漂亮，真正点击后却会暴露加载态、禁用态、错误提示和返回路径。公开说明中，完整审计会查看多个可达页面，也会在移动、平板、桌面尺寸下留截图。这个思路比只在自己 27 寸显示器上扫一眼靠谱得多。

第三类是团队开始听到「产品能用，但不像一个产品」的时候。别急着重做视觉系统。先确认问题是不是可重复出现的，例如字号层级跳跃、同一类按钮有两套半径、颜色没有语义、表单错误只靠红字提醒，或手机上需要悬停才能发现的操作。能被描述为规则的问题，通常先不用推倒重来。

配图是围绕本文走查流程生成的概念插画，不是产品实测截图。

反过来，如果你只有一个静态概念稿，或者品牌方向本身还没定，先跑它大概率会太早。设计走查能修「实现没有兑现既定意图」，不能替你回答「这个产品到底该长什么样」。前者适合 design-review，后者先做产品和视觉方向。

一次有用的走查，最少要留下这四样东西

你不必等到装完整套工作流，先把下面四样东西补齐，团队的 UI 讨论就会立刻清楚很多。

同一状态下的三张截图。 桌面、平板、手机不是额外工作，它们是同一个界面的三次质询。官方流程里用到 1440、768 和 375 这三个宽度，正好能逼出宽屏隐藏、窄屏溢出和触控目标过小的问题。

按用户影响写的发现。 少写「间距不统一」，多写「价格比较区的月付和年付放在同一视觉层级，用户很难看出推荐方案」。前者是 CSS 描述，后者才是产品问题。

一项改动对应一个复核点。 不要把字体、配色、表单和动效揉成一次大提交。改一个问题，回看它影响的页面和尺寸。公开说明强调原子化修复和前后截图，核心并不神秘，就是别让十个变化互相掩盖。

明确的停手线。 页面不是视觉竞赛。首屏能读懂、主操作显眼、关键状态可达、不同尺寸不坏，已经比再添一层玻璃拟态更接近交付。没有停手线，所谓「再 polish 一下」会把团队拖进无穷回合。

你可以把这四样东西直接丢进 PR 描述里。它比一段「已优化用户体验」有用得多。

怎么装，怎么开第一轮

gstack 的 README 给了面向 Codex 的安装方式。它是一个较大的工作流集合，所以我会建议先在非关键分支或小页面上试，不要一上来让它改整个线上产品。

git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/gstack
cd ~/gstack
./setup --host codex

安装后，先把目标说得窄一点。不要只写「帮我优化 UI」，可以这样描述。

对当前分支影响到的创建项目流程做一次设计走查。
保留现有品牌色和组件库。
先输出桌面与手机截图、按用户影响排序的问题清单，
每次只修一个问题，并在修后给出同视口对照。

这段提示词真正有价值的地方，不是多写了几个形容词，而是把范围、不可改动项、证据和修复粒度提前讲明白了。让 Agent 同时改所有东西，看上去很快，出了问题却不知道该回退哪一刀。

还有一个边界值得留心。公开文档提到，如果本机已经有 impeccable 的检测引擎，design-review 可以把它的机械检查接进来，帮助发现部分可机器识别的设计问题。它依旧只是证据，不是裁判。规则能发现对比度、尺寸或一致性风险，却不知道你这次到底想让用户先看价格、作品还是提交按钮。

所以别把分数当审美，也别把截图当真相。截图只能告诉你画面有没有变，真正要验的是用户下一步会不会更自然。

从这个角度看，13.6 万 Star 最值得抄的不是一条命令，而是一种交付习惯。

做完 UI 以后，别再问「好不好看」。

问「哪一个用户任务，在什么尺寸下，被哪一个视觉决定拖慢了」。

这才是一次值得跑的设计走查。

如果你现在做的产品里只能挑一个流程来跑首轮设计 QA，你会先挑注册、支付，还是创建项目？

小岛 AI，记录一线实战、踩坑与成长。