写过前端的人都踩过这个坑——组件写完跑 Storybook 靠肉眼看，CyberAgent 今天把这件事用 Chrome DevTools MCP 彻底自动化了

写过前端的人都踩过这个坑——组件写完跑 Storybook，肉眼看过去没报错，心里以为就没问题。结果到了线上，某类用户的数据触发了边缘情况，控制台报错一片红，客服工单才追过来。UI 组件的运行时错误，是传统自动化测试最难覆盖的死角。 视觉渲染依赖真实 DOM 和 CSS 计算，单元测试摸不到，集成测试也很难模拟。

CyberAgent 就被这个问题卡了很久。他们的 Ameba 设计系统 Spindle 用了 Storybook 做组件开发和测试，32 个组件、236 个 Story，每次改完都要人肉一个个在浏览器里点开看有没有报错。改得多的时候，光过一遍就要大半天，还免不了漏掉。

今年他们试了一个新工具：Chrome DevTools MCP。一个 MCP 服务器，让 AI Agent 能直接控制一台真实的 Chrome 浏览器。

接法很简单，在 Claude Code 里加一行配置：

claude mcp add chrome-devtools npx chrome-devtools-mcp@latest

然后丢给它一句话：

Currently, spindle-ui’s Storybook is running, but runtime errors may be occurring. Please use chrome-dev-tools-mcp to confirm the operation of the Story in the following steps: Identify all target Stories. Confirm each and every one, no matter how many there are. Confirm that the Story is displayed correctly using dev-tools-mcp. Fix all errors. Click and move through each Story from the top in the browser opened with mcp to confirm.

接下来就是等。结果出来得很快：约 1 小时，Claude 把 Spindle 的 236 个 Story 全部跑了一遍，自己发现了 1 个运行时错误和 2 个警告，并且直接修掉提交了 PR。

这个过程里 Agent 做的事很实在：通过 Chrome DevTools MCP 读控制台日志、截屏验证渲染结果、点击导航到每个 Story、自动识别错误然后修改代码再验证。整个链路打通了，不是简单的截图贴给人类看，是真的在执行「发现→修复→验证」的闭环。

实际价值还不只是修掉的那几个 bug。更重要的是确认阴性——确认那 233 个没报错的 Story 是真的没问题。以前靠人肉点，靠的是「没看到报错就当没事」，Agent 这次做的是机械式的完整覆盖，把漏报的概率压到了零。

这件事对前端工程化的意义不只是省人力。CyberAgent 后来把这一套写进了内部的 AI Agent 开发规范，规定所有 Storybook 调试必须用 Chrome DevTools MCP 作为默认调试服务端，把「人肉过 Story」这个环节彻底踢出了流程。

Chrome DevTools MCP 本身的能力不止是读 console。它能让 Agent 操控网络请求、读 Page Performance 数据、读 Storage 和 Cookie、做 JS snippet 执行。等 Chrome DevTools for agents 的能力再丰富一些，下一步据他们说打算让 Agent 直接对着 Performance 面板跑 Core Web Vitals 分析。

如果你现在在管一个前端组件库或者设计系统，Storybook 跑的是人肉验收，不妨试试这个流程——一个 claude mcp add，省掉的是整个团队的重复人工。

GitHub: ChromeDevTools/chrome-devtools-mcp（51.4k stars，Apache-2.0）

案例来源：developer.chrome.com