Vibe Kanban AI 程式設計助理的專屬看板管理系統

開發動機與解決的痛點

在 AI 程式設計助理日益普及的時代，開發者面臨了全新的挑戰。當我們使用 Claude Code、Gemini CLI、Codex 等 AI 助理時，往往需要等待 2-5 分鐘讓它們完成任務，這段時間容易讓人分心或陷入無效的網路瀏覽。

Vibe Kanban 誕生的核心原因：人類工程師的角色已從直接撰寫程式碼轉變為規劃、審查和協調任務。我們需要一個專門的工具來管理多個 AI 助理，並充分利用等待時間進行其他有價值的工作。

主要解決的痛點

同步工作效率低落：等待單一 AI 助理完成任務時，人力資源被浪費
多助理管理困難：缺乏統一介面來協調不同的 AI 程式設計助理
任務狀態追蹤不易：難以即時了解各個 AI 助理的工作進度
配置分散化問題：各個 AI 助理的 MCP 配置缺乏中央管理
程式碼審查流程缺失：需要更好的機制來審查 AI 生成的程式碼

技術框架與設計模式

🎨 前端技術

React 生態系統，提供響應式看板介面

⚡ 後端框架

Rust，高效能系統程式語言，提供極佳的併發性能

🔗 整合機制

GitHub API、檔案系統監控、MCP 協議

🔐 身份驗證

GitHub OAuth 整合

值得學習的設計模式

1. Actor Model Pattern（執行者模式）

// Rust 中的 Actor 模式實作範例（使用 Tokio）
use tokio::sync::{mpsc, oneshot};
use std::collections::HashMap;

// AI 助理執行者訊息類型
enum AgentMessage {
    ExecuteTask {
        task_id: String,
        command: String,
        respond_to: oneshot::Sender<TaskResult>,
    },
    GetStatus {
        respond_to: oneshot::Sender<AgentStatus>,
    },
}

// AI 助理執行者結構
struct AIAgent {
    name: String,
    active_tasks: HashMap<String, TaskHandle>,
    receiver: mpsc::Receiver<AgentMessage>,
}

impl AIAgent {
    async fn run(mut self) {
        while let Some(msg) = self.receiver.recv().await {
            match msg {
                AgentMessage::ExecuteTask { 
                    task_id, 
                    command, 
                    respond_to 
                } => {
                    let result = self.execute_command(command).await;
                    respond_to.send(result).unwrap();
                }
                AgentMessage::GetStatus { respond_to } => {
                    let status = self.get_current_status();
                    respond_to.send(status).unwrap();
                }
            }
        }
    }
}

2. Channel Pattern（通道模式）

// Rust 中的任務佇列實作
use tokio::sync::mpsc;
use serde::{Deserialize, Serialize};

// 任務定義
#[derive(Debug, Clone, Serialize, Deserialize)]
struct Task {
    id: String,
    agent_type: AgentType,
    command: String,
    priority: u8,
    created_at: chrono::DateTime<chrono::Utc>,
}

// 任務管理器
struct TaskManager {
    task_sender: mpsc::UnboundedSender<Task>,
    result_receiver: mpsc::Receiver<TaskResult>,
}

impl TaskManager {
    fn new() -> (Self, mpsc::UnboundedReceiver<Task>) {
        let (task_tx, task_rx) = mpsc::unbounded_channel();
        let (result_tx, result_rx) = mpsc::channel(100);
        
        let manager = TaskManager {
            task_sender: task_tx,
            result_receiver: result_rx,
        };
        
        (manager, task_rx)
    }

    // 提交新任務
    fn submit_task(&self, task: Task) -> Result<(), String> {
        self.task_sender
            .send(task)
            .map_err(|e| format!("Failed to submit task: {}", e))
    }
}

3. Trait Objects Pattern（特徵物件模式）

// 不同 AI 助理的統一介面
use async_trait::async_trait;

// AI 助理通用特徵
#[async_trait]
trait AIAgent: Send + Sync {
    async fn execute_task(
        &self, 
        task: &Task
    ) -> Result<TaskResult, AgentError>;
    
    fn agent_type(&self) -> AgentType;
    fn capabilities(&self) -> Vec<String>;
}

