什麼是 Vibe Coding —
AI 幫你寫程式的時代

一、一句話生出 app 的時代

Vibe coding 是一種用自然語言（natural language）指揮 AI 產生程式的工作方式。你不用先把每個符號都背熟，而是先用人話描述想要的結果，讓 AI 產生第一版程式，再用你的判斷去修改、驗證、追問。它不是「完全不用懂程式」，而是把寫第一版食譜的速度大幅加快。

這件事在 2025 年前後突然變得很有感。AI 不只會回答問題，還能一次生出 HTML（HyperText Markup Language）、CSS（Cascading Style Sheets）、JavaScript（JS）組成的小網頁，甚至幫你改錯、整理檔案、解釋錯誤訊息。以前你可能要先學很多語法才看見畫面，現在可以先看見畫面，再回頭理解它怎麼動。

但「先看到成果」不代表「已經完成」。就像請實習生照你的口述做一份活動流程，他可能很快交出漂亮文件，可是日期可能錯、報名上限可能沒算、付款提醒可能漏掉。vibe coding 的第一個成熟觀念是：AI 產出的 code 只是草稿，不是權威答案。你可以很快得到一個起點，但還要把它當作需要審稿的食譜。

如果你前面學過 ch01 的食譜比喻，這裡就能接上：程式仍然是一連串明確步驟，只是現在有一位速度很快的實習生幫你先寫。你真正要練的不是崇拜速度，而是能不能看出這份食譜少了鹽、火候不對，或把糖寫成鹽。

const request = '做一個待辦清單，可以新增、完成、清空';
const aiDraft = {
  screen: ['輸入框', '新增按鈕', '待辦列表', '清空按鈕'],
  actions: ['新增項目', '切換完成狀態', '清空全部'],
  missingChecks: ['空白內容不能新增', '清空前要確認']
};
console.log('你的需求：' + request);
console.log('AI 草稿包含：' + aiDraft.screen.join('、'));
console.log('主管要追問：' + aiDraft.missingChecks.join('；'));

二、為什麼會動還是不夠

初學者最容易被「畫面看起來能用」騙到。按鈕按了有反應、清單會增加、總額會變，就覺得完成了。可是程式的錯常常藏在邊界條件（edge case）裡：空白可以送出嗎？數量可以是負數嗎？重新整理後資料還在嗎？兩個人同時操作會不會互相蓋掉？這些不是吹毛求疵，而是真正使用時最常出事的地方。

金錢與資安更不能用 vibe 混過。假設 AI 幫你做一個簡單結帳流程，畫面上按「付款」後顯示成功，看起來很完整。但如果程式沒有檢查庫存、沒有確認金額、把私密金鑰（secret key）放在前端，就可能造成扣款錯誤或資料外洩。這裡只需要記住防守常識：不要貼出密碼、金鑰、身分證號或客戶資料；不要執行你看不懂、會刪檔或會傳資料出去的指令。

vibe coding 的危險不是 AI 很笨，而是它太會把東西做得像真的。它會用很順的語氣解釋，也會產生看起來專業的 code。可是一個一本正經的錯誤，比明顯報錯更麻煩，因為你比較不會懷疑它。成熟做法是把「跑得起來」只當第一關，後面還要問：資料從哪裡來？錯誤怎麼處理？使用者亂輸入會怎樣？有沒有留下我不該公開的資訊？

你不需要一次變成資深工程師，但你要養成檢查口袋。每次 AI 交付時，至少檢查三件事：它是否符合原需求、是否處理明顯例外、是否碰到敏感資料或金錢流程。這三問能擋掉很多「看起來完成」的假完成。

還有一種常見風險，是 AI 會替你做出「它以為合理」的決定。例如你沒有說清楚折扣規則，它可能自己假設滿千打九折；你沒有說資料要不要保留，它可能只存在畫面重新整理就消失。這些不是語法錯，而是需求錯。需求錯更難發現，因為程式通常會正常運作，只是運作成一個你沒有真正同意的版本。

function canCheckout(cart) {
  const hasItems = cart.items.length > 0;
  const totalMatches = cart.items.reduce((sum, item) => sum + item.price * item.qty, 0) === cart.total;
  const allQtyValid = cart.items.every(item => item.qty > 0);
  return hasItems && totalMatches && allQtyValid;
}
const carts = [
  { items: [{ name: '貼紙', price: 30, qty: 2 }], total: 60 },
  { items: [{ name: '貼紙', price: 30, qty: -1 }], total: -30 }
];
carts.forEach((cart, index) => console.log('購物車 ' + (index + 1) + ' 可結帳：' + canCheckout(cart)));

三、AI 是超強實習生，不是老闆

這門課會一直使用同一個心智模型（mental model）：AI 是不知疲倦、超博學、速度很快，但會一本正經胡說的實習生。它可以幫你查資料、寫第一版、改錯誤、整理格式，也可以在你累的時候給十種方案。可是它沒有真正承擔結果的責任，也不一定知道你的使用者、商業規則、風險底線。

所以你的角色不是許願者，而是主管。主管不是每件事都親手做，但要講清楚目標、限制、驗收標準，並在交付後抽查。你可以說：「做一個活動報名頁」；更好的說法是：「做一個活動報名頁，欄位有姓名、email、餐食選項；email 必須包含 @；送出後顯示確認；不要真的把資料送到外部服務，只先存在畫面清單。」後者就是把需求變成規格（specification）。

