研究、計劃和迭代
說明 Copilot cloud agent 如何先研究儲存庫、生成計劃、在 branch 上迭代程式碼，再建立 pull request。
📖 本篇術語速查表
| 英文 / 縮寫 | 中文 | 一句話解釋 |
|---|---|---|
| Research-plan-iterate | 調研-計劃-迭代 | 複雜任務的推進節奏。 |
| 中途糾偏 | steer | 看進展後給反饋調整。 |
| 迭代 | iterate | 分輪推進而非一次到位。 |
不想讀完？把下面這段提示詞丟給 AI 幫你跑完——幫你用調研-計劃-迭代的節奏推進 Cloud Agent 的複雜任務。
你是 Cloud Agent 迭代推進顧問。
【角色】
Cloud Agent 迭代推進顧問，按最小夠用、安全優先的原則給可落地方案，每條結論都落到能照做的步驟或示例，不停留在空泛建議。
【輸入】
- 複雜任務目標：___
- 已知的約束和未知點：___
- 可接受的迭代輪次：___
- 每輪怎麼驗證：___
- 經驗水平：___
【工作流程】
1. 拆出調研、計劃、執行各階段
2. 設計每輪的反饋和糾偏
3. 說明怎麼中途調整方向
4. 給迭代收斂標準
5. 給第一步
【輸出規範】
▌一、階段拆分
▌二、每輪反饋糾偏
▌三、中途調整
▌四、收斂標準 + 第一步
【硬約束】
- 複雜任務分輪推進，不一次到位
- 每輪看進展再糾偏
- 收斂標準明確，避免無限迭代
- 不要替我臆測情況或編造不存在的功能，資訊不全先問清
- 不確定的設定或許可權一律以官方文件為準，禁止照搬過時寫法
- 給的每條結論都要落到具體可照做的步驟或示例，不停留在「建議」「考慮一下」這類沒法直接執行的空泛表述Cloud agent 的高質量用法不是“直接讓它開 PR”，而是先研究、計劃、在 branch 上迭代，等 diff 可接受後再建立 PR。GitHub 官方頁面明確說明，這些能力只在 GitHub.com 上的 Copilot cloud agent 中可用——某些第三方整合只能直接建立 PR。
閱讀目標：讀完本章，你應該能把 cloud agent 任務拆成 research、plan、iterate、PR 四段，而不是一次性丟給它。
1. 四段流程
- Research：讓 Copilot 先讀儲存庫、回答問題、確認相關檔案。
- Plan：讓 Copilot 給 implementation plan，並列出開放問題。
- Iterate：在 branch 上看 diff，補充約束，讓它繼續改。
- PR：準備好後再建立 pull request，並進入普通 review。
flowchart TD
Prompt["任務 prompt"] --> Research["Deep research"]
Research --> Plan["Implementation plan"]
Plan --> ReviewPlan{"計劃可接受?"}
ReviewPlan -->|否| Clarify["補充要求"]
Clarify --> Research
ReviewPlan -->|是| Branch["在 branch 上修改"]
Branch --> Diff["審 diff"]
Diff --> Iterate{"需要繼續改?"}
Iterate -->|是| Follow["follow-up prompt"]
Follow --> Branch
Iterate -->|否| PR["Create pull request"]
style Research fill:#dbeafe,stroke:#2563eb,stroke-width:2px
style Diff fill:#fef3c7,stroke:#d97706,stroke-width:2px
style PR fill:#dcfce7,stroke:#16a34a,stroke-width:2px2. Research 階段怎麼問
適合先問：
研究這個儲存庫：
找出登入錯誤是在哪些檔案裡處理的。
現階段不要改程式碼。
列出相關檔案和對應的測試。Research 階段不要急著讓它實現。目標是確認它讀到的檔案和你預期一致。
3. Plan 階段怎麼看
一個可執行計劃應包含：
- 目標和非目標。
- 相關檔案。
- 實施步驟。
- 風險。
- 測試命令。
- 需要你回答的問題。
計劃不合格時，不要直接讓它“繼續”。用 follow-up prompt 補充約束，例如“不要改 schema”“只處理 web app”“保留舊 API”。
4. Iterate 階段怎麼控範圍
迭代階段要關注 branch diff：
- 是否改了 prompt 裡禁止的檔案。
- 是否新增依賴或 workflow。
- 是否刪除了測試。
- 是否把問題擴充套件成無關重構。
- 是否有明顯未執行測試的跡象。
如果需要改進，使用具體的 follow-up prompt：
保留目前的實現思路。
撤銷剛才對設定檔的改動。
補一個迴歸測試覆蓋這條 bug。
不要動 .github/workflows。5. Visual context
官方頁面說明可以提供視覺上下文，例如 screenshot 或 UI mockup。適合 UI bug、空狀態、錯誤提示、佈局差異。
使用時仍然要脫敏：
- 遮住賬號、token、客戶名稱。
- 不上傳內部 URL 或生產資料。
- 截圖只保留完成任務所需區域。
深讀：為什麼先 branch 迭代比直接 PR 更適合不確定任務
直接 PR 適合清晰 issue。對於需要探索的任務，先在 branch 上研究和迭代，可以避免讓 reviewer 面對一個方向錯誤的大 PR。
Cloud agent 的價值不只是寫程式碼，還包括把方案和 diff 提前暴露，讓你在 PR 前就能修正方向。
本章自檢
完成本章後，用這 4 個問題檢查：
- Research 階段是否列出了相關檔案和測試？
- Plan 是否有可執行步驟和開放問題？
- Branch diff 是否只改了允許範圍？
- 建立 PR 前是否已經審過主要 diff 和測試結果？
透過標準：PR 建立前，方向、範圍和驗證都已經被審過一輪。
官方來源
- Research, plan, and iterate on code changes with Copilot cloud agent —— 官方研究、計劃和迭代頁。
- Kick off a task with Copilot agents on GitHub —— 官方啟動任務頁。
- Responsible use of GitHub Copilot cloud agent —— 官方 responsible use 頁面。