AI 写代码太快，CI 跟不上了：五个提速 GitHub Actions 的实用方法

GitHub 每周处理 2.75 亿个 commit，Actions 单周消耗 21 亿分钟，Agent 一下午开十个 PR 时，15 分钟的流水线就成了排队瓶颈。这篇文章给出五个可落地的提速手段：先测量、缓存、换更快硬件、并行分片测试、跳过不必要的运行，每一步都有具体配置示例。

先测量，别靠猜

• 打开最慢 workflow 最近十次运行，记录耗时最长的三个步骤，用中位数而不是最差值，避免被一次网络抖动误导
• 区分排队、环境准备和实际运行三种时间，它们对应不同的解法；如果任务在队列里等了一分钟，调测试毫无用处
• 很多'测试慢'的 job 其实是 90 秒装依赖加 30 秒跑测试

用稳定 key 缓存依赖和构建层

• actions/cache 用 lockfile 的哈希做 key，依赖不变就命中缓存；restore-keys 能在精确未命中时恢复最接近的旧缓存，只补装新增的包
• 避免在 key 里放时间戳或 commit SHA，那样每次都存新缓存却永远复用不上
• Docker 构建先 COPY lockfile 装依赖、再 COPY 源码，改代码就不会重建安装层；BuildKit 配 cache-from/cache-to 为 type=gha 可跨运行保留层
• 注意缓存存在远程存储，大缓存的下载耗时可能抵消省下的安装时间

换更快的硬件

• GitHub 私有仓库标准 runner 只有 2 vCPU 和 7GB 内存；第三方 runner 如 Avrea 只需把 runs-on 改成一个标签，官方数据称硬件本身快约 2 倍，加上缓存命中可达 10 倍
• RunsOn 的公开基准测试显示：在 4-vCPU x64 类别，Avrea 跑完三个开源项目构建约 7 分钟，GitHub 4 核 runner 约 18.5 分钟
• Avrea 把缓存放在与 runner 同一数据中心，npm、pip、Go、Cargo 的包缓存开箱即用，Go、Bazel、Gradle、Turborepo、Nx、sccache 的构建缓存也预配置好了
• 其他路线：Depot 提供更快 runner 和远程 Docker 构建；RunsOn 是自托管，在你自己的 AWS 账号里起 EC2；GitHub 官方大规格 runner 需 Team/Enterprise 套餐

并行和分片测试

• lint、类型检查、单元测试、构建之间通常没有依赖，删掉习惯性加的 needs 行，GitHub 默认就会并行跑 job
• 用 matrix 策略分片：Jest 的 --shard=${{ matrix.shard }}/4 可以把 12 分钟的测试套件压到约 3 分钟，Playwright 同理，最后合并报告
• 设 fail-fast: false 让所有分片跑完，一次看到全部失败
• 分片有上限：每个分片都要付自己的启动成本；单个 job 内可用 pytest-xdist 吃满机器 CPU；个别超大测试文件要单独拆分

少跑不需要的运行

• 用 paths / paths-ignore 让改文档不触发后端全量构建；但注意 required check 因路径过滤没跑时 PR 会卡住，此时应让 workflow 跑起来、用 if 条件跳过 job，因为跳过的 job 会被算作通过
• Monorepo 里用 Nx 的 nx affected -t test 或 Turborepo 的 turbo run test --affected 只测受影响的包；actions/checkout 默认只拉一个 commit，要拉够 Git 历史才能和 main 对比
• 配 concurrency 组并设 cancel-in-progress: true，连续 push 时自动取消过期的旧运行——Agent 每小时多次更新分支时尤其重要
• 部署类 workflow 不要开取消，中途取消部署会留下坏状态，应该排队执行