最近在测试群里看到两个画风截然不同的帖子。
一个发的是“今天用Cursor写了个脚本，解决了接口测试的数据准备问题”，底下跟了一堆技术讨论。另一个发的是“我用自然语言描述了一个流程，AI帮我打包成了Skill，同事直接复用”，底下清一色的“这是啥玩意”。
注意到没？当一部分人还在学习用AI写脚本的时候，另一部分人已经开始“教AI怎么帮别人写脚本”了。从“用AI干活”到“把能力封装成AI能反复用的技能包”——这个跃迁，很多人已经完成了。
测试圈一直有一种声音：Skill这东西，得会写代码，得懂CLI，得能折腾。是工程师的专属玩具。普通测试人员玩不转。
低代码+AI，正在把这道墙拆掉。
进入2026年，Skill开发的门槛正在以肉眼可见的速度下降。JeecgBoot这种低代码平台直接接入AI Skills，号称“零代码模式：一句话即可搭建完整业务系统，无需编写任何代码”。OpenClaw这种AI数字员工，全程可视化部署，零代码、一键启动。
而Claude官方推出的Skill-Creator，更是让非技术背景的领域专家也能开发高质量AI技能，全程不用写一行代码。
这些工具放到测试场景里意味着什么？意味着你的测试经验——哪怕你不会写代码——也可以变成可以被AI理解、执行和复用的能力单元。
这篇文章不讲空概念，讲我最近亲测的一条路：不用写代码，怎么把一个测试流程变成Skill。
目录
一、Skill开发的门槛，到底高不高？ 二、本质变化：从“写代码”到“描述流程”的能力转移 三、核心机制：Skill封装的四层结构 四、典型案例 / 对比：用低代码+AI做跨接口测试Skill 五、工程落地启示：对测试人有什么实际用处 六、趋势判断：Skill会成为下一代能力资产
一、Skill开发的门槛，到底高不高？
先说答案：比想象的低得多，但赛道已经不太一样了。
2025年12月，Anthropic把Agent Skills发布为开放标准。一套标准化的文件夹规范，让Agent像装App一样加载专业技能。每个Skill文件夹里有一份SKILL.md，写清楚这个技能是什么、怎么用，还可以放可执行脚本。标准一出，行业跟进速度异常快，Microsoft在VS Code和GitHub里直接集成，OpenAI在ChatGPT和Codex CLI里也采用了类似架构。
但问题也随之而来。
Skill-Creator刚上线时，第一周就有开发者专门观察了100多个用户的使用情况，结论是“大多数实现看起来更像玩具而不是工具”——Skill该触发时不触发、指令太多导致Agent混乱，大量槽点。真正好用的Skill，依然靠人工打磨。
然而到了2026年3月，形势发生了明显变化。Anthropic发布Skill-Creator 2.0，升级了AI Agent技能自动生成与管理工具。新增的评估系统，让Skill在发布前就能得到系统性的质量验证。
与此同时，JeecgBoot低代码平台正式推出AI技能体系，提供零代码和代码生成两种模式。这已经不是“能用”层面的小改进，而是让Skill开发从“工程师专属”走向了“领域专家可用”的赛道切换。
但这里有一个容易被忽略的分界线：市面上很多“零代码”方案，本质是把底层的代码生成封装掉了，用户依然需要理解Skill的结构逻辑。真正的低代码 Skill 开发，核心不是去掉了什么，而是改变了什么——把写代码这件事，换成了描述流程这件事。
二、本质变化：从“写代码”到“描述流程”的能力转移
为什么Skill开发的门槛可以降下来？核心变化在于能力重心的转移。
传统方式下，开发一个自动化能力需要写脚本、配置工具、处理异常。技能被封在代码里，改不了、看不懂、没法分享。
Skill的本质不一样。它是一份“SOP（标准作业程序）的数字化表达”。Agent Skills的本质是程序性知识封装——在推理阶段增强大语言模型能力的一组结构化指令。核心机制用一句话说：Skill是“给工具让AI自由发挥”，而不是“规定每一步该怎么走”。
传统方式
你的知识 → 你需要写代码 → 代码执行
↑ ↑
经验 技能门槛
Skill方式
你的知识 → 你描述成SOP → AI按SOP执行
↑ ↑
经验 学习描述能力
这就是能力重心的转移：过去掌握编程语言、框架和工具链是核心能力，现在核心能力变成了理解业务流程、抽象问题、设计规则体系、写清楚指令。
Skill-Creator 2.0之所以是一个里程碑，正是因为它把“怎么写指令”这件事流程化了。借助其内置的评估系统，非技术背景的领域专家也能验证技能效果。比如Anthropic官方的brand-guidelines Skill，仅凭一份文档定义品牌颜色、字体规范，AI就能自动设计符合品牌调性的内容。
回到测试场景——测试工程师最擅长的就是写测试SOP和验收标准。把这些SOP结构化地写进SKILL.md，不就是AI能读懂的技能包吗？
可被截图传播的观点句： Skill就是把你的专业知识翻译成AI能读懂的SOP。会不会写代码，没那么重要。
三、核心机制：Skill封装的四层结构
理解了本质变化，再来看Skill是怎么实现“低代码封装的。
这要从Claude Skill的架构说起。它的设计并非凭空创造，而是有深厚的技术渊源。早在1999年，Rich Sutton等人就提出了options framework的理论框架，核心思想是Agent应该能自己发现和组合可复用的行为模块。但那个时代的Skill困在神经网络权重里，不可解释、不可迁移。直到2023年，Voyager项目把Skill从权重拉到了代码里，才真正让Skill变得可解释、可编辑、可组合。
Skill-Creator在这一基础上更进一步。目前的SKILL.md源码约485行，与其说它是一个文档模板，不如说它是一套完整的“AI技能工程化系统”。
它的四层结构是：
第一层是触发。Skill-Creator 2.0升级了评估系统，可以自动测试Skill是否在正确场景被触发，大幅降低了调试成本。
第二层是业务逻辑封装。在SKILL.md中写入执行规范和标准，这是核心所在。
第三层是资源层。对于需要代码落地的场景，Skill-Creator会自动生成配套的代码模板、脚本和配置。在JeecgBoot这样深度融合的低代码平台中，生成的不只是代码片段，而是完整的前后端代码、数据库迁移脚本和菜单权限配置。
第四层是按产出物形态输出最终产品。
从编程黑箱到可读SOP，再通过低代码生成方式打包成Skill——这条链路打通之后，Skill开发的技术壁垒就已经被拆得差不多了。
可被截图传播的观点句： Skill-Creator的价值不是帮你写代码，而是帮非工程师建立测试Skill的工程思维。
人工智能技术学习交流群
伙伴们，对AI测试、大模型评测、质量保障感兴趣吗？我们建了一个 「人工智能测试开发交流群」，专门用来探讨相关技术、分享资料、互通有无。无论你是正在实践还是好奇探索，都欢迎扫码加入，一起抱团成长！期待与你交流！👇
图片
四、典型案例 / 对比：用低代码+AI做跨接口测试Skill
既然理论上说Skill的门槛已经很低了，那我们来看个实际的对比：用一个跨接口测试用例生成来测试。
场景描述： 一个电商场景的接口测试——用户登录→获取商品列表→加入购物车→生成订单。传统方式下，测试人员需要手写4个接口的调用代码，处理Token传递和数据依赖，还要写断言。
传统方式的痛点：
需要熟悉接口框架和签名机制
需要手动管理中间变量的传递
新增接口组合时，需要重新组合代码逻辑
业务团队提需求时，技术实现的理解偏差
用低代码+AI Skills的方式：
我直接在JeecgBoot这类集成了AI Skills能力的低代码平台中，用以下自然语言触发：
“帮我生成一个完整的API测试Skill。包含这些步骤：1.调用登录接口获取token 2.调用商品列表接口 3.调用加入购物车接口 4.调用生成订单接口。每个步骤都需要传递上一步的返回信息作为下一步的参数。”
AI Skills在接收到指令后，会做以下事情：
首先是表结构和依赖推导。AI会自动分析各个接口的依赖关系，识别token需要在哪个字段传递，购物车接口需要商品id作为参数，订单接口依赖用户身份。JeecgBoot的做法是，AI会自动完成表结构推导——包括字段名、数据类型、长度、前端控件类型的智能推导。
然后是批量生成。如果一个业务模块涉及4个接口，AI可以一次性完成所有接口脚本的生成。Jeecg的AI代码生成支持一次性描述整个模块的需求，批量生成所有接口脚本。
接着是智能匹配与自动归位。Skill-Creator会检查现有的接口库、常量定义和配置，自动匹配已有的域名、超时设置、公共函数。生成的代码还能自动放到项目里正确的目录位置——接口定义放service层，测试用例放test目录，配置文件放config文件夹。
最后是异常场景的增量补充。Skill支持精确的增量修改：加字段、调整依赖顺序、补充错误重试逻辑，AI只会改动必要的部分。
一个Skill完成，这个完整的接口测试链路就封装好了。团队里任何成员下次需要针对同一套API做回归测试时，直接一句话触发即可。
对比下来，差异很明显：
传统方式：4个接口，手写约30行核心代码加断言，写了半小时。测试人员需要思考异步等待和数据处理细节。切换业务时，大部分需要重写。
低代码+AI方式：自然语言描述需求。Skill自动解析依赖关系，AI按SOP批量生成代码。接口组合发生变化时，修改Skill的SOP描述即可，AI自动批量更新。
差距的核心不是代码量的降低。而是——传统方式里，知识锁死在代码逻辑里，离开代码就会失效。而Skill方式里，知识被编码成了SOP，可以被审阅、修改和传递。
五、工程落地启示：对测试人有什么实际用处
说完案例，聊点实际的：测试工程师到底怎么把Skill用起来。
Skill在测试领域最直接的落地场景是测试规约统一。Skill本质上是一个Markdown格式的、版本控制的知识模块，编码了自动化所需的方法论、命名规范、Page Object规则、定位器策略、断言方法和验收标准。AI生成脚本时，直接读取Skill中的方法论、执行在线DOM侦测、应用团队既定的架构和验证清单，最终产出符合规范的测试代码。
对测试工程师来说，这意味着三个实实在在的价值：
第一，沉淀团队测试经验。团队里资深成员的测试思路、边界值策略、特殊场景设计，不再需要反复口头传授或写成冗长的文档。打包成一个Skill，任何人都可以复用。Skill是一次封装、终审复用的测试经验包。
第二，规范测试生成质量。Skill-Creator内置了评估系统，在Skill发布前就可以自动测试效果，打破了以往写好Skill就无法验证、更新后无法保证不变的僵局。
第三，降低新成员的培训成本。新人接手新项目时，过去要啃需求文档和代码结构，花数周才能独立产出符合规范的测试脚本。当团队把这套标准封装为Skill之后，AI会帮新人直接生成符合规范的代码，人只需要review逻辑是否正确。
中国信通院2026年4月已经启动了可信技能治理首批测试评估工作，跨越Skills治理、Skills库治理和智能体Skills治理等方向。这个信号表明，Skill作为能力资产，已经进入产业化治理阶段。对个体测试工程师而言，谁先建立体系化的Skill开发能力，谁就掌握了一种未来式的能力资产。
六、趋势判断：Skill会成为下一代能力资产
最后聊一下趋势，也是给中级工程师的方法论升级。
观察整个2026年的行业变化，Skill开发正在形成两条路径：一条是面向工程师的标准化开发路径，包括Agent Skills开放标准、Skill-Creator 2.0的工具链升级；另一条是面向领域专家的低代码封装路径，也就是JeecgBoot、OpenClaw这类平台推进的自然语言式Skill生成。
两条路径指向同一个方向：Skill开发正在从“少数人掌握的技能”变成“多数人能够使用的能力”。
Skill和MCP的关系也在变得清晰。MCP是标准化协议层，实现跨模型兼容的标准化接口调用。Skill是能力包，不只包含工具调用方法，还封装了完整的专业知识、执行逻辑和资源素材。Skill建立在MCP上，为开发者提供更具象的AI辅助开发体验。
低代码+AI的Skill开发，现在确实还有坑。
Skill-Creator 2.0虽然引入了评估系统，但Skill的有效性仍然高度依赖SOP描述的精确度。JeecgBoot这类深度融合的Skill平台虽然强大，但其技能主要围绕自身的低代码设计器展开，迁移到其他平台的成本较高。信通院2026年4月启动的评测工作也侧面印证了公域Skill质量的参差不齐。
与此同时，顶级Agent框架在SWE-bench Verified榜单上解决真实问题的比例已从2023年的48.5%跃升至2026年的78.8%。基础的代码生成已经不足以拉开差距了。技能封装的理解，才是下一阶段分水岭。
回归测试工程师群体自身：Skill的力量也许不在于帮你产出一个即刻的脚本，而在于让你可以从SOP描述的角度去标准化自己的测试思路。这个过程本身，就是对你知识体系的一次梳理和重构。
留给你的问题：
在UI自动化测试、接口测试或者性能测试工作中，如果让你挑选其中一个最复杂但最长尾的环节来封装成Skill，你会选择哪个环节？瓶颈在哪里——是SOP本身不清晰，还是工具集成上有困难？
