上下文切换的真实成本：500万GitHub PR揭示了什么
我们综合了500万+个PR的数据，测量开发者上下文切换的真实成本–结果并不在你预期的地方。
By Ellis Keane · 2026-03-29
大多数文章引用的上下文切换成本–来自Gloria Mark在UC Irvine研究的"中断后重新集中注意力需要23分钟"–是真实研究的真实发现。但该研究在2008年测量的是普通知识工作者，而非软件工程师。用23分钟乘以假设的中断次数来产生惊人年度损失数字的博客文章产业（总是配有某人捂头的股票照片），正在做原始研究从未打算做的事。
我对这个问题有切身体会。在上一家公司，我花了–这不是夸张–某些天80到100%的时间只是充当一个人肉路由器。不是在写代码，不是在审查它。而是在人与工具之间传递信息，因为没有任何一个系统能将它们连接起来。那段经历是我们创建Sugarbug的部分原因，但也是我对标准上下文切换成本计算器持怀疑态度的原因。它们衡量中断，却不衡量你整天忙碌却从未触及原本该做的事情的那些日子。
因此，我们想知道上下文切换在工程工作中的真实代价–不是抽象的开发者生产力术语，而是用团队每天产出的实物来衡量：pull request。我们综合了涵盖数千个开源项目超过500万个PR的三项大规模研究结果，并研究了究竟是什么驱动了pull request的审查时间。
主要发现：代码审查中最昂贵的上下文切换不是打断你工作流的Slack通知。而是在审查队列中躺了一天的pull request，在问题终于到来时迫使作者重建整个心智模型。
我们使用的数据集
我们没有构建自定义爬虫单独分析10,000个PR。我们综合了两项同行评审研究和一个大型行业数据集的发现，然后相互验证它们的结论。
stat: "3.35M" headline: "Zhang等人分析的pull request数量" source: "Pull Request Latency Explained: An Empirical Overview (Empirical Software Engineering, 2022)"
三个主要数据集：
我们将这些数据与2024年DORA DevOps现状报告和Atlassian 2024年开发者体验报告（调查了2100多名开发者关于上下文切换、开发者生产力及人文因素）进行了交叉参照。
队列才是真正的杀手
Zhang等人发现，PR获得第一个响应所需的时间–第一条评论、第一次审查、任何第一次响应–解释了PR总生命周期58.7%的方差。这是数据集中观察到的最强预测因子–领先于PR大小、代码复杂度或更改文件数量！差距悬殊。
代码审查中上下文切换的最大成本不是切换本身–而是在所有人都忙于切换其他事务时形成的队列。
想想这在实践中意味着什么。工程师上午10点开了一个PR。指定的审查者正深陷于自己的功能分支，或者在开会，或者在处理Slack消息（说实话，可能三者都有且按顺序发生）。PR就这样等着。到下午3点有人拿起它时，作者已经完全切换到了其他事情。现在审查者有问题，这意味着作者必须切换回五小时前写的代码，重建心智模型并响应。回复在下午4:30到达，但审查者已经下班了。
PR又老化了一天。
数据表明这更多是一个排队问题而非纪律问题–而该队列的上下文切换成本以中断计算器完全忽略的方式不断累积。
小PR救不了你
你以前听过这个说法：小PR审查更快，所以保持PR小。这没有完全错，但效果大小（真的）比你预期的要小。
Adadot对30万+个PR的分析发现PR大小与lead time之间的Kendall tau相关系数仅为0.06–尽管研究没有报告总体数字的置信区间，这是一个微弱的关联。100行以下的PR有大约80%的概率在一周内完成，这听起来不错，直到你意识到这与一个在某人的审查队列中躺了六天的PR完成率相同！
stat: "0.06" headline: "PR大小与lead time的相关系数" source: "Adadot对约30,000名开发者的30万+个PR分析（2023）"
更有趣的发现是：这个相关性在不同组织间差异悬殊，从0.1到近0.7不等，取决于公司。这表明PR大小本身并不是瓶颈–围绕PR的审查文化和流程才是。拥有强健审查节奏的团队可以高效处理较大的PR。将审查视为事后考虑的团队在任何大小的PR上都会举步维艰。
SmartBear/Cisco代码审查研究的400行阈值仍然是一个有用的启发式准则–Adadot的数据也发现超出该范围后审查参与度下降。但在不修复基础审查节奏的情况下优化小PR（我对每位尝试过的工程管理者都带着真诚的感情说这句话），不过是在下沉的船上重新排列躺椅。
所有人同时在审查所有东西
多重审查研究发现62%的pull request涉及同时审查多个PR的开发者。更重要的是，他们发现了统计显著的相关性：每位审查者并发审查越多，PR解决延迟越长。
62%的pull request涉及同时审查多个PR的开发者–多重审查与更长的解决时间直接相关。 attribution: 多重审查pull-request研究，760个项目中的180万个PR
这个机制直观易懂（即使研究作为观察性研究无法证明因果关系的方向）。审查者拿起PR #1，通读diff，开始形成关于代码试图做什么的心智模型。然后一条通知到来–PR #2需要审查因为它阻塞了部署。审查者切换。当他们回到PR #1时，必须重读一半diff，因为心智模型已经衰减。
将这种情况扩展到一个八人工程团队，每人有两到三个开放的PR，每人为两到三位同事进行审查，协调开销就开始自我解释了。另外，2024年DORA报告发现"高绩效"群体从31%缩减至22%，而低绩效群体从17%增长至25%。DORA没有将PR审查并发性单独列为一个因素，但协调开销的增加是这一转变的一个合理因素。
上下文切换成本估算的错误所在
让我直接谈谈在上下文切换成本文章中广泛流传的"每位开发者每年5万美元"这个数字。这些估算背后的方法论大多是：取23分钟的重新集中时间，乘以估计的每日中断次数（通常在6到15之间，取决于作者感觉多戏剧化），乘以开发者每小时费率，然后年化。
问题不在于数学错了。问题在于它将所有上下文切换视为等同。从深度编码切换到一条询问团队午餐在哪里的Slack消息–这是上下文切换。从审查一个PR切换到审查完全不同代码库中的另一个PR–这也是上下文切换。但认知成本根本无法相比，把它们压缩成单一的每小时费率掩盖了真正损害发生的地方。
具体来说：在我上一份工作中，典型的一天意味着在Notion、Linear、Mattermost、Proton Mail、Proton Calendar、Discord、Twitter、Farcaster以及无数个Telegram和Signal频道之间切换–我确信还忘了半打。现在我只用少数几个（Signal、Obsidian、Figma、GitHub、电子邮件、日历）。每次切换的成本没有改变。改变的是有多少个上下文在排队等待注意–以及其中哪些真正重要。
PR数据表明，昂贵的切换是那些创造队列的切换，而不是那些打断工作流的切换。被即时（几分钟内）ping去审查PR并快速完成50行审查的开发者–那是高回报的短暂中断。将审查请求与其他四个一起排队、明天再处理的开发者–这对审查者来说是更长的中断，但对作者和团队来说产生了更大的成本。
成本计算器所测量的
- 个人中断 – 某人的工作流被打断的频率
- 重新集中时间 – 返回上一个任务需要多长时间
- 乘以每小时费率 – 巨大可怕的年度数字
PR数据实际显示的
- 队列形成 – 等待第一个响应的PR
- 审查并发性 – 审查者同时处理多个PR
- 级联延迟 – 作者的上下文切换放大审查者的延迟
这对你的团队意味着什么
如果你试图减少团队开发者的上下文切换成本，实际答案很无聊–这可能是为什么关于它的文章不多。不是一个工具。不是有认证计划的流程框架。而是审查节奏。（我知道，我知道。从没有人因为改善审查节奏而获得晋升。）
LinearB 2025年工程基准测试，从3,000个组织的610万个PR中得出，发现实现精英周期时间（2.5天以内）的团队共享一个特征：他们快速审查PR。不是因为他们的PR更少，或者他们的PR更小（尽管通常如此），而是因为在几小时内响应审查请求是团队规范，而不是事后考虑。
值得一提的是，Ben和我–一个两人团队–PR首次响应平均以分钟计，而非小时。这不是关于纪律的炫耀（我们不是）。这是一个团队协议：审查请求是你不排队的那个通知。CI操作和自动化测试处理机械检查，这意味着人工审查–需要真正上下文的部分–更短且立即发生。协议先来。工具让它可持续。
实际上，这意味着：
- 衡量首次响应时间，不仅仅是周期时间。 如果你在跟踪DORA指标，添加这一项。这是PR吞吐量最强的单一预测因子（根据Zhang等人，解释生命周期方差的58.7%）。
- 限制审查并发性。 如果审查者有三个待处理的审查请求，第四个无论如何都不会得到好的审查。多重审查数据显示了并发性与延迟之间的明确关联。从两个并发审查的WIP限制开始并监测影响。
- 停止单独优化PR大小。 小PR很好，但它们不能替代实际审查事物的团队。每天生产二十个50行PR却有48小时审查积压的团队，比生产五个200行PR且当天审查的团队更糟糕。
- 承认审查是真正的工作。 Atlassian 2024年调查发现69%的开发者每周因低效损失8小时以上。审查不必是那些低效之一–但只有当它被视为一等工程活动而非"真正"工作的中断时才成立。
这里有一部分是生产力工具领域中没有人（包括我们，公平地说）想大声说出来的：工程团队中上下文切换成本最有影响力的干预不是工具。而是关于PR何时被审查的团队协议。如果你团队的隐性规范是"我有空隙时再去审查"，没有任何工具能阻止PR数据揭示的排队级联。
工具有帮助–不打开四个浏览器标签就能看到PR的完整上下文，减少了每次切换的认知负荷；显示哪些审查正在阻塞他人的工作有助于优先排序。但核心杠杆是协议，而协议是免费的。不需要23分钟计算器。
最昂贵的上下文切换不是打断你工作流的通知。而是在队列中躺了一天的审查请求，在问题终于到来时迫使作者重建心智上下文。
获取信号情报，直达您的收件箱。
常见问题
Q: 每位开发者每年的上下文切换成本是多少？ A: 各方估算不一，但基础研究远比大多数文章所暗示的薄弱。Gloria Mark在UC Irvine的研究发现每次中断后需要23分钟重新集中注意力，Atlassian 2024年针对2100多名开发者的调查发现69%的人每周因低效损失8小时以上。具体金额在很大程度上取决于薪资假设、中断频率以及你如何定义"切换"–这也是我们专注于PR数据的原因。
Q: Sugarbug能帮助工程团队减少上下文切换吗？ A: 能。Sugarbug将Linear、GitHub、Slack和Figma等工具连接到单一知识图谱，让工程师无需打开四个标签页就能看到任务的完整上下文–相关PR、Slack讨论、Figma评论。目标是减少切换次数，而不是减少工具数量。
Q: 什么是最小化审查延迟的理想pull request大小？ A: Adadot对30万+个PR的分析研究发现，100行以下的PR在一周内完成的概率约为80%。超过400行后，审查质量和完成速度都会下降。较小的PR还能减轻审查者的上下文切换负担。
Q: Sugarbug能与GitHub pull requests集成吗？ A: 能。Sugarbug采集GitHub活动–PR、评论、审查和状态变更–并将其与其他工具中的相关信号关联起来。如果一个Linear任务产生了PR，而一个Slack话题讨论了实现方案，Sugarbug会自动将三者连接起来。
Q: "重新集中需要23分钟"这一统计数据出自哪里？ A: 它来自Gloria Mark在UC Irvine的研究，发表于"The Cost of Interrupted Work: More Speed and Stress"（CHI 2008）。该研究发现工作人员在中断后平均需要23分15秒才能回到原来的任务。值得注意的是，该研究观察的是普通知识工作者，并非专门针对软件工程师。