Vibe Coding 安全清單：給用 AI 寫代碼的團隊十條紀律 · 行業洞察

效率提上來了，紀律還沒跟上

Vibe Coding——用自然語言描述意圖、讓 AI 生成實現——已經不是極客的玩具。在不少團隊裏，它承擔了從腳手架搭建到業務邏輯實現的大部分工作量。

問題在於，安全流程的設計前提還是「代碼由人寫」：人會記得自己引了哪個庫，會對陌生依賴產生警覺，會在複製 Stack Overflow 代碼時猶豫一下。AI 不會。它以極高的置信度輸出看起來完全合理的代碼，包括並不存在的包名、帶着原始許可證的開源片段，以及在訓練數據裏學到的過時寫法。

這不是反對用 AI 寫代碼。恰恰相反：正因為它會長期存在且比重還會上升，配套紀律必須補齊。下面十條按開發流程的五個環節組織，每條都可以直接寫進團隊規範。

紀律 1 · 在提示詞裏寫明約束，而不是事後修補。

同樣是「寫一個文件上傳接口」，加上「使用項目已有的 validation 工具，不引入新依賴，路徑處理需防目錄穿越」，得到的代碼質量差異是數量級的。把團隊的技術棧約束、安全要求、依賴策略沉澱成提示詞模板，比在代碼審查時逐個糾正高效得多。

紀律 2 · 敏感上下文不進公共模型。

生產環境配置、真實密鑰、客户數據、未公開的業務邏輯——這些內容貼進公共聊天機器人的那一刻，就已經離開了你的可控範圍。團隊需要明確的數據分級：哪些代碼域可以用公共 AI 工具，哪些必須用企業內部部署的模型。這條紀律的執行難點不在技術，在於提供足夠好用的合規替代品，否則開發者一定會繞過。

紀律 3 · 把 AI 當作高產的初級工程師，而不是資深專家。

初級工程師的代碼要過 review，AI 生成的代碼同樣要過。區別在於 AI 的產出速度快得多，所以審查機制必須自動化——靠人力逐行讀完 AI 生成的代碼，團隊會先被拖垮。

紀律 4 · 生成即掃描，不要等到提交。

風險發現得越晚，修復成本越高。理想的形態是 IDE 內實時檢測：AI 寫下一段代碼的同時，安全引擎就完成了污點分析、依賴檢查和許可證比對。這也是「安全左移」在 AI 時代的必然延伸——左移到代碼生成的那一刻。

紀律 5 · 建立依賴白名單，AI 只能在白名單內選擇。

AI 引入依賴的判斷依據是訓練數據裏的流行度，不是你們團隊的技術棧規劃、許可證策略或安全基線。讓 AI 在受控的依賴集合內工作，比事後逐個審查它引入的庫現實得多。

紀律 6 · 對幻覺包做主動防禦。

AI 會以完全自信的語氣引用並不存在的包名。攻擊者已經在系統性地註冊這些高頻出現的幻覺名稱——這就是 slopsquatting。防禦有三層：安裝前校驗包是否真實存在且有合理的發佈歷史；使用內部製品倉庫鏡像並配置內部優先解析；對新引入依賴的首次安裝做人工確認。

紀律 7 · 傳遞依賴也要看。

AI 引入的一個包，可能帶進來幾十個傳遞依賴。它們同樣會成為你的攻擊面和許可證義務來源，卻不會出現在任何人的注意力裏。完整的依賴樹解析和持續的漏洞比對，是 AI 時代依賴管理的基本盤。

紀律 8 · 用片段級檢測捕捉開源代碼復現。

AI 可能逐字復現訓練數據中的開源代碼。這些片段不出現在任何依賴清單裏，只讀 manifest 的工具完全看不到——但它們攜帶的許可證義務是真實的。片段級指紋比對是目前唯一能發現這類風險的手段，而在 AI 生成代碼佔比越來越高的今天，這項能力從「錦上添花」變成了必需品。

紀律 9 · 審查重點放在業務邏輯，而非語法。

AI 生成的代碼通常語法正確、風格統一，甚至比人寫的更規範。它容易出錯的地方在於：對業務規則的理解偏差、邊界條件處理不全、權限判斷的位置錯誤、錯誤處理過於寬鬆。人類審查者的注意力應該集中在這些機器不擅長的判斷上，語法和風格交給工具。

紀律 10 · 留下代碼歸屬的痕跡。

哪些代碼由 AI 生成、用的哪個模型、什麼時候、基於什麼提示詞——這些信息在三種場景下會突然變得關鍵：出現安全事件時的溯源、許可證糾紛時的舉證、以及未來可能出現的合規審計要求。成本是提交時多加一個標記，收益是在需要時你有據可查。

十條紀律如果只是文檔，落地率不會高。真正有效的方式是把它們編碼進流程：提示詞模板進 IDE 插件，依賴白名單進製品倉庫配置，掃描進 IDE 與 CI，歸屬標記進提交模板，最後由 CI 門禁做統一的准入判斷——不合格的代碼進不了主幹。

AI 讓代碼的生產速度提升了一個數量級，安全能力必須以同樣的速度跟上。這不是給開發者加負擔，而是讓他們能放心地用好這個工具。

---