企业官网建设流程全解析

你有没有遇到过这种情况：让AI帮你查一份资料，它信誓旦旦地给出结论，你顺着它引用的网页链接点进去一看，内容跟它说的完全是两回事。更气人的是，你让它“自己去看那个页面”，它只会回一句“我无法直接访问该网页”。这其实不是AI变笨了，而是绝大多数AI根本没有真正“操作”过浏览器——它读到的网页信息，要么来自训练数据，要么来自搜索引擎返回的摘要，而不是它亲眼看过的实时页面。

今天这篇实战课要聊的结论很明确：借助 Playwright MCP 这套方案，你可以让 AI 真正做到打开网页、点击按钮、填写表单、翻页、截图、执行脚本——像人一样去“用”浏览器，而不是停留在“讨论浏览器”的层面。这套方案在 GitHub 上有非常活跃的官方仓库，文档、示例和版本迭代都跟得很快。这篇内容适合三种人：被重复网页操作折磨的运营和数据分析人员、想改造自动化测试流程的开发测试工程师、以及想把 AI 从“嘴炮选手”变成“实操选手”的工具爱好者。

1. 从“让AI读网页”到“让AI用浏览器”：MCP补上了什么

1.1 以往AI获取网页信息的三种方式，各有各的硬伤

在 Playwright MCP 出现之前，想让 AI 接触网页内容，无非三条路。

第一种是“纯文本投喂”：把网页正文复制粘贴给 AI，让它基于这段文本做总结。这种方式的问题显而易见——网页里大量有价值的信息恰恰不在正文里，而在按钮状态、表单交互、异步加载的数据、需要登录才能看到的模块里。你把页面源码扔给 AI，它看到的是一堆 HTML 标签和转义字符，理解效率极低。

第二种是“搜索引擎摘要”：主流对话 AI 的联网搜索能力确实能返回一些页面摘要，但摘要不是你打开页面后看到的东西，而是搜索引擎预先抽出来的几句文字。对于单页应用、动态渲染网站、需要点击“加载更多”才能出现的内容，搜索引擎爬虫也未必能抓全，传给 AI 的信息自然残缺。

第三种是“写自动化脚本代执行”：也就是用 Playwright、Puppeteer 这类工具写一段脚本，由程序控制浏览器跑完流程后再把结果喂给 AI。这是目前开发圈子里最常见的玩法，但它有一个致命前提——脚本是人写的。页面一改版，脚本就要跟着改；你让 AI 去处理一个你没提前预料到的流程，脚本直接卡死。

这三种方式本质上都是“人先理解、人先编码、AI 只做信息加工”。而 Playwright MCP 的思路完全不同：它把浏览器操作本身封装成了 AI 可以直接调用的“工具”，让 AI 不再需要人类替它把步骤写成代码，而是自己观察页面、自己决定下一步干什么。

1.2 MCP 到底是什么：一个连接 AI 和外部世界的标准插座

MCP 的全称是 Model Context Protocol，模型上下文协议。你可以把它理解成一个标准化的“USB 接口”：AI 是主机，浏览器、文件系统、数据库、各种外部服务都是外设，MCP 协议规定了主机和外设之间怎么握手、怎么传输指令、怎么返回结果。

在 MCP 的架构里有两个角色。一个是 MCP 客户端（Host/Client），也就是 AI 那一侧。另一个是 MCP 服务器（Server），就是真正干活的外设。Playwright 官方维护了一个名为 @playwright/mcp 的服务器实现，它启动后会拉起一个真实的浏览器实例，然后把浏览器能力拆分成十几个可以单独调用的工具。AI 通过客户端向服务器发指令，比如“打开这个网址”“点击这个元素”“输入这段文字”，服务器就在真实浏览器里执行，再把执行结果（页面快照、截图、控制台日志）回传给 AI。

这个过程里最微妙的一点是：AI 全程是在“自然语言理解 + 工具决策”的层面工作，它不需要手写 CSS 选择器、不需要记页面 DOM 结构。它只需要告诉服务器“我想点那个登录按钮”，服务器会自动分析当前的页面可访问性快照，定位到按钮并触发点击。这套链路把 AI 从“只会分析文本”升级成了“能操作真实环境”。

1.3 为什么我的实战选择是 Playwright，而不是其他自动化方案

市面上能做浏览器自动化的框架不少，但把官方 MCP 支持做进主流程的，Playwright 是走得很靠前的一个。它有三个特点让我在实际项目里越用越顺手。

