发明Jenkins的人，现在劝你少跑点测试

2004年，Sun Microsystems的一名开发者受够了构建老是被自己搞挂。他写了个小工具当副业，专门抓自己的错。这个工具后来叫Hudson，再后来叫Jenkins，最终教会了整个行业一个习惯：每次提交都自动跑测试，一直跑下去。

二十年后，同一个人——川口耕介（Kohsuke Kawaguchi）——联合创办的公司，核心产品建立在完全相反的想法上：用机器学习预测某次改动会让哪些测试失败，然后只跑那些。早期客户报告测试执行时间砍掉了90%。这个工具现在以 CloudBees Smart Tests 的名字出货。

让"每次提交跑一万个测试"变便宜的人，如今在研究怎么只跑其中一小部分。这不是自相矛盾，是同一个问题从两头看。

那个发明了习惯的工具

川口2004年在Sun做Hudson，是因为当时的持续集成服务器又重又贵，属于企业级产品。他的判断是：把自动化做成一个免费、可插拔的服务器，任何团队一个下午就能立起来。几年之内，Hudson成了Java世界默认的CI服务器。

接下来是开源史上最离奇的章节之一。2010年Oracle收购Sun，并主张Hudson商标。2011年1月，社区投票决定改名：214票赞成改成Jenkins，14票反对。约85%的开发者迁往Jenkins，前25个插件里有21个跟着走。Oracle留下Hudson，捐给了Eclipse，到2017年被宣布淘汰。Jenkins这个"分叉"几乎所有人都跟了，再没回头。

川口在自己的LinkedIn上把结果写得很直白：一个拥有超过1500个插件的生态，十多年里一直是最流行的CI/CD软件。不管你怎么看Jenkins老化的架构，这种寿命在开发者工具里几乎闻所未闻。

但真正关键的是这一点：Jenkins不只是自动化了构建，它改变了团队对"跑得起多少测试"的认知。当每次提交跑全量套件变成免费，套件就开始膨胀。没人需要盯时钟了，也就没人去修剪。

Jenkins自己造出来的问题

时间快进到现在，算术反过来了。一条10分钟的CI流水线让团队保持流畅；一条90分钟的流水线做的事比浪费钱更糟——它改变开发者行为。人们开始攒改动，合并大分支来摊薄等待，反馈回路从分钟拉长到小时，持续集成原本的意义悄悄流失。

行业的第一反应是堆算力：更多并行执行器、更多机器、切分套件。账单跟着分钟数一起涨。第二个答案才是川口选的：别再假装每个测试在每次提交上都有相同的失败概率。

这是Launchable的创立洞察，他2019年和Harpreet Singh一起做的公司。他们观察到，Facebook多年前就在内部建了预测式测试选择，作为私有优化。技术是work的，但普通团队用不上。Launchable的卖点就是把它变成任何CI流水线都能调用的产品。

预测式测试选择到底怎么运转

机制没有营销话术那么玄，这是褒义。按Launchable自己的文档和产品描述：

• 模型在你的历史数据上训练。每次构建、每个测试会话、每条通过/失败结果都被记录下来。不存在一个通用的"哪些测试通常失败"的大模型，信号来自团队自己的战绩。
• 每次提交拿到一个打分后的子集。你推送时，系统看哪些文件变了，对照历史上"改动与测试失败"的关系，返回一份针对这次改动最可能失败的测试排序。
• 你跑一个切片，带置信度旋钮。流水线请求套件的前N个百分点；模型越有把握，你可以要更小的切片。团队最自豪的功能之一是"置信曲线"，把模型随着数据积累而成熟的过程可视化。
• CLI优先，语言无关。CLI包了一层REST API，对接Java、Python、Ruby、Go、JavaScript、.NET、Perl等二十多个测试运行器。

数字来自早期客户。2024年8月CloudBees收购Launchable时，新闻稿引用了BMW和GoCardless的数据：机器小时减少50%，测试执行时间减少90%，构建时间减少40%。这些是具名客户提供的厂商口径数字，不是独立基准测试，但具体到值得当作方向来认真对待。

