Vibe coding 讓你先把小工具做出來

我拆一套 vibe coding 的實戰流程，從選工具、寫 prompt 到修改與收尾，最後給你可直接複製的小 app 模板。

我用 AI coding 工具一陣子了。Demo 很會演，打一段話就生出一個 app，畫面還挺像那回事。但真拿來做正事，我常常只想翻白眼：第一版不是太空泛，就是太愛自作主張，明明我只要一個小工具，它卻硬塞一堆我沒要的元件。更煩的是，我改一個地方，它順手把另外兩個地方弄壞。這種體驗我看太多次了，老實說，根本不像在「加速開發」，比較像在跟一個很熱心但不太懂需求的實習生磨合。

我後來是讀到 Business Insider 這篇 The beginner's guide to vibe coding 才把這件事想通。作者是 Aditi Bharade，文裡把 Lovable、Base44、Claude Code、Cursor、Replit 這幾個工具的用法拆得很直白。它沒有在那邊神化 AI，只是在講一套比較不浪費時間的做法。這才是我想看的東西。

先選工具，不要先幻想一個萬用解

For non-techies looking to build simple tools rather than complex software products, Lovable, Base44, and Replit are your best bet.

翻譯一下就是：不是每個 AI coding 工具都一樣，也不是每個工具都該拿來做同一種事。你如果只是想快速生一個小工具、內部表單、簡單 dashboard，那就別硬上那種流程很重的東西；反過來，如果你想看得到 code、要接 API、想保留手動修改空間，就該挑比較像開發環境的工具。

我之前做過一個很小的請求追蹤頁面，本來以為「反正都能生 code，哪個都差不多」。結果不是。某些工具很會做漂亮第一版，但結構藏得很深，後面改一個欄位像在拆牆。另一種工具雖然畫面沒那麼討喜，但我可以直接看到生成的東西，改起來反而順。這差很多，尤其是你不是在做展示品，而是在做會一直被改的東西。

實操上，我會先問自己三件事：我要的是快、是可控，還是可部署？如果答案是快，我就選偏 builder 型的工具；如果答案是可控，我就選能看 code 的工具；如果答案是可部署，我就先確認 hosting、資料儲存、權限這些會不會卡住。不要拿 landing page 的漂亮程度當標準，真的很容易踩雷。

• Lovable、Base44 適合快速做出可看的小 app。
• Replit 比較像把開發、執行、部署放在同一個地方。
• Cursor、Claude Code 適合你確定會自己改 code。

別直接丟一句話，先把需求寫成像樣的規格

I've learned that the easiest way to get AI to help you build something is to ask an AI tool like ChatGPT or Claude to generate a custom prompt for your app.

這句我很認同。很多人直接對 builder 說一句「幫我做個待辦 app」，然後開始抱怨它做得很空。問題不是 AI 不行，是你給它的輸入太像靈感，不像需求。要快沒錯，但快不是亂。

翻譯一下就是：先用另一個模型，把你的想法整理成一份更像產品簡報的 prompt。你可以用 ChatGPT 或 Claude 先幫你補齊 app 目標、使用者、欄位、頁面、主要操作。這一步不是多餘，這一步通常才是省時間的地方。

我以前很常犯的錯，是覺得模型會自己補齊空白，像資深工程師那樣理解上下文。結果完全不是。它比較像一個反應很快的初階同事，你沒交代清楚，它就會自己選一個「看起來合理」的答案。合理不等於對。

實操寫法很簡單：先別開 builder，先叫 ChatGPT 或 Claude 幫你寫一段 build prompt，內容至少要包含 app 類型、目標使用者、資料欄位、畫面結構、主要動作、視覺風格。你不用寫得很長，但你要寫得像真的要交付，而不是像在許願。

第一版要醜一點，因為它本來就不是成品

The first version of my vibe-coded app, with its all-white background and pie charts, left me deeply unimpressed.

我喜歡這句，因為它很誠實。第一版常常就是不順眼，甚至有點土。那很正常。第一版的任務不是討你喜歡，而是把東西具體生出來，讓你知道哪裡不對。你不先看到錯誤，就不會知道怎麼修。

翻譯一下就是：別把第一輪生成當交付物，把它當診斷工具。你要的是一個能讓你判斷方向的雛形，不是一個可以直接上線的作品。尤其是小 app，更應該先把結構跑通，再來談美感。很多人卡住，就是因為一開始就想把畫面做得像 SaaS 官網，結果根本沒碰到核心功能。

我之前做過一個簡單 CRM 原型，模型一開始給我一個很像 2018 年企業內網的版面，白底、圓餅圖、預設感滿滿。老實講我一開始也嫌棄，但後來我反而感謝它，因為它把問題攤開了：哪些資訊該放前面、哪些元件根本沒必要、哪些地方的層級太弱。第一版不漂亮沒關係，重點是它要夠具體。

實操上，我會把第一版的檢查清單縮成三項：資訊結構對不對、主要流程順不順、資料呈現有沒有說人話。視覺好不好看先放旁邊。你先能用，再談順眼，順序不要搞反。

• 先做一個窄場景，不要一開始就想包山包海。
• 第一版只檢查結構與流程，不急著微調色彩。
• 看到不順眼是好事，表示你已經有東西可以改。

修改 prompt 要像在帶新人，不要像在許願池丟硬幣

What you need are modifying prompts. Think about it like instructing an intern: "Change the colors. Make it more fun."

這句其實很狠，也很準。很多人以為 vibe coding 的重點是「生成」，但真正會不會用，差在你會不會修改。第一版出來之後，你如果還是只會說「更好一點」「更專業一點」「再順一點」，那你大概只是在跟模型玩猜謎。

