如何制定 Vibe Coding 的工作計劃：從需求分析到 AI Plan 模式
English · 繁中 · Español · 日本語 · Português (BR)
作者： Danko Peng（@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 會：
- 分析你的需求
- 列出它打算做哪些事、改哪些檔案
- 等你確認之後，才開始執行
這和直接叫 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 動手之前就能發現這些問題——但前提是你真的有仔細看、真的有問問題。
把審查計劃當成一個獨立的工作環節，不要急。這十分鐘花得值。
一個完整的工作節奏
把上面所有東西放在一起，你的工作節奏大概是這樣：
開始新專案時（一次性）
- 寫需求分析書（30 分鐘）
- 拆成具體任務（30 分鐘）
- 排定 Layer 1/2/3 優先順序（10 分鐘）
每天開始工作時
- 看任務清單，選今天要做的 1–3 個任務
- 對於不確定的部分，先用「先不要動手」討論（參考上一篇）
- 確認方向後，用 Plan 模式讓 AI 列計劃
- 確認計劃，開始實作
- 本地測試，沒問題就 commit + push
每週回顧
- 哪些任務做完了？
- 哪些卡住了？為什麼？
- 有沒有需要調整優先順序的地方？
需求分析書的模板
你可以直接複製這個模板開始：
# [專案名稱] 需求分析書
## 目標用戶
- 他們是誰：
- 他們的痛點：
- 他們想要什麼：
## 核心功能（MVP，最多五個）
1.
2.
3.
4.
5.
## 技術選型
- 前端：
- 後端：
- 資料庫：
- 支付：
- 郵件：
## 這個版本不做
-
-
-
## 任務清單
### Layer 1 — 地基
- [ ]
- [ ]
### Layer 2 — 核心功能
- [ ]
- [ ]
### Layer 3 — 完善
- [ ]
- [ ]花 30 分鐘填完這個模板，你之後會省下很多「做到一半發現方向不對」的時間。
總結
Vibe Coding 的速度優勢，需要計劃來確保方向正確：
- 寫需求分析書——用戶是誰、做什麼、不做什麼
- 拆成具體任務——越具體越好，方便告訴 AI 要做什麼
- 排 Layer 1/2/3——永遠先打地基
- 用 Plan 模式——讓 AI 先列計劃，你確認之後再實作
- 每天選 1–3 個任務——小步快跑，每天都有完成的東西
計劃不是束縛，是讓你的速度用在對的地方。
Danko Peng
X · YouTube · Threads
👉 回到教程首頁
想直接上手完整的 Cloudflare 全棧模板？
👉 vibefast.app — 早鳥 $99，2026 年 8 月 1 日漲至 $199。