CI 流水线可以是绿色的，却慢到无法影响开发者下一步动作。优化要先找出哪些反馈来得太晚，或者根本不值得信任。

为什么需要这个 Skill

CI 测试流水线优化用于识别瓶颈、重复工作、波动反馈、选择机会和安全的排序改动，同时不削弱有意义的覆盖。

Skill 用来做什么

当团队需要围绕“反馈时间、测试价值、波动、依赖、并行、选择和资源成本”工作时，使用 CI 测试流水线优化 Skill。

Awesome QA Skills 按语言和测试阶段组织 Skill。系列总览 解释通用安装方式，本文只聚焦 CI 测试流水线优化。

好的优化会保留测试存在的理由。它把昂贵反馈移动到真正需要它的决策点，而不是删除所有让流水线变慢的东西。

它适合这些场景：团队需要重复检查反馈时间、测试价值、波动、依赖、并行、选择和资源成本；多个证据来源互相矛盾；交接时必须说明哪些内容仍未验证。

它不做什么

CI 测试流水线优化 Skill 可以组织瓶颈的材料、证据和下一步动作，但它不能替代：

  • 业务或领域负责人对规则、范围和风险的确认。
  • 真实环境、账号、数据、日志或运行结果；静态分析不会自动升级为运行证据。
  • 发布、合规、生产操作和残余风险接受等授权决定。
  • 在输入相互冲突时替团队选择一个未经确认的事实。

它主要检查哪些内容

这个 Skill 的价值不在于把关键词再列一遍，而在于把每个关注点接到可观察的输入、判断和收口动作。先用源 Skill 已定义的输出字段整理一张小矩阵：

检查关注点开始前要问结果应留下什么
瓶颈排队、准备、执行、重试或产物时间测量证据
优化动作选择、分片、排序、缓存或环境改动覆盖与风险护栏
后续指标耗时、信任、缺陷发现或成本负责人和复核日期

如果某一行只有经验判断、没有来源或验证方法，就把它留在待确认项里，不要提前写成通过。

开始之前先审计输入

围绕“瓶颈”开始分析时，先把输入分成六种状态。缺口不会自动变成失败，但也不能被隐藏在结论里。

状态含义本 Skill 的处理方式
known材料直接证明的事实标出来源、版本和时间，允许进入判断
missing本轮需要但尚未提供的材料列出最小补证动作，结论保持受限
conflicting来源之间互相矛盾并列来源和冲突点，交给负责人裁决
stale材料存在但版本或时间已经过期标出新鲜度，不把旧结论当当前事实
out_of_scope有关但不在本轮范围内明确排除，避免分析悄悄扩大
assumptions为继续分析而暂时采用的假设写出验证方式和失效条件

至少把输入版本、范围、环境、证据位置和负责人放在一起。没有运行记录时，只能交付分析、设计或验证计划，不能写执行通过。

从问题到结构化发现

先把来源、范围、证据状态、分析判断、责任角色、动作、关闭条件和验证方式连起来，再写结论。下面的案例保留这个 Skill 的专属编号和领域语境。

分层写法

围绕瓶颈，不要把四种语气揉成一句“建议通过”：

层次写法本文应用
事实材料直接显示了什么引用来源中的重点、版本、输入或运行记录
基于证据的推断多个事实共同支持的判断说明推断链，并保留不确定性
建议下一步最小动作是什么指定补证、复核、执行或回归路径
人工决策谁需要决定什么由负责人确认范围、风险接受、资源和发布含义

一个完整案例

本节按输入、分析、发现、决策和验证展开；材料不足时保留 missing、conflicting 或 assumptions，不把它们改写成通过。

输入

材料这次提供什么缺失时怎么处理
流水线历史耗时、排队时间、重试率、失败类型和改动范围使用时间窗口，不要只看一次慢运行
套件地图依赖、标签、环境、数据和覆盖意图不要因为看起来相似就删除测试
决策目的PR 门禁、合并门禁、夜间信心或发布门禁针对真实决策优化

可以这样调用：

请使用 ci-test-optimization Skill。

