你以为在写脚本，其实在造轮子。你以为在复用代码，其实在重复自己。
最近三个月，我跑了四个项目，见了不下二十个测试团队。一个现象越来越明显：大部分人已经在用“Skill”这个概念，但90%的人把它用成了“脚本收集器”。
什么意思？Skill A 测登录，Skill B 测下单，Skill C 测支付。看起来模块化了，但换个环境、换组数据，就要改代码、重新上线、等发布。
这不是Skill，这是换了个名字的脚本。
更麻烦的是，当业务方说“帮我跑一下这十组参数的对比”时，你只能复制粘贴十个Skill，或者写一个循环硬编码进去。一周后需求变了，参数调整，再来一遍。
这已经不是效率问题了，这是工程债务。
今天不绕弯子，直接讲一个我在生产环境落地过的方案：数据驱动Skill。核心目标一句话——一行配置，跑完十组参数，不改代码。
目录
一、当“可复用”变成了“可复制粘贴”
二、本质是配置与执行没有解耦
三、一个数据驱动Skill的核心机制
四、传统脚本 vs 数据驱动：一个真实的压测对比
五、工程落地：三个最容易踩的坑
六、你现在手上那个Skill，数据是写死的吗？
一、当“可复用”变成了“可复制粘贴”
先说一个真实场景。
上个月帮一个电商团队做交付前的最后验证。他们有一个“下单链路Skill”，封装了登录、选品、加购、下单、支付五个步骤。听起来很标准。
但当我问“你们怎么测试不同用户类型（新客、老客、会员、黑名单）的下单表现”时，负责人愣了一下，然后打开了一个文件夹。
里面有七个版本的下单Skill：
order_flow_new_user
order_flow_vip
order_flow_blacklist
order_flow_guest
……
每个Skill代码逻辑完全一样，区别只在三个地方：用户类型、优惠券规则、超时时间。
这不是复用，这是复制粘贴的升级版。
问题出在哪？他们把“参数”写死在了Skill内部。每次新增一组参数，就要新建一个Skill。每个Skill都要走完整的发布、部署、测试流程。到最后，维护成本已经不是O(n)，而是O(n²)。
这个团队不是个例。大多数人设计Skill时，默认把“数据”和“逻辑”绑在一起。因为一开始只跑一组参数，觉得没必要拆。等项目扩展到十组、二十组参数时，已经改不动了。
本质不是Skill这个工具不行，是设计思路还停留在“脚本思维”阶段。
二、本质是配置与执行没有解耦
拆开看，一个Skill无非做两件事：
拿到数据（参数）
按逻辑执行（步骤）
脚本思维的做法：数据写在代码里。
数据驱动的做法：数据写在配置里，代码只管执行。
这两者的差异，在项目规模小的时候几乎看不出来。三五个参数，写在代码里反而更直接。但一旦进入以下任何一种状态，差别就是天壤之别：
参数组合超过10组
参数需要频繁调整（一周一次以上）
不同环境需要不同参数集（开发/测试/生产）
业务方需要自己改参数，不能碰代码
本质上是变化频率不同。业务参数以天为单位变化，执行逻辑以月为单位变化。把它们写在一起，就是在用低频的发布节奏去应对高频的变化需求。
核心解决思路只有一个：让Skill接收一个标准化的输入结构，内部只处理“怎么执行”，不关心“执行什么”。
三、一个数据驱动Skill的核心机制
直接上设计。这是一个我在生产环境验证过的三层结构。
配置层：只存数据，不存逻辑。每一组参数是一个独立的条目，包含标识、输入值、期望结果、环境标记。
解析器：负责读取配置，做基础校验（参数类型、必填项、范围），然后逐组喂给执行引擎。这一层不做业务判断，只做格式转换。
执行引擎：Skill的真正逻辑。它不关心数据从哪来，只关心当前拿到的这一组参数是什么，然后按步骤执行。同一个引擎，可以跑配置里的第1组，也可以跑第10组。
结果收集器：把每一组参数的执行结果单独记录，最后按配置分组输出对比报表。这一步很多人忽略，但恰恰是数据驱动Skill的价值放大器——你不仅能跑多组参数，还能直接看到哪组参数触发了什么行为。
落地时最关键的三个设计决策：
- 参数协议要固定不论底层是什么格式（YAML、JSON、Excel），Skill入口只认一种结构。我通常用JSON Schema约束，比如：
{
"caseId": "TC001",
"params": {"userType": "vip", "timeout": 30},
"expect": {"code": 200, "maxDuration": 25}
}
执行引擎要做成无状态的同一Skill实例可以顺序跑完10组参数，每组之间重置上下文。否则第一组残留的变量会影响第二组。
配置要支持覆盖全局配置 + 局部覆盖。默认超时30秒，但某组特殊参数需要60秒，在那一组单独写即可，不用复制全量配置。
四、传统脚本 vs 数据驱动：一个真实的压测对比
两个月前，一个做金融服务的团队找到我。他们的场景：需要验证同一个风控Skill在100组不同用户画像下的表现（年龄、额度、历史逾期次数等参数组合）。
传统做法：写一个for循环，在Skill内部遍历参数列表。代码量不大，但问题在后期。
跑完一轮后，发现其中第37组参数触发了超时。开发要调试，但日志里看不到这组参数的上下文——因为for循环把所有输出混在一起了。他不得不重新跑一遍，人工盯着第37组打日志。
前后折腾了三个小时。
换成数据驱动Skill之后：
100组参数写在一个Excel里，业务方自己维护
Skill逐组执行，每组独立输出日志文件，文件名包含caseId
执行完成后，结果收集器自动生成一个对比表：哪几组通过，哪几组失败，失败时的具体参数是什么
问题定位时间从三小时降到五分钟。
观点句：数据驱动Skill带来的不是写代码的速度提升，而是问题定位效率的指数级改善。
另一个被很多人忽略的收益：业务方可以自己调参。
那个金融团队的业务分析师，后来自己改Excel里的参数组合，跑回归验证。全程没找开发。这不是因为业务分析师突然会写代码了，而是因为Skill的入口足够简单——一个配置文件。
观点句：衡量一个Skill是否真正做到数据驱动，就看业务方能不能不改代码就完成一次参数变更。
五、工程落地：三个最容易踩的坑
说完了怎么设计，说三个我在落地过程中亲眼见过的坑。
坑一：配置文件越来越膨胀，变成另一个维度的意大利面
当参数组合达到上百组时，一个YAML文件会变得很难维护。这时候不要硬撑，要引入配置分层：按业务模块拆分文件，Skill启动时动态加载。
本质是：数据驱动Skill也需要分层设计。 配置本身也是工程产物，不是纯文本。
坑二：忽略参数之间的依赖关系
有时候第5组参数依赖第2组执行过程中产生的某个值。如果把参数组完全独立，这种依赖就断了。
解决方案是在参数协议里增加一个字段dependsOn，指向另一组的输出。执行引擎需要具备简单的依赖解析能力。
但这个功能慎用。我的原则是：能并行的不要串行，能独立的不要依赖。依赖越多，数据驱动的价值就越被稀释。
坑三：结果收集做成了日志堆砌
很多人跑完十组参数，输出是十个日志文件，然后就没有然后了。
结果是数据驱动Skill的闭环。没有结构化的结果对比，你就没法回答“哪组参数最好”“哪个阈值最稳定”这类问题。
我的做法：结果收集器除了落日志，还要输出一个CSV/JSON格式的汇总表，包含每组参数的输入、输出、耗时、状态码。这个表可以直接导入BI工具，或者喂给下一个Skill做二次分析。
观点句：没有结果对比的数据驱动Skill，只是一个高级版的for循环。
六、你现在手上那个Skill，数据是写死的吗？
回到开头的那个问题。
Skill本身不是什么新概念。但大部分人设计Skill时，默认把它当成“逻辑封装单元”。很少有人主动问一个问题：数据和逻辑，要不要分开放？
不是所有场景都需要数据驱动。如果你只有一组参数，半年不变，写在代码里完全没问题。
但如果你已经开始出现：
多个参数相近的Skill副本
业务方频繁找你改参数
跑多组对比时需要手动改代码
不同环境需要不同参数集
那数据驱动就不是一个“高级特性”，而是一个必选项。
最后留一个思考。
你去看一下你们团队现在最常用的那个Skill。把代码里所有业务参数（URL、超时、用户类型、阈值、开关）都抽出来放在一个配置文件里。在不改Skill代码的前提下，换三组不同的参数运行。
它能跑通吗？
如果能，恭喜你。如果不能，可以想想——问题出在Skill的设计上，还是你们的发布流程限制了配置的独立变更？
这两个问题的答案，指向的是两种完全不同的改进路径。
