GitHub Copilot Code Review 自動解決 comment？用 re-review 驗證剩餘問題

自動解決發生在 re-review，不是按下 Resolve#

可以用這個順序理解新流程：

1. Copilot Code Review 在 pull request 留下 comment。
2. 開發者依 comment 修改程式碼並 push 新 commit。
3. Repository 若開啟 Review new pushes，就會自動啟動下一次 review；否則要手動要求 re-review。
4. Copilot 將新 diff 和原 comment 對照，確認問題已被修正後，才會解決自己的 comment。
5. 仍未被修正的問題會留在 pull request，不能只看已解決數量判斷整個 review 完成。

這裡的「自動」是指 re-review 結果能更新 Copilot 自己的 comment 狀態，不是每次 push 都一定會產生 review。觸發規則仍由 repository 的 code review 設定和 branch workflow 決定。

先確認新 commit 真的處理同一個問題#

看到 comment 變成 resolved 前，至少檢查四件事：

• 檔案和行號：確認修正落在原 comment 指向的行為，而不是只移動程式碼讓行號消失。
• 新 diff：看變更是否真的消除了問題，沒有用註解、條件繞路或刪除測試掩蓋它。
• 測試與 CI：讓對應測試、lint、型別檢查或安全掃描跑完；review 狀態不會取代 required checks。
• 剩餘 comment：逐一閱讀仍開啟的 comment，尤其是 re-review 可能補上的跨檔案問題。

可以把 review 結果當成一個待驗證的狀態轉移，而不是數字 KPI：open → 修正 → re-review → resolved。如果中間沒有新的分析，open → resolved 就不應被當成已完成的證據。

套用 suggested change 後，先看 commit 再看狀態#

GitHub 這次也更新了 suggested-change 的套用流程：當你在 Copilot review comment 直接套用建議時，系統會依實際變更產生 smart commit message。這能讓歷史紀錄比固定的「Apply suggestion」更容易閱讀，但 commit message 仍是描述，不是測試報告。

建議的操作順序是：

1. 先閱讀 suggestion 的 diff，確認它沒有超出原 comment 的範圍。
2. 套用後閱讀產生的 commit message 和完整 diff。
3. 執行受影響的測試與必要的手動驗證。
4. 再 push 或要求 re-review，確認原 comment 和其他 review 結果。

如果一次套用多個 suggestion，還要確認每個 suggestion 的變更沒有互相覆蓋。自動產生的 message 只幫你整理提交語意，不能取代 reviewer 對變更內容的判斷。

Review 分析更新，不代表治理規則改變#

GitHub 同一則公告也提到分析側的變更：更廣的 shell tools 會在 agent firewall 後提供驗證能力，Lite 會使用多 agent ensemble。這些更新影響 Copilot 如何分析與驗證，不會改變你如何要求 review、如何設定自動 review，也不會讓 review 變成必然完整。

因此要把下面幾層分開：

想調整 review 深度，可以參考 GitHub Copilot Code Review 的 Lite 與 Balanced；想讓 approval 影響 merge gate，則要另外看 Copilot Code Review 核准與安全設定。本篇的自動解決 comment 不會替你開啟這些設定。

用低風險 PR 驗證整個收尾流程#

不要一開始就在 production repository 依賴 resolved comment。可以用文件或測試 repository 做一次可回溯的驗證：

1. 建立一個刻意包含簡單問題的 pull request，要求 Copilot Code Review。
2. 先保存原始 comment、review 觸發方式和當時的 commit SHA。
3. 以最小 diff 修正問題，push 新 commit。
4. 開啟 Review new pushes 時等待自動 review；未開啟時手動要求 re-review。
5. 比對 comment 狀態、review overview、新 diff 與 CI 結果。
6. 再做一個只修表面、不修根因的變更，確認團隊不會把「comment 少了」當成唯一完成條件。

這個測試同時能確認 repository policy 是否真的套用、review 是否使用預期的 effort level，以及 branch protection 是否仍等待必要的人類或機器檢查。

結論：把 resolved 當成線索，不是核准章#

Copilot Code Review 的自動解決功能讓修正後的 comment 更容易收斂，但它依賴 re-review 的分析結果。可靠的完成條件應該是：原問題已在 diff 中被處理、re-review 狀態更新、剩餘 comment 已閱讀、CI 和治理規則都通過。這樣才不會把 UI 上的 resolved 誤當成整個 pull request 已經安全。

常見問題#