用合并队列取代你的CI

# 用合并队列取代你的 CI 来源：https://blog.exe.dev/replace-your-ci 当前 CI 的标准做法是，在代码合并到主分支后，于云端运行测试。这相当于给工程师上了一道双保险：你修改的代码，有没有遗漏某些测试环节？ CI 对人类是有效的。原因在于我们对代码库及其演变有着长期的理解。刚接触某个代码库的工程师知道自己是个新手，会更加谨慎（或者收到自动邮件，告知他们搞砸了 CI）。熟悉代码库的人在心里清楚自己工作时需要测试什么。 CI 的自动邮件之所以管用，是因为它并不常见——毕竟我们都是按人类的速度开发，HEAD 坏掉一会儿也无妨。有些团队会对 CI 故障进行自动回滚。这确实有效，但你会在反复重试中损失不少事后测试的价值。不过它依然可行，至少比夜间构建再二分查找肇事者要强。 但对智能体（agent）来说，这就不管用了——至少截至 2026 年 6 月是这样。 这里存在两个问题。首先，智能体对代码库永远是个新手。它们缺乏代码库专家的那些隐性知识，因此*无时无刻*不在破坏自己未曾关注的项目部分。用智能体配合 CI 进行开发，简直令人抓狂。你的智能体需要在开发过程中运行所有测试，以确保它理解环境。 第二个问题是，等到可怜的人类开发者收到自动邮件说搞砸了 CI 时，智能体的上下文窗口早就凉透了。智能体本应该悄无声息地解决这个问题，不让它成为别人的麻烦。只要不碍着任何人，它有的是时间。让计算机去驱动计算机吧。 因此，你需要让你的组织进入一个状态：智能体可以随时运行所有测试。有一个简单的办法：用合并队列取代你的 CI。 合并队列是一个脚本，运行它将代码推送到 `origin/main`（而不是像我们在全人工的 GitHub 时代那样使用 PR 界面）。 非常重要的是，你必须在合并队列中运行**所有**测试。不要有所谓的“慢速测试”留到每天跑一次。在智能体时代，那些测试*每天*都会挂掉。会有人每天花数小时追着别人的智能体擦屁股。团队里没有人想干这个活。事实表明，唯一比给别人收拾烂摊子更糟的是给别人的机器人收拾烂摊子。 当你有了一个可用的合并队列后，再创建第二个命令：运行合并队列，但不实际合并。把它交给你的智能体。 这样能确保： 1. 智能体的活跃上下文窗口可以在测试中运行，并在把 bug 强加给他人之前修复它们。 2. 无论是人还是机器，都不会破坏构建。 在人类时代，当 CI 很慢的时候，你可以为 CI 而非合并队列辩护。那些论点的依据是测试太慢，不适合放到合并路径中。但在 2026 年，这一点行不通了——为了使用智能体，测试必须快。现在 CI 已经行不通了。有了智能体，CI 就没用了，合并队列要优越得多。 你需要昂贵的计算机来支撑你的合并队列。但这笔投入是值得的。