Vibe Kanban 把 AI 寫程式代理收進看板，這開源工具正在收攤

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

Vibe Kanban 是一個把 AI 寫程式代理（coding agent）收進看板介面來統一管理的開源工具，由 BloopAI 團隊開發，底層用 Rust 寫成，截稿時在 GitHub 上累積約 2.7 萬顆星，採 Apache-2.0 授權。

不過在聊它做得到哪些事之前，有個訊息必須先講清楚，而且這是你決定要不要裝來用的最大變數：README 最頂端直接掛了一句「Vibe Kanban is sunsetting」，專案正在收攤，官方還附了一篇 shutdown 部落格文讓你自己去看細節。換句話說，它不是一個還在積極擴張的產品，而是一個已經預告要退場的工具。下面所有功能介紹都建立在這個前提下：能力是真的，但能陪你走多久要自己評估。

Pin

先把最壞的講在前頭：它已經宣布 sunset

我把整份 README 從頭讀到尾，第一個印象是 sunset 公告放的位置非常刻意。它不是塞在某個段落裡，而是壓在 logo、badge 和那張主視覺截圖的正上方，排在 Overview 之前。任何一個路過 GitHub repo 的人，第一眼就會看到「Vibe Kanban is sunsetting」這行字，旁邊接著「Read the announcement」連到官方的 shutdown 部落格文。

這個擺法的訊號很明確：官方希望你還沒開始用之前，就先知道它要收了。

我只讀了 README，沒有進去翻那篇 shutdown 部落格文的具體時程和原因，所以這裡不會瞎掰一個停止服務的日期給你。詳細什麼時候關服務、雲端版會怎麼處理、本機版還能跑多久，以官方那篇 shutdown 公告為準。你真的要評估的話，第一步就是去看那篇，別聽第二手轉述。

但單就 README 的態度來看，可以把 Vibe Kanban 當成「程式碼還在跑、但產品不再出貨」的狀態來理解。意思是：你現在裝起來它還是會動，可是別期待新功能、別期待 bug 能很快被修，碰到問題很可能得自己來。這是後面所有判斷的地板，先把這層講死，再往下看功能才不會過度期待。

它到底想解決什麼麻煩

sunset 先講完，來看它本體想做什麼。

README 的 Overview 開頭寫了一句話，我覺得是整個專案最值得停下來想一下的判斷：在 AI 寫程式代理普及之後，軟體工程師花最多時間的，其實已經不是自己寫程式，而是「規劃代理要做什麼」和「審查代理產出的程式碼」。所以要把交付速度拉上去，最有效的施力點不是再換一個更聰明的代理，而是讓規劃和審查這兩件事變快。尤其是審查：代理寫出來的程式碼你沒有參與過，得像審陌生人提交一樣逐行看，信任成本比看同事的 diff 高得多，這一塊往往是真正的瓶頸。

具體想像那個場景：你同時讓 Claude Code 改登入流程、讓 Codex 重構 API 層、讓 Gemini CLI 補測試，三條線並行在跑。沒有統一介面時，你得自己記哪條分支是誰開的、哪個終端機在跑誰、哪一份 diff 還沒看、代理改歪了要怎麼退回。context 切換的成本很快就會吃掉代理本來幫你省下的時間，而且代理一多，這種協調開銷是指數在爬，不是線性。Vibe Kanban 想接手的，就是這一塊。

它把整條流程收進一個介面：用看板把要做的任務一條一條列出來，決定優先順序、指派出去；準備開工時，把任務變成一個 workspace，讓 AI 寫程式代理在裡面執行；代理寫完，你直接在同一個介面裡看 diff、留 inline comment 把意見回饋給代理；最後開 PR、在 GitHub 上審、merge。

關鍵是它把自己定位在「管理層」，不是「執行層」。它不會自己幫你寫程式，它做的是把你已經在用的那些 AI 寫程式代理，關進一個有版本控制、有終端機、有預覽環境的籠子裡，讓你一次看好幾個、管好幾個，而不是開十幾個終端機視窗自己切換。

一個介面管住十幾個 AI 寫程式代理

