讓 AI 寫程式前，先決定哪些地方要停下來檢查

Larry

以前你請同事改程式，通常會先寫 issue、補需求、等對方開 branch，再看 pull request。中間雖然來回很多，但每一步大多還有人在決定：這個需求是不是合理、該改哪裡、什麼時候可以合併。

Coding agent 改變的是這個日常畫面：它不只幫你想程式碼，重點在於可以讀 issue、改檔案、跑測試，甚至自己開 pull request。也就是說，AI 開始從「給建議」走到「真的在 repo 裡動手」。

這很方便，但它不會承擔產品判斷。需求範圍、產品假設、風險邊界和 rollback，仍然要由人類先畫清楚。導入 Devin、Copilot coding agent 或類似工具前，不要只問「它能不能自己完成」。先問：任務在哪些點必須停下來，讓人類確認方向仍然正確？

這一篇把「交給 AI 寫程式前，先把檢查點寫進任務」收束成一個可操作的判斷：Coding agent 可以讀 issue、改檔案、跑測試甚至開 PR，但任務不能只寫一句做完。先用檢查點表決定它能做到哪一步、哪裡必須停下來給人看。

先用一張檢查點表切任務

任務越模糊，越不該一次交給 agent 做完。先拆成可驗收的節點，再決定能不能往下走。

檢查點	Agent 可以做什麼	人類要確認什麼	不通過就怎麼辦
任務摘要	重述 issue、列出目標與非目標	它有沒有補錯產品假設	改 prompt 或縮小 issue
實作計畫	列出要改的檔案、函式、測試	檔案範圍是否過大、是否碰到敏感流程	退回重新規劃
第一個小 diff	只改測試或一個明確模組	diff 是否可讀、是否容易 rollback	在範圍擴散前停下
測試與證據	跑指定測試並貼出結果	測試是否證明需求，而不是只讓 CI 變綠	補測試或重寫驗收條件
PR 審查	說明假設、限制、回滾方式	資料、權限、API、使用者路徑假設是否成立	拆 PR 或人工接手

這張表不是增加流程，重點在於避免 agent 在錯的方向上越做越多。

直接丟任務 vs 檢查點流程

如果團隊沒有清楚的 issue 範本、測試習慣和 review gate，coding agent 會放大這些缺口。

範圍： 直接丟任務會讓 agent 猜檔案與產品假設；檢查點先定義目標、非目標和禁止碰的區域。
Diff 與測試： 直接丟任務可能一次改測試、邏輯、UI、文件、設定；檢查點讓每次 diff 小到能 review，並要求證明指定行為。
Rollback： 直接丟任務可能等 PR 變大才看見風險；檢查點讓團隊能在每個節點停止、回復或拆分。

如果任務清楚、測試能覆蓋、改動很小，agent 可以加速。反過來，需求還在討論、核心流程沒有測試、沒有人說得清楚商業規則，就不要讓 agent 直接寫完整功能。

哪些任務適合 agent

Cognition 的 Devin 和其他 coding agents 讓「AI 自己開 PR」變得更常見。實務上的導入標準仍然很簡單：這個任務能不能被檢查？

適合： issue 有完成條件、非目標、相關檔案、指定測試、可控風險、review 負責人，以及小 PR 或 feature flag 的 rollback 路徑。

還不適合： 模糊功能需求、沒有測試的核心流程、付款、權限、刪除、登入，或任何驗證與回復方式不清楚的跨服務改動。

不切換案例： 如果適合條件沒有過半，不要把整個功能切給 agent。先讓它做程式碼研究、列計畫、草擬測試或找相依檔案；人類確認後，只允許它改小範圍。

Coding agent 能提高產出，但不會替團隊承擔產品責任。先把人類檢查點寫進任務，不要等 PR 大到難以檢查才補救。

用日常來理解

朋友組裝櫃子前先確認位置尺寸與檢查點的四格漫畫

朋友想請人馬上組櫃子，但一開始沒有量尺寸、確認位置，也沒有定義「完成」。
做到一半才發現放不下或方向錯了，重做會比先確認更麻煩。
先列清尺寸、步驟、檢查點和回復方式，工作才容易穩定完成。
交給 coding agent 也一樣：先設人類檢查點、測試與 rollback，再讓 AI 寫程式。

AI 整理卡

請 AI 先問情境，再整理行動清單 下面的提示詞會要求 AI 先補背景、再做判斷。適合拿來檢查你自己的流程，不是用來重寫本文摘要。

我想把這篇 BMC 微課套用到自己的情境：交給 AI 寫程式前，先把檢查點寫進任務

這篇處理的具體問題：Coding agent 可以讀 issue、改檔案、跑測試甚至開 PR，但任務不能只寫一句做完。先用檢查點表決定它能做到哪一步、哪裡必須停下來給人看。
文章連結：https://boosterminiclass.com/posts/coding-agents-need-human-checkpoints/

請不要只摘要文章。請先問我 3 個問題，確認：
1. 我現在要處理的實際流程或決策是什麼；
2. 這個流程會碰到哪些資料、權限、帳號、成本或對外動作；
3. 我希望今天得到的是停手判斷、試用清單、交接模板，還是風險分級。

接著用這篇文章的框架檢查我的情境：1. 這次要交給 coding agent 的任務範圍、非目標與禁止碰的檔案；2. agent 可以自己讀 issue、改檔、跑測試、開 PR 到哪一步；3. 哪些 diff、錯誤、權限或資料變更必須停下來給人看；4. 一份交付前的任務說明、測試、rollback 與 review 檢查表。

請輸出：
- 一句話判斷：我現在應該直接做、先限縮試做，還是暫停；
- 對照表：把本文框架逐項套到我的情境，列出已具備／缺證據／需要人工確認；
- 今天可做的一個最小步驟；
- 需要負責人、日誌、回退或人工審核的地方。