做UI自动化的人，大概率都经历过这样的早晨：打开跑批报告，发现昨晚的回归任务又挂了一堆用例，点进去一看，不是选择器失效，就是页面结构改了，再或者某个异步加载变慢了。修脚本这件事，本身不复杂，但架不住它频繁、琐碎、重复。我维护的那套基于Playwright的端到端测试，用例量过了两千之后，每周光是修“能用但偶尔挂”的脚本，就要搭进去大半天。后来我主导做了一个AI参与自动化维护的小闭环，核心思路很简单：让AI帮我分析失败原因、给出修复建议，甚至直接生成补丁，我负责审核和兜底。这篇文章就完整复盘一下这个“自动修复闭环”的实践过程，包括架构设计、关键实现、踩过的坑，以及现在沉淀下来的一套可复用的做法。
这套闭环并不会玄乎地“自动修好所有问题”，但实测下来，能稳定解决其中百分之六七十的选择器失效和等待超时类问题，把脚本维护的人力投入降到了一个比较低的水平。如果你也在维护一批Playwright用例，正在被“修脚本修到头大”这件事困扰，这篇文章应该能给你一个可以直接借鉴的落地方案。
1. 为什么非要让AI参与自动化维护
1.1 脚本维护到底在维护什么
先聊聊我面对的痛点。Playwright这套框架本身很好用，定位稳、等待机制强、多浏览器支持也省心，它已经帮我们挡掉了很多底层兼容性问题。但当用例规模上来之后，真正消耗精力的是几类“软性”问题，这些问题框架本身管不了。
第一类是选择器失效。前端改版、加了个div层级、class名动态化、元素从静态变成异步渲染，这些都会导致定位失败。第二类是时序问题。接口慢了、图片加载延迟、某个动画没结束，用例步骤就提前执行了，断言也跟着失败。第三类是断言本身写得不稳。比如固定匹配某个文案，结果运营后台把提示文案改了；或者只校验了部分属性，漏掉了状态变化。
早期我们的处理方式就是“谁报红了谁去修”，修改内容一般是人工看一眼截图和日志，然后改选择器或者加等待。听着好像不难，但用例基数大了之后，每次发版前后集中的一波“报红潮”，足够把整个团队的迭代节奏拖慢。真正麻烦的不是某一条脚本有多难修，而是“量太大、修不过来”。
1.2 传统自动修复方案为什么不够用
其实“自动修复”这个概念并不新鲜，早些年就有基于规则和固定策略的修复工具。它们的核心逻辑是：定位失败后，尝试用备选选择器列表去匹配，或者自动把固定等待改为显式等待。这类方案能解决一部分问题，但是死板。前端改版往往是结构性的，class和id都换了，备选列表根本覆盖不到。时序问题更是如此，盲目加长等待只能让用例跑得更慢，无法保证就一定稳。
还有一类做法是基于视觉对比，失败时截图与历史截图做diff，推测改动区域，再反推选择器调整。这个思路在纯静态页面上有效，但放到复杂后台系统里就露怯了：图表、弹窗、异步表格，任何动态内容都会产生大量“无效diff”，误报率很高。
所以我当时的目标不是“去找一个完美的自动修复工具”，而是“把AI的语义理解能力引入到现有流程中”。AI的价值在于，它能够结合页面结构变化、报错信息、截图内容甚至网络请求记录，综合判断“页面为什么变了、脚本为什么找不到”，从而给出更聪明的修复建议。
1.3 闭环设计的基本原则
在做这个闭环之前，我先定了三条设计原则，确保它不是一个花架子。
第一条是“AI负责提案，人负责决策”。只要是自动修复，就必须保留人工审核这一道闸门。AI给出的patch不能直接合入主干，必须经过确认，否则一个错误修复会引发更大的连锁故障。
第二条是“修复必须经过验证才算完成”。AI修完脚本后，不能只是“看起来合理”，要落到实际执行上。至少要跑一遍目标用例，通过之后，才能算真正走完一个修复闭环。
第三条是“所有上下文都要结构化沉淀”。AI判断需要数据支撑，这些数据来自失败任务的日志、截图、DOM快照、网络请求记录等，收集得越全，AI的分析就越准。沉淀下来的失败样本，还能不断反哺修复策略。
这三条原则后来贯穿了整个系统的设计，也保证了这套玩法是可以长期运行、越用越准的。
2. 闭环的整体架构与核心思路
2.1 四个核心环节
整个自动修复闭环可以拆成四个环节：失败采集、根因分析、修复提案、回归验证。
失败采集是地基。用例跑挂之后，除了常规的堆栈日志，还需要把当时的页面截图、精简后的DOM结构、浏览器控制台错误、以及关键网络请求记录一并收集起来。信息越完整，后面AI定位的准确率就越高。
根因分析是核心。拿到采集到的多模态数据后，要回答几个问题：脚本为什么失败？是选择器定位不到，还是元素没有出现？是断言值不一致，还是页面发生了跳转？这个问题对应的是哪一个前端改动？这个步骤需要AI去“理解”页面结构和报错之间的关系，传统规则很难做到。
修复提案是落点。AI根据分析结果，给出明确的修复动作。比如“选择器从#old-class改为[data-testid=’new-name’]”“显式等待某个接口响应后再点击”等等。提案必须足够具体，能直接变成可执行的代码补丁。
回归验证是闭环的终点。拿到补丁后，系统会自动在对应分支上跑一次该用例（或其依赖的冒烟集），只有通过后才把结果标记为“已验证”，随后推荐给人工做最终审核。
这四步合在一起，才是真正意义上的“自动修复闭环”，而不是“AI建议，人看完自己改”。
2.2 为什么选Playwright作为承载框架
既然核心是修复，那么承载这个闭环的框架选型很重要。我当时不是没想过自己做一套底层驱动，但仔细评估之后，还是决定基于Playwright来做。原因有三点。
第一，Playwright的追踪信息非常丰富。它自带的trace viewer能记录页面操作、DOM快照、网络请求、控制台日志，几乎是把调试所需的上下文打包好了。用trace文件作为AI分析的核心输入，比自己去拼日志位置、截图路径省太多事。
第二，Playwright的locator API足够精细。旧的定位方式失效后，修复时大概率要换一种定位策略，比如从CSS选择器切到text=、从单一属性切到层级定位。Playwright这套API的灵活性能给AI修复提供很大的操作空间。
第三，Playwright的自动等待机制本身能消化掉一批时序问题。它默认会等待元素可操作，所以很多超时本质上不是“不够等”，而是选择器本身指向了错误的目标。分析这类问题时，重点会更清晰。
2.3 数据流与状态设计
整个闭环本质上是一个异步处理系统。用例在CI中执行失败后，会触发一个失败事件。事件里携带一批采集到的产物，推送到一个独立的消息队列中；后台有一个分析服务消费这个队列，调用大模型API进行根因分析；分析结果生成修复任务；修复任务执行时，先拉取用例所在分支，应用patch，然后触发一次定向回归；回归结果再通知到人工审核端。
每条修复任务的数据模型大概长这样：
- 任务ID、用例ID、失败时间、CI任务编号
- 失败消息摘要、堆栈关键词、trace文件路径
- 截图清单、DOM快照摘要、网络请求异常摘要
- AI分析结论（分类、置信度、根因描述）
- 修复patch内容、涉及文件、涉及步骤
- 回归状态（待验证/验证中/通过/失败）
- 人工审核状态（待审核/已采纳/已驳回）
这个数据结构贯穿了从失败到验收的全过程，每一步的输入输出都依赖它。刚开始做的时候，不需要搞得太重，但字段一定得设计好，不然后面接AI分析、接人工管理界面的时候，会改得想哭。
3. 核心细节解析与关键模块实现
3.1 失败采集模块：别省这一步的功夫
失败采集是整个闭环里技术含量最低、但影响最大的模块。为什么这么说？因为AI的分析是典型的“垃圾进、垃圾出”。采集的信息不完整、格式不统一，再强的大模型也分析不出个所以然来。
我在采集模块里做的事情比较细：
每次用例失败后，先抓Playwright的trace文件，这个是全量信息。但全量trace有时候太大，直接丢给AI既不经济也不高效。所以要做一个提取逻辑：从trace里筛选出失败步骤的前后几帧，找出当时的关键DOM状态。我一般保留失败步骤的上一操作和失败步骤本身这两帧的aria快照，再带上页面URL和控制台报错日志。
截图处理上，我保留的是失败瞬间的整页截图，同时会额外截一张要素聚焦图。要素聚焦图是用Playwright的locator对象尝试定位后，把目标区域裁剪出来，方便AI直观地看到“它想找什么”，以及“当前页面上这个东西长什么样”。
DOM快照不能要那种几千行的完整HTML，AI读起来费token，而且有效信息会被稀释。我做了个压缩策略：去掉script、style标签，去掉动态属性（比如频繁变化的style值），只保留标签层级、class、id、text内容、data-testid等关键属性，同时做截断处理。
网络请求方面，主要采集失败前15秒内有异常的请求：比如接口超时、返回状态非200、请求被取消等，这些往往能解释“为什么元素没有渲染出来”。
3.2 AI根因分析的实现方式
根因分析是整个闭环里最核心的部分，也是我觉得最值得展开讲一讲的部分。
我用的是大模型API，但并不是简单地把日志丢给它，而是设计了一套结构化的提示词模板。模板内部分了三个层次：
第一层是“失败描述层”。把失败消息（比如“locator.click: Timeout waiting 5s”）、脚本步骤名、当前URL、控制台错误合并成一段上下文。
第二层是“页面证据层”。把压缩后的DOM快照、截图描述（用视觉模型生成一段图文摘要，或者在支持视觉输入的模型里直接放图）、异常网络请求列表传递进去。
第三层是“候选修复策略层”。这一步很关键，我会设定若干候选方向，让AI按方向来归类判断，而不是天马行空地猜。候选方向包括：选择器过期、新元素未出现、元素被遮挡、异步加载延迟、断言值不匹配、页面跳转逻辑变动，以及“不确定”兜底。
为了让AI输出稳定，我要求它必须给一个结构化的输出，包含：
- category：问题归属类别
- confidence：0到1之间的置信度
- root_cause：一句话解释，最多两行
- repair_strategy：具体建议，必须说明改哪个文件、哪个步骤、改成什么样子
这套结构化的提示词模板，比那种“帮我看看这个报错”的用法稳定太多了。尤其是限制候选类别这一步，直接让模型的幻觉率大幅下降，因为它不是在开放环境里瞎猜，而是在一个选项空间里做匹配。
3.3 修复patch的生成与校验
分析出根因之后，下一步是把结论变成可以落地的patch。这一步我跑了很多版本才跑通，核心难点在于：AI要修改的是真实代码，不能用自然语言“描述一下怎么改”，而是直接产出diff。
我整理了一个针对Playwright项目的修复生成规则集：
对于选择器失效类问题，AI需要根据DOM快照里当前元素的位置、文本、属性，给出一个新的locator写法。优先建议使用getByRole、getByText、getByTestId这类更语义化的API，而不是继续写一长串CSS层级。同时要求AI保留原有操作步骤的结构，不能顺手“重构”代码。
对于等待超时类问题，AI需要分析是全局等待不足还是条件等待缺失。如果是因为页面某个接口慢，建议用page.waitForResponse配合对应请求URL；如果是元素渲染慢，建议用expect(locator).toBeVisible()这种方式显式等待。不允许AI把timeout参数盲目调大，这是硬性约束。
对于断言失败类问题，AI需要对比期望值和实际值，判断是前端文案调整还是真的回归缺陷。这里特别强调：如果AI判断不了，不要强行给结论，输出“需要人工确认”即可。
patch生成之后，在合入之前还有一个“语法级校验”动作。用AST解析器对patch涉及的代码文件做解析，确保没有语法错误、没有未定义的变量引用。这一步能挡掉一大批大模型犯的低级错误，比如引号不闭合、函数名拼错等。
3.4 人工审核与确认机制
在所有自动环节都跑完之后，最终还是要回到人。但我把人工审核的体验做得极简：不需要去看原始日志、不需要自己去翻页面，只需要看系统生成的分析报告。
报告里包含：失败截图、AI的分析结论（问题类别、根因描述、置信度）、修复patch diff、回归验证结果。人工要做的只是在界面上点“采纳”或“驳回”。如果驳回，还可以写一句原因，这个原因会和失败样本一起进样本库，后期用来做策略迭代。
这个机制看起来简单，但解决了两个问题：一是信任问题，团队才敢慢慢把这个闭环从“备份方案”变成“主力维护手段”；二是数据积累问题，每一次人工驳回和理由，都是后面调优提示词、优化候选策略的输入。
4. 实操过程与效果数据复盘
4.1 从零到一的落地步骤
如果你是第一次在自己项目里搭这样一个闭环，我建议按下面这个顺序来推进，而不是一上来就想要“全自动”。
第一步，先把失败采集做完整。至少保证每次CI失败后能稳定拿到trace文件、截图、压缩后的DOM快照和控制台日志。这一步如果没做扎实，后面AI的能力再强也发挥不出来。
第二步，写一个离线的根因分析脚本。手上有了一批真实失败的样本之后，用大模型API先跑一遍，看看它在历史样本上的准确率如何。我那时候是从历史失败任务里抽了50条做盲测，对着已知答案人工检查AI分析结果，准确率大约六成左右。这个数字看起来不高，但已经足够有实用价值——剩下四成里多半是样本质量不行，数据认真补齐之后准确率还能往上走。
第三步，选择一批风险低的用例做试点。比如纯展示型的页面、内部系统的列表页，这类用例就算修复错了，也不会影响核心资金链路。跑通之后再逐步扩大到核心链路用例。
第四步，部署完整的异步闭环。把消息队列、分析服务、回归执行器、人工审核界面串起来。整个架构技术选型上我没有引入特别重的组件：队列用的Redis Stream，分析服务是一个独立Python进程，回归执行直接复用CI的runner，审核界面就是一个简单的Web页面。
4.2 关键参数与提示词示例
这里分享一段我当时写的提示词模板核心结构，你可以直接拿去做参考：
你是UI自动化测试维护助手。下面是一次Playwright用例失败的上下文。 失败信息： {error_content} 页面信息： {page_url} {dom_snapshot} {exception_screenshot_summary} {abnormal_requests} {console_errors} 请从以下候选类别中选择一个最可能的失败原因： - selector_outdated：选择器定位到的元素已不存在 - element_not_visible：元素存在但不可见或被遮挡 - async_timeout：异步数据加载未完成导致超时 - assertion_mismatch：断言期望与实际不同 - page_flow_changed：页面跳转或流程发生变化 - unknown：以上类别均不适用 要求： 1. 输出JSON格式，包含category、confidence、root_cause、repair_strategy 2. repair_strategy必须具体到“修改哪个文件哪个定位器，改成什么” 3. 如果选择unknown，根因描述要尽量给出可能方向 4. 不要编造上下文以外的信息这套模板配合压缩后的DOM快照，效果比单纯堆日志要好很多。后来我又给截图做了视觉摘要输入，把整页截图的base64直接传给多模态模型，让模型“看”一眼界面布局，对分析元素遮挡类问题特别有效。
4.3 跑了两周之后的数据表现
试点跑了两周之后，我整理了一批数据。真实项目名不方便透露，我用代号来描述：某个内部运营后台，用例规模约1200条，每周执行两次回归，平均每次失败70到100条。
接入闭环后，每天AI平均分析35条失败用例，其中约60%的用例能生成可用的修复patch。patch经过回归验证后，一次通过率约50%，人工审核采纳率约40%。算下来每周能稳定自动修复几十条用例，人力工时从每周大约两三个人天降到了四五个小时，主要花在审核和驳回处理上。
这个数字没有某些演示视频里“准确率98%”那么惊艳，但关键在于：系统是持续在自动跑的，不需要我每周重新投入时间重新分析，AI的修复能力只会随着样本累积越来越稳。
剩下的那些修不了的呢？我分类过：大约15%是前端结构彻底重构，一个页面整体改了交互逻辑，这种光改选择器没用，必须人工分析新流程；还有10%属于断言逻辑本身写得不合理，需要业务方介入确认预期行为；另外有15%左右是环境类问题，比如测试数据被污染、依赖服务不稳定，这些明明是环境问题但脚本报错报得很像前端问题。
4.4 与CI流程的集成细节
把这个闭环接进CI流程，有一些细节值得说清楚。
我是在CI跑批结束之后加了一步“失败任务采集和分析”的作业。这一步不会阻塞主流程，它作为异步任务触发，避免因为AI分析耗时拖累整个回归流水线。失败任务进入队列后，我会控制并发数量，防止一批失败用例太多时瞬间把大模型API配额打满。
回归验证环节也做了优先级控制。AI生成的patch先在一台独立runner上执行，这个runner同时只跑一个验证任务，避免资源争抢导致验证结果不靠谱。验证任务除了跑目标用例，还会补充跑一遍它依赖的公共用例，确保patch不会影响共用模块。举个例子，如果某个AI patch改了登录相关的选择器，验证时不仅跑那条用例，还要把依赖登录态的几条用例一起跑了，防止“修好一条炸掉三条”的情况。
5. 常见问题与避坑指南
5.1 AI频繁给出错误修复怎么办
这个问题很多人一上来就会遇到，尤其是没有做过上下文约束、直接把一个报错日志丢给AI去“猜”的时候，AI会给你编一个看起来非常合理的错误修复。哪怕它给出的选择器本身并不存在。
我的处理策略是第一道的分类约束。不要把AI变成一个全开放问题的解答器，而是让它在一个有限的类别空间里做选择题。一旦类别选错，后面无论patch写得多好都是错的，所以我在提示词里强制要求：只有同时给出高置信度结论时才允许直接生成patch，否则走人工确认流程。
另外，对AI重复犯的同类错误要单独做样本累积。每次人工驳回时都记录原因，定期把这些驳回样本反哺进上下文示例。比如AI总喜欢在时序问题里把timeout调到30秒，我就专门在提示词里加了负面示例：“不要通过增加timeout解决等待问题”。效果立竿见影。
5.2 一条用例为什么越修越脆
这里有一个很容易踩的坑。有些AI patch能够在本轮回归里通过，但它会让用例变得更脆弱。典型情况是：为了快速定位元素，AI写了一条特别长的CSS路径，完全依据当前DOM结构生成，比如html>body>div>div>div>div[class=’xxx’]。这种选择器在当前版本下能工作，但只要前端加一个wrapper层就会立刻失守。
我的约束是：非必要不使用层级CSS选择器作为修复方案。优先要求AI使用语义化定位：getByRole、getByLabel、getByText、getByTestId。如果实在要用DOM结构定位，必须限定在两层以内。这条规矩写进提示词之后，patch质量提升得比较明显。
还有一类“越修越脆”的情况是AI为了处理偶发慢加载，在每步操作前都加了强制sleep等待。这会把用例执行时间拉得很长，还掩盖了真实的性能回退。我明令禁止新增time.sleep这种代码，只允许用Playwright原生的等待机制。
5.3 隐私与成本如何平衡调用大模型API
调用外部大模型API处理测试代码，最大的顾虑是代码会离开本地环境。如果公司有严格要求不能把内部页面DOM信息传到外部模型，那这套方案就需要调整。
我当时参考了几种做法。一种是把分析服务部署在一个能够调用内部模型的网络环境里，用内部部署的模型来做分析，这样数据不出内网，代价是需要运维一个模型服务，成本较高。另一种是对外发数据前做脱敏处理：把所有URL参数去掉，把用户信息、业务实体名替换成占位符，唯一保留的是元素结构特征。这样一来，即使信息到了外部模型，也无从还原成真实业务数据。
成本方面，核心控制手段是减少token消耗。DOM快照压缩、只用失败步骤附近的上下文而不是整段执行日志、截图只传一张而不是全部截图，这些手段叠加起来，平均一条失败用例的分析成本大约在几千token量级。加上缓存机制：同一用例同一失败类型短时间内只分析一次，整体费用处在可接受范围。
5.4 别忽略失败样本的持续积累
每次跑批、每次修复、每次驳回，都会产生新的样本。这些样本如果不做归档，AI能力就是一座孤岛，永远停留在你接入时给它设定的水平上。
我的做法是每周做一次“案例复盘”。从样本库里挑出新增的典型失败类型，把对应的分析结果、修复patch、最终处理结果拼成新的提示词示例。过一两个月之后，模型在你这套业务流程上的“经验”会越来越丰富，修复准确率是肉眼可见地往上涨的。
有一个比较反直觉的发现：随着AI修复能力提升，最终沉淀下来的高难度case反而变多了。因为这些简单的、机械的、可规则化的修复都被AI消化掉了，剩下需要人工介入的，都是真正需要理解业务逻辑的复杂问题。这其实是一个很好的状态，因为它意味着人的精力被释放到了真正有价值的地方。
6. 这套闭环还能怎么扩展
6.1 从“修用例”到“防用例坏”
闭环跑顺之后，我开始思考怎么少让用例变坏，而不只是坏了之后去修。一个直接的想法是：利用AI对DOM快照分析的能力，在每次前端代码合并前做一次“疑似影响面扫描”。前端改动合并前，用当前用例库里的选择器列表批量匹配新版页面的元素，如果某个选择器匹配不到，就提前预警告给前端同学，把“报红”消灭在测试阶段。
这个思路的雏形我已经在一部分核心用例上验证过了，效果很不错。它相当于给选择器们做了个“健康体检”，省去了跑完整个回归才发现问题的时间差。
6.2 从“改脚本”到“改断言策略”
另外一个扩展方向是让AI参与断言策略的优化。很多断言不稳定的根源，在于断言本身写得不够“对准要害”。比如有些用例断言了某段纯展示性文案，但这个文案运营经常改，那这条断言就应该去掉，或者改成断言某个更稳定的业务状态。
AI可以做到的是：分析历史失败数据，找出那些相同失败类别、相同失败步骤反复出现的用例，给出一份“断言健康度报告”。报告标记出哪些断言属于高风险断言（脆弱但价值低），哪些断言覆盖不足（关键步骤没有断言）。这不只是维护脚本，而是在帮你审视整个测试策略是否合理。
6.3 与本地开发体验打通
最后一个小扩展，是把这个闭环的能力做成一个本地命令。开发者在本地写新用例或者调老用例的时候，可以直接命令行触发一次“AI分析当前失败”，不需要等到CI跑完。它本质上是调用了同样的分析服务，只不过输入换成了本地刚产生的trace文件。
这个体验调试起来非常顺，尤其是新写的用例第一次跑挂的时候，AI一分钟内就能告诉你：“这个locator在当前页面上找不到等价元素，建议改用text定位，置信度较高”。开发者顺手点了采纳，本地就直接改掉了，效率体感提升非常大。
7. 最后的一些实践心得
回顾这个闭环从设计到落地的全过程，我最大的体会是：AI参与自动化测试维护，不是把“修脚本”这件事变魔幻了，而是把“修脚本”这件事的决策成本降低了。它没有能力凭空理解你的业务，但只要你把上下文喂给它、把候选空间约束好、把验证关卡守住，它就能成为团队里一个干活非常勤快的“初级自动化维护工程师”。
对于也想尝试这套做法的同行，我给三个建议。第一，先积累一批高质量失败样本再做AI分析，别边踩坑边调试，会浪费很多时间。第二，把人工审核做成不可跳过的一环，不管AI置信度多高，这道闸门都不能省。第三，别追求一次做到位，先跑通最小闭环，后续的每一轮迭代都会让这个体系更健壮、更能打。
这套实践目前还在持续演进，但核心方法论已经比较稳定了。如果你们团队也天天被自动化用例的维护成本折磨，不妨也试着搭一个这样的小闭环，先从小范围用例开始，跑上两周，你大概率会和我一样，重新审视“自动化维护”这件事的价值。