功能面，README 寫到它支援十個以上的 coding agent，名單包括 Claude Code、Codex、Gemini CLI、GitHub Copilot、Amp、Cursor、OpenCode、Droid、CCR、Qwen Code。你在學的、在用的，幾乎都能掛進來，等於不用為了換一個代理就換一套工作流程。（如果你主力是 Claude Code，可以順著我們整理的 Claude Code 實戰建議一起看，會更知道在這類多代理介面裡要怎麼把它的能力發揮出來。）

幾個 README 寫到的核心能力，這裡逐項說：

Workspace 隔離執行。 每個任務會開一個獨立的 workspace，README 寫到裡面包含一個 git 分支、一個終端機、一個 dev server。好處是你可以同時讓多個代理、多個任務並行，彼此不互踩，因為每個都有自己的分支和環境。

Diff 審查與 inline comment。 代理改完程式碼，你不用跳到別的工具看它改了什麼，直接在 Vibe Kanban 裡看 diff，覺得哪裡怪就在那行留 comment，訊息會回給代理。這等於是把「改、看、給回饋、再改」這個圈兜在同一個畫面裡完成。

Dev server 預覽。 README 寫到它內建一個瀏覽器，附 devtools、inspect mode 和裝置模擬，讓你直接預覽代理改出來的成品實際跑起來長怎樣，不用再自己開一台。

開 PR 與 merge。 審完沒問題就開 PR，README 寫到 PR 描述是用 AI 生成的，之後可以在 GitHub 上 review、merge，把成品推回主線。

把這幾個能力串起來，一個任務走完的樣子大概是這樣：你在看板上建一張 issue，寫清楚要做什麼；開一個 workspace，README 寫到它會幫這個任務切一個分支、起一個終端機、跑一個 dev server；選一個代理進去執行；代理改完，你在 Vibe Kanban 裡直接看 diff，哪一行不對就在那行留 comment，代理接著改；改到沒問題，開一支附 AI 生成描述的 PR，推到 GitHub 上 merge。整條路不用離開那個介面，這也是 README 那句「Describe the work, review the diff, ship it」想講的事。能不能真的這麼順，我沒實跑不敢掛保證，但這條路徑就是它設計上想兜起來的圈。

這裡要誠實講一句：上面這些都是 README 寫到的「能力存在」，我只讀了官方文件，沒有實際把 vibe-kanban 裝起來跑過，所以沒辦法告訴你那個 diff 審查的來回實際上順不順、Claude Code 整合得牢不牢、十幾個代理切換會不會卡。這些都得你自己裝一輪才知道。README 能保證的是「它做得到」，不能保證「它做得好」，這兩件事在工具導覽裡必須分清楚。

怎麼裝起來

如果你評估過 sunset 風險還是想試，安裝本身很輕。

一般使用。 README 寫到一行指令搞定：npx vibe-kanban。前置條件是你得先幫自己要用的 coding agent 登入好、認證通過（API key、OAuth 登入那些），因為 Vibe Kanban 只是去呼叫你已經裝好的代理，不會自己生一把 key 給你。換句話說，它是疊在你現有代理訂閱與 API 額度之上的管理層，不是替代品，下面限制段會再把帳單這件事講清楚。另外它跑在 Node.js 上，本機要有 Node.js ≥20 的環境。

自架。 如果不想靠官方雲端，README 指到一份 self-hosting guide，讓你用 Docker 部署、自己架一臺 Vibe Kanban。在 sunset 的脈絡下，這條路其實特別重要，下面限制段會再講為什麼。

從原始碼自己編（給想貢獻或 fork 的人）。 README 列的開發環境需要 Rust（latest stable）、Node.js ≥20、pnpm ≥8，外加 cargo-watch、sqlx-cli 這類工具。這裡要分清楚一件重要的事：單純「用」Vibe Kanban 完全不需要 Rust，npx 一行就好；會碰 Rust 是你想改它、或從原始碼 build 一份，這兩件事的門檻差很多，別被 Prerequisites 那段嚇到。

自架的小坑。 README 的環境變數表裡有一個值得記下來：如果你把 Vibe Kanban 架在反向代理或自訂網域後面（nginx、Caddy、Traefik 那類），必須設定 VK_ALLOWED_ORIGINS，不然瀏覽器的 Origin header 對不上後端預期的 host，API 請求會被擋成 403 Forbidden。這是自架很容易踩到、但文件寫得其實滿明白的細節。另外它內建 PostHog 遙測，不想把使用資料往外送的人，把 POSTHOG_API_KEY 留空就會關掉。

