交接的失敗模式有兩種方向：做得不夠，以及做得太多。第二種比較少被討論，但在有心導入交接紀律的團隊裡反而更常見——因為熱情通常朝著「寫更多文件」的方向去。
過度文件化：比沒有文件更糟的那一種
一份沒有人讀的文件只是浪費。一份沒有人維護但有人讀的文件是主動的傷害——讀者會相信過期的資訊，然後照著錯的步驟操作。runbook 裡那個已經被刪掉的 dashboard 連結、CLAUDE.md 裡那個已經改名的測試指令、spec 裡那個已經被否決但沒更新的決策，都會讓接手者花時間走一段確定是錯的路。
判準很簡單但很少人真的用：這份文件的預期更新成本，跟它被讀取的次數相比划得來嗎？ 一份一年被讀兩次、但需要每個 sprint 更新的文件，應該刪掉，把資訊移到會自然被維護的地方（測試、程式碼註解、CI 設定）。
推論出來的原則是：能被機器驗證的資訊不要寫成文件。「測試指令是 npm test」寫在文件裡會過期；寫成 CI 設定就不會，因為過期時 CI 會壞。文件應該留給無法被機器驗證的東西——為什麼、取捨、已否決的方案。
還有一種過度文件化的變體：每個階段都設交接關卡。設計交接要填表、需求交接要填表、實作交接要填表，每一關都增加一段等待。精實的立場在這裡值得完整引用——減少交接次數優於改善交接品質。改善交接品質是在優化一個本來就有損耗的環節；減少交接次數是直接消除損耗機會。這個優先順序常被忽略，因為「改善交接」聽起來積極，「取消一個交接關卡」聽起來像放棄品質。
文件不足與口頭交接
反方向的失敗更常見。口頭交接的問題不是它不精確——面對面溝通的頻寬其實很高——而是它只服務在場的人、不可審計、不可重播。三個月後沒有人記得那天走廊上講了什麼，而且從一開始就沒有第三個人知道。
Google SRE 值班交接的一個具體細節值得借用：交接摘要要貼到整個團隊可見的共享頻道，不是私訊給下一位值班者。理由是交接的本意就是讓上下文不困在單一個人腦中，私訊只是把它從一個人的腦袋搬到兩個人的腦袋。
隱性假設：最貴的不是缺資訊
缺資訊的交接會讓接手者卡住，然後他會來問——成本是一次中斷。雙方以為對過的資訊不會讓任何人卡住，所以錯誤會一路走到上線。
具體形式：設計師以為「當然會有 loading 狀態」，工程師以為「稿上沒畫就是不需要」；PM 以為「當然要支援分頁」，工程師以為「需求沒寫就是不用」；上一位值班者以為「那個 alert 大家都知道會亂叫」，接班者以為它是真的。
對策是把假設從「共識」降級成「待確認事項」再明說出來。這正是 handoff 模板 裡「已驗證的事實 vs 未驗證的假設」那一欄的用途，也是 接收者回述 最能發揮作用的地方——回述會逼出雙方理解的差異。
交接即甩鍋
這是最有社會性的一種反模式：交接被當成離開責任範圍的手段，而不是轉移責任的動作。典型形式是把一個問題「丟過牆」給下游團隊——丟給 QA、丟給 support、丟給維運——並在丟出去的瞬間認為它不再是自己的問題。
有一個乾淨的判準可以識別它：交接完成後，上游是否仍然需要回答關於它的問題？ 如果是，責任沒有真的轉移——上游只是把工作推走了，卻仍握著唯一能回答問題的知識。這種狀態最糟，因為下游要負責但沒有能力，上游有能力但不再負責。
另一個症狀是交接時的語氣：「這個我交給你了，有問題再找我」聽起來友善，實際上是把責任邊界模糊化。真正的責任轉移需要一個明確的生效時間點與一個可觀測的狀態改變——CODEOWNERS 換人、on-call rotation 換班、assignee 換名字。
文件與現實分岔
Token drift（設計檔的變數與程式碼常數各自演化）、runbook 腐爛、CLAUDE.md 裡的過期指令——這些是同一種失敗的不同外衣：曾經正確的交接物沒有被綁定到它描述的現實上。
結構性的對策只有兩種。一是讓文件成為單一事實來源並由它產生現實（design token 由設計檔產生程式碼常數，schema 由定義檔產生型別）；二是讓分岔會爆炸（runbook 的步驟寫成腳本並在 CI 或演練中跑過，過期就會失敗）。只靠「記得更新」的紀律不是對策，那是一種希望。
runbook 特別值得單獨提：沒有被實際執行過的 runbook 等於沒有 runbook。寫的時候覺得清楚的步驟，在半夜三點會發現缺一個權限。
AI 場景的三種新陷阱
前面所有反模式在 AI 場景都會重現，另外還有三種特有的。
把整段對話當交接。 傳遞完整對話歷史看起來是「無損」，實際上不是——它只是把「什麼重要」的選擇權推給下游的注意力機制去隨機決定。過長的 context 會稀釋關鍵指令。OpenAI 在 2026 年 4 月把 Agents SDK 的 nested handoff history 改為預設關閉，正是承認傳遞全部歷史是錯的預設值。交接應該是過濾器，不是水管。
把 AI 摘要當已驗證事實。 上游 agent 的一個推測經過摘要後，修飾語被磨平，下游把它當前提使用，再交接一次就成了系統的既定認知。摘要的本質就是丟掉不確定性標記，所以必須用結構強制保留——「已驗證 vs 未驗證」分欄，不是可選欄位。
Compaction 靜默丟失關鍵細節。 壓縮必須根據「現在看起來重要」來取捨，而交接損耗的本質正是「當時不覺得重要的東西後來很重要」。Anthropic 在 context engineering 的文章裡明確指出過度激進的摘要會丟掉後來才變關鍵的細節。這是結構性問題而非調參問題，目前唯一的部分解是在壓縮之前就把關鍵狀態外化到檔案（structured note-taking），不要指望壓縮演算法替你判斷什麼重要。
還有一個容易被忽略的組合陷阱：用 AI 產生交接文件。這件事本身沒問題，甚至很有效率，但要記住它漏掉的部分正是最危險的部分——而漏掉的東西不會出現在產出裡，所以你不會發現。AI 寫的交接文件需要由知道實情的人補一輪「它沒問我但我知道很重要的事」。
一個檢查清單
導入交接紀律時，這幾個問題可以定期自問：
哪一份文件已經三個月沒更新但仍在被引用？把它刪掉或標記為過期。哪一個交接關卡從來沒有攔下過任何問題？取消它。哪一次交接之後，上游仍然每週被問到問題？那次交接沒有真的完成。哪一段接縫的 handoff delay 最長？只在那裡投資。
延伸
- 正面版本：六個共同要素 → 好交接的六個共同要素
- 量測哪一段接縫在漏水 → 對工作流與產品開發的幫助
- AI 交接的正確結構 → Agent 之間的 task handoff
- 回到全景 → Handoff 專欄首頁