AI 程式設計教程中文版
官方教程中文版VS Code Agent Mode

審查程式碼修改

說明 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 檢查。

推薦順序:

  1. 先看 modified file list,確認沒有越界檔案。
  2. 再看每個檔案的 inline diff。
  3. 對明顯錯誤的檔案直接 Undo。
  4. 對可疑小塊繼續追問 Copilot 或人工修。
  5. Keep 後跑測試。
  6. 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 個問題檢查:

  1. 你是否先看了 modified file list?
  2. 每個檔案是否都被 Keep 或 Undo,而不是預設全收?
  3. Keep 後是否跑了測試、型別檢查或最小驗證?
  4. PR 裡是否說明了 agent 範圍、執行命令和剩餘風險?

透過標準:AI 改動在進入 commit 前,已經經過 pending edits、測試和 Source Control 三層檢查。

官方來源

接下來去哪

本頁目錄