现在去B站搜「Playwright」，首页基本被同一类视频承包了。
「用Codex+Playwright MCP，测试效率提高100倍」「用Codex把Playwright封装成测试Skill，效率直接起飞」「3天学会AI+Playwright，学完即就业」。标题一个比一个猛，关键词高度统一：零代码、不用再对着F12抠xpath、一句话搞定全流程。
心动很正常。但点开这些视频的评论区，会发现一个有点魔幻的现象：评论几乎清一色「666」，然后UP主挨个回复「已回，点我头像看我给你发的信息」。
这不是个别情况。这两天我把知乎、B站、小红书、微博四个平台最近发布的87条「Playwright」相关内容全部采了一遍，去噪分类之后，结论值得每个打算「让AI写测试脚本」的人花三分钟看完：这波讨论是真的，而且已经相当深入；但你刷到的大部分内容，不是来教你技术的，是来让你领资料的。
先看「导流堆」长什么样
这类内容有几个非常稳定的特征，认出来就能直接过滤。
标题是固定配方：「零代码」「效率提高100倍」「3天精通」「再也不用抠xpath」「起飞/嘎嘎上升/不加班」。数据是固定形态：收藏特别高，讨论特别少。一条「3天学会」的视频有507个收藏，评论区29条，齐刷刷的「666」换资料。哔哩哔哩另一条热门教程更典型，23条评论几乎是一个结构：置顶一条「一键三连评论666，完整工作流免费发你」，后面全是「666」和「已回，看私信」的循环。哔哩哔哩
这种结构意味着什么？意味着这些内容的收藏量，不能当成「同行都认可」的证据，它大部分是「先收藏再领资料」的转化数据。靠教程热度判断一项技术成不成熟，会被带偏。
还有个细节值得警惕：这类内容喜欢给精确数字。比如有帖子直接宣称，用AI生成测试代码，效率提升80%，覆盖率从60%增至95%。今日头条我把采到的内容翻了个遍，没有找到任何一条说明这些数字是哪个项目、谁来测、怎么测出来的。无法验证的数字，先当宣传语处理，不当决策依据。
去掉导流内容，真正在讨论什么
AI可以帮你生成代码，但它经常不知道你的业务边界在哪里，不知道哪些断言有价值，也不知道哪些失败是真缺陷，哪些失败只是脚本不稳定。哔哩哔哩有价值的讨论集中在知乎和几篇公众号长文里，方向出奇一致：问题已经不是「AI能不能写出Playwright脚本」，而是「AI写出来的脚本，团队敢不敢信」。
一位知乎作者（他自己也在做开源的AI测试项目）把话说得很直白：从「模型生成了一段能看的代码」到「团队得到了一条可维护的测试」，中间至少隔着四件事。知乎
第一，测试意图审查。直接从需求生成脚本，问题往往出在代码之前——需求理解对没对、模块漏没漏、覆盖范围合不合理。更稳的流程是把中间产物显式化：需求先变成测试模块和测试计划，人审查完计划，再让AI去写实现。
第二，真实浏览器验证。语法正确不等于定位器在当前页面有效，也不等于加载时序稳定。「已生成」和「已验证」必须当成两个状态分开标记。
第三，失败修复要复验。「AI已修复」不能当结论，改完的脚本必须重跑一次。否则会掉进「AI修→没修好→重开对话」的循环，一下午就没了。
第四，版本和证据管理。脚本一旦长期使用，就要能回答：它来自哪份计划、这次跑的是哪个版本、失败时截图、日志、Trace在哪。这些是传统工程能力，模型再强也替代不了。
失败不可怕，误判才可怕
在「失败怎么处理」这件事上，另一位写「测试提效系列」的知乎作者拆得更细。他不上来就猜，而是先按判定信号把失败分成六类：环境、定位、超时、数据、脚本、真实缺陷，每一类对应一套明确的修复策略。知乎判定还有优先级：环境排第一，因为环境挂了，后面所有失败都没有意义；真实缺陷排第二，因为它是根因。
其中两种误判，代价最大，值得所有用AI跑测试的团队背下来。一种是环境问题被当成bug提了缺陷单，开发看一眼退回来「环境没配好」，报告白写半天；另一种更隐蔽——真bug被当成偶发失败，重跑两遍跑绿了，缺陷直接漏到线上。知乎用他的话说，「偶现」大概是自动化测试领域最危险的两个字。
他还给「让AI修脚本」定了一条铁律：可以改定位器、调超时、清脏数据，但永远不修改测试用例的断言和业务语义。知乎每处修复自动重跑验证，修不好就回滚备份，报告里如实写「修复未生效，建议人工介入」。这条规则不用等任何工具成熟，今天就能抄进你自己团队的规范里。
官方也在下场，这不是野路子
两个事实坐标。今年6月，Playwright官方推出了Test Agents，让AI代理自动完成浏览器测试——从分析需求、生成测试计划到写脚本，再到自动修复失败的用例。微信公众号它的关键不是「又能生成代码了」，而是把UI自动化拆成了一条更完整的工作流：先规划测试，再生成代码，最后修复失败。哔哩哔哩上个月发布的1.62版本，又把MCP和CLI直接收编进官方主线，「AI操作浏览器、AI写测试」已经从外围插件变成工具自家的主干道。
但生成能力不等于可靠。有实测者发现，Test Agent一次生成的6条用例，最终只跑通了2条。微信公众号这恰恰印证了前面那四个缺口：没有意图审查和真实验证，生成再多也只是库存，不是资产。
同一时期，DeepSeek Harness在8月13日开放开发者预览并同步开源，测试圈的讨论热点随之变成「当Agent自己操作浏览器，怎么保证它每次都操作正确」。知乎微博上也有人把CI流水线编排做成Skill，把「人串链」变成「一句话启动」。微博方向是真的，迭代也是按月算的。
谁现在可以上，谁建议再等等
我的判断分三类人。
第一类，已经有Playwright脚本资产的团队。这是最适合现在动手的，但切入点不是「让AI生成新脚本」，而是「让AI做失败诊断和修复」——存量脚本库的失败分类、根因定位、修复建议、复跑验证，风险低、回报直接，前面的六类失败分类可以直接当起点框架。
第二类，没有自动化基础、想借AI补课的团队。最容易被「一夜生成100条脚本」打动，也最容易翻车。很多团队的UI自动化并不是没人写，而是写完以后没人敢长期维护。哔哩哔哩没人审过意图、没在真实浏览器跑稳、没有证据管理的脚本，数量越多债越重。先把最核心的3到5条业务流程跑稳，让CI绿一个月，再谈扩量。
第三类，拿Playwright做抢票、采集、日常操作的个人用户。这波跟你关系不大，AI+MCP操控浏览器确实能用，但你该关心的是反检测和平台规则，那是另一个话题。
进CI之前，先过一遍这张清单
如果你已经决定把AI生成的Playwright脚本放进CI，先确认这五条：
有没有人工审过的测试计划或用例清单，而不是需求直接变脚本？
每条脚本是否在真实浏览器里跑通过，而不只是「生成成功」？
失败时能否留下截图、日志和Trace，并区分环境、脚本、真缺陷？
让AI修复时，有没有「不碰断言、修后重跑、失败回滚」的规则约束？
脚本是否纳入版本管理，能追溯它来自哪份计划、哪次执行？
五条里满足不到三条，建议先让AI当「诊断助手」，别急着当「生成工具」。
最后留几个值得持续盯的信号：官方Test Agents的成熟度（目前还在早期）、Skill形态的测试工作流怎么演化、以及DeepSeek Harness这类Agent运行时的动向。这个领域现在按月迭代，今天的判断只对今天有效——但「先建信任，再谈提速」这件事，大概率不会过时。
