这个 UI 审查 Skill 58.8 万次安装，报错直接给行号

58.8 万次安装，3.06 万 GitHub Star，一条命令就能装。

npx skills add https://github.com/vercel-labs/agent-skills --skill web-design-guidelines

它干的事也不绕，拿 Vercel 的网页界面规范审查 UI 代码，再把问题按 file:line 吐出来。

不是再生成一版页面，不是给按钮刷个渐变，也不是把三个功能卡片换成四个。它做的是代码写完后那道经常被省掉的工序，看看图标按钮有没有名称，输入框有没有标签，键盘能不能走到操作区，动画会不会把容易眩晕的用户晃得难受，图片尺寸有没有提前声明。

很多朋友可能不知道，skills.sh 的公开页面显示，这项 Skill 已有 588.6K 次安装，所属的 Vercel Labs agent-skills 仓库约 30.6K Star。好家伙，一个做检查清单的 Skill，热度追到了不少生成型工具前面。

这事挺能说明问题。大家已经不缺「帮我做个好看的落地页」了，缺的是「你做完后，谁替我盯住那些截图里看不见的坑」。

58.8 万次安装，买的不是审美

打开它的公开规则，会看到一份不太浪漫、但很像真实上线检查的清单。图标按钮需要 aria-label，输入框要有 <label>，动作优先用 <button>，导航应该用 <a>，焦点不能被 outline: none 一刀切掉，动画要尊重 prefers-reduced-motion，图片要写明宽高，长列表要考虑虚拟化。

完整规则放在 Vercel Web Interface Guidelines，Skill 每次审查前会读取最新的规则文件。这点有点子牛逼。UI 规范最怕变成贴在团队 Wiki 里的一张化石，写下那天全员点头，三个月后谁也不看。它把规范放回任务现场，代码变了就再审，规则变了也跟着更新。

而且输出格式刻意压得很短。

src/Button.tsx:42 - icon button missing aria-label
src/Modal.tsx:34 - "..." -> "…"
src/Card.tsx:67 - transition: all -> list properties

没有八百字的 UI 哲学，没有「建议进一步优化用户体验」这种读完仍不知道改哪儿的空气。文件、行号、问题，完事。

我自己的感受是，这才是 Skill 适合承接的工作。生成页面需要理解品牌、内容、受众和视觉方向，主观判断很多。规则审查相反，它有稳定输入、明确边界和固定输出，失败也容易验收。Agent 在这种窄而硬的任务上，往往比在「帮我设计得高级一点」里更靠谱。

同一张页面，修完看着几乎没变

为了看看它到底会抓什么，这次做了一个 47 行的静态页面，故意留下一批常见问题。

页面上有搜索框、新建部署入口、三个指标卡片。鼠标点起来都正常，截图也算干净。要是验收只停在「Chrome 能打开」「产品说差不多」，它大概率就过去了。

按公开规则逐条过一遍，得到 12 条明确问题。其中几条很典型。

demo-before.html:29 - icon button missing aria-label
demo-before.html:35 - input lacks label, name and autocomplete
demo-before.html:36 - div onClick used for navigation -> use <a>
demo-before.html:17 - outline removed without focus-visible replacement
demo-before.html:12 - transition: all -> list properties
demo-before.html:31 - missing skip link for main content

最有意思的地方来了。把图标按钮补上可读名称，把搜索框接到真实 <label>，把伪装成按钮的 <div> 换成链接，再补焦点样式、跳转主内容入口和低动态模式，页面外观没有翻天覆地的变化。

截图前后只多了一个可见标签，按钮颜色略微调整。可对键盘用户、屏幕阅读器用户和关闭动画的用户来说，它已经不是同一张页面了。

这就是此类审查最容易被低估的原因。视觉验收只能看见视觉，交互合同藏在 DOM、CSS 和状态管理里。设计稿不会提醒你 transition: all 可能带来多余的布局动画，也不会在按钮旁边画一个 aria-label。浏览器里点得通，更不等于按 Tab 走得通。