发布帖里不会写的那个坑

一个预测失败的模型，从统计上讲，是被允许出错的。如果它把某个测试排进"这次改动不太可能失败"并跳过，而这个测试其实被你的提交搞坏了，你要到后面才知道——通常是第二天夜里，定时全量跑把它抓出来。如果你的发布节奏以周计，这个延迟没问题；如果你一小时内就要上生产，可能就不行。

三个风险值得单独列出来：

• 冷启动。模型第一天什么都不知道。你需要几周的历史记录，置信曲线才有意义。只有几百个测试的小项目攒不出有用信号。
• 漂移。重构架构或引入新模块，学到的"改动—失败"关系就会偏移。系统需要持续重新学习，你也需要注意到它准确率下滑。
• 覆盖盲区。预测式选择优化的是"找出历史说很可能失败的测试"。极少失败的测试永远排在末尾，而防住罕见回归的测试恰恰就住在那里。定时全量跑不是可选项，它是让这个优化变得安全的兜底网。

需要说明：我没有在生产环境跑过Launchable或CloudBees Smart Tests。我自己的项目在GitHub Actions上跑小套件，整条流水线几分钟就结束，对这类项目，这个产品品类确实不划算。这一点很重要，因为决策依据是套件规模，不是时髦。

底下的那套哲学

在最近与Josh Long的播客对话里，川口讲了一个关于AI在软件开发中的观点，也正好是他职业生涯的总结：AI正在快速改变软件开发，但最终胜出的系统，可能是那些把智能带进既有工作流的，而不是逼所有人搬进一个巨大的聊天界面。

具体到测试上看这意味着什么。预测式测试选择不要求开发者做任何新动作。你不用把代码粘进聊天窗口，不用学提示词格式。流水线还是2011年那样跑测试，唯一的区别是一个学习出来的模型决定这次提交该跑套件的哪一片。智能坐在你已有的工作流里面。

这个判断比听起来更锋利，因为它跟当下大多数打着"AI for developers"旗号出货的东西相反。默认的卖点是新界面：新聊天、新面板、新地方要你去查。川口的赌注——背后是二十年看着工具要么嵌入要么死掉——是AI的持久形态是隐形的。Jenkins赢，是因为它嵌进了构建里；Smart Tests想赢，是因为它嵌进了流水线里。没有东西要采纳，也没有东西要离开。

一张清单：这东西适合你的团队吗

"你该不该用"的诚实答案是"看情况"。下面是我真会走一遍的决策清单：

• 你的套件超过30分钟吗？低于这个数，预测式选择省下的是分钟级收益，记录、训练、监控模型的运维开销不划算。
• 你每周有几百次提交吗？模型靠历史喂养，靠新结果重新训练。提交少的仓库会把它饿死。
• 你有至少几个月的CI数据可训练吗？没有历史就没有信号。除了现在开始记录，没别的可做，而记录本身不花钱。
• 你能容忍罕见失败被晚发现吗？如果每次合并都是当天上生产，把这个代价诚实地和节省的分钟数放在一起称。
• 团队里有人愿意盯置信曲线吗？一个没人监控的跳测试模型，是安全网上的慢性渗漏。指定负责人，否则别上。

如果大部分答案是"否"，无聊的替代方案依然有效：把套件拆成提交级的快速层和夜间的慢速层，把不稳定的测试修掉而不是重试，能缓存的都缓存。川口的公司瞄准的是那些招数已经不够用的团队。

一个完整的圆

这个故事有种整齐的对称。2004年，测试的门槛是成本，川口把它拆了。行业的回应是建出大到成本再次成为门槛的套件，只是这次用小时计而不是许可证计。现在同一个人在攻老问题的新版本，用的技术之所以存在，正是因为上百万条Jenkins流水线花了二十年，记录下了这种模型恰好需要的数据。

Smart Tests本身赢不赢没那么重要，重要的是这个模式：开发者工具里下一波有用的AI，大概不会长成聊天窗口的样子。它会看起来像你现有的流水线，安静地少跑一些，抓住同样的失败。