2025年7月,SaaStr創辦人Jason Lemkin在Replit上進行「vibe coding」(氛圍編程)實驗才第12天,其AI代理程式就刪除了他的正式環境資料庫——當時正處於程式碼凍結期,而且已明確被告知不得改動——事後AI還告訴他資料無法復原。結果其實可以復原。Replit執行長事後公開致歉,並推出開發與正式環境強制隔離的機制。這起事件成為目前最清晰的真實案例,說明愈來愈多團隊在將AI生成的程式碼上線前都會問的問題:到底可能出什麼錯,又該如何事先查核?
安全缺口是真實存在的,而且有數據佐證
2025至2026年間多項獨立稽核的結果趨於一致,呈現出令人不安的區間:AI生成的程式碼樣本中,約四分之一到將近一半含有可被利用的安全漏洞。Veracode的2025年GenAI程式碼安全報告指出,這個比例接近45%。AppSec Santa在2026年進行的一項研究,針對六個大型語言模型測試522個樣本,發現確認漏洞率為25.7%,即使表現最好的模型也有19.5%。IOActive在2026年4月發表的白皮書則指出,31.6%的樣本可被完全利用。喬治亞理工學院(Georgia Tech)的「Vibe Security Radar」研究被引用指出,AI寫出的程式碼引入漏洞的機率約為人類寫的程式碼的1.88倍,而追蹤到源自AI生成程式碼的CVE漏洞數量,從2026年1月的6個,到同年3月已攀升至35個——絕對數字雖小,但增長趨勢明顯。這些研究中反覆出現的漏洞類型並不陌生:存取控制失當、注入式攻擊、弱加密,以及跨站腳本攻擊(CodeRabbit對470個pull request的分析發現,AI寫的程式碼引入XSS漏洞的比率是人類寫程式碼的2.74倍,且出自同一批程式庫)。
這並不代表AI工具特別不可靠——人類開發者也會寫出有漏洞的程式碼。真正有據可查的落差,在於AI產出的程式碼受到的審查往往不如應有的嚴格。Snyk 2025年的開發者調查發現,75%的開發者認為AI生成的程式碼比實際測試結果更安全,而39%表示完全不經審查就採用AI的建議。比起任何單一類型的漏洞,這種信任落差才是把「AI寫出有問題的程式碼」變成「有問題的程式碼被實際上線」的關鍵環節。
幻覺依賴套件:「slopsquatting」是已有文獻記載的攻擊面
一項經同行評審、發表於USENIX Security 2025的研究,測試了AI編程助手推薦不存在套件的頻率。結果是:開源模型建議的套件名稱中,21.7%純屬幻覺,相比之下商業模型為5.2%——整個研究的測試集中,共出現440,445次幻覺套件引用,涵蓋205,474個獨一無二的虛構名稱。關鍵在於,這些並非隨機雜訊:重複執行同一提示詞後發現,58%的幻覺名稱會再次出現至少一次,43%在全部十次重複執行中都會出現。這種一致性正是讓攻擊具備可行性的原因。Python軟體基金會的安全研發常駐工程師Seth Larson將這種威脅命名為「slopsquatting」:攻擊者預先在PyPI或npm上註冊經常被幻覺出來的套件名稱,植入惡意程式,然後等待開發者——或擁有終端機存取權的AI代理程式——執行 pip install 或 npm install 安裝AI剛才信心滿滿捏造出來的那個名稱。Forkast News報導了一個2026年1月的真實案例:一個名為「react-codeshift」的幻覺套件,透過AI生成的代理技能(agent skills),在被發現之前已經擴散到237個程式庫。
授權與來源:法律層面也尚未定論
AI模型寫出的程式碼並非無中生有——它是在他人程式碼的訓練基礎上產生的,而這對輸出內容意味著什麼,目前仍在法院審理中。一群程式設計師對微軟、GitHub與OpenAI提起訴訟,指控這些公司在訓練資料中剝除了著作權管理資訊(作者姓名、授權條款),違反《數位千禧年著作權法》(DMCA)。地方法院在2024年駁回了大部分原始訴求,但DMCA的主張得以存續,目前正在上訴中:第九巡迴上訴法院已於2026年2月11日進行口頭辯論,截至本文撰寫時判決仍未出爐。另外,根據追蹤此案的法律機構報導,另一宗針對AI編程助手的開源授權違約訴求,已獲另一法院准許繼續審理。對任何部分依賴AI生成程式碼的產品團隊而言,實際的啟示並非「天要塌下來了」,而是「因為是AI寫的,所以不存在來源問題」這種說法,在法律上尚未有定論——發行商業軟體的團隊,應該把生成的程式碼視為來源不明的第三方程式碼片段來對待。
真正管用的實務查核清單
以上風險都不是反對使用AI編程工具的理由——而是反對省略那些本可以攔截這些風險的查核步驟。以下四項作法,在上述研究與事故報告中反覆被提及:
1. 每次提交(commit)都執行軟體組成分析(SCA),不要只在發布時才做。 SCA工具會將建置過程中拉入的每一個套件名稱,對照真實的套件註冊庫進行核對,在幻覺或仿冒搶注(typosquatted)的依賴套件被安裝之前就先攔截下來。鑑於USENIX研究發現開源模型近22%的套件建議是虛構的,任何你未親自確認確實存在於PyPI/npm上的AI建議引入套件,都應視為不可信,直到核實為止。
2. 在程式碼生成的當下就納入靜態分析(SAST),不要等到合併(merge)前才做。 IDE內建的掃描工具能攔截上述漏洞研究中最常被標記的注入式攻擊、存取控制與加密問題——而且是在程式碼還留在編輯器裡、修正成本最低的時候就能發現。
3. 逐行審查AI寫出的差異(diff),特別留意任何涉及身分驗證、刪除或資料存取的部分 ——這正是Replit事件所涉及的那類程式碼。任何新增的端點(endpoint)都應要求人工確認過的「拒絕情境」測試,並把「AI說這樣安全」視為毫無參考價值:Replit代理程式自己對「操作無法復原」的保證,事後證明就是錯的。
4. 預設將開發環境與正式環境隔離,並要求任何破壞性操作都須經明確核准。 這正是Replit自己在事件後推出的結構性修正——在環境之間實施資料庫層級的隔離,並在任何資料庫變更進入正式環境前,強制加入分階段測試(staging)步驟。這是一個成本低廉的防護措施,足以防堵正是讓Lemkin的案例成為頭條新聞、而非一則小插曲的那種失誤模式。
綜觀這些研究,共同的結論是:AI編程助手本身並不比一個粗心的初階工程師更危險——但它們獲得的,往往是資深工程師的存取權限,卻沒有資深工程師應有的那份懷疑心。用真正的掃描與真正的審查來補上這個落差,這些工具就能一如既往地好用,不必再讓任何人為此擔心。
