opencode-workflow/design-idea/QUICK_START_GUIDE.md

197 lines
5.9 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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 "您的功能名稱"`