交付前的"提交检查清单"：把交付事故消灭在最后一个小时

**具体场景**：周五下午 4 点，你把功能提交、写了说明、截图、打了个 tag，然后下班。周一早上客户回复："字段少了一个"、"颜色不对"、"没有写重启步骤"。这些事故 90% 都能用一份提交检查清单在最后一个小时拦下来。

这是什么技能

提交检查清单（Pre-commit Checklist）不是文档写作技巧，而是一种**交付质量门禁**：在你宣布"完成"之前，用一份固定问题列表逐项核对，把"我认为做完了"和"客户认为做完了"之间的信息差摊开在纸面上。

什么时候用

- 给客户的正式交付（功能、报告、设计稿更新）

- 依赖别人验收的工作（PR 评审、外包成果验收）

- 任何"你改完对方看不见过程"的异步交付

- 跨时区协作，对方有时间差无法即时追问的场合

什么时候别用

- 内部快速迭代、当天还要继续改的东西——清单会拖慢节奏，改用口头对齐

- 对方是"边看边聊"风格的评审会——直接演示比清单高效

- 需求本身还在剧烈变化时——清单锁死的是昨天的需求

清单怎么写（5 步）

1. **从历史事故倒推**：翻过去 3 个月收到的所有"补一下"消息，每条变成一个检查项。这是清单里最值钱的 60%。

2. **按"对方视角"排序**：对方打开交付物后第一眼会确认什么？（能跑吗？文档齐全吗？）排前面。

3. **每项必须可二元判定**：写"文档完整"没用，要写"README 里的安装步骤在当前分支上能直接跑通"。

4. **控制在 7±2 项**：超过 10 项就不会被认真执行。

5. **放进交付模板**：写进 Notion 模板、PR 模板或 Trello 卡，别靠记忆。

核对时机与 gotchas

- **时机**：在"觉得自己完成了"之后的 10 分钟冷静期里执行，而不是提交按钮按下前 30 秒。

- **坑 1——清单僵化**：每季度删一次没人勾选过的项，加一次新事故的项。清单活着才有用。

- **坑 2——用清单证明自己没错**：全勾上但交付还是被退回时，先怀疑清单漏项，而不是"对方需求变了"。

- **坑 3——替对方做决定**：清单只能覆盖"标准交付物"，项目特有的特殊约定（比如只交截图不交视频）要另起一行业务备注。

最小启动版

今天就能用的 5 项起步清单：

- [ ] 交付物在干净环境（新机器/干净分支）能跑通

- [ ] 版本号/日期/命名和对方要求一致

- [ ] 文档里的每一步都用最新代码手动执行过

- [ ] 截图/演示反映的是当前版本，不是上周的

- [ ] 回复里明确写了"包含什么、不包含什么、下一步是什么"

最后一个小时花 10 分钟过一遍清单，比周一花一下午补洞便宜得多。