同样是给 AI 编程做看板，auto-coder.chat 和 Vibe Kanban 走的是两条路

2026 年 4 月，AI 编程社区里突然冒出来两个长得很像的东西。

一个是国外的 Vibe Kanban——BloopAI 团队做的开源项目，GitHub 24k+ stars，主打"orchestrate AI coding agents"，一句 npx vibe-kanban 起服务，左到右四列泳道：To Do → In Progress → In Review → Done。

另一个是我们的 auto-coder.chat 看板——五条泳道：待规划 → 待开发 → 进行中 → 待审查 → 已完成，每张需求卡跑完之后自带"判定理由"和"关联会话"。

不少朋友看完会问我一句很自然的话：

"你这个看板和 Vibe Kanban 是不是同一个东西？"

答案是：画面长得很像，骨子里是两条完全不同的路。

我把两个产品都摸了一遍，我自己写代码也在用 auto-coder.chat 看板，所以这篇文章不打算"写 PR 稿"。我想认真把两件事讲清楚——

1. Vibe Kanban 做对了什么。 它是"AI 编程 + 看板"这一波最早提出来、做得最成熟的开源项目之一，没有它，整个行业不会这么快意识到"看板才是 AI 编程的协作载体"。
2. 两个产品的架构选择不同，因此适用场景也不同。 你是想要"本机起 localhost，坐在这台电脑前做多 agent 并行实验"，还是想要"云端看板 + 本地实例，手机地铁上都能推进需求的工业流水线"，决定了你应该选哪个。

先把 Vibe Kanban 这个产品介绍清楚

我把 Vibe Kanban 上手玩了一遍，也通读了它的官方文档。它的标语是 "Your Engineering Bottleneck Has Shifted"——意思是 AI 编程时代，工程师的瓶颈从"写代码"挪到了"规划 + review"，所以应该把工具的注意力放到"加速规划和 review"这件事上。

它的核心机制可以用三个词概括：Plan / Prompt / Review。

• Plan：在看板上提 issue，填标题、描述、优先级、标签，可以拆子任务，可以加 blocker。
• Prompt：每个 issue 进入 In Progress 时，Vibe Kanban 自己不干活，它给你的本机 Claude Code / Codex / Cursor / Gemini CLI / Amp / Copilot / OpenCode / Droid / Qwen Code 这些已经认证好的第三方 CLI Agent 派活，每个任务起一个独立的 git worktree（独立工作目录、独立分支），多个 Agent 在不同 worktree 里物理隔离地并行跑。
• Review：Agent 跑完，卡片进入 In Review 列。你点进去看 diff，像 review PR 一样行内评论，把意见 send 给 agent，agent 回去改，改完再来 review，满意就 Create PR → 推到 GitHub → CI 跑过 → merge。

这套机制有几个真正做得好的点，我必须先说清楚：

1. 多 agent 并行的物理隔离做得很扎实。 每个 task 一个 git worktree，agent A 改 auth.ts、agent B 改 user.ts 不会互相踩。这是它的"杀手锏"，也是 24k stars 的真正原因。
2. 不绑某一个 Agent。 它的口号是 "Don't get locked in while the SOTA is constantly changing"——SOTA 模型今天是 Claude，明天可能是 Codex，再过一个月可能是某个新的开源 agent。Vibe Kanban 把自己定位成编排层，让你可以随时换 agent、甚至同一个任务用不同 agent 各跑一遍（"Attempt"模式）做对照。
3. PR 工作流闭环。 它直接对接 GitHub，可以自动生成 PR description、起 draft PR、按"Open PR → CI → reviewer → Merge"的标准 GitHub 流走完。
4. 开源 + 自托管。 Apache 2.0 协议，单人完全免费，团队 self-host 也免费，云托管才收费（Pro $30/user/月）。
5. 生态积累已经很厚。 站在它官网首页那个滚动条上往下翻，你能看到大量真实仓库通过 Vibe Kanban 创建并合入的 PR——anchapin/portkit、footnote-ai/footnote、Real-Solutions-PH/full-stack-fastapi-template……不是 demo，是已经在产中跑的真东西。

