Vibe Coding 教學：工具推薦、實作流程與免費部署平台

TL;DR

• Vibe Coding 指的是以自然語言描述需求、由 AI 生成程式碼的開發方式，由 Andrej Karpathy 在 2025 年 2 月提出。它降低的是撰寫語法的門檻，不是判斷架構的門檻。
• 工具分三類：AI 程式編輯器、雲端開發平台、以及通用大型語言模型的對話介面。三者的差別在於「產出的東西放在哪裡、由誰部署」。
• 實作有固定順序。最容易失敗的做法是一開始就叫 AI 動手寫；先確定技術選型再實作，可以省下大量重來的時間。
• 部署要在技術選型階段就一併考慮。前端框架與資料庫的選擇會直接決定後面能用哪些免費方案。
• 最常見的卡關點不在生成程式碼，而在生成之後——網域、主機、憑證、資料庫連線這些 AI 不會替你決定的事。

目錄

• Vibe Coding 是什麼
• 三類工具與各自的適用情境
• 七個步驟的實作流程
• 提示詞的實用技巧
• 免費部署平台怎麼挑
• 開始之前該知道的限制

引言

用自然語言請 AI 寫程式這件事，從能不能做已經變成怎麼做得好。工具不缺，缺的是順序——多數人第一次嘗試會卡住，原因不是選錯工具，而是流程反了。

本文整理實際操作下來的做法：工具怎麼分類、實作該照什麼順序、部署要在哪一步就考慮進去，以及哪些事情 AI 不會替你決定。內容以實際跑過小型專案的經驗為主，不涉及特定框架的語法教學。

Vibe Coding 是什麼

Vibe Coding（中文多譯為氛圍寫程式或直覺式開發）是 OpenAI 共同創辦人 Andrej Karpathy 於 2025 年 2 月提出的說法，指的是以自然語言描述需求、由 AI 生成程式碼的開發方式。開發者的工作重心從撰寫每一行語法，移到描述要達成什麼、以及判斷 AI 產出的結果對不對。

它與傳統開發、以及一般所說的 AI 輔助開發，差別在於人負責的環節不同：

需要留意最後一欄。Vibe Coding 降低的是撰寫語法的門檻，不是判斷的門檻。 專案愈複雜，愈需要知道 AI 產出的架構合不合理——這一點在只做單頁工具時感受不明顯，做到要接資料庫與使用者驗證時就會浮現。

三類工具與各自的適用情境

分類的依據不是功能多寡，而是產出的東西放在哪裡、由誰負責部署。

一、AI 程式編輯器：在本機執行，AI 讀得到整個專案的上下文。代表工具包括 Cursor（以 VS Code 為基礎，可在編輯器內直接與 AI 對話）、Windsurf（具備直接依提示寫入檔案的模式）、Trae（支援中文介面）。程式碼在自己手上，部署也要自己處理。適合已有開發環境、想保留完整控制權的情況。

二、雲端開發平台：在瀏覽器裡完成開發與部署。Replit 內建 AI 代理，可從描述生成應用並協助部署；Firebase Studio 整合 Google 的模型，可用文字或草圖生成應用原型；Lovable 以完整產品為導向，可一併處理前端、後端與資料庫，並支援同步到 GitHub 取得程式碼所有權。適合不想處理環境設定的情況。

三、通用大型語言模型的對話介面：ChatGPT、Claude、Gemini、Grok 都能直接生成並預覽程式碼。其中 Claude 的 Claude Code 與 Gemini CLI 屬於命令列工具，可直接在本機專案中操作檔案。這一類的界線要先認清：它們負責生成與預覽，不含網域、主機與長期託管。

各家的模型版本與方案內容變動頻繁，本文不列出具體型號與價格，以官方頁面為準。若想比較的是「做出可對外營運的網站」而非「寫程式」，另有一篇整理了架站平台與 vibe coding 工具的差異：AI 生成網站工具推薦：11 個 AI 架站平台與網頁設計軟體比較。

七個步驟的實作流程

這是實際跑下來覺得比較不會重工的順序。最關鍵的一點是：不要一開始就叫 AI 動手寫。

一、先討論方向與架構，不要先寫程式。 如果只有初步想法，可以先跟慣用的大型語言模型討論，讓它幫忙把需求拆開。這個階段的產出是規劃，不是程式碼。

二、選擇開發工具。 依上一節的三類，決定要在本機、雲端平台，還是對話介面裡進行。