當 AI 回答時，你也要像主管審稿。不要只問「可以嗎」，要問具體問題：這段 code 哪裡儲存資料？使用者輸入空白會怎樣？如果清單有一百筆會不會難用？有沒有多餘套件？能不能把流程拆成三步給我檢查？這些問題會把 AI 從表演模式拉回協作模式。

這個模型也能降低挫折。AI 做錯不是你失敗，而是實習生交了一版需要修的稿。你要做的是縮小任務、補上限制、要求它解釋，再用測試確認。真正的能力不是一次問出完美答案，而是能帶著 AI 逐步逼近可用答案。

const task = {
  goal: '活動報名頁',
  mustHave: ['姓名欄位', 'email 欄位', '餐食選項', '送出後顯示確認'],
  rules: ['email 必須包含 @', '空白姓名不能送出', '資料先留在畫面，不連外部服務'],
  checks: ['輸入空白姓名', '輸入錯誤 email', '送出一筆正確資料']
};
console.log('交辦目標：' + task.goal);
console.log('驗收檢查：');
task.checks.forEach((check, index) => console.log((index + 1) + '. ' + check));

四、工具版圖：三種協作方式

你不用把所有 AI 工具都追完，但要分得出它們大概站在哪裡。第一類是聊天型工具，例如 ChatGPT、Claude。它們像坐在你旁邊的顧問，適合討論需求、解釋錯誤、幫你把想法拆成步驟，也適合請它用白話講一段 code。當你還在想「我到底要做什麼」時，聊天型很適合。

第二類是編輯器型工具，例如 Cursor、GitHub Copilot。編輯器（editor）就是寫 code 的地方，這類工具會直接看你正在編輯的檔案，幫你補程式、改函式、解釋錯誤。它像坐在你的工作桌前一起改稿的實習生，適合你已經有專案、有檔案，想在局部快速修改。

第三類是 agent 型工具，例如 Claude Code 這類能在專案裡讀檔、改檔、跑指令的助手。代理（agent）不只回答，還能連續執行任務：找出相關檔案、修改、測試、再回報。它比較像你派出去辦事的實習生。能力更大，風險也更大，所以更需要明確邊界：哪些檔可以改、哪些不能碰、驗收要跑什麼。

選工具時，不要問「哪個最強」，先問「我現在卡在哪一層」。想釐清想法，用聊天型；想改某段 code，用編輯器型；想讓 AI 在一個專案裡完成多步驟任務，用 agent 型。工具不是身份標籤，而是工作情境的選擇。你越能描述情境，越不會被工具廣告牽著走。

同一個需求也可能依階段換工具。早上你用聊天型工具討論使用者流程，下午把確定的欄位交給編輯器型工具改畫面，晚上再請 agent 型工具跑測試並整理變更。這樣選工具，你會比較像在安排團隊工作，而不是被某個工具的介面牽著走。

function chooseTool(stage) {
  if (stage === '想需求') return '聊天型：先討論目標、限制、使用者情境';
  if (stage === '改檔案') return '編輯器型：在現有檔案旁邊補 code、改錯';
  if (stage === '跑專案任務') return 'agent 型：先給邊界，再讓它讀檔、修改、驗證';
  return '先把卡住的點說清楚，再選工具';
}
['想需求', '改檔案', '跑專案任務', '不知道'].forEach(stage => console.log(stage + ' -> ' + chooseTool(stage)));

五、綠帶五力：你要練的不是許願

從這章開始進入綠帶，重點不是背更多語法，而是建立 vibe coding 的五種主管能力。第一是規格力：把「做一個好用的工具」變成欄位、流程、限制、驗收。規格越清楚，AI 越不容易自由發揮到歪掉。下一章 ch10 會專門練這件事。

第二是閱讀力：看得懂 AI 交回來的 code 大概在做什麼。你不必逐字背語法，但要能辨認變數（variable）、函式（function）、條件（condition）、迴圈（loop）在扮演什麼角色。前面 ch02、ch03 的盒子、分岔路與重複，會在這裡變成讀 code 的地圖。

第三是驗證力：知道怎麼證明它真的可用。不是「我按了一次可以」，而是準備幾個正常案例、錯誤案例、邊界案例，逐一確認。第四是除錯力：出錯時不慌，能讀錯誤訊息、縮小範圍、請 AI 解釋可能原因，再做一次小修改。第五是拆解力：把大需求切成小任務，讓 AI 一次只處理一段，降低混亂。

這五力會把你從「魔法許願師」推向「挑剔主管」。魔法許願師只說我要一個 app，然後相信第一版；挑剔主管會說先做新增功能、再做刪除、每步都要驗收，最後才談美化。這不是變慢，而是讓速度變可靠。AI 時代真正稀缺的不是會貼 prompt 的人，而是能把 AI 產物帶到可交付的人。

你可以把五力當成每次交付前的口頭檢查：我有沒有說清楚？我看不看得懂它大概做什麼？我測過哪些情境？錯了我能不能縮小範圍？任務是不是太大？只要這五問能回答，就算你還不是工程師，也已經不是被 code 牽著跑的人。

const fiveSkills = [
  { name: '規格力', action: '把需求寫成欄位、流程、限制、驗收' },
  { name: '閱讀力', action: '看懂 code 大概在處理哪些資料與步驟' },
  { name: '驗證力', action: '用正常、錯誤、邊界案例測一次' },
  { name: '除錯力', action: '根據錯誤訊息縮小問題範圍' },
  { name: '拆解力', action: '把大任務切成可檢查的小步' }
];
fiveSkills.forEach((skill, index) => console.log((index + 1) + '. ' + skill.name + '：' + skill.action));

檢查一下這章