AI 驅動開發：從 Vibe Coding 到 Agentic Workflow

一個人做產品 第 5 / 18 篇 ，前往系列總覽

本篇是「一個人做產品」系列的第 5 / 18 篇。你可以從系列總覽開始閱讀，也可以直接接著看本文。

從貼錯誤訊息，到讓 AI 自己跑測試

我以前用 AI 寫程式，常常是貼錯誤訊息、拿回修改、自己跑一次，再把新錯誤貼回去。雖然比全靠自己查快，但整個晚上還是得盯著螢幕。

後來開始用 Claude Code，才把讀檔、修改、跑測試這幾步交給它接著做。我負責把需求講清楚，最後看結果；遇到部署、資料或權限相關的操作，再停下來確認。

上一章談怎麼把 MVP 砍到不能再砍，這章就接著整理我怎麼用 AI 開發。先看幾種用法，再說明 CLAUDE.md、Skills、MCP 和 hooks 怎麼搭配。

AI 輔助開發的三個等級

不是所有的「用 AI 寫程式」都一樣。根據 AI 的自主程度，我把它分成三個等級：

用法	AI 做什麼	你做什麼
Level 1：Autocomplete	補完正在寫的程式碼	逐段撰寫、接受或修改建議
Level 2：Vibe Coding	根據描述產生程式碼	描述需求、執行並回報結果
Level 3：Agentic Workflow	讀檔、修改、執行測試與修正	交代範圍、檢查結果

下面依序說明這三種用法，這一章會多談我怎麼使用 Agentic Workflow。

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）：

1. 你打開文件，找到要用的 API
2. 你寫第一行程式碼
3. Copilot 建議後面幾行
4. 你修改、調整、繼續寫
5. 你跑測試、發現 bug
6. 你自己 debug

Vibe Coding 做法（Level 2）：

1. 你在 chat 裡描述：「幫我寫一個 API endpoint，接收用戶上傳的圖片，存到 R2，回傳 URL」
2. AI 生成整個函式
3. 你跑一下看結果
4. 不對的地方貼錯誤訊息回去
5. AI 修好

這種方式比較容易開始：先描述想要的結果，拿到初稿後再查文件、確認參數和行為。

如果工具只能回覆文字，讀檔、執行和回報錯誤仍得由你接手，來回幾次就很花時間。

對一個每週只有 5-10 小時的 Solo Builder 來說，這意味著你必須全程盯著螢幕。你的寶貴時間變成了「不斷跟 AI 對話」的時間。

如果不想每一步都來回對話，可以試試下一種做法。

Level 3：Agentic Workflow — 讓 AI 接著執行與檢查

在 Agentic Workflow 裡，AI 不再是被動回應你的問題。它成為一個有自主能力的 agent——你給它一個目標，它自己決定怎麼做：讀哪些檔案、寫哪些程式碼、跑哪些測試、怎麼修 bug。

你要交代任務範圍和完成條件，再檢查它的修改。

讓我描述一個我實際的開發場景：

我在 terminal 輸入一句話：「幫我新增一個 blog 文章的標籤篩選功能，參考現有的分類篩選。寫完跑測試。」

然後我去泡咖啡。

回來的時候，AI 已經：

1. 讀了現有的分類篩選程式碼
2. 理解了專案的 component 架構和 CSS conventions
3. 新增了標籤篩選的 component
4. 更新了頁面 routing
5. 跑了 build 確認沒有 TypeScript 錯誤
6. 生成了一個 commit 訊息等我確認

整個過程我不在電腦前。回來後再看 diff 和測試結果。

但「不用盯著螢幕」這件事，有它的另一面我得先講：你放手的程度越高，一次出錯的傳播半徑就越大，而你能攔下它的機會就越少。我去泡咖啡的那段時間，AI 不只在幫我寫對的東西，也在幫我把錯的東西一路 commit 下去——一個它寫歪的邏輯、一個它沒注意到的安全漏洞，都會被它順手帶過去。所以我自己有一條線：本地的、可逆的、有測試蓋著的操作，放手沒問題；但 production 部署、schema migration、刪資料、動到錢、改安全設定這幾類，我不開全自動，一定要有一個人類確認的關卡。自主程度不是越高越好，是要跟「出錯的代價」配對著用。

