- Vibe 編碼讓任何人都能透過與人工智慧對話來構建功能齊全的應用程式，但 48% 的人工智慧生成的程式碼都存在安全漏洞。
- 教我奶奶開發一個花園追蹤應用程式的經歷，恰恰展現了 Vibe 編碼的優勢和劣勢。
- 2025 TEA 應用程式的安全漏洞暴露了在缺乏安全審查的情況下快速開發應用程式，這些應用程式雖然功能強大，卻隱藏著諸多漏洞。
- 你可以快速構建原型，但要讓它們達到生產就緒狀態則需要專業知識。
現在，我建立了一個框架，幫助你理解“Vibe 編碼”的實際效果與它所承諾的有何不同，這樣你就能透過營銷噱頭，真正地使用這款產品。
首先，什麼是“Vibe編碼”？
“Vibe 編碼”是指用簡單的英語描述你的需求，然後讓AI為你編寫程式碼。
特斯拉前AI總監、OpenAI聯合創始人安德烈·卡帕西（Andrej Karpathy）於2025年2月創造了“vibe coding”這個術語。他在推特上寫道：“有一種我稱之為‘Vibe 編碼’的新型編碼方式，在這種方式中，你完全沉浸於感覺之中，擁抱指數級增長，甚至忘記程式碼的存在。”
這篇文章迅速獲得了超過 500 萬的瀏覽量，捕捉到了一種已經在科技界迅速傳播的開發方法。
你無需學習程式語言，也無需費力鑽研語法，只需告訴人工智慧你想構建什麼。人工智慧會生成程式碼。你不再是程式設計師，而是產品經理，專注於應用程式應該做什麼，而不是如何實現它。
為什麼Vibe Coding現在如此重要？
據麥肯錫公司稱，87% 的公司面臨人才短缺，或預計在未來幾年內將面臨人才短缺。
Bolt.new、Lovable、Replit Agent 和 Cursor 等人工智慧編碼工具承諾透過提高現有開發人員的效率，並允許非開發人員快速測試他們的想法，來解決這個問題。
資料也印證了這種說法：
- 2025 年 3 月，Y Combinator 公佈，在其 2025 年冬季孵化專案中，25% 的公司 95% 的程式碼庫都是由人工智慧生成的。
- 2025 年 4 月，微軟 CEO 薩蒂亞·納德拉透露，其程式碼庫中有 20% 到 30% 是由人工智慧編寫的。
- YC 創業公司當前孵化的創業者中，有四分之一的程式碼庫幾乎完全由人工智慧生成。
- 谷歌 CEO 桑達爾·皮查伊也公佈了類似的資料，稱谷歌超過 25% 的程式碼是由人工智慧生成的。
我們已經從基本的自動補全功能發展到只需極少的人工干預即可編寫完整的應用程式。
但是，正是這些讓 Vibe Coding 易於使用的特性，例如自然語言輸入、自動程式碼生成和自動複雜度處理，在應用程式需要擴充套件到第一個版本之後時，卻會帶來嚴重的問題。
Vibe Coding 究竟能構建什麼？
何時才能真正使用 Vibe 編碼進行開發取決於三件事：
- 你的應用需要有多複雜
- 你是否能夠發現糟糕的程式碼和安全漏洞
- 你是否知道何時停止新增功能
如果你的應用需求很簡單，並且你能識別技術差距並抵制不必要的功能新增，那麼Vibe編碼可以幫助你快速交付功能性成果。
然而，隨著複雜性的增加，或者當你需要構建生產級應用時，專業的程式碼審查和架構規劃就變得必不可少了。
第一小時發生了什麼？簡單的指令奏效了
目前至少有十幾個 AI Vibe 編碼平臺，例如 Bolt、Lovable、OpenAI Code、Claude Code、Google Opal 等等。
我們一開始使用的是 VS Code 中的 OpenAI Codex 擴充套件，因為我已經訂閱了，但我建議從 Bolt.new、Lovable 或 Vercel 開始，以獲得更直觀的Vibe編碼體驗。
我們的第一個任務是：“Build a garden tracking app where I can record what I planted, when I planted it, and how much I harvested. Include a way to see which plants performed best each season.”
這個提示之所以有效，是因為它包含了三個關鍵要素：
- 清晰的資料結構（植物名稱、種植日期、收穫量、季節）
- 明確的輸出（按季節進行效能比較）
- 具體的用例背景（個人花園跟蹤）
幾分鐘之內，Codex 就生成了一個完整的應用程式。它包含一個 SQLite 資料庫，其中包含植物、種植和收穫的表；用於 CRUD 操作的 REST API 端點；一個包含資料表和輸入表單的 Python 前端；以及基本的 CSS 樣式。
它甚至還預設包含一些演示資料。
這個網頁應用看起來不錯。這就是“氛圍編碼”的強大之處，也是它最大的隱患。但在深入探討之前，讓我先解釋一下 Codex 背後的設計思路。我試用了這個應用，弄清楚了我們現有的功能以及還需要哪些功能。
介面背後的故事
生成的程式碼為單使用者應用做出了架構決策。資料庫模式可以輕鬆處理新條目。API 遵循 RESTful 規範。前端元件在邏輯上是分離的。
然而，我注意到它預設情況下並未考慮關鍵的安全因素。它沒有輸入驗證、沒有身份驗證層、沒有速率限制、沒有考慮 SQL 注入漏洞，也沒有加密。
人工智慧代理的架構假定使用者是受信任的，且處於受控環境中。
考慮到這只是我奶奶的專案，沒有其他人參與，這些疏漏的風險尚可控制。但是，對於任何考慮使用 Vibe Code 構建多使用者 Web 應用程式的人來說，這些都是不容忽視的關鍵安全風險。
我經常在 Reddit 或 PostStatus 上看到相關的討論：開發者之所以能夠成功地迭代 AI 生成的程式碼，是因為他們發現了這些漏洞並實現了適當的安全層。非技術使用者看到一個可以執行的應用程式，就想當然地認為它已經可以投入生產環境了。
第二個小時發生了什麼？功能蔓延變得顯而易見
應用程式執行正常，這一突破性的時刻幫助你建立了信心。我們開始思考如何改進。這時，Vibe Code 的侷限性就顯露出來了。
我們嘗試了一項功能請求：“Add the ability to upload photos of each plant so I can see what they looked like at different growth stages.”
這個看似簡單的請求引發了一系列架構上的複雜性。
需要修改的資料庫模式和應用模組：
- 新增照片表，包含以下列：id、plant_id（外部索引鍵）、photo_url、upload_date、growth_stage
- 植物與照片之間的關係定義（一對多）
- 現有資料的遷移策略
後端需要修改：
- 支援多部分表單處理的檔案上傳端點
- 檔案儲存方案（本地檔案系統 vs. 雲端儲存）
- 用於照片 CRUD 操作的新 API 端點
- 更新現有植物端點以包含照片資料
前端需要修改：
- 支援拖放的檔案輸入元件
- 影像預覽功能
- 每個植物的照片庫顯示
- 更新現有植物卡片以顯示縮圖
- 上傳進度的載入狀態
OpenAI Codex 嘗試同時實現所有這些功能。最新的 GPT5-Codex-High 模型在收到請求後約 5 分鐘內就完成了這項工作。
問題在於它生成了漏洞百出且不安全的程式碼。以下是出現的問題：
- 原始植物表結構發生了變化
- 引用舊架構的前端元件停止工作
- 新的照片元件與現有 UI 之間出現了 CSS 衝突（如螢幕截圖所示）
此外，還存在過度設計的問題：Codex 生成了一個複雜的系統，其中包含不必要的影像處理和每張照片的資料採集等。
每次修復嘗試都會引入新的問題。更新資料庫架構，導致 API 崩潰；修復 API，導致前端崩潰；解決前端問題，又會發現新的後端 bug。原本只需 200 行程式碼就能完美執行的程式碼庫，現在卻擴充套件到了 1500 行，並且存在相互關聯的依賴關係。
不可擴充套件架構的陷阱
該應用程式的架構僅針對我們最初一小時內提出的需求進行了最佳化。使用 Vibe 編碼時，你必須非常具體，而這對於非開發人員來說正是難點所在。
如果人工智慧實現了可擴充套件架構，你根本無法理解它的含義。
如果你已經開發了一個簡單的應用程式，之後需要對其進行擴充套件，那麼採用非可擴充套件架構就意味著你需要為人工智慧從頭開始重寫程式碼。
最初一小時的架構假設：
- 單表設計（適用於簡單資料）
- 直接 API 查詢資料庫（讀取密集型操作速度快）
- 內聯元件定義（適用於小型使用者介面）
- 業務邏輯和資料訪問沒有分離（適用於簡單的 CRUD 操作）
這些假設為何變成了限制：
- 單表設計無法對照片進行正確的關聯資料建模
- 當模式發生變化時，直接查詢需要完全重寫
- 內聯元件意味著更改會波及整個程式碼庫
- 沒有業務邏輯層意味著每個功能都直接訪問資料庫
我們已經錯過了最佳時機。程式碼量太大，無法放棄。每次嘗試修復都會消耗更多代幣，試圖挽救一個無法支援新需求的架構。
第三小時發生了什麼？程式碼耗盡，勉強能用的程式碼出現了
照片上傳功能實現後，我們嘗試進行其他改進。
- “Add categories for plant types (vegetables, herbs, flowers)”
- “Show planting recommendations based on season”
- “Let me mark plants as favorites”
每個請求都遵循相同的模式：Codex 試圖對一些看似簡單的請求進行徹底的實現，引入了破壞性更改，建立了過度設計的解決方案，並消耗了數千個令牌來嘗試修復由此產生的錯誤。
這款應用執行良好，對結果也很滿意。
不過，作為一名開發者，我清楚地意識到，就程式碼而言，我們已經接近尾聲了。再新增幾個功能，這款應用就會變得一團糟。
為什麼這是一個如此普遍的問題？
編碼代理本質上是大型語言模型，它們被“提示”輸出程式碼。
因此，它們也存在所有常規大型語言模型都會遇到的問題，包括：
- 不清楚預期結果是什麼
- 隨意呼叫函式（產生幻覺）
- 為簡單的目標編寫複雜的程式碼
此外，隨著聊天記錄的增長，編碼代理會達到其上下文視窗的限制。
- 最初的架構決策及其原理
- 後續修改及其相互依賴關係
- 當前存在的錯誤及其根本原因
- 新功能的預期功能
每個新的提示都被孤立地解讀，而沒有完全理解架構歷史。人工智慧提出的解決方案對於單個功能來說似乎合理，但當與現有程式碼整合時，就會產生系統性衝突。
這篇 Reddit 指南強調：“When the chat gets very big, just open a new one. The AI context window is limited. If the chat is very big, it will forget everything earlier, forget any patterns and design, and start producing bad outputs.”
但開啟新的聊天意味著丟失所有關於現有內容的上下文資訊。提供這些上下文資訊需要消耗令牌。即使是“總結”上下文，在程式碼層面上，我們仍然會遺漏一些重要的細節。
我們曾在較小規模下遇到過TEA應用的問題
TEA 應用在生產規模上展現了這種故障模式。該應用於 2023 年作為女性安全平臺推出，使用者數量迅速增長至 160 萬。
隨後，在 2025 年 7 月，該應用遭遇了災難性的故障：
- 安全漏洞：安全研究人員發現了一個未受保護的 Firebase 儲存桶，其中包含 72,000 張使用者圖片，包括 13,000 張驗證自拍和政府頒發的身份證件。另一個資料庫洩露了 110 萬條私人訊息。
- 技術缺陷：API 金鑰硬編碼在原始碼中，Firebase 儲存桶無需身份驗證即可公開訪問，沒有執行時保護措施，也沒有安全審查層。專家將這些漏洞歸咎於“快節奏”的編碼實踐，在這種實踐中，功能開發速度凌駕於安全架構之上。
- 結果：一位匿名 4chan 使用者發現並分享了下載工具。48 小時內就出現了集體訴訟。該平臺被迫關閉。平均每次資料洩露造成的損失高達 488 萬美元。
TEA 的失敗模式與我們之前在如此小的規模上遇到的情況如出一轍，這讓我不禁思考，為什麼人們不去驗證 AI 生成的程式碼。
我們最初的實現執行良好；然而，功能的新增使架構變得複雜，新功能的安全考量被忽視，系統漏洞在不知不覺中暴露出來，容易被利用。
如何編寫出流暢的程式碼，避免重蹈覆轍
如果你不是開發人員，完全避免這些問題是不可能的。但是，有一些方法可以最大限度地減少問題。
1. 堅持極簡主義
在編寫第一個提示之前，定義絕對最小的功能集，但始終要抵制在初始開發階段新增功能的誘惑。
有效的範圍界定框架：
- 列出所有所需功能
- 確定 3-5 個能夠驗證核心假設的功能
- 在第一版中僅構建這些功能
- 釋出、驗證並迭代
不要給出類似“Build me this whole feature”這樣的指令。人工智慧會胡亂猜測，生成糟糕的程式碼。將任何功能分解為至少 3-5 個順序請求。
如果您無法確定最小功能集，請使用大多數人工智慧編碼工具中提供的“Plan mode”或“Chat mode”。
這使您能夠用自然語言告訴智慧體您的需求，並讓 AI 計算出如何將應用程式拆分成各個功能或檔案。
2. 每個可用功能完成後提交到Git
對於非開發人員來說，版本控制聽起來可能很複雜，但它是必不可少的。Git 是一種版本控制工具，它會在新增功能破壞現有功能時建立還原點。
Vibe 編碼的 Git 工作流程：
- 在第一個提示之前初始化儲存庫
- 在初始可用版本完成後提交
- 為每個新增功能建立一個新分支
- 在功能開發期間頻繁提交
- 在合併到主分支之前進行全面測試
如果您不熟悉 Git 命令，可以告訴您選擇的編碼智慧體為您執行這些操作。
3. 在初始提示中設計可擴充套件性
您的第一個提示定義了程式碼庫。簡單的提示只會提供一個可用的應用程式，直到您開始要求新增新功能。
相反，從一開始就要求構建一個可擴充套件的架構。
- 無效的初始提示：“Build a garden tracking app where I can record what I planted and harvested.”
- 有效的初始提示：“Build a garden tracking app with an extensible database schema that can accommodate future features. Use a modular architecture where frontend components, API endpoints, and database access are separated. Include clear documentation of schema and API structure for future modifications.”
雖然這會增加初始階段的令牌使用量，但當您開始新增新功能時，AI 無需浪費令牌來重構舊程式碼以適應請求。
4. 基於架構穩定性選擇工具
- Bolt.new、Replit 代理和 Lovable：非常適合單會話原型和輕鬆部署。不適合多會話功能新增。架構會隨著每次修改而變得越來越脆弱。
- Claude/OpenAI/Gemini 編碼代理：有時對複雜的編碼很有用，但與我們之前看到的視覺化 Web 應用相比，它們可能感覺更復雜。
- Liftoff：非常適合作為 WordPress 的基礎架構，擁有成熟的擴充套件模式。WordPress 架構的設計初衷就是為了方便修改和外掛新增。它從一個經過實戰檢驗的可擴充套件基礎架構入手，解決了架構不可擴充套件的問題。
5. 從一開始就落實安全措施
與可擴充套件性類似，您需要在第一個提示中就整合安全措施。因此，除了要求構建可擴充套件的模組化架構之外，您還需要在初始提示中新增安全優先的元件。
以下是我在第一個提示中新增安全措施的示例：“Build a garden tracking app with bcrypt password hashing, input validation on all fields, parameterized SQL queries to prevent injection attacks, rate limiting on all API endpoints, and secrets stored in environment variables never exposed to frontend code.”
如果您正在構建面向客戶端的應用程式，請記住以下幾點：
- 永遠不要信任客戶端資料——在伺服器端進行驗證和清理
- 將金鑰儲存在環境變數中
- 驗證每個操作的許可權
- 使用通用錯誤訊息——詳細日誌僅供開發人員使用
- 實施所有權檢查以防止未經授權的資料訪問
- 使用速率限制保護 API
6. 知道何時應該重新開始，何時應該繼續
識別繼續開發會浪費代幣的跡象。
以下情況需要重新開始：
- 代幣消耗超過 30 萬且功能未正常使用
- 每次修復 bug 都會引入兩個新 bug
- 架構修改破壞了多個現有功能
- 聊天記錄超過 30 次交易
- 無法解釋當前程式碼庫架構
以下情況可以繼續：
- 新功能與現有程式碼無縫整合
- bug 修復解決問題且無副作用
- 代幣消耗保持在預算範圍內
- 架構仍然清晰易懂
當 AI 出錯並走錯方向時，返回、更改提示並重新傳送遠比繼續編寫這段糟糕的程式碼要好得多。
7. 使用AI進行安全分析
構建核心功能後，將整個程式碼庫複製到 Gemini 2.5 Pro 進行全面的安全分析。我之所以推薦這種語言模型，是因為它擁有兩百萬個代幣的超大上下文視窗，可以將整個程式碼庫遷移過去。
安全審查提示：“Act as a security expert. Analyze this complete codebase for vulnerabilities. Identify SQL injection risks, XSS vulnerabilities, authentication weaknesses, authorization flaws, credential exposure, and any OWASP Top 10 issues. Provide specific code locations and remediation recommendations.”
這可以以極低的成本實現接近專業安全審查的效果。
雖然它不足以用於生產環境部署，但它可以在原型交付給使用者之前識別出災難性缺陷。
何時Vibe編碼才能真正發揮商業價值？
即使 Vibe 編碼目前還無法建立複雜的應用程式，也不必完全放棄它。以下幾個例子說明了 Vibe 編碼的原型或應用程式在哪些情況下真正具有意義。
- 快速概念驗證：在數小時內構建原型以測試市場興趣。平均驗證成本從 15,000 美元到 100,000 美元以上降至 500 美元以下。使用 Vibe 編碼來回答：“客戶是否足夠需要它？”
- 內部流程自動化：為您的團隊提供工具，您可以控制訪問許可權並接受更高的風險承受能力，因為影響範圍有限。內部工具可以迭代最佳化安全性，而不是從一開始就要求具備安全性。
- 開發前規範：在聘請開發人員之前瞭解需求，以減少代價高昂的溝通不暢。Vibe 編碼的原型可以作為互動式需求文件。
- 用於融資的 MVP：向投資者展示功能，同時保持技術成熟度的透明性。許多初創公司使用基於氛圍設計的最小可行產品 (MVP) 來獲得種子資金，然後再組建專業團隊進行完善的重建。
當專業發展成為不可或缺的一部分
任何處理使用者資料的面向客戶的應用程式都需要專業的安全審查。安全實施不當的成本遠超快速編碼所節省的費用。
以下情況需要專業審查：
- 多使用者身份驗證
- 支付處理
- 個人資訊儲存
- 面向公眾的部署
- 涉及合規性要求的情況（例如 GDPR、CCPA、HIPAA）
微軟 CEO 透露，該公司 30% 的程式碼現在由 AI 生成。谷歌也公佈了類似的資料。兩家公司都維持著完善的安全審查流程、自動化測試和人工監督。
無論程式碼生成方法如何，生產部署都需要類似的安全保障措施。
瞭解 AI 是否會取代開發人員，有助於您設定合理的預期，明確哪些功能可以安全地獨立構建和部署。探索最佳的線上學習資源，學習程式碼，彌合快速編碼原型和生產就緒系統之間的差距。
關於Vibe編碼的常見問題
什麼是 Vibe 編碼？它與傳統程式設計有何不同？
Vibe 編碼是指透過向人工智慧 (AI) 描述需求（使用簡單的英語），由 AI 生成程式碼來構建應用程式的過程。與需要掌握程式語言知識的傳統程式設計不同，Vibe 編碼將重點放在產品管理和意圖上，而不是手動編寫程式碼。
非開發人員可以使用 Vibe 編碼構建可用於生產環境的應用程式嗎？
雖然 Vibe 編碼可以讓非開發人員快速構建功能性應用程式原型，但大多數 AI 生成的程式碼缺乏生產部署所需的安全性和健壯性。儘管如此，Vibe 編碼的原型非常適合概念驗證。
使用 AI 生成的程式碼進行應用程式開發的最大風險是什麼？
最主要的風險包括安全漏洞（例如缺少驗證、身份驗證、速率限制和 SQL 注入防護）、架構不可擴充套件以及功能蔓延導致系統脆弱或崩潰。TEA 應用程式洩露事件就是一個缺乏適當安全審查的快速開發案例，最終導致了災難性的後果。
何時才適合在實際商業專案中使用 Vibe 編碼？
Vibe編碼非常適合快速原型開發、內部工具、開發前期規範（需求收集）以及用於融資的MVP。但是，對於面向客戶的應用程式或處理敏感資料的應用程式，務必投資於專業開發和安全審查。
小結
本次示例專案是維護著一個簡化的花園追蹤器，供個人使用。其中還新增了功能分析（以前導航欄按鈕的位置並不固定），以便檢視花園的生長情況。
這可以作為單使用者應用程式使用。如果您正在構建一個供多使用者使用的平臺，您仍然可以建立 Vibe 編碼的原型、MVP 等，以啟動專案。但是，如果僅僅依賴 Vibe 編碼而不瞭解其工作原理，那就只是在重蹈TEA應用程式的覆轍。
Vibe 編碼使軟體建立更加普及，同時也引入了新的責任。您可以在 30 分鐘內構建應用程式。然而，在向使用者釋出產品之前，您必須瞭解架構限制、安全隱患和令牌消耗模式。
未來屬於那些瞭解原型與量產之間差距的開發者。
評論留言