如果你的诉求是"我有 8 张并行的活，希望让 4 个不同的 agent 同时去试，然后我快速 review 选最好的"，Vibe Kanban 在今天是这件事最成熟的开源工具，没有之一。

再说 auto-coder.chat 的看板想做什么

我们做 auto-coder.chat 看板的出发点不太一样。

我从 2024 年 3 月开源 Auto-Coder，到 2026 年 4 月，整整两年。这两年我看着 AI 编程从"补全片段"一路演化到"独立交付完整需求"。Claude Opus 4.7 出来之后，模型已经过了那个阈值——你可以放心地把一个完整需求丢给 Code Agent 去实现了。

模型跨过这个阈值的瞬间，两个问题立刻浮出水面——

1. 当 Code Agent 可以独立交付了，主流的对话式协作模式就撑不起软件开发的真实需求了。
2. 当 Agent 可以独立交付了，我凭什么还必须坐在那台装了 Agent 的电脑前才能推进工作？

所以我们想做的其实是两件事叠起来——

第一件："让一根管道把人类的一句话变成 git 仓库里的一次 commit"。

第二件："让这根管道的入口在云端，执行体在本机"——你在工作笔记本启动 auto-coder.chat.lite，执行一条 /connect ak_xxxx 就把这台机器注册成云端的一个实例。之后你在手机 / 平板 / 出差路上任意一台浏览器打开 auto-coder.chat 登录，就能看到自己那块看板，新建一张卡、指定"绑定实例"到你家里那台电脑，点 ▷，活就在你家里那台电脑上真实跑起来。

这套"云端看板 + 本地实例"的架构，就是 auto-coder.chat 官网上那句话的直接含义——"笔记本只管跑，开发在任意浏览器里"。

这条管道有 6 个工位：

每张卡片在管道里走完一遍，要经过：

1. 需求提出（人 OR Agent 提）——Agent 可以根据一个大目标自动生成一批草稿需求，人只负责"aha moment"。
2. 填验收标准——这是整条流水线的刻度尺，决定了第 4 步谁来判卷。
3. Agent 评审 + 开发 + 自校验——卡片右下角点 ▷，Agent 接管。我们底层是Subagent 分层架构：主 Agent 用 Opus 4.6 / GPT-5.4 拆任务，Subagent 用 doubao-seed 这种性价比模型并行执行，单次需求成本压进了"几毛钱"级别。
4. Agent 对照验收标准给出"判定理由"——不只给"通过/不通过"，还要写清楚"凭什么通过"。
5. 人在"待审查"列做最终把关——AI 判定 ≠ 你接受交付，留一格给人肉 review。
6. Hook 自动 commit——卡片进"已完成"的瞬间，改动自动 commit 到对应 git 仓库；配合"自动接力"开关，下一张卡自动启动。

这条链路上，每一步都有明确的"交付物"和"状态变更信号"。

晚上睡前列一周的需求，早上起来可能已经 commit 了一半。

同样画看板，骨子里是两个不同的产品

讲到这里，两个产品的架构差就清楚了。我把它们做成一张对比表：

这张表里，最关键的三行是"控制面板在哪里跑"、"Agent 是不是自己带的"、"谁来判卷"。其他所有差异，都是这三个选择推出来的。

差异一：控制面板在哪里——本机 localhost vs 云端 Dashboard

这是两个产品最底层的架构分野，也是之前很多对比都没讲透的一条。

Vibe Kanban 是"本机一体"的——你 npx vibe-kanban，控制面板和执行体都在这同一台电脑上。它的好处是简单：没有云端，没有密钥，没有登录，你这台机器一关，看板和 agent 一起停。

代价是：你必须一直坐在这台机器前。

• 手机上看到一个 bug？记下来，回家打开电脑再 npx
• 出差用另一台机器？上下文没了，看板状态也没了
• 晚上 agent 还在跑？这台机器不能关，合盖睡觉它就停了
• 团队里想让别人看看你这块看板？对方连不上你的 localhost:8080