第一是自动等待机制。很多自动化脚本挂就挂在“元素还没渲染出来就去找它”，Playwright 有一套内建的智能等待逻辑，元素不可见、不稳定的情况下它会自动重试，到了 MCP 层这个特性也被保留了下来。AI 的每一步点击都天然带上了“等元素可交互之后再操作”的兜底，踩空、点错的概率比裸写脚本低很多。

第二是多浏览器支持。Chromium、Firefox、WebKit 三套内核它都支持，拿来做跨浏览器验证很省事。特别是很多内部系统和老旧后台只兼容某一种浏览器，Playwright 可以直接指定浏览器启动，不必另起炉灶。

第三是生态和文档完备。GitHub 仓库里从安装命令、配置文件、API 参考到常见问题都写得很细，遇到报错基本都能搜到解决方案，这一点在踩坑的时候能救命。

所以，如果你也想让 AI 真的会用浏览器，我的建议很直接：从 Playwright MCP 入手，先把官方仓库拉下来跑通，再考虑要不要定制自己的工具集。

2. 一套能“动手”的工具清单：Playwright MCP 到底暴露了什么

2.1 核心工具一览：AI 手里真正握着的“技能”

MCP 服务器暴露给 AI 的工具不是凭空定义的，每一类都对应一个真实的浏览器操作。我把常用的几类整理成了一张表，方便你理解 AI 到底能干什么。

有意思的是，这套工具并没有为 AI 单独发明什么神秘能力，它就是把 Playwright 原本通过代码提供的 API 能力，逐个映射成了“AI 可以按需调用”的命名函数。AI 对浏览器能力的理解，本质上就是它对这十几个工具的理解：知道什么时候该截图、什么时候该获取快照、什么时候要执行脚本。

2.2 快照机制：AI 判断“下一步点哪里”的关键

AI 在浏览器里不是瞎点一气的。它每操作完一步，都会调用一次“获取快照”类工具，拿回一串结构化的可访问性树——简单说，就是当前页面里所有可见/可交互元素的语义描述，比如“按钮，文本为‘登录’，编号 12”“输入框，标题为‘用户名’，编号 8”。

这个机制非常重要。因为 AI 不像人一样有视觉记忆，它必须靠“元素编号 + 语义描述”来锚定操作目标。所以你会看到，AI 在执行点击动作时，传递的参数往往不是 CSS 选择器，而是一个元素编号。这让它对页面结构理解的门槛大幅降低——不需要懂前端也能精准操作。

你可以在实际使用中做个小实验：让 AI 打开一个复杂后台页面，然后问它“你现在能看到哪些可以交互的区域”，它会非常详尽地罗列出按钮、输入框、链接和它们的编号。从这个输出你就能直观感受到，AI 眼中的网页已经变成了一个“带编号的交互地图”。

2.3 和人工操作对比：各有各的擅长区

我给同事做演示时常说一句话：AI 操作浏览器，不是模仿人类的手，而是模仿人类的“判断”。它的优势不在速度和精度——人工点击 0.1 秒，AI 每一步要考虑工具调用、等待快照回传，整体节奏慢得多。但它的核心优势是：它可以按你的要求，一遍又一遍稳定地执行同样复杂的判断链路。

比如你让实习生每天花二十分钟重复打开三个后台、分别下载报表再填到汇总表里，实习生干到第三天就会开始烦躁出错。但 AI 不会烦，它会老老实实地每一步都先确认页面状态，发现异常就停下来截图报告。这种“稳定的判断能力”，才是它被用于自动化流程的最大价值。

当然，它也有力所不及的地方——后面我会专门讲它翻车的事故现场。在没踩过坑之前，先别急着把全部流程都交给它。

3. 本地搭建一条“AI + 浏览器”产线：配置全流程

3.1 环境准备：哪些软件是必须的

先说基础要求。Playwright 官方 MCP 包是在 Node.js 生态里维护的，所以第一步是确保机器上有 Node.js 环境，建议用 18 及以上版本。你可以先在终端里跑一条检查命令，确认没有遗漏：

node -v npm -v

如果你主力语言是 Python，也可以走 Python 路线，但首推 Node 版本，因为新功能发布、Bug 修复都更及时。接下来是安装 Playwright 内核和 MCP 服务器包。这两步可以分开做，也可以像我一样一步步来：

