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

具体场景：周五下午 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 分钟过一遍清单，比周一花一下午补洞便宜得多。