給凌晨兩點的自己寫備註：交接備註（Handoff Note）

這是什麼（一句話）

把「做了什麼、為什麼這麼做、下一步風險在哪」寫在旁邊，讓任何不在線的讀者——尤其是未來的你——能直接接手，不用再翻聊天記錄。

什麼時候用（4 個場景）

- **跨天/跨週的工作交接**：你寫了一天的服務，明天早上要交給同事。他下午要「打開接著做」，3 分鐘能看懂的交接備註，比 1 小時的螢幕共享划算得多。

- **一個人同時壓著兩三個平行任務**：CI 修復沒合併，佇列 bug 沒解，每天來回切換脈絡——沒有一份「現場還原」清單，每次切回來都要花 20 分鐘重新找回狀態。

- **程式碼/設定要交給 AI 或通用腳本**：通用工具沒有你的隱含脈絡，沒有說明它會默默改掉遵守的約定，測試一晚變紅。往目錄根目錄丟一份 `HANDOFF.md`，比事後修 10 處 bug 划算。

- **你現在頭很痛，只是想「今晚收工」**：30 分鐘的備註比「明天再理」更救你的命——因為明天早上 8 點的你，和今晚 11 點的你，是兩個不同的大腦。

什麼時候不用（反例）

- **單次、單一檔案、語意清晰的改动**——提交訊息的 `commit message` 就夠了，別為這一行修改建立一個獨立文件。

- **出了事故的復盤記錄**——那是 postmortem 的工作，有自己的範本和讀者；把「交接備註」塞進事故記錄只會把兩者都搞混。

- **你自己的團隊已經有一整套文件/issue 規範**——用它們，別搞雙軌制。你的目標是複用既有結構，而不是再造一層。

- **你還在「不確定的草案」階段**——如果結論本身幾天內可能會被推翻，別提前備註。把「還在驗證」這件事單獨標註出來就行。

實作清單（5 段式，每段每 30 字以內）

1. 目前狀態     —— 三句話內可重現：「當前到哪一步 + 證據」
2. 為什麼這麼做 —— 你拒絕了什麼思路/方案，一句話
3. 下一步       —— 明確需要什麼人/工具 + 驗證方式
4. 風險還沒解   —— 最多兩條；標註「大概率會踩雷 / 偶爾會踩」
5. 找一個活人   —— 「如果遇到 X，先問 Y」的備援路線

**就這樣。整份備註，一個讀者 3 分鐘看完，80% 的讀者看過 10 行之後就讀完了。** 每一條 30 字不夠寫清楚，是真的不清楚——逼自己重寫，或砍掉這條。

**放在哪裡**：放在下一個讀者「會打開」的地方——程式碼根目錄的 `HANDOFF.md` / 分支說明的第一個 Release Note 項目 / 通訊軟體群組的置頂訊息。放在 wiki 最深處的三層麵包屑路徑裡，就等於沒寫。

常見坑（Gotchas）

- **寫一半就停**：半成品最傷讀者——看到「TODO: 後續補充」就轉走了。要么收尾，要么明確標註「這是草稿，還缺第 N 段」，別讓讀者猜。

- **開頭塞一切背景**：背景昨天就有，不值得一行。第一句必須告訴讀者「現場處在哪一步」。

- **把驗證路徑藏起來**：說「改完測試綠了」順便把指令和一次綠色輸出並列展示出來（輸出可以截圖短行）。讀者最貴的是「我要從他手头這套新機環境裡重現一次，去驗證是不是真的綠」。

- **追責語氣**：「X 昨天為什麼沒檢查這條」——這類語句不要出現在交接備註裡。你寫的是給現場的接手者，不是審判者。

- **多版本疊加**：今天 5 行，明天又追加 5 行，後天再加…… 兩週後 40 行沒人讀。舊版本歸檔，只保留最新的；「目前狀態」永遠是不許超過 5 段。

真實的教訓

兩年前，我加班到深夜做了一個底層協定的修復，第二天身體累得沒寫備註，就把服務交給同事。第三週，同事在 Slack 問「XX 重放視窗到底怎麼算回傳值」——事實在我 commit 的雙位元組 v2 註釋裡已經寫得一清二楚。他花了兩個小時自己把整個協定條文扒了一遍才拼湊出來。從那以後我給自己定了一條最硬的規則：**任何跨天任務，沒有 5 段備註 = 任務未完成**。兩個月後，我也沒有錯過幾次「你當時為什麼改得這麼奇怪」的同事懲罰性提問。

---

**cover-theme:** engineer writing sticky notes at late night