IBM Vibe Coding 把提示詞變程式碼

IBM 的 vibe coding 指南其實是在教你用提示詞先產出第一版程式碼，再靠人類把它修好。

我最近一直在看 vibe coding，越看越有種熟悉的煩躁感。不是因為它沒用，剛好相反，是它太容易看起來有用。我把需求丟給模型，它回我一坨像樣的程式碼；我再多問幾句，它又補得頭頭是道。問題是，這種順手常常會騙人。你以為自己在加速，其實只是更快拿到一份需要重寫的草稿。

我讀 IBM 這篇 What is Vibe Coding? 時，最有感的不是它把 vibe coding 說得多漂亮，而是它至少沒有裝傻。它講得很白：先用自然語言表達意圖，讓 AI 生出骨架，再由人去 refine。這就對了。很多人只聽到「AI 會寫 code」，就開始幻想把工程師整個外包給模型，然後再花兩週追 bug，追到懷疑人生。

所以我想把 IBM 這份說法拆開，不是講概念，而是講我會怎麼用。重點只有一個：它到底怎麼把提示詞變成可控的第一版程式碼，哪裡好用，哪裡會翻車，最後又怎麼寫成你真的能照抄的工作流。

這篇的起點是 IBM 的文章 What is Vibe Coding?，作者是 Shalini Harkar。文中還提到 Andrej Karpathy，以及 Replit、Cursor、GitHub Copilot 這些常見工具；我下面的拆解是沿著這些來源往下拆，不是憑空發明一套新名詞。

Vibe coding 不是免寫程式，是先寫提示詞

“Vibe coding” is a new and loosely-defined term in software development that refers to the practice of prompting AI tools to generate code rather than writing code manually.

翻譯一下就是：你不是直接敲每一行程式，而是先把意圖、限制、輸入輸出講清楚，讓模型先吐出第一版。這件事最重要的地方，不是「AI 幫你寫」，而是你把工作單位從「逐行輸入」改成「描述需求」。

IBM 的重點其實很務實。它沒有把 vibe coding 說成什麼神奇新宗教，只是把它定義成一種 prompt-first 的流程。對我來說，這個說法比「AI 寫 code」準多了。因為真正有價值的部分，從來不是模型會不會打字，而是你能不能把需求講到夠清楚，讓產物可以直接進下一步。

我自己最常拿來測這件事的，是 UI 或內部工具。你如果只說「做一個 dashboard」，模型通常會回你一個很像 dashboard 的東西，但細節空洞得要命。可是一旦你說「React、左側導覽、表格、inline filter、loading/error/empty state 都要有」，它就會開始像樣。不是因為它懂你的產品，是因為你把骨架講出來了。

這裡 IBM 提到的工具也很有代表性：ChatGPT、Claude、OpenAI Codex。我會把它們看成不同型態的助手，不會幻想一套工具通吃。有人適合做 scaffold，有人適合 refactor，有人適合來回問答。你如果拿錯工具，還怪它不聰明，那其實是你 workflow 沒分清楚。

實操上，我會把 AI 當成一個打字很快、但需要超明確指令的 junior engineer。你要告訴它 stack、檔案邊界、使用者流程、不能做什麼、成功標準是什麼。這些東西你自己都說不出來的話，先別急著 vibe coding，因為那不是 AI 的問題，是你還沒把需求想完整。

• 先寫提示詞，再寫 code，不要反過來。
• 一定要交代 framework、runtime、輸出格式。
• 先切最小可用片段，別一口氣丟整個產品。

真正省下來的是 boilerplate，不是思考

IBM 說 vibe coding 可以讓人留在創造的狀態，把瑣碎工作交給 AI，還能快速產出標準化的 codebase 結構。這句話我認，因為它講的是速度，不是智商。模型不會替你想產品方向，但它很會幫你把那些重複到讓人想翻桌的東西先鋪好。

我最有感的是重複性高的 setup。新 feature branch，routing 要接、表單驗證要寫、loading/error/empty state 要補、component shell 要拉。這些工作不是難，是煩。煩到你很容易把注意力浪費在「把東西打出來」而不是「這功能到底該怎麼長」。如果 AI 能先把骨架弄好，我就可以把腦力留給真正該想的地方。

