Claude Code 動態工作流：用檢查點把任務拆成可控步驟

複雜任務若只用一句“把這個專案做好”，模型很難知道完成標準，也不利於審查。更穩妥的動態工作流，是根據倉庫現狀逐步決定下一步：先調查，再提出方案，執行一小段，檢查結果，然後繼續。Claude Code 的命令和設定會變化，本文講的是通用協作模式；具體許可權與 hooks 以當前官方檔案為準。

先寫清任務邊界

提供目標、允許修改的目錄、不可觸碰的配置，以及驗收條件。例如：“修復登入頁窄屏溢位，只改 UI 檔案；完成後說明改動與驗證方法。”要求 Agent 先讀取相關程式碼並列出假設，不要一開始就授權刪除、部署或遷移資料。明確哪些操作必須等待人工批准。

按檢查點推進

第一階段只讓它定位頁面和復現路徑；第二階段給出最小修改方案；第三階段實施有限改動；第四階段檢查 diff、執行適當的本地驗證並報告未覆蓋部分。每個階段都要看實際結果，再決定是否進入下一步。若調查揭示問題範圍超出預期，先更新任務邊界，而不是讓 Agent 順手重構整個模組。

把上下文交接寫成記錄

對長任務，儲存目標、已確認事實、未解決問題和關鍵檔案路徑。新的會話從這份簡短記錄繼續，避免重複讀大量無關材料。不要把臨時猜測寫成事實；標註“已驗證”和“待確認”。涉及多個子任務時，給每個任務獨立的完成標準和檔案邊界，減少並行修改衝突。

許可權、工具與安全

工具許可權決定 Agent 能讀寫什麼。優先使用專案級配置和明確白名單，審查 shell 命令、聯網請求和檔案寫入；不要把 API 金鑰放進提示或提交記錄。需要通知或自動觸發時，先確認當前 Claude Code 版本支援的 hook 事件與輸入格式，使用官方示例並在臨時專案裡驗證。任何影響生產資料的步驟都應由人執行或逐項批准。

如何判斷流程有效

比較返工次數、越界修改和審查時間，而不是隻看生成速度。若 Agent 常誤解要求，改善任務說明與驗收條件；若它頻繁停下來詢問，則檢查許可權是否設定過窄。對一次性小改動，直接問答可能更合適。動態工作流的價值在於高風險、多檔案任務有清晰暫停點。

官方資料

Anthropic Claude Code 官方概覽文件