auto-coder.chat 看板走的是**"控制面板在云端、执行体在本机"** 的架构。流程是这样的：

[任意设备浏览器打开 auto-coder.chat] ─→ [云端看板] ─→ CloudBridge HTTP
                                                              ↓
[你家里那台电脑跑着 auto-coder.chat.lite，已 /connect]        ↓
                                        ↑── 认领任务 ←────────┘
                                        └── 回传结果 ──────────→ 云端刷新

具体步骤只要三步：

1. 在你的工作电脑启动 auto-coder.chat.lite（Python CLI，或者 auto-coder.web 开 Web UI 也行）
2. 在官网"我的 API Key"页点"创建 Key"，拿到一串 ak_xxxx，回到终端输入 /connect ak_xxxx
3. 这台机器 + 这个项目就注册成了云端的一个实例，之后随时出现在 auto-coder.chat/dashboard/instances 这个页面里

这台电脑不用一直开 IDE、不用坐在它面前、甚至不用锁屏——只要 auto-coder.chat.lite 进程活着，它就是一个随时待命的执行实例。

之后发生的事情就很有意思了：

• 手机地铁上看到 bug → 打开浏览器登录 auto-coder.chat → 新建一张卡 → **"绑定实例"**下拉里选"家里那台 Mac · auto-coder.chat" → 点 ▷
• 云端把这张卡下发下去 → 家里那台 Mac 上的 auto-coder.chat.lite 认领任务 → SubAgent 在本地仓库里真刀真枪地跑代码、跑测试、提交
• 结果回传云端 → 手机上刷新看板，卡片已经到"待审查"列

这就是前几天我在 8-minute-mobile-bugfix 那篇文章里讲的"8 分钟修 bug"故事的底层架构支撑——当时我人在外面办事，用户群里扔过来一张截图，我没回家、没开电脑，就在手机上把整张 bug 卡派给家里电脑的 Cursor 去跑。

这件事在 Vibe Kanban 上物理不成立——因为它没有"云端"这一层，手机上 npx 不动，就算你在 iPad 上 ssh 进家里电脑手动起 Vibe Kanban，下次再换手机就又要重来一次。

用一句话总结这个差异：

Vibe Kanban 把全部状态都绑在"你这台开着的电脑"上。 auto-coder.chat 看板把调度状态放到云端、把执行和代码留在本地。

至于这种云端架构的安全和隐私问题，也值得澄清一下：代码和密钥永远不出本机——云端只存"任务 promptText、结果 resultText、卡片元数据、conversation_id 映射"这种调度信息，你改的每一个文件、每一条 git commit 都发生在你自己的电脑上。Prisma schema 里的 LiteRun 表存的是 prompt 文本和最终回答文本，不存代码。

差异二："Agent 编排器"路线 vs "自带 Agent + 完整流水线"路线

Vibe Kanban 是一个Agent 编排器——它自己什么都不干，它只是给你的本机已经装好的那些第三方 CLI Agent 排队、隔离、收 diff。

这个定位的好处很清楚：对模型 SOTA 的变化天然鲁棒。今天你用 Claude Code，明天 Codex 出新版本你切到 Codex，后天 Gemini 3.5 出来你切到 Gemini，Vibe Kanban 不需要做任何升级。

这个定位的代价也清楚：它没法对最终交付负责。

举个例子。你在 Vibe Kanban 里提一个 issue："给登录接口加 rate limit，限制 IP 每分钟 60 次"。Claude Code 在 worktree 里跑了 8 分钟，提交了 18 个文件改动，进入 In Review 列。

Vibe Kanban 接下来给你做的事是：把 diff 摆出来，让你自己判断有没有改对。

它不会告诉你"这次改动有没有对应到你的需求"，因为它根本不知道"你的需求"具体是什么——它只把那一段 issue 描述原封不动转给了 Claude Code，剩下的全在 Claude Code 的会话里。

这是编排器路线的物理边界——你不能要求一个不知道业务上下文的工具去判定业务正确性。

auto-coder.chat 走的是另一条路：自带 Agent，所以可以对最终交付负责。