npm install -g @playwright/mcp npx playwright install chromium

第一条命令装的是 MCP 服务器本体；第二条命令是下载浏览器内核。这里有个细节容易踩坑：npx playwright install chromium会把一个独立编译的 Chromium 下载到本地缓存目录，它和你系统里的 Chrome、Edge 互不影响。这样做的优点是环境干净、版本可控，缺点是下载时间取决于网络状况。

如果长时间下载失败，我的替代方案是直接复用系统已有的浏览器。只需要在启动 MCP 服务器时添加一个参数，让 Playwright 用你机器上已经装好的 Chrome：--browser chrome，后面的运行效果基本一致。你可以在实战中先默认下载 Chromium，实在不行再走这条捷径。

3.2 客户端配置：把 MCP 服务器“挂”到 AI 上

装好服务器以后，问题就变成了：你的 AI 客户端怎么找到它？目前主流的支持 MCP 的 AI 客户端和开发工具都提供了一套配置文件，格式大同小异，核心就是下面这段：

{ "mcpServers": { "playwright": { "command": "npx", "args": ["@playwright/mcp@latest"] } } }

这段配置的意思是：当 AI 客户端启动时，通过npx命令拉起@playwright/mcp这个 Node 包，并和它建立一个标准输入输出（stdio）通道。为什么要用 stdio 而不是 HTTP？因为本地场景下 stdio 最简单、最安全——服务器进程由客户端直接管理，数据不经过网络，也不存在鉴权问题。

配置保存并重启客户端之后，你可以在工具列表里确认 playwright 相关的工具已经加载。如果没有加载，优先检查三件事：第一，npx命令是否能在终端里正常执行；第二，@playwright/mcp是否安装成功；第三，工作目录是否有网络权限去实时解析 npm 包。这三步排查掉，90% 的连接问题都能解决。

3.3 启动参数里值得关注的几个开关

启动 MCP 服务器时，除了默认配置，还有几个参数是我在实战里反复用到的，这里提前列出来。

• --browser：指定用哪个浏览器，默认是 chromium，也可以指定 firefox、webkit 或系统里的 chrome。
• --headless：以无头模式运行。默认会弹出一个有界面的浏览器窗口，方便你实时观察 AI 的操作；需要跑无人值守任务时再开 headless。
• --user-data-dir：指定浏览器用户数据目录。这个参数特别重要——如果你希望保持登录态，比如维持某个后台的登录 Cookie，就得用它挂载一个固定的浏览器数据目录，否则 AI 每次启动都是全新会话，登录信息全部丢失。
• --device：模拟手机设备，可以用来验证移动端页面。

不要一上来就用 headless。第一次跑通流程时，我强烈建议你打开有头窗口，亲眼看一遍 AI 是怎么操作浏览器的。这一步能帮你建立对这套系统的直觉——什么情况下它动作麻利、什么情况下它犹豫不决、什么时候它明显“看漏了”，观察几次就心里有数了。

4. 让 AI 真正干活：三个任务从发出指令到结果落地

4.1 任务一：自动登录后台并填写周报

我第一个在身边跑通的场景是“让 AI 替我填周报”。模拟一下我当时下发的指令：

“打开后台地址，登录后进入周报页面，把这几条工作内容填进对应输入框，最后提交。”

AI 接到这条指令后的实际执行路径大致是：先调用导航工具打开后台登录页，获取快照找到用户名和密码输入框，逐个填写，点击登录按钮，等页面跳转后再获取快照定位周报菜单，点击进入，找到工作内容输入框，填入我提供的文本，最后点击提交按钮。

整个链路我没有给它任何 CSS 选择器，没有写任何一行脚本，它纯粹靠“每步操作后获取快照，根据页面状态决定下一步”完成了整条流程。第一次跑通的时候，浏览器窗口里弹出的提交成功提示，我的感受是“这东西是真能干活”。

但别高兴太早——这类流程对 AI 来说属于“简单线性任务”，真正到了生产场景你会发现，登录前往往有验证码、提交后有二次确认弹窗，这些我会在第 6 节的踩坑记录里展开。

4.2 任务二：跨页数据采集与结构化整理

比填表单更有实用价值的场景是数据采集。举个例子，你负责竞品监控，需要从某个公开列表页里抓取三页数据，每个产品提取名称、价格和上线时间，最后整理成表格。

