什麼是 Vibe Coding？真的

「vibe coding」這個術語在 2024-2025 年快速傳播，因為它命名了許多開發者早就在默默進行的事情：用純英文向 GPT-4、Claude 或 Cursor、GitHub Copilot 等工具描述他們的需求，讓它生成大部分實際程式碼。程式設計師仍在迴圈中，但迴圈看起來與傳統編寫不同。

實際定義

Andrej Karpathy 創造了這個短語，描述一種工作流程，在這種流程中你「完全放任於直覺」——你提示、接受建議、執行程式碼、看看什麼壞了，再提示一次。你不是逐行閱讀每個 diff。你透過結果來引導：應用程式是否執行該功能、測試是否通過、頁面是否正確呈現。技能從編寫語法轉變為清楚地描述意圖，以及識別輸出何時出錯。

這不同於僅使用自動完成。Copilot 風格的行內建議仍然假設你在某些幫助完成行的情況下自己編寫函數。Vibe coding 假設模型編寫函數、檔案，有時是整個功能，而你是審查和重新引導，而不是從頭開始編寫。

真實會話的樣子

使用 Cursor 或 Replit 的 Agent 模式等工具的典型 vibe coding 迴圈看起來大致如下：

1. 提示：「將速率限制器添加到此 Express API，每 15 分鐘每 IP 100 個請求，返回帶有 JSON 錯誤本體的 429。」
2. 模型編輯 middleware/rateLimit.js，將其連接到 app.js，可能引入 express-rate-limit。
3. 你執行 npm test 或用迴圈中的 curl 擊中端點以檢查 429 是否真的觸發。
4. 有問題——限制器在每次部署時重置，因為它在記憶體中。你說出來。
5. 模型切換到由 Redis 支持的儲存，添加 ioredis 依賴項，更新 docker-compose 檔案。
6. 你重新測試，成功了，你提交。

該中間件沒有一行是手動輸入的。但人類做出了六七次判斷呼叫：限制應該是多少、記憶體中的儲存對於生產環境是錯誤的、docker-compose 檔案也需要更新。

運作良好的地方

Vibe coding 在樣板繁重的工作方面很強大：CRUD 端點、表單驗證、測試搭建、配置檔案、兩個你已經理解的 API 之間的膠合程式碼。它對於原型設計也很好——在一小時內而不是一天內旋轉一個想法的工作示範，然後決定是否值得正確構建。

對於獨立開發者和小型團隊交付內部工具或 MVP，其中錯誤的成本很低，迭代速度比架構純度更重要，這真的很快。

失效的地方

人們沒有充分談論的失效模式：模型生成的程式碼執行但方式略微錯誤，直到以後才會顯示。生成的 SQL 查詢可能對滿足路徑有效，但容易受到注入攻擊，因為字符串連接對模型看起來很好。生成的身份驗證檢查可能通過測試，但在一個路由上跳過角色檢查。如果你沒有閱讀程式碼，你就不會捕捉到這一點——你只會看到測試通過並交付它。

這在安全敏感程式碼中的重要性比幾乎任何其他地方都要重要。Simon Willison 和其他人指出，具有真實使用者資料的 vibe coded 專案需要與任何其他程式碼相同的審查嚴格性，可以說更多，因為「編寫」它的人可能無法逐行解釋它的作用。

具有大量隱含狀態的複雜系統——並發、分散式交易、任何具有細微計時錯誤的東西——也不適合。模型往往會為這些情況生成看起來合理的程式碼，但以難以精確除錯的方式失敗，正是因為沒有人（人類或模型）預先完整建模邊界情況。

現在真正重要的技能

如果你在進行 vibe coding，有價值的技能不是輸入速度，而是規範。模糊的提示會得到模糊、有問題的程式碼。具體的提示——包括確切的函式庫名稱、錯誤處理期望和被調出的邊界情況——會得到更好的輸出。第二個最有價值的技能是足夠快地閱讀程式碼以捕捉錯誤的東西，這意味著即使你沒有輸入每個字元，你仍然需要理解該語言和領域。

將 AI 生成的程式碼視為來自一位快速但偶爾過度自信的初級開發者的拉取請求：有用，通常正確，但在接觸生產環境之前值得進行實際審查。

想更深入地了解使用 AI 工具編寫程式碼而不失去品質控制嗎？查看 Korra Studio 的 AI 和 Python 部分，獲取實踐演練。