智能体把 CI 变成瓶颈：Linear 用四步把 PR 等待时间从 6 分钟压到 5 分钟，测试套件翻了近四倍

起点是一句内部 issue

Linear 的工程师回忆，年初他打开 Linear 时发现 CTO 给自己指派了一个 issue，标题只有四个字：「CI 的成本太高了」。同一时间还有个附带要求：顺手把 CI 做快。他们的解释是，智能体让代码提交的速度成倍上升，但验证这些改动的速度没有同步跟上，每个 PR 仍然要排队过 CI，于是开发者和智能体一起在等反馈，成本也随之上涨。

只盯两个指标

为了避免「优化了但说不清有没有用」，他们把目标压到两个量上：一个 PR 等待 CI 的时间，以及每个测试消耗的 runner 时间。结果是，从年初到现在测试套件规模接近翻四倍，PR 等待时间反而从 6 分钟出头降到 5 分钟出头，单个测试的机器时间大约减半。

测试分片能缩短等待，但会增加机器时间——在白线（每测试机器时间）上会看到明显的凸起。

四类改动，按见效速度排

• 换基础设施：把负载从 GitHub Actions 迁到 CPU 更快、存储性能更好、缓存更强的第三方 runner，同口径对比下作业平均快 34%，tsc 这类单项快 52%；
• 换工具链：改用原生 TypeScript 编译器 tsgo 后，tsc 检查的周中位数下降 73%，类型检查不再是最长的环节；
• 拆掉 lint 对类型信息的依赖：把自定义规则重写成基于语法树（AST）的静态分析，ESLint 不再需要先构建完整类型图，API lint 降 68%、全库 lint 降 55%，内存占用大幅下降；
• 减少重复准备与优化门禁作业，让卡住其它任务的环节先跑完。

可以被别处复用的部分

Linear 的代码库以 TypeScript 为主，但他们明确说其中不少优化跨语言通用：换 runner 是纯基础设施收益；把 lint 规则从类型依赖改成 AST 静态分析，任何语言的自定义规则集都适用；而「减少重复的环境准备」本质上是缓存与依赖边界问题。唯一需要自己算的是分片策略——它买时间，但要付机器费。