最近用 Vibe Coding 做了一個 Blog，雖然文章產量不高，加上現在網路上一堆 AI 生成的相似內容，讓我也猶豫要不要寫。但回頭想想，現在的開發流程跟一年前完全是兩回事，還是決定把心得記錄下來。
現在如果還有人說 Vibe Coding 只是給外行人玩的，那他可能還停留在「餵一段 Prompt 然後 Enter」的階段。如果只是單純叫 AI 做個網頁，出來的東西通常很陽春，而且那種紫色底的 Tailwind 配色一看就很「AI 味」——那是因為你沒有給規格，AI 只能照著預設套路走。
1. 先討論出完整架構（最重要的步驟）
這是我認為最關鍵的一點。不管是自己寫一個討論用的 Skill，還是用 Claude Code 或其他 CLI 的 Plan Mode 都行，這個步驟要盡可能的產出詳細的架構。
我會先跟 AI 磨合出一份我滿意的文檔，然後再叫它重新審視一遍，看哪裡要補強。一開始架構訂得越詳細，後面就越省事。如果沒考慮清楚，寫到一半才發現需求對不上，那不只是浪費 Token，可能連架構都要砍掉重練。
2. 產出設計稿
UI 不能放任 AI 亂跑。我目前主要用 Pencil，我個人認為它比 Stitch 好用很多，不管是間距調整還是樣式反應都更快，還能搭配 Skill 使用。
如果我腦中已經有網站的雛形，我會先畫個 Prototype 餵給 Pencil。至於風格或配色，如果沒靈感，我會掛個像是 ui-ux-pro-max 這種 Skill 進去，保證生出來的 UI 至少有專業水準，不再是那種公版的 AI 味。
3. SDD(Specification-Driven Development 規格驅動開發)
有些人對 SDD 反感，但無論如何我認為拆分任務才是最主要的。大家都遇過 AI 處理大任務時會偷懶，所以不管有沒有用 SDD 我會在 Agent.md 或 CLAUDE.md 加上規則，要求 AI 拆分任務一條一條處理。
我使用的是 OpenSpec，這工具好處是新舊專案都很容易使用。下一個 /opsx:new 建立任務，會自動產出 Proposal、Specs、Design，最重要的是產出 tasks.md 的任務清單。
4. TDD (Test-Driven Development 測試驅動開發)
TDD 這步其實在前面的 /opsx:ff 或 /opsx:new 階段就已經佈署好了。我有寫skill讓Openspec在規劃任務時就會要求同步切分 Task，讓接下來的 /opsx:apply 必須嚴格執行：先寫測試檔案，跑出紅燈，才能動實作代碼。
「為什麼 Red（紅燈）階段一定要失敗？」 因為如果還沒寫 Code 測試就過了，那這測試就完全沒意義。 先看到紅燈，是為了證明這個測試「真的有在守門」。在 Vibe Coding 裡，如果不加測試，AI 很容易改 A 壞 B，這能讓 AI 更可靠地自我測試。
這裡有用兩個prompt，禁止讓 AI 鑽漏洞：
隔離性： AI 寫測試時絕對不能看即將要寫的實作代碼。不然它只會照著「代碼現在做了什麼」去寫測試，而不是根據「應有的行為」來測。
流程紀律： 如果在 Green（實作）階段發現測試寫錯了，AI 絕對不能回頭改測試。它必須立刻中斷（Abort），回到 Red 階段重新開始。
如果不這樣強制要求，AI 為了讓燈變綠，會去「作弊」改掉測試來配合它寫的 Code。
結語：開發者的角色轉變與不可替代性
現在的開發不再是拚手速寫語法，而是拚你對「流程」的管控能力。完成上述工作後，只要專案不是太複雜，讓 AI 跑完流程基本上就能完成第一版。
身為工程師，這點確實很痛苦，因為你會看到很多不會 Coding 的人利用 AI 就能馬上做出你學了好幾年才能做出來的專案。現在很多人說開發不必再刷題、不了解底層邏輯也能做出東西，這確實是事實。
是這樣沒錯，但不是這樣。當專案複雜度提高、涉及大規模的資料結構設計、底層邏輯優化、或是對編程語言特性的深度依賴時，專業開發者與純粹 Vibe Coder 之間的差距會被無限放大。
AI 可以幫你寫出跑得動的程式，但它無法替你決定整體的架構優劣。如果沒有經過系統性的學習與基本功的累積，一般的 Vibe Coder 很難產出真正高品質、高可維護性的專案。在 AI 時代，我們不再只是代碼的「打字員」，而是站在更高維度的系統架構師與品質守門員。