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

**具體場景**：週五下午 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 分鐘過一遍清單，比週一花一下午補洞便宜得多。