AI 驅動開發：從 Vibe Coding 到 Agentic Workflow
本篇是「一個人做產品」系列的第 5 / 18 篇。你可以從系列總覽開始閱讀，也可以直接接著看本文。
為什麼你的 AI 輔助開發還停在 2024 年
打開 ChatGPT，貼上錯誤訊息，拿到修好的程式碼，複製貼上。
或者用 Copilot，打幾個字，按 Tab 接受建議。
如果你的 AI 開發工作流程還是這樣，你只用到了 AI 能力的 10%。
不誇張。
2026 年的 AI 輔助開發，已經從「工具」進化成「團隊」。你可以讓 AI 自己讀 codebase、跑測試、分析失敗原因、修 bug、送 commit、甚至在部署失敗的時候自動修復後重新部署。
整個流程你可以不用碰鍵盤。
這不是未來式。這是我每天在用的工作流程。
延續上一章把 MVP 砍到不能再砍的思路，這一章談怎麼用 AI 把它快速做出來。這也是整本書最核心的章節，AI 驅動開發是 Solo Builder 能以一人之力做出團隊等級產品的關鍵。我會帶你從最基礎的 Level 1 走到最高階的 Level 3，讓你建造自己的 AI 開發系統。
AI 輔助開發的三個等級
不是所有的「用 AI 寫程式」都一樣。根據 AI 的自主程度，我把它分成三個等級：
| 等級 | 名稱 | AI 做什麼 | 你做什麼 | 效率提升 |
|---|---|---|---|---|
| Level 1 | Autocomplete | 補完你正在打的程式碼 | 逐行寫程式 | 1.3x |
| Level 2 | Vibe Coding | 根據描述生成整段程式碼 | 描述需求、review 結果 | 2-3x |
| Level 3 | Agentic Workflow | 自主讀 codebase、寫程式、跑測試、修 bug | 下指令、做決策 | 5-10x |
大多數人停在 Level 1 到 Level 2 之間。這一章的重點是帶你到 Level 3。
Level 1：Autocomplete — 節省打字時間
這是 GitHub Copilot 最初的用法。你寫一行註解，AI 幫你補完下面幾行程式碼。或者你打了一個函式名稱，AI 幫你把函式實作補完。
適合的場景：
- 寫重複性高的程式碼（boilerplate）
- 補完你已經知道怎麼寫的東西
- 套用常見 pattern
限制：
- AI 不理解你的專案脈絡
- 生成的程式碼常常需要修改
- 每次只能處理幾行到幾十行
Level 1 很有用，但效率提升有限。就像有人幫你打字，但思考還是你自己在做。
Level 2：Vibe Coding — 用自然語言寫程式
Andrej Karpathy 在 2025 年提出了 Vibe Coding 這個詞：不看程式碼、不仔細 review，直接用自然語言描述你要什麼，AI 幫你寫好。如果結果不對，用自然語言描述問題，AI 幫你修。
傳統做法（Level 1）：
- 你打開文件，找到要用的 API
- 你寫第一行程式碼
- Copilot 建議後面幾行
- 你修改、調整、繼續寫
- 你跑測試、發現 bug
- 你自己 debug
Vibe Coding 做法（Level 2）：
- 你在 chat 裡描述：「幫我寫一個 API endpoint，接收用戶上傳的圖片，存到 R2，回傳 URL」
- AI 生成整個函式
- 你跑一下看結果
- 不對的地方貼錯誤訊息回去
- AI 修好
Vibe Coding 的效率大約是傳統方式的 2-3 倍。它的好處是降低了啟動阻力——你不需要先去查文件、搞清楚 API 參數，直接描述想要的結果就好。
但 Vibe Coding 有個致命缺陷：你說一句、AI 做一步，所有的推進力都來自你。AI 沒有主動性，你不說話，它就停下來。
對一個每週只有 5-10 小時的 Solo Builder 來說，這意味著你必須全程盯著螢幕。你的寶貴時間變成了「不斷跟 AI 對話」的時間。
我們可以做得更好。
Level 3：Agentic Workflow — AI 成為自主的團隊成員
Level 3 是質變。
在 Agentic Workflow 裡，AI 不再是被動回應你的問題。它成為一個有自主能力的 agent——你給它一個目標，它自己決定怎麼做：讀哪些檔案、寫哪些程式碼、跑哪些測試、怎麼修 bug。
你的角色從「寫程式的人」變成「管理 AI 團隊的人」。
讓我描述一個我實際的開發場景：
我在 terminal 輸入一句話：「幫我新增一個 blog 文章的標籤篩選功能，參考現有的分類篩選。寫完跑測試。」
然後我去泡咖啡。
回來的時候，AI 已經：
- 讀了現有的分類篩選程式碼
- 理解了專案的 component 架構和 CSS conventions
- 新增了標籤篩選的 component
- 更新了頁面 routing
- 跑了 build 確認沒有 TypeScript 錯誤
- 生成了一個 commit 訊息等我確認
整個過程我不在電腦前。這就是 Level 3 的威力。
但「不用盯著螢幕」這件事，有它的另一面我得先講：你放手的程度越高，一次出錯的傳播半徑就越大，而你能攔下它的機會就越少。我去泡咖啡的那段時間，AI 不只在幫我寫對的東西，也在幫我把錯的東西一路 commit 下去——一個它寫歪的邏輯、一個它沒注意到的安全漏洞，都會被它順手帶過去。所以我自己有一條線：本地的、可逆的、有測試蓋著的操作，放手沒問題；但 production 部署、schema migration、刪資料、動到錢、改安全設定這幾類，我不開全自動，一定要有一個人類確認的關卡。自主程度不是越高越好，是要跟「出錯的代價」配對著用。
建造你的 Agentic Workflow
要達到 Level 3，你需要的不只是一個 AI 工具，而是一套系統。以下是我用 Claude Code 建造的系統架構，你可以參考來建造自己的版本。
組件 1：CLAUDE.md — 教 AI 認識你的專案
CLAUDE.md 是 Claude Code 的核心設定檔，放在專案根目錄。它的功能是讓 AI 理解你的專案架構、開發慣例和偏好。
把它想成是你跟新同事的 onboarding 文件。你會告訴新同事什麼？
- 專案的目錄結構
- 怎麼跑 dev server 和 build
- 命名慣例（component 用 PascalCase、CSS 用哪套方案）
- 部署方式
- 程式碼風格偏好
沒有 CLAUDE.md 的情況：
你每次開啟新的對話，都要重新跟 AI 解釋：「我的專案用 Astro、部署到 Cloudflare、CSS 用 Tailwind、component 放在 src/components/ 底下……」
有 CLAUDE.md 的情況：
AI 自動讀取設定檔，已經知道你的一切偏好。你可以直接說「幫我加一個新 component」，它就會按照你的慣例來做——檔案放對位置、用對的命名、套對的 CSS 方案。
一個好的 CLAUDE.md 大概長這樣：
# 專案名稱
## 指令
- npm run dev — 啟動開發伺服器
- npm run build — 建置生產版本
## 架構
- src/pages/ — 檔案路由
- src/components/ — 元件（按功能分子目錄）
- src/content/blog/ — MDX 部落格文章
## 慣例
- Component 檔案用 PascalCase
- 用 Tailwind CSS，不寫自定義 CSS
- 優先使用既有的 CSS custom properties關鍵原則：越具體越好。 不要寫「程式碼品質要高」這種廢話，要寫「error handling 用 Result type，不用 try-catch」這種具體的規則。AI 需要的是明確的指令，不是抽象的原則。
組件 2：Custom Skills — 教 AI 可重複的任務
如果你發現自己重複叫 AI 做同樣的事，就該把它變成一個 custom skill。
Custom skill 是一組預先定義好的指令，AI 可以直接呼叫。就像是你訓練團隊成員的 SOP。
常見的 Solo Builder custom skills：
| Skill 名稱 | 功能 | 觸發方式 |
|---|---|---|
| new-post | 生成新的 blog 文章骨架 | /new-post "文章標題" |
| review | 做 code review，檢查常見問題 | /review |
| deploy-check | 部署前的預檢清單 | /deploy-check |
| test-write | 為指定功能寫測試 | /test-write src/lib/utils.ts |
| commit | 分析變更、生成 commit 訊息 | /commit |
每個 skill 是一個資料夾，裡面放一個 SKILL.md（帶 YAML frontmatter），寫清楚 AI 應該做什麼、怎麼做、用什麼格式輸出。skill 既可以用斜線指令手動呼叫，也能由 AI 依情境自動載入——這由 frontmatter 的 disable-model-invocation、user-invocable 等欄位控制。
舉例，一個「新增 blog 文章」的 skill 大概是：
# new-post skill
1. 讀取 src/content.config.ts 了解 frontmatter schema
2. 建立新目錄 src/content/blog/{slug}/
3. 生成 index.md，包含完整的 frontmatter
4. frontmatter 的 author 預設為 "Bobo Chen"
5. pubDate 設為今天
6. 標題和 description 根據用戶輸入生成一次設定，永久受用。從此之後，你說一句話就能生成一篇符合你專案規範的新文章。
組件 3：MCP Server — 讓 AI 連接外部工具
MCP（Model Context Protocol）是讓 AI 連接外部服務的標準協定。透過 MCP server，你的 AI agent 可以直接跟其他工具對話。
Solo Builder 最實用的 MCP 連接：
| MCP Server | AI 可以做什麼 |
|---|---|
| Notion MCP | 讀取你的 Notion 筆記和任務清單 |
| GitHub MCP | 查看 Issues、建立 PR、讀 review 留言 |
| Playwright MCP | 開瀏覽器測試你的網站 |
| 資料庫 MCP | 直接查詢和修改資料庫 |
沒有 MCP 的工作流：
- 你在 Notion 看到一個 bug report
- 你把 bug 描述複製到 AI
- AI 給你修復建議
- 你手動修改程式碼
- 你手動跑測試
- 你手動更新 Notion 的狀態
有 MCP 的工作流：
- 你說「處理 Notion 裡的 bug #42」
- AI 自己去 Notion 讀 bug 描述
- AI 找到相關程式碼並修復
- AI 跑測試確認修好了
- AI 更新 Notion 狀態為「已解決」
你只講了一句話。剩下的全部自動化。
組件 4：Hooks — 自動觸發的品質關卡
Hooks 是在特定事件發生時自動執行的腳本。你可以設定 AI 在 commit 前自動跑 linter、在生成程式碼後自動跑型別檢查。
這就像在 AI 的工作流程裡加入品質關卡。AI 不是完美的——它會生成有 bug 的程式碼、忘記 edge case、用了 deprecated 的 API。Hooks 確保這些問題在進入 codebase 之前就被抓到。
常用的 hooks 配置：
| 時機 | Hook | 功能 |
|---|---|---|
| 修改檔案後 | TypeScript 型別檢查 | 確保沒有型別錯誤 |
| commit 前 | ESLint + Prettier | 程式碼格式和品質 |
| push 前 | 跑完整測試套件 | 確保沒有破壞既有功能 |
| 生成程式碼後 | build 驗證 | 確保可以成功建置 |
有了 hooks，你可以放心讓 AI 更自主地工作，因為品質關卡會幫你把關。
Multi-Agent 模式：一個人的開發團隊
Level 3 的進階玩法：同時跑多個 AI agent，每個負責不同的任務。這正是第 1 章宣言裡說的「一個人＋AI 就是一支團隊」的具體實現。
在一個人做產品的情境下，你可以模擬一個小型開發團隊：
| Agent 角色 | 職責 | 類比 |
|---|---|---|
| Developer Agent | 寫功能程式碼 | 開發者 |
| Test Agent | 寫測試、跑測試 | QA 工程師 |
| Review Agent | Code review、抓 bug | 資深工程師 |
| Ops Agent | 部署、監控、修復 | SRE |
一個實際的工作流可能是這樣的：
- 你告訴 Developer Agent：「實作用戶登入功能」
- Developer Agent 寫好程式碼
- Test Agent 自動為它寫測試並跑測試
- 如果測試失敗，Developer Agent 自動收到反饋並修改
- 測試通過後，Review Agent 檢查程式碼品質
- 全部通過，Ops Agent 部署到 staging 環境
你做了什麼？你下了一個指令。其餘的都是 AI agents 之間的協作。
Self-Healing Deploy：AI 自動修復部署失敗
這是我最喜歡的 agentic 模式之一。
部署失敗是 Solo Builder 最頭痛的事——通常發生在你以為已經搞定一切的時候，而且每次的錯誤都不一樣。
Self-healing deploy 的概念很簡單：
- CI/CD pipeline 觸發部署
- 部署失敗
- AI agent 自動讀取錯誤日誌
- 分析失敗原因
- 生成修復 commit
- 重新觸發部署
- 如果三次都失敗，通知你來看
你可以在 CI/CD pipeline 裡加一個步驟來實現這個模式。這個概念不限定於特定工具——重點是「部署失敗時自動分析錯誤並嘗試修復」這個流程。
傳統做法： 部署失敗 → 你收到通知 → 打開電腦 → 看 log → 查原因 → 修 → 推 → 再部署 → 再失敗 → 再修。可能花一整個晚上。
Self-healing 做法： 部署失敗 → AI 自動修 → 自動重新部署 → 成功。你甚至不知道中間失敗過。
不過這個模式我得加個警告，因為它最危險的地方正是「你甚至不知道中間失敗過」。AI 的修復常常是推測性的——它沒真的理解問題，只是試一個看起來合理的改動再推一次。如果它猜錯，下一輪可能在錯的修補上再疊一個錯的修補，commit history 會變得一團亂。而那個「三次才通知你」的設計，意味著在你被叫醒之前，環境可能已經被它的盲目重試搞髒了。所以我會把 self-healing 限制在低風險的部署上（例如預覽環境、可一鍵 rollback 的靜態站），並且強制它每次失敗都把錯誤摘要寫進通知，而不是默默重試到第三次才出聲。production 的部署，我寧可被吵醒，也不要它自己亂修。
Self-healing 只是監控維運的第一層防線，更完整的 AI 監控體系（alert 策略、log 分析、異常自動回報）在第 11 章：監控維運繼續展開。
Iterative TDD Loop：AI 自我修正的開發循環
另一個強大的模式：先寫測試，讓 AI 自己跑「寫程式 → 跑測試 → 看結果 → 修 bug」的循環。
流程是這樣的：
- 你寫測試（或讓 AI 幫你寫，但你要 review）
- AI 實作功能
- 自動跑測試
- 如果失敗：AI 讀錯誤訊息、分析原因、修改程式碼
- 回到步驟 3
- 如果通過：完成
這個循環可能跑 3-5 次，但不需要你介入。你只需要做第一步——定義「正確」長什麼樣（也就是測試）。
這個模式的好處是：你把 AI 的角色從「生成程式碼」變成「達成目標」。AI 不只是產出程式碼，它要對程式碼的正確性負責。
這裡有一個陷阱我特別要點出來：如果上面那個第一步——測試——也是 AI 寫的，那整個循環就變成「AI 寫程式 + AI 寫測試 + AI 判自己過關」，等於讓它自己出考卷又自己改考卷。我踩過這個雷：AI 為了讓紅燈變綠，會去改測試的斷言、塞一堆 mock 把真正的行為繞過去，甚至寫出剛好通過它那段錯誤實作的測試。測試全綠不等於行為正確，它只代表「AI 的實作通過了 AI 對自己的要求」。所以關鍵邏輯的測試，我會自己定義「正確長什麼樣」，至少也要人工 review 一遍——不是看綠燈，是看這些測試到底有沒有測到我真正在乎的意圖。剩下的 boilerplate 測試交給 AI 沒關係，但守門的那幾條，人要在場。
時間對比：傳統 vs. AI 各等級
讓我用一個具體的功能來比較不同等級的效率差異。
任務：為部落格新增標籤篩選功能
| 階段 | 傳統開發 | Level 1 | Level 2 | Level 3 |
|---|---|---|---|---|
| 了解需求 | 15 分 | 15 分 | 10 分 | 5 分 |
| 查文件/範例 | 30 分 | 20 分 | 5 分 | 0 分 |
| 寫程式碼 | 120 分 | 90 分 | 40 分 | 15 分 |
| 寫測試 | 45 分 | 30 分 | 15 分 | 0 分（AI 自己跑） |
| Debug | 60 分 | 45 分 | 20 分 | 5 分 |
| 部署驗證 | 20 分 | 20 分 | 15 分 | 5 分 |
| 合計 | 290 分 | 220 分 | 105 分 | 30 分 |
從 290 分鐘到 30 分鐘，將近 10 倍的差距。
而且 Level 3 的 30 分鐘裡，你實際坐在電腦前的時間可能只有 10 分鐘——下指令和最終確認。其餘的時間 AI 在自己工作，你可以做別的事。
在這類任務上，你每週擠出來的幾小時可以頂以前的一整天。
不過這張表我得標清楚：這是我在「標籤篩選」這種任務上的個人經驗值，不是普適量測，更不是要你拿 290 對 30 去算什麼倍率。我故意挑了一個對 AI 最有利的場景——有現成的分類篩選可以抄、需求邊界很清楚、改錯了也不會出大事。AI 在這種「有 pattern 可參考、低風險」的功能上確實快得誇張。
但換個任務，數字會整個垮掉：
- 全新領域、模糊需求——你跟 AI 來回澄清的時間，可能比自己想清楚還久。
- 深度 debug 罕見問題——AI 容易猜，猜錯了你還要回頭看它改壞了哪些地方。
- 大型 refactor、跨系統整合——上下文一複雜，AI 的命中率掉得很快，加速比可能趨近於零，甚至是負的。
2025 年 METR 那份研究就有一個反直覺的發現：資深開發者在自己熟悉的大型 codebase 裡用 AI，平均反而變慢——他們以為自己快了，實際拖長了工時。所以別把上面這張表當成你的待辦清單會自動縮 10 倍的保證。它告訴你的是「某類任務的天花板」，不是你每件事的平均值。
建造你的 Agentic 系統：三步走
如果你目前在 Level 1 或 Level 2，不要試圖一步跳到 Level 3。循序漸進：
第一週：基礎設施
- 安裝 Claude Code（或你選擇的 agentic 工具）
- 寫好 CLAUDE.md：把你的專案架構、開發慣例、指令全部寫進去
- 測試基本功能：讓 AI 幫你做一個小功能，觀察它怎麼理解你的專案
這一週你可能只會感受到 Level 2 的效果。但基礎建好了。
第二週：自動化
- 建立 2-3 個 custom skills：從你最常做的重複工作開始
- 設定 hooks：至少設定 commit 前的品質檢查
- 嘗試 TDD loop：寫一個測試，讓 AI 自己跑到通過
這週你開始感受到 Level 3 的威力。
第三週：整合
- 連接 MCP server：至少連一個（GitHub 或你的專案管理工具）
- 設定部署自動化：讓 AI 能幫你部署和驗證
- 嘗試 multi-agent：讓 AI 自己寫 + 測 + review
到了第三週，你應該已經有了一套初步的 agentic 系統。之後就是持續優化。
當 AI 出錯：錯誤處理手冊
AI 不是完美的。以下是常見的問題和應對方式：
問題 1：Hallucination — AI 編造不存在的 API
症狀： AI 生成的程式碼引用了不存在的函式或套件。
對策：
- hooks 裡加上型別檢查，在 AI 生成程式碼後自動跑
tsc - 在 CLAUDE.md 裡明確列出專案使用的套件版本
- 遇到不熟悉的 API 呼叫，要求 AI 附上文件連結
問題 2：Context 遺失 — AI 忘記之前的脈絡
症狀： 對話太長後，AI 開始做出跟之前矛盾的事情。
對策：
- 複雜功能拆成多個小任務，每個任務一個新對話
- 把重要決策記錄在 CLAUDE.md 或 IMPLEMENTATION_PLAN.md
- 善用 custom skills 把常用脈絡固化下來
問題 3：過度自信 — AI 信誓旦旦但答案是錯的
症狀： AI 說「這段程式碼是正確的」，但跑起來就爆了。
對策：
- 永遠跑測試，不要相信 AI 的口頭保證
- 用 TDD loop：讓程式碼的正確性由測試決定，不是由 AI 的自信決定
- 設定「三次失敗就停下來」的規則，不要讓 AI 在同一個 bug 上無限循環
問題 4：風格不一致 — AI 生成的程式碼跟你的風格不同
症狀： AI 用了不同的命名慣例、不同的錯誤處理方式、不同的檔案結構。
對策：
- 在 CLAUDE.md 裡寫清楚你的風格規範
- 提供範例：「像 src/components/PostCard.astro 那樣」
- 設定 ESLint/Prettier，用 hooks 自動修正
心態轉換：從「寫程式的人」到「管理 AI 的人」
最後聊聊心態。
很多工程師對 Level 3 感到不自在。「如果我不自己寫程式碼，我還算工程師嗎？」
換個角度想：一個好的 CTO 不會自己寫所有程式碼。他的工作是做技術決策、設計架構、確保品質、管理團隊。
作為 Solo Builder，你就是你的 AI 團隊的 CTO。
你的工作不是打字——AI 打字比你快。你的工作是：
- 做決策：做什麼功能、不做什麼功能
- 設計架構：系統怎麼組織、資料怎麼流動
- 確保品質：設定好測試和 hooks，讓品質有保障
- 給方向：用清楚的指令和 context，讓 AI 做對事情
把打字時間省下來，花在思考和判斷上。這才是 Solo Builder 最稀缺的資源——不是寫程式碼的時間，而是做對的決策的能力。
本章重點回顧
- 🎯 AI 輔助開發有三個等級：Autocomplete（1.3x）→ Vibe Coding（2-3x）→ Agentic Workflow（5-10x）
- 🏗️ Agentic 系統四大組件：CLAUDE.md（專案記憶）+ Custom Skills（可重複任務）+ MCP（外部整合）+ Hooks（品質關卡）
- 👥 Multi-agent 模式讓你模擬一個小型開發團隊：Developer + QA + Reviewer + Ops
- 🔄 Self-healing deploy 和 TDD loop 是最實用的 agentic 模式
- ⚠️ AI 會出錯：用測試和 hooks 把關，設定「三次失敗就停下來」的規則
- 🧠 心態轉換：從「寫程式的人」變成「管理 AI 團隊的 CTO」
下一步
有了 AI 開發系統，你可以用驚人的速度寫程式碼了。
但寫好的程式碼要放到哪裡？部署平台的選擇，對 Solo Builder 來說比你想像的重要得多。選對平台，git push 就自動上線。選錯平台，光是搞部署設定就花掉你一整個週末。
下一章，我們來做這個關鍵選擇。