这条路要求我们在卡片上引入一个明确的字段——验收标准。它看起来只是一个多行文本框，但在整条流水线里承担了刻度尺的角色。Agent 跑完之后，会在同一会话上再起一轮只读校验任务，对照验收标准逐条核对，输出结构化的 PASS / FAIL 判定 + 判定理由 + 时间戳，连同执行总结一起写回卡片。

你看上面这张卡片的截图——

• 验收标准 原封不动列在那儿，是你最初定下的刻度尺；
• 最近一次校验 带精确到秒的时间戳 + 绿色"校验通过"；
• 判定理由 一段话讲清楚"凭什么通过"——"项目根目录存在合法的 project.md 文件，且内容是实质性的项目说明文档，不是空文件或占位文本，因此满足验收标准"；
• 执行结果 是 Agent 自己写的交付总结。

这就把 AI 从一个"黑盒执行者"变成了可审计的协作者。

编排器路线和自带 Agent 路线没有谁对谁错——它们对应的就是不同的诉求。

如果你想 SOTA 一变就丝滑切 agent，编排器路线更适合你；如果你希望工具能对"这次交付到底算不算完成"给出判断和留痕，自带 Agent 路线更适合你。

差异三：人 review 工位 vs 双工位（Agent 自校验 + 人审查）

Vibe Kanban 的 In Review 列是个单工位——agent 跑完直接交给人，人审完要么 send 反馈让 agent 再改，要么 Create PR 推 GitHub 走 CI。

这个设计在"人 = 工程师 + Senior 同事"的场景里非常顺畅。但它有一个隐藏的代价：所有的 review 注意力都压在你身上。

我自己实测过：当你同时有 5 个 worktree 在 In Review 列，每个都改了 12~30 个文件，review 本身就成了瓶颈。Vibe Kanban 自己也认这一点——它官网原话就是 "the speed of shipping is now limited by how quickly you can plan and review"。

auto-coder.chat 看板做了一个双工位拆分——

• 第一工位是 Agent 自校验：agent 跑完之后立刻起一个只读校验任务，对照你填的验收标准逐条打卡。它不只检查"文件是否存在"这种表层条件，还会判断"内容是不是实质性的、是不是空文件或占位文本"。这一步把绝大多数"agent 嘴硬说做完了其实没做"的情况直接挡在 In Review 之前。
• 第二工位是人审查：经过 Agent 自校验、判定为 PASS 的卡片才停在"待审查"列等你看。FAIL 的卡片会带着判定理由直接打回，不会浪费你 review 注意力。

这就是工业流水线和小作坊的区别——工业流水线在最后的人工质检之前，会先经过 Agent 自检。

这个设计的前提是"你写得了机械可核对的验收标准"。如果你的需求本质是探索性的（"看看这个数据集能不能挖出什么模式"），那写不出这种验收标准，你就走不上这条流水线，这时候 Vibe Kanban 那种"全靠人 review"的路子反而更顺。

差异四：手动并发 vs 自动接力

Vibe Kanban 的并发是人手动控制的——你想并行跑 5 个 issue，就要手动起 5 个 workspace。这是它"不绑 SOTA"的必然结果：它不知道你下一张卡想用哪个 agent、用什么 effort level、配什么 plan mode，所以它不敢替你启动。

auto-coder.chat 看板有一个 ⚡ 自动接力 开关。打开之后：

• 上一张卡校验通过进入"已完成"
• 调度器从"待开发"列里按优先级和手动顺序挑出下一条
• 自动提交执行，不需要人去拖卡片

底层这是看板的一个 auto_run 开关。它能这么自动，是因为我们自带 Agent——我们知道怎么启动下一张卡，因为执行器就是我们自己。

晚上睡前列一周的需求，早上起来可能已经 commit 了一半。

这种产能图景在"必须人手动启动每个 workspace"的产品上是不存在的。

也不是说 Vibe Kanban 不能往这个方向走——它只是没在这个方向上做。它把那部分注意力放在了"让多 agent 并行实验更顺滑"这条路上。

