嗨，大家好，我是絳燁。作為一名AI領域的探索者，我一直致力于為大家帶來最新、最酷的AI玩法和資訊。

2025 年，AI 世界風起云涌，“vibe coding” 成了一個熱詞。 有人說它代表未來，也有人唱衰，認為“Spec coding”（又繞回來了）才是正道。

各種觀點交織，讓人眼花繚亂。

說白了，這些爭論很多時候不過是制造焦慮，吸引你為“未來”買課下單。

但拋開這些喧囂，從一個技術小白的角度出發，我們今天就來聊聊：

• “vibe coding” 到底是什么？
• 它真的能做出成熟的商業產品嗎？
• 普通人如何利用它，才能真正發揮價值？
  讓我們一起補齊信息差，你會發現，這玩意兒并沒有那么難。

很多技術小白可能不太懂代碼，只聽說各個產品能夠一句話生成應用，于是非常感興趣，要么加入各個社區，要么報班學習，不亦樂乎；

甚至一些老板、投資人，都會認為這類產品很“牛”、很有“價值”，自己體驗一下就開始采購/在自己的企業內推廣、試行....

從“Spec Coding”到“Vibe Coding”

在深入探討之前，我們先搞清楚兩個概念：

Spec Coding（規范編程）：這是傳統的軟件開發模式。

我們先寫一份詳盡的需求文檔（Spec），涵蓋每一個功能、接口、數據流和用戶交互細節。開發者嚴格按照這份“藍圖”來一行行敲代碼。這種方式嚴謹、可控，但過程漫長且僵化，往往需要耗費大量時間來溝通和修改文檔。

Vibe Coding（氛圍編程）：這是一種全新的協作模式。

你不再需要編寫厚重的文檔，而是通過自然語言、圖片、甚至只是一個模糊的“感覺”（Vibe），告訴 AI 你的想法。AI 快速生成一個原型，你再基于這個原型進行迭代。這個過程高效、靈活，但不確定性非常高（主要修改環節，費時費力，對于大型項目來說是夢魘），對 AI 的理解和你的提示詞質量有極高的要求。

簡單來說，Vibe Coding 是一種從模糊到清晰的“涌現式”開發，而 Spec Coding 則是從清晰到執行的“規劃式”開發。

“Vibe Coding” 的真實能力邊界

針對vibe coding 目前能做什么？能做到什么地步？哪些人非常適用？距離商業落地應該怎么做（解決方案等等）等一些的問題，我們給大家整理了一些 從業者/深度開發者的角度和觀點。

首先，我們得清楚一點：AI 生成的代碼，大多數只能算是 MVP（最小可行產品）。它們擅長快速實現基礎功能，但往往會忽略很多關鍵細節，比如安全驗證。這可能導致嚴重的數據泄露和潛在漏洞。

目前主流的 vibe coding 工具，無論是強大的大模型，還是各類 IDE 和 Agent CLI，它們的能力表現如何？

1. 前端開發：擅長快速生成

當前的 vibe / ai coding，不論是大多數國內外強大的大模型也好，或者是最近層出不窮的 ide、agent cli 也罷，這類工具對前端框架（如 Vue、React）以及 JavaScript、TypeScript 的支持最友好，大概能完成 80% 以上的任務。

（扣子空間）中秋低糖月餅禮盒宣發頁 https://space.coze.cn/s/fs845zpuy0g/

但是我們絕大多數的情況下會發現，AI 生成的頁面有一個非常明顯的“AI 風格”：

• 偏愛紫色系。即使你明確要求使用某些特點的主題色/xxx風格/蘋果宣傳樣式等，它也可能傾向于生成紫色調的頁面。

• 鐘愛標準圖標。生成的頁面會大量使用常見或標準的圖標，讓你一眼就能看出是 AI 作品。如下紅色標注的部分。

基本上前端生成的頁面完成之后，后面各種功能的對接才是重頭戲，這個時候，AI就開始作妖了。

2. 后端開發：基于框架完成業務開發

對于后端開發，我們常規的習慣是 基于 “架構師”——專業工程師 去設計和開發好的框架，在幾個框架的基礎上，使用 Ai coding 工具幫我們快速完成一些業務代碼和接口文檔的生成，從而實現快速迭代和新增功能。

目前大部分模型對 Python 的效果最好，能夠輕松完成 80% 左右的簡單工具、函數或服務。而對于 Go、Java、C++ 等語言，由于訓練數據相對較少，AI 輔助開發的成功率在 60-70% 左右，主要用于輔助完成簡單的開發任務.

這些能力的強弱會依賴于模型的訓練數據平衡和訓練策略不同導致模型的強弱導致的，在 CLI 、AI IDE 等出來前，很多的插件都會宣傳到 20+ 種語言都能完成支持和輔助代碼編寫，但真實可用性只有真的體驗過的才知道。

值得一提的是，當項目變得復雜時，AI 的輔助能力就會顯得乏力。一個完整的函數往往涉及多個文件，而目前大多數 AI 工具的上下文感知能力還不夠，無法提供全面的幫助，不同的 ide 、CLI 之間的上下文管理的策略和效果是有差異的，這也是為什么我們有時會覺得某個 ide 或者 cli 很強的原因。

