AI coding has made CI a bottleneck, so we reworked ours to keep up（AI 编程让 CI 成了瓶颈：Linear 的重构实录）

📅 2026-09-21 | 🏷️ 工程 & Agent | ⭐ HN 122分/113评论
🔗 原文：https://linear.app/now/ci-bottleneck-reworked

是什么

Linear（知名项目管理工具公司）发布的官方一手复盘：引入 AI 编程后，代码产出速度暴涨，原本游刃有余的持续集成（CI）流水线排队严重、变成交付瓶颈，团队因此对 CI 体系做了针对性重构。HN 上 122 分、113 条评论。

🔍 小白解读

先说几个词

• CI（持续集成）：每次有人提交代码，系统自动跑编译、测试、检查的"质检流水线"，是软件工厂的质量关卡。
• 瓶颈（Bottleneck）：流水线里最慢的一环——上游再快，货都堆在它这里。
• AI 编程（AI Coding）：让大模型帮忙写代码，人类工程师从"打字员"变成"审稿人"。
• 吞吐量：单位时间内流水线能处理完的任务数，决定团队交付速度的天花板。

这篇到底在说什么

打个比方：以前工厂每天进 10 批货，质检线一班岗就够了；现在 AI 让"造货"速度翻了几倍，每天进 50 批，质检线排起长队，最后质检成了全厂最慢的环节。Linear 遇到的就是这个局面：AI 让写代码变快了，但每份代码都要过 CI 质检，结果工程师写完代码却要干等 CI 排队，AI 带来的提效被白白吃掉。于是他们重构了自己的 CI，让质检线跟上造货速度。HN 上一百多条讨论说明，这几乎是所有用 AI 编程的团队正在或即将遇到的问题。

这跟普通人有什么关系

如果你所在团队开始用 AI 写代码，却感觉"交付反而变慢了"，大概率不是 AI 不行，而是 CI 这类下游环节没跟上。对管理者来说，这是"买工具之前先算配套产能"的典型案例；对开发者来说，等 CI 的时间会直接吞噬 AI 节省下来的编码时间。

为什么值得架构师关注

• 容量规划前提变了：AI 编程时代，CI 并发容量不能再按"人头 × 日提交数"静态估算，要按提交量增速动态重估。
• 成本结构显性化：CI runner 是真实的算力开支，AI 提效的另一面是质检算力账单上涨，需要纳入 TCO。
• 质量门禁设计：测试分层（冒烟/全量）、远程缓存、并行化是业界通行的扩容手段，Linear 的实践可作为对照基准。
• 组织影响：等待 CI 的时间直接抵消 AI 提效，工程效能团队应把"CI 等待时长"列入 AI 转型的核心观测指标。

核心内容

• Linear 官方一手复盘（非转述），核心论点：AI coding 让 CI 从后台设施变成交付瓶颈。
• 团队据此对 CI 体系进行了重构，以匹配 AI 编程带来的提交量增长。
• HN 122 分 / 113 评论，讨论集中在 CI 容量、成本与质量门禁的平衡。
• 与同期 HN 热帖《If AI coding is lowering your code quality, you're not managing quality right》（117 分/164 评论）共同指向"AI 编程时代的工程基础设施重构"这一主题。

行动建议

建议立即检查：拉出本团队近三个月 CI 排队时长与并发峰值曲线，若已引入 AI 编程工具，按提交增速重新测算 CI 容量预算；优先落地测试分层与远程缓存这两个性价比最高的改造。Linear 的具体做法详见原文。