人員交接是資訊損耗最嚴重的一類，原因結構性：其他交接轉移的是某一件工作的上下文，人員交接要轉移的是一個人累積數月或數年的判斷力。而判斷力的大部分是隱性知識——業界常見的估計是組織真正知道的東西裡，有八成以上從未被寫下來（這個比例是知識管理領域的常引數字而非嚴謹量測，見 客觀檢視）。
隱性知識具體長什麼樣：哪個服務在月結時會變慢、哪段程式碼看起來該重構但有理由不動、哪個供應商的技術支援要找誰才有用、哪個客戶提到某功能時要特別小心、哪個測試偶爾會 flaky 但不是真的壞。這些東西不會出現在任何文件裡，因為擁有它的人不覺得它是知識——對他來說那只是常識。
Bus factor：把風險變成一個數字
Bus factor 是指「團隊裡要有多少人同時消失，某個專案才會停擺」。這個粗糙的指標之所以有用，是因為它把一個模糊的組織風險變成一個可以追蹤、可以設定目標的數字。實務上的共識是：關鍵元件的 bus factor 應該至少為 3；等於 1 或 2 代表存在嚴重的知識轉移缺口。
要注意的是 bus factor 有一種隱性形式，比離職更常見也更難察覺：人還在，但只有他能改那個模組。這種情況不會觸發任何警報，因為工作照樣完成——只是每次那個模組要改動時，都必須排到那一個人的檔期，而他也因此永遠沒有時間把知識交出去。
近似的量測方式是看 git 歷史裡每個目錄的作者集中度：某個模組九成的 commit 來自同一個人，就是一個訊號。這個代理指標會被 monorepo 結構、大規模格式化 commit、以及 AI 代寫但掛在單一作者名下的 commit 污染，所以它適合當成「哪裡值得去看一眼」的雷達，不適合當 KPI。
四階段交接：從盤點到獨立驗證
第一階段：盤點。 離職通知發出後的第一件事不是寫文件，是列清單——他擁有哪些系統與模組（CODEOWNERS 是起點但通常不完整）、哪些定期任務或 cron 只有他知道、哪些外部關係（供應商、客戶、其他團隊的對接人）掛在他身上、哪些口頭承諾還沒兌現。最後一項最常被漏，也最容易在他離開後變成信任問題。
第二階段：書面化。 把盤點出來的東西寫成可查閱的形式：runbook（怎麼操作）、ADR（為什麼這樣設計）、決策紀錄（哪些方案被否決過）。這一階段有一個明確的邊界要守住——不要試圖書面化所有隱性知識，那是做不到的，而且會消耗完剩下的交接時間。書面化應該優先處理高風險 × 低頻率的知識：一年只做一次、做錯代價很大、只有一個人知道怎麼做的那些事。
第三階段：影子期與反向影子期。 隱性知識只能透過人際互動轉移——共同解決問題、旁觀決策、聽故事、討論假設情境。影子期是接手者旁觀離開者工作；反向影子期是接手者實際動手、離開者旁觀並在必要時介入。第二個方向才是真正在轉移判斷力，也是最常被跳過的一步（因為它比較慢，而且看起來像在浪費資深工程師的時間）。跳過它的後果是：接手者知道流程，但沒有在有安全網的情況下練習過判斷。
第四階段：獨立驗證。 這是整個交接的驗收關卡，而且它的判準不是「文件都交出來了」，是接手者獨立完成一次具代表性的真實任務——獨自處理一次該系統的事件、獨自完成一次部署、獨自回答一次來自其他團隊的技術問題。沒有通過這關的交接，只是把文件從一個地方搬到另一個地方。
這四階段對應的其實就是 接收者回述 在人員交接場景的放大版：驗證交接成功的方法永遠是看接收端能不能產出等價結果，不是看發送端交了多少東西。
常態化才是真正的解法
上述四階段是離職發生時的補救措施，而補救措施的品質上限受限於剩下的時間（通常兩到四週，而且離職者的動機正在下降）。真正降低人員交接成本的做法都是在平時就進行的：輪流值班（強迫每個人都要能處理不熟的系統）、pair programming 與 mob programming、刻意輪調模組所有權、code review 跨模組指派、以及最便宜的一項——要求每個非顯然的決策留下一則 ADR。
這些做法的共同點是把人員交接從一次性的大事件，攤成日常的小額支付。這也是 AI 時代一個值得注意的變化：當 CLAUDE.md、spec、ADR 這類文件同時是給 AI agent 用的交接載體時，維護它們就有了立即的回報，而不只是為了某天有人離職（見 人↔AI 的上下文交接）。平時就有理由維護的文件，才是離職時真的能用的文件。
一個反直覺的觀察
交接品質最差的離職，通常不是走得匆忙的那些，而是走得很客氣、雙方都想維持體面的那些。真正需要交出來的資訊往往帶著尷尬——這個系統其實有個沒人敢動的地雷、這個決策當初是被業務逼出來的、這段程式碼我一直知道有問題但沒時間修。一個只問「還有什麼要交接的嗎」的交接會議，得到的答案永遠是「應該都寫在文件裡了」。
有效的問法是具體且假設有問題存在的：「這個系統最可能在什麼情況下出事？」「哪個部分你會建議接手者不要碰？」「有沒有什麼你一直想修但沒修的？」「如果我照文件操作，最可能在哪一步踩到坑？」
延伸
- 交接損耗的來源與三種成本 → 交接的本質
- 值班輪調如何順帶提高 bus factor → 工程內部：PR review 與值班交接
- 交接清單與 runbook 模板 → 交接產物模板
- 過度文件化的反面風險 → 反模式與陷阱
- 回到全景 → Handoff 專欄首頁