對于 Rust、Swift 這類新興語言，由于其訓練數據更少，AI 的生成效果通常更差，甚至可能無法正確理解其獨特的內存管理和并發模型。

Vibe Coding 的落地邊界

那么，vibe coding 能做些什么，不能做些什么？

? 業務代碼： 對于重復、簡單的業務代碼，AI 可以按照既定規則和框架快速實現，效率提升 90% 以上。

? 框架設計： AI 設計的架構往往過于理想化（Model預設，沒有考慮實際情況），容易導致后續開發和運維困難，甚至存在性能不足和安全隱患。在沒有人工干預的情況下，AI 獨自完成復雜架構設計的成功率不足 30%，失敗率偏高。

? 商業化落地： 商業化的產品，需要考慮支付系統、登錄系統等復雜模塊，以及整一個系統的安全架構，這些是 vibe coding 目前無法獨立完成的，人為去進行引導也同樣會出現無法滿足或存在設計缺陷的情況.

哪些人最適合“Vibe Coding”？

哪些人非常適用：

• 產品經理 / 設計師： 他們可以快速將想法變成 MVP，直觀地展示和分享設計原型，而不再需要只靠口述或簡單的原型圖。
• 技術小白： 即使沒有編程基礎，也能快速開發出簡單的小工具（如 HTML 網頁或 Python 小腳本），將自己的想法快速變為可用的東西。
• 程序員： 借助 AI IDE 或 CLI，程序員可以快速適應新的語言，進行跨語言開發，并提升日常業務代碼的編寫效率。

Vibe Coding 落地最后一公里：如何從 MVP 走向商業化？

正如弗蘭克·赫伯特在《沙丘》中所說：“能力的基礎是存在的現實，而非期待的幻象。”

vibe coding 給你的是一個想法的“現實”投影，但要讓它成為一個可盈利、可維護的“產品”，你需要補齊以下幾步：

第一步：規范化需求文檔

把 AI 生成的 MVP 視為一個視覺化的需求文檔。它明確了“想要什么”，但沒有回答“如何實現”。你需要將它轉化為一份初步的需求規范，明確功能、數據流和用戶旅程。

第二步：技術選型與架構設計

AI 的代碼更像是一份“草稿”，它的架構往往是不嚴謹的。你甚至不知道什么時候會報錯，各種奇奇怪怪的bug。

你需要聘請一位有經驗的開發者或顧問，來對 MVP 進行評估，選擇合適的技術框架，設計可擴展、高可用的架構。這一步至關重要，決定了產品的上限。

好的AI產品，AI只占很少的一部分，其他部分就是工程化了。

第三步：安全與合規審計

AI 自動生成的代碼可能存在安全漏洞，例如缺乏輸入驗證、數據泄露風險等。在產品上線前，必須由專業的開發者進行代碼安全審計，并確保符合相關法規要求，如數據隱私保護法（GDPR）。

第四步：業務邏輯與核心代碼重構

AI 擅長寫通用代碼，但對于你的核心業務邏輯，比如支付系統、用戶權限管理，它無法理解。這部分代碼必須由人工重構，確保其魯棒性、可維護性和高效率。

第五步：部署、運維與監控

一個商業產品需要可靠的服務器部署、自動化運維和實時監控。這些是 AI 尚無法獨立完成的（雖然說vercel可以，但是也有很多用戶被vercel無端扣費，基本出海AI產品需要在cloudflare部署或者自建服務器部署保證穩定性，確保服務質量和用戶數據備份。

你需要建立一個專業的運維團隊或使用云服務，來保證產品的穩定運行。

寫在最后

Vibe coding 的核心價值，在于把你的想法具象化并進行分享。它讓你能將一句“我有一個 idea”，快速變成一個“這是我的初步效果”。

然而，要將這個“效果”變成一個真正可以商業化落地的產品，還有很長的路要走。一個團隊，不可能全是viber（vibe → viber）。你可以用 AI 快速生成一個 MVP，但要讓它真正可用，你仍然需要專業的程序員。

AI、Agent，是放大器，把所有人的亮點和能力去放大，你vibe的創意被放大，但是無法讓一個0 coding 能力的人coding能力放大到100。

正如科幻小說家弗蘭克·赫伯特在《沙丘》中所說：“能力的基礎是存在的現實，而非期待的幻象。”

AI 就像一面棱鏡，或一個放大器。它能將我們靈光一閃的 vibe 延展成星河，把我們獨特的頻率傳播到更遠的地方，但它不會憑空創造不存在的東西。

劉慈欣在《三體》中那句冰冷的警告： “文明的力量，不在于其工具多么先進，而在于使用工具的人。”

它就像《哈利·波特》中的厄里斯魔鏡，照見的不是“你將會是什么”，而是“你原本已經是什么”。AI 放大我們的光芒，但光，必須首先來自于我們自己。

AI 是這個時代最鋒利的工具，但它不創造靈魂，不賦予初心——你的亮點，你的能力，你的創意，才是它能點燃的火種。

下一篇我們將從0到1構建一個小小的MVP開始，同時也會交叉使用當前主流的AI編程工具，敬請期待。

你對 vibe coding 的看法是什么？

本文本文轉載自???AIGC新知???，作者：絳燁