试想这么一个案例：我想用 AI 帮我抓一个考题网站的真题。 Token 哗哗地烧。页面上几十个分页来回翻了，上下文窗口直接干到 60%。肉疼。
就为了抓题，费了老半天劲不说，关键是Token都没了。
这事儿其实挺荒谬的。 AI 够聪明了，但搭个浏览器让它干活， Token 消耗像个漏水的水龙头。我后来算了一下，简单页面一天能跑掉十几万 Token ，复杂点的前端框架——比如小红书创作者中心那种——嵌套好几层的 SPA ， Token 直接翻倍。钱包在滴血。
MCP 方案的问题：把整个网页塞进 AI 嘴里
说白了，现在主流的浏览器自动化方案（比如 Playwright MCP ）就是一招鲜：把网页的 DOM 结构整个打包塞进 AI 的上下文窗口。
你想让 AI 看看页面上有啥？行，整个 DOM 树发过来。想截图？好，一张 PNG 直接灌进上下文。
页面越复杂， Token 吃越多。一个中等复杂度的页面， DOM 几千个节点， Token 消耗轻松破万。说实话看着那个数字往上蹦，心态有点崩。
说实话，这跟让一个人把整本书背下来才能回答"第三段第三行写了啥"有什么区别？荒唐。但很长时间以来大家都这么干，因为没有更好的选择。烦不烦？
2026 年初，微软开源了一个新工具，叫 Playwright CLI 。这个东西一出来，整个局面就不一样了。
Playwright CLI ：按需加载，不要全量推送
核心思路就一句话：按需加载，而不是全量推送。
传统 MCP 方案， AI 说"帮我看看页面上有啥"， MCP 把整个 DOM 几千行全扔过来。 Playwright CLI 的做法不同——它只返回一段简洁的网页摘要，附带一个快照文件的本地路径。 AI 觉得需要细节了，再去读那个文件。截图也是，存到本地磁盘， AI 按需读取，而不是直接塞进上下文。
这个差别有多大？微软官方的基准测试数据：CLI 比 MCP 节省约 4 倍 Token。
4 倍。不是 10%，不是 20%，是 4 倍。这个差距说实话有点吓人。
我一开始看到这个数字，觉得是不是有点夸张。后来自己试了几天，信了。尤其是复杂页面，差距非常大——MCP 方案下一个小红书创作者中心的页面能吃掉几万 Token ， CLI 方案几千就搞定了。
GitHub 仓库： github.com/microsoft/p…
安装也简单，前提是装了 Node.js ：
npm install -g @playwright/mcp@latest
Chrome 浏览器也得有。装好以后，一条命令就能用：
playwright-cli open google.com --headed
--persistent
--headed 这个参数是用有头浏览器（能看到页面），不加的话默认无头模式在后台跑。调试阶段建议加上。
一个很关键的参数是--persistent ，它把 cookie 和登录状态写到磁盘里，下次执行直接用，不用重新登录。这个对自动化任务来说太重要了——你总不能每次都手动扫码登录吧。
Skill 的角色：教 AI 用一个它不认识的新工具
Playwright CLI 是 2026 年初才开源的。 AI 的训练数据里没有它的用法。你直接扔给 Claude 说"用 Playwright CLI 帮我抓评论"，它会一脸懵。
所以需要搭配 Skill 。
Skill 说白了就是一个 Markdown 说明文档，放在.claude/skills/或者.codex/skills/目录下。告诉 AI 这个工具怎么装、有哪些命令、参数怎么用、常见坑有哪些。
它不参与运行。不是代码，是知识文档。
这个定位很重要。 Skill 的本质是降低 AI 的试错成本——把别人踩过的坑写下来，让 AI 别再踩一遍。
某博主做了一个对比实验，数字特别说明问题：
第一次，让 AI 从零摸索怎么用 Playwright CLI 抓电商评论。磕磕绊绊，试错，报错，重试。上下文窗口消耗 41%。一次任务就用掉将近一半的上下文。离谱。
第二次，把第一次的执行经验沉淀成 Skill 。 AI 照着 Skill 做，同样的任务，上下文只消耗了 5%。
从 41%到 5%，将近 10 倍的效率提升。
三级效率阶梯：从烧 Token 到零成本
这个模型特别值得记住，实践一圈下来总结起来就是：
第一级： AI 自由探索。给 AI 一个复杂任务，让它自己摸索。它会试各种方案，踩各种坑， Token 消耗巨大。适合第一次做某个任务，没有先例可以参考。但这一步的体验真的很痛苦。
第二级： Skill 指导。把探索阶段的经验写成 Skill 。 AI 照着 Skill 的指引操作，不再重复踩坑。 Token 消耗降低 10 倍左右。
第三级：纯脚本。如果一个流程完全固定了——比如每次都是"打开商品页→翻评论→保存 CSV"——那就让 AI 把整个过程写成一个脚本。脚本运行时完全不需要 AI 参与， Token 消耗直接归零。
我之前做自媒体文章的自动发布时，走的就是这条路。先让 Claude 操作浏览器一步步验证每个平台的编辑器结构，截图验证，来回调试。 Token 消耗很高，过程也很折磨人。验证通过后，写成脚本，之后一行命令搞定，零 Token 。
扯远了，说回来。
这三个级别不是非此即彼的关系。实际操作中，大部分工作流处于第一级和第二级之间——有些步骤固定了可以写脚本，有些还需要 AI 的判断力。
几个实际踩坑
说点随便想到的。
每个网站的坑不一样。每个平台都是独立的深渊。
小红书的 HTTPS 页面拒绝从 HTTP localhost 加载图片，得自己写一个带 CORS 头的静态服务器绕过去。坑爹不？掘金用的 CodeMirror 编辑器异步加载，简单的 sleep(2000)根本不可靠，得轮询等 DOM 元素出现。烦死了。微信公众号最难——UEditor 套 iframe ， URL 带动态 token ，搞了半天靠浏览器原生复制粘贴比 JS 注入靠谱得多。
这说明一个问题：Skill 不能做成通用模板。每个目标页面都需要一份独立的适配，针对它的 DOM 结构和交互怪癖单独处理。
但好消息是，一旦适配完成，沉淀下来的 Skill 可以反复使用。第一次花两小时搞定，之后每次执行就是几十秒的事。
我不确定这算不算"一劳永逸"。也许"一劳"太绝对了，页面改版了 Skill 可能得跟着改。但比起每次手动操作，效率差距是量级的。差距大到你不想再回去了。
这套方案能干嘛
聊几个实际场景。
数据采集。电商评论、竞品价格、行业报告。以前手动复制粘贴一下午的数据， AI 几分钟搞定。但前提是你别踩坑——踩了坑一下午都搞不定。尤其是那种需要翻页、需要筛选条件的场景，手动操作烦得要死。
内容发布。像我之前做的，把 Markdown 文章自动发布到掘金、知乎、微信公众号。每个平台的编辑器都是独立的坑，但坑填完以后，以后就是一键操作。
自动化测试。自己写了个 Web App ，想测一测注册流程有没有 bug ？以前得手动点一遍，现在让 AI 用 Playwright CLI 自动跑测试用例。它自己打开浏览器，自己点注册按钮，自己填表单，自己判断结果对不对。
重复操作。填表、导出、数据录入。这些完全不需要 AI 的"智能"，写成脚本零 Token 就跑完了。纯纯的浪费人力去干的事。
说白了，浏览器能做的事，这套方案都能自动化。区别只在于第一步要花多少 Token 让 AI 学会怎么干。有时候那第一步真的贵得离谱。
一个趋势判断
CLI + Skill 正在替代 MCP ，成为 AI Agent 浏览器自动化的主流方案。这不是我一个人的感受——2026 年 Agent 社区里这个讨论越来越热。
核心逻辑很简单： MCP 把工具能力暴露给 AI ，但 Token 开销太大了。大到什么程度？复杂页面一天烧掉几十万 Token ，跟打水漂差不多。 CLI 把执行层面和 AI 推理层面解耦，按需加载， Token 效率高一个数量级。 Skill 负责教 AI 怎么用 CLI ，降低试错成本。
三者组合起来，就是现在能看到的最优解。
当然了，也许半年后又出个新东西把这套方案也干掉。技术迭代嘛，就是这么快。卷不动。但至少现在，如果你想让 AI 帮你操作浏览器干点正经事， Playwright CLI + Skill 是最务实的选择。
具体会怎样，我也说不准。但方向是对的——把 Token 花在"思考"上，而不是花在"搬运数据"上。
你觉得呢？
