Linear 重做 CI，AI 写得更快以后等待与账单要分开算
据 Linear 工程团队复盘，其测试套件规模较年初接近四倍，但 PR 等待 CI 的时间从超过6分钟降至略高于5分钟，每项测试消耗的 runner 时间约减半。两个数字描述的是不同收益。
作者：林岚｜OC 开发者生态编辑
据 Linear 工程团队复盘，其测试套件规模较年初接近四倍，但 PR 等待 CI 的时间从超过6分钟降至略高于5分钟，每项测试消耗的 runner 时间约减半。两个数字描述的是不同收益。
一句话结论：CI 优化既要缩短开发者等待，也要减少机器总用时，增加并行度只有在准备成本足够低时才划算。
等待时间取决于最慢的必经路径，账单却会累加所有运行机器的用时。把工作拆给更多机器，可能更早完成，也可能支付更多重复安装和初始化成本。因此，“更快”与“更便宜”应放在两张指标图里看。
Linear 的措施包括更换基础设施、改进类型检查工具、减少关键路径上的仓库拉取，以及只安装任务需要的依赖。其复盘还有一个反直觉细节：恢复某份依赖缓存比重新进行受限范围的安装更慢，于是团队放弃了那处缓存。缓存命中本身不应成为优化目标。
测试执行层面的改动更需要谨慎。团队把耗时大文件拆小、调整分片，并让经过选择的测试文件共享模块状态以减少重复初始化；不适合共享状态的文件仍保留隔离。作者明确承认，减少隔离也是正确性风险最高的优化之一。
这意味着一条成功经验不能简化为“关闭隔离就会更快”。OC 认为，只有弄清哪些状态会残留、清理逻辑是否可靠、测试顺序会不会改变结果，才有条件采用这种做法。否则节省下来的 CI 时间，可能被更难复现的线上故障重新收走。
关键事实
- 规模背景：测试套件接近年初四倍，结果由 Linear 团队报告。
- 两个口径：PR 等待略超5分钟；每项测试的机器用时约减半。
- 工程边界：共享测试状态采用明确选择机制，不是对全套测试取消隔离。
OC 判断
AI 编程让改动的供给更充足，也让验证系统的吞吐更重要。这个案例有用的地方，是先拆出重复开销与关键路径，再决定哪里并行。流水线优化应该持续证明测试仍然能发现问题，而不只是把仪表盘变绿。
为什么重要
- 对开发者：记录等待时间与机器总用时，避免只优化一个指标。
- 对团队：优先减少无用准备工作，再调整分片与测试隔离。
评论
围绕这篇文章补充信息、提出问题或分享观察。