在 AI 工具普及的今天，許多初入行的工程師或安全研究員可能會發現，使用 AI 掃描程式碼或生成攻擊 Payload（攻擊載荷，指用來觸發漏洞的特定數據）變得異常簡單。AI 能在幾秒鐘內分析 API、總結攻擊面，甚至寫出一份看起來非常專業的漏洞報告。
然而，這裡存在一個危險的認知陷阱：AI 產出的「結果」並不等於「證據」。在攻擊性安全（Offensive Security）領域，最核心的價值不在於你發現了多少個疑似漏洞，而是在於你能否證明這個漏洞在真實環境中是可以被觸發且具有影響力的。
AI 產出的是假設，而人類知識負責將假設轉化為事實。
看似漏洞與真實漏洞的鴻溝
AI 非常擅長模式識別。當它在程式碼中看到使用者輸入直接進入資料庫查詢時，會立刻告訴你這可能是 SQL Injection（SQL 注入）；看到 URL 請求，會建議可能是 SSRF（伺服器端請求偽造）。
但對資深工程師來說，這僅僅是一個線索（Lead），而非發現（Finding）。要將其定義為漏洞，必須回答以下關鍵的實務問題：
可達性（Reachability）：攻擊者控制的輸入真的能傳遞到那個危險函數嗎？中間是否有過濾機制？ 權限邊界（Trust Boundary）：觸發此路徑是否需要高權限？它是否跨越了身份驗證或授權的邊界？ 環境配置（Configuration）：生產環境的配置是否真的開啟了該功能？ 實際影響（Impact）：觸發後能做到什麼？是僅僅讓程式崩潰（DoS），還是能執行任意指令（RCE）？
如果缺乏這些驗證，AI 產出的報告就只是「看起來很像漏洞」，這會給企業帶來巨大的 Triage（分選/審核）壓力，導致安全團隊在大量低品質的雜訊中浪費時間，而非處理真正的風險。
為什麼經驗與底層知識不可替代
許多人認為 AI 讓學習底層技術變得不再必要，但事實恰恰相反。頂尖的安全研究員之所以昂貴，是因為他們理解系統運作的本質，而非擅長操作工具。
真正的漏洞挖掘往往來自於對細節的深度掌握，例如記憶體配置（Memory Allocation）的特性、框架的解析邏輯、或是身份提供者（IdP）的認證流程。當 AI 給出的路徑行不通時，只有具備底層知識的人才能根據錯誤訊息進行調整，重新建構心理模型（Mental Model）來繞過防禦。
過度依賴 AI 會導致技術退化。如果習慣於讓 AI 解釋每一行程式碼或生成每個腳本，工程師會失去對模式識別的直覺，這就像長期使用計算機而忘記如何心算，最終在面對複雜、非標準的系統問題時會顯得束手無策。
實務建議：如何正確將 AI 納入工作流
對於 Junior 工程師，建議將 AI 定位為「加速器」而非「權威」。
首先，區分線索與發現。將 AI 的輸出視為待調查的線索。在提交報告前，必須通過一套驗證清單：觀察到了什麼具體行為？需要什麼輸入？跨越了哪個安全邊界？如何穩定地重現？實際影響是什麼？
其次，避免誇大影響。不要因為 AI 給了高分（如 CVSS 9.8）就直接採信。一個僅限管理員權限才能觸發的 Bug，與一個未經認證即可觸發的 Bug，其風險等級完全不同。
最後，利用 AI 進行學習而非替代。當 AI 建議某處有漏洞時，不要直接複製結果，而要問它「為什麼這裡會有問題？」，然後嘗試手動驗證這個理論。
總結來說，AI 提高了發現漏洞的數量，但並沒有降低證明漏洞的標準。在安全領域，「證明它（Prove it）」永遠是唯一的真理。未來的競爭力將屬於那些能利用自動化工具快速篩選，並用深厚的技術判斷力完成最後驗證的人。
來源：thehackernews.com (原作者：Stephen Sims, SANS Fellow)
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。