什麼是 Vibe Coding?淺白解說
Vibe coding 就係用白話文向 AI 描述你想要嘅嘢,運行佢產生嘅成品,然後根據結果去引導,而唔係睇代碼。你負責判斷應用程式——撳個掣有冇反應、頁面望落啱唔啱——然後要求改到符合你需要為止。呢個詞係 AI 研究員 Andrej Karpathy 喺 2025 年 2 月於 X 發文時創造嘅,佢形容自己順應感覺、唔再理會代碼係點寫。
呢個詞嘅來源
Karpathy 係 OpenAI 嘅創始成員之一,亦曾任 Tesla 嘅 AI 負責人。佢用呢個詞形容自己做細嘅周末項目嘅方式:同 AI 編程工具傾偈,接受佢做嘅改動而唔睇清楚差異,遇到錯誤訊息就貼返去,直到搞得掂為止。佢亦講明,呢種做法最適合用完即棄嘅項目。
呢個詞之所以流行,係因為佢為一種好多人已經在做嘅事情起咗個名。幾個月內,佢就被用嚟形容由興趣項目到初創原型嘅各類開發工作。柯林斯英語詞典更將「vibe coding」選為 2025 年度詞語。而家呢個詞泛指任何由 AI 寫代碼、由人用白話文指揮嘅建造工作。
點解用 AI 建造嘢時要留意
對於唔寫代碼嘅人嚟講,vibe coding 正正係 AI 應用程式建造工具有用嘅原因。創辦人可以喺一個下晝內測試一個構思;小生意老闆可以建造佢哋以前從來唔會為此付錢搵外判公司嘅預約表格或者庫存追蹤器;設計師亦可以將設計稿變成可以點擊嘅原型。
但呢個定義本身已經帶有一個警告。「忘記代碼係存在嘅」喺只係為你自己、而且只係今日用嘅時候冇問題;但如果應用程式儲存客戶資料、處理付款,或者要運作好多年,就冇咁啱。認清呢條界線,係你可以從 vibe coding 學到最有用嘅嘢。
一個日常比喻
想像你裝修廚房,唔係自己畫圖,而係直接同承建商講你想要咩。你話「窗戶下面一條長枱、開放式櫃、雪櫃放近門口」,然後每晚行入去,睇吓做咗啲乜,再講要改邊度。
呢種方式對佈局同外觀好有效,因為你企喺房入面就可以判斷。但對於牆後面嘅嘢就冇咁有效,例如電線、水管、煤氣喉有冇跟足規例。呢啲你用眼望係睇唔到嘅,而問題可能要等到出事先會顯露。一個細心嘅業主仍然會請人驗收。
Vibe coding 都係咁。畫面就係睇得到嘅房間;保安、資料處理同代碼嘅組織方式,就係牆後面嘅線路。
實際上 vibe coding 係點樣做
假設你想要一個簡單工具,追蹤邊啲客戶已經俾咗發票嘅錢。
| 步驟 | 你做咩 | AI 做咩 |
|---|---|---|
| 1. 描述 | 「一個頁面列出我嘅客戶,有發票金額、到期日同已付/未付狀態。我可以新增客戶,並將發票標示為已付。」 | 寫頁面、表格同儲存紀錄嘅邏輯 |
| 2. 試用 | 新增一個客戶,標示為已付,然後重新整理頁面 | 喺預覽中運行應用程式 |
| 3. 反應 | 「重新整理之後,我嘅客戶都唔見咗」 | 解釋紀錄只係暫存喺瀏覽器記憶體入面,並加入資料庫 |
| 4. 優化 | 「將逾期發票排喺最頂,並用紅色顯示」 | 修改列表 |
| 5. 檢查 | 用手機開啟;試吓空白表格 | 按你報告嘅問題修正 |
你成個過程都冇開過任何代碼檔案。但留意第 3 步:應用程式睇落已經完成,但其實仲未儲存任何嘢。Vibe coding 獎勵嗰啲識得以用戶角度去測試,並且可以準確描述所見嘅人。
好處
- 快。 幾分鐘或幾個鐘頭就有一個可以運作嘅第一版,而唔係幾個星期。
- 試錯成本低。 你可以做三個版本,然後留低最好用嗰個。
- 直接掌控。 最明白問題嘅人就係塑造產品嘅人,唔會因為要轉述畀開發者而失真。
- 邊做邊學。 好多人只係睇住 AI 點樣建造,並不斷問點解,就已經學識應用程式點樣組合,例如前端同後端、資料庫、API。
真正嘅風險
以下唔係叫你唔好用 vibe coding 嘅理由,而係「感覺」唔會幫你檢查嘅嘢。
睇唔到嘅保安漏洞
一個應用程式可以睇落完美無缺,但仍然容許任何已登入嘅用戶讀取其他用戶嘅所有紀錄,或者將密鑰放喺訪客瀏覽器運行嘅代碼入面。你自己用自己個帳戶點撳,係睇唔出呢啲問題嘅。常見問題包括伺服器端缺少權限檢查、API 密鑰放喺前端代碼,以及接受任何輸入嘅表格。
冇人理解嘅代碼
如果冇人睇過代碼,就冇人知道佢點樣組織。細規模時冇問題。隨住應用程式愈嚟愈大,每次改動都可能弄壞無關嘅部分,而 AI 亦可能「修好」一個 bug 時又製造另一個。經過幾個月 vibe coding 而冇任何檢視嘅應用程式,往往比慢慢建造嘅應用程式更難改。
唔知咩叫「完成」
AI 會好樂意話某樣嘢已經修好。只有測試先講得清係咪真係修好。跳過測試嘅人,最後會得到示範時運作正常、但用真實資料就出錯嘅功能:名稱好長、欄位留空、兩個人同一時間預約同一個時段。
隱藏嘅依賴同成本
AI 建造嘅應用程式通常會接駁外部服務,例如電郵供應商、付款處理商、AI API。每一個都有自己嘅帳戶、密鑰、限額同收費。推出之前,要清楚知道你個應用程式依賴咩。
常見誤解
| 誤解 | 實際情況 |
|---|---|
| 「Vibe coding 即係冇代碼。」 | 其實有真正嘅代碼,只係你冇睇。所以你之後可以匯出,或者交俾開發者。 |
| 「能夠運行就即係正確。」 | 運行、正確、安全同易於維護,係唔同嘅事。 |
| 「只係非開發者先會用。」 | 好多專業開發者都會用 vibe coding 做原型,然後先檢視或者重寫,再正式推出。 |
| 「AI 會話我知有問題。」 | 如果你問佢,佢通常會講,但未必會主動提。直接問清楚。 |
| 「咁樣做唔可以做嚴肅嘅嘢。」 | 好多真正嘅應用程式都係咁樣開始。嚴肅嘅部分,係喺真正用戶倚賴之前加入測試同檢視。 |
點樣負責任地做 vibe coding
幾個習慣就可以涵蓋大部分風險:
- 改動要細。 一個要求,一個改動,然後測試。大而含糊嘅要求會產生大而含糊嘅結果。
- 用檢查點。 嘗試有風險嘅嘢之前,確保你可以退返去最後一個運作正常嘅版本。
- 叫 AI 解釋。 「呢個改動做咗乜?可能會弄壞咩?」花唔到幾多時間,但好多問題都可以捉到。
- 以陌生人身份測試。 用第二個用戶登入,試吓睇唔睇到第一個用戶嘅資料。
- 密鑰唔好放喺代碼同對話入面。 API 密鑰應該放喺環境變數或者項目 secrets 入面。
- 面向真正用戶之前要檢視。 如果涉及付款或者個人資料,請跟循保安清單,或者搵開發者幫手檢查。
要求你嘅 AI 建造工具做咩
以下提示可以將「感覺」變成具體檢查:
- 「建造之前,先講你嘅計劃,以及會儲存咩資料。」
- 「列出呢個應用程式儲存或者發送用戶資料嘅每一個位置。」
- 「已登入嘅用戶可唔可以睇到或者改到其他用戶嘅紀錄?請檢查伺服器端代碼,唔好只係睇頁面。」
- 「有冇任何 API 密鑰喺瀏覽器運行嘅代碼入面可以見到?」
- 「如果兩個人同一時間提交呢個表格,會發生咩事?」
- 「總結最近三次編輯改咗啲乜。」
更多寫法可以睇點樣為 AI 應用程式建造工具寫提示;如果出咗問題,就睇點樣除錯 AI 建造嘅應用程式。
用 Mythex 做 Vibe coding
Mythex 係一個AI 應用程式建造工具,就係為咗呢種工作方式而設計:你喺對話中描述應用程式,代理會喺即時預覽中寫代碼同運行,然後你可以發佈到公開網址。有幾個功能就係為咗應付上面嘅風險:Plan 模式可以令代理喺改動任何檔案之前先列出做法,Ask 模式只回答問題而唔編輯任何嘢,而每次成功嘅回合都會保存一個檢查點,等你可以還原。Pro 方案下,你可以打開完整嘅代碼編輯器、匯出項目,或者同步到 GitHub,等開發者檢視。聊天文件會解釋各模式同檢查點,如果由空白頁開始覺得太難,可以睇吓範本提供嘅起點。
常見問題
邊個首先提出 vibe coding 呢個詞?
AI 研究員 Andrej Karpathy 係 OpenAI 嘅創始成員之一,佢喺 2025 年 2 月喺 X 上面發文時創造咗呢個詞。佢形容自己順應感覺,唔再理會代碼係存在嘅,之後呢個詞就好快傳開。
Vibe coding 同 no-code 係一樣嘅嗎?
唔完全係。No-code 工具係喺一個隱藏咗代碼嘅視覺編輯器入面建造。Vibe coding 則係 AI 寫出真正存在於檔案中嘅代碼;你只係選擇唔睇,透過描述你想要咩同檢查結果去引導。
Vibe coding 建造真正嘅應用程式安全嗎?
可以安全,前提係你加入感覺所忽略嘅檢查:測試用戶睇唔到彼此嘅資料,將 API 密鑰放喺 secrets 入面而唔係代碼入面,並檢視任何處理金錢或個人資料嘅部分。對於用完即棄嘅原型,風險低;但對於有真正用戶嘅應用程式,風險就不低。
我要識得編程先可以做 vibe coding 嗎?
唔使。不過認識一啲基本概念,例如咩係資料庫、API 同驗證,會令你嘅要求更清晰,亦有助你察覺問題。你唔使寫代碼都可以理解呢啲概念。