超越 Vibe Coding —— AI 輔助程式設計指南
你好，我是[冴羽](https://link.juejin.cn?target=https%3A%2F%2Fyayujs.com)。用 AI 寫程式，70% 的功能 5 分鐘就能搞定，但剩下的 30% 能讓你崩潰一整天。
我專門研究了 Google 工程師 Addy Osmani 寫的《Beyond Vibe Coding》。
他用 25 年的開發經驗告訴你：
- Vibe Coding（氛圍編碼）：70% 進度 5 分鐘，剩下 30% 要 3 天
- AI-Assisted Engineering（AI 輔助工程）：從原型到生產環境，全流程可控
兩種方式的差距，就是「能跑的 Demo」和「能上線的產品」的差距。
-
什麼是 Vibe Coding?
1.1. 定義
Vibe Coding 是一種「隨性」的開發方式：
你給 AI 一個模糊的需求，它給你一堆程式碼，你看都不看直接執行，關注的是整體「感覺」而不是實作細節。
特斯拉前 AI 總監 Andrej Karpathy 描述過這種未來：「我只是看看東西、說說話、跑跑程式碼、複製貼上，然後它就能工作了。」
聽起來很美好對吧？
1.2. 70% 問題
但現實是：Vibe Coding 能讓你快速達到 70%，剩下 30% 會讓你懷疑人生。
具體表現：
- 兩步前進，三步後退：修一個 Bug，冒出三個新 Bug
- 隱藏成本：沒有工程知識，程式碼根本沒法維護
- 邊際遞減：AI 工具對有經驗的開發者幫助更大，新手反而更容易踩坑
- 安全漏洞：「Vibe Coding 很爽，直到你開始洩露資料庫密碼」
但這並不是說： Vibe Coding == 低品質程式碼。
它只是一種特定的開發方式，對於生產系統，你需要考慮的遠不只「能跑」。
-
AI 程式設計 4 大坑
2.1. 坑 1：一上來就讓 AI 寫程式
plaintext 體驗AI代碼助手 代碼解讀複製代碼❌ 錯誤示範：「幫我做一個 Todo 應用」
✅ 正確示範：「給我幾個 Todo 應用的架構方案，從最簡單的開始。
先別寫程式碼，只列出思路，讓我選一個方向。」
🚀 最佳實踐：寫一個 mini PRD —— 定義問題、使用者旅程、預期結果這是因為 AI 十之八九會提出一個過於複雜的方案。你要先讓它規劃，再讓它實作。
目前很多 AI 程式設計工具都支援「Plan Mode（規劃模式）」:
- Cline：先生成計畫，再執行
- Bolt：支援「Enhance Prompt」，把粗糙的想法變成結構化的需求
2.2. 坑 2：不提供文件就讓 AI 寫程式
- 檢查知識門檻
很多模型只知道 Tailwind v3，但 v4 其實在 2025 年就發布了。
- 附上相關檔案
當你用特定的 API 或框架時，把官方文件餵給 AI。
- 設定全域規則：
markdown 體驗AI代碼助手 代碼解讀複製代碼始終遵循這些原則:
1. 先定義資料模型，再寫程式碼
2. 用 Mock 資料，別一上來就搞資料庫
3. 建立元件庫，把程式碼拆分到多個檔案
4. 集中管理狀態
5. 分批實作，別一次寫太多
6. 改程式碼前確認改的是正確的檔案
7. 需求不清楚就問對應英文版：
markdown 體驗AI代碼助手 代碼解讀複製代碼// Example system prompt
Always follow these guidelines:
1. Define the data model before writing code
2. Start with mock data instead of a database
3. Create a component library and split code into multiple files
4. Centralize state management
5. Batch implementation into smaller chunks
6. Double-check you're changing the correct files
7. Ask follow-up questions if requirements are unclear2.3. 坑 3：純文字描述 UI
一張圖勝過千言萬語。 當你讓 AI 實作設計或修 Bug 時，直接截圖。
現在的 AI 程式設計工具都支援：
- 從 Figma 匯入設計：無縫整合設計和程式碼
- 把圖片加入提示詞：讓 AI 理解視覺上下文
- 引入即時瀏覽器截圖：即時擷取頁面狀態
2.4. 坑 4：懶得測試
不管你多麼小心，AI 總會在某個時刻破壞你的應用程式。
所以：
- 每次更新後都在 localhost 測試
- 打開瀏覽器主控台檢查錯誤
- 小步測試才能避免噩夢般的 Debug 過程
-
Prompt 工程 5 條原則
3.1. 提供足夠的上下文
永遠假設 AI 對你的專案一無所知。
markdown 體驗AI代碼助手 代碼解讀複製代碼❌ 錯誤："為什麼我的程式碼不工作?"
✅ 正確："這個 React hooks 函式應該在表單提交時更新使用者資料，
但現在報錯'Cannot read property name of undefined'。
程式碼如下:
const updateProfile = (userData) => {
setUser(userData.name);
};
錯誤發生在第 2 行。使用 React 18.2.0。"3.2. 明確你的目標
模糊的問題會得到模糊的答案。要具體說明：
- 預期行為是什麼
- 目前（錯誤的）行為是什麼
- 相關的限制或要求
- 期望的輸出格式
3.3. 拆解複雜任務
把大問題分成小塊，逐步推進。
舉個例子：建構使用者驗證系統
- 首先：「設計使用者驗證的資料庫 schema」
- 然後：「建立使用者註冊介面」
- 接著：「實作密碼雜湊和驗證」
- 最後：「新增 JWT token 生成和驗證」
3.4. 提供輸入輸出範例
用具體例子來減少歧義。
markdown 體驗AI代碼助手 代碼解讀複製代碼建立一個格式化貨幣的函式。
範例:
- formatCurrency(2.5) 應該返回 "$2.50"
- formatCurrency(1000) 應該返回 "$1,000.00"
- formatCurrency(0.99) 應該返回 "$0.99"3.5. 使用角色和人設
讓 AI 「扮演」特定角色能改變回答的風格和深度。
有效的人設：
- 資深 React 開發者：「作為一個資深 React 開發者，review 我的程式碼找潛在 Bug」
- 效能專家：「你是 JavaScript 效能專家，優化下面這個函式」
- 程式碼審查員：「以安全專家的角度 review 這段程式碼」
-
生產程式碼 4 條原則
4.1. 始終 Review AI 生成的程式碼
把 AI 生成的程式碼當作初級開發者寫的程式碼。 需要仔細 review 和測試才能提交。
列出檢查清單：
- ✅ 安全漏洞
- ✅ 錯誤處理
- ✅ 效能影響
- ✅ 可維護性標準
4.2. 有完整的測試策略
AI 可以幫你生成測試，但你必須驗證覆蓋率和品質。
markdown 體驗AI代碼助手 代碼解讀複製代碼"為這個使用者驗證函式生成完整的單元測試。包括：
- 有效憑證
- 無效憑證
- 網路錯誤
- 畸形輸入
- 邊界情況如空字串
- 安全場景如 SQL 注入嘗試
使用 Jest，遵循我們在 /tests/auth/ 的現有測試模式"4.3. 安全優先
AI 可能引入安全漏洞。始終驗證安全實踐。
列出安全驗證清單：
- ✅ 輸入驗證和清理
- ✅ 驗證和授權
- ✅ SQL 注入防護
- ✅ XSS 防護
- ✅ 敏感資料處理
- ✅ API key 和憑證管理
- ✅ HTTPS 和安全通訊
4.4. 效能和可擴展性
AI 可能生成能用但低效的程式碼。始終考慮效能。
markdown 體驗AI代碼助手 代碼解讀複製代碼"優化這個資料庫查詢，表有 100 萬+記錄。考慮：
- 合適的索引策略
- 查詢執行計畫
- 記憶體使用
- 連線池
- 快取機會
解釋你的優化選擇，包括優化前後的效能對比。"-
未來 AI 輔助開發的完整工作流
想像一下這樣的開發體驗：
🎯 意圖定義 → 用自然語言描述你想建構什麼，AI 理解上下文、需求和限制
📋 智慧規劃 → AI 生成詳細的技術方案，考慮架構決策，建議最優實作策略
🏗️ 自主實作 → AI agent 跨多個檔案實作功能，處理整合，生成完整測試
🔍 智慧 Review → AI 提供詳細的程式碼審查、安全分析和效能優化建議
🚀 自動部署 → AI 管理部署流程，監控效能，提供優化建議
這其實都不算是未來了，而是現在已經在跑的東西。
我是冴羽，10 年筆耕不輟，專注前端領域，更新了 10+ 系列、300+ 篇原創技術文章，翻譯過 Svelte、Solid.js、TypeScript 文件，著有小冊《Next.js 開發指南》、《Svelte 開發指南》、《Astro 實戰指南》。
歡迎圍觀我的「網頁版朋友圈」，關注我的公眾號：冴羽（或搜尋 yayujs），每天分享前端知識、AI 乾貨。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
