197 lines
5.9 KiB
Markdown
197 lines
5.9 KiB
Markdown
|
# Vibe-Kanban 快速開始指南
|
|||
|
|
|
|||
|
|
本指南幫助您快速理解如何使用 Vibe-Kanban 工作流程。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 核心概念
|
|||
|
|
|
|||
|
|
### 什麼是 Vibe-Kanban？
|
|||
|
|
|
|||
|
|
Vibe-Kanban 是一個由 AI 代理協作的軟體開發工作流程系統。每個開發階段都由特定的 AI 代理負責，從需求探索到部署全自動化。
|
|||
|
|
|
|||
|
|
### 核心角色
|
|||
|
|
|
|||
|
|
| 角色 | 負責階段 | AI 技能 |
|
|||
|
|
|------|---------|---------|
|
|||
|
|
| PM (產品經理) | 需求探索、PRD 撰寫 | brainstorming,pm-prd |
|
|||
|
|
| CEO (商業決策) | 商業價值審核 | plan-ceo-review |
|
|||
|
|
| Backend Engineer | API 設計 | be-api-design |
|
|||
|
|
| DBA | 資料庫規劃 | dba-schema |
|
|||
|
|
| UX Designer | 原型設計 | ux-prototype |
|
|||
|
|
| Design Reviewer | 設計審核 | design-review |
|
|||
|
|
| QA Engineer | 測試驗收 | qa |
|
|||
|
|
| OPS (運維) | 部署 | land-and-deploy |
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 使用方式
|
|||
|
|
|
|||
|
|
### 1. 開始新專案
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
/vibe-kanban start "使用者認證功能"
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
系統會自動：
|
|||
|
|
1. 建立專案狀態檔案
|
|||
|
|
2. 觸發 PM 進行需求探索
|
|||
|
|
3. 進入 Brainstorming 階段
|
|||
|
|
|
|||
|
|
### 2. 查看當前狀態
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
/vibe-kanban status
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
輸出範例：
|
|||
|
|
```
|
|||
|
|
╔══════════════════════════════════════════════════════════════╗
|
|||
|
|
║ VIBE-KANBAN 狀態 ║
|
|||
|
|
╠══════════════════════════════════════════════════════════════╣
|
|||
|
|
║ 專案: feature-user-auth ║
|
|||
|
|
║ 當前階段: CEO_REVIEW (CEO 商業價值審核) ║
|
|||
|
|
║ 狀態: IN_PROGRESS ║
|
|||
|
|
║ ║
|
|||
|
|
║ 下一步: 等待 CEO 審核通過 ║
|
|||
|
|
╚══════════════════════════════════════════════════════════════╝
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 3. 前往下一階段
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
/vibe-kanban next
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 4. 退回修改
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
/vibe-kanban back "設計與需求不符，需要重新定義"
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 工作流程總覽
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
┌─────────┐ ┌──────────┐ ┌─────────┐ ┌───────────┐
|
|||
|
|
│Brainstorm│ ──▶│CEO Review│ ──▶│ PRD │ ──▶│ API Design │
|
|||
|
|
└─────────┘ └──────────┘ └─────────┘ └───────────┘
|
|||
|
|
│
|
|||
|
|
▼
|
|||
|
|
┌─────────┐ ┌──────────┐ ┌──────────┐ ┌───────────┐
|
|||
|
|
│ Deploy │ ◀──│PR Review │◀───│ QA │◀───│DB Schema │
|
|||
|
|
└─────────┘ └──────────┘ └──────────┘ └───────────┘
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 各階段產出
|
|||
|
|
|
|||
|
|
### 階段 1-2: 需求探索
|
|||
|
|
- **產出**: `docs/brainstorm/{date}-{feature}.md`
|
|||
|
|
- **內容**: 需求分析、使用者故事、技術方案
|
|||
|
|
|
|||
|
|
### 階段 3: PRD 撰寫
|
|||
|
|
- **產出**: `docs/prd/{date}-{feature}.md`
|
|||
|
|
- **內容**: 功能性需求、非功能性需求、驗收標準
|
|||
|
|
|
|||
|
|
### 階段 4: API 設計
|
|||
|
|
- **產出**: `docs/api/{date}-{feature}.yaml`
|
|||
|
|
- **內容**: OpenAPI 3.0 規格文件
|
|||
|
|
|
|||
|
|
### 階段 5: 資料庫規劃
|
|||
|
|
- **產出**: `docs/db/{date}-{feature}.sql`
|
|||
|
|
- **內容**: 資料表定義、索引、遷移計畫
|
|||
|
|
|
|||
|
|
### 階段 6: UX 原型
|
|||
|
|
- **產出**: `docs/design/{date}-{feature}/`
|
|||
|
|
- **內容**: 使用者流程、線框圖、原型連結
|
|||
|
|
|
|||
|
|
### 階段 7: 設計審核
|
|||
|
|
- **產出**: `docs/design/{date}-{feature}/review-report.md`
|
|||
|
|
- **內容**: 審核報告、修改建議
|
|||
|
|
|
|||
|
|
### 階段 8: 任務拆分
|
|||
|
|
- **產出**: `.gstack/kanban/{project}/tasks.md`
|
|||
|
|
- **內容**: 前後端任務分配
|
|||
|
|
|
|||
|
|
### 階段 9: 實作
|
|||
|
|
- **產出**: 程式碼
|
|||
|
|
- **內容**: 功能實作、單元測試
|
|||
|
|
|
|||
|
|
### 階段 10: QA 測試
|
|||
|
|
- **產出**: `.gstack/qa-reports/qa-report-{date}.md`
|
|||
|
|
- **內容**: 測試報告、Bug 列表
|
|||
|
|
|
|||
|
|
### 階段 11: PR 審核
|
|||
|
|
- **產出**: PR 描述、審核報告
|
|||
|
|
- **內容**: 代碼變更說明
|
|||
|
|
|
|||
|
|
### 階段 12: 部署
|
|||
|
|
- **產出**: `.gstack/deploy-reports/deploy-report-{date}.md`
|
|||
|
|
- **內容**: 部署日誌、驗證結果
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
常見問題
|
|||
|
|
|
|||
|
|
### Q: 如果某個階段的產出不滿意怎麼辦？
|
|||
|
|
|
|||
|
|
A: 使用 `/vibe-kanban back "原因"` 退回到上一階段重新處理。
|
|||
|
|
|
|||
|
|
### Q: 可以跳過某些階段嗎？
|
|||
|
|
|
|||
|
|
A: 使用 `/vibe-kanban skip`，但需要確認跳過的原因和風險。
|
|||
|
|
|
|||
|
|
### Q: 如何查看歷史記錄？
|
|||
|
|
|
|||
|
|
A: 查看 `.gstack/kanban/{project}/` 目錄下的 `state.yaml` 檔案。
|
|||
|
|
|
|||
|
|
### Q: 多人協作時如何同步狀態？
|
|||
|
|
|
|||
|
|
A: 將 `.gstack/kanban/` 目錄加入版本控制，團隊成員可以共享狀態。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 最佳實踐
|
|||
|
|
|
|||
|
|
1. **每個階段都應該產出文件** - 確保可追溯性
|
|||
|
|
2. **及時退回修改** - 發現問題立即退回，不要累積技術債
|
|||
|
|
3. **QA 前確保驗收標準完整** - 測試案例來自驗收標準
|
|||
|
|
4. **部署前確認所有測試通過** - 自動化測試是門檻
|
|||
|
|
5. **保存所有產出文件** - 方便日後參考和審計
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 故障排除
|
|||
|
|
|
|||
|
|
### 問題: 狀態檔案損壞
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
# 重置狀態檔案
|
|||
|
|
rm .gstack/kanban/{project}/state.yaml
|
|||
|
|
/vibe-kanban start "{project-name}"
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 問題: 階段卡住無法前進
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
# 強制前往下一階段
|
|||
|
|
/vibe-kanban next --force
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 問題: 需要回到特定階段
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
# 跳轉到特定階段
|
|||
|
|
/vibe-kanban goto PRD
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 下一步
|
|||
|
|
|
|||
|
|
1. 查看 [VIBE_KANBAN_PLAN.md](VIBE_KANBAN_PLAN.md) 了解詳細設計
|
|||
|
|
2. 查看 [IMPLEMENTATION_CHECKLIST.md](IMPLEMENTATION_CHECKLIST.md) 了解實施步驟
|
|||
|
|
3. 開始使用 `/vibe-kanban start "您的功能名稱"`
|