三个月前，一个测试主管给我看他们的自动化代码。
登录、加购、下单、支付、退款，五个核心流程，写了四十多个脚本。不是写错了，是排列组合。登录方式三种，商品类型四种，支付渠道两种，再加上优惠券、地址、库存边界——线性的业务步骤，变成了爆炸的场景矩阵。
他说，我们维护的不是脚本，是笛卡尔积。
我问，为什么不动态编排？他说，太难了。步骤之间有数据依赖，每一步的输出是下一步的输入。登录拿token，下单拿订单号，支付拿支付ID。硬编码还能跑，想灵活组合，数据链路就断了。
上个月，我用一套基于Skills+大模型的方式，把这个场景跑通了。不是写更多脚本，是把“登录”“下单”“支付”每个步骤变成独立的Skill，然后让AI根据一句话自动编排执行顺序和传参。
比如输入“用手机号登录，买一件普通商品，用微信支付”，AI自动调用对应Skills，链路自动串起来。换一种组合“用账号密码登录，买两件会员商品，用余额支付”，同样通。
本质上，我们把测试执行从“代码”上升到了“意图”。
目录
一、业务流程测试的三种死法
二、AI编排不是生成脚本，是生成执行计划
三、三层模型：Skill仓库、调度器、数据总线
四、一个下单流程的AI编排实录
五、工程落地的四个关键判断
六、把最复杂的流程拆成Skills，你敢不敢试？
一、业务流程测试的三种死法
先不聊AI。聊一个现实问题。
任何一个业务系统，核心流程都是有限的几个：登录、下单、支付、退款、发货。但每个流程有多个变体。登录有手机号、邮箱、扫码、第三方。下单有普通商品、虚拟商品、预售商品。支付有微信、支付宝、银行卡、余额。
当你写自动化用例时，通常的做法是：针对每一种组合，写一个脚本。登录-普通商品-微信支付是一个脚本，登录-会员商品-余额支付是另一个脚本。
这套做法会导致三种死法。
第一种死法：组合爆炸。3种登录×4种商品×3种支付 = 36个脚本。每个脚本里80%的代码都是重复的（获取token、解析订单号、等待回调）。但这些代码又不敢随便复用，因为细微的参数差异会藏在脚本深处。
第二种死法：变更蔓延。登录接口改了一个字段，36个脚本全部要改。不是不能改，是没人愿意改。最后结果就是脚本逐渐变红，然后没人修，然后整个自动化弃用。
第三种死法：新场景加不进去。产品经理说，我们要支持“先下单后登录”的模式。你看着已有的36个脚本，发现数据依赖全是基于登录在前。重构数据链路？成本够开一个新项目。
这三种死法的共同根源是什么？
本质是：我们把业务流程的“骨架”和“血肉”混在一起写了。 骨架是步骤之间的顺序与数据传递，血肉是每个步骤的具体实现。传统脚本里，这两者耦合在代码行里。
AI编排想解决的事很单纯：把骨架交给AI动态生成，血肉做成独立可复用的Skill。
二、AI编排不是生成脚本，是生成执行计划
很多人听到“AI自动编排”，第一反应是让大模型直接写测试脚本。然后跑一下，发现生成的脚本要么调不通，要么断言错，要么用了不存在的变量。
这条路走不通，因为大模型不擅长精确的代码逻辑和运行时状态管理。
正确的做法是：让大模型输出一个“执行计划”，而不是代码。执行计划是一个JSON结构，描述了Skill的调用顺序、输入参数如何从上一步的输出中提取、以及预期结果如何校验。
举个例子。用户说“用手机号登录，买一件普通商品，用微信支付”。
大模型不需要知道怎么调登录接口，不需要知道订单号的JSON Path是什么，更不需要知道支付回调的轮询逻辑。它只需要输出：
{
"plan": [
{"skill": "login_by_phone", "inputs": {"phone": "13800138000", "pwd": "xxx"}, "outputs_as": "token"},
{"skill": "create_order", "inputs": {"token": "$token", "product_type": "normal", "quantity": 1}, "outputs_as": "order_id"},
{"skill": "pay_by_wechat", "inputs": {"token": "$token", "order_id": "$order_id"}, "outputs_as": "pay_result"}
],
"asserts": [
{"step": "pay_by_wechat", "field": "pay_result.status", "expected": "SUCCESS"}
]
}
这个计划是确定性的，可执行的。大模型只负责两件事：根据用户自然语言匹配对应的Skill，以及推断数据依赖关系（比如pay_by_wechat需要order_id，而order_id来自上一步）。
有了执行计划，剩下的全交给一个轻量级的执行引擎。引擎负责调用Skill、管理变量作用域、做断言、处理重试和超时。
核心在于：大模型的输出空间被约束在一个很小的、结构化的执行计划上。 这不是代码生成，这是决策生成。成功率比直接生成脚本高一个数量级。
观点句1：
AI编排的本质，是把测试执行从代码生成转变为计划生成。代码的确定性交给引擎，大模型只做它最擅长的语义匹配和依赖推断。
三、三层模型：Skill仓库、调度器、数据总线
要做到上述编排，需要三层架构。下图是完整设计。
Skill仓库
每个Skill是一个独立的功能单元。它有明确的三要素：
输入规格：需要哪些参数，类型是什么，是否可选
输出规格：会产出哪些变量（如token, order_id, pay_id）
执行体：实际的HTTP请求、数据库查询、等待逻辑等
Skill可以用任何语言实现，只要暴露统一接口。我们内部用Python函数包装，装饰器声明输入输出元数据。
登录Skill的定义示例：
@skill(
name="login_by_phone",
inputs={"phone": str, "password": str},
outputs={"token": str, "user_id": int}
)
def login_by_phone(phone, password):
resp = requests.post("/api/login", json={"phone": phone, "pwd": password})
return {"token": resp.json()["access_token"], "user_id": resp.json()["uid"]}
LLM Planner
Planner收到自然语言指令后，首先从Skill仓库拉取所有Skill的名称和输入输出描述（不需要实现细节）。然后构造一个提示词，要求模型输出一个执行计划。
提示词的核心是一组约束：
只能使用仓库里存在的Skill
每个Skill的输入必须能从已有变量或用户输入中解析
计划必须是有向无环图（不能循环依赖）
最后必须包含断言步骤
模型返回JSON后，校验器会做类型检查和依赖完整性检查。发现缺失依赖或Skill不存在，就拒绝执行并返回错误提示。
执行引擎与数据总线
执行引擎很简单：按顺序遍历计划中的每个Step，调用对应Skill，将返回的outputs写入数据总线（一个字典存储）。后续Step中遇到$变量名，就从总线中替换。
数据总线还支持简单的表达式，如$order_id、$token.user_id（嵌套取值）。这比让大模型处理复杂路径可靠得多。
断言引擎在每一步后或整体结束后执行，根据plan中的asserts配置做校验。
整个架构的核心优势：新增一个业务流程，不需要写脚本，只需要注册一个新的Skill。 而Skill的粒度可以很小（比如“获取商品详情”“解析优惠券”），组合由AI动态完成。
观点句2：
当业务流程被拆解为原子Skill，测试维护的成本就从O(场景数)降到了O(Skill数)。后者通常比前者小两个数量级。
四、一个下单流程的AI编排实录
拿一个真实业务举例。
技能仓库里有这些Skill：
login_phone：手机号登录，输出token
login_email：邮箱登录，输出token
select_product：按类型选择商品，输出product_id和price
add_to_cart：加购，输出cart_id
create_order：下单，输出order_id
pay_wechat：微信支付，输出pay_result
pay_balance：余额支付，输出pay_result
check_order_status：查询订单状态，输出status
传统做法：写一个test_login_phone_select_normal_add_cart_create_order_pay_wechat脚本，大概150行。再写test_login_email_select_vip_add_cart_create_order_pay_balance，又一个150行，大部分重复。
Skills-first做法：
测试人员输入自然语言：
用邮箱登录，选择会员商品，加到购物车，下单，用余额支付。最后检查订单状态是PAID。
LLM Planner输出：
{
"plan": [
{"skill": "login_email", "inputs": {"email": "test@test.com", "pwd": "123"}, "outputs_as": "token"},
{"skill": "select_product", "inputs": {"type": "vip"}, "outputs_as": "product"},
{"skill": "add_to_cart", "inputs": {"token": "$token", "product_id": "$product.id", "quantity": 1}, "outputs_as": "cart"},
{"skill": "create_order", "inputs": {"token": "$token", "cart_id": "$cart.id"}, "outputs_as": "order"},
{"skill": "pay_balance", "inputs": {"token": "$token", "order_id": "$order.id"}, "outputs_as": "pay"},
{"skill": "check_order_status", "inputs": {"token": "$token", "order_id": "$order.id"}, "outputs_as": "status"}
],
"asserts": [
{"step": "check_order_status", "field": "status", "expected": "PAID"}
]
}
执行引擎跑完，全绿。
第二天需求变了：先登录，直接下单（不经过购物车），用微信支付。测试人员输入：
手机号登录，选普通商品，直接下单，微信支付，检查订单状态。
Planner重新生成计划，这次跳过了add_to_cart Skill，直接create_order接收product_id。不需要改任何代码，不需要写新脚本。
更极端的情况：产品经理说支持“游客先下单，后登录”。怎么测？
输入：
不登录直接下单商品，得到订单号，然后用手机号登录，再用登录后的token去支付这个订单。
Planner分析依赖：create_order在不传token的情况下是游客模式，输出order_id。然后login产出token，最后pay需要token+order_id。计划自动生成，数据链路自动打通。
这在传统脚本里几乎是灾难级的重构。但在Skill模式里，只是AI换了几个Skill的串联方式。
观点句3：
当数据依赖由AI推断而非人工编码时，业务变更对测试的影响就从“改脚本”变成了“改自然语言”。
五、工程落地的四个关键判断
这套模式听起来不错，但落地时有不少坑。我踩了四个，总结成四个判断，帮助你决定要不要做、怎么做。
判断一：你的业务步骤是否足够原子？
Skill的粒度不能太大，否则复用性差。比如“完成下单”本身包含加购、地址验证、库存锁定、生成订单，如果做成一个Skill，就无法灵活跳过加购或换支付方式。
但也不能太小。比如“提取HTTP响应头”这种，不值得做成Skill，因为太琐碎会爆仓库。
我们的经验：Skill应该对应一个“用户可感知的业务动作”，比如登录、选商品、支付。内部HTTP请求的细节不属于Skill范畴。
判断二：你的数据依赖是否复杂到AI拼不出？
如果两个Skill之间的数据依赖不是直接的字段传递，而是需要复杂计算（比如根据商品价格计算满减后的实付金额），AI很难凭空推断。这时需要在Skill的输入规格里声明“计算逻辑由调用方提供”或者单独做一个“金额计算”Skill。
更实用的做法：允许执行计划中插入一段简单的Python表达式，而不是全部交给AI。混排模式往往更稳健。
判断三：你能接受AI偶尔瞎排吗？
大模型会出错。比如它可能把pay_wechat和pay_balance都塞进计划，而业务上只能二选一。或者它忘记加断言，导致执行完不校验结果。
解决方式两重：第一层是计划校验器，写一些规则（“支付类Skill只能出现一次”“必须有至少一个断言”）。第二层是人工复核界面，复杂计划可以展示给测试人员确认后再执行。
判断四：现有测试资产如何迁移？
不要推倒重来。我们做了一件事：把一个现有的、稳定的登录脚本直接封装成第一个Skill。然后跑通一个最简单的场景。然后逐步把其他脚本里的重复逻辑拆出来，注册为新Skill。
迁移周期大概两周，期间新旧模式并行。等80%的核心Skill都有了，旧脚本就可以退休了。
六、把最复杂的流程拆成Skills，你敢不敢试？
回到开头那个测试主管的问题。他的四十多个脚本，最后被拆成了11个Skill。新增一个支付渠道，只需要写一个新Skill，然后告诉AI“用新渠道支付”。不需要改其他任何东西。
两个月后，他团队的脚本维护时间下降了70%。不是因为他们写了更多代码，而是因为代码变少了，变活了。
现在换到你的项目。
你手上最复杂的那条业务流程，比如涉及到五个系统、十几个步骤、七八种分支。把它拆成Skill，你觉得会拆出多少个？哪个步骤是最难原子化的？
不用回答我。在评论区写下来，就当是给自己的一次架构推演。
如果你已经拆完了，再问自己一个问题：这个Skill列表，AI能在不看代码的情况下，仅凭名字和输入输出描述，就正确拼出你脑海中那条最复杂的路径吗？
如果答案是否定的，你的Skill设计还需要再调整。
我等着看你们的答案。
