情境切換的真實成本：500萬筆GitHub PR告訴我們的事
我們整合超過500萬筆PR資料，衡量開發者情境切換的真實成本 – 結果和你想的完全不一樣。
By Ellis Keane · 2026-03-29
多數文章引用的情境切換成本 – 來自 Gloria Mark 在 UC Irvine 研究的「被打斷後需要 23 分鐘才能重新聚焦」 – 確實是來自真實研究的真實發現。但它測量的是 2008 年的一般知識工作者，不是軟體工程師。而那些把 23 分鐘乘上假設的打斷次數、算出驚人年度損失金額的部落格文章產業鏈（永遠配著一張抱頭崩潰的圖庫照片），其實正在做原始研究從未打算做的事。
我對這個問題有切身之痛。在上一家公司，我花了 – 這絕對不是誇飾 – 某些天 80% 到 100% 的時間純粹在當人肉路由器。不是在寫 code，也不是在 review code，而是在人和工具之間搬運資訊，因為沒有任何單一系統把它們連起來。那段經歷是我們打造 Sugarbug 的部分原因，但也是為什麼我對那些標準的情境切換成本計算器抱持懷疑態度。它們測量的是「打斷」本身，卻沒有算進你整天忙碌、卻從來沒回到原本該做的那件事的那些日子。
所以我們想知道，情境切換在工程工作中的實際代價到底是多少 – 不是用抽象的開發者生產力來談，而是用團隊每天產出的具體成果來衡量：pull request。我們整合了三項大型研究的發現，涵蓋數千個開源專案中超過 500 萬筆 PR，去看到底是什麼因素在拖延 PR 的審查時間。
主要發現：最昂貴的情境切換，不是打斷你心流的 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 年開發者體驗報告（調查了 2,100 多位開發者關於情境切換、開發者生產力及人因面向）進行交叉比對。
佇列才是真正的殺手
Zhang 等人發現，一個 PR 從建立到收到首次回應 – 第一則留言、第一次審查、任何第一次互動 – 所需的時間，可以解釋 PR 總生命週期 58.7% 的變異數。這是資料集中觀察到最強的預測因子 – 遠遠超過 PR 大小、程式碼複雜度或變更檔案數！完全不在同一個量級。
Code review 中情境切換的最大成本，不是切換本身 – 而是當大家都在忙著切換其他事情時，慢慢堆出來的那個審查佇列。
想想這在實務上代表什麼。一位工程師在早上 10 點開了一個 PR。指定的審查者正深陷在自己的 feature branch 裡，或是在開會，又或者在處理 Slack 訊息（老實說，很可能三件事輪流來）。PR 就這樣擱著。等到下午 3 點有人終於來看時，作者早就跑去處理完全不同的事了。現在審查者有問題，這意味著作者必須切回五個小時前寫的 code，重建心智模型，然後回覆。回覆在下午 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，開始建構「這段 code 到底想做什麼」的心智模型。然後通知來了 – PR #2 需要審查，因為它卡住了一個 deploy。審查者切過去。回到 PR #1 時，必須重讀一半的 diff，因為心智模型已經衰退了。
把這種情境放大到一個八人工程團隊，每個人同時開兩三個 PR，各自幫兩三位同事做審查，協調成本就不言而喻了。另外，2024 年 DORA 報告發現「高績效」群體從 31% 縮減到 22%，而低績效群體則從 17% 增加到 25%。DORA 並沒有將 PR 審查並行度單獨列為因素，但日益增加的協調成本是造成這種轉變的合理原因之一。
情境切換成本估算錯在哪
讓我直接談談那些在情境切換成本文章中廣泛流傳的「每位開發者每年損失 5 萬美元」這個數字。這類估算背後的方法論通常是：拿 23 分鐘的重新聚焦時間，乘上估計的每日打斷次數（通常在 6 到 15 次之間，取決於作者想寫得多聳動），再乘上開發者時薪，然後年化。
問題不在於數學算錯了。問題在於它把所有情境切換都當成同一種成本。從深度寫 code 切到一則問團隊午餐吃什麼的 Slack 訊息 – 這是一個情境切換。從審一個 PR 切去審另一個完全不同 codebase 的 PR – 這也是情境切換。但兩者的認知成本根本無法相提並論，把它們扁平化成單一時薪費率，反而掩蓋了真正造成傷害的地方。
具體來說：在我上一份工作，典型的一天意味著要在 Notion、Linear、Mattermost、Proton Mail、Proton Calendar、Discord、Twitter、Farcaster，以及數不清的 Telegram 和 Signal 頻道之間切來切去 – 我確定還漏掉了半打。現在我只用少數幾個（Signal、Obsidian、Figma、GitHub、email、行事曆）。每次切換的成本並沒有改變。改變的是有多少個情境正在排隊等待注意 – 以及其中哪些才是真正重要的。
PR 資料顯示，昂貴的切換是那些會製造佇列的切換，而不是打斷心流的切換。一個開發者被 ping 後幾分鐘內就審完一個 50 行 PR – 這是短暫打斷、高回報。一個開發者把審查請求跟其他四個一起排進佇列、明天才處理 – 這對審查者來說是較長的打斷，但對作者和整個團隊來說，製造了大得多的成本。
成本計算器測量的是什麼
- 個別打斷 – 某人的心流被打斷的頻率
- 重新聚焦時間 – 回到上一個任務需要多久
- 時薪乘數 – 嚇人的年度大數字
PR 資料實際揭露的是什麼
- 佇列形成 – PR 等待首次回應
- 審查並行度 – 審查者同時處理多個 PR
- 級聯延遲 – 作者的情境切換疊加審查者的延遲
這對你的團隊意味著什麼
如果你想降低團隊中開發者的情境切換成本，實務上的答案其實很無聊 – 這大概也是為什麼很少人寫這個。不是某個工具，不是帶有認證計畫的流程框架，而是審查節奏。（我知道，我知道。從來沒有人因為改善了審查節奏而升職。）
LinearB 2025 年工程基準報告（取自 3,000 個組織的 610 萬筆 PR）發現，能達成菁英級 cycle time（低於 2.5 天）的團隊有一個共同特徵：他們審查 PR 的速度很快。不是因為 PR 比較少，也不是因為 PR 比較小（雖然通常確實比較小），而是因為「在幾小時內回覆審查請求」是團隊常態，不是事後才想到的事。
順帶一提，Ben 和我 – 一個兩人團隊 – 平均首次 PR 回應時間是以分鐘計，不是小時。這不是在炫耀我們多有紀律（我們並沒有）。這是一個團隊約定：審查請求是唯一你不排進佇列的通知。CI actions 和自動化測試負責處理機械性的檢查，這意味著人工審查 – 那個需要實際情境脈絡的部分 – 會更短且能立即進行。約定先來，工具只是讓它變得可持續。
實務上，這意味著：
- 追蹤首次回應時間（time-to-first-response），不只看 cycle time。 如果你在追蹤 DORA 指標，把這項加進去。它是 PR 吞吐量最強的單一預測因子（根據 Zhang 等人，可解釋生命週期變異的 58.7%）。
- 限制審查並行度。 如果審查者手上已經有三個待處理的審查請求，第四個反正也不會得到好的審查。多重審查資料顯示了並行度與延遲之間的明確關聯。可以從每人同時兩個審查的 WIP 限制開始，觀察影響。
- 停止孤立地最佳化 PR 大小。 小 PR 是好事，但它們不能取代一個真正會去審查東西的團隊。一個每天產出二十個 50 行 PR、但積壓了 48 小時審查待辦的團隊，比一個每天產出五個 200 行 PR、當天就審完的團隊還要糟。
- 承認審查是正式的工程工作。 Atlassian 2024 年調查發現 69% 的開發者每週因低效率損失超過 8 小時。審查不一定要成為這些低效率的來源 – 但前提是它必須被視為第一級的工程活動，而不是對「正事」的打斷。
接下來這部分，是生產力工具領域裡沒有人（老實說，包括我們自己）願意大聲說出來的：對工程團隊情境切換成本最有效的介入措施，不是一個工具。而是團隊對於「何時該審 PR」的共同約定。如果你們的隱性規範是「等我有空檔再來做 review」，那再多的工具也無法阻止 PR 資料所揭露的佇列級聯反應。
工具確實有幫助 – 能在不開四個瀏覽器分頁的情況下看到 PR 的完整脈絡，會降低每次切換的認知負荷；而凸顯出哪些審查正在阻礙其他人的工作，也有助於排定優先順序。但核心的槓桿是約定，而約定是免費的。不需要什麼 23 分鐘計算器。
最昂貴的情境切換，不是打斷你心流的通知。而是在佇列裡卡了一整天的審查請求，迫使作者在問題終於出現時必須重建心智脈絡。
讓訊號情報直接送達你的信箱。
常見問題
Q: 每位開發者每年的情境切換成本大概多少？ A: 估算方式很多，但底層研究其實沒有多數文章暗示的那麼扎實。UC Irvine 的 Gloria Mark 研究指出，每次被打斷後平均要 23 分鐘才能重新聚焦；Atlassian 2024 年針對 2,100 多位開發者的調查則顯示，69% 的人每週因低效率損失超過 8 小時。具體金額很大程度取決於薪資假設、打斷頻率，以及你如何定義「切換」 – 這也是我們改看 PR 資料的原因。
Q: Sugarbug 能幫助工程團隊減少情境切換嗎？ A: 可以。Sugarbug 把 Linear、GitHub、Slack、Figma 等工具連結成單一知識圖譜，讓工程師不用開四個分頁，就能看到任務的完整脈絡 – 相關 PR、Slack 討論、Figma 留言。目標是減少切換次數，而不是減少工具。
Q: 為了將審查延遲降到最低，理想的 PR 大小是多少？ A: 根據 Adadot 對超過 30 萬筆 PR 的分析，低於 100 行程式碼的 PR 大約有 80% 機率在一週內完成。超過 400 行後，審查品質和完成速度都會下滑。較小的 PR 也能減輕審查者的情境切換負擔。
Q: Sugarbug 有整合 GitHub pull request 嗎？ A: 有。Sugarbug 會抓取 GitHub 上的活動 – PR、留言、審查和狀態變更 – 並把它們連結到你其他工具中的相關訊號。如果某個 Linear issue 衍生出這個 PR，而 Slack 討論串又在辯論做法，Sugarbug 會自動把三者串起來。
Q: 「重新聚焦要 23 分鐘」這個數字是從哪來的？ A: 這來自 Gloria Mark 在 UC Irvine 的研究，發表於《The Cost of Interrupted Work: More Speed and Stress》（CHI 2008）。該研究發現，工作者被打斷後平均需要 23 分 15 秒才能回到原本的任務。值得注意的是，該研究觀察的是一般知識工作者，而非專門針對軟體工程師。