AI 的应对方式是：打开列表页，先用快照确认每一页的卡片结构，然后调用脚本执行工具直接批量提取当前页的数据，再点击“下一页”按钮，重复同样的提取动作，直到收集完三页，最后按你的要求输出成 Markdown 表格。

这个场景让我最惊喜的不是它能提取数据，而是它懂得“需要翻页”。它看到快照里“下一页”按钮信息，就能自动推断出翻页并重复执行。放到传统的自动化脚本里，这一步你不仅要写翻页逻辑，还得做页码边框判断；但对 AI 来说，“看到下一页按钮就有理由点它”几乎是一种不需要教的常识。

唯一要注意的是频率控制：如果目标站点有严格的反爬机制，AI 连续快速点击翻页很可能触发风控，所以数据抓取任务我一般会额外叮嘱 AI“每翻一页停留两秒”，用自然语言约束操作节奏比写代码设置延时方便得多。

4.3 任务三：模拟用户走一遍冒烟测试流程

最后一个场景是给测试团队看的——让 AI 当“智能冒烟测试员”。我给它的指令是：“模拟一个真实用户，从商城首页开始，搜索关键词，进入商品详情页，加入购物车，完成下单，过程中每一步都用截图记录页面状态，如果发现报错或异常就停下来分析原因。”

这条指令的任务复杂度比前两个高不少。AI 需要连续切换多个页面，每一步之后还要调用截图工具给自己留“证据”。在执行过程中它做了很多脚本测试人员非常熟悉的动作：检查结算页金额是否和商品页一致、看下单后是否有订单号回显、核对页面是否有 JS 报错。这些“检查点”没有写在任何脚本里，而是它根据对业务的理解主动去验证的。

这次跑完我对它的价值判断更清晰了：它不能取代专业的自动化测试框架，但非常适合做探索式冒烟测试。当你懒得写一整套断言和选择器时，把你的业务检查点用自然语言描述给它，它就会真的去检查并回报异常，这个能力在传统工具链里是稀缺的。

5. AI 的“观察-决策-执行”循环：tool calling 的运行逻辑

5.1 一个循环包含四个阶段

看外部表现，你只会觉得 AI“会用浏览器了”，但搞明白背后是怎么转的，对后续调优非常重要。MCP 场景下，AI 操作浏览器不是一次性调用，而是一个由“观察-决策-执行-反馈”组成的闭环。

观察阶段：AI 调用快照类工具，获取当前页面的可访问性树结构。决策阶段：AI 结合原始用户指令和当前页面状态，决定调用哪一个工具，并给出相应参数。执行阶段：MCP 服务器在真实浏览器里执行这个操作。反馈阶段：执行完成后，页面变化、新快照、截图、控制台信息一起回传给 AI，然后进入下一轮观察。

你可以把一个复杂任务想象成无数个这样的小循环：点一下、看一下、再点一下、再看一下。这个过程和人类实际上网时的思维方式没有本质区别，只不过人类靠眼睛看，AI 靠快照和截图看。

5.2 为什么“按需获取快照”比“一次性灌入全文”更聪明

早期做网页 AI Agent 的人喜欢走另一条路：一次性把页面的完整 HTML 或者渲染后的文本全部塞给 AI，让它自己找关键信息。但实践下来发现这条路很快就走不通了——一个大型后台页面渲染完的 DOM 树可能有几万行，加上 CSS 类名、内联样式、治理属性，token 消耗巨大，AI 也容易抓不住重点。

MCP 的快照机制聪明在“按需”：AI 只需要知道当前页面上有哪些可交互元素、它们的语义标签是什么，这个数据量比完整 DOM 小了好几个数量级，而且都是 AI 决策真正需要的。遇到特别复杂、需要看视觉布局的场景，再补一次截图调用。这种“先取结构、再取视觉”的思路极大节省了上下文空间，让 AI 在执行长任务时不容易因为上下文耗尽而断片。

5.3 别忘了它也会“读图”：截图能力不止是为了给人看

如果你的 AI 客户端本身就支持视觉理解（也就是能读图），截图的作用会被放大。AI 不再只依赖结构化的快照，还能直接“看”页面长什么样——字体大小是否合适、元素是否错位、弹窗遮没遮挡关键按钮，这些视觉信息在纯结构快照里是体现不出来的。

