交付前的「提交檢查清單」：把交付事故消滅在最後一個小時

具體場景：週五下午 4 點，你把功能提交、寫了說明、截圖、打了個 tag，然後下班。週一早上客戶回覆：「欄位少了一個」、「顏色不對」、「沒有寫重啟步驟」。這些事故 90% 都能用一份提交檢查清單在最後一個小時攔下來。

這是什麼技能

提交檢查清單（Pre-commit Checklist）不是文件寫作技巧，而是一種交付品質關卡：在你宣布「完成」之前，用一份固定問題列表逐項核對，把「我認為做完了」和「客戶認為做完了」之間的資訊落差攤開在紙面上。

什麼時候用

• 給客戶的正式交付（功能、報告、設計稿更新）
• 依賴別人驗收的工作（PR 審查、外包成果驗收）
• 任何「你改完對方看不見過程」的非同步交付
• 跨時區協作，對方有時差無法即時追問的場合

什麼時候別用

• 內部快速迭代、當天還要繼續改的東西——清單會拖慢節奏，改用口頭對齊
• 對方是「邊看邊聊」風格的審查會——直接演示比清單高效
• 需求本身還在劇烈變化時——清單鎖死的是昨天的需求

清單怎麼寫（5 步）

1. 從歷史事故倒推：翻過去 3 個月收到的所有「補一下」訊息，每條變成一個檢查項。這是清單裡最值錢的 60%。
2. 按「對方視角」排序：對方開啟交付物後第一眼會確認什麼？（能跑嗎？文件齊全嗎？）排前面。
3. 每項必須可二元判定：寫「文件完整」沒用，要寫「README 裡的安裝步驟在當前分支上能直接跑通」。
4. 控制在 7±2 項：超過 10 項就不會被認真執行。
5. 放進交付範本：寫進 Notion 範本、PR 範本或 Trello 卡片，別靠記憶。

核對時機與常見陷阱

• 時機：在「覺得自己完成了」之後的 10 分鐘冷靜期裡執行，而不是按下提交按鈕前 30 秒。
• 陷阱 1——清單僵化：每季度刪一次沒人勾選過的項目，加一次新事故的項目。清單活著才有用。
• 陷阱 2——用清單證明自己沒錯：全勾選但交付還是被退回時，先懷疑清單漏項，而不是「對方需求變了」。
• 陷阱 3——替對方做決定：清單只能覆蓋「標準交付物」，專案特有的特殊約定（比如只交截圖不交影片）要另起一行業務備註。

最小啟動版

今天就能用的 5 項起步清單：

• 交付物在乾淨環境（新機器/乾淨分支）能跑通
• 版本號/日期/命名和對方要求一致
• 文件裡的每一步都用最新程式碼手動執行過
• 截圖/演示反映的是當前版本，不是上週的
• 回覆裡明確寫了「包含什麼、不包含什麼、下一步是什麼」

最後一個小時花 10 分鐘過一遍清單，比週一花一下午補洞便宜得多。