// Claude Code 實作
struct ClaudeCodeAgent {
    api_client: ClaudeClient,
    workspace_path: PathBuf,
}

#[async_trait]
impl AIAgent for ClaudeCodeAgent {
    async fn execute_task(
        &self, 
        task: &Task
    ) -> Result<TaskResult, AgentError> {
        // Claude Code 專屬執行邏輯
        let response = self.api_client
            .send_coding_request(task.command.clone())
            .await?;
        
        Ok(TaskResult {
            task_id: task.id.clone(),
            output: response.generated_code,
            status: TaskStatus::Completed,
            execution_time: response.execution_time,
        })
    }
}

// 代理管理器使用 Trait Objects
struct AgentManager {
    agents: HashMap<AgentType, Box<dyn AIAgent>>,
}

impl AgentManager {
    async fn dispatch_task(
        &self, 
        task: Task
    ) -> Result<TaskResult, String> {
        let agent = self.agents
            .get(&task.agent_type)
            .ok_or("Agent not found")?;
            
        agent.execute_task(&task)
            .await
            .map_err(|e| format!("Task execution failed: {:?}", e))
    }
}

應用情境

🚀 並行開發管理

同時管理多個 AI 助理執行不同的開發任務，如前端介面開發、API 實作、測試程式撰寫等。

🔄 持續整合流程

與 GitHub 整合，自動追蹤提交、合併請求和程式碼審查狀態，實現完整的 CI/CD 工作流。

📊 專案管理協調

為技術領導者提供視覺化介面，統一管理團隊中的人類開發者和 AI 助理的工作分配。

🏢 企業級部署

自架部署解決方案，適合需要資料主權和客製化整合需求的企業環境。

🎯 任務專業化

根據不同 AI 助理的專長分配特定任務，如 Claude Code 負責複雜邏輯、Gemini CLI 處理系統操作。

📈 效能最佳化

透過工作負載分析和任務排程最佳化，提升整體開發團隊的生產力。

軟體架構圖

架構特點說明

高效能後端：Rust 提供記憶體安全和零成本抽象化，確保極佳的併發處理能力

執行者模式：使用 Tokio 非同步執行環境，每個 AI 助理作為獨立執行者運行

類型安全：Rust 的強型別系統在編譯時期就能捕捉潛在錯誤

零複製最佳化：透過借用檢查器避免不必要的記憶體複製，提升整體效能

即時通訊：WebSocket 連線確保前端即時更新任務狀態

快速開始

# 全域安裝並執行
npx vibe-kanban

# 或者開發模式安裝
git clone https://github.com/BloopAI/vibe-kanban.git
cd vibe-kanban
pnpm install
pnpm run dev

# Rust 後端編譯（開發需要）
cargo build --release
cargo run --bin vibe-kanban-server

# 設定環境變數
GITHUB_CLIENT_ID=your_github_client_id
GITHUB_CLIENT_SECRET=your_github_client_secret
DATABASE_URL=sqlite:///./vibe_kanban.db
RUST_LOG=info

設定完成後，開啟瀏覽器造訪 http://localhost:3000 即可開始使用。系統會自動建立範例看板，您可以立即開始管理您的 AI 程式設計助理。

常見問題 Q&A

Q: Claude Code 和 Gemini CLI 可以同時進行程式碼生成或是修改嗎？

A: 是的，這正是 Vibe Kanban 的核心價值之一。

🔄 並行執行的優勢

解決同步等待問題：避免在等待單一 AI 助理完成任務的 2-5 分鐘內分心，可以讓 Claude Code 處理複雜演算法實作的同時，讓 Gemini CLI 執行測試或部署腳本。

任務專業化分工：

Claude Code：擅長複雜邏輯、架構設計、程式碼重構
Gemini CLI：擅長命令列操作、系統整合、快速腳本生成
Codex：擅長程式碼補全、API 文件生成

工作流程最佳化：可以設計並行工作流，例如同時進行用戶認證系統實作、CI/CD 管道設置和 API 文件生成。

⚠️ 需要注意的事項

邏輯衝突仍需注意：雖然 git worktree 消除了檔案層級的衝突，但不同功能之間可能存在邏輯上的不相容性，需要人類開發者判斷和協調。