翻譯一下就是：修改 prompt 要具體，而且要像你在帶一個會做事但需要指令的新人。你不能只說「改漂亮」，你要說哪裡保留、哪裡改、哪裡加、哪裡刪。模型不是不聰明，是它沒辦法替你做取捨。你不講清楚，它就會自己取捨，然後常常取捨到你頭痛。

我有一次改一個 dashboard，明明只想讓它「更清楚」，結果它把所有輔助資訊都砍掉，畫面是乾淨了，可是使用者根本不知道下一步要看什麼。後來我改成「保留資料表、保留篩選器、把次要圖表縮小、把主操作按鈕提亮」，它才終於像樣。這就是差別。

實操寫法我建議直接固定成四段：Keep、Change、Add、Remove。這個格式很土，但很管用。你每次修改都照這個格式寫，模型比較不會亂飛。尤其是 UI 類的調整，越具體越省時間。

先想再建，才能少燒 credits

To ration your daily credits, you can toggle between the "plan" and "build" modes.

這段很務實，我很買單。AI coding 工具很多都不是免費玩具，你每次亂點 build，本質上就是在拿 credits 換失誤。最煩的是，錯了還不一定一次看得出來，等你發現架構不對，credits 也差不多燒掉了。

翻譯一下就是：先用 plan mode 想清楚，再用 build mode 真的動手。plan mode 是拿來問架構、資料需求、可能會壞什麼；build mode 才是你確定方向後，叫它把東西做出來。這個順序很普通，但很多人就是省略，然後一直在修補。

我自己也浪費過不少次。最常見的情況是，我先丟一個功能，看到半成品不滿意，就立刻再丟第二個功能，結果 app 結構越來越歪。後來我才學會：先問「加這個會不會逼我重構」，再決定要不要真的建。這句問完，通常可以少走一堆冤枉路。

實操上，你可以把每次 build 前的流程固定成一個小檢查：這次改動影響哪些資料、會不會動到頁面結構、能不能用最小變更完成。如果答案不清楚，就先停在 plan mode。這不是保守，這是省 credits。

做小一點，反而比較容易真的 ship

Once you're happy with how your website looks, press the "publish" button and enjoy the fruits of your — or AI's — labor.

這句我覺得是整篇最重要的落點。vibe coding 最有用的地方，不是讓你做出一個永遠還差一點的半成品，而是讓你把一個很小的東西真的送出去。小工具、個人儀表板、內部追蹤頁、單一流程表單，這些才是它最適合的範圍。

翻譯一下就是：不要把目標訂成「做一個產品」，先把目標訂成「做出一個能解決單一問題的小 app」。你越小心，越容易完成。你越想一次包大，越容易卡在 prompt、架構、視覺、資料模型全部一起失控。這不是 AI 不夠強，這是你把任務切太大。

我做過一個很簡單的個人支出追蹤器，原本一直想加圖表、通知、分類、同步，後來發現我真正需要的其實只有三件事：新增、總覽、提醒。把範圍砍掉之後，整個流程反而順了。這就是 vibe coding 的實際價值：不是做大，而是做快，然後真的用起來。

實操上，你要先定義完成條件。比如三個畫面、一個資料表、兩個主要操作、能部署、能在手機看。條件達成就停，不要因為模型還能再生一輪就一直加。你不是在養寵物，你是在交付工具。

可抄的模板

Vibe coding 小 app 工作流（可直接照抄）

1) 先選工具，不要先選情緒
- 想快做出可看的小工具：Lovable / Base44 / Replit
- 想保留 code 控制權：Cursor / Claude Code

2) 先用 ChatGPT 或 Claude 產生 build prompt
請它幫我補齊這些欄位：
- app 名稱
- 目標使用者
- 要解決的問題
- 資料欄位
- 主要頁面
- 主要動作
- 視覺風格
- 必要限制

3) 把上面的 prompt 貼進 builder
- 先 build 第一版
- 不要先修細節
- 先看結構、流程、資料是否合理

4) 修改時固定用這個格式
Keep: [保留什麼]
Change: [改什麼]
Add: [新增什麼]
Remove: [刪什麼]

5) 每次 build 前先問 plan mode
- 這個改動會影響哪些資料？
- 會不會逼我重構？
- 最小安全變更是什麼？
- 現在能不能先不 build？

6) 什麼時候可以停
- 核心流程可用
- 主要畫面完成
- 手機可讀
- 能 publish
- 不再為了「更好看」一直改

Copy-ready starter prompt:
Build a simple subscription tracker web app for personal use.
The app should let me add subscriptions with these fields: name, category, cost, billing cycle, start date, end date, and notes.
I want a dashboard that shows total monthly spending, upcoming renewals, and active subscriptions.
Include filters by category and billing cycle.
Make the UI modern, easy to scan, and mobile-friendly.
Use clear labels, simple navigation, and a visual style that feels energetic rather than corporate.
If a chart is included, keep it simple and readable.
Prioritize usability over decoration.

Copy-ready modifying prompt:
Keep the subscription tracker working as-is.
Change the design to a dark theme with brighter accent colors.
Replace any boring default charts with a simpler summary view.
Make the dashboard feel more playful and less corporate.
Add a clear button for creating a new subscription.
Keep the app easy to scan on mobile.

Copy-ready credit-saving prompt:
Before building, tell me what this change will affect, what data it needs, and whether it can be done without restructuring the app.
Give me the smallest safe change set first.
Then I will decide whether to use build mode.

我會把這套方法論收斂成一句話：vibe coding 不是叫 AI 替你想，而是叫它替你快一點把你已經想清楚的東西做出來。這樣用，才比較不會變成 prompt 亂槍打鳥。

來源致謝：主拆解來源是 Business Insider 的文章，作者 Aditi Bharade。我上面的模板是原創整理，但方法論的骨架是從原文延伸出來的。