VIBE Coding：AI 驅動的企業應用開發新典範

摘要

• 核心論點：AI 沒有讓初階工程師的價值上升，反而讓資深工程師的價值放大 3–5 倍；因為 AI 寫程式很快，但只有資深工程師判斷得出「AI 寫的這段不行」。
• 不是 vibe coding 也能做 vibe coding：產業流行的「靠感覺寫程式」是反模式，我們的 VIBE 流程刻意把規格、測試、審查留給人，把模板、轉換、樣板交給 AI。
• 真實案例：我們對自己動手——把用了快兩年的 Swingvy 換掉，用 VIBE Coding 從零打造 EKel 內部 HR / 營運系統，4 週內同步交付 Web Application、iOS Mobile App、Android Mobile App 三端，2026 年 5 月正式上線。完整案例見 EKel 自建 HR 系統。
• AI 還做不好的四件事：複雜業務邏輯邊界、架構長期取捨、與客戶建立信任、需求模糊時的提問能力——這些才是工程師議價的籌碼。

一、一個常被誤解的詞：vibe coding

過去半年，"vibe coding" 被產業濫用成「AI 寫程式我看得順眼就上線」。我們堅持把它定義回來：

VIBE = Vision-led, Iteration-driven, Boundary-aware, Engineered.

差別在哪？反例先講：開了 Cursor、複製貼上 ChatGPT 輸出、看跑得起來就 commit——這不是 vibe coding，這是技術債生產線。我們的方法論是有紀律的 AI 輔助開發：先規劃、後生成、再嚴格 review，每一步 AI 的角色都明確，沒有「全交給 AI」這個選項。

二、我們的工程師為什麼還沒被 AI 取代

我每週帶內部 review 都會問同一個問題：「這段 AI 寫的，你看得懂為什麼這樣寫嗎？」

這個問題的本質是判斷力。AI 能在 30 秒寫出一個看起來合理的 React component，但它不會告訴你：

• 這個 query 在 10 萬筆資料時會慢到不能用
• 這個 useEffect 的依賴陣列其實會無窮迴圈
• 這個錯誤處理把 silent fail 留在 production
• 這個型別其實會在 Salesforce 整合的邊界爆炸
• 這個 API 是 AI 自己「腦補」出來的，文件根本沒有

判斷這幾件事，就是資深工程師現在的議價籌碼。AI 寫程式快，但 review AI 寫的程式更需要功力。我們的內部說法是：「AI 把寫程式變便宜了，把懂程式變更貴了。」

三、案例拆解：4 週把 Swingvy 換成 EKel 自建 HR / 營運系統

很多人問我們：「VIBE Coding 真的快嗎？」最具體的證明是我們對自己動手——把用了快兩年的 Swingvy 換掉，用 VIBE Coding 從零打造 EKel 內部 HR / 營運系統。傳統估時 4–6 個月，實際 4 週全部上線，三端同步交付：Web Application、iOS Mobile App、Android Mobile App。

為什麼要拿自己開刀：因為這是最誠實的測試。對自己動手，沒有客戶壓力可以推託、沒有需求模糊可以怪別人、沒有「客戶是這樣要求的」可以擋。整個專案從規格到上線都是我們自己負責，每一個工時都有清楚的歸屬。

技術選擇刻意保守、可長期維護：

• Next.js 16 (App Router) — Web 前端與 API routes 一體
• iOS + Android Mobile App — 給差旅現場拍收據、查請款狀態用
• Supabase (Postgres) — 資料庫 + auth + storage
• Vercel — 部署、edge function
• Clerk — 員工身分（整合 Google Workspace SSO）
• Anthropic Claude API — 收據 / 發票自動辨識（金額、商家、稅額、類別）
• Tailwind + shadcn/ui — UI 組件系統

下面拆解這 4 週裡 AI 與人各做了什麼（5 人顧問團隊）：

兩個關鍵觀察：

1. 架構決策時數沒變：再強的 AI 也不能替你決定「要不要把 Mobile 與 Web 共用 type schema」、「Receipt OCR 要不要 fallback 到傳統 regex」，因為這個決定要五年後維護的人扛責任。
2. Code Review 時數反而增加：AI 生成程式碼變多，要看的也變多。沒有嚴格 review 的 AI 輔助開發是裸奔。

