這四個月，我學習 Vibe Coding 的心得

今年五月，我透過線上教學與線下實體活動，一頭栽進了正夯的「Vibe Coding」浪潮中，嘗試用 AI 把腦袋裡的點子親手搓出來。從跑團專用的 CRM、個人網站，到前後嘗試打造的 5 款產品 App，過程中碰過了各種硬核技術：串接外部 API、整合 Google 第三方登入、摸索 Stripe 測試環境的金流邏輯，再到研究 Cloudflare 的部署。這段狂熱的摸索期，最終真正完整上線落地的是我的「個人網站」。

回頭看這四個月，過程絕對稱不上優雅，反而塞滿了各種讓人抓狂的「技術暗礁」：

現在許多 AI 工具都整合了 Chat（對話） 與 Work / Agent（工作區） 兩種模式。剛開始我不懂兩者差異，習慣把天馬行空的構思和程式碼執行全塞在 Work 裡進行，結果被懂行的朋友調侃：這種用法根本是「吃米不知米價的天龍人」，白白燒掉極為昂貴的 Token。

經歷了育後，我才建立起清晰的分工邏輯：

在動手寫第一行程式碼之前，先用最平價的對話模式跟 AI 來回激盪。透過一問一答，把腦中模糊的靈感收斂成具體的規格、使用者流程與開發清單。在會議室裡隨便改構想都不心疼，因為動腦的成本最低。

當明確的藍圖成型後，才切換到 Work 讓 Agent 照圖施工、打造第一版原型 MVP（最小可行性產品）。切記，地基打好後的第一次施工通常只會達到六、七成水準，但因為規格事前已經定案，後續精修就能直指核心，不用整棟拆掉重蓋。

1. 撰寫企劃書

在正式執行開發之前，不是靈感一來就直接丟給 AI 盲目產出，背後有很的事前準備需要完成。就像我們在學生時期籌辦過的迎新宿營、校慶活動，或是校外的大型專案一樣；在活動正式開始之前，一定得先確立本次的主題、目標受眾、活動地點與預計參與人數等關鍵細節。只有在前期建立扎實且完善的規劃，我們才能具體釐清這次的專案究竟「要做什麼」以及「該怎麼做」。

整體的推展脈絡大致會呈現這樣：

有想法 － 列出目標 － 預期規劃 － 如何執行 － 實際行動 － 驗證結果 － 優化缺失

2. 面面俱到

統籌一個專案絕不可能只靠總召集人單打獨鬥，底下勢必會再細分出不同的專業部門，例如行銷部、財務部、公關部等；各部門共同協同推進這項計畫，同時也各自承擔著專屬的職責界線。

在實務上，我們通常會依據專案的規模與複雜度，彈性調配各部門的人力資源。同樣的道理，我們不能只賦予 AI 單一模糊的角色，而是要賦予它各部門的專業職能，讓它們清楚明白各自的核心任務。簡單地說，你必須親手打造出一個分工精準的 AI Agent 軍團。

但請務必牢記：你始終是最高統籌者的角色，專門負責拍板「哪些重要的事情必須執行」，以及「哪些不重要的事情堅決不做」。別把決策權完全讓給 Agent 替你決定。

3. 角色定位

當部門架構確立後，接下來便會落實到個人的專長發揮。這時需要為不同的 Agent 進行明確的角色分配；針對每個 Agent 設定清晰的職務定位與專屬技能，讓它們在執行特定垂直任務時能精準發揮價值，而不是讓所有的 Agent 一窩蜂搶著做同一件事。對照職場的實際運作，主管向來是將任務指派給最適任的人選，絕不會讓兩三個人重複做著毫無區別的雜事，反而平白消耗寶貴的人力成本。

當各個角色完成自己的份內職責後，便會循序向上彙報，明確讓主管知道：「我目前已經完成了哪些里程碑」。等到所有角色與各部門都依序回報進度後，接下來你要做的核心工作，就是統整所有輸出成果，進一步收斂並梳理出一個可落地的 MVP（最小可行性產品）專案計劃。

我認為 AI 不再是誰的專屬工具，只要你有想法，幾乎能透過 AI 來實現。所以，我都會鼓勵身邊朋友，有夢就去追、有想法就去執行，別老是停留在腦海裡，它可能會漸漸地被你遺落在某個角落。

以下是我這幾個月開發下來的收穫，是目前適合我的開方方式，還有很多地方可以優化，不見得適合每個人，僅提供大家參考。

1. 設定具體目標

「大膽敢夢，更要勇敢行動。」

很多人以為開發是從「寫功能」開始，其實不是，開發是從「看見終點的模樣」開始。就像準備登上一座高山，出發前你必須先看過整張等高線地圖，確認稜線走向與扎營點，而不是悶著頭一路往上硬切，最後迷失在密林裡。

