任務規劃

你是 Gemini CLI 任務規劃顧問。

【角色】
Gemini CLI 任務規劃顧問，按最小夠用、安全優先的原則給可落地方案，每條結論落到能照做的步驟或示例。

【輸入】
- 要做的任務：___
- 目標和成功標準：___
- 涉及範圍：___
- 可用的驗證方式：___

【工作流程】
1. 把任務拆成可獨立驗證的小步
2. 給每步的邊界
3. 設計驗證錨點
4. 給推進順序

【輸出規範】
▌一、任務拆解
▌二、每步邊界
▌三、驗證錨點
▌四、推進順序

【硬約束】
- 任務太大先拆
- 每步可驗證、可回復
- 不可逆操作人工確認
- 不要替我臆測情況或編造不存在的命令，資訊不全先問清
- 不確定的命令或引數一律以官方文件為準，禁止照搬過時寫法
- 給的每條結論都要落到具體可照做的步驟或示例，不停留在「建議」「考慮一下」這類沒法直接執行的空泛表述
- 給的每個命令或操作都標一句它解決什麼、什麼時候用，別讓我對著一長串不知何時該用的東西發愣，也不要一次塞太多

Gemini CLI 的任務規劃能力適合處理多步驟任務。官方文件把 todos / planning 作為工具能力和 tutorial 主題列出。

什麼時候需要計劃

• 需要改多個檔案。
• 需要先讀專案結構。
• 需要跑測試並根據結果迭代。
• 涉及資料庫、構建、部署、許可權。
• 你不確定它會改哪裡。

推薦 prompt

第一句先限定邊界：先不要修改檔案。請先閱讀相關程式碼，列出執行計劃、會影響哪些檔案、需要跑哪些驗證。

確認計劃後再說：

執行時再縮小範圍：按計劃執行第一步，只改一個檔案，改完展示 diff。

更完整的版本可以直接要求它輸出邊界：

先不要修改檔案。請只讀分析這個問題，輸出：
1. 你需要檢查哪些檔案；
2. 你預計會修改哪些檔案；
3. 哪些檔案明確不會碰；
4. 每一步的驗證命令；
5. 失敗時停止條件；
6. 需要我確認的風險點。

這類 prompt 的價值不是形式感，而是把 agent 的行動範圍提前暴露出來。計劃越具體，後續 diff 越容易稽核。

一個穩定任務迴圈

flowchart TD
    A["讀專案"] --> B["列計劃"]
    B --> C["使用者確認"]
    C --> D["執行一小步"]
    D --> E["跑驗證"]
    E --> F{"透過?"}
    F -->|是| G["繼續下一步"]
    F -->|否| H["分析失敗原因"]
    H --> B

完成標準

每個任務至少要明確：

• 改哪些檔案。
• 不改哪些邊界。
• 用什麼命令驗證。
• 失敗時如何回復。
• 什麼狀態算完成。

計劃和 todo 的分工

計劃回答“為什麼這樣做、影響什麼、風險在哪”；todo 回答“目前執行到哪一步”。計劃可以寫得更完整，todo 應該短而可執行。長任務裡，兩者都需要：先有方案，再用 todo 跟蹤執行。

一個常見錯誤是把 todo 寫成“最佳化文件、修復問題、跑測試”。這種條目太大，無法判斷進度。更好的拆法是“讀取相關文件”“補導航卡”“跑 MDX 型別檢查”“記錄未覆蓋風險”。

官方 todo 工具要求同一時間只有一個 in_progress，狀態只屬於目前會話。它適合執行透明度，不適合替代專案管理。需要交接給另一個人或另一個 agent 時，要把計劃和完成狀態寫進檔案或 issue，而不是隻依賴會話內 todo。

Plan Mode 的邊界也要寫清：進入後是隻讀 PLAN approval mode，不適合 YOLO；退出時需要一個真實存在且有內容的 Markdown plan，使用者批准後才回到執行模式。

計劃質量檢查

執行前可以用這張錶快速判斷計劃是不是合格：

計劃不合格時，不要讓它直接開改。先要求 Gemini CLI 把計劃改到可審查，再批准第一步。

驗收方式

執行前檢查計劃是否覆蓋影響檔案、驗證命令、回復方式和人工確認點。執行中檢查 todo 是否只保留一個 in_progress。完成後要求 Gemini CLI 總結已改檔案、未覆蓋風險和實際跑過的驗證，不接受只說“完成了”。

接下來去哪

官方來源

• Gemini CLI task planning tutorial
• Gemini CLI todo tool
• Gemini CLI planning tools