上周，团队里一个做了三年自动化的同学跟我说：“每次产品改版，光改定位器就要花一整天，改完还得跑两轮回归。” 这不是个例。很多测试团队已经意识到，传统的UI自动化，正在变成一种维护成本远超收益的技术负债。
目录
一、现象：UI自动化越跑越慢，越修越累 二、本质变化：维护成本重心从“写脚本”转向“找元素” 三、核心机制拆解：一个Skill如何接管定位器失效 四、典型案例对比：同一张登录页，两种做法的差距 五、工程落地启示：你可以在两周内复刻这套能力
一：UI自动化越跑越慢，越修越累
四个小时，这是每次前端大版本上线后，我花在修复UI自动化脚本上的平均时间。
不是写新用例。而是改定位器。一个页面平均15个可交互元素，改版后xpath变了、id变了、class名从btn-login变成了button_primary_v2。流水线全红。定位器修完一轮，发现还有三个断言也挂了——原来文案也改了。
这个场景，过去两年我在不下十家公司见过。小到创业公司，大到万人级别的互联网中厂，没人能幸免。
更糟的是，团队里开始有人用硬编码time.sleep来“解决”不稳定问题，有人把显式等待从3秒调到10秒。脚本越来越慢，维护意愿越来越低。
核心痛点不是写不出用例，而是定位器与真实DOM之间没有任何自动纠偏能力。
二：本质变化：维护成本重心从“写脚本”转向“找元素”
过去我们认为UI自动化的主要成本在“编写”。实际上，当项目运行超过三个月，真正吃掉时间的是三件事：
定位器失效：前端重构、组件库升级、样式调整，都会导致xpath/CSS选择器断裂。 等待条件错位：元素存在、可见、可点击、稳定不动，四个状态混为一谈。 断言颗粒度失配：断言太细（精确文案）容易失败，断言太粗（仅存在）漏掉问题。
这三件事的本质是同一个：自动化脚本不知道页面的“语义”。脚本只记得//div[@class='submit']，但不知道这个按钮叫“提交订单”，也不知道它在流程中承担什么角色。
当定位器断裂时，传统做法是人肉去浏览器里重新找、重新写。而我做的Skill，核心目标就是让脚本具备“按语义定位”的能力。
三：核心机制拆解：一个Skill如何接管定位器失效
这个Skill本质上是一个“定位器自愈”模块，跑在Playwright框架之上。以下是它的工作流程：
怎么做的
Skill被封装为一个Playwright的自定义fixture。每次调用click或fill前，会先执行一个“定位器预检”。如果原始定位器在500ms内未找到元素，自动进入自愈模式。
自愈模式做三件事：
捕获当前DOM的快照（仅结构，不存截图） 提取元素周围的文本、aria-label、placeholder、role属性 用一个约80MB的轻量语义匹配模型（onnx量化版），将目标描述与候选元素进行相似度排序
为什么这么做
传统AI定位方案（如Applitools、test.ai）都是在云端跑大模型，延迟高、成本高、依赖外网。我把匹配模型做成本地推理，一次匹配耗时约120ms，且完全离线。
模型不关心class名和id，只关注“可见文本”和“无障碍语义”。比如脚本说“点击登录按钮”，模型会在DOM里找文本包含“登录”的button或者role=button的元素。
解决了什么问题
消除了95%的定位器断裂故障。当产品把btn-login改成button_primary_v2时，脚本不会报错，而是自动找到新的元素并执行。同时，Skill会记录这次匹配结果，提醒测试人员“定位器建议更新”。
四：典型案例对比：同一张登录页，两种做法的差距
上周公司交付了一个改版需求：登录页从左右布局改为居中卡片，所有class名从BEM规范换成了Tailwind。
传统做法
手工重写8个定位器（用户名、密码、登录按钮、忘记密码、注册链接、错误提示、记住我勾选框、关闭按钮）→ 35分钟 重新调试每个步骤的等待条件 → 20分钟 跑一轮回归，发现两个断言文案改了 → 修复15分钟 最后推PR、等审核、合并 → 30分钟 总耗时：约2小时（仍是熟练工的水平）
用Self‑Healing Skill
流水线第一次全红 → 自愈流程自动触发，8个操作全部自动匹配新元素 → 耗时约4秒 文案断言失败（提示语从“用户名或密码错误”改为“账号信息有误”） → 人工修改断言文案 → 2分钟 总体维护耗时： 不到15分钟
💬 可截图传播的观点句1：
“UI自动化的维护成本，不是由变更频率决定的，而是由定位器与被测页面之间的‘语义距离’决定的。距离越远，断裂越频繁。”
💬 可截图传播的观点句2：
“让脚本知道自己在点‘登录按钮’，而不是在点‘那个class为submit的div’——这是自愈能力的认知底座。”
