如果 AI 一口氣列出十個「高風險漏洞」，你會立刻排進修復清單，還是先問它在哪個環境重現？對維護網站的小團隊，後者通常才是下一步：工程師需要能檢查的證據，不能只收到一段很有把握的推論。
Google 在 9 月 24 日介紹 PageBreak，表示這項內部專案已在自家網頁應用累計找出逾 500 個跨站腳本（XSS）漏洞。這是 Google 公布的成果，不是本站實測，也不是當天一次找出的數量。
PageBreak 的關鍵，是驗證後才把問題交出去
PageBreak 將候選問題交給不是由 AI 撰寫的專用驗證器，在執行環境確認後才通報產品團隊；未驗證的線索留下來繼續調查。Google 稱誤報率接近零，同時承認驗證能力仍有缺口。
因此，我更在意報告附了什麼，而不是 AI 用多肯定的語氣描述漏洞。即使列出函式名稱、檔案位置和嚴重程度，也可能漏看前面的存取限制，或把測試用的程式當成正式服務。這些是審查時應排除的可能性，不是上述專案已發生的個案。
這次公告沒有提供對外下載版本，也不代表團隊可以直接複製 Google 的內部測試條件。若你要評估公開工具，可另讀 Google Mantis 的沙箱與驗收限制，兩者的取得方式與使用範圍要分開看。
「沒有確認」和「確認沒有」差在哪裡？
假設一份 AI 報告指出後台預覽功能可能有問題，但測試帳號根本進不了後台。此時比較合理的狀態是「缺少測試權限，尚未驗證」，不能直接標成誤報，也不能對老闆說這個功能已經安全。
誤報是把不存在的問題當成存在；漏報則是問題存在卻沒有找出來。把通報門檻提高，可以讓工程師少處理不成立的警報，但不會自動增加測試涵蓋範圍。收件匣變安靜，和系統風險降低，需要不同的證據。
我的建議是保留三種狀態：待驗證、已確認、修補後已複查。第一種要有人追蹤缺少什麼，不要直接算進「已發現漏洞」的績效數字；第三種則要留下重新測試的結果，避免把程式碼已合併當成修復已完成。
小團隊收到 AI 資安報告，先要求什麼？
OWASP 的報告指南建議，技術發現應讓工程師能理解、重現並處理問題，也要交代測試範圍與限制。內部 issue 可以精簡，但接手的人仍需要足夠資訊採取行動。
可以從一個最小的交付要求開始：報告寫清楚測的是哪個版本、用了什麼帳號權限、預期與實際結果有何差異，並附上去除機密資料的證據。重現只能在自己擁有或已獲授權的環境進行；若測試條件不足，就明確列出缺項。
例如你請工程師檢查一個表單，不必先追求掃完整個網站。先挑一項候選問題，由另一人按報告確認結果，再決定是否修補和擴大測試。這是本文建議的試行方式，並非 PageBreak 的公開操作教學。
當 AI 也會讀取網頁、issue 或測試資料時，還要避免把其中的文字直接當成新指令。可接著看提示詞注入的辨識與防護，把「正在檢查的內容」與「准許採取的動作」分清楚。