web-design-guidelines（网页界面审查技能）Skill 是什么？

网页界面审查技能：让 UI 代码在合并前就符合可访问性与体验最佳实践

它是什么：由 Vercel 出品的 web-design-guidelines（网页界面审查技能）技能，用一句话说，就是“把资深前端 + 设计评审的检查清单交给 AI，逐行审查你的 UI 代码”。
核心能力：覆盖可访问性、焦点状态、表单、动画、排版、图像、性能、导航与状态、触摸交互、深色模式、国际化、水合安全、文案等十余类规则，并内置一份“反模式清单”用于重点标注。
输出友好：结果按文件分组，使用 文件:行 格式（在 VS Code 等编辑器中可直接点击跳转），只陈述问题与位置，不写废话，信噪比极高。
使用门槛低：不需要配置 ESLint 插件、不需要跑浏览器审计，用自然语言说“审查我的 UI”“检查可访问性”即可触发。
定位清晰：它不替代自动化测试与人工设计评审，而是补上“规则性体验问题”这一最容易被漏掉的中间层。

该技能叫什么？如何一键安装 AI 技能提升开发效率？

这个技能的中文名是网页界面审查技能，英文名 web-design-guidelines，技能 ID 为 11783，作者为 vercel，版本 1.0.0。

它解决的问题非常具体：前端团队在写 UI 时，大量体验问题并不是“功能不对”，而是“不够规范”——图标按钮漏了 aria-label、输入框没有 <label>、动画忘了尊重 prefers-reduced-motion、用了 transition: all、<img> 没写宽高导致 CLS、模态框忘了 overscroll-behavior: contain。这些问题单看都不致命，但堆积起来就会让产品显得“粗糙”，并且带来真实的可访问性障碍。传统做法依赖个人经验记忆或零散的 Code Review 清单，而该技能把这些规则固化下来，交给 AI 逐条比对代码。

一键安装的思路与步骤：

确认安装前提：需要一个支持“AI 技能（Skill）”机制的运行环境或 IDE 扩展，并已登录可用的模型服务。具体支持的客户端、账号要求与版本限制，以官方说明为准。
通过技能入口添加：在技能市场、技能仓库或扩展面板中搜索技能 ID 11783 或英文名 web-design-guidelines，点击安装/启用。若你的环境通过配置文件声明技能，则按官方文档给出的字段填写技能名与版本。具体命令与配置格式以官方说明为准。
完成授权与启用：安装后确认该技能在“已启用技能”列表中处于开启状态，并允许其读取你工作区内的代码文件（该技能的工作方式包含“读取指定文件”）。
验证是否生效：在对话框中输入一句最简单的触发语，例如“审查我的 UI，文件是 src/Button.tsx”。如果技能已生效，它应当先获取最新的网页界面指南，再读取该文件，最后以如下格式输出结果：

## src/Button.tsx

src/Button.tsx:42 - 图标按钮缺少aria-label
src/Button.tsx:18 - 输入框缺少标签
src/Button.tsx:67 - transition: all → 列出属性

如果输出是按文件分组、带 文件:行 定位的简洁清单，说明安装成功；若它只是泛泛地夸你的代码“写得不错”，说明技能未被调用，需要检查启用状态或触发语。

该技能的主要功能和特点

多维度规则审查：一次检查即可覆盖可访问性、焦点状态、表单、动画、排版、内容处理、图像、性能、导航与状态、触摸与交互、安全区域与布局、深色模式与主题、本地化与国际化、水合安全、悬停与交互状态、内容与文案等十余个维度。
反模式重点标注：对 user-scalable=no、onPaste + preventDefault、transition: all、无替代的 outline-none、<div onClick> 导航、无尺寸图像、无标签表单、无 aria-label 的图标按钮、硬编码日期格式、无理由的 autoFocus 等典型反模式直接点名。
输出可定位：采用 文件:行 格式，VS Code 等编辑器中可直接点击跳转，修一个划一个，效率远超人工翻文件。
高信噪比：明确要求“输出简洁但全面——牺牲语法以求简洁”，没有开场白、没有客套话；问题修复不明显时才补充解释。
支持通过状态反馈：文件没有问题时会输出 ✓ 通过，方便判断哪些文件已经达标。
支持模式匹配：可以一次性传入文件或模式参数批量审查，而不是只能逐个文件看。
与普通工具的区别：ESLint 类工具擅长语法与静态规则，Lighthouse 擅长运行时指标，而该技能擅长“语义层面的界面规范”——比如该用 <button> 还是 <a>、占位符该不该以 … 结尾、加载态文案该怎么写这类兼具工程与设计判断的问题。

如何使用该技能？

第 1 步：打开支持技能的 AI 会话，确认 web-design-guidelines 已启用。

第 2 步：用自然语言触发。技能描述中给出的触发场景包括“审查我的 UI”“检查可访问性”“审核设计”“审查 UX”“检查我的网站是否符合最佳实践”。

第 3 步：指定要审查的文件或模式。这是最关键的一步，示例输入：

审查我的 UI：src/components/Button.tsx、src/components/Modal.tsx、src/components/LoginForm.tsx

或使用模式：

检查 src/components/**/*.tsx 的可访问性和最佳实践

第 4 步：技能按固定流程工作——先从源 URL 获取最新的网页界面指南，再读取你指定的文件，然后对照指南中的所有规则逐条检查，最后输出发现。

第 5 步：阅读并消化输出。输出会按文件分组，例如：

## src/LoginForm.tsx

src/LoginForm.tsx:12 - 缺少overscroll-behavior: contain
src/LoginForm.tsx:20 - "..." → "…"
src/LoginForm.tsx:31 - 提交按钮请求期间未显示旋转器

