夜雨聆风
昨天写 browser-use 的时候，我强调的是“浏览器 agent 不是许愿机，要把任务写成工单”。今天换一个角度，拆 Chrome DevTools MCP。它真正有意思的地方，不是让 AI 多一只会点网页的手，而是让 AI 多一条能验收网页结果的线。
以前很多网页自动化失败，是因为 AI 只是在猜：猜哪个按钮能点，猜提交有没有成功，猜页面有没有报错。DevTools 这类能力接进来以后，重点就变了：AI 不只看页面，还能看控制台、网络请求、DOM 状态和性能信号。
很多人一听浏览器自动化，就只关心“它能不能帮我打开网页、输入、点击”。这当然重要，但还不够。真实工作里，更麻烦的是点击之后发生了什么：按钮是不是被禁用，接口是不是 500，表单是不是没保存，页面是不是只弹了一个转瞬即逝的错误提示。
第一条 如果 AI 只能看页面表面，它很容易把“点过了”当成“做完了”。
第二条 如果 AI 能读 DevTools 信号，它就可以把“页面状态、控制台错误、网络请求、截图证据”一起交回来。
普通聊天机器人处理网页，最常见的是读文本、总结内容。浏览器 agent 更进一步，可以点按钮、填表单、切换筛选条件。但 Chrome DevTools MCP 这类工具补上的，是另一个常被忽略的维度：网页运行时到底发生了什么。
这对做自动化的人很关键。比如你让 AI 登录后台生成一张报表，页面最后停在报表页并不代表成功。你还要知道网络请求有没有失败，下载文件有没有生成，控制台有没有报错，页面数据是不是和预期一致。
适合场景 前端页面验收、后台表单巡检、运营工具检查、自动化脚本调试、低代码页面测试。它不只是给程序员用，任何需要反复检查网页流程的人都能用。
不适合场景 不要拿它做绕验证码、绕平台限制、批量骚扰、自动付款或高风险提交。能操作浏览器，不等于应该把判断权交出去。
很多人写提示词时会这样说：“帮我打开后台，把这条内容发布出去。”这句话太危险，因为它把动作和责任都丢给了 AI。更稳的写法，是把任务拆成入口、动作、证据和验收。
可以直接改成这类工单：
打开【指定后台页面】，检查【指定表单/列表】，只执行【查询、填写草稿、截图、导出】这些动作；每一步都记录页面状态、控制台错误和失败请求；遇到登录、验证码、付款、删除、发布按钮时停止，并把结果整理成检查清单。
关键变化 不要问“AI 能不能帮我点完”。要问“AI 点完以后，能不能证明这件事真的完成了”。
输出格式 建议固定成表格：步骤、页面状态、关键截图、网络请求结果、是否需要人工处理、下一步建议。
对普通人来说，Chrome DevTools MCP 不一定是拿来全自动做业务的。更现实的用法，是把它当成网页流程的检查员。你每天要打开后台看订单、看表单、看数据、看广告页、看活动页，它可以先跑一遍，把异常列出来。
例子一 你做一个报名页，让 AI 模拟填写，但最终不提交付款。它检查输入框、按钮状态、接口返回和错误提示，最后给你一份问题清单。
例子二 你维护一个内容后台，让 AI 每天巡检草稿列表、素材上传、预览页加载。它不替你发布，只告诉你哪里失败。
例子三 你做小团队工具，让 AI 在改版后跑一遍核心流程：登录、筛选、导出、预览。它把截图和失败请求都留给你复核。
网页自动化一旦接近真实账号，就一定会碰到边界：登录态、验证码、付款、删除、批量发送、客户隐私。这些地方不能靠 AI 临场判断。你要提前写清楚，哪些动作只能生成草稿，哪些动作必须停下来等人确认。
停止线一 出现验证码、二次验证、登录失效，停止并截图，不尝试绕过。
停止线二 涉及付款、删除、发布、群发、批量私信，只生成预案或草稿，不自动提交。
停止线三 涉及客户隐私、账号密码、订单明细，先脱敏，再决定是否交给自动化流程。
Chrome DevTools MCP 这类工具出现后，我反而更不建议大家追求“一句话全自动”。因为越接近真实浏览器，越接近真实账号和真实责任。
普通人更值得抄的，是这条验收线：让 AI 先看真实页面、真实报错、真实请求、真实截图，再把结果交回来。机器负责巡检、记录、整理；人负责判断、确认、发布。
如果你现在想试，不要从“让 AI 管一个业务”开始。先选一个固定网页流程，让它每天帮你检查一次，输出异常清单。能稳定省下 20 分钟，已经比很多炫技演示更有价值。
资料地址 Chrome DevTools MCP 项目：https://github.com/ChromeDevTools/chrome-devtools-mcp；Chrome for Developers 的 AI agents 文档也可以一起看。