yupi-translate-app[bot]
16 KiB
Vibe Coding 專案開發流程
從想法到產品的完整 Vibe Coding 工作流
你好，我是魚皮。
在快速上手階段，我們已經做過一個簡單的網頁應用了。那個專案很簡單，直接和 AI 對話就能做出來。但現在，讓我們來解決一個更實際的問題：如果要做一個完整的、商業級的專案，應該怎麼做？
很多同學剛開始用 AI 做專案時，都會犯同一個錯誤：打開 AI 編程工具後，直接就開始和 AI 聊天，讓它生成程式碼。對於小專案來說，這樣做是沒問題的。但如果你想做一個完整的商業級專案，這樣就會出問題。一開始可能還挺順利，但很快就會發現 AI 生成的程式碼越來越亂，完全不是自己想要的。改來改去、左右腦互搏，最後不得不推倒重來，浪費了大量時間。
這是為什麼呢？因為你跳過了最重要的一步 —— 規劃。
在 Vibe Coding 時代，雖然 AI 可以幫你寫程式碼，但好的規劃依然是專案成功的關鍵。甚至可以說，規劃比以前更重要了。
下面我就來分享一套經過驗證的 5 步開發流程，幫你避開這些坑。
為什麼需要標準流程？
在傳統編程中，如果你對專案規劃不清楚，最多就是寫出來的程式碼質量不高，但至少你知道自己在寫什麼。
但在 Vibe Coding 中，情況就完全不同了。如果你對專案規劃不清楚，AI 就會 「自由發揮」，生成一堆你看不懂、也不需要程式碼。
AI 不是魔法，它只是一個非常強大的執行者。你告訴它做什麼，它就做什麼。如果你自己都不知道要做什麼，AI 自然也無法幫你做出理想的產品。
所以，一套清晰的開發流程，可以幫助你：
- 明確專案目標和需求
- 讓 AI 理解你的意圖
- 避免專案失控
- 提高開發效率
- 做出真正有用的產品
完整的 5 步工作流
這套流程是我在實踐中總結出來的，也參考了很多優秀開發者的經驗。
它包括 5 個步驟：
- 需求研究（Research）
- 產品需求文件（PRD）
- 技術設計文件（Tech Design）
- AI 代理指令（AGENTS.md）
- 實現和迭代（Build）
看起來好像很複雜？別擔心，我會用最簡單的方式 「餵飯」 給你。
步驟一、需求研究（Research）
了解完整流程後，讓我們從第一步開始，詳細講解每個步驟該怎麼做。
在動手之前，先搞清楚：我到底要做什麼？為什麼要做？有沒有人做過類似的東西？
很多同學會跳過這一步，直接開始寫需求文件。但我的經驗是，花 30 分鐘做調研，可以避免走很多彎路。
具體怎麼做？
1）明確你的目標
先問自己幾個問題：我想解決什麼問題？這個問題真的值得解決嗎？我希望做出來的東西是什麼樣的？
比如你想做一個記賬應用，那就要想清楚：是給自己用還是給別人用？主要記錄哪些類型的賬目？需要哪些核心功能？
2）調研類似產品
去看看市面上有沒有類似的產品，它們是怎麼做的？有什麼優點和缺點？
你可以搜索相關的應用或網站，看看別人的開源專案，或者直接問 AI：「有哪些好用的記賬應用？它們有什麼特點？」
這一步很重要，可以幫你避免重複造輪子，也能給你提供靈感和參考。
3）記錄你的發現
把你的想法和調研結果記錄下來，可以用一個簡單的文件，比如 RESEARCH.md。這個文件不需要很正式，就像寫日記一樣，記錄你的想法和發現就行。
舉個例子，假設你想做一個記賬應用。你先調研了市面上的幾款記賬應用，發現它們功能都太複雜了，你只需要一個簡單的工具。然後你記錄下自己的想法，RESEARCH.md 可能是這樣的：
# 記賬應用需求研究
## 目標
做一個簡單易用的個人記賬應用，幫助自己養成記賬習慣。
## 調研發現
- 市面上的記賬應用功能都太複雜了
- 我只需要快速記錄收入和支出
- 最好能看到每月的統計數據
## 核心需求
1. 快速添加收支記錄
2. 按日期查看記錄
3. 查看月度統計
4. 數據本地存儲
步驟二、產品需求文件（PRD）
完成需求研究後，你應該對要做的東西有了清晰的認識。接下來，我們要把這些想法整理成一份正式的文件。明確要做哪些功能，不做哪些功能。
這是整個流程中最重要的一步，一份好的 PRD 可以讓 AI 準確理解你的意圖，生成高質量的程式碼。
怎麼寫出高質量的 PRD？
我的建議是，先自己寫一個簡單的需求描述，然後讓 AI 幫你擴展成完整的 PRD。
比如，你可以先寫：
我要做一個記賬應用，能快速記錄收支，查看每月統計。
要簡單易用，不要複雜的功能。
然後把這段話發給 AI 大模型，比如 Gemini 或 DeepSeek：
請幫我把這個需求擴展成完整的產品需求文件（PRD），
要包含：
1. 產品概述和目標用戶
2. 詳細的功能列表
3. 功能優先級（MVP 和後續版本）
4. 界面設計要求
5. 技術棧建議
6. 非功能性需求（性能、安全等）
AI 會幫你生成一份結構化的 PRD，然後你再根據自己的需求修改和完善。
PRD 應該包含什麼？
一份完整的 PRD 通常包含：
- 產品概述（簡單介紹這個產品是什麼）
- 目標用戶（誰會用這個產品）
- 核心功能（列出所有要做的功能）
- 功能優先級（哪些是必須做的，哪些是可以後續添加的）
- 界面設計（簡單描述界面應該是什麼樣的）
- 技術棧建議
- 程式碼風格和架構模式
- 限制條件和邊界場景
舉個例子：
# 記賬應用 PRD
## 產品概述
一個簡單的個人記賬應用，幫助用戶快速記錄日常收支。
## 目標用戶
需要記賬但不想用複雜應用的個人用戶。
## 核心功能
### 必須做（MVP）
1. 添加收支記錄
- 輸入金額
- 選擇類型（收入/支出）
- 選擇分類（餐飲、交通、工資等）
- 添加備註（可選）
- 選擇日期
2. 查看記錄列表
- 按日期倒序顯示
- 顯示金額、類型、分類、備註
- 可以刪除記錄
3. 月度統計
- 顯示當月總收入
- 顯示當月總支出
- 顯示當月結餘
### 後續可以做
- 數據導出
- 圖表展示
- 預算設置
- 多賬戶管理
## 界面設計
- 首頁：顯示記錄列表和添加按鈕
- 添加頁面：表單輸入
- 統計頁面：展示月度數據
步驟三、技術設計文件（Tech Design）
有了清晰的 PRD 後，我們就知道要做什麼了。
下一步，就是確定用什麼技術來實現這些功能，以及大致的技術架構。
創建一個 TECH_DESIGN.md 文件，包含：
- 技術棧選擇（前端用什麼、後端用什麼、數據庫用什麼）
- 專案結構（程式碼怎麼組織）
- 數據模型（需要存儲哪些數據）
- 關鍵技術點（有哪些技術難點需要注意）
還是以記賬應用為例。根據 PRD 中的需求，你決定用 React 來做前端，因為它生態成熟、AI 支持好。數據存儲用 LocalStorage 就夠了，因為是個人工具，不需要後端。技術設計文件可能是這樣的：
# 記賬應用技術設計
## 技術棧
- 前端：React + TypeScript + Vite
- 樣式：Tailwind CSS
- 數據存儲：LocalStorage
- 部署：Vercel
## 專案結構
src/
components/ # 組件
pages/ # 頁面
hooks/ # 自定義 Hooks
utils/ # 工具函數
types/ # 類型定義
## 數據模型
### Transaction（交易記錄）
- id: string
- amount: number
- type: 'income' | 'expense'
- category: string
- note: string
- date: string
## 關鍵技術點
1. 使用 LocalStorage 存儲數據
2. 使用 React Hooks 管理狀態
3. 使用日期庫處理日期（date-fns）
如果你不熟悉技術選型，可以問 AI：「我要做一個記賬應用，應該用什麼技術棧？」
AI 會給你推薦合適的技術。
步驟四、AI 代理指令（AGENTS.md）
PRD 和技術設計都準備好了，現在我們要創建一個專門給 AI 看的指令文件，告訴 AI 在這個專案中應該遵循什麼規則。
這個文件你可以隨便取名，比如 AI_RULES.md、INSTRUCTIONS.md 等。但我推薦使用 AGENTS.md 這個名稱，因為這是一個新興的社區標準。
AGENTS.md 是一個標準化的文件格式，用來指導 AI 編程工具如何工作。它就像是給 AI 的 「工作手冊」。這個標準由 OpenAI、Anthropic、Google 等公司共同推動，目前已經有超過 8 萬個開源專案在使用。主流的 AI 編程工具，比如 Cursor、Windsurf、Claude Code、Gemini CLI、GitHub Copilot 等都支持自動讀取 AGENTS.md 文件。
那 AGENTS.md 應該包含什麼內容呢？
一般包含專案概述、開發規範、測試要求、程式碼風格、注意事項等。
繼續用記賬應用來舉例。根據前面的 PRD 和技術設計，你可以創建這樣一個 AGENTS.md 文件：
# 記賬應用 AI 開發指令
## 專案概述
這是一個簡單的個人記賬應用，使用 React + TypeScript 開發。
## 開發規範
- 使用 TypeScript，確保類型安全
- 組件使用函數式組件 + Hooks
- 使用 Tailwind CSS 編寫樣式
- 所有數據存儲在 LocalStorage
## 程式碼風格
- 使用 ESLint 和 Prettier
- 組件名使用 PascalCase
- 函數名使用 camelCase
- 常量使用 UPPER_SNAKE_CASE
## 測試要求
- 每個功能完成後手動測試
- 確保數據正確存儲和讀取
- 測試各種邊界情況
## 注意事項
- 保持程式碼簡潔，避免過度設計
- 優先實現核心功能
- 確保移動端適配
有了這個文件，AI 就知道在這個專案中應該遵循什麼規則，生成的程式碼會更加規範和一致。
步驟五、實現和迭代（Build）
前面 4 步都是準備工作，現在終於可以開始寫程式碼了！
但不是一口氣寫完，而是小步迭代。
分步迭代策略
對於複雜的專案，想一步到位是不現實的。我推薦採用 3 步走的策略：
1、生成基礎框架
先讓 AI 生成基礎專案框架，暫時不管功能好不好用，確保能夠運行專案即可。
請根據 PRD.md、TECH_DESIGN.md 和 AGENTS.md 的要求，
初始化專案並創建基本的專案結構，包括：
1. 安裝必要的依賴
2. 創建目錄結構
3. 配置開發環境
4. 創建基礎的路由和頁面框架
確保專案能夠正常啟動。
對於有編程基礎的同學，其實有更簡單的方法。你可以使用腳手架或者專案模板來快速生成基礎框架。
腳手架就像是一個自動化工具，幫你生成專案的基本結構和配置文件，比如 create-react-app、create-vite 等。
專案模板則是一個預先配置好的專案示例，你可以直接複製使用。
使用這些工具，幾分鐘就能搭好基礎框架，不需要從零開始。
2、逐步實現核心功能
框架搭好後，就可以開始實現具體功能了。這一步的關鍵是 先跑通核心業務流程、實現核心功能，而不是一開始就追求完美。建議把專案拆分成多個小功能，一個一個來實現。
比如記賬應用可以這樣拆分：
- 實現數據模型和存儲
- 實現添加記錄功能
- 實現記錄列表顯示
- 實現刪除功能
- 實現月度統計
對於每個功能，你可以這樣和 AI 對話：
我要實現添加記錄功能，請根據 PRD.md 和 TECH_DESIGN.md 中的要求，
創建一個 AddTransaction 組件，包含表單輸入和提交功能。
每完成一個功能，就測試一下：功能是否正常工作？有沒有 Bug？界面是否符合預期？
如果有問題，就繼續和 AI 對話，讓它修改。
3、優化實現細節
核心功能都實現後，就可以打磨細節了。在 保證不影響功能的前提下，優化性能、改進用戶體驗、美化界面等。
打磨完細節後，你的 MVP 最小可行產品就完成了。之後就可以根據用戶反饋和自己的想法，擴展更多功能了。
另外，跑通核心功能後，強烈建議用 Git 來管理程式碼。每完成一個功能就提交一次，這樣即使後面出問題，也能快速回退。
如果你還不會 Git，可以看看 魚皮的 Git 學習路線，很快就能上手。
避免 AI 失控的關鍵技巧
在實際開發中，你可能會遇到這些問題：
- AI 輸出的內容驢頭不對馬嘴
- 成了一個新功能後原來的功能就不能用了
- 改了一個 Bug 又來 3 個 Bug
這些問題很常見，但都有解決辦法。
1、專案模塊化
由於 AI 的上下文是有限的，隨著專案信息量不斷增大，它可能忘記之前的信息，導致生成的程式碼錯誤。所以我們要把專案的功能盡可能隔離出來，把一個大專案分割成多個小模塊。
舉個例子，開發一個電商系統，可以把商品管理模塊獨立出來。當需要 AI 生成添加商品功能的程式碼時，只需要提供商品表的字段設計、添加商品的業務邏輯規則，不需要把支付結算、用戶會員等關聯不大的功能作為上下文提供給 AI。
2、限定修改範圍
AI 生成的程式碼沒有那麼可控，經常改 A 功能的同時把 B 功能也順帶修改了。這個問題很好解決，只要在提示詞中限定修改範圍即可：
僅修改 components/AddTransaction.tsx 文件：
1. 添加表單驗證功能
2. 保持現有的樣式和佈局
3. 不要改動其他文件
3、抽象和複用
假如我們要讓 AI 生成 2 個佈局一模一樣的頁面，它有時會很死板，生成完頁面 A 之後，複製一遍頁面 A 的程式碼來生成頁面 B。這樣非常不利於大專案的維護，以後 AI 改了頁面 A，說不定頁面 B 就忘了改。所以我們需要主動告訴 AI：
請幫我抽象這個頁面為可複用的組件，
讓其他頁面可以通過傳入不同的參數來使用。
這樣也能減少整個專案的程式碼量，減輕 AI 上下文記憶的負擔，讓生成結果更準確。
4、版本控制
強烈建議使用 Git 版本控制工具。每正確生成一個功能後都提交一次版本，在每次 AI 生成新程式碼之後人工對比一下改動的文件，出了問題也能快速還原到之前的版本，防止程式碼丟失。
每完成一個功能後，提交程式碼：
git add .
git commit -m "實現添加記錄功能"
Cursor 自帶了 Git 對比功能，可以很方便地查看程式碼變化。
5、人工控制
AI 有時會因缺乏關鍵上下文信息、或者自身能力的不足而陷入循環。比如改來改去總是出現同樣的錯誤，或者一直在做無用功。這時就有必要人工介入了。
可以嘗試手動指定上下文、更換 Prompt 換個角度描述問題、清空對話歷史重新開始，甚至手動修改部分程式碼給 AI 一個正確的方向。
這時候，學編程的好處就體現出來了。如果你有一些編程基礎，就能更好地對 Vibe Coding 進行把控和干預。你能看懂 AI 生成的程式碼，知道哪裡出了問題，能夠手動修正關鍵部分，引導 AI 往正確的方向走。這也是為什麼我建議大家在學習 Vibe Coding 的同時，也要了解一些編程基礎知識。
6、多元 AI 協作
不同 AI 大模型擅長不同任務。如果單一大模型無法正常工作，可以利用其他大模型生成 「教 AI 做事的方法和指令」。
比如，你在 Cursor 中使用 GPT 生成的程式碼有問題，你可以：
- 把程式碼和錯誤信息複製給 Claude 或 Gemini
- 讓它分析問題並給出修改建議
- 把修改建議再告訴 GPT，讓它修改程式碼
這種多模型協作的方式，可以大大增加解決問題的可能性。
反面教材 - 需求不清導致專案翻車
在這套 Vibe Coding 教程的專案實戰板塊，我會分享大量的成功專案案例，大家之後可以挑感興趣的學習。這裡我只舉一個反面