背景：
我在做一个校园美食评价社区的 H5 项目。设计流程是这样的：产品需求和设计稿定好之后， Gemini 负责具体页面的设计，跑通之后再交给我 review 页面是否有问题。
这个事并不复杂，但是，让我一条条对着 spec 去检查，既费时间，又容易遗漏。
问题不在难，而在琐碎。我想把这种重复的事交给 agent 去做。
于是，我用Claude Code 建了一个 审查 Agent 专门用于进行重复的审查工作。下面想分享一下我的做法。
工具：Chrome DevTools MCP
MCP（Model Context Protocol）你可能已经听说过。简单来说，它是一套标准协议，让 AI 能通过工具调用去操作外部系统。
Chrome DevTools MCP 是 Chrome DevTools 官方维护的一个 MCP server，做的事情是：把一个受控的 Chrome 实例的能力暴露给 AI------截图、读取 accessibility snapshot、执行 JavaScript（拿 computed style）、抓控制台与网络请求、模拟移动端视口、点击和输入......
这一点很关键。"代码写对了"和"页面长对了"是两回事：
- AI 审查源代码 ，只能发现逻辑层面的问题（API 用错了、props 漏传、状态机分支没覆盖）。
- AI 审查渲染结果 ，才能发现视觉层面的偏差（间距错了 2px、token 用成了 hover 态、移动端视口下溢出、aria 标签缺失）。
只有后者贴着 ui 设计稿 去比对，才算真正的"还原度审查"。
配置：在项目里启用 chrome-devtools MCP
如果你已经配置过，可以跳过这部分。
和大多数 MCP server 一样，chrome-devtools-mcp 通过 npx 拉起，不需要装任何 Chrome 浏览器扩展------它会用 Puppeteer 自己启动一个受控的 Chrome 实例。
Claude Code（仓库内集成） ：在项目根目录写一个 .mcp.json：
json
{
"mcpServers": {
"chrome-devtools": {
"type": "stdio",
"command": "npx",
"args": ["chrome-devtools-mcp@latest"]
}
}
}Claude Code 会自动加载这个文件。这样配的好处是：MCP 配置跟着仓库走，团队里所有人 clone 下来就能用。
Claude Desktop ：在 claude_desktop_config.json 里加同样的 mcpServers 配置即可。
重启 Claude，工具列表里能看到 mcp__chrome-devtools__take_screenshot / take_snapshot / evaluate_script / emulate 等一系列工具，就说明 MCP server 已经接好了。第一次运行 npx 会拉镜像并启动 Chrome，稍微等一下。
工作流设计：让审查 subagent 动起来
我把审查工作流设计成这样：
启动
审查 subagent · ui-spec-reviewer
① 读 设计稿 + 参考图
② navigate_page · 打开页面
③ emulate · 切到移动端视口
④ take_screenshot · 截图
⑤ take_snapshot · 读 DOM 树
⑥ evaluate_script · 取 computed style / 实测尺寸
⑦ list_console_messages · 抓控制台报错
⑧ 与 设计稿 对比 → 输出结构化 gap list
主 agent（任务调度）
它的定位很专一：只读、不改代码、只输出结构化的差异清单。调用的时候传入模块名，它会自己去找对应的 ui-spec.md 和 images/，然后通过 chrome-devtools MCP 去访问本地预览，逐项比对
它返回的东西大概是这样一份 清单：
- 缺失的状态（loading / empty / error / login / report / delete 这些 ui-spec 里列出但代码里没实现的）
- 文案不一致（按钮、提示、空态描述对不上 spec）
- 布局偏差（间距、对齐、断行）
- token 误用（写了硬编码 hex 而不是
sy-*变量；用了 hover 态颜色作为默认态）
而做成 subagent 除了方便以外有一个好处，在审查时会产生很多截图和 DOM dump，而独立上下文能避免把主 agent 的"脑子"塞满。
实际效果
修改前
能明显看出来的问题：
- 底部导航与详情页互动栏重叠
- 图片引用无效，详情页会出现 404 或占位
- 图标使用 emoji 未使用组件库图标
...
ui-spec-reviewer 跑完之后，把它们整理成了一份清单，对照修复就行。
修改后
按这份清单修改过之后：不仅达到了想要的效果，同时顺手补了代码里漏掉的几个状态（评论空态、举报弹层）。
MCP 在这里真正解决了什么？
有一个值得细说的点：Chrome DevTools MCP 的核心价值是"看见渲染结果"，而不是"读代码"。
以"标签样式较弱"这个问题为例------如果只看源码，<Tag> 组件存在、className 也写了、ui-spec 里"浅粉色 chips"的描述也对得上，乍看代码是正常的。但实际渲染时，因为某条全局样式 / antd-mobile 默认样式把 background-color 覆盖成了透明，chip 的视觉效果就消失了。
这种"代码看着没问题、页面看着不对"的情况，在代码层面很难一眼发现。但 MCP 让 Claude 直接读取了元素的 computed style，实际值是 rgba(0,0,0,0)，问题立刻浮出水面。
这就是"能读代码的 AI"和"能看页面的 AI"之间的本质区别。
小结
这套流程跑通之后，一个页面从"AI 写完"到"还原度 OK"之间的来回，明显短了一截。我不再需要一条条文档对着页面看，把这种琐碎活转给 ui-spec-reviewer + chrome-devtools MCP 就行，自己只看它输出的清单决定哪些要修。
Chrome DevTools MCP 是我目前用过的 MCP 里比较实用的，推荐使用Claude Code辅助开发的朋友都可以尝试一下------只要你有一份认真写过的设计稿，它就能帮你把"还原度"这件事自动化掉一大半。
如果你也在用类似的工作流，欢迎在评论区分享你的经验。