AI 把漏洞警示修到變綠，為什麼還不能按合併？
假設團隊的後台資料查閱功能收到一則安全警示。Agent 修改了權限檢查，掃描結果轉綠，草稿 PR 也開好了。審查者卻發現，原本有權限的客服現在也看不到自己負責的資料。
這不是一件真實事故，也不是對某款工具的實測。它指出一個很容易混在一起的判斷：掃描器不再回報那則警示，和產品的權限行為仍然正確，並不是同一回事。
從警示到草稿 PR，工作沒有因此結束
GitHub 在十月宣布 Agentic Autofix 正式推出，符合資格的 GitHub Enterprise Cloud／Code Security 客戶可以把預設分支的程式碼掃描警示指派給 Copilot。它會探索相關程式碼、提出修補、重跑 CodeQL，並建立草稿 PR。這比收到一段單次修補建議更接近完整的工作流程；但「草稿」兩字不能略過。
Azure DevOps 隨後宣布把這類流程擴到相依套件漏洞與第三方掃描器警示。那邊仍在向限定的預覽使用者推出，較廣泛的公開預覽規劃在十一月，不能把 GitHub.com 的正式推出直接套到 Azure DevOps 的組織。兩邊都可能提供修補提案，卻不保證每一則警示都能修好。
對小團隊來說，新能力最可貴的地方，是把原本容易擱著的警示推進到有人可以審的差異檔。它省下「第一版改動由誰寫」的時間，沒有省掉「什麼證據夠我們合併」的決定。
把「已檢查」寫得比「已修復」精確
如果我是接手那張草稿 PR 的人，會想先看見警示來自哪條規則、落在哪個分支，接著才看改了哪些檔案、跑過哪些分析與測試。掃描器不再觸發，是針對某次分析、某組規則的結果。GitHub 的文件也提醒：自訂查詢、security-extended 查詢產生的警示，不能因 agent 重跑 CodeQL 就視為已獲同等確認；第三方掃描器的結果更不能一律用 CodeQL 的綠燈代替。
回到開頭那個假設的權限問題。我會請團隊替「不該讀到資料的人」留一個應被拒絕的測試，也替「本來就有權限的人」留一個仍能讀取的測試。兩個測試的角色與預期結果，都要依實際產品規則設定。Agent 如果只把那條掃描規則壓掉，測試與差異檔就有機會暴露行為上的退步；反過來說，測試全過也不能證明未涵蓋的路徑都安全。
若修補是升級相依套件，審查重點又不同：版本和鎖檔變了什麼、建置與現有功能是否相容。把每一種警示都塞進同一份驗收清單，最後只會得到一排看似完整的勾選框。
我比較希望草稿 PR 清楚留下四件事：原警示與對應的改動、掃描器實際重跑的範圍、相關 CI 與行為測試的結果，以及還沒驗證的部分。這是給審查者使用的建議格式，不是宣稱產品會自動附上這些欄位。有人能從這些資料判斷是否可合併，才算把工作交接出去；單獨一個綠燈做不到。
試行時，先縮小派工範圍
正式把警示交給 agent 前，先確認自己的方案是否符合資格、預設分支是否有可指派的警示，以及企業、組織和儲存庫的相關設定與計費方式。這個流程可能消耗 AI credits 與 GitHub Actions 分鐘數。即使介面允許一次處理多個警示，第一次也不必整批交出去：挑一則範圍清楚、有人願意審的警示，比一次收進一串難以對照的改動好。
修補提案可以由 agent 先寫，合併責任仍然屬於了解產品行為的人。當掃描範圍、測試結果或權限規則說不清楚時，就讓 PR 停在草稿狀態。交到人手上的不該只是一張變綠的圖，而是一份能指出哪些地方已檢查、哪些地方仍待確認的改動。
資料來源與範圍
產品範圍及驗證限制依同日蒐集的官方公告與文件搜尋摘錄；未直接擷取原頁全文，亦未實測掃描器、修補功能或費用。後台權限例子與 PR 驗收方式是假設情境及建議流程，並非安全性測試結果。