任务：缩短一个共享 Runner 的 Monorepo 中浏览器、API 和契约测试的 PR 反馈时间
输入材料：[需求、版本、链接、日志、报告或数据路径]
范围：[本次包含和排除的对象]
未知项：[缺失的环境、账号、数据或权限]
期望输出：[按风险排序的发现、证据状态和下一步动作]

先审计输入。分开写事实、假设和待确认问题。没有运行记录时不要声称已经执行。

分析

先从一个边界清楚的小回合开始：在采用单体仓库结构、共用运行器的项目中，缩短浏览器、API 和契约测试的 PR 反馈时间。比较四周的 PR 运行记录，再根据稳定耗时和依赖拆分浏览器测试。如果契约测试能更早发现接口断裂，就把它放在 UI 测试前，并测量新分片是否降低排队时间而没有增加重跑。

交接产物要保留输入版本、时间窗口、证据索引、负责人和下一次验证动作。Skill 可以整理不确定性，不能制造缺失的产物。

发现

示例发现：把一次问题写成可交接动作

下面的字段示例只展示记录方式，不代表真实环境已经执行。

假设当前材料无法证明“瓶颈”已经满足要求，发现可以这样写。它既不替团队补写规则，也不把缺失证据伪装成失败。

字段示例写法
来源与范围记录本轮使用的需求、版本、环境和瓶颈的具体对象
发现瓶颈的判断条件或结果仍缺少可追溯依据
证据状态missing / assumptions；如果来源相互矛盾则改为 conflicting
影响与优先级说明会影响哪个用户、链路或交付决定，不凭感觉扩大等级
负责人和人工决策由业务、开发、安全或测试负责人确认规则和风险取舍
动作与关闭条件补齐最小证据；关闭条件是来源、判断和责任人都能复核
验证指定一次可重复的检查、查询或运行，并保存原始产物

这类记录的重点是让下一位同事能从发现回到来源，再执行一项能改变结论的动作。

决策

责任角色和待决策问题应由对应负责人确认；Skill 不替他们做风险取舍。

验证

关闭前按发现中的验证方式执行，并保留原始产物；没有执行记录时，状态仍然保持未验证。

发现如何进入下一阶段

交接产物

输出字段它要回答什么示例状态
瓶颈排队、准备、执行、重试或产物时间测量证据
优化动作选择、分片、排序、缓存或环境改动覆盖与风险护栏
后续指标耗时、信任、缺陷发现或成本负责人和复核日期

没有运行记录、查询结果或原始产物时，不要写“已通过”。好的优化会保留测试存在的理由。它把昂贵反馈移动到真正需要它的决策点，而不是删除所有让流水线变慢的东西。

下一步路由

至少交付来源、证据状态、负责人、关闭条件和验证动作；下一阶段的结论仍受证据状态约束。

怎样准备更好的输入

如果第一次调用只有一行目标，输出就应该保持受限。补充来源版本、受影响对象、环境、已知缺陷和决策负责人，才能从看起来完整的清单推进到可用评审。

这里补充信息会改变结果，因为反馈时间、测试价值、波动、依赖、并行、选择和资源成本必须接回证据，不能只靠熟悉的测试套路推断。

和其他 Skill 怎么配合

容易踩的坑

  1. 只优化平均耗时，却忽略 p95 仍不可用。
  2. 把重试次数增加当成速度提升。
  3. 没有覆盖和依赖地图，只根据文件名选择测试。

安装与调用

全局安装这个 Skill：

npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/ci-test-optimization -g

安装后使用 ci-test-optimization Skill，并附上真实项目材料。

常见问题

波动测试可以从 CI 删除吗？

只有在有负责人、替代证据和后续计划时，才能从阻塞门禁移出，不能只是隐藏失败。

并行一定会加快反馈吗？

不一定。排队、共享数据、Runner 争用和准备成本都可能让它更慢或更不可信。

参考

源 Skill 与执行契约

完整执行契约位于 CI 测试流水线优化 提示词。调用 Skill 前先阅读它；提示词定义了详细流程和输出契约。源目录 中包含入口文件以及实际存在的配套资料。

入口文件重点约束反馈时间、测试价值、波动、依赖、并行、选择和资源成本。要保留它的决策边界，不要把静态设计写成执行结论。

参考链接

安全测试白盒测试背靠背测试本地化测试边界测试
分享