关注 霍格沃兹测试学院公众号，回复「资料」, 领取人工智能测试开发技术合集
目录
- 一、传统自动化脚本，正在被谁吃掉
- 二、Skill到底是什么——本质不是代码，是方法论
- 三、核心机制拆解：Agent、MCP、Skill三层怎么协作
- 四、从案例看变化：Cursor、Money Forward、OpenClaw
- 五、传统自动化框架还剩下什么
- 六、Skill工程师，就是AI时代的测试架构师
- 七、一个值得你想的问题
最近半年，行业里的风向在变。
Claude Code推出了自动决策模式，开始自己决定代码怎么写、文件怎么改。Codex以终端助手的形式回归，可以直接接管编码任务。Cursor在Money Forward落地的数据显示，QA工程师生成测试用例的效率提升了70%。OpenClaw开源用例库在GitHub上冲到335k星标，30个实践场景覆盖社交媒体、内容生产、基础设施运维多个领域。
很多人开始感觉到：以前那些基于Selenium、Appium、Pytest搭起来的自动化测试框架，好像没那么“能打”了。
不是这些工具不行了。你写一个WebDriverWait等着元素加载，AI直接调用Playwright MCP操作整个浏览器。你维护三层的Page Object Model，AI用一个Skill就能完成测试用例生成和执行。从脚本驱动到意图理解——这不是效率提升，这是范式切换。
这篇文章想跟你聊的，就是这个变化背后最核心的东西：Skill技术。
它不是“AI帮你写代码”这么简单。它在重构整个测试流程的组织方式，从写脚本变成搭能力。而传统自动化框架的最后一块领地，正在被它一步步吃掉。
一、传统自动化脚本，正在被谁吃掉
很多测试同学第一次接触AI测试，最容易盯着一个点：AI能不能生成用例？AI能不能写接口脚本？AI能不能操作浏览器？AI能不能帮我分析报告？
这些当然重要，但它们不是核心变化。
真正值得关注的是，AI正在把过去分散的测试动作串起来。
以前做接口自动化，大概是这样的：人读Swagger或接口文档 → 人分析测试场景 → 人写接口脚本 → 人执行脚本 → 人看报错 → 人改代码 → 人再回归。每一步都靠测试工程师手动推进。
现在呢？Agent自动跑完整个链路——规划、生成、执行、修复、沉淀。
这背后不是简单的“AI写代码更快了”，而是软件测试的工作方式正在发生变化。以前自动化测试的核心是写脚本。现在更像是在搭一个能理解任务、能调用工具、能沉淀经验的测试智能体系统。
一个数据能说明问题。Money Forward的工程团队引入Cursor之前，使用其他工具时开发者完全没有感受到明显的时间节省，采用进展基本停滞。引入Cursor后，仅一周内，使用编程智能体的工程师人数就增加了30%。为什么？不是因为“这个AI更聪明”，而是因为它能端到端完成完整的工程任务，而不是只帮你补全一行代码。
更值得留意的信号出现在招聘市场。
今年3月，字节2026年春招中，“测试开发工程师-开发者AI”岗位直接硬性要求：对AIGC技术有一定理解和实践经验的优先，如AI Agent、机器学习、自然语言处理等。阿里“通义实验室-技术专家-测试开发”岗位要求熟练掌握机器学习算法原理和应用。
不是“会写Selenium脚本优先”，不是“熟悉持续集成/持续部署优先”——是“对AI Agent有深入理解和实践经验”、“熟悉MCP协议模型上下文协议者优先”、“有Skill封装和工程化落地能力”。
招聘JD变了，不是行业变卷了。是因为大模型的测试方式，和传统软件测试本质上不是一回事。
能被截图传播的观点句1：AI测试的本质变了——从“验证功能”变成了“验证能力”。
二、Skill到底是什么——本质不是代码，是方法论
Skill这个词最近被反复提及，但很多人还没搞明白它究竟是什么。
简单来说，Skill就是给AI准备的技能包，让AI快速学习使用各种专业技能，而不用每次都重复输入提示词、编写脚本。它的本质是一组结构化的指令和资源，用于教会AI完成特定任务，是一套可复用的规则。
用工程语言翻译一下：Skill就是把“这个场景该怎么测”的过程化经验，封装成一个AI可以调用的能力单元。
软件测试过去有一个很大的问题：经验都在人的脑子里。比如一个有经验的测试工程师看到接口文档，会自然想到：参数为空要不要测？状态码异常要不要测？鉴权失败要不要测？接口之间有没有依赖？前置数据从哪里来？响应字段要不要做结构校验？失败后怎么判断是脚本问题还是接口问题？
这些判断很值钱，但很难复用。新人学起来慢，团队沉淀也难。
Skill的核心价值，就在于把这些经验拆出来，变成可调用、可组合、可复用的能力。
这跟写自动化脚本有什么区别？
写自动化脚本，你是把一个具体场景的执行步骤写成了代码。今天测登录，写登录脚本。明天测注册，写注册脚本。第三天登录的UI改了，改脚本。第四天登录的业务规则变了，再改脚本。
Skill不是这样。Skill封装的是“怎么做测试”的方法，而不是“做哪个测试”的代码。
拿测试用例生成来说。你不需要每次手动分析需求文档、设计边界值、编写用例文本。创建一个Skill，配置好：根据需求文档生成测试用例，覆盖正向、逆向、异常、并发场景。然后一个CMD命令就能跑起来。Cursor上有人用这种方法，10分钟产出可评审的测试用例。生成的用例同时支持excel、markdown、json三种格式输出。
这不是“AI替你工作”的差距。这是“编码vs配置”的差距。传统框架的自动化脚本用代码描述执行步骤，Skill用规则描述测试方法。
三、核心机制拆解：Agent、MCP、Skill三层怎么协作
一个测试智能体通常不是一个大提示词解决所有问题。更合理的结构是三层协作。
看这张图就明白了：
第一层是大模型： 负责理解任务意图。用户用自然语言说“帮我测一下这个登录接口的所有边界情况”，模型先搞明白你在说什么。
第二层是Agent： 负责拆解和调度。它把“测登录接口”这个整体任务，拆成：参数有效性分析→正向用例设计→异常用例设计→执行→结果校验→生成报告。每个子任务再分派给对应的Skill。
第三层是Skills： 负责提供测试方法。接口测试Skill封装了接口测试怎么做。参数边界值的选取策略、状态码的校验规则、响应结构的Schema校验——这些经验全部打包在Skill里。
第四层是MCP（模型上下文协议, Model Context Protocol）： 负责调用真实工具。Skill决定“我需要调这个接口”，MCP负责通过标准协议去调Postman、curl、PostgreSQL或Elasticsearch。
关键点在于：大模型不懂测试，Agent只懂拆任务，Skill才是真正“懂测试”的那一层。核心不在于模型自己会不会测试，而在于你有没有把测试能力工程化封装出来。
落地AI测试最容易踩的坑是什么？只让大模型直接生成用例，效果往往不稳定。只让大模型直接写代码，脚本经常跑不起来。只做一个聊天窗口，最后会变成“问答玩具”。真正能落地的方式，是把测试动作封装成工具，把测试经验封装成Skills，再让Agent负责调度。
能被截图传播的观点句2：AI测试不是把需求丢给大模型，而是把测试流程拆成模型能理解、工具能执行、结果能验证的工程链路。
人工智能技术学习交流群
伙伴们，对AI测试、大模型评测、质量保障感兴趣吗？我们建了一个 「人工智能测试开发交流群」，专门用来探讨相关技术、分享资料、互通有无。无论你是正在实践还是好奇探索，都欢迎扫码加入，一起抱团成长！期待与你交流！👇
四、从案例看变化：Cursor、Money Forward、OpenClaw
光讲原理不够，看几个真实案例。
案例一：Money Forward的QA效率提升70%
Money Forward是一家日本金融科技公司，有1000多名员工每天使用Cursor。
在使用Cursor之前，QA工程师需要手动阅读产品规格说明，为每个用户故事设计测试用例，并编写测试脚本。现在的工作流程是：QA工程师通过MCP将相关的Jira工单和Notion文档提供给Cursor。一个智能体生成结构化测试用例，另一个智能体再将其转换为Playwright脚本。最终测试生成时间减少70%。
但这还不是最重要的变化。最重要的是，QA团队现在把更多时间投入到了软件生命周期更早期的产品质量把控上，重点关注基于风险的测试和质量门禁。QA团队开始用Cursor来分析事故、自动化测试结果，并在开发开始前审查规格说明。
这就是从执行者到决策者的转变。
案例二：Cursor生成移动端测试的局限与应对
Cursor生成的Appium脚本看起来很干净——几行Python代码，找到元素，输入文本，点击按钮，断言显示。但它有一个致命问题：脆。
真实的移动应用存在异步UI加载、资源ID随构建变化、设备云环境不一致、环境漂移等问题。一个在本地Pixel 6模拟器上通过的测试，到了BrowserStack上的物理Pixel 9可能就会失败，因为视图层级变了。
这暴露了什么？单纯依赖脚本生成，哪怕AI写的，解决不了稳定性问题。需要的是在Skill层面封装隐式等待策略、自定义重试逻辑和Page Object模式。换句话说，不是“AI写脚本”不够好，而是“脚本”这个形态本身不够用。
案例三：OpenClaw的开源用例库
OpenClaw的核心价值体现在三个维度：环境感知能力（通过计算机视觉与UI元素识别，无需预先定义控件位置即可操作）、多模态交互（支持语音/文本混合指令）、自主决策系统（内置任务规划引擎，能根据目标动态调整执行路径）。
值得注意的是，OpenClaw在2026年3月的一次版本更新中，因为SDK重构导致微信、企业微信、飞书等插件集体崩溃，全球超3万个实例受影响。一个被无数开发者追捧的AI自动化引擎，一次API变更就让整个生态瘫痪。
这说明一个道理：越智能的工具，系统越复杂，风险越隐蔽。测试工程师的价值不在于执行了多少用例，而在于当AI工具崩了的时候，你能站出来说“我有Plan B”。
能被截图传播的观点句3：传统自动化框架的核心资产是写好的脚本。Skill的核心资产，是封装好的测试专家经验。
五、传统自动化框架还剩下什么
传统自动化框架的核心资产是什么？
是写好的脚本库。一个接口的登录、下单、支付回归脚本，一个模块的1000条UI自动化用例，一个产品的性能压测脚本。这些脚本代表了过去几年的人力投入。
这套体系的弱点在哪儿？
第一，维护成本与代码改动量正相关。 UI改了，定位符全崩。接口改了，断言全崩。业务规则改了，用例逻辑全崩。每一次重构都是对脚本库的一次大手术。
第二，复用单元是脚本，不是能力。 你在A项目写了一套登录的自动化逻辑，到了B项目几乎得重写。不是因为登录业务变了，而是因为框架不一样、命名规范不一样、数据准备方式不一样。
第三，新人上手周期长。 看懂一个项目已有的自动化脚本，比手动测一遍需要的时间还长。测试经验被困在代码里，不是被封装成方法论。
相比之下，Skill方式重构了这个逻辑。复用单元从“脚本”变成“能力”。维护重点从“改代码”变成“更新规则”。沉淀对象从“写死逻辑”变成“可组合技能”。
但这并不意味着传统框架会在一夜之间消失。在稳定不变的核心系统、存量资产巨大的遗留项目、以及对AI安全性有严格合规要求的场景中，传统脚本和断言模型仍然是最可控的选择。
变化正在从边缘进入核心。新项目的自动化测试，你会选择从头写pytest套件，还是配置一套Skill + MCP + Agent的智能测试系统？答案正在变得明确。
六、Skill工程师，就是AI时代的测试架构师
回到开篇的焦虑：当测试用例可以自动生成、脚本可以自动写的时候，测试工程师还剩下什么？
答案是：设计Skill的能力。
未来测试工程师的分水岭，不是会不会用AI，而是能不能把测试经验封装成可复用的工程能力。
一个Skill工程师的核心能力是什么？我把它拆成三条：
能力一：MCP工程化。 理解标准化的连接协议，能把内部测试工具、监控系统、数据源通过MCP接入Agent体系。不是写一个调用脚本，而是搭一个可被调用的服务。
能力二：渐进式Skill封装。 从具体的测试场景出发，提炼出可复用的测试方法论。不是写死了“参数A=1，B=2”的测试用例，而是定义了“当遇到参数边界问题时，应测试最小值、最大值、空值、非法值”的规则。
能力三：反馈闭环设计。 Skill不是一次配完就结束了。执行结果需要流回来，Skill规则需要不断优化。这是一个闭环系统，而不是一次性交付。
三类测试岗位的区别可以画成这样：
| 维度 | 传统测试工程师 | AI测试工程师 | Skill工程师 |
|---|---|---|---|
| 核心工作 | 写用例、跑脚本、报Bug | 调提示词、生成用例、评估结果 | 封装方法论、设计能力体系 |
| 复用粒度 | 用例和脚本 | 提示词模板 | Skill能力单元 |
| 产出形态 | 测试报告 | AI生成结果 | 可被调用的Skill |
| 关注边界 | 正确/错误 | 模型输出质量 | 能力闭环和进化 |
Skill工程师本质上是在做一件事：把“怎么做测试”这件事工程化。他们不是在写测试代码，而是在构建一套让AI能理解、能执行、能进化的测试能力体系。
七、一个值得你想的问题
Skill技术正在改变测试领域的游戏规则。它不是增量上的效率优化——Selenium到Cypress是效率优化，从脚本到能力是范式切换。
这场切换最难的不是技术实现，而是心智转变。很多资深测试工程师积累了厚实的脚本资产，但Skill技术的逻辑是：脚本会过时，方法论不会。
关注开源社区动态的人已经看到，字节、阿里、腾讯在Skill生态上的密集布局已经展开。2026年1月，字节将AI智能体平台“扣子”升级至2.0版本，推出Agent Skills功能；阿里发布“悟空”平台；腾讯上线SkillHub平台聚合超过28000个Skill。
一线互联网公司已经完成概念验证，正在规模化铺开。
还有一个问题留给读者思考，也欢迎在评论区讨论：
你在日常的测试工作中，哪一部分流程是目前自动化脚本最难维护、最耗心力的？如果用Skill的方式——不是写死步骤，而是封装测试方法论——你觉得能让这部分工作量压缩多少？
推荐学习
测试智能体与智能化测试平台公开课， 从架构设计到大厂落地，重塑自动化测试力。
扫码进群，报名学习。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
