北京
让AI自动修改测试代码，听起来很美好，但如果没有刹车机制，这辆车迟早要撞墙。Playwright自愈测试Agent的实践者最近分享了一套方案：与其赌AI每次都能改对，不如用三道硬性护栏，把它的权限锁死在"只换定位器"这个范围内。
这个思路的起点很直接——自愈的本质是"让AI改你的代码"，而AI改代码这件事，没有刹车的自愈就是灾难。恶意代码执行、误改业务断言、带崩其他用例，这些风险不是假设，而是真实会发生的场景。作者给出的解法不是祈祷AI更聪明，而是从工程层面把风险路径一条条堵死。
第一道护栏：用AST白名单替代永远堵不完的黑名单
传统思路是维护一个危险代码黑名单，但AI生成代码的方式决定了黑名单永远追不上它的花样。作者改用Python的ast模块，把代码解析成语法树，然后只允许特定的语法节点和名称通过。白名单是反过来的思路：不在名单里的语法节点，一律拒绝。这样从语法层面就拦截了不安全代码，而不是事后去识别它。
这套机制的关键在于"默认拒绝"——AI生成的代码必须逐项匹配白名单里的节点类型，任何不在名单里的结构直接打回。相比黑名单的被动防御，白名单把安全边界画在了最前面。
第二道护栏：改动范围校验，只换定位器不碰业务逻辑
AI最容易犯的错不是改错，而是改太多。作者通过对比改动前后的文件，强制要求改动行必须符合定位器特征，同时明确排除assert、def、import这类业务逻辑关键词。行数不变、改动次数受限，这些约束叠加在一起，确保AI只能在"换定位器"这个动作上做文章，碰不到用例结构和业务断言。
这道护栏的本质是给AI画了一个极小的操作窗口。它不需要理解整个测试用例的业务含义，只需要在指定范围内完成替换动作。范围越小，出错的可能性就越低。
第三道护栏：沙箱验证、回归测试与自动回滚闭环
新定位器通过沙箱验证只是第一步，还得跑关联用例做回归测试。如果回归失败，系统通过git自动回滚到改动前的状态；如果改动过多，则转入人工审核流程。"验证→回归→回滚"这条闭环，就是"自愈"和"瞎改"的分界线。
这套闭环把AI的每一次改动都置于可撤销的保障之下。即使AI真的改出了问题，系统也能在几秒内恢复到安全状态，不会让坏代码留在测试套件里持续造成影响。
踩过的三个坑：护栏本身也需要调试
作者在编写护栏的过程中也踩了三个实际坑点。这些坑主要集中在白名单覆盖不全、范围校验误伤正常改动、以及回滚逻辑在特定场景下失效等问题上。这些细节提醒我们，护栏不是写一次就完事的，它需要在实际使用中不断调整和补全。
这套方案的价值在于，它把"AI改代码"这件事从"信任问题"变成了"工程问题"。不需要AI变得绝对可靠，只需要在它出错时，系统能及时发现并恢复。对于正在尝试让AI参与测试维护的团队来说，这三道护栏提供了一个可落地的参考框架。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