跟這個案子有關的延伸閱讀：EKel 自建 HR 系統 — 完整案例 — 那邊有 Sprint 1 / Sprint 2 的詳細交付節奏、收據 AI 的具體實作、為什麼選這個技術堆疊、以及上線後實際運行情況。

四、我們的 VIBE Coding 8 步工作流

每一個 ticket 都會走完這 8 步，沒有例外：

1. 規格人寫：PM 或資深工程師把需求寫成 user story + AC，這一步禁用 AI。
2. AI 拆任務：Claude 把 user story 拆成 sub-task 清單，工程師檢查有沒有遺漏。
3. AI 生成第一版：根據規格 + 既有 codebase 風格，產出第一版實作。
4. 工程師重構：第一版很少能直接用，工程師按 codebase 的慣例調整。
5. AI 生成測試：工程師指定要覆蓋的情境，AI 寫對應測試。
6. 工程師補測試：AI 漏掉的 edge case、negative test 由人補。
7. AI 預審：commit 前讓另一個 AI 角色（reviewer）做第一輪 review。
8. 人 Code Review：人類 reviewer 至少看過所有變更，PR 才能 merge。

這個流程裡，AI 永遠在第一稿，人永遠在最後一稿。

五、我們踩過的坑

坑一：AI 把 API 文件「腦補」出來

Claude 一度產出一段使用某 REST API endpoint 的程式碼——這個 endpoint 不存在。我們花了一小時 debug 才意識到 AI 在幻覺。

對策：所有 AI 生成的外部 API 呼叫必須附原始文件連結，工程師上線前驗證。我們在 prompt template 裡加了一條規則：「若你不確定 API 存在，請輸出 TODO 而不是假裝知道。」幻覺率明顯下降。

坑二：型別看起來對，跑起來不對

TypeScript 通過編譯不代表對。AI 寫的整合層常會把 Date 跟 string 在邊界上混用，本機跑沒事，到 production 拿到時區資料就炸。

對策：邊界層（外部系統互通的地方）一律人工寫；內部商業邏輯才大量用 AI。

坑三：好看但不對的 UI

AI 對美感很有意見，但對使用情境沒有。它會生成一個 dashboard 看起來很潮，但實際每天要按 30 次的按鈕被藏在第三層 menu。

對策：UI 草稿先用 AI 出，但跟使用者面對面 walkthrough 是不能省略的。我們堅持每個 UI 上線前要有 5 位真實使用者的回饋紀錄。

坑四：silent fail 偽裝成 error handling

AI 很喜歡寫 try { ... } catch (e) { console.log(e) } 這種「假裝有 error handling」的程式碼。看起來安全，實際上 production 出問題時找不到 stack trace。

對策：CI 加 lint rule 禁止只 console.log 不向上拋的 catch；Code Review 強制檢查每個 catch 是否有意義。

六、AI 還做不好的四件事

1. 業務邏輯的例外情況：客戶會說「除了那個 VIP 客戶以外」，AI 不會主動問這句話背後有幾個 VIP、定義是什麼。
2. 架構層級的長期取捨：要不要 multi-tenant、要不要事件驅動、要不要 micro-frontend，這些決定五年後還在影響。
3. 與客戶建立信任：AI 不會接電話安撫客戶，也不會在會議室裡讀懂客戶沒說出口的擔憂。
4. 需求模糊時的提問能力：好的工程師會問「您說的『即時』是指多久？500ms 還是 5 分鐘？」AI 通常會直接做出某個解釋的版本，而不問你。

七、人才結構的隱形改變

VIBE Coding 不是純粹的工具升級，它正在改寫工程團隊的金字塔結構：

金字塔被擠扁成菱形。原本中階人做的「依規格寫第一版」工作，AI 接走 60–80%；初階人做的「樣板程式」工作，AI 直接吃掉。剩下需要的角色是能設計、能 review、能跨領域判斷的資深人。

對企業招募的意涵：

• 第一年想用 AI 提速，不要一次大量招新人；先投資現有資深人的 AI 工作流訓練
• 工程主管的核心 KPI 從「人月產出」變成「品質×速度」綜合指標
• Code Review 文化要寫進公司的工程準則裡，沒有強 review，AI 輔助是負分

八、ROI 的真實計算方式

很多企業看 VIBE Coding 的 ROI 算錯了，他們算「AI 工具訂閱費」與「節省的工程師薪水」相減。這是錯誤的算法。正確的算法是：