任務範圍設計：合理設計任務邊界，確保各個 AI 助理的工作範圍相對獨立，減少功能間的交互依賴。

整合測試重要性：各個 worktree 中的功能雖然獨立開發，但整合後的系統行為仍需完整驗證。

Q: 每個 AI 助理在自己的 branch 中修改程式碼，最後誰來負責 merge 這些不同的 branch 修改？

A: 這是 AI 協作開發中的核心挑戰，需要人類開發者作為最終的整合者和決策者。

👨‍💻 人類開發者的關鍵角色

程式碼審查與整合：人類開發者負責審查每個 AI 助理產生的程式碼品質、測試覆蓋率和架構一致性，決定哪些分支可以合併。

衝突解決：當不同分支修改同一檔案或功能時，需要人類判斷如何解決衝突，確保最終程式碼的邏輯完整性。

品質把關：驗證 AI 生成的程式碼是否符合專案標準、安全性要求和效能指標。

🔄 建議的工作流程

# 典型的 AI 協作分支策略
main
├── feature/claude-auth-system     # Claude Code 負責
├── feature/gemini-ci-pipeline     # Gemini CLI 負責
├── feature/codex-api-docs         # Codex 負責
└── integration/human-review       # 人類整合分支

# 工作流程
1. AI 助理在各自分支完成任務
2. 自動測試與程式碼品質檢查
3. 人類開發者審查每個分支
4. 逐步合併到整合分支進行整合測試
5. 最終合併到 main 分支

🛠️ Vibe Kanban 的輔助機制

視覺化管理：看板介面清楚顯示每個分支的狀態、測試結果和審查進度。

自動化檢查：整合 CI/CD 管道，自動執行測試、程式碼品質掃描和安全性檢查。

衝突預警：透過檔案監控功能，提前發現可能的合併衝突並通知開發者。

📋 最佳實務建議：

設計清晰的任務邊界，減少不同 worktree 間的功能依賴
建立完善的整合測試來驗證 AI 生成程式碼的系統相容性
善用 Vibe Kanban 的 diff 檢視功能，仔細審查每個變更
利用自動重新基底功能保持任務分支與主分支同步
合理安排任務合併順序，考慮功能間的邏輯依賴關係

Q: 它有使用 git worktree 功能嗎？

A: 是的！Vibe Kanban 專門為每個任務嘗試建立一個 git worktree，這正是解決並行開發衝突的核心機制。

🌳 Git Worktree 的優勢

隔離的工作環境：每個 AI 助理在獨立的 worktree 中工作，完全避免檔案衝突和交叉污染。

純淨的 AI 上下文：處理 API 功能的助理完全不知道其他 worktree 中的無關錯誤修復，確保專注度和檔案修改的隔離性。

並行執行安全：不同的 AI 助理可以同時修改相同的檔案名稱，但實際上是在不同的 worktree 副本中操作。

🔧 技術實作細節

# Vibe Kanban 的 worktree 策略
main-repo/
├── .git/                          # 主要 Git 目錄
├── worktrees/
│   ├── task-auth-claude/          # Claude Code worktree
│   ├── task-ci-gemini/            # Gemini CLI worktree
│   └── task-docs-codex/           # Codex worktree

# 每個任務建立獨立 worktree
git worktree add worktrees/task-auth-claude feature/auth
git worktree add worktrees/task-ci-gemini feature/ci
git worktree add worktrees/task-docs-codex feature/docs

# AI 助理在各自的 worktree 中工作
cd worktrees/task-auth-claude
claude-code "實作用戶認證系統"

🚀 與 Vibe Coding 生態系統的整合

最佳實務架構：Ghostty + Git Worktree + Claude Code 被認為是當前 vibe coding 的最佳實務技術堆疊。

終端機優先：Claude Code 的終端機導向設計使其能完美整合到 worktree 工作流程中，可以被腳本化、管道化和自動化。

可程式化執行引擎：將 AI 從圖形介面的對話機器人轉變為開發者核心命令循環中的可程式化執行引擎。

⚡ 實際效益：

完全消除檔案衝突的可能性
每個 AI 助理保持純淨的上下文環境
支援真正的並行開發工作流程
簡化合併過程，每個 worktree 對應一個功能分支
提供單一開發者多執行緒開發環境的實作藍圖