UI自动化测试提效必备Skill！一套CI流水线编排 Skill 可以直接抄了...

大家好，我是狂师。

前三篇，我们把 UI 自动化的三个环节逐个交给了 AI。「跑测试」有了 ui-test-executor，「修脚本」有了 ui-failure-diagnoser，「出报告」有了 ui-report-generator。

每个环节单拎出来都能打。但真用起来，你会发现一个新的问题。

跑一轮完整测试，你得先调用一次执行技能，跑完看一眼结果，再调用一次报错修复诊断技能，修完再重跑一次执行技能，最后再调用报告生成技能。一条链，人要调用四次 AI，中间还得自己判断衔接时机。

活是 AI 干的，链子是人串的。人的注意力，还是要被拴在这条链上。

写在前面

这个系列一直在做一件事，用 Agent Skill 把 UI 自动化测试的各个环节逐个自动化。

到上一篇为止，环节级的 Skill 都齐了。执行有证据，失败有结论，报告有判断，单点能力全部到位。

缺的是一个把它们串起来的东西。什么时候执行、失败了要不要诊断、修完要不要重跑、重跑几轮、结果怎么算，这些环节之间的决策，之前都靠人临场判断。

所以这个系列收官的一篇，我做了 ui-pipeline-scheduler，一个全链路统一编排的 Skill。它不当球员，只当指挥，把前面几个 Skill 编排串联成一条自动化流水线。

本篇就聚焦这个 Skill，从它面对的问题讲起，到它怎么解决，再到实战跑一遍。

有了独立执行的 Skill，为什么还需要编排

把「人工串联」这件事拆开来看，问题往往集中在几个主要地方。

1、一条链，Skill要单独执行四次。

执行、诊断、重跑、报告，每一步都是单独发起。测试同学反而变成了 AI 之间的传话筒，一条链跑下来，切换十几次窗口。

2、衔接时机，靠人盯。

跑完要看一眼有没有失败，有失败才调诊断；修完要看一眼修没修好，修好了才值得重跑。每一步的「下一步」都要人来判断，人一走开，链就断。

3、重试几轮，没有规矩。

修一轮跑一轮，挂了再修再跑。什么时候算够？没有上限就是死循环，上限拍脑袋，修不好的用例照样耗时间。

4、多轮结果，相互冲突。

重跑通常只跑失败的那几条，新的执行结果会把旧的覆盖。首轮 8 条用例，重跑 3 条之后，结果文件里只剩 3 条。拿这个直接出报告，数字全是残缺的。

5、中途出错，整链报废。

诊断环节报个错，后面全部断掉，前面跑的结果也顾不上收。要么从头再来，要么手工拼凑。

6、接不进 CI。

流水线要的是单入口、一条命令。几个技能都是人工操作，CI 里根本没法落地。

这几件事有个共同点。顺序是固定的，条件是明确的，边界是清晰的。全是 AI 擅长的活。

那能不能让 AI 把「串链子」这一步也接管了？

答案是，可以。而且这一步接管之后，前面几个 Skill 的价值才真正连成片。

ui-pipeline-scheduler Skill 技能介绍

简单来说，ui-pipeline-scheduler 是一个把执行、诊断、重试、报告四个阶段自动串联成闭环的编排层 Skill。

它自己不干活，只负责按规则调度前置的几个 Skill。

输入：

• 测试项目目录（含 tests/、pages/、pages.yaml）
• 执行参数（优先级、标签、浏览器、并行数等）
• 重试上限（默认 2 轮）

处理逻辑：

1. 环境自检：确认项目结构完整、Python 环境就绪；
2. 首轮执行：调用 ui-test-executor 跑完指定范围，备份首轮结果；
3. 条件诊断：有失败才调 ui-failure-diagnoser，全过直接跳到报告；
4. 定向重试：只重跑失败的用例，修完再验，循环判断；
5. 结果合并：把首轮和各轮重试的结果合并成一份完整数据；
6. 终版报告：调用 ui-report-generator，融合全部产物出报告。

输出：

• 一份融合了执行、诊断、重试全部信息的终版 HTML 测试报告
• 各轮留档结果与诊断报告

适用场景：

• 一键全跑 UI 自动化（执行 + 诊断 + 重试 + 报告）
• 版本发布前的完整回归闭环
• 失败用例自动诊断修复后自动重试验证
• 对接 CI/CD，单入口触发整条测试流水线

它的整个设计遵循两条原则。

零侵入，只当指挥。 它不改前面几个子 Skill 的任何代码、入参、出参，只做三件事，传参、读产物、控顺序。这条原则反过来看更重要，三个子 Skill 随时可以单独调用，套进流水线不影响单用，单用也不依赖流水线。

该停就停，绝不空转。 每一轮循环都有明确的退出条件，修不好就止损。一条流水线最怕的不是慢，是无意义地空转。

落到流程上，它固化成一条五阶段链路。

执行 → 诊断 → 重试 → 合并 → 报告

对着前面这几个问题，一步一步看它是怎么拆的。

1. 一条指令，五个阶段