IBM 也提到一種「先做出來，再慢慢修」的思路。我同意，但前提是「慢慢修」真的有發生。很多團隊最會犯的錯，就是把第一版草稿當成半成品真理，然後開始裝忙。結果不是沒有加速，而是把風險往後拖，拖到最後一起爆。

所以 vibe coding 最適合的場景很明確：原型、內部工具、demo、驗證想法。你先把東西做出來，讓人看見流程和互動，再決定要不要重做。這比一開始就把每個細節雕到完美，然後發現方向根本錯了，要實際得多。

實操上，我會用一句話判斷要不要上 vibe coding：這個任務的最大風險，是「想法不對」還是「系統撐不住」？如果是前者，AI 很適合。若是後者，別鬧了，先別把核心邏輯交給模型。

• 適合：prototype、internal app、throwaway experiment、UI scaffold。
• 不適合：核心交易流程、安全敏感流程、分散式系統。

提示詞品質，其實就是需求品質

“The more effective the prompt is, the better the output will be.”

這句話很直白，但我還是要講，因為太多人嘴上說懂，手上卻還在丟「幫我做一個好看的頁面」這種空話。提示詞不是魔法咒語，它就是換了介面的需求文件。你寫得越模糊，模型就越會用它自己的預設值補洞。

IBM 給的例子不錯：一個互動視覺體驗，會隨音樂、使用者互動、即時資料變化，還指定 JavaScript 或 React，甚至提到不同 mood 的客製化。這種 prompt 之所以有效，不是因為它長，而是因為它把行為、限制、技術棧都講了。模型最怕的不是複雜需求，是你什麼都沒說，卻期待它懂。

我現在寫 prompt，會直接想成在交代一個只會做第一版的外包工程師。我要它知道五件事：做什麼、給誰用、用什麼 stack、要有哪些狀態、哪些東西不要碰。只要這五件事講清楚，輸出通常就會從「看起來很像」變成「我真的能改」。

我以前踩過的坑很典型：我只說要做一個表單，結果模型幫我加了一堆自作聰明的驗證與 UI 裝飾，最後我還得先砍掉八成內容。後來我改成先寫清楚輸入、輸出、錯誤狀態、非目標，模型反而更像在幫忙，而不是在亂猜。

實操上，prompt 要像規格，不要像心情。你可以直接照這個結構寫：功能、受眾、stack、行為、限制、非目標、交付物。這樣模型才知道自己是在產出哪一層的東西，而不是隨便發揮。

• 功能描述要可驗收，不要只寫感覺。
• 一定要列出 loading、empty、error、success。
• 最好要求它回傳檔案結構與假設，方便你接手。

修正階段才是真正的工程

IBM 的四步驟其實很老實：選平台、定需求、修生成結果、檢查後再交付。聽起來像廢話，因為它本來就該是這樣。真正難的不是叫模型吐 code，而是你有沒有耐心把第三步做完。

我看過太多人卡在第一版就停了。模型一輸出，大家就開始說「差不多了吧」。差不多通常就是最危險的詞。因為你如果沒有真的檢查結構、命名、邊界、錯誤處理，那你只是把重寫的工作延後，沒有省掉。

我自己用 AI 寫 React 小功能時，最常遇到的問題就是 state 分散、component 太肥、命名不一致。這時候我不會直接手工整坨重寫，而是回頭要求模型做更小的切分、抽 helper、把 props 邊界講清楚。這個節奏很重要：先生成，再檢視，再收斂，再重生一次。

IBM 也提醒要在部署前 review。這一步不能只看一眼，真的不能。我要看的是正確性、可讀性、依賴數量、錯誤處理、以及模型是不是偷偷塞了我沒同意的假設。AI 很會補假設，而且通常補得很自然，像沒事一樣。問題就在這裡。

實操上，我會把 refinement 變成清單，而不是感覺。缺測試就補測試，component 太大就拆，架構太鬆就先要 folder map 或流程圖，再碰 business logic。你只要願意把修正當工程做，vibe coding 才真的有用。

• 先看結構，再看行為，最後才看美觀。
• 盡量用 targeted edit，不要每次都整份重寫。
• 生成的 code 要小到你能口頭講完。

IBM 最有價值的提醒，是它直接講限制

“AI simply generates code, but true creativity, goal alignment and out-of-the-box thinking remain uniquely human.”

這句我很買單。AI 可以生 code，但它不會替你扛產品目標，也不會替你決定什麼叫合理妥協，更不會在出事時自己去跟老闆解釋。它只是很會產出看起來像答案的東西。

