每日30到70个PR：我们如何做到不搞垮系统

# 每天 30 到 70 个 PR：我们如何做到不搞垮系统 来源：https://www.honeycomb.io/blog/30-70-prs-day-how-we-managed-not-wreck-systems *在这两篇系列博客中，我详细汇报了 Honeycomb 工程团队如何在不破坏一切或不降低质量标准的情况下，借助 AI 将吞吐量提升了 2.5 倍。第一部分解释了我们如何做到，并展示了这一加速过程的数据。第二部分分享了我们学到的东西。 (https://www.honeycomb.io/blog/ai-amplifies-existing-practices-lessons-ai-first-strategy)* ## TL;DR - 高峰工作日的合并次数大约翻了一番（从约 30 增至约 74），同时 AI 归因代码行从接近零增长到 2026 年 6 月新代码中至少占 82.6%。事故也随之增加，其增长与变更量的大致线性关系正如你所预期；现在的目标是让每次故障的遏制成本保持低廉，而不是让事故数量保持平稳。 - 收益分为三个阶段：缓慢的实验期（2025 年）、工具驱动的大规模采用期（2025 年 10 月），以及 2026 年 2 月 Opus 4.6 发布后委托强度的一次阶跃变化——同样的工程师，同样的工具，但他们不再监督每一步。 - 我们的核心论点：AI 会放大你已有的实践。它会让功能失调的组织更加失调，让高自主权、高主人翁意识的组织变得更高效。真正关键的实践——持续交付、快速且 AI 可读的 CI、闭环可观测性、CLAUDE.md、功能开关——才是故事本身，而倍数只是结果。 为什么我要在标题里写上那个大数字？因为它能吸引你点击。但我们将深入探讨除了提升 2.5 倍吞吐量之外的所有细节和条件，包括我们是否让质量下滑了。这篇博客及其姊妹篇是我们的汇报，讲述我们如何实现这一结果，如何让支撑该吞吐量的系统免于崩溃，以及在此过程中学到了什么。 ## 设定目标：一年内将生产力翻倍 2025 年 8 月中旬，我们的创始人向全公司（不仅仅是工程团队）发了一封信：每个人应努力在未来一年内将生产力翻倍。这封信是个体导向的，但其背后的框架是团队协作，而非个人竞赛，并且不应被理解为与队友竞争。信中明确提到 Darragh Curran 的 Intercom 2x 文章 (https://ideas.fin.ai/p/2) 作为灵感来源。八个月后，我们开始衡量和反思。本文紧随 Darragh 关于九个月内实现 2x 的回顾 (https://ideas.fin.ai/p/2x-nine-months-later) 以及 Kesha Mykhailov 和 Niamh Young 关于安全扩展 AI 自动批准的文章 (https://www.intercom.com/blog/ai-is-approving-our-pull-requests-heres-how-we-made-it-safe/) 之后。我们比 Intercom 规模小，也年轻几岁，历史上一直跟随他们几个月的步伐。 Honeycomb 单仓库在高峰工作日的合并数量从 2025 年初的约 30 个增加到 2026 年 4 月的约 74 个，翻了一倍多。该代码库在十六个半月内翻倍，从 2024 年底约 97 万行增长到 2026 年 5 月第一周的 194 万行以上，截至 7 月初已达到 210 万行。此前一次翻倍花了将近三年时间。这些净新增代码中，大部分在其历史中的某个阶段是由 AI 共同编写或审阅的。 ## 关于那个数字的实话实说 1. 这是高峰工作日的数字，不是日历平均值。周三无会议的日子生产力最高，无论是 AI 使用前还是使用后；日历平均值大约只有峰值的一半。这是峰值。不要在某一个随机周二去找 70 个 PR，然后认为我骗了你。 2. 这是一个下限，不是真实计数。我们最活跃的 Claude Code 用户之一（按 token 量计）在 git 提交中没有 AI 归因。他们在 30 天内运行了 22 次会话，消耗了 1.99 亿 token 通过 Claude Code，但 git 完全没有记录，因为他们的 Co-Authored-By 尾部标记在工具层面被禁用了。如果我们无法衡量他们的 AI 使用情况，那么我们也无法衡量其他几个人的使用情况。 3. 它同时与同期发生的组织变革纠缠在一起。2026 年 1 月初，我们的创始人发了一封后续信，比 8 月那封提出了更尖锐的战略赌注：将 Honeycomb 的产品界面和市场定位重建为 AI 优先，远远超出最初的生产力目标。随后在 1 月中旬进行的重组，转向绿地项目、高 AI 杠杆的工作。我们入职了新工程师。我们投资了平台工程。任何人告诉你单一因素导致其团队收益，都是在夸大其词，包括我们。 从“AI 工具确实让工程团队更快”到“任何采用它的团队都会得到相同结果”之间，存在巨大差距。本文的大部分内容都处于这两种说法之间的空白地带。有趣的故事不是倍数，而是我们如何保持系统在其下稳定运行、付出了什么代价，以及我们仍在摸索什么。简短版本（也是我每次受邀上台时反复提及的一句话）是：AI 会放大你现有的实践 (https://www.honeycomb.io/blog/shipping-is-your-companys-heartbeat-letter-from-cto)。它可以让功能失调的组织更加失调，也可以让已经拥有高自主权、高主人翁意识和反馈循环的组织发挥出最佳状态。我们当初并不是为了证明这个论点；我们接受了一个挑战，这个论点是在事后才显现出来的。 如果你看过我的“AI 就像巧克力”演讲 (https://www.honeycomb.io/blog/observability-day-san-francisco-future-ai-observability-is-bright)，你就知道那个片段：巧克力不适合放在所有东西上，一次吃太多会让你生病，而且再多的巧克力也不能替代你知道如何烹饪。我发表那个演讲时是一个转为现实主义的悲观者，现在也仍然如此。从那时到现在发生的变化不是比喻本身，而是工具及其周围的实践已经变得足够好，以至于巧克力在厨房里的合法地位变得更大了。它比以前更通用、更宽容。本文后面“怀疑论者说得对的地方”中所做的让步，依然是我仍在做出的让步。作为一个改过自新的怀疑论者，并不意味着我不再是怀疑论者。 你应该对本文中每一个数字（包括我们自己的）都持保留态度。方法论比数值大小更重要。在这篇文章的剩余部分，请始终保持对炒作和听起来合理的数据的语义防御。 ## 数字在质量方面说明了什么，没有说明什么 我们尚未遭遇由 AI 引起的重大故障。没有“AI 删除了我的数据库”，也没有“AI 发布了损坏用户数据的代码”。这不是运气；也不是什么新鲜事。这是防御性设计的结果，无论混乱的制造者是人是机器人。在现有基础设施上堆叠代理，并在组件之间设置舱壁、审查、部署列车、功能开关和最小权限访问，这意味着 outages 的影响更低，而不是要么不存在、要么全是严重等级。如果你还没有建立这样的体系，那么在使用 AI 之前，这是需要先解决的问题，而不是之后。数据库被删除是系统设计问题：有人跳过了构建本应能捕获该问题的护栏，无论代码是谁或什么写的。 事故的绝对数量在增长。从 2024 年的基准线（每季度约 18.5 起事故）来看，2026 年第一季度达到 32 起，是基准线的 1.7 倍，而 PR 吞吐量约为基准线的 2.5 倍；这一个季度看起来是次线性增长。第二季度未能保持：53 起事故，基准线的 2.9 倍，即使 PR 吞吐量本身在剔除 5 月冻结周和 1 月加速激增后大致持平。两个季度下来，事故增长与变更量大致呈线性关系，正如你所预期。变更是全行业事故的主要驱动因素（参见 VOID 报告、Google 的 DORA 研究），而我们正交付更多的变更。大数定律降临到我们头上。 数据实际支持的是两件事：没有重大故障，加上我们捕捉到的一些综合二阶效应。更广泛的 AI 归因叙事往往是自我美化的，无论方向如何；如今 AI 已经如此深入地融入其中，将其作为单一原因隔离出来很少是有意义的练习。按原因归因是我们人类为了对自己已有的立场感觉更好而编造的童话。 交付的变更越多，缺陷出现在批次中的机会就越大，无论组织的缺陷基线是多少。我们交付的变更多得多，因此事故也多得多，大致比例如你所预期。现在说 AI 协助调试是否能降低事故严重性还为时过早；在某些情况下，它帮助我们快速找到根本原因，在其他情况下，却让我们追逐一个自信但错误的答案。这种数量级对吸纳它的团队来说是真实压力，而不仅仅是图表上的一条上升曲线。我们依靠更好的自动预检检查等手段，试图将曲线重新压下来。将 AI 的速度直接转化为纯产出而非可持续速度所带来的倦怠风险 (https://steve-yegge.medium.com/the-ai-vampire-eda6e4f07163) 是真实存在的，值得明确指出，而非假设它不存在。 我更愿意挂在墙上的指标不是每天的 PR 数量。吞吐量是输入指标，而非产品；它只是我们今天用来展示阶跃变化的粗略衡量手段。如果吞吐量上升而用户成果停滞或下降，那么定义上说就是“垃圾化”（enshittification）。 ## “AI 贡献”究竟意味着什么？ 不存在单一的“AI 百分比”。至少有四个不同的分母，在引用一个数字之前，你必须明确你问的是哪个问题。 （供应商仪表盘会很高兴地给你一个“受 AI 影响的 PR”数字，并带有一个置信度开关。在低置信度下，我们在做以下任何工作之前，我们的仪表盘就愉快地报告大多数 PR 是 AI 影响的。不要相信低置信度。本文中的数字来自我们自己的 git 历史和遥测数据，并经过手动校准。） 这些是校准后的下限，而非点估计。我们通过将三层修正叠加到 git 的原始信号上来得到这些数字：本地分支尾部标记（245 个 PR 的 AI 归因因 squash merge 被剥离）、GitHub API 分支尾部标记（117 个 PR，合并后分支被删除，但我们通过 GraphQL 在所有 7,952 个 PR 中恢复了尾部标记），以及一个“气味测试”遥测覆盖（112 个 PR，来自那些在 git 中没有 AI 归因但拥有大量 Claude Code 会话遥测的工程师，按月度根据他们的实际会话活动进行门控）。 95% 的工程师级别采用率（更接近我们的直觉估计）与较低的 PR 级别（63%）和行级别（75%）下限自然吻合：高采用率，但选择性在每个 PR 上使用。我们可以从 git 历史中测量下限。我们无法测量上限。明确这一区别比具体的数字更重要。 AI 归因下限叠加在无归因基线之上 *自 2024 年以来在 HEAD 存活的代码行。红色条带是下限；来自 PR 的代码行在其历史中某处有 AI 归因。蓝色条带是“无归因”，而非“无 AI”。* ## 发生了什么 Honeycomb 的采用曲线有三个不同的阶段。每个阶段都由不同的因素驱动。 第一阶段，2025 年 4 月至 9 月，是持续的低速率实验阶段。每月大约有一到两名新工程师采用 Claude Code，有支持但没有强制要求；工程师们自行探索，至少直到 8 月中旬创始人信件发布后，情况变得模糊。AI 在新代码行中的占比温和上升，6 月份达到约 18% 的峰值，然后到 10 月回落至 8%，因为蜜月期消退。这就是“领导层打开了大门”在实践中的表现：不是一次离散的推动，而是一个持续的绿灯。2025 年下半年的下降是评估，而非失败：工程师们用当时可用的模型尝试了 Claude，认为它尚未证明其摩擦的合理性，于是退出了。如果猫薄荷是烂的，那么让猫去吃就更难了。 第二阶段始于 2025 年 10 月，Claude Code 的“缰绳”改进。当月有 7 名新采用者，背后没有模型发布；仅工具质量就推动了指针。11 月和 12 月是暂停期（尽管一些工程师利用假期以个人身份尝试了这些工具）。随后 Claude 4.5 在 12 月底发布，采用率在 2026 年 1 月回升，新增 8 名采用者，AI 在新代码行中的占比到 1 月升至 18%。 每月 AI 提交次数与累计使用 AI 的工程师数 *至少有一次 AI 归因提交的工程师，累计值。每一次阶跃变化都与一次能力事件对齐，而非按时间表平稳变化。* Opus 4.6 于 2026 年 2 月 5 日（星期四）发布。我们 Claude Code 遥测中的会话率起飞点出现在 2 月 11 日至 13 日：这是继星期四发布、周五及周末“烘焙”之后第一个完整工作周。每月不同的 Claude Code 用户在 1 月、2 月和 3 月几乎持平（59、63、64）。每位用户的会话数在同一窗口内增长了 3.3 倍（21、35、70）。AI 在新代码行中的占比从 1 月的 18% 升至 2 月的 46%，再到 3 月的 65%。 我们一直称之为“委托的信心”。同样的工程师，同样的工具，访问的是同一模型家族，只是改变了使用方式。他们不再咨询或密切监控每一步，而是开始委托。提升来自每位用户的强度，而非启用更多人数。 Opus 4.6 前后的工程师数量、会话次数与 PR 次数 *第一季度的证据，每个面板一个数量级：工程师数量几乎没变，每位工程师的会话数爆炸式增长，而按模型分组的已提交 PR 显示委托具体落在了 Opus 4.6 上。* 虽然中位数工程师的 PR 吞吐量相比 2 月前的基准线（称该基准线为 1.0x）增长了约 45%，但分布顶端的移动要大得多。P75 从约 1.8 倍基准线升至约 2.9 倍，相对增长约 +64%；我们活跃工程师的周最大值从 2 月前的 3.2 倍至 6.4 倍基准线范围，升至 4 月的 7.7 倍至 12.3 倍范围。底部几乎没动（P25 从约 0.5 倍基准线升至约 0.8 倍）。AI 的提升集中在分布顶端。它不是一股自动提升每位工程师的普遍浪潮，这没问题，因为并非所有工程工作都属于 AI 加速的范畴。正如 Charity 所说，你越接近接触磁盘上的字节，你就越需要以怀疑的眼光审慎地审查*一切*。 在我们整个 10 年历史上，我们从未有过每周有十多名工程师每人交付 7 个以上 PR 的情况，直到 2026 年 3 月。2 月前，每周有两到四名工程师达到七个或更多 PR；2 月份是三到七人，3 月份是七到十二人，4 月份是八到十六人。这是全新的，并且现在已成为常态。而且顶部的工程师并非固定阵容；3 月和 4 月选出的前十二名群体只有大约一半重叠。这是一个轮流登上新上限的流动阵容，而不是少数超级用户扛着所有人。 每周合并的 PR *每周合并的 PR（总数/AI 归因/无归因）以及每种划分下每位工程师的每周分布，2025 年 9 月至 6 月 22 日那一周。每周每位工程师超过 20 个 PR 的顶部尾部出现在 3 月并持续存在；5 月的凹陷是冻结周，而非衰退。机器人已排除，包括 autobot。* 高峰工作日的非 AI 合并在整个窗口期大致稳定在 25-30 个；人类在其最佳日子并未放慢速度为 AI 让路。但在组织级别的每周层面，非 AI 提交哈希数量显著下降，从每周约 120 个 PR 提交