上个月，一个做了四年自动化的朋友跟我吐槽。
他们产品改版，页面重构。四百多个UI用例，跑一次失败两百个。定位器全挂了。他带着两个初级工程师，通宵改XPath、CSS Selector，改完第二天又挂了几个。他说这不是第一次了，每次发版前都像在填坑。
我问他，你们有没有试试AI生成动态定位器。他说试了，ChatGPT写出来的代码跟手动写没什么区别，该断还是断。
问题不是AI能不能写脚本，而是他们还在用三年前的思路做自动化。
2026年的测试行业，已经没有人再怀疑AI能不能干活了。信通院报告显示，全球70%的企业测试用例已由AI生成。传统自动化脚本的月均失效比例超过25%。AI生成测试用例的普及率从2020年的不足10%跃升至当前的70%。
但很多人最大的变化，只是多了一个代码补全工具。该维护脚本的还在维护脚本，该排查随机失败的还在排查随机失败。
工具变了，工作流没变。
另一部分团队已经开始换玩法了。
目录
一、从改XPath到定义意图
二、脚本维护的本质困局
三、AI Skill 的工程架构
四、一个登录页面的两种写法
五、工程落地：从哪开始
六、你的测试资产还能撑多久
一、从改XPath到定义意图
先看一个真实场景。
一个典型Selenium脚本是这样写的：
driver.find_element(By.ID, “email”).send_keys(“test”)
driver.find_element(By.XPATH, “//button[text()=‘登录’]”).click()
每一行都包含具体的定位方式、具体的操作顺序、具体的数据。页面结构变化，脚本直接碎一地。
问题的本质是测试意图被淹没在实现细节里。你真正想表达的是“输入邮箱并点击登录”，但不得不写出一堆定位器和等待逻辑。
AI Skill的解法完全不同。
它不是用AI帮你生成一段会过时的脚本，而是把AI作为执行层的一个可调用能力。一个登录验证的Skill是这样定义的：
意图：验证邮箱格式校验逻辑
输入：测试邮箱地址
执行：AI理解当前页面结构，动态定位邮箱输入框，输入值，触发校验，读取错误提示
输出：校验结果是否匹配预期
整个Skill里没有任何写死的XPath。所有定位由AI在运行时实时完成。
这个转变的本质是从“步骤驱动”升级到“意图驱动” 。测试工程师不再花时间伺候定位器，而是花时间定义“什么算正确”。
二、脚本维护的本质困局
传统自动化测试有一个天然缺陷：把“做什么”和“怎么做”焊死在了一起。
这不是代码写得差的问题。
Selenium脚本的每一行都在描述“怎么做”——用ID找元素、用XPath找按钮、等待三秒、点击。但“做什么”被淹没在这些实现细节里。维护成本随着UI变动指数级增长。
本质上是抽象层次太低。
传统自动化脚本在三个层面存在根本性脆弱：
脚本与UI强耦合。 页面结构调整，定位器失效。不是脚本逻辑错了，是“路”变了。
异常处理僵化。 脚本只认得预设的路径。页面加载慢了一点、弹窗多了一个、按钮文字改了一个字——全部失败。
维护成本随用例量指数增长。 四百个用例，每个都要单独维护。改一个页面结构，改四百个地方。
这三个问题叠加的结果是什么？
维护工作量占比超过60%，月均脚本失效率高达25%。测试团队不是在写自动化，是在给自动化写“售后”。
另一个层面是范式变化。如果说2023-2024年是AI辅助测试的探索期，那么2025年则是AI深度融入测试全生命周期的转折点，而2026年，AI将从“辅助”走向“主导”。AI智能体将人工智能从被动响应的工具，升级为具备自主规划、推理与协作能力的“决策伙伴”。测试活动将从“脚本驱动”跃迁至“目标驱动”。
三、AI Skill 的工程架构
抛开玄学，AI Skill是一个可调度的、结构化的智能任务单元。
它的内部架构可以拆解成四个工程层：
第一，意图解析层。
接收自然语言或结构化指令。比如“验证登录页邮箱格式校验”，模型把这句话拆解成：目标页(登录页)、动作(输入邮箱并触发校验)、预期行为(显示错误提示)、校验项(邮箱格式)。这一层把人类模糊的描述转成机器可执行的计划。
第二，上下文感知层。
Skill不能盲目操作。它需要知道当前页面长什么样、有哪些可交互元素、每个元素的语义是什么。实现方式通常是抓取DOM树或可访问性树，压缩后注入模型上下文。这是AI定位器能工作的核心——模型不是猜XPath，而是看完整页面结构后推理出最匹配目标语义的元素。
目前主流的实现方式有两种路径：
一种是基于MCP（Model Context Protocol）协议，Playwright和Selenium等主流框架正在引入各自的MCP服务器，通过结构化页面快照让AI理解界面并操作。
另一种是多模态视觉驱动，直接通过截图让视觉模型理解界面布局和元素位置。这种方式不依赖DOM结构，对复杂动态页面适应性更强。
第三，执行调度层。
将解析后的计划转化为具体的浏览器操作。调用Playwright或Selenium的API，执行点击、输入、滚动、等待等动作。这一层还要处理异常——元素没出现怎么办、超时了怎么办、弹窗挡住了怎么办。
第四，校验反馈层。
执行完操作后，验证结果是否符合预期。不是简单的“有没有报错”，而是语义级别的验证——错误提示文案对不对、页面跳转正不正确、数据状态符不符合预期。
这四个层加起来，就是一个完整的AI Skill工程单元。
四、一个登录页面的两种写法
用同一个场景对比，差异会更清楚。
传统脚本方式：
步骤1：打开登录页
driver.get(“ https://xxx.com/login ”)
步骤2：输入邮箱
driver.find_element(By.CSS_SELECTOR, “#email-input”).send_keys(“test@test.com”)
步骤3：输入密码
driver.find_element(By.CSS_SELECTOR, “#password-field”).send_keys(“123456”)
步骤4：点击登录
driver.find_element(By.XPATH, “//button[contains(@class, ‘login-btn’)]”).click()
步骤5：验证跳转
assert “dashboard” in driver.current_url
问题在哪？ CSS选择器 #email-input 可能变成 #email，XPath里的class可能从 login-btn 变成 submit-btn，断言里的 dashboard 可能变成 home。改一个页面，全盘皆崩。
Skill方式：
意图：验证正确邮箱密码可成功登录
前置条件：已注册账号 test@test.com / 123456
验证点：登录后跳转至仪表盘，显示用户名
没有定位器、没有XPath、没有等待逻辑。AI在运行时实时看页面、找元素、执行操作、验证结果。
核心差异：前者让人适应脚本，后者让脚本适应变化。
传统方式追求“精准控制”，适合稳定环境下的高效执行。AI驱动方案通过“智能识别”与“行为模拟”，突破动态页面与复杂交互的限制。
这不是谁更好的问题。传统自动化在稳定场景下依然高效，但维护成本随用例量指数增长。AI Skill在动态场景下优势明显，但引入了模型调用成本和不确定性。
成熟的做法是混合架构：核心稳定流程用传统脚本保证效率，高频变动的UI层用AI Skill降低维护成本。
五、工程落地：从哪开始
如果现在想落地AI Skill，有几个实际问题绕不开。
第一个问题：Skill的粒度怎么拆？
拆得太粗，一个Skill干太多事，不稳定、难调试。拆得太细，Skill数量爆炸，编排成本高。
一个可参考的原则：一个Skill只做一件事，但这件事是一个完整的业务语义单元。比如“登录”是一个Skill，“验证邮箱格式”是另一个Skill。而不是“点击输入框”是一个Skill、“输入文字”是另一个Skill。
第二个问题：稳定性怎么保证？
AI的不确定性是客观存在的。同一个页面，模型这次找到的元素和下次可能不一样。
生产级的做法不是消除不确定性，而是管理不确定性：
设置明确的超时和重试机制
对关键操作做二次确认（比如点击后验证页面变化）
建立降级策略——AI定位失败时回退到传统定位器
记录每次执行的上下文，便于失败后复现
第三个问题：现有的测试资产怎么办？
四百个Selenium脚本不可能一夜之间全部重写。
渐进式迁移是唯一可行的路径：
识别高频失效的用例——这些是AI Skill最有价值的地方
从最核心、最稳定的业务流程开始封装Skill
新功能直接用Skill方式写，老脚本逐步替换
传统脚本和Skill可以共存，通过统一的调度层管理
第四个问题：反馈闭环在哪？
很多团队把Skill当成“高级版的脚本生成器”——生成了、跑完了、结束了。
但Skill真正的价值在于持续进化。每一次执行的成功与失败、定位器的命中与miss、验证的通过与否，都应该回流到Skill的上下文中。失败的案例用来优化prompt和定位策略，成功的案例用来固化经验。
六、你的测试资产还能撑多久
回到开头的故事。
那个通宵改XPath的朋友，后来换了一种做法。他们把登录、注册、下单、支付四个核心流程封装成了四个Skill。页面改版后，不需要改任何代码。AI重新看页面、重新找元素、重新执行。
UI自动化维护时间从4小时压到了15分钟。
这不是个例。已经有团队在把“登录”“下单”“支付”每个步骤变成独立的Skill，让AI根据一句话自动编排执行顺序和传参。
定义Skill者驾驭AI，仅修脚本者将被替代。
招聘市场已经在反映这个变化。AI Agent、RAG、工作流编排这些词正在频繁出现在技术岗的JD里。企业需求正在从“会写代码”转向“会用AI落地业务”。
测试开发尤其需要关注这个趋势。需求分析、用例生成、日志诊断这些高重复、强流程的场景，正在成为Agent落地的最佳入口。
Skill的本质不是一种新技术，而是一种新的工程抽象方式。它把“测试工程师的经验”从代码里抽出来，变成了AI可以理解和执行的“知识”。
你现在维护的那些自动化脚本，有多少是在描述“怎么做”，又有多少是在描述“做什么”？
如果明天页面重构了，你的测试需要改多少行代码？
推荐学习
软件测试开发快速落地智能化测试公开课，从Web/App/接口测试智能体，再到业务测试用例生成，爱测智能化测试平台，手把手带你掌握AI智能体与智能化测试平台！
👇扫码进群，报名学习！
关于我们
霍格沃兹测试开发学社，隶属于 测吧（北京）科技有限公司，是一个面向软件测试爱好者的技术交流社区。
学社围绕现代软件测试工程体系展开，内容涵盖软件测试入门、自动化测试、性能测试、接口测试、测试开发、全栈测试，以及人工智能测试与 AI 在测试工程中的应用实践。
我们关注测试工程能力的系统化建设，包括 Python 自动化测试、Java 自动化测试、Web 与 App 自动化、持续集成与质量体系建设，同时探索 AI 驱动的测试设计、用例生成、自动化执行与质量分析方法，沉淀可复用、可落地的测试开发工程经验。
在技术社区与工程实践之外，学社还参与测试工程人才培养体系建设，面向高校提供测试实训平台与实践支持，组织开展 “火焰杯” 软件测试相关技术赛事，并探索以能力为导向的人才培养模式，包括高校学员先学习、就业后付款的实践路径。
同时，学社结合真实行业需求，为在职测试工程师与高潜学员提供名企大厂 1v1 私教服务，用于个性化能力提升与工程实践指导。