大家好，我是狂师。
前三篇，我们把 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 轮）
处理逻辑：
- 环境自检：确认项目结构完整、Python 环境就绪；
- 首轮执行：调用
ui-test-executor跑完指定范围，备份首轮结果； - 条件诊断：有失败才调
ui-failure-diagnoser，全过直接跳到报告； - 定向重试：只重跑失败的用例，修完再验，循环判断；
- 结果合并：把首轮和各轮重试的结果合并成一份完整数据；
- 终版报告：调用
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 负责编排和执行，人负责参数和决策。流水线把路铺好，走不走、怎么走，还是人说了算。
到这里，「跑、修、报、串」四块拼图凑齐，UI 自动化从执行到决策的整条链路，正式跑通。
把这条链接进企业 CI/CD，代码一提交，测试自动跑，报告自动推。让你的流水线，真正流起来。老弟，你学会了吗，我们下个系列见。
