為長任務設置檢查點：讓 AI 每走一段就交出中間存檔

把長任務丟給 AI，最常見的翻車方式是這個：等了二十分鐘拿到成品，打開一看，它在第二步就跑偏了。打回來重寫，或者推翻重來，兩種都虧。

檢查點技巧就是治這個的。不要求 AI 一口氣做完，而是要求它在每個階段結束時停下，交一份結構化的中間產物：做了什麼、決定了什麼、還剩什麼、哪裡需要你做決定。你檢查的是產物，不是工作過程。

具體場景

**場景一：長內容寫作。** 一篇三千字的影片腳本，別讓它「直接寫完」。拆成檢查點：先出大綱（含每段的核心論點）→ 你點頭 → 再出關鍵段落初稿 → 點頭 → 最後出全文。大綱錯了，全文都不用救；方向對了，全文打磨成本極低。

**場景二：程式碼遷移。** 把專案從 Python 遷到 TypeScript，檢查點可以是：函式簽名對照表 → 已寫檔案的清單加說明 → 自測結果。你只需要看簽名表和測試輸出，就能抓住八成問題。

**場景三：週報或對外材料。** 先讓 AI 輸出一份事實清單，標註每個數字的來源。你確認事實沒問題，它再動筆。這比讓它自由發揮再挑錯安全得多。

可以直接抄的話術

「這個任務分三個節點。每完成一個節點停下來，列出：1）已完成的步驟（附證據）；2）我做了哪些決定、為什麼；3）哪些地方可能出錯；4）需不需要我做決定。我回覆之前不要進入下一步。」

注意關鍵詞是「證據」。「已完成」必須帶檔案路徑、命令輸出或資料來源，不接受一句「已經搞定了」。

什麼時候用，什麼時候別用

**值得用的情況：**

- 任務超過三個階段，或者總耗時超過十分鐘

- 成品修改成本高：對外發布的內容、給客戶的文件、線上跑的遷移腳本

- 你對 AI 的方向沒把握：新領域、不熟悉的技術棧

**別用的情況：**

- 單次就能完成的短任務：起個名字、改個錯字、查個事實

- 你驗證不了結果的階段：讓設計稿等你對顏色方案沒有意義。檢查點的前提是你有能力檢查

- 本身就沒確定路徑的探索階段：腦力激盪要放開跑，檢查點是給「驗證過程」用的，不是給「探索方向」用的

開始前的自檢清單

- [ ] 任務能拆成 2 到 4 個檢查點，且你知道每個檢查點該產出什麼東西

- [ ] 每個檢查點你願意花兩三分鐘驗證。如果驗證比重工還貴，這個任務不適合用檢查點

- [ ] 你規定了產物格式：證據、決定、風險，三項都要有

常見坑

1. **檢查點開成批鬥會。** 每次你都只回「好的」，那檢查點只是讓對話變長、上下文變重。驗證時就把意見寫下來，當場改，別攢到結尾一起說。

2. **產物越積越亂。** 每個檢查點的產物建議存一個檔案，最後跟成品逐條對帳。這份記錄還能直接當交接文件用。

3. **驗證靠感覺。** 只掃一眼標題，跟沒驗證一樣。強迫自己抽查至少一條證據：打開那個檔案、跑一遍那條命令、核對那個資料來源。

4. **檢查點設得太細。** 檢查點的目的是「早發現方向錯」，不是「盯住每個細節」。粒度以階段為準。階段錯了還能換方向，細節盯多了累的是你。

核心一句話：別管理 AI 的勞動過程，管理它的決策節點。每個節點要求它給出證據，你來對證據。