1. 為什麼要先規劃後編碼？
Vibe 編碼時最常見的錯誤之一是沒有計劃就直接開始編碼。結果通常是：
- 特工走錯了方向，必須從頭開始重做
- 程式碼結構不適合規模
- 缺少重要的邊緣情況
- 需要多次迭代（以及令牌/請求）
計劃代理 透過分離階段來解決這個問題 規劃。規劃 和 實施。實施。
2. 規劃代理工作流程
┌─────────────────────────────────────────────────┐
│ PLAN-FIRST WORKFLOW │
├─────────────────────────────────────────────────┤
│ │
│ 1. 📝 USER: Mô tả feature/task │
│ ↓ │
│ 2. 🔍 PLAN AGENT: Phân tích codebase │
│ - Đọc files liên quan │
│ - Hiểu architecture hiện tại │
│ - Hỏi clarifying questions nếu cần │
│ ↓ │
│ 3. 📋 PLAN AGENT: Tạo implementation plan │
│ - Step-by-step tasks │
│ - Files cần tạo/sửa │
│ - Dependencies cần install │
│ - Potential risks/trade-offs │
│ ↓ │
│ 4. 👀 USER: Review + điều chỉnh plan │
│ ↓ │
│ 5. 🚀 HAND OFF: Plan → Agent để implement │
│ │
└─────────────────────────────────────────────────┘
3. 使用計劃代理
步驟1：選擇計劃代理
在聊天視圖中，選擇 “計劃” 從代理下拉清單中。
第 2 步：描述任務
I want to add a real-time notification system to our Express.js app.
Requirements:
- WebSocket-based (Socket.IO)
- Notification types: info, warning, error, success
- Persist notifications in PostgreSQL
- Mark as read/unread
- Bell icon with unread count badge
- Dropdown showing recent notifications
- API endpoints for CRUD operations
- Only authenticated users receive notifications
步驟 3：計劃代理分析並返回計劃
計劃代理將建立一個結構化計劃，例如：
## Implementation Plan: Real-time Notification System
### Phase 1: Database & Models
1. Create `notifications` table migration
- Fields: id, user_id, type, title, message, is_read, created_at
2. Create Notification model (Sequelize/Prisma)
3. Add relations to User model
### Phase 2: Backend API
4. Install socket.io dependency
5. Create NotificationService (create, getByUser, markAsRead, delete)
6. Create NotificationController with REST endpoints
- GET /api/notifications (with pagination)
- PATCH /api/notifications/:id/read
- DELETE /api/notifications/:id
7. Add authentication middleware to notification routes
### Phase 3: WebSocket Integration
8. Setup Socket.IO server alongside Express
9. Implement auth for WebSocket connections (JWT verification)
10. Create room-per-user pattern for targeted notifications
11. Emit events on notification create/update
### Phase 4: Frontend Components
12. Create NotificationBell component (badge with unread count)
13. Create NotificationDropdown component
14. Setup Socket.IO client with auto-reconnect
15. Add toast notifications for new incoming notifications
### Trade-offs & Risks:
- Socket.IO adds complexity; consider SSE for simpler use case
- Need Redis adapter for multi-server deployment
- Consider rate limiting notification creation
第四步：回顧與調整
您可以回覆：
Good plan! But let's make these changes:
- Use Prisma instead of Sequelize
- Add a Phase 0 with unit test setup
- Skip the toast notifications for now
- Add rate limiting in Phase 2
第 5 步：移交給代理
當計劃確定時，選擇 移交給代理。代理將逐步執行計劃，您可以追蹤會話中的進度。
4. 針對不同場景進行規劃
4.1.新功能
Plan adding OAuth2 social login (Google, GitHub) to our Next.js app.
We currently use JWT with email/password auth.
Consider: NextAuth.js vs custom implementation.
4.2.重構
Plan migrating our REST API from Express.js to Fastify.
Current codebase has 15 route files, 8 middleware, Sequelize ORM.
We want zero downtime migration — propose a phased approach.
4.3.錯誤調查
Plan debugging this issue: Users report that their session expires
randomly after 10-15 minutes, even though token expiry is set to 24h.
Analyze our auth flow and create a debugging plan.
4.4.架構決策
Plan the data layer for our e-commerce app. Compare these options:
1. PostgreSQL + Prisma
2. MongoDB + Mongoose
3. PostgreSQL + Drizzle ORM
Consider: our team knows SQL, we need transactions, Vercel deployment.
5. 計劃優先與代碼優先
| 標準 | 計劃優先 | 代碼優先（直接代理） |
|---|---|---|
| 何時使用 | 任務複雜、多檔案、影響架構 | 任務簡單、功能單一、定義明確 |
| 設定時間 | 更長（計劃+回顧） | 快速（立即編碼） |
| 輸出品質 | 更高、更少重做 | 取決於提示質量 |
| 風險 | 低（儘早發現問題） | 更高（可能方向錯誤） |
| 代幣效率 | 更好（更少的迭代） | 可能需要多次迭代 |
經驗法則：
- 任務 < 30 分鐘 → 程式碼優先（直接代理模式）
- 任務 > 30 分鐘或影響許多文件 → 計劃優先
- 遷移或重構 → 永遠計劃第一
6. 有效規劃的技巧
- 提供完整的上下文：技術堆疊、當前約定、限制
- 清楚說明您所知道的權衡：幫助計劃代理人專注於正確的決策
- 請求風險分析：“會出什麼問題嗎？”或“什麼是邊緣情況？”
- 詢問替代方案：在提交之前“比較方法 A 與 B”
- 交接前仔細檢討計劃：編輯計畫比編輯已實施的程式碼更容易
7.練習練習
- 開啟聊天視圖 → 選擇 計劃 代理。代理人
- 提示： “計劃建立一個 Markdown 部落格引擎，其中包括：基於文件的帖子、標籤、類別、搜尋、RSS 提要、深色模式。使用 Next.js 15 和 Tailwind。”
- 從計劃代理處審查計劃
- 至少需要 2 點調整
- 移交給代理實施第一階段
八、總結
計劃代理是“建築師”——它可以幫助您 行動前思考。在本系列中，我們將在第 5 部分中對所有實際項目使用計劃優先方法。
| 工作流程 | 步驟 |
|---|---|
| 計劃優先 | 描述→計畫→審查→調整→移交→實施 |
| 程式碼優先 | 描述→實施→審查→迭代 |
下一首歌曲將是翻唱歌曲 雲端代理和副駕駛 CLI — 如何在任何地方運行代理：本機、後台、雲端以及透過拉取請求。