你以为 AI 提高的是代码产出速度，今天才发现在 CI 里埋了一颗雷——Linear 把这件事彻底变了

你们团队今年引进 AI 编程工具了吗？引进之后，CI pipeline 变快了还是变慢了？

Linear 的工程师最近遇到了一个他们自己都没预料到的问题：AI coding 辅助把代码提交速度提上来了，结果 CI 测试套件的规模在一年内涨了近四倍——不是 bug，是正常迭代带来的测试量。PR 等待时间从六分钟变成了一个需要「去喝咖啡等」的常态。

这不是 Linear 一家的问题。AI 编程工具正在以一个以前不存在的速度往仓库里注入代码，而大多数团队的 CI 基础设施是按人类程序员的提交节奏设计的。

Linear 怎么解决的？三个动作：

第一，换掉 GitHub Actions 默认 runner，用上了更快的第三方执行器；第二，把 TypeScript 编译检查切换到 tsgo（原生 TypeScript 编译器而非解释执行）；第三，减少重复的环境初始化步骤，优化 gate job 的触发逻辑。

结果：PR 等的时间从六分钟缩短到五分多，runner 单次耗时平均减少 34%，TypeScript 编译检查的中位时间直接砍了 73%。

这里有个反直觉的地方：他们没有减少测试用例，反而让测试套件继续变大。提速的核心在于让每一分钟的计算资源都花在真正需要重新跑的测试上——增量测试分流，加上更快的执行环境。

对于还在用默认 CI 配置、前端项目却越来越依赖 AI 辅助生成的团队，Linear 的经验值得提前看一遍：你的 CI 工具链的「载荷上限」，可能比你想象的低很多。

下一步可以做的： 查一下你 CI 流水线的瓶颈到底在哪一步——是依赖安装、编译、还是测试执行？然后逐段做一次耗时分布分析。大多数团队的 CI 慢，瓶颈往往只在一个环节。