每行含义是“位置 + 问题”，→ 表示“应改为”。没有解释通常意味着修复方式显而易见。

第 6 步：修复后复审。改完再次触发同一指令，直到该文件输出 ✓ 通过。

第 7 步：未指定文件时的处理。技能会主动询问你要审查哪些文件，直接回答路径即可，不会自行猜测。

同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
web-design-guidelines（网页界面审查技能）	AI 驱动的界面规范审查	十余类界面规则逐条比对，输出 `文件:行` 定位	低：在支持技能的环境中添加并启用即可	提交前自查、组件库维护、代码评审辅助	优势：覆盖面广、规则具体、有反模式清单、无需写配置；不足：依赖 AI 环境，规则随官方指南更新，需联网获取
ESLint + a11y 类插件	静态代码检查工具	语法级规则校验、CI 中强制拦截	中：需安装依赖、编写配置、接入流水线	团队统一规范、持续集成门禁	优势：自动化、可阻塞合并；不足：偏语法层面，对“该用 button 还是 a”这类语义判断和文案规范覆盖有限
Lighthouse / 浏览器审计面板	运行时性能与可访问性审计	生成评分报告、指出运行时问题	低：浏览器内置或命令行运行	上线前体检、性能优化	优势：真实运行环境数据；不足：需要能跑起来的页面，难以在代码阶段发现根因，报告偏指标而非定位到行
Storybook 可访问性插件	组件级可视化测试	在组件故事中检测可访问性问题	中：需要项目已采用 Storybook	设计系统与组件库	优势：与组件开发流程贴合；不足：强依赖 Storybook 体系，纯代码层规则（如性能、水合）覆盖不足

选择建议：如果团队已有 CI 门禁，ESLint 与 Lighthouse 应当保留；该技能的定位是“代码评审阶段的第一道语义审查”，与它们互补而非替代。

该技能的典型应用场景与实际体验情况

场景一：前端工程师提交 PR 前的自查 角色是业务前端，痛点在于评审时被同事指出“图标按钮没有 aria-label”会很被动。使用方式是提交前对自己改动的 3-5 个组件跑一次审查。实际体验：上手几乎零成本，输入一句话就能拿到带行号的清单；注意事项是要提前指定文件，否则它会先反问你要审查哪些文件。

场景二：设计系统/组件库维护者 角色是基础组件维护者，一次改动会波及全站。使用方式是对整个 components 目录做批量审查，逐条修正后再次复审。实际体验：批量审查时输出会按文件分组，✓ 通过 的提示让“哪些组件已达标”一目了然；注意文件很多时建议分批执行，避免一次输入过长。

场景三：独立开发者或小团队上线前检查 角色是独立开发者，没有专门的设计评审与测试资源。使用方式是上线前对关键页面组件做一次全量审查，重点看表单、焦点状态与触摸交互。实际体验：这类团队往往最容易漏掉深色模式、安全区域、Intl 本地化格式等细节，该技能的规则清单刚好补上盲区；注意它给出的是规则性建议，是否采纳仍需结合产品实际。

场景四：接单/外包项目的交付前加固 角色是外包开发者，交付质量直接影响回款与口碑。使用方式是把审查结果整理成清单，作为交付报告的一部分。实际体验：明确的规则条目比“我优化了体验”更有说服力；注意输出本身很简洁，对外交付时可以自行补充说明。

该技能能为用户带来的价值

效率提升：原本需要逐条翻查清单、人工比对的界面规范检查，压缩为“一句话 + 一份带行号的清单”。规则条目累计数十条，人工记忆成本极高，交给技能后可以反复执行。
门槛降低：不要求使用者背下 WCAG 细节、不要求会写 ESLint 插件、不要求项目已接入 Storybook，刚入行的前端也能按清单逐条修。
质量前移：在代码阶段而不是上线后发现问题，避免“上线了才发现移动端双击缩放被禁用”“深色模式下原生下拉框刺眼”这类难以回滚的体验问题。
协作标准化：文件:行 的统一输出格式让评审沟通更短——“第 42 行缺 aria-label”比一大段描述更高效。
长期价值：反复使用会反向塑造团队习惯，让语义化 HTML、焦点可见、prefers-reduced-motion、tabular-nums 这些细节成为默认写法，而不是每次靠提醒。

常见问题 FAQ

Q1：这个技能怎么安装？需要付费吗？ A：在支持 AI 技能机制的环境或扩展中搜索技能名 web-design-guidelines 或技能 ID 11783，添加并启用即可；若通过配置文件声明，按官方字段填写。关于具体客户端支持范围、是否需要付费以及额度规则，以官方说明为准。

Q2：它只检查可访问性吗？ A：不是。可访问性只是其中一类规则，它还覆盖焦点状态、表单、动画、排版、内容溢出处理、图像尺寸与加载、性能、导航与 URL 状态、触摸交互、安全区域、深色模式、国际化格式、水合安全、悬停状态与文案规范，并单独列出了反模式清单。

Q3：它会自动改我的代码吗？ A：根据技能说明，它的职责是“审查并输出发现”，按 文件:行 格式给出问题与位置，修复动作由你自己完成。个别修复方式不明显的条目，它会补充极简说明。

Q4：它和 ESLint、Lighthouse 冲突吗？该怎么选？ A：不冲突，层次不同。ESLint 在语法与 CI 门禁层面自动化拦截，Lighthouse 提供运行时指标与评分，该技能则在代码评审阶段做语义与设计规范层面的审查。建议保留既有工具链，把该技能作为提交前的补充检查。

Q5：适合谁用？ A：业务前端、组件库维护者、独立开发者、外包交付方，以及需要在合并前对 UI 质量把关的技术负责人。如果你们的项目完全不含前端界面，则收益有限。