我們掃描了1868個AI構建的應用並審計了掃描器

PathToShip最近釋出了一份深度報告，基於對1868個公開GitHub倉庫的掃描，揭示了使用AI編碼工具構建的應用在生產就緒性方面的現狀。這些倉庫均被確認為使用Bolt、Lovable、v0、Cursor、Replit等九種主流AI工具建立，掃描器對每個倉庫執行了80項自動化檢查，涵蓋安全、架構、可擴充套件性等七個維度。

結果顯示，平均得分為68.3，中位數為71，範圍從31到95。僅23%的應用達到80分以上的生產就緒標準。24%的應用至少有一個嚴重級別的發現，15%存在硬編碼金鑰或API金鑰。安全性和生產就緒性是最薄弱的維度，平均得分分別為65和56；而可擴充套件性和成本效率表現較好，分別為80和88。這驗證了報告的核心論點：AI工具生成的程式碼高效但缺乏生產運營所需的健壯性。

報告的亮點之一是對掃描器自身的審計。團隊手動核驗了57個嚴重發現的代表性樣本，發現初始誤報率高達42%。透過針對性修復，例如忽略示例檔案中的佔位符金鑰、識別無害值（如錯誤訊息中的“password”）、放寬對服務角色無許可權策略的判斷，誤報率降至約25%。一個重要的檢測錯誤是v0域名的未更新，導致約85%的v0倉庫被遺漏，修復後工具檢測準確率從76%提升至92%。

儘管有所改進，團隊承認仍有約四分之一的嚴重發現可能為誤報，這是由於靜態分析無法追蹤值的來源。他們選擇不透過猜測規則來掩蓋真正的漏洞，而是等待資料流分析技術的下一輪改進。報告強調，所有修復均驗證了32個手工確認的真實發現未受影響。

各工具的表現顯示，嚴重發現率現在集中在21-31%的區間內，遠低於最初報告的22-53%的範圍。例如Lovable和Windsurf的早期高誤報率已得到糾正。常見的非嚴重問題包括缺少內容安全策略（90%）、無隱私政策（88%）、大檔案（74%）以及無React錯誤邊界（60%）。這些無不表明，AI構建的演示與生產應用之間的差距主要在於常規的工程工作。

PathToShip還公佈了其方法的侷限性：掃描基於靜態模式分析，無法評估執行時行為、部署設定或資料流。此外，掃描的倉庫均為公開專案，可能偏向於業餘作品和演示，而非真正的生產應用。因此，所有統計資料僅代表掃描的樣本，不應外推至所有AI構建的應用。