我在验证页面样式是否符合预期时，通常会直接对 AI 说“截个全页面图，检查一下这个区块的间距和文案有没有溢出”，它截完图后能给出相当准确的判断。不过要提醒一下：截图视觉理解依赖底层模型能力，不同模型的判断精度差异比较大，真到像素级视觉验收的场合，还是建议用专门的测试工具兜底。

5.4 “以为点了但实际没点”的幻觉时刻从哪来

讲了这么多优点，必须说一个反面案例。有一次我让 AI 点击某个弹窗里的“确认”按钮，它返回“已经完成点击”，但下一页面的快照告诉我弹窗还开着，根本没有跳转。排查后我发现，它错误地拿弹窗出现之前的旧快照里的元素编号去点击——快照过期了。弹窗打开后按钮的实际位置、编号都变了，它还在用旧的映射关系，自然点了一个“不存在的位置”。

这说明 AI 不是万无一失的，它也会基于过时信息做出错误判断。应对方案是两条：一是尽量让 AI 在每一步关键操作前重新获取快照，不要复用太久之前的元素编号；二是在关键动作后增加一个状态校验指令，比如“提交后确认页面是否出现成功提示，如果没有就截图并说明”。给 AI 加校验环节，就像给流程加上 check point，安全系数高很多。

6. 翻车现场：我在实战中踩过的坑与修复方案

6.1 登录态总是丢，每次都要重新登录

现象：AI 每次启动浏览器都像第一天上班，完全“失忆”，登录信息全部归零。对于需要长期登录的内部系统，这会导致任务每一步都在和登录页纠缠，烦不胜烦。

根因：默认情况下，MCP 启动浏览器用的是临时用户数据目录，关闭进程时所有 Cookie、Session 都会清空。人用浏览器不会每次丢登录态，是因为浏览器把用户数据持久化到了磁盘，而 AI 默认没做这件事。

修复：在 MCP 配置参数里指定一个固定的--user-data-dir路径，比如--user-data-dir=/data/playwright-profile。这样浏览器会把 Cookie 写入这个目录，下次启动时自动恢复。实测下来，只要指定了这个参数，AI 第二次启动就能直接进入已登录状态，省掉一整段登录流程。

6.2 点击按钮时报错“元素列表里没有这个东西”

现象：AI 想点击某个按钮，但获取到的快照元素列表里根本没有这个按钮的编号，于是报错停止。

根因：大多数时候是页面还没来得及把按钮渲染出来。现代前端框架大量使用异步加载，按钮往往在某个接口返回后才出现。AI 拿到快照的那一瞬间，按钮还不存在。

修复：用自然语言引导 AI 先等待再重试。我通常在指令里会加一句“如果页面没有完全加载，就等两秒再重新获取快照”。你也可以在配置里调大默认超时时间，给 AI 更多耐心。这不算什么高级技巧，但实测下来非常管用。

6.3 弹窗和遮罩层挡住关键元素

现象：AI 明明定位到了元素的编号，点击却返回“元素被拦截”之类的结果。我亲眼看过一次：页面上弹了一个调查问卷遮罩，AI 想点的“确认下单”按钮在 DOM 里存在，但视觉上被遮罩盖住了，点击事件根本没落到按钮上。

根因：快照反映的是元素“存在”，而点击判断的是元素“是否真正可交互”。遮罩层没有可访问性信息，但物理上挡住了一切点击。

修复：让 AI 先处理弹窗。实操里我会在任务开始前给一条通用规则：“如果页面出现弹窗或遮罩，先尝试关闭它再继续。”AI 会主动查找关闭按钮并点击，实在找不到时我会让它执行一段脚本强制移除遮罩层。这个兜底方法虽然粗暴，但有效。

6.4 长任务中途上下文爆炸，越往后越恍神

现象：一个包含十几步操作的长任务，跑到后面 AI 开始“犯迷糊”，有时候会用错误的参数去调用工具，有时候直接不响应。

根因：每一步操作都要消费一定量的 token，快照和截图会快速塞满上下文窗口。上下文太长后，模型对最早期指令的注意力会被稀释，容易出现“忘事儿”。

修复：把长任务拆成短任务，每段只干一件具体的事，运行完一段就整理结果，下段重新开始。比如“先整理出所有商品数据，保存成文本，再对文本做分类汇总”，而不是要求它一口气从抓取跑到汇总。另外，尽量少在中间环节大量截图，截图是 token 消耗大户，能用快照解决的就别截图。