每當閃過任何創意點子，立刻把它記錄下來，第一時間丟進 Chat 模式跟 AI 來回探討，共同拼湊出終端成品的具體藍圖：

以我過去開發幾款 App 的血淚經驗來說，起初常為了某個酷炫的特殊功能而貿然開工，壓根沒想過產品最終的全貌。缺乏清晰目標的下場，就是在開發過程中被隨興的想法牽著鼻子走，今天加個按鈕、明天刪個分頁，最後拼湊出一個邏輯混亂的「四不像」，平白耗費了極為巨大的時間成本。

2. 產品介面

我個人偏好在 Pinterest 上參考圖片找出喜歡的風格、再用 Gemini 設計產品介面，依照我要的模樣來調整。在產品還沒開發之前，先設定好你要的介面、排版、文字風格，以及互動方式。讓你在第一版做出來後，比較好能按照原有的產品風格來進行優化。

3. 技術框架

很多人以為用 AI 寫程式就完全不用懂技術，這其實是個美麗的誤會。你確實不需要親手刻出每一行程式碼，但你必須知道系統的「骨架」長什麼樣，才不會在產品出狀況時，連問題出在哪個環節都摸不著頭腦。

簡單來說，一個產品由三個核心要素組成，就像一間餐廳的運作：

在向 AI 下指令或梳理架構時，我習慣把流程拆解成「檯面上」與「檯面下」兩個維度來思考。

舉我個人網站為例，頁面底部有一個「請我喝一杯咖啡」的互動表單：

讀者看完我首頁裡的自介後，滑到頁面最下方，你會看到「請我喝一杯咖啡」表單。你可以在欄位裡輸入了暱稱、Email 以及想對我說的話，輕輕按下「送出」按鈕。畫面瞬間轉為「感謝您的來信，我會盡快與您聯繫！」的文字回饋，整個過程不到三秒鐘，乾淨俐落、毫無負擔。

當讀者按下「送出」的瞬間，前端網頁會把剛才填寫的文字打包，透過 API 悄悄發送到後端的處理機制（例如 Google Apps Script）。接著，系統兵分兩路同步執行：一邊呼叫 Google Sheets API，像是在雲端筆記本上默默添上一行新紀錄，記下「誰、在什麼時間、留了什麼話」；另一邊則立刻觸發郵件伺服器，自動發送一封 Email 到我的信箱，提醒我「剛剛有新朋友想請你喝咖啡囉！」。直到確認資料寫入且信件送出後，系統才回傳訊號給網頁，網頁接收到「成功指令」，才向讀者秀出感謝畫面。

這裡甚至不需要花大錢架設獨立的資料庫伺服器，Google Sheet 本身就是最輕量實用的「資料庫」，而信件通知就是即時的「事件觸發」。

理解這個運行邏輯的最大好處是：當某天讀者反映「我按了送出但你好像沒收到」，你就不會慌張地要 AI 瞎猜。你能條理分明地去檢查：是網頁按鈕壞了（前端）、Google 表單額度滿了沒寫入（資料庫），還是通知信被擋信了（第三方服務）。你懂得拆解系統的流向，AI 才能成為你手中最精準的手術刀。

4. 理解你的專案

正式動手的第一步，千萬別急著叫 AI 寫程式，而是先當「面試官」，把前置整理好的企劃與架構整份丟給它，並要求它用自己的話複述一遍：這個專案核心要解決什麼問題？目標受眾是誰？採用哪些技術規格？

這就像新專案啟動時的 Team Briefing。只有當你確認 AI 的理解與你的藍圖完全在同一個頻道上，後續的協作才不會出現「你想要造一台休旅車，它卻幫你拼出一輛割草機」的認知落差。

5. 打造第一版

開發時最容易踩的雷就是「貪心與急躁」。

過去我常犯一個致命錯誤：急著想在幾分鐘內看到完整成品，把整個系統龐大的需求一次灌給 Agent。結果往往是一場災難AI 就像一個被主管在半小時內塞了厚厚十本資料的新人，腦袋瞬間超載打結，吐出來的程式碼漏洞百出、邏輯斷裂。

飯要一口一口吃，系統要一層一層蓋。我現在會要求 AI 先交出只具備最核心功能的 MVP（最小可行性產品），並嚴格拆解成三到五個里程碑逐步實作：

每完成一小塊就驗證一次，穩紮穩打遠比一次崩盤重來快得多。

6. 產品細修

當第一版原型出爐時，通常只能拿到及格線邊緣的 60 分。別氣餒，這完全在預料之中，剩下的 40 分要靠精細打磨。

我最推薦的精修方式是「截圖」：

直接將當前網頁截圖丟回 Chat 模式，圈出你不滿意的區塊。人對視覺的感知遠比文字敏銳，AI 也是如此一張標註明確的圖片，勝過你寫三百字的抽象形容。

