設計交給工程、需求交給實作、值班交給下一班、離職者交給接手者、人交給 agent、agent 交給 agent——六個場景的工具與節奏完全不同，但拆到底之後，成功的交接都具備同一組要素。以下每一項都附一個可驗證的判準，因為「我們有寫交接文件」不是一個可以檢查的狀態。
一、單一事實來源
同一件事實只能有一個權威來源，其他地方都是引用。違反這一點的後果不是資訊不足，而是資訊衝突——接手者拿到兩個版本的真相，而他無從判斷哪個新。
這在實務上最常見的形式是：Figma 裡的間距值與程式碼裡的常數各自演化（token drift）、Notion 的 spec 與 Jira 的 ticket 描述不一致、runbook 說要跑那個指令但實際上指令已經改名。
判準：對任何一個關鍵事實（這個顏色的值、這個 API 的 schema、這個服務的部署指令），你能不能指出唯一的權威來源？如果答案是「有兩個地方都寫著，應該一樣」，那就已經失敗了。
二、明確的驗收標準與 DoD
沒有「怎樣算做完」的交接，接手者會自己定義完成，而他的定義幾乎一定比你的寬鬆——不是因為他偷懶，是因為他不知道你在意什麼。
驗收標準是這一件工作的行為契約，DoD 是團隊層級的固定門檻，兩者的分工見 需求→工程。交接時兩者都要在場：AC 說明目標，DoD 說明「在這裡，交出去之前還要做什麼」。
判準：驗收標準能不能被轉成一個測試或一組可執行的檢查步驟？不能的話它還是願望，不是標準。
三、決策紀錄：為什麼是這樣
這是最常缺、也最貴的一項。程式碼記錄了做了什麼，永遠不記錄為什麼不做另一件事；設計檔記錄了最終版，不記錄那三個被否決的方向。缺了這一層，接手者不會卡住——他會很有效率地重新做決定，然後慢慢偏離原本要解的問題。這就是 決策漂移。
決策紀錄的成本被高估了。ADR 的有效版本可以只有四段：情境、決策、考慮過但否決的替代方案、後果與取捨。三到五行就夠。真正稀有的不是篇幅，是「已否決的選項」這一欄——它是唯一能阻止接手者重蹈舊路的東西。
判準：半年後有人問「為什麼這裡是這樣寫的」，能不能不找當初的作者就得到答案？
四、可執行的下一步
交接物必須讓接手者知道下一個動作是什麼，而不只是知道現狀。「目前狀態：整合到一半」是狀態描述；「下一步：把 PaymentAdapter 的 retry 邏輯接上 webhook 重送，測試在 tests/payment/retry_test.ts，卡在沙箱環境的 webhook 簽章驗證失敗」才是可執行的交接。
這一項在值班交接與 AI session 交接裡特別關鍵，因為接手者的時間窗很短，沒有餘裕先做一輪現狀考古。
判準：接手者讀完之後，能不能在五分鐘內開始動手，而不需要先問任何問題？
五、最小必要上下文
不多不少。不足的後果是接手者必須重新發現已知的事實；過量的後果比較隱蔽但同樣真實——對人來說重要訊號被稀釋，對模型來說過長的 context 讓關鍵指令失效。一份塞滿所有可能有用資訊的交接文件，效果會比精準的短版差，而寫的人會誤以為自己做得更周全。
判準：逐段問「刪掉這段，接手者的第一個決策會不同嗎？」不會就刪。這個判準對人的交接文件、CLAUDE.md、agent 的 handoff payload 都同樣適用。
六、接收者回述
前五項都是關於發送端要交什麼。第六項是唯一能確認交接成功的機制，而它在軟體業幾乎完全缺席。
醫療業的 I-PASS 協議把它寫進了名字裡——最後那個 S 是 Synthesis by receiver：接收者用自己的話把交接內容重述一遍，發送者確認無誤，交接才算完成。Starmer 等人 2014 年在《NEJM》發表的九家醫院研究顯示，導入這套結構化交接後可預防不良事件顯著下降，且未明顯增加交接時間（詳見 客觀檢視）。
軟體場景的等價物很便宜。PR：reviewer 先用一句話說「我理解這個改動是為了 X」。值班：接班者回述進行中的事件與待辦。人員交接：接手者獨立完成一次代表性任務。人交給 AI：要求 agent 在開工前重述任務、驗收標準與邊界——這是目前少數能在動手前發現上下文缺口的手段。
判準：這次交接有沒有任何一個環節，是接收端把理解送回發送端？沒有的話，這不是交接，是投遞。
六項的優先順序
如果只能做兩件事，做第三項（決策紀錄）和第六項（回述）。理由是其他四項的缺口會很快暴露——接手者卡住了就會來問；而決策依據的缺口不會暴露，它只會安靜地產出一個偏離的系統。回述則是唯一能在成本還很低的時候（動手之前）發現其他五項有缺口的機制。
延伸
- 這六項為什麼是這六項（本質推導）→ 交接的本質
- 六項落成具體文件 → 交接產物模板
- 每一項做過頭會變成什麼 → 反模式與陷阱
- 回到全景 → Handoff 專欄首頁