差异五：成本控制——Subagent 分层是不是产品的一部分

Vibe Kanban 完全不管你的成本——你用 Claude Code 烧多少 token、用 Codex 烧多少钱，那是你和 agent 厂商的事。

这并不是 Vibe Kanban 的问题，而是它的定位决定的——它是编排层，不是执行层。

但当你真的把"AI 编程做成一个团队的日常生产力"，成本会变成一个绕不开的话题。一个工程师一天提 30 张卡，全部用顶级模型跑，一个月账单可能比你的工程师还贵。

我们在 auto-coder.chat 上做了 Subagent 分层 的事情：

1. 主 Agent 只负责理解需求、拆分任务、验收结果，用 Opus 4.6 或 GPT 5.4
2. Subagent 负责所有执行，统一用 doubao-seed-2.0-pro 这种性价比模型
3. 主 Agent 被 Rule 限制为只能通过 Subagent 干活

结果是顶级模型变成了"稀土"——必须要有，但用量极少。单次需求成本进入几毛钱带，质量只有轻微损耗。

这套机制不是看板的一部分，但它是看板能"工业化吐单"的底层支撑。如果没有 Subagent 那一层把成本压下来，再漂亮的看板也是个昂贵的玩具。

Vibe Kanban 没有这一层，因为它不需要——它把成本问题外推给了第三方 agent 厂商。这是它定位的优势（轻），也是它的局限（你自己的成本你自己想办法）。

差异六：代码合入是 PR 工作流，还是流水线最后一节

Vibe Kanban 的代码合入路径是 PR-first：

• 在 worktree 里改完 → Create PR（AI 写 description）→ 推到 GitHub → CI 跑 → reviewer review → merge

这套流程在团队协作 + 公开仓库 + 强 review 文化的场景里很合适——每个改动都有 PR 留痕，CI 把关，团队成员可以参与讨论。

auto-coder.chat 看板的代码合入路径是 Hook-first：

• 卡片进入"已完成"的瞬间，触发一个 hook，自动把改动 commit 到对应仓库
• 你不用再手动 git add && git commit && git push
• 你对着验收标准点一下"接受"，代码已经进仓库了

这套流程在单人开发 + 私有仓库 + 高频小颗粒交付的场景里更顺。当然它也支持走 PR 路径，但我们不把 PR 当成主流交互，因为：PR 流程的核心是"让人 review"，而我们的核心已经前移到"Agent 自校验 + 人审查待审查列"了。

不冲突。两套流程对应的是不同协作密度。

不是 zero-sum 的——分工建议

写到这里你可能在等我说"所以 auto-coder.chat 看板比 Vibe Kanban 好"。我不会这么说，因为这不公平。

两个产品的合理分工大概是这样：

Vibe Kanban 适合的场景——

1. 你已经是 Claude Code / Codex / Cursor 的重度用户，不想换 agent，只想要一个更好的"批量调度 + 物理隔离"工具
2. 你想做"多 agent 比稿"的实验，看看同一个 task 让不同 agent 跑出来什么差异
3. 你的团队工程文化是强 PR review —— 每个改动都要进 GitHub PR、过 CI、有 reviewer 签字
4. 你习惯坐在工位前集中办公，不需要"通勤路上提需求"这种能力
5. 你愿意为模型 SOTA 的快速变化付出"自己 review 所有交付"的代价
6. 你 OK 自己负责成本（用什么 agent、烧多少 token，自己定）

auto-coder.chat 看板适合的场景——

1. 你希望需求有结构化的验收标准，agent 自己能对照打卡，不要全靠人肉 review
2. 你希望开"自动接力"开关之后，晚上睡前列卡 → 早上起来已经 commit 一半，不要每次都手动启动
3. 你想要**"笔记本只管跑、开发在任意浏览器里"** —— 手机地铁上、平板咖啡馆里、出差酒店里都能推进工程
4. 你接受单 agent（我们自己带的）+ Subagent 分层成本控制，不需要切第三方 agent
5. 你希望代码改动直接 commit 到本地仓库（也支持走 PR），交付密度高
6. 你需要私有化部署、需要团队场景下的云端电脑接力

