整站源码复盘模板：交付前后对照法

整站源码类商品的特殊性在于：它交付的不只是能跑的东西，还包括一整套隐含假设。复盘如果只写“完成了什么”，价值有限；真正有用的是把假设显性化，让接手的人知道哪里可以动、哪里一动就疼。

建立交付前基线
在打包之前先填一份基线记录，内容包括：目录职责划分、入口与构建流程、运行时依赖与开发时依赖的区分、外部服务对接点、数据存储位置与初始化方式、以及所有需要人工填写的配置项。每一项都要写清“缺了它会怎样”。基线记录的作用是给后续对照提供锚点，因此描述要具体到可操作，例如写明某个目录只放静态资源、某个配置文件只影响本地调试。

交付后观察与差异记录
交付后按同一份清单逐项核对，记录三类差异：与基线不一致的地方、基线未覆盖但实际存在的东西、以及基线写了但实际不生效的内容。第三类最容易被忽略，却往往是后续故障的源头。差异记录不追求一次补齐，而是标注优先级：影响启动的、影响数据完整性的、影响日常修改的。每条差异写清发现路径，方便他人复现。

文档与迁移轨道
整站源码的复盘必须回答“换一个人能不能接手”。模板要求检查文档是否覆盖：环境准备的最短路径、首次启动的验证方法、常见启动失败的排查顺序、目录与模块的职责说明、以及修改某类内容时应该动哪些文件。迁移部分记录：数据如何导出与导入、配置如何随环境切换、哪些路径是硬编码需要手工调整。这一节写得好，后续维护成本会明显下降。

执行节奏与注意事项
建议分两次执行：打包前完成基线，交付后一周内完成对照与差异记录，之后每次较大改动前回看上一版差异清单。注意四点：基线记录只写事实与规则，不写进度与评价；差异清单要保留历史，不覆盖旧条目；文档检查以“新人能否独立完成首次启动”为验收标准；迁移步骤必须按顺序写，并标注每步的预期结果。把这套对照法坚持下来，整站源码类商品的交付会从“一次性转移”变成“可延续的交接”。