目录
一、凌晨两点还在改XPath
二、脚本维护的根因不是代码写得差
三、AI Skill到底是个什么工程单元
四、两种测试方式的对决
五、测试工程师的新工具箱
六、分水岭就在今年
一、凌晨两点还在改XPath
上个月，一个做了四年自动化的朋友跟我吐槽。
他们产品改版，页面重构。四百多个UI用例，跑一次失败两百个。定位器全挂了。他带着两个初级工程师，通宵改XPath、CSS Selector，改完第二天又挂了几个。他说这不是第一次了，每次发版前都像在填坑。
我问他，你们有没有试试AI生成动态定位器。他说试了，ChatGPT写出来的代码跟手动写没什么区别，该断还是断。
问题不是AI能不能写脚本，而是他们还在用三年前的思路做自动化。
同样的故事正在大量测试团队里发生。AI来了半年多，很多人最大的变化只是多了一个代码补全工具。该维护脚本的还在维护脚本，该排查随机失败的还在排查随机失败。工具变了，工作流没变。
另一部分团队已经开始换玩法了。他们不再写死每一步操作，而是给AI一个意图——“验证登录页面的邮箱格式校验”，AI自己决定怎么测、用什么定位器、失败怎么重试。这种能力就是AI Skill。
核心差异很清楚：前者让人适应脚本，后者让脚本适应变化。
二、脚本维护的困境本质是抽象层次太低
传统自动化测试有一个天然缺陷：把“做什么”和“怎么做”焊死在了一起。
一个典型的Selenium脚本是这样写的：
driver.find_element(By.ID, "email").send_keys("test")
driver.find_element(By.XPATH, "//button[text()='登录']").click()
每一行都包含具体的定位方式、具体的操作顺序、具体的数据。页面结构变化，脚本直接碎一地。
这个问题的本质是测试意图被淹没在实现细节里。你真正想表达的是“输入邮箱并点击登录”，但不得不写出一堆定位器和等待逻辑。代码越写越长，意图越来越模糊。维护成本随着UI变动指数级增长。
AI Skill的解法完全不同。它不是用AI帮你生成一段会过时的脚本，而是把AI作为执行层的一个可调用能力。
一个登录验证的Skill可以这样定义：
意图：验证邮箱格式校验逻辑
输入：测试邮箱地址
执行：AI理解当前页面结构，动态定位邮箱输入框，输入值，触发校验，读取错误提示
输出：校验结果是否匹配预期
整个Skill里没有任何写死的XPath。所有定位由AI在运行时实时完成。页面结构调整？AI重新看页面，重新找输入框。只要按钮上还有“登录”这两个字，它就能找到。
这个转变的本质是从“步骤驱动”升级到“意图驱动”。测试工程师不再花时间伺候定位器，而是花时间定义“什么算正确”。
三、AI Skill到底是个什么工程单元
抛开玄学，AI Skill是一个可调度的、结构化的智能任务单元。它的内部架构可以用这张图表示：
拆解成四个工程模块：
第一，意图解析层。 接收自然语言或结构化指令。比如“验证登录页邮箱格式校验”，模型把这句话拆解成：目标页(登录页)、动作(输入邮箱并触发校验)、预期行为(显示错误提示)、校验项(邮箱格式)。这一层把人类模糊的描述转成机器可执行的计划。
第二，上下文感知层。 Skill不能盲目操作。它需要知道当前页面长什么样、有哪些可交互元素、每个元素的语义是什么。实现方式通常是抓取DOM树或可访问性树，压缩后注入模型上下文。这是AI定位器能工作的核心——模型不是猜XPath，而是看完整页面结构后推理出最匹配目标语义的元素。
第三，工具调用层。 Skill需要调用外部能力：查找元素、点击、输入、截图、读数据库、调API。这些工具以函数接口暴露给模型，模型自主决定什么时候调用哪个工具、以什么参数调用。工具调用的可观测性是调试的关键——必须能回看模型为什么选择了那个元素。
第四，自适应校验层。 传统断言失败就失败了。Skill可以带自愈逻辑：断言失败后，模型先尝试理解原因——是元素没加载出来，还是页面结构变了，还是业务逻辑真的错了。根据根因判断是重试、调整定位策略，还是直接报告失败。这个闭环大幅降低了误报率。
一个生产级的AI Skill通常还用RAG挂载了业务知识库。例如“校验邮箱格式”到底什么算正确——是正则匹配、调用后端接口，还是前端特定错误文案。这些约束条件存储在外部，运行时动态注入。
四、两种测试方式的对决
拿一个真实场景对比：测试购物车添加商品后的价格计算。
传统脚本方式：
def test_cart_price():
driver.find_element(By.CSS_SELECTOR, ".product-1 .add-btn").click()
driver.find_element(By.CSS_SELECTOR, ".cart-icon").click()
price_text = driver.find_element(By.CLASS_NAME, "total-price").text
assert price_text == "$19.99"
问题一目了然。产品ID一变、CSS类名重构、文案从$19.99变成19.99，脚本全炸。
AI Skill方式：
定义Skill：verify_cart_price(product_name="无线鼠标", expected_price=19.99)
Skill内部执行：
调用AI扫描页面找到名为“无线鼠标”的商品区域的“添加到购物车”按钮
点击后等待购物车图标出现（AI自己判断等待条件）
进入购物车，AI定位总价区域
提取金额数字，与预期比较
如果页面结构和预期不同，返回差异原因
另一个团队用这套方案改造了100多个核心流程用例。三个月内的数据显示：UI改版导致的脚本失败率从每次发版平均35%下降到6%。剩余失败的场景集中在完全没有语义提示的纯图标按钮和 canvas 画布区域。
关键不是AI解决了所有问题，而是测试维护的重心从“修定位器”变成了“补充语义信息”。给一个图标按钮加aria-label，比改两百个脚本的XPath成本低两个数量级。
五、测试工程师的新工具箱
AI Skill不是空中楼阁。现在就可以开始落地。测试工程师需要补三个能力。
能力一：提示工程 + 结构化输出
不是写prompt调教模型聊天。是为Skill设计清晰的输入输出契约。例如要求模型必须返回JSON，包含action、selector_hint、value、confidence字段。结构化输出让Skill的结果可被下游逻辑可靠消费。
能力二：工具定义与调用
模型能调用的工具需要你用OpenAPI或类似规范描述清楚。每个工具的输入参数、输出格式、副作用都要明确。脏活都在工具实现里——模型只负责决策“该不该点这个按钮”，实际点击由安全封装好的函数执行，带超时、重试、日志。
能力三：可观测性设计
Skill运行时，你得知道它干了什么。每个工具调用的输入输出、模型的中间思考、定位时扫描了哪些候选元素，全部结构化记录。失败时能回放当时的页面快照和模型推理过程。没有这个闭环，Skill就是一个黑盒，你不敢让它上生产。
当前主流的AI Agent框架如OpenClaw、Claude Code、LangGraph都已经支持定义自定义工具和Skill。Cursor等IDE也提供了Agent能力集成。测试团队不必从零造轮子，在自己的自动化框架里嵌入AI执行单元即可。
一个务实的起点：选一个你最头疼的、频繁因UI变动而失败的场景，比如登录、搜索、表单提交。把它封装成第一个Skill，跑一周，对比维护成本和失败率。
六、分水岭就在今年
两个趋势已经很清楚。
第一，AI Skill的开发会像当年写单元测试一样成为基础能力。三年后测试工程师的简历上写“熟悉Selenium”不会有任何竞争力，写“设计并维护80+生产级AI Skill”才是硬通货。
第二，测试团队内部会分化。一部分人仍在手动维护脚本大泥球，不断修复不断崩溃。另一部分人搭建Skill中台，让业务测试人员用自然语言描述测试意图，底层Skill自动编排执行。前者被业务抱怨“自动化没用”，后者被当成提效核心。
有个判断值得截图：
改脚本的人将被AI替代，而定义Skill的人将驾驭AI。
不是危言耸听。Cursor和OpenClaw已经让十几行自然语言变成可执行程序。测试领域更难幸免——因为测试本质上就是“验证预期与实际是否一致”，这是一个比通用编程更适合AI发挥的封闭域。
现在回看文章开头那个朋友。他后来做了一个决定：不再修那四百个用例了。挑出最核心的二十个流程，每个花一天改写成AI Skill。剩下的用例全归档。下个版本发布，二十个Skill全绿。发版后第二天，他给团队开了个会，主题是“Skill开发规范”。
你现在的测试脚本里，有多少逻辑是可以被意图替代的？如果页面明天全部重构，你的团队需要几天恢复回归能力？
这个问题没有标准答案。但值得你今晚就想一想。