对用户来说只有一个入口。一句话，「一键全跑 P0 冒烟，失败自动诊断修复重试，最后出报告」。剩下的，执行、诊断、重试、合并、报告，五个阶段按顺序自己走。

以前人要单独执行四次 AI，现在人只说一句话。

2. 全绿直通车

首轮就全过，是流水线最好的情况，也最不该浪费的情况。此时诊断和重试直接跳过，一路直通报告。

不为「流程完整」而空跑环节，每一环的触发都有实际条件。

3. 诊断修复，定向重试

首轮有失败，进入诊断环节。修完之后不重跑全量，只把失败的那几条捞出来定向重跑，快，而且不给已通过的用例添变数。

跑完再看结果，修好了继续收敛，还有失败就进入下一轮判断。

4. 熔断兜底，绝不死循环

三种情况，立即停机。重试轮数到上限；这一轮诊断一条都没修好，再跑也是白跑；或者全部通过了，任务完成。

停机后如果还有失败，不会静悄悄吞掉，会在结果里明确标出，这几条用例经过 N 轮修复仍未通过，附上用例清单。这几条，就是该人出手的地方。

5. 多轮合并，数字不失真

这是整条流水线最隐蔽的一个坑，也是编排层最值钱的细节。

重试只跑失败用例，结果文件会被覆盖成只剩一个小集合。直接拿去出报告，首轮 8 条的活，报告里只剩 3 条，数字全部失真。

所以每轮结果都留档，最终出报告前做一次合并，以首轮完整结果为基底，用各轮重试的最新状态逐条覆盖，用例一条不丢，状态都是最新。

Skill 实战演练

还是 shop-lab 项目。在技能列表中选择 ui-pipeline-scheduler，输入一句指令。

/ui-pipeline-scheduler 一键全跑 shop-lab 的 P0 冒烟用例，
失败自动诊断修复并重试，最后出一份完整报告

执行详细过程如下：

UI 自动化全流程执行完成，过程结果如下：

打开最新生成的测试报告，确认效果：

到此，我们通过一键式调度UI自动化测试流水线技能ui-pipeline-scheduler：将「执行→诊断→重试→合并→报告」串联好了。

绝大多数的场景下，你只需要调用这个技能就可以了。

小结

先说说我的真实感受。

这个系列写到第四篇，我最想分享的其实是一个认知。单个 Skill 是能力，编排才是生产力。 执行、诊断、报告，每一环单独看，省下的都只是一段时间。串成流水线之后，改变的是工作方式——测试同学从「盯着每个环节的操盘手」，变成「定好参数看报告的决策者」。这个角色变化，比省下来的几个小时值钱得多。

另一层感触在设计上。编排层最容易走歪的方向，是越做越胖，把几个 Skill 的逻辑都吸进来，最后变成一个谁也拆不开的大块头。ui-pipeline-scheduler 反着来，零侵入，只传参、读产物、控顺序，子技能保持完全独立。能组合，是因为各自专业；各自专业，才有资格组合。

当然，边界必须讲清楚。流水线自动化的是流程，判断权仍然在人。

AI 负责的事	人负责的事
五阶段按序调度、条件触发	定执行范围（跑哪些、跑几轮）
诊断修复循环、定向重试	复核熔断标记的「修不好」用例
熔断止损、绝不空转	确认真实缺陷、推动修复
多轮结果合并、数字不失真	看终版报告，做发布决策

特别提醒一句。熔断不是失败，是分工。 流水线明确告诉你「这几条机器修不好」，恰恰是它靠谱的表现，剩下的判断本来就属于人。别把一键流水线当成无人值守的挡箭牌，报告里那个 ⚠️ 标记，永远值得点开看一眼。

回顾一下整个过程。

痛点。 一条链调四次 AI，衔接靠人盯，重试没规矩，多轮结果打架，中途断链全报废，接不进 CI。

方案。 ui-pipeline-scheduler 把流程固化成「执行、诊断、重试、合并、报告」五阶段闭环。全绿直通车，失败进循环，熔断有兜底，合并不失真，单入口一条指令。

效果。 以前一轮完整回归，人要盯着串四次环节。现在一句话启动，回来直接看终版报告，中间的循环、止损、合并全部自动，CI 也能直接接。

边界。 AI 负责编排和执行，人负责参数和决策。流水线把路铺好，走不走、怎么走，还是人说了算。

大家可以自己根据本文提供的思路开发 skill，如果需要现成的教程和 skill，也可以加入「狂师 . AI 进化社」获取，里面有各类 AI 技术落地保姆级图文教程、视频教程，包括 AI 测试全流程的实战教程（保姆级手把手喂饭教程，跟着步骤操作，零基础也能快速上手，目前含有 30 多个 AI 测试全场景的 Agent Skill）。

温馨提醒，「AI 测试」只是 AI 进化社八大技能版块之一。

到这里，「跑、修、报、串」四块拼图凑齐，UI 自动化从执行到决策的整条链路，正式跑通。

把这条链接进企业 CI/CD，代码一提交，测试自动跑，报告自动推。让你的流水线，真正流起来。老弟，你学会了吗，我们下个系列见。