给凌晨两点的自己写备注：交接备注（Handoff Note）

这是什么（一句话）

把"做了什么、为什么这么做、下一步风险在哪"写在旁边，让任何不在线的读者——尤其是未来的你——能直接接手，不用再翻聊天记录。

什么时候用（4 个场景）

- **跨天/跨周的工作交接**：你写了一天的服务，明天早上要交给同事。他下午要"打开接着做"，3 分钟能看懂的交接备注，比 1 小时的鼠标共享便宜得多。

- **一个人同时压着两三个并行任务**：CI 修复没合，队列 bug 没解，每天来回切上下文——没有一份"现场还原"清单，每次切回来都要花 20 分钟重新捡状态。

- **代码/配置要交给 AI 或通用脚本**：通用工具没有你的隐含上下文，没有说明它会默默改掉遵守的约定，测试一晚变红。往目录根部丢一份 `HANDOFF.md`，比事后修 10 处 bug 便宜。

- **你现在的头很痛，只是想"今晚收工"**：30 分钟的备注比"明天再理"更救你的命——因为明天早上 8 点的你，和今晚 11 点的你，是两个不同的脑子。

什么时候不用（反例）

- **单次、单文件的、语义清晰的改动**——提交信息的 `commit message` 就够了，别为这一行修改 oluştur 一个独立文档。

- **出了事故的复盘记录**——那是 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