📌 项目地址：BloopAI/vibe-kanban | ⭐ 26,579 颗星 | 🔧 Rust | 📜 Apache-2.0
Vibe Kanban 在 GitHub 拿了 26579 颗星，然后 2025 年宣布停止维护。README 第一行写着“Vibe Kanban is sunsetting”。我读了这个项目的源码和文档，它解决的问题很具体，但最终被自己支撑的复杂性压垮。这篇分析不说空话，只讲事实和工程判断。
一条命令启动 AI 代理工作流
执行 npx vibe-kanban 后，本地启动一个服务，浏览器里出现看板页面。流程是固定的：
- 在看板上创建 Issue，拖拽到执行状态
- 选一个编码代理（支持 10+ 种，列表见官网）
- 代理被放进一个 Workspace，每个 Workspace 有自己的 Git 分支、终端进程、开发服务器
- 代理改代码后，UI 实时显示 diff，你可以在 diff 行写注释，代理根据注释再改
- 改完自动生成 PR 描述，跳转到 GitHub 合并
整个链条是 Issue → Workspace → Diff → PR。每个步骤都有对应 UI，不需要切换窗口。README 原话：“Plan with kanban issues — create, prioritise, and assign issues on a kanban board”和“Review diffs and leave inline comments — send feedback directly to the agent”。
Workspace 隔离：最实在的技术设计
每个 Workspace 对应三样东西：
- 一个独立 Git 分支：隔离代码修改
- 一个终端进程：隔离代理输出和错误日志
- 一个开发服务器：使用随机端口，避免端口冲突
多个代理跑同一个 Issue 的不同方案时，互不干扰。Rust 后端用 std::process::Command 启动子进程，通过 WebSocket 推送终端输出（这个细节我推测的，README 没详细描述）。分支创建和服务器端口分配都是自动的。
这种设计可以拿来复用：任何需要并行跑 AI 代理的场景，不限于看板。把每个代理的执行环境隔离成一个独立沙箱，相当于把“写代码”的动作标准化成一个可控进程。
为什么停更：IDE 内置代理和适配层维护成本
项目没有给出停更的具体原因。从产品逻辑和工程角度，我判断有两点。
第一，IDE 生态挤压独立看板。 VS Code 的 Copilot、Cursor 等工具把代理直接嵌在编辑器里。工程师在写代码的界面就能调用代理，不需要单独开一个看板页面。独立看板的价值被压缩到“多代理管理”和“流程可视化”上，大众市场已经被 IDE 吃掉。
第二，适配层维护成本太高。 Vibe Kanban 支持 10+ 种代理：Claude Code、Codex、Gemini CLI、Copilot、Amp、Cursor、OpenCode、Droid、CCR、Qwen Code。每个代理的调用方式、参数、配置文件都在快速迭代。项目停更后，这些适配全部冻结。如果某个代理改了命令行参数，你需要自己去改 Rust 源码里的调用逻辑。理想设计是把适配层做成可插拔的：抽象出一个 Agent Trait，每个代理一个独立模块，通过 JSON 配置文件注册。但项目没有这么做，所有适配写死在 Rust 代码里。
这是一个典型的“平台化过度”陷阱——为了支持所有主流代理，团队投入大量精力做适配，但每个代理都在变，维护工作像吹气球一样膨胀。一旦项目停止更新，这些适配立刻变成技术负债。
现在还能用吗：能用，但需要自己维护
启动命令就一行：
npx vibe-kanban前提是你已经认证了想用的编码代理。支持的代理列表在官网 https://vibekanban.com/docs/supported-coding-agents。
本地开发依赖：
- Rust（latest stable）
- Node.js（>=20）
- pnpm（>=8）
安装开发工具：
cargo install cargo-watch
cargo install sqlx-cli安装依赖和启动：
pnpm i
pnpm run dev这会启动后端和 web 应用，数据库用 SQLite，初始数据从 dev_assets_seed 文件夹复制。
构建 web 应用：
cd packages/local-web
pnpm run build团队协作需要自托管。README 提供的指南：https://vibekanban.com/docs/self-hosting/deploy-docker。自托管需要自己配置数据库和认证。
如果长期用，建议 fork 项目自己维护代理适配层，或者手动模仿工作流：为每个 Issue 建 Git 分支，用 claude code 或 codex 命令行执行，手动检查 diff。缺看板，但稳定性高。
对做类似项目的人：四个可借鉴的点
26579 星证明“看板 + AI 代理”这个需求真实存在。但如果你要做类似的工具，有四个坑值得避开。
第一，代理适配层必须可插拔。 每个代理一个独立模块，通过配置文件注册。添加新代理不修改核心代码。Vibe Kanban 的 Rust 后端把适配逻辑写死在代码里，导致停更后适配全部失效。
第二，服务端与本地脚本分离。 Vibe Kanban 把整个后端逻辑放在 Rust 二进制里，本地启动。要支持团队协作，需要用云服务。虽然项目提供了 Docker 自托管，但团队规模越大，维护越重。
第三，流程要可配置。 不是每个团队都想要“Issue → Workspace → Diff → PR”这四步。有的团队只需要 Workspace + Diff，有的想加审批流。Vibe Kanban 的流程是固定的，不能调整。
第四，考虑与 IDE 的融合。 独立 UI 在 IDE 生态挤压下生存空间很小。最好把看板功能做成 IDE 插件或 WebView，而不是独立浏览器应用。
Vibe Kanban 是一个过渡产品。它留下的 Workspace 隔离思路和流程标准化方法，比项目本身更有价值。停更不代表它的设计没有参考意义。