07 · Cloud Agent 到 PR 的閉環
解釋 Cloud Agent 如何從 prompt 或 issue 出發，研究儲存庫、建分支、改程式碼、給出 diff 並進入 PR 審查。
📖 本篇術語速查表
| 英文 / 縮寫 | 中文 | 一句話解釋 |
|---|---|---|
| Cloud Agent | 雲端代理 | 在雲端非同步跑、直接產出 PR。 |
| PR 閉環 | pr loop | 從任務到 PR 再到審查合併。 |
| 人工把關 | gate | PR 由人審查後合併。 |
不想讀完？把下面這段提示詞丟給 AI 幫你跑完——幫你用 Copilot Cloud Agent 跑通從任務到 PR 的閉環。
你是 Copilot Cloud Agent 顧問。
【角色】
Copilot Cloud Agent 顧問，按最小夠用、安全優先的原則給可落地方案，每條結論都落到能照做的步驟或示例，不停留在空泛建議。
【輸入】
- 想讓它非同步完成什麼任務：___
- 涉及的儲存庫和分支：___
- 團隊的 PR 審查流程：___
- 許可權要求：___
- 經驗水平：___
【工作流程】
1. 判斷任務適不適合雲端非同步
2. 說明任務到 PR 的流程
3. 強調 PR 必須人工審查
4. 按最小給許可權
5. 給驗證
【輸出規範】
▌一、是否適合雲端非同步
▌二、任務到 PR 流程
▌三、PR 人工審查
▌四、許可權 + 驗證
【硬約束】
- 雲端產出的 PR 必須人工審查後合併
- 許可權按最小必要
- 非同步任務設計成低介入
- 不要替我臆測情況或編造不存在的能力，資訊不全先問清
- 不確定的設定或介面一律以官方文件為準，禁止照搬過時寫法Cloud Agent 最適合的不是你盯著螢幕等三分鐘的小改，而是可以非同步推進、最後回到 branch 和 PR 審查的儲存庫任務。GitHub 官方說明，Copilot cloud agent 能完成"研究儲存庫 → 制定實現計劃（implementation plan）→ 在分支裡改程式碼"這條鏈路，並在你準備好時建立 pull request。
本章目標：你會把 Cloud Agent 當成 GitHub PR 工作流的一部分使用，而不是當成一個“幫我自動寫完”的黑箱。
1. PR 閉環
flowchart TD
Source["Issue / Prompt / Agents tab"] --> Research["Research repository"]
Research --> Plan["Implementation plan"]
Plan --> Branch["Agent branch"]
Branch --> Diff["Diff / commits / test output"]
Diff --> Iterate{"需要繼續改?"}
Iterate -->|是| FollowUp["Follow-up prompt"]
FollowUp --> Branch
Iterate -->|否| PR["Create pull request"]
PR --> Review["Human review / checks"]
Review --> Merge{"透過?"}
Merge -->|是| Ship["Merge"]
Merge -->|否| More["Comment / request changes"]
More --> Branch這個閉環裡，Cloud Agent 的產物不是“回答”，而是可審查的 branch、commits、diff、checks 和 PR 討論。
2. 兩種啟動方式
官方啟動任務頁有一個重要分工：
- Assign issue to Copilot（把 issue 直接指派給 Copilot）：適合 issue 已經寫清目標、範圍和驗收標準；Copilot 會基於 issue 標題、描述和已有 comments 工作，並建立 PR 或請求 review。
- Agents prompt / Agents tab（在 Agents 標籤頁裡發起 prompt）：適合任務還需要研究和迭代；預設先在 branch 上工作，你可以 review diff、繼續追加 prompt，然後再決定是否建立 PR。
一個容易踩的坑：issue assignment 後新增到 issue 的 comments，Copilot 不一定自動看到。後續上下文要寫到它建立的 PR 或 session 裡。
3. Prompt 要像 issue spec
Cloud Agent prompt 不應該是“幫我最佳化一下”。它至少要包含四件事：
目標：
修復登入錯誤提示不清楚的問題。
範圍：
只處理 Web 登入頁和 auth 錯誤對映。
不要改：
認證協議、資料庫 schema、billing、workflow。
驗證：
執行 auth 相關測試，說明未覆蓋風險。如果任務包含 UI 差異，可以附 screenshot 或 mockup。上傳前要遮住賬號、客戶資料、token、內部 URL 和生產資訊。
4. Research、Plan、Iterate
Cloud Agent 的高質量用法不是直接 PR，而是先 research、plan、branch iterate，再 PR。
Research 階段：
- 讓它列相關檔案、測試、入口和不確定點。
- 明確“不要改程式碼”。
- 檢查它是否讀到了正確模組。
Plan 階段：
- 看目標和非目標是否清楚。
- 看檔案範圍是否合理。
- 看測試命令是否真實存在。
- 看開放問題是否需要你回答。
Iterate 階段：
- 審 branch diff。
- 要求撤銷無關改動。
- 補測試或收窄範圍。
- 準備好後再建立 PR。
5. 什麼任務適合 Cloud Agent
適合：
- backlog 裡的中低風險改進。
- 文件、測試、技術債、錯誤提示。
- 能透過 branch、CI、PR review 驗收的小功能。
- 需要先讀儲存庫再給方案的任務。
不適合：
- 本地未提交現場。
- 必須依賴本機登入態、私密 UI 或本地環境。
- 生產部署、資料遷移、許可權調整。
- 沒有測試和 review 路徑的模糊需求。
Cloud Agent 在 GitHub Actions 驅動的臨時開發環境中執行，但臨時環境不等於沒有風險。它仍然可能改 workflow、依賴、許可權設定或業務邏輯。
6. 審查清單
PR 出來後，至少檢查：
- 是否符合 issue 或 prompt 的範圍。
- 是否新增依賴、workflow、許可權或設定。
- 是否刪除測試或跳過失敗。
- commit 和 diff 是否可理解。
- checks 是否跑過並透過。
- Copilot 的說明是否和程式碼一致。
- 是否需要人工補充測試或回復說明。
Cloud Agent 能提高非同步吞吐，但不能替代程式碼負責人。
本章自檢
你應該能回答：
- 這個任務應該 assign issue 直接 PR，還是先 prompt 到 branch 迭代？
- prompt 是否寫清目標、範圍、不可觸碰內容和驗證方式？
- PR 前是否已經審過 branch diff 和測試輸出？
- 失敗時能否關閉 PR 或人工接管分支？
透過標準：Cloud Agent 的每一步都能被 GitHub 物件追蹤，而不是隻靠自然語言總結。
官方來源
- About GitHub Copilot cloud agent：官方 cloud agent 能力、執行環境和適用邊界。
- Kick off a task with Copilot agents on GitHub：官方任務啟動入口、issue assignment 和 prompt 分工。
- Research, plan, and iterate on code changes with Copilot cloud agent：官方 research、plan、iterate、PR 流程。
- Responsible use of GitHub Copilot cloud agent：官方 responsible use 和安全邊界。