這個專欄用了不少數字與引用，它們的證據強度差距很大。這篇把每一項的來源與強度攤開，並列出被我刻意棄用的來源。
有同儕審查研究支撐
結構化交接協議能降低可預防的不良事件。 來源：Starmer 等人《Changes in Medical Errors after Implementation of a Handoff Program》，發表於《New England Journal of Medicine》2014 年 11 月，涵蓋九家醫院的小兒住院醫師交接流程，導入 I-PASS 協議（Illness severity、Patient summary、Action list、Situation awareness and contingency plans、Synthesis by receiver）。研究報告可預防不良事件顯著下降（依量測項目不同，公開報導的降幅在兩成到三成之間），且未明顯增加交接所需時間。
強度與限制：這是本專欄唯一一筆有多中心同儕審查支撐的證據，也是「交接格式本身會改變結果」最硬的依據。但它是前後對照設計而非隨機分派，且情境差異大——醫療交接高頻、時間短、格式高度標準化、後果立即可見；軟體交接低頻、時間長、可回溯、後果延遲。外推到軟體業必須打折，我在專欄中只用它支撐「交接是可設計的協議」這個定性結論，不用它支撐任何軟體場景的效果量。
是權威來源的實務指南或政策，但不是研究
「每次交接損失約 50% 知識」。 來源：Poppendieck 夫婦《Implementing Lean Software Development: From Concept to Cash》（2006），handoff 被列為軟體開發七大浪費之一。作者自述這是一個保守估計，不是量測結果。三次交接剩 12.5% 是由這個估計外推出來的算術，不是觀測值。
強度：這是一個思考工具。它的價值在於指出損耗是複利的、因此減少交接次數優於改善交接品質；它的數字本身不應該被當成基準線引用。四十年來沒有人真的量過這個比例，這也列在專欄的待解問題裡。
交接摩擦是價值流裡需要重點檢視的環節。 來源：DORA 的 value stream mapping 指南。這是權威的實務指南（DORA 本身有多年研究基礎），但這一條建議屬於實務判斷而非研究結論。
流動效率通常落在個位數到約 15%。 來源：業界的價值流量測實務報告（例如 DX 等開發者生產力平台的量測整理）。這是可信的觀測範圍，但不是同儕審查、樣本非隨機、且各家對「處理時間」的定義不完全一致。我用它支撐「排隊佔多數時間」這個定性結論，不用它做精確計算。
Google SRE 的具體參數：至少 50% 的 SRE 時間投入工程工作、值班不超過 25%、每班次 actionable incident 以 2 到 3 件為可持續上限；班次結束時寄交接信。來源：Google SRE Book 與 SRE Workbook 的相關章節。這些是 Google 的內部政策，不是普適最佳值——它們反映 Google 的系統規模、人力配置與文化，小團隊直接照抄未必合理。可以借用的是背後的邏輯：交接品質隨疲勞程度下降。
15 分鐘交接、同步優先、貼共享頻道而非私訊。 來源：業界 on-call 實務指南（incident.io 等事故管理供應商的公開內容）。屬於實務建議，供應商有商業動機，但這幾條與 Google SRE 的做法一致，可信度尚可。
可佐證的產品與治理事實
以下都是可以直接查證的事實陳述，不涉及效果主張：
- W3C Design Tokens Community Group 制定了 design token 的標準交換格式；Figma Variables 支援該格式。
- Figma Code Connect 提供 UI 與 CLI 兩種方式，把 repo 元件與設計檔元件建立對映；對映結果會餵給 Figma 的 MCP server。
- Figma Dev Mode MCP server 讓 AI 工具透過 Model Context Protocol 直接讀取設計檔的結構化內容，而非解讀截圖。
- AGENTS.md 由 OpenAI 於 2025 年 8 月發布，其後移交 Linux Foundation 底下的 Agentic AI Foundation 治理；至 2026 年採用的開源 repo 超過六萬個。Claude Code 原生讀 CLAUDE.md，在找不到時退回讀 AGENTS.md。
- Anthropic 的 context engineering 機制：compaction（高保真壓縮後重新初始化，官方明確指出過度激進的摘要會丟失後來才關鍵的細節）、structured note-taking（外化狀態到 context 之外）、sub-agent 在乾淨 context 中工作並回傳約 1,000–2,000 token 的濃縮摘要、memory 工具支撐跨 session 的專案狀態。來源：Anthropic 工程部落格〈Effective context engineering for AI agents〉。
- OpenAI Agents SDK 在 2026 年 4 月 15 日的更新把 nested handoff history 改為預設關閉（opt-in），以降低 cross-agent context bleed。
- Anthropic 2026 年的架構走向是 brain／hands 解耦與角色範圍明確的 subagent（4 月的 Managed Agents 與三 agent harness），而非更寬的平行 fan-out。來源：官方發布與技術媒體（InfoQ）報導。
強度：這些是產品事實，查得到、時間點明確。但**「這些機制能減少多少返工／提高多少品質」沒有任何公開對照數據**。Figma 沒有公布 Code Connect 的返工降幅，Anthropic 沒有公布 sub-agent 架構相對於單一 context 的效果量。
屬於機制性主張（合理但未經驗證）
以下是本專欄的推論，讀者應該當成有待檢驗的工程意見：
- 交接品質可以用「接手者做出同等品質決策所需時間」（time-to-first-safe-change）來量測。這個指標我沒有找到任何團隊公開使用或驗證過。
- 決策依據（why）的缺失比上下文（what）的缺失更貴，因為前者不會暴露、後者會。機制清楚，無數據。
- 上下文過量與不足同樣有害；「刪掉這段會不會改變接手者的第一個決策」是可用的判準。啟發式。
- 接收者回述在軟體場景（PR、值班、AI session）能帶來與醫療場景類似方向的效益。這是外推，不是證據。
- 「AI 的交接問題沒有一個是新的，只是迭代週期被壓縮」——這是本專欄的核心論點，屬於結構性觀察，無法被單一實驗驗證。
- 「減少交接次數優於改善交接品質」在 agent 系統裡依然成立。這條在人類場景有精實理論支撐，在 agent 場景是我的推論；agent 的交接成本遠低於人類，這可能改變最佳的交接次數，見專欄的待解問題。
刻意棄用的來源
**「design token 採用率從 56% 升到 84%」**這類數字在多篇 2026 年的設計工具內容裡流傳，但追不到原始調查方法、樣本或發布單位，看起來是內容行銷之間互相引用形成的數字。本專欄不使用它，即使它支持我想講的論點。
各類「導入某工具後效率提升 X%」的供應商案例同樣未採用，除非能追到方法論。這類數字幾乎都是自我報告、無對照組、且有明顯的選擇偏差。
**「組織 80% 以上的知識是隱性的」**這個比例在知識管理領域被廣泛引用，但溯源困難。我在 人員交接 裡使用它時已標記為「常引數字而非嚴謹量測」，它的作用只是強調隱性知識占比高，不承擔任何計算。
已知限制的誠實清單
軟體業沒有針對交接品質的隨機對照研究。本專欄的實務建議大多是三種東西的組合：鄰域（醫療、精實製造）的證據、權威來源的實務指南、以及機制性推論。這意味著建議的方向相對可靠，效果量完全未知。
因此我在 對工作流與產品開發的幫助 裡給的落地方式是量測導向而非制度導向：先量流動效率與 handoff delay，找出最大的一段接縫，只在那裡導入結構化交接，再看指標動不動。這個做法在效果量未知的情況下仍然安全，因為它的成本是有界的。
延伸
- 這些證據支撐的核心論點 → 交接的本質
- 量測方式與指標定義 → 對工作流與產品開發的幫助
- 回到全景 → Handoff 專欄首頁