建造你的 Agentic Workflow

我用 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 根據用戶輸入生成

存成 Skill 之後，新增文章就能沿用這些步驟。專案規範改了，再回來更新這一份。

組件 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 的工作流：

1. 你在 Notion 看到一個 bug report
2. 你把 bug 描述複製到 AI
3. AI 給你修復建議
4. 你手動修改程式碼
5. 你手動跑測試
6. 你手動更新 Notion 的狀態

有 MCP 的工作流：

1. 你說「處理 Notion 裡的 bug #42」
2. AI 自己去 Notion 讀 bug 描述
3. AI 找到相關程式碼並修復
4. AI 跑測試確認修好了
5. AI 更新 Notion 狀態為「已解決」

這樣就省掉了在 Notion 和終端機之間複製貼上的步驟。

組件 4：Hooks — 自動觸發的品質關卡

Hooks 是在特定事件發生時自動執行的腳本。你可以設定 AI 在 commit 前自動跑 linter、在生成程式碼後自動跑型別檢查。

AI 可能漏掉邊界情況、用錯 API，或產生型別錯誤。把檢查接到 Hooks，可以提早發現工具檢查得到的問題。

常用的 hooks 配置：

時機	Hook	功能
修改檔案後	TypeScript 型別檢查	確保沒有型別錯誤
commit 前	ESLint + Prettier	程式碼格式和品質
push 前	跑完整測試套件	確保沒有破壞既有功能
生成程式碼後	build 驗證	確保可以成功建置

Hooks 能少掉手動啟動檢查的步驟，但需求有沒有做對，還是要看測試內容和實際結果。

Multi-Agent 模式：一個人的開發團隊

Level 3 的進階玩法：同時跑多個 AI agent，每個負責不同的任務。這正是第 1 章宣言裡說的「一個人＋AI 就是一支團隊」的具體實現。

在一個人做產品的情境下，你可以模擬一個小型開發團隊：

Agent 角色	職責	類比
Developer Agent	寫功能程式碼	開發者
Test Agent	寫測試、跑測試	QA 工程師
Review Agent	Code review、抓 bug	資深工程師
Ops Agent	部署、監控、修復	SRE

一個實際的工作流可能是這樣的：

1. 你告訴 Developer Agent：「實作用戶登入功能」
2. Developer Agent 寫好程式碼
3. Test Agent 自動為它寫測試並跑測試
4. 如果測試失敗，Developer Agent 自動收到反饋並修改
5. 測試通過後，Review Agent 檢查程式碼品質
6. 全部通過，Ops Agent 部署到 staging 環境

這是把任務拆給幾個 agent 的一種方式；前提是先交代好誰負責什麼，以及每一步怎麼驗收。

Self-Healing Deploy：AI 自動修復部署失敗

這是我最喜歡的 agentic 模式之一。

部署失敗是 Solo Builder 最頭痛的事——通常發生在你以為已經搞定一切的時候，而且每次的錯誤都不一樣。

Self-healing deploy 的概念很簡單：

1. CI/CD pipeline 觸發部署
2. 部署失敗
3. AI agent 自動讀取錯誤日誌
4. 分析失敗原因
5. 生成修復 commit
6. 重新觸發部署
7. 如果三次都失敗，通知你來看

flowchart TD
    Deploy["CI/CD 觸發部署"] --> Result{"部署成功？"}
    Result -->|是| Done(["完成"])
    Result -->|否| Log["AI agent 讀取錯誤日誌"]
    Log --> Analyze["分析失敗原因"]
    Analyze --> Fix["生成修復 commit"]
    Fix --> Count{"已經重試<br/>幾次？"}
    Count -->|"< 3 次"| Deploy
    Count -->|"= 3 次"| Human(["通知你來看"])

    Risk["⚠️ 危險區：AI 的修復常是推測性的<br/>猜錯時會在錯的修補上再疊錯的修補"] -.-> Fix
    Guard["我的護欄：<br/>① 只用在低風險部署（預覽環境、可一鍵 rollback 的靜態站）<br/>② 每次失敗都發錯誤摘要，不是第三次才出聲"] -.-> Count

