在多數軟體交付的價值流量測裡，工作真正被「動手處理」的時間只佔總流經時間的個位數到大約 15%；剩下八成以上的時間，工作躺在某個等待狀態裡——等 review、等設計確認、等 QA 排程、等另一個團隊回覆。這些等待幾乎全部發生在交接的接縫上。交接不是流程裡的一個行政步驟，它是決定週期時間與缺陷率的主要變數之一。
這個專欄把 handoff 當成一個貫穿產品開發生命週期的單一概念來拆解：從設計交給工程、需求交給實作、PR 交給 reviewer、值班交給下一班、離職者交給接手者，一路到 AI 時代新增的兩種——人交給 agent、agent 交給 agent。這些場景表面上差異很大，底層卻是同一件事在重複發生：一次「上下文 ＋ 責任 ＋ 決策依據」的轉移，而每一次轉移都會漏水。
Poppendieck 夫婦在《Implementing Lean Software Development》裡把 handoff 列為軟體開發七大浪費之一，並給了一個廣被引用的保守估計：每一次交接大約留下 50% 想要傳遞的知識沒有傳遞出去。順著算下去，經過分析→設計→實作→測試三次角色交接，原始知識只剩約 12.5%。這個數字是啟發式而非量測值（見 客觀檢視：主張 vs 可佐證），但它抓對了問題的形狀：交接品質可以用資訊損耗率來理解，而損耗是複利的。
本專欄全程區分可佐證的事實與研究（醫療業的 I-PASS 隨機多中心研究、Google SRE 的公開政策、Figma／Anthropic／OpenAI 的官方產品文件與 SDK 變更紀錄）與機制性的工程主張（合理、可推導，但缺乏軟體業對照實驗）。
學習路徑
基礎：交接到底在轉移什麼
- 交接的本質：上下文、責任、決策依據 — 三個同時轉移的東西、資訊損耗率的來源、交接失敗的三種成本（返工／隱性知識流失／決策漂移）、為什麼「接收者回述」是唯一的成功驗證機制
四類人與人之間的交接
- 設計→工程：從像素到可實作契約 — 只畫理想螢幕的代價、token drift、design tokens 與 Code Connect 當單一事實來源、邊界情境清單
- 需求→工程：PRD 如何從說明文件變成可執行契約 — 與 Spec-Driven Development 的關係、驗收標準與 DoD 的分工、最容易掉落的非功能需求
- 工程內部：PR review 與值班交接 — PR 是最高頻的 handoff、review 佇列如何吃掉流動效率、Google SRE 的班次交接與 runbook 常態化
- 人員交接：離職、輪調與 bus factor — 隱性知識只能靠人際互動轉移、四階段交接、反向影子期、用 git history 量測隱性的 bus factor
AI 時代的交接
- 人↔AI 的上下文交接：session、記憶與載體 — handoff 是工作狀態而非對話的轉移、compaction 的取捨、CLAUDE.md／AGENTS.md／spec 作為交接載體、三層記憶對應三層交接
- Agent 之間的 task handoff — 2026 年的 orchestrator＋隔離 subagent 共識、context bleed 與錯誤放大、handoff payload 該裝什麼、agent→人的升級交接
通則與可直接抄用的產物
- 好交接的六個共同要素 — 單一事實來源、驗收／DoD、決策紀錄、可執行的下一步、最小必要上下文、接收者回述；每項附可驗證判準
- 交接產物模板（可直接抄用） — 通用 handoff doc、design→dev checklist、AI session 交接模板、on-call runbook 骨架
影響與風險
- 對工作流與產品開發的幫助（含量測方式） — 會議減量、非同步化、平行化、週期時間、缺陷率、決策可追溯、規模化；五個可以真的量的指標
- 反模式與陷阱 — 過度文件化與文件不足、口頭交接、隱性假設、交接即甩鍋、runbook 腐爛、AI 特有的三種新陷阱，以及「先減少交接次數，再改善交接品質」
客觀基礎
- 客觀檢視：主張 vs 可佐證 — 每個關鍵數字的來源與強度、被我刻意棄用的來源、已知限制
與既有專欄的關係
這個專欄的角度是接縫，不重複其他專欄已深入處理的內容：
- 規格本身怎麼寫、問題怎麼框定 → Problem Framing ＋ Spec-Driven Development。本專欄關心的是「spec 作為交接載體時，它必須額外承擔什麼」。
- AI 輔助編碼的整套工程紀律 → Engineering AI Coding Methodology。本專欄只取其中一條軸線：上下文如何在人與模型、模型與模型之間傳遞而不失真。
- AI 記憶的分層架構 → AI memory（Agent Memory 架構）。記憶是交接的基礎設施；本專欄關心的是使用它的協議。
- 領域知識如何固化進設計 → Event Storming ＋ Event Sourcing ＋ Pattern Language。Event Storming 的產物本身就是一種高品質的跨角色交接物。
- 資深視角的 AI 方法論與 context engineering → Thoughtworks 2026：AI 工作流與方法論。
一句話定位差異：其他專欄回答「這件事怎麼做對」，這個專欄回答「這件事換手的時候，什麼會掉在地上」。
🔍 待解問題 / 持續追蹤
- Poppendieck 的「每次交接損失 50% 知識」是作者自述的保守估計，四十年來沒有人真的量過。有沒有可行的實驗設計？例如讓兩組工程師分別以口頭與結構化文件接手同一段程式碼，量測 time-to-first-safe-change 的差異。
- I-PASS 在醫療交接上有多中心研究支撐，但軟體業沒有等價的對照實驗。結構化交接格式在軟體場景的效果量是多少？醫療交接（高頻、短、生命攸關、格式高度標準化）與軟體交接（低頻、長、可回溯）的差異大到什麼程度會讓外推失效？
- 「最小必要上下文」目前只有啟發式判準（能刪掉而不改變接手者第一個決策，就刪）。有無方法在交接前事前估計上下文是否足夠，而不是等接手者卡住才知道？
- 精實的立場是「減少交接次數優於改善交接品質」，但 AI agent 讓交接成本大幅下降，也讓交接次數自然變多（每個 subagent 呼叫都是一次交接）。這是否推翻了「減少交接」的優先順序，還是只是把損耗從人身上搬到 context window 裡？
- Compaction／摘要式交接會丟掉「當時看起來不重要、後來才關鍵」的細節，這是一個結構性問題而非調參問題。有沒有辦法在壓縮時保留「未來可能重要」的訊號，而不是只保留「現在看起來重要」的？
- 責任的轉移比上下文的轉移難得多。有沒有比 CODEOWNERS、on-call rotation 更好的機制，能讓「責任真的換手了」這件事變成可觀測的狀態，而不是社會約定？
- 隱性的 bus factor（人還在，但只有他能改那個模組）可以用 git 作者集中度近似量測，但這個代理指標會被 monorepo、格式化 commit、AI 代寫 commit 污染。更可靠的量法是什麼？
- AI 生成的交接文件品質如何驗證？讓 agent 寫 handoff doc 很容易，但「它漏掉的部分」正是最危險的部分，而漏掉的東西不會出現在產出裡。
🕒 更新紀錄
- 2026-07-27 — 建立專欄。1 篇 hub ＋ 12 篇原子筆記。核心一手／權威來源：Starmer et al.《Changes in Medical Errors after Implementation of a Handoff Program》（NEJM, 2014，九家醫院 I-PASS 多中心研究）；Poppendieck《Implementing Lean Software Development》（2006）的七大浪費與 50% 交接損耗估計；Google SRE Book／SRE Workbook 的值班與交接章節；DORA 的 value stream mapping 指南與 DX 的流動效率量測；Figma 官方 Code Connect 與 Dev Mode MCP server 文件；W3C Design Tokens Community Group 格式；Anthropic《Effective context engineering for AI agents》（compaction／structured note-taking／sub-agent 摘要回傳）與 2026 年三 agent harness 報導；OpenAI Agents SDK 2026-04-15 將 nested handoff history 改為 opt-in 的變更；AGENTS.md 規格與其移交 Linux Foundation Agentic AI Foundation 的治理事實。全程標示可佐證事實與機制性主張的分界，並在 客觀檢視 中明確列出被棄用的不可靠數據。