一次交接同時轉移三樣東西，而且這三樣東西的轉移難度是遞增的。
**上下文（context）**是現在的狀態：做了什麼、還剩什麼、東西放在哪、怎麼跑起來。這一層最容易寫下來，也是絕大多數交接文件唯一真正處理的一層。
**責任（accountability）**是「出事的時候誰要回答」。這一層無法靠文件轉移，只能靠一個明確的宣告加上一個可觀測的狀態改變——CODEOWNERS 換人、on-call rotation 換班、Jira assignee 換名字。責任沒有被明確轉移的交接，會退化成一種特別糟的狀態：兩個人都以為對方負責，而系統以為有人負責。
決策依據（rationale）是「為什麼是這樣，而不是那樣」。這一層最難轉移，因為它通常不存在於任何 artifact 裡——它存在於交出者腦中那些已經被否決的選項、試過但失敗的路徑、以及當初的約束條件（有些約束早已消失，有些還在）。決策依據缺失的後果不是「接手者不知道怎麼做」，而是接手者會做出不同的決策，而且他不知道自己正在偏離。
資訊損耗率：交接品質的操作定義
把交接看成一條有損管道，就能問一個可操作的問題：接手者要花多少時間，才能做出跟交出者同等品質的決策？
這個時間可以當成交接品質的代理指標。我在 對工作流與產品開發的幫助 裡把它叫做 time-to-first-safe-change：接手者第一次獨立做出一個安全變更所需的時間。它比「文件寫了幾頁」有意義得多，因為它量的是結果而不是產出。
損耗來自三個地方。第一是隱性知識（tacit knowledge）——Polanyi 的老概念，指那些「知道怎麼做但說不出來」的判斷。哪個服務半夜特別脆弱、哪段程式碼看起來可以重構但其實有理由、哪個客戶問到某個功能時要特別小心。第二是隱性假設：交出者認為理所當然所以不寫，接手者不知道所以不問。第三是決策理由不在產物裡：程式碼記錄了「做了什麼」，永遠不記錄「為什麼不做另一件事」。
Poppendieck 夫婦在《Implementing Lean Software Development》裡把 handoff 明確列為軟體開發的七大浪費之一，並用一個保守估計把它量化：每次交接大約留下 50% 的目標知識沒有傳遞。兩次交接剩 25%，三次剩 12.5%。這個數字要當成思考工具而不是量測結果（見 客觀檢視：主張 vs 可佐證），但它推導出的結論是穩固的：損耗是複利的，所以減少交接次數的效益通常大於改善單次交接品質的效益。這個優先順序常被忽略，我在 反模式與陷阱 裡會回到它。
交接失敗的三種成本
**返工（rework）**是最容易看見的一種。設計沒說錯誤狀態長什麼樣，工程師自己編一個，設計 review 時被打回，重做。這種成本可以量：rework rate、reopened ticket 比例、design QA 的打回次數。
隱性知識流失是最容易忽略的一種，因為它不產生事件，只產生一個緩慢下降的能力曲線。原本三分鐘能判斷的問題，現在要花兩小時追查。系統沒有壞，只是變得沒有人真的懂它。這種成本在人員交接時最猛（見 人員交接：離職、輪調與 bus factor），但在 AI session 之間也每天發生。
**決策漂移（decision drift）**是最貴的一種。接手者不知道某個設計曾經被評估並否決，於是重新提案；不知道某個奇怪的實作有其理由，於是「清理」掉它；不知道某個 API 形狀是為了某個客戶的約束，於是簡化它。單次漂移看起來都是小事，累積起來會讓系統慢慢偏離它原本要解的問題。這正是 ADR（架構決策紀錄）存在的理由——它是專門為了對抗決策漂移而設計的交接物。
唯一能確認交接成功的機制：接收者回述
軟體業的交接幾乎都是單向投遞：寫一份文件、丟一個連結、開一場會、然後假設對方接到了。醫療業在這件事上比軟體業成熟得多。
I-PASS 是一套結構化的病人交接協議，五個字母分別是 Illness severity（病情嚴重度）、Patient summary（病人摘要）、Action list（待辦事項）、Situation awareness and contingency plans（情境意識與應變計畫）、Synthesis by receiver（接收者回述）。最後那個 S 是整套協議的關鍵設計：接收者要用自己的話把交接內容講回來，交出者確認無誤，交接才算完成。
Starmer 等人 2014 年發表於《New England Journal of Medicine》的多中心研究，在九家醫院的小兒住院醫師交接流程導入 I-PASS，量測到可預防不良事件顯著下降（研究報告的降幅在兩成到三成之間，視量測項目而定），而且沒有明顯增加交接所需時間。這是目前最強的一筆「交接格式本身會改變結果」的實證。外推到軟體業要打折——醫療交接高頻、短、格式高度標準化、後果立即可見，跟軟體交接的性質差很多——但它至少確立了一件事：交接不是一種溝通態度，而是一種可以設計、可以訓練、有可量測效果的協議。
回述機制在軟體場景的等價物很便宜：讓接手者用自己的話寫三句話回傳（「我理解要做的是 X，驗收是 Y，我卡在 Z」）。在 AI 場景更便宜也更必要——讓 agent 在開工前先重述任務與驗收標準，是目前少數能在動手前發現上下文缺口的手段（見 人↔AI 的上下文交接）。
一個貫穿全專欄的論點
AI 沒有為交接發明新問題。人交給 agent、agent 交給 agent 的所有失敗模式——缺驗收標準、隱性假設、上下文過量或不足、責任沒人接——都是人與人之間早就存在的失敗模式。AI 只做了一件事：把這些失敗的成本曝露得更快、更便宜、更頻繁。人類接手者會在走廊上抓你問清楚，模型不會；人類會察覺「這裡怪怪的」，模型會自信地繼續。所以 AI 場景其實是研究交接的最佳實驗室——它把交接品質與產出品質之間的關係，從幾週的延遲縮短到幾秒。
延伸
- 六個共同要素與它們的驗證判準 → 好交接的六個共同要素
- 每一類交接的具體痛點與實踐 → 設計→工程、需求→工程、工程內部、人員交接
- 決策紀錄為什麼是 AI 時代的必需品 → 方法論支柱：可操作的工程紀律
- 回到全景 → Handoff 專欄首頁