Playwright MCP/Skills/Dev Browser：AI自动化测试的坑我全踩过
询问ChatGPT
点击关注上方公众号，发现更多精彩内容等你来发现
大家好,我是靈吾靈,专注于AI技术前沿分享,用最接地气的话讲最前沿的科技是我的专长,让每个人都能玩转AI是我的初心~
前言
为了减轻测试人员和前端人员的自动化测试的重复性工作，我一直在寻找一个可以用的方案。
我是从Playwright MCP开始入坑的，陆陆续续玩过以下几种方案：
Playwright MCP: @executeautomation/playwright-mcp-server(这类 mcp 有很多类似名字，我主要是用这个)Google Chrome DevTools MCP：https://github.com/ChromeDevTools/chrome-devtools-mcp Cursor 中的内置浏览器 @Browser 功能 Google Antigrvity 的 Antigravity Browser Control浏览器插件Playwright Skill
实际效果，差强人意，基本跑不通，玩玩可以，但是很难用于实际项目。
我之前也写过类似的实战文章，有兴趣的可以过去翻翻，
写作不易，如果小伙伴们都看到了这里，请点个
赞和在看，分享给更多的朋友；为确保您能收到每一篇文章，点个关注并在主页右上角设置星标。
我们的测试同事在使用Playwright MCP过程中遇到了以下问题：
如果在 Trae这种编辑器上用Playwright MCP话，经常会容易出现：模型思考次数已达上限，请输入"继续"后获得更多结果 。执行就被终止了，连个简单的用例都无法正常执行
如果在 Claude Code + GLM-4.7的配合场景下执行相同的用例，会出现：API Error: The model has reached its context window limit.
大家可以深品这句话：AI 操控浏览器最大的痛点是什么？
又慢！又贵！又笨！
下面我来详细分析一下，为啥出现以上的痛点，我们又应该如何去避免出现以上问题？
Playwright MCP的工作原理
众所周知，playwright-mcp是让AI控制浏览器的神器。
微软官方出品，GitHub上火得一塌糊涂。
经过测试小伙伴们用了一段时间，发现两个问题：
聊着聊着，Claude就弹出提示「上下文快满了！」，明明就聊了几次而已
看似灵活，但也只是看一眼，想一下，动一下，一步一卡，在反复装 playwright 环境，或者在反复写 playwright 脚本，不断陷入调用的循环
为了帮他们也是帮我自己想明白这个工作原理，或者深入研究这个 MCP 的执行过程，找到解决问题的办法。后来我研究终于明白了。
问题一：MCP 工具的设计问题
大家先看看这个执行用例的过程时序图：
1. 工具返回信息质量不足
问题表现：执行失败后需要截图 + LLM重新分析 根本原因： 工具返回的错误信息不够结构化和精确 LLM截图分析：这里考验的是模型的多模态能力，国外的 Gemini、Claude、GPT-5.x 三大收费模型，多模态能力最强，效果最好，国内的常用平替方案 GLM-4.7/MiniMax 2.1 之类的模型都没有多模态的能力， 豆包模型有，但是效果也是时好时坏。导致了如果用国内模型，经常执行不下去，如果用国外模型，这个价格贵得离谱，也不是百分百一次就能成功的，一旦调用不成功，智能体都用调用截图分析，不断循环
2. 缺乏自动错误恢复机制
问题表现：每次失败都要回到LLM重新规划整个流程 根本原因： MCP工具不具备自我修正能力
3. 状态管理缺失
问题表现：循环流程混乱，难以追踪执行历史和上下文 根本原因：无状态设计，每次调用都是孤立的
4. 工具与LLM协作成本过高
问题表现：需要多次循环（截图 → 分析 → 重新规划 → 再执行） 根本原因：工具不理解"业务意图"，大模型不理解"技术细节"
问题二：Playwright MCP的 token 占用问题
我们都知道大模型都会有「脑容量」（上下文内容）。
一句话理解：上下文 = AI 的"短期记忆工作台"
就像你和朋友聊天，你们需要记住之前说过的话，才能继续对话。AI 也是一样，它需要记住之前的对话内容，才能理解你现在说什么。
你和大模型聊天、发代码、看截图，都在消耗这个容量。用完了，对话就中断
而Playwright MCP一共有32 个工具函数，每个工具的完整 JSON 定义（包括工具名称、描述、参数结构等）。
按工具复杂度分类估算：
光是让Claude Code或者 GLM-4.7记住这些功能定义，就要吃掉13,600 Tokens。
Claude Code Sonnet 4.5/GLM-4.7/MiniMax M2.1 的上下文容量都是 200k Token
也就是说啥都还没有开始干活，8% 的脑容量就被占用了！
按照上面的时序图，多来几次，上下文就爆，AI 的上下文越多，智商越低，所以越到后期，调用失败的可能越大，就陷入了恶性循环。
就是这个原因导致了自动化测试就是一个空头支票，可远观而不可亵玩！
Playwright Skill 的工作原理
GitHub 地址：
https://github.com/lackeyjb/playwright-skill
今年 Skills 兴起后，这个词最近是已经火爆得很，声称所有现成的一切 MCP 工具都可以使用Skills重写一遍。
playwright-skill只有453行说明，相当于给Claude一个「目录索引」。
需要什么功能，再去翻具体那一页。
不用的功能，不占脑容量。
同样的功能，Skill版本能让你和Claude聊更久，做更多事。
工作原理：
从上面的工作原理图（简化版的，忽略环境配置）可以知道，playwright-skill比MCP工具更加稳定的，更加可靠的方案就是，它能根据用例生成固定的playwright测试脚本的代码。
一旦的你代码固定下来后，加上测试通过后，下次直接让大模型执行固定的代码即可，不需要在每次都输入测试用例，重新生成，这样就已经大大的减轻了大模型每次执行相同的用例时，可能会产生幻觉的次数。
同样的，直接执行代码，肯定比你每次问大模型，调用 mcp 工具得到的效果要准确很多。
但是它不是没有缺点的，我把我踩过的坑也告诉大家：
缺点：
1.复杂任务可能需要多轮对话
如果你的要求很复杂，Claude第一次可能做不对。
它会自己调整，但有时候需要你给点提示。
比如："登录按钮的文案是：登录，不是「确定」，调整你的代码"
这可能是你用例写得不够精准，也可能是 AI 根据通用的文本给你生成了代码
2.网页加载慢的时候容易出错
有些网站打开很慢。
Claude可能还没等页面加载完就去点了，然后报错， 然后又开始截图，然后分析错误，发现又没有错误，不断陷入了循环。
解决办法：
如果是这个问题，大家还是得看看日志，看看他的调用记录，如果不去监听日志，就放手不管，去喝咖啡的话，你永远不知道问题在哪里，
找到问题后，如果你能告诉它"等2秒再操作"或者"等页面完全加载再点"。它会重新生成延迟的代码，这样就不会错了。
3.偶尔会判断错误
有时候会把正常的当成错误。
比如页面跳转了，它以为是出问题了。
所以结果还是要自己看一眼。因此还是上面那一句，第一次没有固化流程之前，得要跟进测试过程，review 日志
4.第一次运行不容易成功
根据我的多次实践，第一次生成的代码运行不太容易成功，主要原因我可以归纳为两点：
生成代码的质量取决于模型的强弱，用的模型越好，第一次执行成功的可能越大。 测试用例的精准度，如果你的测试用例一般，那么生成的代码质量也不会好，这个时候就要反复调教，多轮对话。消耗的时间精力是比 Playwright MCP要多的。
总结
总结下来，技术在发展，Playwright Skill的生成质量，可拓展性、可迭代性、稳定性、执行速度、上下文容量等各个方面是要比Playwright MCP好太多了。
它更适合测试人员从功能测试 转变成自动化测试能力转变的的一个技能包。
Dev Browser的工作原理
GitHub 地址：https://github.com/SawyerHood/dev-browser
上面已经说到了 MCP 到 skills 的发展过程。
在以往的文章中：「插件市场终于来了！Claude Code插件生态已成熟，直接拿来就用」
我曾经说过：Claude Code 插件系统的推出，标志着这款 AI 编程工具正式迈入「高度可定制化」的新阶段。也意味着Anthropic在围绕着Claude Code核心能力打造可定制化的工作流模式。
所以Dev Browser就是这么一套关于自动化测试的一个定制化工作流程的插件
技术原理：
1.基于 A11y Tree 的元素定位
不同于 Playwright 的选择器（CSS/XPath） dev-browser 使用 UID 映射可访问性树 更稳定、更符合用户视角
2.Chrome DevTools Protocol (CDP)
直接与浏览器 DevTools 通信 无需启动独立浏览器实例，可以附加到已有的浏览器 可以选择独立启动浏览器
3.实时交互模式
Playwright：脚本执行（一次性） dev-browser：持续连接（可反复操作） 更适合调试和探索式测试
4.丰富的调试信息
网络请求/响应 控制台日志 性能指标 页面快照
与其他自动化工具相比
因为它实现了架构层面降维打击。
完成同样的复杂任务，Playwright Skill 跑了 8 分 07 秒，Dev Browser 只要 3 分 53 秒，成本仅需 0.88 美元。
| Dev Browser |
安装
在 cluade code 命令行里面执行：
/plugin marketplace add sawyerhood/dev-browser
/plugin install dev-browser@sawyerhood/dev-browser
如果你的 ssh 执行不成功，你可以https 地址
/plugin marketplace add https://github.com/SawyerHood/dev-browser.git
/plugin install dev-browser@sawyerhood/dev-browser
安装成功之后，成功的截图
安装后记得重启 Claude Code。
实战过程
提示语：
使用 dev-browser skills 打开链接http://localhost:3000/#/login,登录账号:admin, 密码:,xxx 机构选择总院, 登录成功后,执行测试用例-部门管理
我的测试用例，都是之前生成的，无论用 MCP 工具还是 skills，我都是同一套。
测试结果是我之前用的所有工具中得到的最好的结果，主要有两点：
测试完成的速度非常快 执行测试用例，一次就成功，属于又快又好的那种，根据调用记录来看，没有一次是因为错误，需要截图，分析问题，再执行的恶行循环。
各位蠢蠢欲动的测试小伙伴，如果想深入学习 Dev browser的技术，可以千万 zread 的网站，看看文档，地址如下：
https://zread.ai/SawyerHood/dev-browser/3-choosing-your-mode-standalone-vs-extension
在整个实战过程中，执行一次成功就能成功，我是是用了：
Standalone Mode（独立模式）
后来我想用实战插件模式的时候，遇到一个问题：
可能是浏览器兼容问题，我的谷歌版本是最新的，所以还是用默认的模式会更好，非常稳定。插件还是不太靠谱。
下面就是执行我这个测试用例，占用上下文的情况：
本地已使用了 52% 的对话存储配额，就是一个用例的情况。
总结
回顾整个AI自动化测试工具的发展历程，我不禁感叹技术演进的惊人速度！
从早期的 Playwright MCP 到 Playwright Skill，再到如今的 Dev Browser 插件，我们见证了一场真正的技术革命。这不仅仅是工具的迭代，更是整个AI辅助测试范式的升级。
技术演进的核心价值：
MCP时代：开启了AI控制浏览器的可能性，但受限于上下文容量和执行效率 Skills时代：通过生成固定代码，大幅提升了稳定性和可维护性 Plugins时代：实现了有状态服务和智能体脚本执行的完美结合
对测试人员的友好程度：
对于想要从功能测试转型自动化测试的同事来说，现在是最好的时机！
推荐方案一：Skill + Dev Browser（强烈推荐）
这是最完美的组合：
✅ Playwright Skill 生成可靠、可维护的测试代码 ✅ Dev Browser 提供优雅的错误处理和调试能力 ✅ 代码固化后可反复执行，避免AI幻觉 ✅ 执行过程中的错误可以被精准捕获和修复
这个方案特别适合：
想要系统学习自动化测试的测试人员 需要长期维护测试用例的团队 追求稳定性和可扩展性的项目
推荐方案二：纯 Dev Browser
如果你只想专注于用例设计，Dev Browser也是一个极好的选择：
✅ 执行速度快，3分53秒完成复杂任务 ✅ 一次执行成功率高 ⚠️ 前提是：你的测试用例必须写得足够精准
使用这个方案的关键：
用例质量决定一切 - 越精准的用例，执行效果越好 需要持续优化用例 - 根据执行结果不断调整 适合快速验证 - 想要快速测试某个功能时非常高效
最后的话：
AI技术正在以前所未有的速度改变着自动化测试的未来。从MCP到插件的演进，不仅仅是工具的变化，更是让我们看到了"人机协作"的无限可能。
选择适合自己的方案，让AI成为你的得力助手，而不是神秘的黑盒。无论你选择哪条路径，最重要的是：开始行动！
如果这篇文章对你有帮助，请点个赞和在看，分享给更多的朋友；为确保您能收到每一篇文章，点个关注并在主页右上角设置星标。
免责声明:本文仅供技术交流学习使用,请遵守相关法律法规。文中提到的工具和方法仅作为技术探讨,不构成任何使用建议。