6.5 内嵌iframe里的内容“看不见”

现象：有些系统把功能模块嵌在 iframe 里，比如老旧的报表系统、第三方支付页面。AI 获取快照时只能看到主页面结构，iframe 里的按钮和输入框完全不在列表里。

根因：可访问性快照默认只覆盖当前浏览上下文，iframe 相当于另一份独立的文档，需要切换进去才能看到。

修复：这种情况靠对话让 AI 自己处理比较费劲，我更建议用脚本执行工具做兜底，直接写一段 JavaScript 定位 iframe 里的元素并触发操作。这不违背“让 AI 干活”的初衷——把 AI 不擅长的脏活交给脚本，把判断和流程交给 AI，本来就是最务实的组合。

7. 能力边界与安全护栏：哪些事别急着让 AI 干

7.1 先想清楚：AI 操作浏览器，权限等于你的权限

这是最需要警惕的一点。MCP 服务器启动的浏览器就是普通浏览器，它打开的页面能访问什么，全凭登录用户的权限决定。如果你的浏览器已经登录了某个管理后台，AI 就在以这个管理员的身份执行操作——它能查多少数据、能改多少配置，完全由你的账号权限决定，AI 自己没有任何“额外特权”，也没有天然的安全意识。

所以我的经验是：给 AI 用的浏览器环境要“最小化授权”。跑敏感操作时，不要用你有全量权限的主账号，单独开一个只具备必要权限的账号；用独立的--user-data-dir，不要共享日常浏览器配置；如果条件允许，放在容器或虚拟机的隔离环境里跑，从物理层面把关。

7.2 MCP 能力裁剪：别把所有工具都暴露给 AI

MCP 配置支持对工具集进行裁剪，也就是把不必要的工具从 AI 可见列表里移除。比如一个只需要“读取数据并汇总”的任务，根本不需要把“执行脚本”“文件写入”这类危险能力放给它。少一个工具，就少一分误操作的风险。

我看到不少团队的实践是：默认把所有工具都挂上去，遇到问题再收紧。我更推荐反着来——先只给最小必要工具集，任务确实需要再加。工具管理的关键不是“功能越多越好”，而是“够用且可控”。对 AI 这种注定会有幻觉的系统，减少暴露面就是减少出错机会。

7.3 不适合上 AI 的场景清单

基于我自己的实测，下面这几类场景建议谨慎使用甚至不要用。

• 付款、转账、发送正式邮件等不可逆操作：AI 一旦点错，后果是真实的，而且不好挽回。至少要在流程中加入人工确认环节。
• 对精确度要求到像素级的 UI 验收：AI 的视觉判断距离机器视觉算法还有差距，截图看个大概可以，像素级比对还是交给专门工具。
• 需要长期保持登录会话的定时任务：除非你已经配置好 user-data-dir 并验证过登录恢复机制，否则半夜跑挂了一个认证过期问题，第二天早上才发现，就不值得了。
• 涉及敏感个人数据的批量操作：一定要确认日志里会不会泄露数据内容，避免在无审计的环境里让 AI 处理大范围敏感数据。

7.4 给 AI 定“任务边界”，权力就收住了

技术护栏只是一部分，另一部分靠指令约束。我通常在启动任何自动任务之前，会把边界写成明确规则告诉 AI：“你只做这三件事，碰到其它弹窗一律截图并停下来问我”“不要点击任何带删除、清空字样的按钮”“如果页面出现异常提示，停止执行并汇报”。不要让 AI 拥有“自由发挥”的空间，把它当作一个能力很强但需要明确边界吩咐的实习生，效率和安全都能兼顾。

这听起来像废话，但实际项目里 80% 的 AI 操作事故，根因都不是 AI 能力不够，而是人类没有说清楚边界就跑路去摸鱼了。只要你保持“先小范围试验，再扩大授权”的原则，AI 操作浏览器这件事就会是增收工具，而不是事故源头。

最后说一点个人体会吧。把浏览器交给 AI 不等于把一切交给 AI，MCP 解决的是“怎么让 AI 接触到真实网页”的问题，而真正决定这项工具价值的，是你在哪个流程里用它、边界怎么画、异常怎么兜底。我自己的经验顺序是：先拿一个低风险、重复度高的任务跑通全流程，再逐步增加复杂度。跑通一次之后你会发现，“AI 会用浏览器”这句话，从概念变成了每天实实在在帮你省时间的工具。