# 如何制定 Vibe Coding 的工作計劃：從需求分析到 AI Plan 模式

[English](../en/17-vibe-coding-work-plan-and-ai-plan-mode-en.md) · [繁中](../zh/17-vibe-coding-work-plan-and-ai-plan-mode-zh.md) · [Español](../es/17-vibe-coding-work-plan-and-ai-plan-mode-es.md) · [日本語](../jp/17-vibe-coding-work-plan-and-ai-plan-mode-jp.md) · [Português (BR)](../pt-br/17-vibe-coding-work-plan-and-ai-plan-mode-pt-br.md)

**作者：** Danko Peng（[@dankopeng](https://x.com/dankopeng)）  
**更新：** 2026 年 3 月  
**閱讀時間：** 約 10 分鐘

-----

## 大多數人的 Vibe Coding 是這樣開始的

有個想法，打開 Cursor，說「幫我做一個 XX app」。

AI 開始生成，你開始改，改著改著發現方向不對，推倒重來。又生成，又改，又不對。

三天後，你有一堆半成品的功能，沒有一個是完整的，也不知道接下來要做什麼。

**問題不是 AI，是你沒有計劃。**

-----

## 為什麼 Vibe Coder 特別需要計劃？

傳統工程師有多年的訓練，知道怎麼拆解問題、評估工作量、排定優先順序。

Vibe Coder 的優勢是速度——但速度也是陷阱。AI 讓你「做任何事都很快」，所以你很容易在錯誤的方向上跑得飛快。

計劃的作用不是讓你慢下來，而是確保你的速度用在對的地方。

-----

## 第一步：寫需求分析書

在打開 Cursor 之前，先花 30 分鐘寫一份需求分析書。

需求分析書是整個 Vibe Coding 專案的第一份文件——在你寫任何一行 code 之前，它就存在了。這份文件是你和 AI 之間的共識基礎，之後每次開新任務，都可以把它貼給 AI，它就知道整個專案的背景，不需要你每次重新解釋。

### 不知道怎麼寫？讓 AI 幫你起草

如果你是第一次做產品，可能不知道怎麼把腦子裡模糊的想法變成一份完整的文件。這完全正常——讓 AI 幫你起草就好。

假設你買了 vibefast.app 模板，想做一個賣手工皂的電商網站。你腦子裡有個模糊的想法，但不知道怎麼整理成文件。

打開 Claude 或 ChatGPT，直接說出你的想法：

```
我想用 vibefast.app 模板（Remix + Cloudflare 全棧）
做一個賣手工皂的電商網站。
我自己做皂，想在網路上賣，顧客可以下單、付款、收到出貨通知。
庫存不多，每次大概 20–30 個品項。

請幫我寫一份需求分析書，包含：
1. 目標用戶是誰、他們的痛點是什麼
2. MVP 核心功能（最多五個）
3. 技術選型（基於 vibefast.app 的現有架構）
4. 這個版本不做什麼
5. 開發任務清單，分成地基/核心/完善三層

先不要動手寫 code，只寫文件。
```

AI 可能會生成這樣的草稿：

```
# 手工皂電商 需求分析書

## 目標用戶
- 他們是誰：喜歡天然手工皂的消費者，25–45 歲，注重成分和品質
- 他們的痛點：找不到有品質保證、成分透明的手工皂購買管道
- 他們想要什麼：簡單瀏覽、安心下單、知道自己的訂單狀態

## MVP 核心功能
1. 商品列表和商品詳情頁
2. 購物車和結帳（Stripe 付款）
3. 訂單管理（顧客可查詢訂單狀態）
4. 出貨後自動發送通知 email
5. 後台管理商品和訂單

## 技術選型（基於 vibefast.app）
- 前端/後端：vibefast.app 現有架構（Remix + Cloudflare Workers）
- 資料庫：D1（商品、訂單、用戶）
- 圖片儲存：R2（商品圖片）
- 支付：Stripe（vibefast.app 已整合）
- 郵件：Resend（vibefast.app 已整合）

## 這個版本不做
- 會員積點系統
- 商品評論功能
- 多國語言
- 手機 app

## 任務清單

### Layer 1 — 地基
- [ ] 建立 products 資料表
- [ ] 建立 orders 和 order_items 資料表
- [ ] 設定 R2 存放商品圖片

### Layer 2 — 核心功能
- [ ] 商品列表頁和詳情頁
- [ ] 購物車邏輯
- [ ] Stripe 結帳流程
- [ ] 訂單確認 email
- [ ] 後台商品和訂單管理

### Layer 3 — 完善
- [ ] 商品圖片 lazy loading
- [ ] 訂單狀態頁面優化
- [ ] SEO meta tags
```

拿到草稿之後，**逐條讀，不要急著接受**：

- 有不明白的地方，問：「order_items 資料表是什麼？為什麼要和 orders 分開？」
- 有不喜歡的地方，說：「我不需要會員系統，顧客結帳不用註冊，改成 guest checkout」
- 有遺漏的地方，補充：「我想加一個庫存管理功能，每個商品要能設定數量上限」
- 有不確定的地方，討論：「出貨通知要用 email 還是 SMS？各有什麼優缺點？」

來回幾輪，直到你看著這份文件，覺得「對，這就是我想做的東西」——這時候才算完成。

**這份文件是你的，不是 AI 的。** AI 幫你起草，但每一個決定都需要你理解和認可。你不明白的不要放進去，你不同意的要改掉。

不需要像正式的產品文件那樣完整，但要涵蓋這幾個問題：

### 1. 這個產品是給誰用的？

```
目標用戶：喜歡天然手工皂的消費者，注重成分和品質
他們的痛點：找不到有品質保證、成分透明的手工皂購買管道
他們想要什麼：簡單瀏覽、安心下單、清楚知道訂單狀態
```

說清楚用戶是誰，之後每一個功能決定都以「這對我的目標用戶有沒有用」來判斷。

### 2. 核心功能是什麼？

列出你的 app **必須有**的功能，最多五個：

```
核心功能（MVP）：
1. 商品列表和詳情頁
2. 購物車和結帳（Stripe 付款）
3. 訂單管理（顧客可查詢訂單狀態）
4. 出貨後自動發送通知 email
5. 後台管理商品和訂單
```

這個清單就是你的 MVP。上線之前，這五個做好就夠了。其他想到的功能，先放到「之後再說」的清單。

### 3. 技術選型

vibefast.app 已經幫你決定好大部分的技術選型，你只需要確認用哪些服務：

```
前端/後端：vibefast.app 現有架構（Remix + Cloudflare Workers）
資料庫：D1（商品、訂單）
圖片儲存：R2（商品圖片）
支付：Stripe（vibefast.app 已整合）
郵件：Resend（vibefast.app 已整合）
```

技術選型一旦決定，不要中途換。換技術的代價很高，而且通常不是因為技術本身的問題，而是因為你還沒熟悉。

### 4. 不做什麼

這一欄和「做什麼」一樣重要：

```
這個版本不做：
- 會員積點系統
- 商品評論功能
- 多國語言
- 手機 app
```

明確說清楚不做什麼，能防止你在開發過程中不斷加功能（scope creep），讓 MVP 永遠做不完。

-----

## 第二步：把需求拆成具體任務

需求分析書寫好之後，把每個功能拆成具體的開發任務。

**不夠具體的任務：**

```
- 做商品頁面
- 做結帳
```

**夠具體的任務：**

```
- 建立 products 資料表（name、description、price、stock、image_url）
- 建立 orders 和 order_items 資料表
- 實作 GET /api/products 端點（商品列表）
- 實作 GET /api/products/:slug 端點（商品詳情）
- 實作 POST /api/checkout 端點（建立 Stripe session）
- 建立商品列表頁面 UI（/shop）
- 建立商品詳情頁面 UI（/shop/:slug）
```

任務越具體，你越容易評估「這件事大概要多久」，也越容易告訴 AI 要做什麼。

-----

## 第三步：排定優先順序

把任務分成三層：

**Layer 1 — 地基（先做）**  
沒有這些，其他功能都跑不起來：

- 資料庫 schema
- Auth 系統
- 專案基本結構

**Layer 2 — 核心功能（接著做）**  
你的 MVP 主要功能：

- 支付流程
- 主要用戶頁面
- Admin 後台

**Layer 3 — 完善（最後做）**  
讓產品更好，但不是必須：

- 動畫和微互動
- SEO 優化
- 錯誤頁面設計

永遠從 Layer 1 開始。很多人一開始就做 Layer 3（調整按鈕顏色、加動畫），結果地基還沒打好。

-----

## 第四步：用 AI 的 Plan 模式

現在你有了需求分析書和任務清單，可以開始用 AI 了。

但不是直接叫 AI 動手——先用 **Plan 模式**。

### 什麼是 Plan 模式？

Cursor 有一個功能叫 **Plan**（在 Chat 模式裡選擇「Plan」）。在 Plan 模式下，你描述你要做什麼，AI 會：

1. 分析你的需求
1. 列出它打算做哪些事、改哪些檔案
1. **等你確認之後，才開始執行**

這和直接叫 AI 動手的差別是：你在 AI 做任何事之前，就能看到它的「計畫」，確認方向對不對。

### 怎麼用 Plan 模式

在 Cursor 的 Chat 面板，切換到 **Plan** 模式，輸入：

```
我要實作手工皂電商的商品列表和詳情頁。

背景：
- 這是一個基於 vibefast.app 的電商 app（Remix + Cloudflare Workers + D1）
- D1 已有 products 資料表，欄位：id、name、slug、description、price、stock、image_url
- 商品圖片存在 R2

要做的事：
1. GET /api/products — 回傳所有上架商品（stock > 0）
2. GET /api/products/:slug — 回傳單一商品詳情
3. 建立 /shop 商品列表頁，顯示商品圖片、名稱、價格
4. 建立 /shop/:slug 商品詳情頁，顯示完整資訊和加入購物車按鈕

請先列出你的計劃和會改哪些檔案，不要先動手。
```

AI 會回覆類似這樣的計劃：

```
我的計劃：

1. 新增 apps/api/src/routes/products.ts
   - GET /products：查詢 stock > 0 的所有商品
   - GET /products/:slug：查詢單一商品

2. 新增 apps/web/app/routes/shop._index.tsx
   - loader 呼叫 products API
   - 顯示商品 grid，每個 card 有圖片、名稱、價格

3. 新增 apps/web/app/routes/shop.$slug.tsx
   - loader 呼叫 products/:slug API
   - 顯示商品完整資訊
   - 加入購物車按鈕（先做 UI，購物車邏輯下一步）

4. 新增 apps/web/app/components/ProductCard.tsx
   - 可重用的商品卡片元件

確認這個計劃可以嗎？
```

你看完確認沒問題，再說「可以，開始實作」。

但「確認沒問題」不是隨便掃一眼就點頭——這一步和需求分析書一樣，要認真對待：

**看不明白的，問清楚：**

```
你說要新增 ProductCard 元件，
這個元件和 shop._index.tsx 的關係是什麼？
為什麼要分開，直接寫在頁面裡不行嗎？
```

**有疑慮的，說出來：**

```
商品圖片存在 R2，你的計劃裡怎麼取得圖片 URL？
R2 的圖片是私有的，需要透過 Workers 代理嗎？
```

**不喜歡的，要求修改：**

```
我不想做可重用的 ProductCard 元件，這個版本先直接寫在頁面裡，
等之後有需要再抽出來。請調整計劃。
```

**確認影響範圍：**

```
這個計劃會新增幾個檔案？會修改到現有的檔案嗎？
有沒有可能影響到已有的功能？
```

把這些問題都問清楚、改到你滿意之後，再說「可以，開始實作」。

一個還沒動手的計劃，改起來代價是零。一個已經實作到一半才發現方向不對的功能，改起來代價可能很高。

### Plan 模式的核心心態：計劃是用來審查的，不是用來批准的

很多人看到 AI 列出計劃，習慣性地說「好，開始吧」——因為計劃看起來很合理，而且你急著想看到進展。

但計劃列出來是給你**審查**的，不是讓你**蓋章批准**的。

有幾次我叫 AI 直接做，它改了我沒預期到的檔案，或者用了一個我不喜歡的架構，改完之後才發現。Plan 模式讓你在 AI 動手之前就能發現這些問題——但前提是你真的有仔細看、真的有問問題。

把審查計劃當成一個獨立的工作環節，不要急。這十分鐘花得值。

-----

## 一個完整的工作節奏

把上面所有東西放在一起，你的工作節奏大概是這樣：

**開始新專案時（一次性）**

1. 寫需求分析書（30 分鐘）
1. 拆成具體任務（30 分鐘）
1. 排定 Layer 1/2/3 優先順序（10 分鐘）

**每天開始工作時**

1. 看任務清單，選今天要做的 1–3 個任務
1. 對於不確定的部分，先用「先不要動手」討論（參考上一篇）
1. 確認方向後，用 Plan 模式讓 AI 列計劃
1. 確認計劃，開始實作
1. 本地測試，沒問題就 commit + push

**每週回顧**

1. 哪些任務做完了？
1. 哪些卡住了？為什麼？
1. 有沒有需要調整優先順序的地方？

-----

## 需求分析書的模板

你可以直接複製這個模板開始：

```markdown
# [專案名稱] 需求分析書

## 目標用戶
- 他們是誰：
- 他們的痛點：
- 他們想要什麼：

## 核心功能（MVP，最多五個）
1. 
2. 
3. 
4. 
5. 

## 技術選型
- 前端：
- 後端：
- 資料庫：
- 支付：
- 郵件：

## 這個版本不做
- 
- 
- 

## 任務清單

### Layer 1 — 地基
- [ ] 
- [ ] 

### Layer 2 — 核心功能
- [ ] 
- [ ] 

### Layer 3 — 完善
- [ ] 
- [ ] 
```

花 30 分鐘填完這個模板，你之後會省下很多「做到一半發現方向不對」的時間。

-----

## 總結

Vibe Coding 的速度優勢，需要計劃來確保方向正確：

1. **寫需求分析書**——用戶是誰、做什麼、不做什麼
1. **拆成具體任務**——越具體越好，方便告訴 AI 要做什麼
1. **排 Layer 1/2/3**——永遠先打地基
1. **用 Plan 模式**——讓 AI 先列計劃，你確認之後再實作
1. **每天選 1–3 個任務**——小步快跑，每天都有完成的東西

計劃不是束縛，是讓你的速度用在對的地方。

-----

**Danko Peng**  
[X](https://x.com/dankopeng) · [YouTube](https://www.youtube.com/@DankoPeng) · [Threads](https://www.threads.com/@dankopeng)

-----

👉 [回到教程首頁](../README-zh.md)

想直接上手完整的 Cloudflare 全棧模板？  
👉 **[vibefast.app](https://vibefast.app/pricing)** — 早鳥 $99，2026 年 8 月 1 日漲至 $199。