審查程式碼修改
說明 VS Code pending edits、inline review、Keep Undo、檔案級批次操作和 Source Control 審查流程。
Agent 改完檔案不等於任務完成。VS Code 官方 Review AI-generated code edits 文件的核心思想是:Copilot 生成的改動會先進入 pending edits(待提交的改動),你要逐個審查,再決定 keep(保留)或 undo(撤回)。
商業專案裡,pending edits 是 Agent Mode 的安全閥。它讓你先看 diff,再決定是否把改動納入工作區——少這一道,agent 的速度優勢會直接變成 review 階段的負擔。
閱讀目標:讀完本章,你應該能在 VS Code 裡審查 AI 改動、接受或回退,並把結果交給測試和版本控制。
1. Pending edits 是什麼
VS Code 官方頁面說明,AI 程式碼修改在編輯器裡以 pending edits 形式顯示。它們和 ordinary edits 不同:你可以在接受前檢查,每個 changed line 都有標記。
典型入口:
- 檔案裡直接看到 inline diff。
- Chat response 裡看到 modified file list。
- Source Control view 裡看到 pending edits。
- 編輯器 overlay 中看到 Keep / Undo 控制。
flowchart TD
Agent["Agent 修改程式碼"] --> Pending["Pending edits"]
Pending --> Inline["Inline diff"]
Pending --> List["Modified files list"]
Pending --> SC["Source Control view"]
Inline --> Decision{"逐項處理"}
List --> Decision
SC --> Decision
Decision -->|Keep| Keep["保留改動"]
Decision -->|Undo| Undo["撤回改動"]
Keep --> Test["執行測試 / 型別檢查"]
Test --> Commit["提交或繼續 review"]
style Pending fill:#fef3c7,stroke:#d97706,stroke-width:2px
style Undo fill:#fee2e2,stroke:#dc2626,stroke-width:2px
style Test fill:#dcfce7,stroke:#16a34a,stroke-width:2px
2. 審查粒度
官方頁面覆蓋幾種審查方式:
- 逐個編輯審查:在 changed line 上看 AI 改了什麼。
- 檔案級審查:對某個檔案 Keep 或 Undo。
- 批次審查:透過 Chat response 或 Source Control 處理所有檔案。
- 普通 diff 審查:把 pending edits 當成普通 Git diff 檢查。
推薦順序:
- 先看 modified file list,確認沒有越界檔案。
- 再看每個檔案的 inline diff。
- 對明顯錯誤的檔案直接 Undo。
- 對可疑小塊繼續追問 Copilot 或人工修。
- Keep 後跑測試。
- Source Control 裡再做最終 diff review。
3. Keep 不等於 commit
Keep 只是把 AI 改動保留到工作區,不等於已經透過工程驗收。
Keep 後還要檢查:
- 是否只改了計劃中允許的檔案。
- 是否引入新依賴、配置、指令碼或許可權。
- 是否修改了敏感路徑。
- 是否有未解釋的刪除。
- 測試是否真實執行並透過。
- Commit message 是否說明 AI 參與的範圍和驗證結果。
4. Undo 和重新規劃
Undo 不是失敗。它說明 pending edits 的某一部分不應該進入程式碼庫。
觸發 Undo 的典型情況:
- 改了不該改的目錄。
- 刪除了必要邏輯。
- 用錯誤 API 或舊版本寫法。
- 生成了無法解釋的複雜程式碼。
- 沒有測試入口卻改了高風險邏輯。
Undo 後不要繼續在原 prompt 上無限修補。更穩的做法是縮小任務,或回到 Plan agent 重新拆分。
5. 團隊審查清單
建議把 Agent Mode 審查寫進 PR 模板:
- Agent 的原始任務是什麼。
- 允許修改哪些目錄。
- 實際修改哪些檔案。
- 哪些 terminal commands 被執行。
- 哪些 pending edits 被 Undo。
- 執行了哪些測試。
- 還有哪些人工 review 風險。
這樣 reviewer 不需要猜 agent 做過什麼。
深讀:為什麼 pending edits 要先於 Git diff 審查
Git diff 是最終狀態,pending edits 是 AI 改動進入工作區前的第一道檢查。越早發現越界改動,越少需要後面從大 diff 裡拆出來。
真正高質量的 Agent workflow,是讓 Copilot 快速生成候選改動,但讓人類在 pending edits 階段保留選擇權。
本章自檢
完成本章後,用這 4 個問題檢查:
- 你是否先看了 modified file list?
- 每個檔案是否都被 Keep 或 Undo,而不是預設全收?
- Keep 後是否跑了測試、型別檢查或最小驗證?
- PR 裡是否說明了 agent 範圍、執行命令和剩餘風險?
透過標準:AI 改動在進入 commit 前,已經經過 pending edits、測試和 Source Control 三層檢查。
官方來源
- Review AI-generated code edits —— VS Code 官方 pending edits 和 Keep / Undo 文件。
- Using agents in Visual Studio Code —— VS Code 官方 agents 總覽,用於理解 agent output 的審查入口。
- Responsible use of GitHub Copilot Chat in your IDE —— GitHub 官方 responsible use 頁面,用於核對 AI 輸出審查責任。