修完以后，最便宜的复查动作不是再截一张图，而是先把鼠标放下。按一次 Tab，焦点应该落到「跳到主要内容」，继续按会依次经过设置、搜索框和新建入口。按 Enter 能走导航，点击后焦点环不会黏在按钮上，系统开启「减少动态效果」时也不会继续播放无关动画。

这套动作不高级，甚至有点朴素。可它把抽象的「无障碍做得更好」变成了能重复的验收步骤。代码里看到标签只是第一层，浏览器里真的走通才算交货。Agent 负责提醒和改代码，人负责确认页面在真实状态下没有别的岔子，谁也别抢对方的锅。

厉害了，改动最值钱的部分，恰好最不适合拿 Before 和 After 做夸张营销。

装上以后，别只喊一句「审查这个页面」

安装后可以直接把文件或 glob 交给它。

使用 web-design-guidelines 审查 src/components/**/*.tsx
只输出 file:line，按 accessibility、focus、forms、animation、performance 分组
修复高置信问题，涉及产品行为的改动先列出不要直接改

这个调用里有三个小动作很重要。

一是把范围钉住。不要让它从整个仓库扫到构建产物和第三方组件，噪声一多，真正的风险会被淹掉。新页面可以审整个目录，老项目更适合从本次 diff 或核心交互组件开始。

二是把输出钉成 file:line。这不是排版洁癖，而是让结果能进代码审查。团队可以把清单贴进 PR，也可以按行逐条确认，不需要从长报告里手工摘任务。

三是把「发现」和「修改」分开。像缺少 aria-label、使用 transition: all 这类高置信问题，可以直接修。可删除动作要选确认弹窗还是撤销窗口，筛选状态要不要写进 URL，这些会碰产品行为，别让 Agent 自己拍脑袋。

拿到清单后也别全选全改。我会先看会阻断操作的问题，像键盘走不到按钮、表单没有可读标签、删除没有退路，这些优先级最高。再看会在规模上放大的问题，像几十个受控输入框每次按键都触发重渲染，或者长列表一口气把几百项塞进 DOM。纯文案与排版建议放在后面，它们通常最显眼，却未必最危险。

还要留一栏给误报。某个图标可能在组件封装层已经提供可读名称，某个弹窗可能由成熟组件库负责焦点锁定，单看调用文件不一定看得出来。把这类上下文写回项目约定，比每次都跟 Agent 争同一道题更省事。下一次审查带上约定，结果会干净很多。

坦率讲，这玩意更像一个会说人话的静态检查层，不是第二个设计师。你还可以把它跟现有工具叠起来。HTML 语义和无障碍规则交给它做广覆盖，真实浏览器行为再用 Playwright或 axe-core跑确定性测试，性能问题进 Lighthouse，视觉回归留给截图差异。

别把一份提示词当成 CI 的唯一真相。Agent 会漏报，也可能把上下文相关的设计选择当成错误。它适合缩小人工审查范围，不适合替你签上线确认单。

哪些场景别用，边界比安装命令更重要

纯后端仓库没必要装，设计探索早期也别太早拿规则清单压灵感。一个还在找方向的概念页，被一百条生产规范追着跑，很容易先把味道修没了。

它也不会替你判断品牌是否成立。字体有没有性格，页面是否贴合产品，信息层级是不是在讲一件清楚的事，这些仍需要设计判断。aria-label 全部补齐的页面，照样可能丑得很稳定。棒棒的，合规了，然后呢。

真正合适的时机，是 UI 已经进入可交付阶段，或者 Agent 刚生成完一批组件。此时创意方向基本定了，代码量又大，人最容易对细小重复项失去耐心。让规则审查先扫一轮，人再把注意力留给高价值判断，分工很顺。

如果团队想把它接进日常，我会建议从一次小范围试跑开始。挑一类高频页面，只审本次改动，保留 file:line 结果，修完再跑浏览器测试。连续几次观察误报和漏报，再决定要不要扩大到全仓库或 PR 门禁。

AI 做 UI 的下一步，未必是再会一种玻璃拟态。

可能只是终于肯在交稿前，认真检查一遍 Tab 键。