CircleCI 流水线优化器

要解决的问题

CircleCI 流水线变慢时，问题往往分散在 pipeline 的 stage/job 时间线、workflow 的 run 状态和 .circleci/config.yml 的并行配置里。团队容易陷入两类无效优化：要么凭感觉拆分 job，要么把缓存策略写成一刀切，结果缓存命中率没上来，矩阵任务反而更碎。该技能面向需要可复现诊断的工程师，把“哪个 job 慢、为什么慢、下一步改哪里”压缩到同一条分析路径。

核心能力与工作路径

它通过 CircleCI API v2 的 /pipeline 与 /workflow 端点读取构建元数据，从时间数据中识别慢速作业，并给出两类可执行建议：推荐启用或调整 Docker layer caching，以区分依赖变化与镜像构建成本；生成或更新带并行设置的 .circleci/config.yml，让 parallelism、matrix 参数和 job 拆分能围绕真实耗时做取舍。

实际使用时，建议先把分析范围限定到目标 pipeline/workflow，再让输出落回现有仓库配置；若 CI 权限只读，先核对 API token 的 scope，避免在分析阶段误触发流水线。

适用边界与注意点

它适合做构建性能诊断和配置改写建议，但慢的原因仍可能来自私有镜像仓库、缓存远端存储、资源 class、测试自身抖动或外部服务超时。生成的并行与缓存配置需要保留团队既有的 job 依赖、审批与手动触发语义；对涉及凭据、部署审批或破坏性 job 的改动，仍应人工复核。