斯坦福研究：用 AI 寫程式碼不僅漏洞更多，開發者還迷之自信

如果你這陣子寫程式碼也離不開 GitHub Copilot 這種 AI 助手，可能得稍微留個心眼了。

大家通常覺得 AI 寫程式碼最多也就是偶爾邏輯不對、跑不通，改改就好。但斯坦福大學計算機系的一幫研究人員最近做了一項實驗，結果發現事情沒那麼簡單：用 AI 輔助寫程式碼的程式設計師，寫出來的東西往往漏洞更多，而且自己還渾然不知。

這篇題為《使用者會用 AI 助手寫出更不安全的程式碼嗎？》的論文，專門測試了開發者在使用類似 Copilot 的 AI 輔助工具時的真實表現。

漏洞變多了，人反而更自信了

這項研究找了 47 名開發者，讓他們根據幾個具體的提示詞來寫程式碼。一部分人允許使用 AI 助手，另一部分人則全靠自己純手寫。

實驗裡的第一個任務就很典型：要求用 Python 寫兩個函式，用給定的對稱金鑰對字串進行加密和解密。

結果很有意思。沒用 AI 助手的開發者裡，有 79% 的人給出了正確答案。而開了 AI 外掛的那組人，正確率反而掉到了 67%。

更嚴重的是安全性。研究人員發現，有 AI 幫忙的組明顯更容易寫出存在安全隱患的程式碼，在 Welch 不等方差 t 檢驗中呈現出統計學上的顯著差異（p < 0.05）。

具體來說，AI 組非常喜歡使用像「替換密碼」這種極度初級、極不安全的加密方式，而且基本不會對最終返回的值做真實性校驗。在字串加密和 SQL 注入這兩個測試項上，漏洞尤其密集。

最諷刺的是心理層面的反差。論文作者指出，用了 AI 助手的開發者，往往對自己的程式碼質量有一種盲目的自信。比起純手寫的人，他們更堅信自己寫出來的程式碼非常安全。

實驗裡還有一位參與者打趣說，自己巴不得趕快普及 AI 助手，因為「它就像是更好的 Stack Overflow，至少它永遠不會跳出來說你的問題很蠢」。

漏洞之外，版權炸彈還在頭上懸著

除了程式碼本身的質量和安全性問題，這類工具背後的合規風險也在集中爆發。

就在上個月，OpenAI 和微軟剛剛因為 GitHub Copilot 遭到了集體訴訟。訴訟的核心原因大家都清楚：Copilot 是在海量的公開程式碼庫上訓練出來的，抓取了別人的程式碼卻完全不給原作者署名。

這就帶來了一個很現實的法律隱患。開發者在編輯器裡開開心心地採納了 Copilot 吐出來的補全建議，轉頭可能就成了無意侵犯開源版權的侵權者。

正如軟體自由保護協會的 Bradley M. Kuhn 今年早些時候寫道的那樣，Copilot 基本上是把開源協議合規這個爛攤子，直接甩給了終端使用者自己去擦屁股。隨著 Copilot 越來越好用，使用者頭上頂著的法律責任可能不減反增。

為什麼重要

這個研究其實戳破了很多人對 AI 程式設計神話的幻想。我們認為，現在的程式碼補全工具最大的隱患不是「生成完全錯誤的程式碼」，而是「生成看起來非常工整、能跑通，但在底層埋了致命安全雷的程式碼」。更糟糕的是，它還順便麻痺了開發者的警惕心。

如果你是日常寫業務的工程師或者獨立開發者，我們覺得 Copilot 依然可以用，但絕對不能拿它來應付安全敏感模組。比如身份驗證、加解密邏輯、資料庫查詢這些關鍵鏈路，老老實實用成熟的安全庫，比讓大模型給你「即興發揮」要靠譜得多。盲信 AI 的輸出，代價可能是日後被駭客打成篩子。

對於整個軟體工程行業來說，這意味著程式碼審查的標準必須徹底重寫。以往看同事的程式碼，主要抓語法和邏輯；以後團隊可能得專門排查那些「一股 AI 味」的程式碼模式，比如脆弱的預設配置和過時的加密演算法。

看起來，AI 廠商們聰明的點在於把互動做到了極簡，讓生產力暴漲的快感瞬間到位；但隱患在於，它們把安全審查和版權合規的風險完完整整地甩給了下游開發者。如果不給生成的程式碼自動附帶漏洞掃描與合規校驗，這種效率紅利早晚會變成技術債務的無底洞。