GitHub Code Quality 導入與 Agentic Autofix：成本、批次修補與驗收

Code Quality 實際包含哪些分析#

GitHub Code Quality 會在 pull request 與 default branch 提供結果。規則型分析使用 CodeQL，AI-powered analysis 則補充規則未涵蓋的問題；兩者的結果與可用語言範圍不要混為同一套保證。

GitHub 文件列出的 CodeQL 規則型分析語言包含 C#、Go、Java、JavaScript、Python、Ruby 與 TypeScript。AI-powered analysis 的涵蓋範圍可能更廣，但不能因此把 AI finding 當成所有語言都具有相同深度的靜態分析。

Trends 看到的是變化，不是單一品質分數#

Organization-level Code Quality dashboard 的 Trends tab 會把 open findings 依日期區間整理成趨勢。GitHub 目前提供 7、14、30 天的範圍，可以依 health score 或 severity 分組，並同時顯示目前 open findings 總數與區間開始到現在的 net change。

它還提供兩張 repository 表格：哪些 repository 改善最多，以及哪些 repository 需要支援。圖表與表格會套用 dashboard 上的 repository filters，因此可以先縮小到某個團隊、產品線或 repository 集合，再判讀變化來源。這讓 Trends 適合回答「哪裡在變差、哪裡正在改善」，但不該被解讀成單一的團隊品質排名。

這項能力的前提仍是 organization 已啟用 Code Quality，並使用 GitHub Team 或 GitHub Enterprise Cloud；GitHub Enterprise Server 不在支援範圍。Organization owner 能看到所有已啟用 repository 的資料，其他成員則受限於自己有權查看的 Code Quality findings，官方文件也對可見 repository 數量設有上限。若你要追蹤長期趨勢，先記錄 dashboard 的範圍、權限與啟用清單，避免把「看不到」誤認成「沒有 findings」。

可以把 Trends 放進 pilot 的驗收流程：先保存一個 7 天或 14 天基準，再對照 open findings、health score、repository filter 和實際 PR 修補。Code Quality 的 Trends 和 default setup 的中央 CodeQL 設定 是兩個不同層次；前者觀察結果如何變化，後者控制掃描設定如何套用。

Agentic autofix 一次最多處理 25 筆 finding#

2026 年 9 月 9 日後，Code Quality 的 findings 頁面可選取單筆或最多 25 筆 standard findings，再用 Assign to Copilot 啟動修補。Copilot 會建立分支、修改程式碼、執行它能使用的驗證，最後開出 pull request。這個流程取代原本逐筆使用的 Generate fix，但不代表選取的 25 筆一定會在同一次執行中全部修好，也不代表 PR 可以略過既有的 review 與 required checks。

批次上限是介面允許的最大數量，不是每次都應選滿。實際分組時可用三個邊界縮小風險：

1. 同一個 repository、語言與模組的 findings 才放在一起，避免 PR 同時跨越互不相關的責任範圍。
2. 先處理 severity、規則類型與測試路徑相近的項目；若修補會碰到共用 API，再縮小批次。
3. PR 建立後逐筆對照 finding 是否關閉、測試是否真的覆蓋修補路徑，以及 diff 是否出現範圍外重構。

Agentic autofix 沿用 enterprise 現有的 Code Quality policy，沒有另一個獨立的企業政策開關。可使用 Code Quality 的 repository 不等於每位使用者都能指派 cloud agent；執行指派仍需要符合功能要求的 Copilot license，且 agent 工作會消耗 AI credits。上線前應用測試帳號實際確認按鈕、授權與帳務，不要只從管理頁的 Code Quality 啟用狀態推論權限完整。

先算清楚三種成本#

GitHub Changelog 將 Code Quality 描述為獨立的付費產品，並列出三類成本：

1. 授權費：每位 active committer 每月 $10。active committer 是在啟用 Code Quality 的 repository 推送過 commit，且時間落在最近 90 天的人；同一位 committer 在組織內只計一次，bot account 不收費。
2. AI 用量：AI-assisted detection 與修補會依 usage-based billing 使用 GitHub AI credits。檢視 Code Quality 結果本身和把工作指派給 Copilot agent 是不同權限；後者需要符合要求的 Copilot license。
3. 分析計算：deterministic CodeQL analysis 會使用 GitHub Actions minutes，GitHub-hosted 與 self-hosted runner 都可支援，但 runner 成本與並行限制仍要自行評估。

這三筆要分開記錄。active committer 數量是授權基礎，AI credits 是模型相關用量，Actions minutes 則是分析執行資源；用一個「每個 PR 平均成本」欄位把它們全部相加，會讓後續排查變得困難。

Enablement 先用小範圍 pilot#

Code Quality 的控制面可分 enterprise、organization 與 repository 三層。建議先採一個可以回溯的 pilot：

官方文件支援 organization-wide enablement、organization dashboard 與 API；這些能力適合在 pilot 通過後使用，不代表一開始就要對整個 organization 全開。先保留 selected repositories，較容易辨認新增的 finding、費用與 Actions 用量從哪裡來。

Quality gate 不要第一天就阻擋所有 PR#

Code Quality 的 rulesets 可以設定 quality 與 coverage threshold，也有 evaluate mode 讓團隊先觀察結果。實務上可以採下面順序：

1. 先讓 findings 出現在 PR，確認嚴重度與修補建議是否適合團隊程式碼。
2. 將既有技術債與新引入的問題分開；不要因為舊 repository 一次出現大量 finding，就直接阻擋所有新 PR。
3. 先對單一高影響條件設 evaluate，例如 coverage 不得比 default branch 下降。
4. 等測試、例外與誤報處理成熟後，再讓 ruleset 對特定 PR 阻擋 merge。

Agentic autofix 產生的是待 review 的 PR，不能取代測試、PR review 或 branch protection。若團隊也在追蹤 Copilot 的 PR 活動，可以參考 repository 指標與品質判斷的分界，不要把 finding 數、merge 數或 AI 使用量直接當成品質分數。

GA 導入前的最後檢查#

• 列出要啟用 Code Quality 的 repository、語言與 active committer 估算。
• 確認 enterprise、organization、repository 三層各由誰負責開關。
• 將 AI credits 與 Actions minutes 放進不同的預算或告警維度。
• 確認測試能輸出 Cobertura XML，且 coverage 的基準分支定義清楚。
• 用 evaluate mode 跑一個完整 PR 週期，再決定是否阻擋 merge。
• 在 organization dashboard 保存 Trends 的初始日期區間、repository filter 與 open findings，讓後續比較有固定邊界。
• 用 1 至 3 筆同模組 finding 試跑 Agentic autofix，逐筆核對 finding、diff、測試、required checks 與 AI credits。
• 為 preview 時期已開啟的 repository 重新檢查啟用範圍，因為 GA 後已開始計費。

Code Quality 的價值在於把品質檢查與修補放進既有 PR 流程，並讓團隊能觀察 findings 的變化；導入成功的條件是成本、finding、測試、趨勢範圍與審查責任都能被分開追蹤。先小範圍啟用，再從少量同類 findings 驗證 agentic autofix，會比一開始選滿 25 筆更容易辨認失敗原因。

常見問題#