GitHub Copilot 成效怎麼看？用 repository 指標先分開 PR 活動與品質判斷

先確認這份資料回答的是什麼#

新的報表可看到兩類活動：Copilot coding agent 建立或合併的 PR，以及 Copilot code review 審查的 PR 和依 comment 類型拆分的建議數。它能幫你定位「哪些 repository 正在使用」，但不能單獨證明變更比較好、審查更快，或缺陷變少。

我會把它當成第一層盤點資料，再搭配既有的 CI 結果、revert、production incident 或人工審查紀錄。這樣才不會把「建議留言很多」誤讀成「審查品質很好」。

兩個 endpoint 都必須指定一天#

GitHub 提供 organization 和 enterprise 兩種端點；每次都用 day=YYYY-MM-DD 查單日資料：

1
# Organization owner、enterprise owner 或具 View Copilot Metrics 權限的角色使用
2
gh api \
3
  '/orgs/你的組織/copilot/metrics/reports/repos-1-day?day=2026-07-19'

若在 enterprise 範圍盤點，路徑改成：

1
gh api \
2
  '/enterprises/你的企業/copilot/metrics/reports/repos-1-day?day=2026-07-19'

這不是把所有歷史資料一次倒出來的 endpoint。要觀察一週或一個月，應由排程逐日拉取、保留查詢日期與原始回應，再在自己的資料表做彙整。不要猜測 API 會自動補齊缺少的日期。

先處理權限與 policy

GitHub 說明指出，enterprise owner、billing manager、organization owner，或獲授 View Copilot Metrics 的自訂角色才能存取；同時還必須啟用 Copilot usage metrics policy。若回應是權限錯誤，先檢查這兩項，而不是直接改用其他人的 token。

把指標接到可審核的週報，而不是排名表#

我會用下面的欄位保留一份最小週報：

1
日期：2026-07-19
2
範圍：organization / enterprise
3
repository：
4
coding agent 建立 PR：
5
coding agent 合併 PR：
6
code review 審查 PR：
7
建議數（依 comment 類型）：
8
CI 失敗／revert／事故連結：
9
人工觀察與下一個檢查點：

前五項來自 Copilot usage metrics；後面三項由團隊自己的工程流程補上。這個分法能保留官方資料的原意，也讓看到異常活動時能回到 PR 和 CI 證據，而不是以單一排行榜決定誰「最會用 AI」。

若你的 agent 工作流程是用 GITHUB_TOKEN 呼叫 Copilot，還應分開記錄 workflow 的 token 成本與這份 PR 活動資料；兩者回答的分別是「跑了多少 inference」與「在 repo 裡產生了哪些 PR 互動」。可搭配 GitHub Agentic Workflows 不用 PAT 後：權限、費用與寫入邊界怎麼設 一起設計。

上線前的三個檢查#

1. 先選一個 repository 與一天交叉驗證：對照 API 回應、PR 清單和 code review 紀錄，確認欄位理解正確。
2. 不要把個人或小隊比較當成預設用途：官方資料是 repository 活動報表，沒有直接提供品質或個人產能評分。
3. 固定週期與保留快照：每天端點只查一天；週報或月報需要由你自行保存採樣日期與資料來源。

真正有價值的做法不是多畫一張儀表板，而是先確認每個數字可以回到哪個 repository、哪張 PR 和哪一個工程結果。這樣當 Copilot 的使用範圍擴大，團隊仍能判斷是值得複製的流程，還是需要補測試與審查規則的警訊。

常見問題#