“帮我把这个页面做得更好”其实包含至少三个不同问题：
它有没有清楚、具体的视觉方向？
React / Next.js 实现有没有性能问题？
键盘、语义、对比度和 UX 是否合格？
把三个问题交给同一个万能 Skill，结果通常是设计建议、性能口号和无障碍清单混在一起。更可控的做法是拆成三次工作：
frontend-design建立视觉方向；- Vercel React Best Practices 审查实现与性能；
web-design-guidelines审查可访问性和 UX。
本文在一个独立 Next.js 16 页面上按这个顺序执行，并保存 baseline、diff、构建记录、两种视口截图和 axe 结果。
| 项目 | 说明 |
|---|---|
| 内容类型 | 三种 Skill 机制对照与分阶段前端实验 |
| 适合读者 | 想让 Codex 改前端页面，又不希望设计、性能和 UX 混成一轮的开发者 |
| 阅读 / 跟做时间 | 约 12 分钟 / 30–45 分钟 |
| 前置条件 | 可运行 Next.js production build，并能做桌面、手机与 a11y 检查 |
| 页面 | 中文 Agent Skill 候选目录 |
| 框架 | Next.js 16.2.10、React 19.2.7 |
| frontend-design | anthropics/skills@b29e7cf |
| React Best Practices | vercel-labs/agent-skills@7c180d9 |
| Web Design Guidelines | 同上，在线规范另固定到 4e799d4 |
| 视口 | 1440×900、390×844 |
| 构建 | baseline 与 final 均通过 production build |
| 浏览器验收 | console 0 error、键盘焦点通过、axe violations 0 |
| 核对日期 | 2026-08-01 |
一分钟概览
frontend-design负责决定“长什么样”，不是性能审查器。- React Best Practices 是 70+ 条分级规则库，最容易被误用成一次性加载 112 KB 全集。
- Web Design Guidelines 的 Skill 只有 39 行，但每次会联网取最新规范，复现风险最大。
- 本例视觉阶段改变最多；性能阶段最重要的结果是拒绝无收益优化；UX 阶段修掉真实 P1/P2。
- 三个 Skill 不必总是一起用，先判断问题属于哪一层。
1. 三个 Skill 的机制完全不同
| Skill | 入口结构 | 核心机制 | 主要风险 |
|---|---|---|---|
frontend-design | 单个 55 行 SKILL.md | 设计方向、token、排版、布局、自我批评 | 大幅视觉改写 |
| React Best Practices | 149 行入口 + 72 个 rule 文件 | 分优先级按需读取具体性能规则 | 误加载 112 KB 完整 AGENTS.md |
| Web Design Guidelines | 39 行入口 | 每次从远程 URL 获取最新 review 规则 | 同一 revision 结果仍会变化 |
因此它们对上下文的影响也不同。
frontend-design 主要成本是一次读取约 8.3 KB 的设计约束。React Skill 的入口约 7.4 KB，但完整 AGENTS.md 是 112,071 bytes、3,810 行。Skill 文案写“70 rules”，固定 revision 实际有 72 个 rules/*.md；这类小漂移也说明统计数字需要对应 revision。
Web Design Skill 的本地内容最小，却把真实规则移到了网络。上下文占用可能不大，可复现性成本却最高。
2. Baseline：能用，但没有明确理由
基线页面已经具备：
- 一个 hero；
- 三张候选卡片；
- 评分、运行依赖、证据状态和推荐理由；
- 移动端单列；
- 静态 Server Component。
未使用三个前端 Skill 的基线页面：居中白色 hero、紫色评分和三张通用卡片
图 1：基线可以交付，但视觉语言和“Skill 审计”主题没有关系，按钮也没有真实行为。
它的问题不是难看，而是几乎所有 SaaS 卡片页都可以长这样：浅灰背景、白卡、紫色强调、圆角阴影、居中大标题。
更严重的问题是“查看审计”只是一个没有行为的 button。视觉上像承诺，功能上却没有结果。
3. frontend-design：先写方向，再写代码
我先把页面主题固定为“研究者的田野索引卡”，而不是直接换颜色：
| 设计轴 | 决定 |
|---|---|
| 主题材料 | 纸张、索引卡、审计标记、手册页边线 |
| 色彩 | 纸灰 #e9eadf、墨绿、铁锈红、深芥末色 |
| 字体角色 | Georgia 大标题、系统中文正文、等宽证据标签 |
| 布局 | 大标题错位，候选卡片像连续编号的审计页 |
| 签名元素 | “先验收 / 再安装”两行错位标题与卡片顶部状态色条 |
这一步实际改变的是信息表达：评分变成视觉中心，证据状态和运行依赖退到审计元数据；“三层验收”成为页面下半段的方法说明。
应用 frontend-design 后的最终桌面页面：纸张底色、错位中文大标题、审计标签和连续索引卡
图 2：最终桌面页。视觉风险集中在标题和色条，其余元素保持克制。
我没有引入远程字体、图片或动画。原因不是 Skill 禁止，而是这个主题不需要它们；新增依赖会让后续性能阶段替设计阶段还债。
4. React Best Practices：最有价值的结果可能是“不改”
React Skill 把规则按影响分为 waterfalls、bundle、server、client、rerender、rendering、JavaScript 与 advanced。我的页面没有数据请求、客户端状态和第三方 bundle，因此只按需检查：
bundle-*：是否引入不必要的包或 barrel import；rendering-*：静态内容是否有明显渲染成本；rerender-*：是否错误加入客户端状态或 memo。
审查结果：
skills已在组件外，不会每次 render 重新创建；- 页面不需要
use client； - 只有三条静态记录，不值得加
content-visibility； - 没有昂贵组件，不需要
next/dynamic； - 没有计算热点，不需要 memo；
- 系统字体避免新增网络与字体 bundle。
性能阶段没有为了证明 Skill “生效”而制造改动。这恰恰是分工的意义：设计阶段可以大胆改变视觉，性能阶段只接受有机制和证据的修改。
5. 为什么不读取完整 AGENTS.md
固定 revision 的 React Skill：
SKILL.md 7,400 bytes / 149 lines
AGENTS.md 112,071 bytes / 3,810 lines
rules/ 72 markdown files
如果任务只是审查一个静态目录页，一次性读完 112 KB 会让大量与当前页面无关的 server cache、SWR、复杂 hydration 和 JavaScript micro-optimization 进入上下文。
我采用的路由是：
先判断页面有没有请求、客户端状态、重包、长列表
→ 只选相关类别
→ 读取对应 rule 文件
→ 给每个 finding 绑定真实代码
这比“加载完整最佳实践，然后凭印象改”更省上下文，也更容易说明为什么没有采用某条规则。
6. Web Design Guidelines：在线最新不等于可复现
web-design-guidelines 的流程很直接：
- 每次 fetch 最新
command.md； - 读取目标文件；
- 按全部规则 review；
- 输出
file:linefindings。
问题是，本地 Skill revision 没变，远程 main 也可能变化。同一份页面下周得到不同 findings，并不一定是模型漂移。
本轮把在线规范固定为：
URL https://raw.githubusercontent.com/vercel-labs/web-interface-guidelines/4e799d4.../command.md
commit 4e799d45c17aec1498c269287a83b9dba22b966b
date 2026-08-01
SHA256 FB9B73DD69CEAD884F29E8A6FB0ADF53D525E65D4BF82C51F78F2C781638F2F1
实验包保留带元数据头的 snapshot；原始 SHA 不包含这段本地头部。
7. UX 与 a11y 阶段修了什么
第一轮 review 找到这些可操作问题：
| 严重度 | Finding | 修改 |
|---|---|---|
| P1 | 无行为的“查看审计” button | 改为指向真实方法段落的 link |
| P1 | 重复卡片没有列表语义 | 改成 ul > li > article |
| P2 | 键盘焦点依赖弱默认样式 | 加高对比 :focus-visible |
| P2 | 平滑滚动没有 reduced motion 边界 | 在偏好减少动态时关闭 |
| P2 | 移动端方法步骤可能拥挤 | 单列布局并收窄网格 |
随后用 agent-browser a11y 跑 axe 4.12.1。第一轮还有一个 serious violation：黄色评分 #bd812b 在纸张背景上的对比度是 2.97:1，低于大字号文本要求的 3:1。我把它调为 #976316 后重建、重截并复测，最终 violations 为 0。
axe 同时把 header[aria-labelledby] 与无 role 的 div[aria-label] 标为 incomplete。我删除了不必要的 ARIA，让可见分数字符直接进入可访问名称；背景页边线也从 gradient 改为伪元素，减少“无法判断背景色”的自动化不确定项。
最终页面在 390×844 下的截图：标题、候选清单和状态色条在窄屏保持可读
图 3：移动视口。截图只覆盖首屏，完整页面仍由浏览器脚本继续检查链接焦点和控制台。
8. 构建与输出数据
| 指标 | Baseline | Final |
|---|---|---|
| Next production build | 通过 | 通过 |
| 构建耗时 | 8,879 ms | 8,807 ms |
| 静态输出大小 | 917,261 bytes | 931,547 bytes |
| 浏览器验收命令 | 10 | 10 |
| 控制台错误 | 0 | 0 |
| 键盘焦点检查 | 通过 | 通过 |
最终输出增加 14,286 bytes，主要来自 HTML 与 CSS；没有增加第三方依赖。两次构建时间差只有 72ms，在单次本机实验里没有性能意义。
页面的代码差异、stage summary、findings 与截图均保存在 examples/agent-skills-practical-lab/runs/frontend/。
9. 什么时候只用其中一个
| 任务 | 只用哪个 | 不必加载什么 |
|---|---|---|
| 新 landing page 没有视觉方向 | frontend-design | 不必先读 72 条 React 规则 |
| 现有 Next.js 页面明显变慢 | React Best Practices | 不要让视觉重做扩大 diff |
| 发布前检查键盘、语义和 UX | Web Design Guidelines | 不需要重新定品牌语言 |
| 组件库重构 | React + Web Guidelines | 视觉方向已由设计系统决定 |
| 从零完成重要产品页 | 三个分阶段使用 | 不要在同一轮混合所有目标 |
顺序也很重要。先用性能 Skill，再大改视觉，前面的 review 很快失效；先做视觉实现，再做性能和 UX 收口，更容易把 finding 绑定到最终代码。
10. 我会保留的工作流
写真实页面内容和单一目标
→ baseline build + screenshot
→ frontend-design：方向、token、signature
→ build + desktop/mobile screenshot
→ React rules：只读相关 reference
→ build
→ 固定 Web Guidelines URL/commit/SHA
→ findings review
→ console + keyboard + axe + 双视口
→ 保存 diff 与未解决项
三个 Skill 最值得保留的不是三份“更好页面”的指令，而是三种不同的判断责任。设计负责做选择，性能负责要求机制，UX 负责保护真实用户。
系列从 Agent Skills 筛选方法开始，上一篇是 agent-browser 语义快照实测。关于 Skill 的加载方式、目录结构与 eval，可以回到 Codex Skills 入门和进阶篇。