交接文档写法

何时触发

• 换会话/换模型/换人继续同一个项目
• 一个阶段收口（打磨完一批内容、修完一批 bug）要留一份可读的状态快照

结构（按顺序写）

1. 一句话现状：谁交给谁、交接到哪、下一步做什么。
2. 铁则：接手者必须先读什么、什么情况下不许动代码（例如「用户提议 → 复述方案 → 确认后才改」）。
3. 进度速览：已完成 / 进行中 / 待开始，带编号与验收卡位置。已完成的写清「验收卡 + commit」。
4. 工具入口表：用途 / 前置条件 / 完整命令。把坑写进前置条件（例如「启动前必查同项目旧编辑器是否还开着，否则静默退出返回 0 假成功」）。
5. 索引与参数：内容编号表、输出目录、按项调节的参数表。
6. 环境差异：换平台后哪些行为不同（编码、路径、超时、权限）。
7. 遗留与下一步：按优先级排，逐条写「做什么 + 验收标准」。
8. 已知坑清单：踩过的、会重复踩的，一条一行。

写法要求

• 只写可执行的信息：能给命令就给命令，能给路径就给路径。
• 已完成项的「验收证据」必须可查（验收卡 / commit / 报告路径）。
• 不确定的标「待确认」，不要写成结论。
• 不写心路历程与讨论过程，决策只留结论 + 日期。

验收

• 接手者只看这份文档就能跑通核心命令
• 每个「已完成」都有可查证据
• 工具入口表里的命令是完整可复制的一行
• 坑清单里至少包含「假成功」类问题
• 下一步每条都有验收标准

坑

• 只写「已完成 X」，不写证据 —— 下一个人无法确认到底完成没。
• 命令缺前置条件：旧进程没关、索引文件没写，命令返回 0 但什么都没跑。
• 把讨论过程当交接内容，接手者要读半小时才知道结论是什么。