目录
一、Selenium脚本还没写完，需求已经变了
二、传统框架的致命伤：脆弱、昂贵、反敏捷
三、Skill如何重构自动化底层逻辑
四、三个真实场景：Skill完胜传统脚本
五、工程落地：从POM到Skill的迁移路径
六、你的自动化资产还能撑多久
上个月，一个朋友跟我吐槽。
他们团队花了一个季度，用Playwright重构了整套UI自动化。3000行代码，覆盖了核心业务的80%路径。信心满满上线。结果下个迭代，产品改了三个页面的DOM结构。3000行里直接废了600行。
修这些脚本又花了两周。
他说：“我当初就该用视觉驱动的方案，别死磕定位器。”
这不是个例。
过去一年，我和十几个测试团队聊过。所有人都在面对同一个问题：传统自动化框架的投入产出比在急剧下降。
不是工具不好。Selenium、Playwright、Appium依然稳定强大。问题是，业务节奏变了。
从前一个页面结构半年不变。现在两周三个版本。从前UI组件库统一升级一年一次。现在每两周一个patch。你花大力气写的XPath、CSS选择器、页面对象模型，在敏捷面前就是一次性筷子。
很多人已经开始感觉到：传统自动化框架的地位，正在被动摇。
动摇它的不是另一个框架，而是一套叫Skill的技术范式。
一、Selenium脚本还没写完，需求已经变了
先说现象。
2025年到2026年，测试自动化领域发生了三件容易被忽视的事。
第一，头部大厂开始用AI Agent替代大量UI脚本。不是逐步替代，是直接砍掉维护成本高的那一半。有家电商公司，原来维护着1200条UI自动化用例，每个迭代光修脚本就要3人天。引入视觉驱动的Skill方案后，用例数降到400条，通过率反而从82%升到94%。
第二，Playwright官方社区讨论热度最高的不再是“如何提高稳定性”，而是“如何集成视觉模型做自适应定位”。用户想要的不再是更稳的selector，而是不需要selector。
第三，几乎所有测试工具SaaS厂商都在产品路线图中加入了“AI Skill”模块。Tricentis、Mabl、Testim，无一例外。
这些信号的共同指向：传统脚本式的自动化框架，正在从“首选方案”变成“备选方案”。
不是它们不能用了。是不划算用了。
维护成本已经超过了编写成本。一个UI用例的生命周期里，开发和调试只占20%，剩下80%都在修修补补——定位器失效、等待超时、环境差异、数据依赖。
Skill技术试图解决的就是这80%。
二、传统框架的致命伤：脆弱、昂贵、反敏捷
为什么传统框架越来越吃力？三个本质问题。
第一，定位器的脆弱性。
Selenium和Playwright的本质是基于DOM定位。你用XPath或CSS选择器告诉工具“点那个按钮”。但只要按钮的class变了、父级结构变了、甚至同一页面出现两个相似按钮，脚本就挂了。
这本质是“按路径寻址”的缺陷。路径稍微偏移，就找不到目标。
第二，断言的低级性。
传统框架做UI验证，只能断言“元素是否存在”“文本是否等于某值”。但验证“页面看起来是否正常”这种人类一眼能判断的事，脚本需要几十行代码去检查每个区域。
更麻烦的是动态内容。广告、时间戳、推荐模块让断言变得要么假阳性高（忽略所有动态区），要么维护成本爆炸（每个动态区写一个特殊处理）。
第三，跨平台成本线性增长。
Web、iOS、Android、桌面端，每个平台需要不同的驱动和定位策略。你在Web上写好的XPath，到了移动端要重写成基于accessibility id的逻辑。一套业务逻辑，N套实现。
这三个问题叠加的结果是：传统自动化框架的维护成本，随着业务复杂度线性增长。甚至超线性。
而Skill技术，用一种完全不同的思路绕过了这些问题。
三、Skill如何重构自动化底层逻辑
Skill不是另一个定位器策略。它是一套新的自动化范式。
核心差异在于：传统脚本是“指令式”，Skill是“目标式”。
你告诉传统框架：步骤1，找到id=username，输入admin；步骤2，找到xpath=//button[text()='登录']，点击。
你告诉Skill：登录系统，用admin账号。
Skill自己去识别当前界面、定位输入框、输入内容、找到登录按钮、点击、等待跳转、验证登录结果。过程中如果定位器失效，Skill会换一种方式（比如视觉识别）重新尝试。
来看一个简化架构图：
Skill框架的关键组件：
感知层：不依赖单一信息源。同时拿到DOM结构、截图、可访问性树。哪个好用用哪个。
决策层：根据目标（如“点击登录按钮”）和当前感知信息，动态选择定位策略。优先用最快最稳的（比如ID），失败后用备用方案（比如视觉匹配）。
降级链：定位失败不是直接报错，而是尝试下一种策略。直到所有策略耗尽才失败。
语义验证：验证时不写死文本。问模型“这个页面是否显示登录成功后的欢迎语？”。
这套架构解决了传统框架的三个致命伤：
脆弱性问题被降级链解决。一种定位器失效，换一种。不是重写脚本，是运行时自适应。
断言低级问题被语义验证解决。你不再需要写几十行判断页面布局的代码，直接问模型。
跨平台成本问题被感知层统一解决。视觉和OCR是跨平台的。同样的Skill，在Web上截图，在移动端也截图。底层驱动不同，但验证逻辑完全复用。
这就是为什么Skill正在瓦解传统框架的地位。不是传统框架做错了什么，是Skill用了更合适的抽象层级。
四、三个真实场景：Skill完胜传统脚本
说理论太虚，直接看案例。
场景一：登录表单，按钮文字从“登录”变成“Sign In”
传统脚本：死在寻找//button[text()='登录']这一步。报错。需要人修改脚本，改成‘Sign In’。
Skill：第一次尝试用text定位失败。触发降级，尝试用button的type=submit属性定位，成功。或者用视觉识别“那个蓝色的、在密码框下方的按钮”。整个过程自动完成，不报错。
场景二：商品详情页，加入购物车按钮的位置随屏幕尺寸变化
传统脚本：固定坐标点击(x=200,y=800)。换手机尺寸，按钮位置变了，点到空白区域。
Skill：目标描述是“点击加入购物车按钮”。感知层分析当前截图，识别出按钮区域，动态计算中心坐标。不管按钮在屏幕什么位置，都能点到。
场景三：注册成功后的欢迎弹窗，文案中的用户名是动态的
传统脚本：断言toast包含“欢迎”。太弱。断言精确文本“欢迎，张三123”，但用户名每次不同，只能做模糊匹配或参数化。麻烦。
Skill：验证“是否有一个弹窗，内容包含‘欢迎’以及当前登录用户的昵称”。Skill先拿到当前用户名，再用模型比对弹窗文本和预期语义。一次调用，精准通过。
这三个场景的共同特点是：传统框架需要人为预判变化并写代码适配。Skill不需要。Skill的自适应能力来自运行时决策，不是预编程。
从投入产出比看，一个Skill的初始编写成本比传统脚本高30%左右（因为要配置降级链和感知层）。但维护成本只有传统脚本的20%。三个迭代之后就回本了。
五、工程落地：从POM到Skill的迁移路径
如果你决定尝试Skill，不需要推翻现有框架。迁移路径是渐进式的。
第一步：识别高维护成本的用例
拿出你的测试用例库，筛出过去三个月修改次数最多的前20%用例。这些是Skill降级链最能发挥作用的地方。
通常这类用例有以下特征：依赖复杂DOM结构、频繁变动、多环境运行、断言复杂。
第二步：选一个低风险场景做POC
不要选核心交易链路。选一个内部管理后台的低频功能。用Skill重写这条用例。跑通。对比维护成本和稳定性。
POC阶段的目标不是覆盖率，是验证Skill在你的技术栈里是否稳定。验证降级策略是否够用。验证模型调用成本是否可控。
第三步：抽象Skill模板
当你有了3-5个成功的Skill，观察它们的共性。比如“登录”“搜索”“填表单”这些高频模式。把这些共性封装成Skill模板。以后新用例只需要填空（用户名、目标URL等），不用重写感知层和降级链。
第四步：存量用例按策略迁移
不是全部迁移。定一个规则：每次某个传统脚本坏了，修之前评估一下。如果过去三个月已经坏了超过两次，这次不修了，直接重写成Skill。否则继续修。
两到三个季度，高维护成本用例会自然迁移完毕。
需要注意几个坑：
模型调用有延迟。Skill的降级链里，视觉识别通常比DOM定位慢。优先用DOM，失败再降级到视觉。
成本要监控。视觉模型调用按次收费。一个Skill一天跑几十次，月成本可控。但如果用例数量上千，需要做缓存和采样。
确定性操作不要交给模型。比如“点击同意协议复选框”这种固定位置的，直接写坐标或ID。Skill只在需要自适应的地方调用模型。
六、你的自动化资产还能撑多久
Skill技术还在快速演进。
未来12个月，可以预见的趋势：
Skill框架从“模型辅助定位”走向“模型生成完整测试”。给模型一个需求文档，它自动生成一组验证Skill。
跨端Skill成为标配。一套Skill描述，自动在Web、iOS、安卓、小程序上执行。底层驱动由框架适配。
传统定位器退化到“兜底方案”。视觉和语义成为主流，DOM定位只在性能敏感场景使用。
这对测试团队意味着什么？
你花了几年积累的页面对象模型、用例库、数据驱动框架，这些资产的价值在缩水。不是没用，是边际收益递减。
新资产的核心，是你对业务场景的Skill化封装。是你团队有多少个经过验证的、自带降级链的、跨平台可用的Skill。
这是一个判断题：
如果你的核心业务下个版本UI完全重构成新的组件库，你现在维护的自动化资产里，有多少比例能在不修改代码的情况下继续通过？如果这个比例低于50%，你的迁移计划什么时候启动？