裝之前要先接受的幾件事

把限制集中在這裡講，不要散在每一段裡踩煞車。

Sunset 是最大的一條，沒有之一。 這點前面講過了，這裡不重複細節，但它就是你在衡量下面所有優點時的乘數。再多功能、再漂亮的介面，乘上一個「不知道還維護多久」，實際價值就會打折。

Apache-2.0 是你的安全網。 這是 sunset 故事的另一面。因為它開源、Apache-2.0、可以自架，所以「官方收攤」並不等於「工具消失」。程式碼還在 repo 裡，你隨時可以 fork、自己架、自己修。對本來就有 Rust 與 Node 維護能量的團隊來說，sunset 的殺傷力會比封閉原始碼的 SaaS 小得多，這也是為什麼自架那條路在這個時間點特別有意義。不過要誠實說：fork 一個 Rust 後端加 web 前端的專案，長期門檻比 fork 一個純腳本工具高得多，得有人持續願意接手修 bug、跟上代理 API 的變動，社群版才有可能真的活下來。這件事現在還在觀察期，別假設一定會有人接。

它不是代理，是管理層。 Vibe Kanban 自己不寫程式。如果你現在根本沒在用任何 AI 寫程式代理，裝了它也不會憑空幫你產出程式碼。它的價值完全建立在「你已經有在用的代理，只是管得很累」這個前提上，沒有這個前提，它對你就是空的。

代理的帳單還是你要自己付。 Vibe Kanban 本身開源免費，但它驅動的那些 coding agent，每一個都有自己的計費方式：Claude Code 吃 Anthropic 的額度、Codex 吃 OpenAI 的、Copilot 要訂閱。VK 只是把它們呼叫起來，不會幫你付錢，也不會讓你少用 token。把十個代理掛上來，不代表十個都免費，反而可能因為一次開多個 workspace 並行跑，讓你的 API 帳單疊得更快。這在評估「要不要裝」時，是個很容易被漂亮介面蓋過去的變數。

需要 Node.js 環境。 它不是打開瀏覽器就能用的純網頁服務，本機要有 Node.js ≥20。對非工程背景的人，這是一道門檻。

2.7 萬顆星不等於有人接手。 星數證明了需求是真的、概念打中了痛點，但星數從來不等於維護者。會不會有人出來 fork 接手、社群版能不能成型，是接下來的觀察重點，現在還說不準。

誰還值得在收攤階段裝來用

講到底，sunset 並不是判死刑，而是把「適合誰」這個問題的答案整個改寫了。

適合裝來用的人。 如果你或你的團隊正在同時哄好幾個 AI 寫程式代理、切視窗切到很累，而手上這個專案只需要再跑幾個月，那麼在官方公布的 sunset 時程還許可的範圍內，把 Vibe Kanban 當短期管理介面用是很合理的選擇。如果你本身有 Rust 與 Node 的維護能量、本來就在找可以自架的多代理管理工具（這類 把多個 AI 代理整成一組來管理的選擇值得交叉比一下），那 Apache-2.0 加上完整原始碼，等於是把一個已經驗證過概念的基座交到你手上，自己 fork 一份養起來完全可行。如果你是在研究「多代理協作的 UI 到底要怎麼設計」，這份程式碼本身就是很好的觀察對象，後端 Rust、前端 web、還掛了 MCP，架構值得讀。

不該碰的人。 如果你要的是一個能長期依賴、有廠商在背後撐的產品，尤其想把它放進生產環境當團隊的標準工具，那這個時間點就不該把 Vibe Kanban 當成長期方案。它已經預告退場，把它塞進你的關鍵工作流程，等於把一個會過期的依賴放進地基。

最誠實的下一步。 先去看那篇 shutdown 部落格文，搞清楚官方給的時間表，再回來決定。時間表許可、又只是短期需求，npx vibe-kanban 裝一輪自己體驗那個 diff 審查的來回；想長期用的話，把它當參考程式碼來讀、或評估自己 fork 一份，會比把它當現成產品依賴更踏實。別因為 2.7 萬顆星和一份漂亮的功能清單，就忽略 README 最頂端那句 sunset。