GitHub Copilot Code Review 的 effort level 怎麼選？Lite 與 Balanced 設定

Lite 與 Balanced 怎麼分#

這不是「Balanced 一定比 Lite 正確」的排序。Lite 可能更符合小型 PR 的延遲與用量需求；Balanced 也不會替你補出缺失的需求、測試或 domain knowledge。level 只控制 review 的投入深度，不能取代人類 reviewer、required approval 或 CI。

先用變更風險決定 level#

可以在送出 review 前，用下面的問題做一分鐘分級：

1. 這個 PR 是否只改單一函式、文件或明確的樣式，不會改變資料流？如果是，先考慮 Lite。
2. 是否改到 authentication、authorization、付款、migration、部署或外部 API？如果是，先考慮 Balanced。
3. 是否有跨 repository、MCP、agent skill 或非同步 job 的脈絡？如果 review 需要較深的上下文，Balanced 比較容易成為合理起點。
4. 如果 PR 看起來很小，但會改變 shared utility 或 schema，不能只因 diff 短就選 Lite；先看影響面。

即使選了 Balanced，也要要求 CI、測試與人類 review 給出可驗證的結果。不要把一次「沒有找到問題」當成安全證明，也不要把 review comment 數量當成品質指標。

組織預設與單次 PR 覆寫#

GitHub 目前提供組織層級的預設 effort level，repository 可以繼承這個預設；個別 review 也可以在發起時覆寫。這讓團隊可以採用一個低摩擦的 default，再替高風險 repository 或特定 PR 選更深的 level，而不必把所有 review 都鎖在同一種成本。

建議把政策寫成「預設值 + 例外條件」，例如：

這種政策要配合 repository 的 code owners、required checks 和 PR template；effort level 不是授權開關，也不是讓未通過測試的 PR 自動取得合併資格。

如何驗證這次 review 真的用了哪個 level#

不要只看設定頁面的 default。每次重要 PR 都應在結果頁確認：

1. review 是否成功啟動，且沒有被 organization policy 或 plan 限制。
2. PR timeline 是否標記實際使用的 effort level。
3. PR overview 是否顯示同一個 level；若兩者不一致，先保存時間、PR URL 與設定變更，再查 GitHub 文件或支援管道。
4. review comment 是否引用了正確的 head branch、instructions、skills 與測試結果。

如果你同時使用 repository agent skills 或 MCP，還要把工具邊界獨立驗證；可以接著看 GitHub Copilot Code Review 的 Skills 與 MCP。effort level 只回答「投入多少 review 深度」，不回答「它是否讀了哪些外部資料」。

GitHub 這次也把 preview 時期的 Low／Medium 名稱改成 Lite／Balanced，既有設定會延續。遇到舊文件仍寫 Low 或 Medium 時，先對照目前的設定與 changelog，不要因為名稱變了就重建整套 repository policy。

結論：先用風險選深度，再用結果做驗證#

Lite 適合範圍清楚、低風險的 PR；Balanced 適合需要更多分析的變更。兩者都不保證 review 完整或程式碼正確。可維護的做法是把 effort level 記在團隊的 review policy，對高風險 PR 明確選擇，並在 timeline／overview 驗證實際套用值，再由測試和人類 approval 完成最後判斷。

常見問題#