也可以混着用——你可以用 auto-coder.chat 跑你的常规迭代需求（特别是需要"不在工位前也能推进"的那些卡片），遇到一个想要"让 3 个 agent 比稿"的实验性任务时，开 Vibe Kanban 起 3 个 worktree。两个产品在我自己的工作流里都有位置。

一个更深的判断：看板这个形态会赢

抛开两个产品的具体差异，我想说一个更大的判断——

从 Opus 4.7 开始，AI 辅助编程的分界线不再是"写得好不好"，而是"有没有一套需求管理的协作形态"。

聊天窗口（Claude Code、Cursor、Codex 默认形态）解决不了三件事：

1. 状态是散的——昨天聊到一半的需求，今天得从头复盘
2. 需求是线性的——必须排成一条队挨个说给 AI 听
3. 验收是口头的——"帮我看看对不对"能问，没有结构化留痕

这三件事不是 chat 窗口本身的问题，是 chat 这个载体的问题。

看板把这三件事一次性解决了——卡片化让每个需求有独立的状态和上下文、泳道化让多需求并行调度、结构化字段（无论是 Vibe Kanban 的 description + priority + tag，还是我们的描述 + 验收标准）让信息有标准格式可以传递。

所以无论你最后选 Vibe Kanban 还是 auto-coder.chat，看板模式本身就是 AI 编程的正确进化方向。Vibe Kanban 在 24k stars 那个体量上验证了这一点，我们在国内的实践也在验证这一点。

剩下的差异，是路线选择和适用场景的问题。

如何快速体验

Vibe Kanban：

npx vibe-kanban

确保你已经认证好了 Claude Code / Codex / Cursor 等任意一个 CLI Agent。打开 http://localhost:8080 即可使用。

官网：vibekanban.com

GitHub：BloopAI/vibe-kanban

auto-coder.chat 看板：

体验流程一共三步（和 Vibe Kanban 不一样——你不是"起一个本地服务"，而是"把本地机器注册到云端"）：

1. 在你的工作电脑上装好 auto-coder

pip install -U auto-coder auto_coder_web

2. 在项目目录起一个 lite 实例

cd your-project
auto-coder.chat.lite

3. 拿到 API Key 并 /connect 到云端

登录 auto-coder.chat → "我的 API Key" → 创建一个 Key，格式为 ak_xxxx。

回到刚才的 auto-coder.chat.lite 终端，输入：

/connect ak_xxxx

这台机器 + 这个项目就注册成了云端的一个实例。

之后你就可以在任意设备（手机、平板、任意电脑）的浏览器打开 auto-coder.chat 登录，进 Dashboard → "需求看板"，新建卡片时在"绑定实例"里选刚注册的那台，点 ▷，活就开始在你那台电脑上跑了。

详细文档：docs.auto-coder.chat/docs/connect-cloud

任何问题欢迎在 GitHub issue 里留言，或者发邮件到 allwefantasy@gmail.com，我本人会看。

最后

每一波生产力工具的演化，都不是"一个产品赢者通吃"，而是"几条路线各自走出自己的位置"。

本机编排器路线和云端控制 + 本地执行的自带 Agent 路线，本质是 AI 编程在工业化路上的两条相邻车道。Vibe Kanban 在第一条车道上做到了今天的天花板，我们想在第二条车道上把"云端看板 + 本地实例 + 完整流水线"这件事做厚。

第二条车道关心的，不只是"AI 能不能把代码写对"，更是"工程师能不能不用坐在电脑前"——在地铁上、在饭桌上、在出差的酒店里，手机上一张卡，家里那台笔记本就把活干了。

我们的愿景很简单——让每个开发者都拥有一条自己的 AI 流水线，从任意设备的一句话，到 git 仓库里的一次 commit，全程工业化，每张卡片都自带交付凭证。

让软件开发，像制造业那样有节律、有证据、有规模。

体验 auto-coder.chat 看板：auto-coder.chat

体验 Vibe Kanban：vibekanban.com