摘要： GitHub 在 2026 年 10 月 13 日宣布，組織與企業管理員現在可以在 security overview 觀察 AI Scan 對 pull requests 的實際影響，包含發現數量、修復率與 autofix 建議的採用情況。對正在評估要不要擴大導入 AI 安全掃描的團隊來說，這把「AI 工具有沒有用」從印象問題變成可量化的營運問題。
新指標到底給了什麼
根據 GitHub 的 changelog，這次公開預覽提供的指標包括：AI Scan 產生了多少發現、解決了多少、修補率（remediation rate）如何、哪些儲存庫產生髮現、所選期間的趨勢，以及開發者套用 autofix 建議的頻率。
介面也跟著調整：原本的「CodeQL pull requests」頁面更名為「Code scanning on pull requests」，並分成 CodeQL 與 AI Scan 兩個分頁。AI Scan 分頁顯示總發現數，以及有多少發現附帶或不附帶 autofix 建議；舊有的 CodeQL 指標則歸到 CodeQL 分頁之下。
為什麼對 builder 有意義
過去評估 AI 掃描工具，常見的做法是抽幾個 PR 來看，樣本小、容易失真。這組指標的價值在於把評估拉到組織層級：GitHub 明確指出，這些數據是為了幫安全團隊衡量 AI Scan 在整個組織或企業的成效、理解開發者的回應，並在不逐一看 PR 的情況下做出導入與投資決策。
修補率和 autofix 採用率是其中最值得盯的兩個數字。前者告訴你 AI 找到的問題有沒有真的被處理；後者告訴你自動修補建議是不是真的被開發者接受，而不是淪為噪音。如果採用率低，問題可能不在模型，而在建議品質或工作流程的摩擦。這和我在先前討論 token 優化時強調的順序是同一個道理：先量測，再談優化——沒有指標，任何導入決策都只是猜測。
導入前的幾個實務限制
這是公開預覽（public preview），目前支援 github.com 與 GitHub Enterprise Cloud 的客戶，需要 GitHub Code Security 或 GitHub Advanced Security 授權；GitHub Enterprise Server 不在此波支援範圍。如果你的團隊仍跑在自建環境，這條路還沒打通。
另一個限制是指標的解讀本身就是設計問題。修補率高不一定代表程式碼更安全，也可能代表團隊忙著處理低嚴重度的發現；發現數下降也不一定是好事，可能是掃描涵蓋率縮了。把這些數字放進季度檢討時，最好搭配定期的人工抽樣驗證，而不是單看儀表板。
實際的下一步：如果你已經有 Code Security 或 Advanced Security 授權，先花一個 sprint 觀察 autofix 採用率的基準值，再決定要不要對更多儲存庫開啟 AI Scan。
參考來源
在 X 上查看原貼文