给凌晨两点的自己写备注：交接备注（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