工程團隊內部每天發生幾十次交接，而且幾乎沒有人把它們叫做交接。最高頻的兩種是 pull request 與值班換班。它們的頻率高到讓單次品質的微小改善產生可觀的累積效果，也高到讓單次的浪費被複利放大。
PR 是一次完整的交接，只是很少人這樣寫它
開一個 PR 的動作，本質是把「一段變更 ＋ 為什麼要這樣改 ＋ 怎麼確認它是對的」交給另一個人，並請他承擔一部分審核責任。用這個框架看，多數 PR 描述的問題就一目了然：它只交了第一項。
一份能真正被審的 PR 描述要回答四件事。為什麼——這個變更解決什麼問題，連結到 issue 或 spec；reviewer 沒有這個資訊時，只能審「程式碼寫得漂不漂亮」，審不了「這是不是對的解法」。做了什麼決定——如果有取捨（為什麼不用另一種寫法、為什麼加了這個看起來多餘的檢查），寫三行；這是把決策依據夾帶在交接物裡最便宜的時機。怎麼驗——reviewer 或 QA 要怎麼確認它有效，包含手動步驟或該看哪個測試。風險與回滾——這個變更最可能在哪裡出錯，怎麼回退。
PR 的大小本身就是交接品質的一部分。一個改了四十個檔案、混了重構與功能與格式化的 PR，不是「工作量大」，是一次無法被有效審查的交接——reviewer 的認知負荷超過閾值後，review 會退化成看格式。一個 PR 一個意圖，是為了讓交接的接收端還能承載。
Review 佇列是流動效率的主要漏水點
DORA 的價值流對映指南把「交接摩擦」列為需要特別關注的環節，理由是工作在角色之間移動時最容易產生誤解與延遲。實務量測支持這個判斷：多數團隊量到的流動效率（flow efficiency，實際處理時間 ÷ 總流經時間）落在個位數到大約 15%，也就是說工作絕大多數時間在排隊，而不是在被處理。PR 等待 review 通常是這條佇列裡最大的一段。
這件事的重要性在於它改變了優化的方向。把實作速度提高一倍，對總週期時間的影響可能不到 10%；把 PR 平均等待時間從兩天壓到兩小時，效果大得多。而後者主要不是靠「大家勤快一點」，是靠交接設計：PR 小到可以在十五分鐘內審完、描述完整到 reviewer 不需要來回問、明確指定 reviewer 而不是丟給整個團隊（沒有指定接收者的交接沒有人負責）。
值得注意的是 review 的方向性也是交接品質的一部分。Review 意見如果只寫「這裡不對」，就是一次低品質的反向交接；寫「這裡不對，因為 X，建議 Y，這點是阻擋合併的／這點只是建議」，才把上下文、理由與責任狀態一起交回去。
值班交接：Google SRE 的做法
Google 的 SRE 實務裡，值班工程師在班次結束時會寄一封交接信給下一位值班者。這件事看起來行政，實際上是整套 on-call 制度得以運作的黏著劑——沒有它，每一班都從零開始重新發現系統當下的狀態。
幾個可以直接借用的參數。Google SRE 明確的政策是把至少 50% 的 SRE 時間投入工程工作，剩下的部分裡值班不超過 25%；SRE Workbook 建議每個班次可處理的 actionable incident 以 2 到 3 件為可持續上限。這些數字是 Google 的內部政策而非普適最佳值（見 客觀檢視），但它們背後的邏輯可以外推：交接品質會隨值班者的疲勞程度線性下降，一個被 alert 轟炸整晚的人交不出一份可用的交接。
業界實務（例如 incident.io 的 on-call 指南）在格式上有兩個具體建議值得採用。第一，交接控制在 15 分鐘，能同步就同步、不能同步就留一份簡短書面 artifact；第二，交接摘要貼到整個團隊可見的共享頻道，而不是私訊給下一位值班者。第二點的理由是交接的本意就是讓上下文不困在單一個人的腦袋裡，私訊等於把它從一個人的腦袋搬到兩個人的腦袋。
交接內容的骨幹是四塊：進行中的事件（開啟中／已緩解但未解決／調查中——這三種狀態必須分開，「已緩解未解決」是最容易在交接中被誤認為已結案的一類）、持續關注事項（部署凍結、已知會亂叫的 alert、上游依賴的異常）、本班的變更紀錄、runbook 的更新。
Runbook：把值班交接變成資產而不是儀式
單次交接信只服務下一位值班者，寫完就過期。把每次值班學到的東西寫回 runbook，交接才會累積成資產：同樣的問題第二次發生時，處理時間從一小時降到五分鐘，而且不論誰值班都一樣。
Runbook 有一個容易被忽略的失效條件：沒有被實際執行過的 runbook 等於沒有 runbook。寫的時候覺得清楚的步驟，在半夜三點會發現缺了一個前置權限、指令參數過期了、或者那個 dashboard 已經被刪掉。把 runbook 在演練或非緊急時段跑過一次，是唯一可靠的驗證方式。骨架見 交接產物模板。
兩者的共同結構
PR 交接與值班交接看起來差很遠，結構卻一致：都需要明確的接收者、都需要「為什麼」而不只是「什麼」、都需要區分已完成與未完成、都需要一個讓上下文沉澱成資產的機制（PR 對應 ADR 與 commit 訊息，值班對應 runbook）。這個共同結構就是 好交接的六個共同要素 的內容。
延伸
- PR 描述模板與 runbook 骨架 → 交接產物模板
- Code review 在 AI 輔助開發裡為何更不能省 → 方法論支柱：可操作的工程紀律
- 流動效率、handoff delay 等指標怎麼量 → 對工作流與產品開發的幫助
- 回到全景 → Handoff 專欄首頁