GitHub Copilot 程式碼審查可正式批准 PR，核准票能計入合併門檻

GitHub 擴大 Copilot code review 的權限：每次審查現在都會在總覽留言中顯示「是否可批准」的判斷，而管理員可進一步允許 Copilot 提交正式 Approve review。單純的判斷提示不會影響合併規則；只有啟用正式批准後，Copilot 的票才會計入儲存庫要求的核准數。新提交進入 PR 後，舊核准會像人類審查一樣被撤銷，必須重新要求檢查。

這項能力預設關閉，控制範圍分為企業、組織及儲存庫三級。企業可全面禁用或下放決定權；組織可指定個別儲存庫；儲存庫管理員還能限制 Copilot 可以批准的檔案路徑。功能目前向 Copilot Pro、Pro+、Max、Business 與 Enterprise 方案提供公開預覽。技術上的變化不是多一段摘要，而是模型輸出首次能直接滿足既有 branch protection 的 required approvals 條件，因此權限設定已成為軟體供應鏈控制的一部分。

近期針對 GitHub 事件的大規模研究也顯示，AI 撰寫、AI 審查的閉環並非邊緣現象。研究者辨識出約 283 萬個代理撰寫的 PR，其中 248,641 個至少收到一次 AI 審查；跨產品審查占已辨識代理 PR 約 1.6%。不過資料依賴產品簽名歸因，數量只是下限，而且留言分類不能代表真正找到缺陷。

團隊不宜把 Copilot 核准直接替代安全審查。較穩妥的做法是先限定低風險路徑，保留人類或不同工具的獨立核准，並量測漏報、誤報及新提交後的重新審查行為。後續關鍵是 GitHub 是否公開核准門檻、模型版本變更紀錄，以及在安全漏洞、生成程式碼與同產品閉環情境下的分層評測。