在 Chat 裡針對特定局部來回雕琢。例如：「這個送出按鈕是否改用紙飛機 Icon？」、「副標題的灰階層次是否太淡？」、「手機版畫面會不會造成文字折行？」。

有了在 Chat 版討論定案的介面架構圖後，我會要求 Chat 直接將這些具體修改轉化為「極度精準的優化 Prompt（施工指令）」。這樣做能大幅砍掉 Agent 在摸索與試錯時消耗的昂貴 Token。把這張清晰的施工單直接派給 Agent 實作，改出來的成品通常八九不離十，既省錢又省心。

1. 快慢哲學

過去我是個急性子，極度討厭等待，恨不得剛拋出想法下一秒就看見完整產品上線。但在歷經無數次「快快做、狠狠崩」的慘痛教訓後，我才深刻體會到什麼叫「慢即是快」。在開發前期花時間釐清架構、打磨技術骨架，絕不是浪費生命，而是不可跨越的必經之路。

走捷徑、貪快而不打地基，就像用劣質鋼筋強行搶蓋高樓。表面上看蓋得飛快，但結構早已千瘡百孔；一旦遇到使用者流量增加或需求調整這場「小地震」，整座系統隨時會轟然倒塌，最終得花十倍的時間拆掉重建。

前期蹲得越深，後期的爆發力就越強。每一次親手解決 Bug 的回饋、每一回被 AI 逼著理解系統的撞牆反思，都會化為下一次開發時的精準直覺。當你在關鍵節點能做出正確判斷，開發的進度條就會呈現幾何級數的推進。

剛接觸 Vibe Coding 時，我完全是個技術門外漢，連最基礎的 GitHub 版控怎麼用、伺服器怎麼部署都一頭霧水。我不怕露怯，緊抓著 AI 當全天候導師，從一行行指令硬啃，直到親手把網站成功掛載到 Cloudflare 上。

正是這份在前期「慢慢熬」出來的底氣，讓我後續的推進像滾雪球一樣加速從架設一頁式落地頁、串接第三方 API、打造會員 CRM 系統，到逐步摸索多款 App 原型。每一次從零到一的突破，都不是因為我走得有多快，而是我終於學會把每一步踩實。

真正的捷徑，就是不走捷徑。先花時間把思維想透、把地基打造的扎實；後期的快，才是真正能落地的從容。

2. 邊界控制

「產品到底要做到什麼程度才算合格？」這曾是我最難拿捏的痛點。

在前面的篇幅中，我反覆強調了兩次 MVP（最小可行性產品），它的真正威力不在於「做得很簡陋」，而在於「極致的克制」。為了不讓專案失控，我給自己立下了「三原則」：

第一，保護起步時的開發心力。對於剛踏入技術世界的自學者而言，過度龐大的系統架構只會帶來沉重的挫敗感，最後往往因進度停滯而半途而廢。

第二，克制「貪心」的本能。每當在社群或別人的產品上看到酷炫的特效、新奇的互動，腦袋總會忍不住冒出「我也來加一點」的衝動，幻想能拼湊出一個天下無敵的超級產品。但殘酷的現實是： 無節制地添加亮點，只會讓產品迅速失去焦點，淪為臃腫又難用的四不像 。

做加法很容易，靈感一來誰都能加；但做減法需要極大的勇氣。學會對非核心的酷功能說「不」，你才能把最重要的核心打磨到極致。

在敲下第一行提示詞或程式碼之前，最該問自己的根本問題：「這個產品到底要給誰用？」

如果目標是大眾市場：你必須從第一天就直面現實的殘酷「市場定位、獲客成本、留存率、商業模式與維運架構」，每一項都是硬仗；如果純粹是為了解決自己的痛點：目標就是提升效率與體驗，那就大膽拿掉所有繁文縟節，只要它能幫你每天省下 10 分鐘，這就是一個 100 分的好產品。

出發點不同，決策的尺度與架構的寬度就截然不同。釐清初衷，後續的開發才不會陷入自我懷疑的泥沼。

AI 時代給了我們每個人前所未有的「造物能力」。別再讓那些稍縱即逝的靈感或突如其來的點子，孤獨地躺在備忘錄裡發霉。善用 AI，它能以極低的成本幫你快速驗證假說、跑通原型，把原本需要數月的摸索壓縮在幾天之內。

邊做、邊錯、邊學。每一次看著產品在手中從無到有，都是對思維與能力的一次升級。這就像一場「骨牌效應」：推倒第一張骨牌後，前進的動能會一層一層推著你向前奔馳；直到在某一處卡關停下，你不用把整排推翻，只要冷靜地在卡關的地方重新調整、對齊角度，再輕輕推一次，原本的阻礙便迎刃而解，動能繼續向前推進。