历史与交接

这一类记录「东西变了」：人变了、设备变了、系统迁走了、项目结束了。它的作用是提供上下文——没有它，新来的人会看到一堆「为什么是这样」的既成事实，却找不到原因。

为什么要有这一类

实验室文档最常见的失效方式，是写对了但没人知道它已经过时。

比如：一份运维手册写得很好，但它描述的是已经下线的机器；一个新人在上面折腾一晚上才发现。技术内容不会自我标注过时，所以必须人为地留下时间线。

三条约定：

1. 删东西要留痕。文档不能默默消失——要么移到本类下并注明「已废弃，原因见…」，要么在对应页面里留一行「某年某月起不再适用」。
2. 人员变动必须写。谁原来是某个服务的负责人、交接给了谁、有没有交接完成。这一条最容易被跳过，也最容易造成事故。
3. 同一件事只有一份记录。系统迁移的过程写在这里，技术细节写进参考，两边互相链，不要抄两遍。

本类放什么

类型	内容	模板
人员变动记录	谁加入/离开/换负责范围、交接状态	_templates/记录模板.md
设备变动记录	设备上线/下线/搬迁/报废、当前存放位置	同上
系统迁移记录	服务从哪台机器换到哪台、数据怎么迁、有没有回滚方案	同上
项目复盘	一个项目结束后回答五个问题	见本页「项目复盘的五个问题」

硬件设备的具体规格、序列号与位置属于内部信息，在内部库；本类下只记变动事件。

项目复盘的五个问题

复盘不写「这次大有收获」。要回答的是这五条（逐字）：

1. 做对了什么
2. 做错了什么
3. 为什么失败（如果失败）
4. 哪些经验值得保留
5. 下一次怎么做

**第 5 条是复盘的产出。**如果五条都写了但「下一次怎么做」仍然是「下次注意」，那这次复盘没有产生任何可执行的东西，等于没做。

记录

日期	类型	一句话	页面
2025-12-17 / 2025-12-29	教学记录	新成员教学的第一批留档：VSCode 基础、Git 协作、浏览器与效率工具、系统维护、网络环境，以及当次验收结论	2025 年秋季教学进度
待补	人员 / 设备变动	本部门尚未建立人员与设备变动记录；第一条应当是一次真实变动	待补（E11）

怎么加一条

node scripts/new.mjs 历史与交接 docs/部门/终端服务部/历史与交接/<主题>

记录从你说「有一条要记」的时候就开始写，不要等交接完成。交接过程中断的、没做完的事，比交接完成的事重要得多。