IBM 列的限制我覺得都很實在：技術複雜度、code quality、performance、debugging、maintenance、security。這些不是附註，這些才是 vibe coding 真正會撞牆的地方。你在 demo 階段覺得它很神，不代表你有能力把它養到上線後還活著。

特別是安全性。IBM 直接提醒，AI 產出的 code 可能被排除在 review 和 security check 之外，這會製造風險。我看過最常見的翻車方式，就是團隊太相信「看起來對」，結果沒人再做一次認真的檢查。這種東西最容易帶著自信上線，然後在最不想修的時候出事。

維護也是大坑。模型生成的 code 常常不是按照你團隊的命名、資料夾、測試、lint 規範來寫，它會自己長出一套很順手但很陌生的結構。短期看沒事，三個月後你自己回頭看，會懷疑這到底是不是你家 repo。

實操上，我會把 vibe coding 放在 guardrails 裡面，不讓模型定架構，不讓它跳過測試，也不讓它繞過 review。快是快，但快不是理由，快只是前提；能不能長期維護，才是重點。

最適合的場景，是人類主導的快速原型

IBM 把快速原型、問題導向思考、降低風險，還有 voice、visual、text 的多模態輸入都放進來，這一點我覺得很準。因為 vibe coding 最強的地方，從來不是證明工程有多高級，而是幫你更快看見事情長什麼樣子。

我比較喜歡把它想成草圖板，不是成品。你先畫出流程、互動、資料流的大概樣子，拿去驗證想法。如果草圖有戲，再進入正式開發。這樣做的好處是，你不會在錯的方向上雕太久。

這也是為什麼早期團隊常常會愛上這套方法。因為他們要的是訊號，不是完美。只要能更快知道「這東西有人要嗎」，就值得。你如果還在 pre-product market fit，卻把每個 function 都當成銀行核心系統在寫，那通常是自虐，不是專業。

IBM 提到的 Replit、Cursor、GitHub Copilot 都可以用，但工具不是關鍵，流程才是。沒有 review 沒有測試，最強工具也只是更快把垃圾生出來。反過來說，只要流程有規矩，普通工具也能很好用。

實操上，我會在團隊裡明確切一條「vibe coding lane」：只用在 idea、prototype、internal experiment。只要要碰到使用者或金流，就回到正常 engineering review。這樣你才有速度，也才不會把風險假裝不見。

可抄的模板

# Vibe Coding 工作流模板（可直接複製改寫）

## 1) 先定義問題
- 我要做什麼？
- 給誰用？
- 解決哪個痛點？
- 什麼叫做成功？

## 2) 丟給 AI 的 prompt
Build a [feature/app/component] for [audience] using [stack].

Requirements:
- Core behavior: [list]
- Inputs: [list]
- Outputs: [list]
- States: loading, empty, error, success
- UI/UX constraints: [list]
- Performance constraints: [list]
- Accessibility constraints: [list]
- Security constraints: [list]
- Non-goals: [list]

Deliverables:
1. Suggested file structure
2. Implementation code
3. Short explanation of key decisions
4. Assumptions made
5. Follow-up questions for me

## 3) 第一輪 review 清單
- 行為有沒有對上需求？
- 結構是不是看得懂？
- loading / empty / error / success 有沒有處理？
- 有沒有測試或至少可測試案例？
- 依賴有沒有太多？
- 有沒有安全或隱私問題？
- 三個月後別人看得懂嗎？

## 4) 精修 prompt
Refine the code with these changes:
- [specific change 1]
- [specific change 2]
- [specific change 3]

Keep the same stack. Keep the scope limited to these changes. Preserve working behavior unless explicitly requested otherwise.

## 5) 上線規則
不要把生成的 code 直接丟 production，直到：
- 人類 review 過
- tests 跑過
- 安全敏感路徑檢查過
- code 不看 prompt 也能看懂

這份模板就是我把 IBM 文章拆成可執行版本後，留下來最有用的部分。它的精神很簡單：先把需求講清楚，再讓 AI 產第一版，然後你要真的做 review 和 refinement，不要把「快」誤認成「完成」。

原始來源是 IBM 的 What is Vibe Coding?。上面關於流程、風險與模板的整理，是我根據原文做的實務化改寫；模板本身是我自己的可複製版本，不是 IBM 原文直接附上的內容。