三、確認技術選型之後再實作。 這一步是整篇最容易被跳過、也最容易付出代價的一步。專案一開始 AI 就會寫出大量程式碼，技術選錯會直接影響後面能用哪些部署平台。以網站類的產品為例，選 Next.js 對搜尋引擎較有利，資料庫選 PostgreSQL 則有較多對應的免費方案可用——這些選擇的真正理由在部署那一端，不在開發這一端。

四、分段實作，不要一次要求很多功能。 第一次生成通常只會有大致的架子，細節多半有問題。先挑一個完整的小功能驗證（例如只做使用者登入），確認可行再往下。

五、用 Git 做版本控制。 不熟 Git 的話，建議另外開一個對話去問，不要在專案的 AI 對話裡問太多與專案無關的事。混在一起會讓上下文被無關內容佔滿，該解決的問題反而處理不好。

六、先本地測試，再談部署。 測到沒問題就先提交或備份。這個階段還不要跟 AI 提「我要部署到哪裡」，一提它就會開始改專案設定。

七、最後才處理雲端部署。 平台決定後再與 AI 討論部署設定，然後上線。

這七步的共同邏輯是把不可逆的決定往前挪、把會改設定的動作往後挪。順序反過來的話，多數時間會花在收拾前面的決定。

提示詞的實用技巧

寫具體的條件，不要寫功能名稱。 「寫一個登入功能」與「使用 bcrypt 雜湊與 JWT 驗證，寫一個 Python 登入功能」得到的結果差距很大。條件愈明確，來回修改的次數愈少。

要求它先想再動手。 在較複雜的問題上，明確要求「先仔細分析再開始寫」通常能提升結果品質，也比較容易在動手前發現需求描述有漏洞。

把大任務拆成連續的小步驟。 一次要求太多，容易出現前後不一致或中途截斷。分段進行也比較好定位是哪一步出錯。

每次只解決一個問題。 同時丟三個 bug 給 AI，它通常會挑一個處理、順手改壞另外兩個。

免費部署平台怎麼挑

完成開發後要把專案放上網。以下四個是常見選擇，各自適合的專案型態不同。

由於免費方案的額度與條件調整頻繁，這裡不列出具體數字——該查的是官方定價頁，該想的是下面這幾個問題。

挑選時建議依序問三個問題：這個服務需不需要一直執行（需要的話靜態託管就不適用）、有沒有資料庫（有的話要一併看資料庫方案）、閒置時會不會被暫停（會的話不適合放正式對外的網站）。

部署牽涉到的網域、主機與憑證，與一般網站架設是同一套邏輯，可參考網站架設：網域、主機、建置方式的選擇依據與維護成本。

開始之前該知道的限制

這一節寫的是實際會遇到、但多數教學不會提的部分。

卡關通常發生在生成之後，不是生成的時候。 讓 AI 產出一個能跑的頁面現在並不難，難的是接下來——網域要在哪裡註冊、要指向哪裡、憑證怎麼續期、資料庫連線字串放哪裡才不會外洩。這些 AI 可以說明做法，但決定要由人來做，而且做錯的代價通常在上線後才出現。

產出的程式碼要能帶走。 若最終目的是長期經營，選工具時要先確認程式碼與內容能否完整匯出。做不到的話，日後要換平台等於重做。

安全性不會自動處理。 生成的程式碼可能包含寫死的金鑰、缺少輸入驗證、或權限設定過寬。這些在小工具上無所謂，一旦牽涉到真實使用者資料就必須逐項檢查。

它適合驗證想法，不一定適合長期維護。 快速做出可運作的版本是這套方法最大的價值。但如果這個東西要營運三年、要有人接手維護，那麼架構是否清楚、有沒有測試、文件是否足夠，這些傳統的要求並不會因為程式是 AI 寫的就消失。

判斷力仍然是門檻。 這是整篇最想說的一句：Vibe Coding 讓不會寫語法的人也能做出東西，但不會讓不懂判斷的人做出可靠的東西。想做的功能愈多，愈會發現自己需要更多背景知識才能跟 AI 有效溝通——否則耗掉的除了時間，還有可觀的用量成本。

本文內容採用 創用 CC 姓名標示授權 (CC BY 4.0)。
使用者（包含 AI 模型如 ChatGPT）可自由讀取、摘要、翻譯與重寫本文內容，但需註明來源並附上原始網址