ROI = (上市時間提前 × 業務機會) − (AI 訂閱 + 額外 review 成本 + 訓練投資)

對 B2B SaaS 而言，提前 3 個月上線通常意味著多兩個季度的合約收入；對內控 / 合規型 App 而言，提前上線意味著風險窗口縮短。這些業務影響遠大於工具錢。

但同時，企業也常忽略隱藏成本：

• AI 訂閱：每位工程師 $50–200 / 月（Claude Code、Cursor、GitHub Copilot 多重訂閱常見）
• Review 工時增加：估算開發時數的 15–25% 增加在 review
• 訓練投資：每位工程師至少 40h 的學習曲線

只有把這些都算進去，才能誠實看 VIBE Coding 對你的組織值不值得。

九、結語：放大資深工程師，不是取代任何人

VIBE Coding 的真相是：它讓資深工程師更值錢，初階工程師更焦慮。 因為 AI 把寫程式的肌肉勞動取代了，留下的全部都是判斷力。

如果你的團隊還沒有人在規矩地玩 AI 輔助開發，現在開始還來得及。如果你準備找資深的人帶這個轉型，歡迎來聊。

十、我們的 prompt template library：四個立刻能複製的範例

不是所有 prompt 都好用。以下四個 template 是我們從上百次嘗試中保留下來的：

Template 1：服務類別生成

你是一位資深工程師。請為下面的 user story 撰寫服務類別：

User Story: <貼上 user story>

要求：
- 處理權限與資料邊界（不繞過 row-level security）
- 所有資料庫查詢必須在 method 開頭，避免迴圈內查詢
- 拋出明確的 custom exception，不要 silent fail
- 附對應的測試案例，覆蓋 positive、negative、bulk 三類情境
- 若 user story 有歧義，請列出你假設的部分

Template 2：UI 元件審查

請審查以下 UI 元件，重點檢查：
1. 資料載入策略是否合理（同步 vs 非同步）
2. 是否有不必要的 re-render
3. 錯誤處理是否會 silent fail
4. 是否有可重用的 sub-component 該被抽出
5. accessibility（a11y）有沒有問題

附上具體建議（不只是說「可以改進」，要說「改成什麼」）。

Template 3：Integration 邊界程式碼

這是一段呼叫外部系統的整合程式碼。請列出所有可能的失敗模式（網路、認證、schema 不符、timeout、rate limit 等），並對每一種說明：
1. 我們的 code 會怎麼反應？
2. 如果反應不夠好，建議怎麼改？

Template 4：商業需求理解

這是客戶提供的需求描述。在開始寫 code 之前，請：
1. 列出你假設的部分（例如：「我假設『所有客戶』指的是 IsActive=true 的客戶」）
2. 列出至少 5 個可能讓需求模糊的邊界情況（如 VIP、休眠戶、欠款戶）
3. 寫出兩個版本的 user story，分別代表兩種合理的解讀

這四個 template 在我們團隊每天都被使用。好的 prompt template 不是寫得花，而是把陷阱寫在前面。

十一、新人三週進入 VIBE workflow 的訓練計畫

新加入的工程師最常見的兩個失誤：要麼完全不信 AI（產出慢），要麼完全信 AI（產出有 bug）。我們設計了一份三週訓練：

關鍵心法：先讓他們相信自己（第 1 週），再讓他們學會駕馭 AI（第 2 週），最後讓他們培養辨別力（第 3 週）。順序不能反，否則會養出「AI 依賴症」的工程師。

十二、Production AI-generated code 的監測與責任歸屬

最後一個常被忽略的問題：上線後 AI 寫的程式碼出問題，誰扛責任？

我們的內部規則：所有 AI 生成的 code，commit 訊息要標記 ai-assisted，但 PR author 是最終負責人。AI 不能簽 PR，所以人簽下去就是承擔判斷責任。

監測上要做兩件事：

1. Sentry / DataDog 上加上 ai-assisted=true tag：方便事後分析 AI 輔助程式碼的 production 失敗率。
2. 季度 retrospective 看 AI 輔助 vs 人工 code 的 incident 比例：如果 AI 輔助比例顯著高，那是 prompt 或 review 流程出了問題。

當這兩件事都做了，AI 輔助開發才是「工程實踐」，不是「賭博」。