CLI+Skill 正在替代 MCP：浏览器 AI 自动化的新范式

最近看到技术爬爬虾在 B 站发了一期视频《告别一切重复枯燥任务，CLI+Skill 搭建浏览器 AI 自动化框架》，讲的是用 Playwright CLI 配合 Skill 文档来做浏览器自动化，替代传统的 Playwright MCP 方案。正好我刚做完四个自媒体平台的自动化发布，走的几乎是同一条路------先让 AI 操作浏览器验证流程，再沉淀为脚本。看完视频觉得有共鸣，也有一些不同的体会。

Playwright CLI 到底是什么

2026 年初微软开源了 Playwright CLI，一个命令行版的浏览器自动化工具。跟传统的 Playwright MCP 比，核心区别就一句话：按需加载，而不是全量推送。

MCP 的做法是把页面 DOM 和截图一股脑塞进 AI 的上下文窗口------页面越复杂，token 吃得越多。CLI 的做法不同：它只返回一段简洁的页面摘要和一个快照文件路径，AI 觉得需要看细节的时候再去读那个文件。截图也一样，存到本地磁盘而不是直接灌进上下文。

官方基准测试说 CLI 比 MCP 省 4 倍 token。这个数字在简单页面上可能感知不明显，但页面一复杂（比如小红书创作者中心那种前端框架嵌套好几层的），差距就非常大了。

Skill 的角色：教 AI 用新工具

Playwright CLI 太新了，AI 的训练数据里没有它的用法，直接让 AI 用会一脸懵。所以需要搭配 Skill------本质上就是一份 Markdown 说明文档，放在 .claude/skills/ 或 .codex/skills/ 目录下，告诉 AI 这个工具怎么装、怎么调、有哪些参数。

视频里把 Skill 定位为"知识文档"而不是代码，这个说法很准确。Skill 不参与运行时执行，它的作用纯粹是降低 AI 的试错成本------把别人踩过的坑写下来，让 AI 别再踩一遍。

三级效率阶梯：41% → 5% → 0

视频提出了一个三级优化模型，用电商评论抓取做演示：

AI 自由探索：让 AI 从零开始摸索，磕磕绊绊完成任务，消耗 41% 上下文窗口
Skill 指导：把踩坑经验固化为 Skill，AI 照着做，只消耗 5% 上下文------约 10 倍提升
纯脚本：流程完全固定后让 AI 写成脚本，运行时 0 token

这个模型我拿自己的实践验证过，数字虽然不完全一样，但趋势对得上。

我的实践：四个平台的发布自动化

我做自媒体发布自动化时，走的路径几乎完美对应这三级：

Level 1------定义流程 ：用 /post 命令描述"把这篇博客发到小红书/掘金/知乎/微信公众号"的步骤。

Level 2------AI 现场执行：让 Claude 通过 chrome 浏览器扩展操作浏览器，逐步验证每个平台的编辑器结构、上传方式、填写逻辑。这一步 token 消耗确实很高------每次截图都是一张图片进上下文，图片 token 比文本贵 5-10 倍，8 张截图下来已经是大量消耗。

Level 3------沉淀为脚本 ：验证通过后，把每个平台的操作写成 Playwright 脚本（post-xhs.mjs、post-zhihu.mjs 等），之后 Claude 只需要跑 node scripts/post-all.mjs 一行命令，几乎零 token。

级别	做法	token 消耗
Level 2	Claude 操作浏览器	高（截图 + DOM 交互）
Level 3	`node scripts/post-xhs.mjs`	≈ 0

视频没讲到的：每个平台都是独立的坑

视频用了三个案例演示（电商评论、发推文、Web 测试），但这三个场景相对"干净"------页面结构比较规整，流程线性。我实际做四个中国平台的自动化时，发现每个编辑器的坑完全不同，没有银弹：

小红书：HTTPS 页面拒绝从 HTTP localhost 加载图片，得自己写一个带 CORS 头的静态服务器绕过去
掘金：CodeMirror 编辑器异步加载，简单的 sleep(2000) 不可靠，要轮询等待 DOM 元素
知乎：富文本编辑器，Markdown 得先转 HTML 再注入。登录后跳转会销毁 JS 执行上下文
微信公众号：最难------UEditor + iframe，URL 带动态 token，最终靠浏览器原生复制粘贴比 JS 注入更可靠

这说明 Skill 不能做成通用模板然后所有场景复用。每个目标页面都需要一份独立的 Skill（或脚本），针对它的 DOM 结构和交互怪癖单独适配。视频里暗示"一个 Skill 就能复用相似任务"，实际操作中没这么理想。

另一个差异：我用的不是 Playwright CLI

值得一提的是，我的实践路径虽然结论相似，但中间走了一条不同的路。验证阶段我用的是 claude-in-chrome（Chrome 浏览器扩展），不是 Playwright CLI。两者的定位不太一样：

Playwright CLI：AI 通过命令行控制一个新开的浏览器实例，按需读取 DOM 摘要
claude-in-chrome：AI 直接操作用户当前打开的 Chrome 浏览器，通过 MCP 协议交互

claude-in-chrome 的好处是可以直接复用用户的登录态（不需要 --save-persistent），缺点是截图和 DOM 全量进上下文，token 消耗更高。这也是为什么我在验证完流程后立刻切到了 Playwright 脚本------浏览器自动化是验证手段，不是生产方案。

对"10 倍效率提升"的看法

视频的 10 倍提升（41% → 5%）来自单一案例（电商评论抓取），这个数字有参考价值但不能直接套用。我的体感是：

简单线性流程（开页面 → 填内容 → 提交）：Skill 提升确实很大，因为步骤固定，AI 按 Skill 走就行
复杂交互流程（动态加载、iframe 嵌套、异步渲染）：Skill 能减少试错，但 AI 仍然需要大量 DOM 探测来处理运行时变化，提升没那么夸张
跨平台复用：几乎为零。小红书的 Skill 对掘金毫无用处

真正的效率跃迁不在 Level 1 → Level 2，而在 Level 2 → Level 3------直接跳到脚本。如果一个流程足够固定，与其花时间写 Skill 优化 AI 的执行效率，不如直接让 AI 写成脚本一步到位。

总结和行动

视频的核心观点------CLI + Skill 替代 MCP 是趋势------我认同。按需加载确实比全量推送更合理，尤其在长流程和复杂页面上。

但我觉得更值得关注的不是 CLI vs MCP 的工具之争，而是三级固化这个思维模型本身：

遇到新任务，先让 AI 自由探索一遍，哪怕费 token
跑通了就提炼经验，能写 Skill 就写 Skill
流程一旦确定，立刻固化为脚本，把 AI 彻底踢出运行时

这个模式不限于浏览器自动化。我做小红书卡片截图、做博客发布、做知识库编译，全都是这个路子------先手动或让 AI 摸索，验证可行后立刻脚本化。

下一步打算试一下 Playwright CLI 本身，看看在验证阶段（Level 2）能不能比 claude-in-chrome 省更多 token。如果按需加载的体验确实好，可能以后验证新平台的自动化都走 CLI 路线。