AI 加速交付，CI 却成新瓶颈

随着 AI 编码工具的普及，开发者（以及 AI Agent）的代码交付速度呈指数级增长。然而，传统的 CI（持续集成）流程却未能同步跟上，验证环节反而成了制约团队效率的新瓶颈。

Linear 团队在今年早些时候就意识到了这个问题。CTO Tuomas 指派了相关任务，要求在控制成本的同时提高 CI 速度。随着测试套件自年初以来几乎增加了三倍，团队面临着一个严峻挑战：如何在代码量激增的情况下，保持 CI 的反馈速度？

经过深入分析，Linear 团队发现，虽然代码量增加，但他们成功将 Pull Request 的等待时间从 6 分钟以上缩短到了 5 分钟以上，同时将单次测试的运行器时间缩短了约一半。他们主要在以下四个方面进行了重构：

策略一：升级基础设施与工具链

硬件和编译器的升级往往能带来立竿见影的效果，且不需要对 CI 流程做大幅改动。

• 换用高性能运行器：Linear 将工作负载从 GitHub Actions 迁移到第三方运行器。这些运行器配备了更快的 CPU、高性能存储和更好的缓存基础设施。在同等对比下，CI 作业的平均运行速度提升了 34%，其中 TypeScript 编译器（tsc）的运行速度甚至提升了 52%。这对开发者来说意味着更快的反馈循环。

• 引入原生编译器：团队切换到了 tsgo，这是一种基于 Go 语言的原生 TypeScript 编译器。相比于传统的 JavaScript 实现，它在性能上具有巨大优势。这一改动将 tsc 检查的中位数每周运行时间减少了 73%，成功将类型检查的瓶颈从 CI 流程中移除。

策略二：重构 Lint 规则，移除类型依赖

Linting（代码规范检查）通常是 CI 中内存占用最高的任务之一，因为许多自定义规则依赖于 TypeScript 的类型信息。

• 从类型检查转向静态分析：Linear 重写了部分 Lint 规则，不再依赖 TypeScript 的类型图，而是利用抽象语法树（AST）进行静态分析。这种方法可以在不构建完整类型图的情况下识别函数结构和守卫模式。

• 大幅提升性能：这一改动让 ESLint 完全脱离了对 TypeScript 的依赖，API lint 时间减少了 68%，全仓库 lint 时间减少了 55%。内存使用量也显著下降。此外，这种纯语法的规则更容易移植，使得后续引入 oxlint 等超快 Lint 工具变得更加容易。

策略三：优化“门控”作业，缩短关键路径

CI 系统不仅是个体作业的集合，更是一个整体。Linear 将目光投向了那些位于所有作业之前、决定后续流程走向的“门控”作业。

• 精准控制 Fetch 深度：许多工作流以一个变更检测作业开始，用于判断 PR 是否包含数据库迁移等特定变更，从而决定后续运行哪些检查。过去这些作业会检出完整的仓库树，但实际上只需要极少量的文件。

• 减少无效等待：通过限制 fetch depth（拉取深度），这些门控作业只获取必要的代码。由于这些作业位于关键路径上，哪怕微小的延迟也会被放大。优化后，系统避免了不必要的资源占用，确保了后续测试分片能更快启动。

总结

Linear 的案例表明，面对 AI 带来的开发速度激增，CI 优化不再是“锦上添花”，而是“必选项”。通过升级硬件/工具、重构 Lint 逻辑以及优化作业调度，团队成功在测试量翻倍的情况下，实现了 CI 性能的逆势增长。这些经验对于所有希望构建高效 CI 流程的开发团队都具有很高的参考价值。