以下四份模板可以直接複製使用。它們共同遵守 六個共同要素，並刻意保持短——每一個欄位都是為了對抗一種具體的交接損耗而存在，沒有任何欄位是為了看起來完整。如果某個欄位在你的場景裡從來不填，刪掉它。
一、通用 handoff doc 範本
適用於任何一次性的工作交接：功能做到一半換手、專案移交、跨團隊委派。
# Handoff: <一句話說清楚這是什麼>
**交出者**：@name **接手者**：@name（必填，不能是「團隊」）
**日期**：YYYY-MM-DD **責任轉移生效時間**：<明確時間點>
## 1. 目標與為什麼
- 要達成什麼（一句話，可測試）
- 為什麼要做這件事 / 它解決誰的什麼問題
- 相關 spec / issue / 設計檔連結（單一事實來源）
## 2. 現狀
- 已完成：<清單，附可驗證的證據，例如已合併的 PR>
- 進行中：<清單，附目前卡在哪>
- 未開始：<清單>
## 3. 驗收標準
- [ ] <可轉成測試或可執行檢查的條件>
- [ ] <...>
- 團隊 DoD 是否適用：是／否（例外請說明）
## 4. 決策紀錄
| 決策 | 為什麼 | 考慮過但否決的方案 | 否決理由 |
|---|---|---|---|
| | | | |
## 5. 假設與未驗證的事
- 已驗證（可直接依賴）：<事實 + 怎麼驗證的>
- 未驗證（請勿當前提）：<假設 + 若為假的影響>
## 6. 下一步（可直接動手）
1. <具體動作，含檔案路徑 / 指令 / 環境>
2. <...>
## 7. 邊界
- 不要做：<清單>
- 不要碰：<檔案 / 模組 / 資料表>
## 8. 風險與低信心清單
- 我認為最可能出錯的地方：<...>
- 回滾方式：<...>
## 9. 接收者回述（接手者填寫）
- 我理解要做的是：<用自己的話>
- 我理解驗收是：<...>
- 我現在的疑問：<...>第 9 節是整份文件裡唯一由接手者填寫的部分，也是唯一能確認交接成功的機制。少了它，前八節只是投遞。
二、Design → Dev checklist
貼在設計交付的說明裡，或設成 Figma 交付區塊的固定清單。理由與失效點見 設計→工程。
## 設計交付檢查清單
### 單一事實來源
- [ ] 所有顏色 / 間距 / 字級 / 圓角都使用 design token，沒有硬寫的一次性值
- [ ] 使用的元件都是設計系統元件；一次性元件已標記並說明理由
- [ ] 已透過 Code Connect（或等價方式）對映到 repo 元件，避免「這是哪顆按鈕」的猜測
### 響應行為
- [ ] 三個代表性寬度都有稿：375 / 768 / 1440
- [ ] 已說明中間寬度是流動還是跳變
- [ ] 已標註最小可用寬度與內容溢出時的處理
### 互動狀態（每個可互動元素）
- [ ] default / hover / focus / active / disabled / loading / error
- [ ] focus 狀態視覺明確（同時是無障礙需求）
### 邊界情境
- [ ] 空狀態（從未有資料）與清空狀態（曾有資料但被刪光）
- [ ] 載入中 / 載入失敗 + 重試 / 部分失敗
- [ ] 資料極少（1 筆）與極多（設定分頁或虛擬滾動的門檻）
- [ ] 超長文字的截斷規則（單行省略？多行夾斷？tooltip？）
- [ ] i18n 字串膨脹（假設最長語言為 1.8 倍）
- [ ] RTL 鏡像行為
- [ ] 權限不足時看到什麼（隱藏？禁用＋說明？）
- [ ] 離線 / 網路極慢
- [ ] 時區與日期格式
### 無障礙
- [ ] 目標標準已明說（例如 WCAG 2.2 AA）
- [ ] 對比度已檢查（含 disabled 與 placeholder）
- [ ] 鍵盤操作順序已標註
- [ ] 圖像 / 圖示的替代文字已提供
### 驗收與回交
- [ ] 有可判定的驗收方式（不是「照稿做」）
- [ ] 已約定工程端的回交內容：因技術約束偏離之處、工程自行決定的狀態、實際效能表現三、AI session handoff / context 交接模板
兩種用途：一是 session 快要塞滿 context 時寫給「下一個自己」；二是 orchestrator 委派給 subagent 的 payload。結構刻意跟通用模板同構，理由見 Agent 之間的 task handoff。
# Session Handoff — <任務名稱>
## 任務
<一句話，可測試。不要寫「繼續之前的工作」>
## 已驗證的事實（可直接依賴）
- <事實> — 驗證方式：<跑了什麼指令 / 看了什麼檔案>
- <...>
## 未驗證的假設（請勿當前提）
- <假設> — 若為假的影響：<...>
## 已做的變更
- <檔案路徑>：<改了什麼、為什麼>
## 已試過但失敗的路徑（不要重蹈）
- <方案> — 失敗原因：<...>
## 驗收標準
- [ ] <...>
- 驗證指令：`<實際可跑的指令>`
## 邊界
- 不要修改：<檔案 / 模組>
- 不要做：<...>
## 下一步
1. <具體動作>
## 低信心清單
- <我最不確定的地方，人類 reviewer 請優先看這裡>
---
## 開工前請先回述（接手的 agent 填）
- 我理解任務是：
- 我理解驗收是：
- 我理解的邊界是：
- 我發現交接文件裡缺少：最後一段是把醫療交接的 synthesis by receiver 直接搬過來。它的價值在於在動手之前暴露上下文缺口——修一段重述的成本，遠低於回收一批寫錯方向的程式碼。
寫進專案層而非 session 層的東西（CLAUDE.md / AGENTS.md）另有判準：每次進這個 repo 都需要、且無法從程式碼推導出來。建置與測試的確切指令、與預設不同的風格約定、架構約束、不要碰的區域、重要決策的理由。程式碼讀得出來的東西不要寫，寫了只會稀釋訊號。
四、On-call runbook 骨架
一個 runbook 對應一種可能發生的狀況，不是一份包山包海的手冊。理由與 Google SRE 的交接實務見 工程內部：PR review 與值班交接。
# Runbook: <警報名稱 / 症狀>
**最後驗證日期**：YYYY-MM-DD（由誰、在哪個環境實際跑過）
**嚴重度**：P1 / P2 / P3 **預期處理時間**：<分鐘>
## 這個警報在說什麼
<用一句人話說明，不要複製 alert 的 query>
## 使用者受到什麼影響
<沒有影響 / 部分功能降級 / 完全不可用；影響哪些人>
## 先確認不是誤報
1. 看 <dashboard 連結>，確認 <具體指標> 是否真的超過 <閾值>
2. <...>
## 立即緩解（先止血，不求根治）
1. <具體指令，可複製>
2. 確認緩解生效：<怎麼看>
3. 若無效，升級給：<角色 / 頻道>
## 診斷
- 常見原因 1：<症狀特徵> → <怎麼確認> → <怎麼修>
- 常見原因 2：<...>
## 已知不是原因的東西
- <看起來相關但實際無關的訊號，避免下一個人白追>
## 需要的權限與前置
- <帳號 / 角色 / VPN / 工具>（缺少時找誰要）
## 相關連結
- Dashboard / Log 查詢 / 上游依賴的狀態頁 / 相關 ADR
## 事後
- [ ] 是否需要 postmortem
- [ ] 本次處理有沒有偏離這份 runbook → 更新它最後驗證日期 這一欄是刻意放在最上面的。沒有被實際執行過的 runbook 等於沒有 runbook——寫的時候覺得清楚的步驟，在半夜三點會發現缺了一個權限、指令參數過期了、或那個 dashboard 已經被刪掉。
五、班次交接摘要（最短版）
值班交接不需要長文件，需要固定欄位。貼到整個團隊可見的頻道，不要私訊。
**值班交接 <日期> <班次> → @下一位**
- 進行中事件：<開啟中 / 已緩解未解決 / 調查中，三者分開寫>
- 持續關注：<部署凍結、已知會亂叫的 alert、上游異常>
- 本班變更：<部署 / 設定調整 / 資料修補>
- Runbook 更新：<有 / 無，連結>
- 給下一班的一句話：<你最該注意的是什麼>
@下一位 請回述確認：<你理解的進行中事件是什麼>「已緩解但未解決」必須跟「已解決」分開寫，這是值班交接裡最常被誤認為已結案、然後在下一班半夜復發的一類。
延伸
- 每個欄位對抗的損耗是什麼 → 好交接的六個共同要素
- 模板用過頭會變成什麼 → 反模式與陷阱
- 回到全景 → Handoff 專欄首頁