你可以在 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」的循環。

流程是這樣的：

1. 你寫測試（或讓 AI 幫你寫，但你要 review）
2. AI 實作功能
3. 自動跑測試
4. 如果失敗：AI 讀錯誤訊息、分析原因、修改程式碼
5. 回到步驟 3
6. 如果通過：完成

flowchart TD
    You(["你：定義『正確』長什麼樣"]) ==>|"人一定要在這一步"| Test["寫測試<br/>（守門的那幾條自己寫或人工 review）"]
    Test --> Impl["AI 實作功能"]
    Impl --> Run["自動跑測試"]
    Run --> Pass{"通過？"}
    Pass -->|否| Diagnose["AI 讀錯誤訊息<br/>分析原因、修改程式碼"]
    Diagnose --> Run
    Pass -->|是| Ship(["完成（通常循環 3-5 次）"])

    Trap["⚠️ 若測試也是 AI 寫的<br/>就變成自己出考卷、自己改考卷<br/>它會改斷言、塞 mock 把行為繞過去"] -.-> Test

這個循環可以讓 AI 先處理幾輪修改，不必每次都由你貼回錯誤訊息。你仍要確認測試涵蓋了需求，做完後也要看 diff。

這裡有一個陷阱我特別要點出來：如果上面那個第一步——測試——也是 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 去算什麼倍率。我故意挑了一個對 AI 最有利的場景——有現成的分類篩選可以抄、需求邊界很清楚、改錯了也不會出大事。AI 在這種「有 pattern 可參考、低風險」的功能上確實快得誇張。

但換個任務，數字會整個垮掉：

• 全新領域、模糊需求——你跟 AI 來回澄清的時間，可能比自己想清楚還久。
• 深度 debug 罕見問題——AI 容易猜，猜錯了你還要回頭看它改壞了哪些地方。
• 大型 refactor、跨系統整合——上下文一複雜，AI 的命中率掉得很快，加速比可能趨近於零，甚至是負的。

2025 年 METR 那份研究就有一個反直覺的發現：資深開發者在自己熟悉的大型 codebase 裡用 AI，平均反而變慢——他們以為自己快了，實際拖長了工時。所以別把上面這張表當成你的待辦清單會自動縮 10 倍的保證。它告訴你的是「某類任務的天花板」，不是你每件事的平均值。

建造你的 Agentic 系統：三步走

如果你目前在 Level 1 或 Level 2，不要試圖一步跳到 Level 3。循序漸進：

第一週：基礎設施

1. 安裝 Claude Code（或你選擇的 agentic 工具）
2. 寫好 CLAUDE.md：把你的專案架構、開發慣例、指令全部寫進去
3. 測試基本功能：讓 AI 幫你做一個小功能，觀察它怎麼理解你的專案

這一週你可能只會感受到 Level 2 的效果。但基礎建好了。

第二週：自動化

1. 建立 2-3 個 custom skills：從你最常做的重複工作開始
2. 設定 hooks：至少設定 commit 前的品質檢查
3. 嘗試 TDD loop：寫一個測試，讓 AI 自己跑到通過

這時就能試著讓它接著跑幾個步驟，不用每一步都手動啟動。

第三週：整合

1. 連接 MCP server：至少連一個（GitHub 或你的專案管理工具）
2. 設定部署自動化：讓 AI 能幫你部署和驗證
3. 嘗試 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 讀檔、修改、跑測試，再看它在哪一步需要你幫忙。

如果一直在重講專案規則，就補 CLAUDE.md；如果總是在做同一組步驟，就寫成 Skill。等這些用順了，再接 MCP 或試多個 agent。這樣加進來的設定，才是為了省掉實際遇到的麻煩。

接下來還有部署要處理。下一章會比較平台，以及怎麼把寫好的程式放上線。

👉 第 6 章：部署上線——選對平台省 80% 的事