Bika 的新階段，以及 Buda 的獨立新方向
很長一段時間裡，Bika 對我們來說都不只是一個產品名字。
它承載了我們對下一代工作軟體的很多判斷，也承載了我們一段非常真實的創業經歷。
我們想讓軟體不只是記錄工作，而是能主動推動工作。
我們想讓自動化不只是流程串接，而是真的能理解上下文。
我們想讓 AI 不只是聊天，而是能參與團隊的日常運轉。
也因為這樣，今天這篇文章並不輕鬆。
今天，我們想正式發布一個並不輕鬆的決定：
第一，Bika 不會徹底消失，但會進入有限維護狀態。
第二，Buda 是我們正在投入的新產品方向，但 Buda 和 Bika 是完全獨立的產品。Buda 不是 Bika 的改名，不是 Bika 的升級版，不是 Bika 的新方案，也不是 Bika 或 AITable.ai LTD 權益的延伸。
這篇文章不是一次產品遷移公告，也不是一次 plan-name change 公告。
它是一次關於 Bika 新階段，以及 Buda 為什麼會作為獨立產品方向繼續推進的公開說明。
一個艱難的決定
我們需要把產品邊界放在最前面說清楚。
Bika 和 Buda 是完全獨立的產品。它們的功能、使用場景、產品架構、資料模型、計費體系和服務邊界都不同。
Bika 是一個圍繞 spreadsheet / database、automation、dashboard、docs、agent 和 template package 組織起來的工作系統。
Buda 則是另一個獨立產品，圍繞 agent 的雲端運行環境、Browser、Terminal、Drive、Git、雲端沙箱和長期任務執行來設計。
這意味著：
- Buda 不是 Bika.ai 的改名
- Buda 不是 Bika.ai 的升級版
- Buda 不是 Bika.ai 的新方案
- Buda 不是 AITable.ai 或 Bika.ai AppSumo LTD 的 plan-name change
- Buda 不會自動包含在 AITable.ai 或 Bika.ai LTD 權益中
- Bika.ai 的資料、自動化、模板、agent 或 workspace 內容不會自動遷移到 Buda
我們在團隊內部確實從 Bika 的長期建設中學到了很多經驗。但產品經驗上的學習，不等於產品權益、帳號方案或資料結構上的延續。
所以如果你是 Bika.ai 或 AITable.ai 的現有使用者，尤其是 LTD 使用者，請把 Buda 理解為一個由同一團隊開發、但與 Bika.ai 和 AITable.ai 完全獨立的新產品。
Bika 幫我們看清了什麼
Bika 不是一個沒有價值的嘗試。
相反，它幫我們把很多關鍵問題真正做深、做透，也讓我們看清了一個複雜工作系統的能力邊界。
在做 Bika 的過程中，我們越來越確認幾件事。
1. 複雜工作，確實可以被整合進一個強大的系統
今天回頭看，Bika 其實是一個非常有野心的產品。
它不是只做單點功能，而是試圖把很多原本分散的能力，融合成一個統一的工作系統：
- spreadsheet / database
- agent
- docs
- automation
- dashboard
- template package
我們當時的判斷是，企業裡很多複雜問題，本來就不是單點工具能解決的。
真正棘手的工作，通常都橫跨：
- 資料結構
- 業務流程
- 文件協作
- 自動執行
- AI 理解與生成
所以 Bika 想做的，是把這些東西收攏成一個 template package，讓使用者拿到的不是零散功能，而是一整套可運作的工作解法。
這件事到今天我們仍然覺得是對的。
而且說實話，Bika 很 powerful。
如果你真的深入去用，你會發現它能解決的，是那種傳統 SaaS 很難一把兜住的複雜工作問題。
但問題也恰恰從這裡開始。
2. Bika 的強大，也帶來了它自己的複雜性
當你把 spreadsheet、agent、doc、automation 全都揉進一個系統裡，再進一步打包成 template package，產品能力會變得非常強。
但另一個結果也會同步出現：
互動複雜性會開始上升。
因為新使用者不再是在學一個單獨的產品，而是在理解一整套工作系統。
這會帶來很真實的問題：
- 新手上手門檻變高
- 心智負擔變重
- 功能很多，但第一眼不夠輕盈
- 產品哲學本來該有的魅力，會被複雜互動稀釋掉
我們後來越來越清楚地意識到，Bika 的問題從來不是「不夠強」，而是它在試圖解決複雜工作時，也把複雜性一併交給了使用者。
能力是真的有。
但入門也確實不簡單。
而當一個產品的第一感受，開始從「有吸引力的未來工作方式」變成「這是一個功能很完整、但需要學習成本的系統」，它的產品哲學就會被削弱。
3. 更核心的限制，在 Agent 引擎本身
再往下看，我們還碰到了一個更本質的問題。
那就是：
Bika 的 Agent 能力，更多還是基於 API 調度。
這在很多場景裡當然可以工作，也足以做出很多有價值的事情。但如果你真的想把 agent 往「長期運行的 AI 員工」那條路推進，就會慢慢感受到它的邊界。
因為一個真正能持續工作的 agent，不應該只是一段被調度起來的 API 呼叫鏈。
它還需要有自己的工作環境。
它需要：
- 自己獨立的工作網盤
- 自己的持久上下文
- 自己的檔案系統
- 自己的隔離空間
- 可以長期運行的沙箱
- 能真正執行複雜任務的 runtime
而 Bika 並不是圍繞這套底層假設來設計的產品。
它可以把很多能力接起來，但它並不是從第一天開始，就圍繞著「agent 自己擁有一個長期可工作的空間」去構建的。
更具體地說，Bika 沒有把 agent 自己的獨立沙箱網盤 作為底層第一原則。
而我們後來越來越相信，這件事不是錦上添花，而是核心前提。
如果 agent 沒有自己的獨立工作網盤，沒有自己的隔離沙箱，沒有一個可以長期沉澱檔案、上下文、執行痕跡的空間，那麼它就更像一次次被臨時喚起的能力，而不是一個真正能持續工作的 AI 員工。
4. 我們不想繼續把 Bika 擴展成一個越來越重的系統
Bika 越往後做，我們越明顯地感覺到，如果繼續把所有新能力都塞進 Bika，它會變得越來越重。
這不一定對現有使用者更好。
對已經熟悉 Bika 的使用者來說，穩定、可用、可靠，比不斷加入大量新方向更重要。
所以我們最終決定：Bika 會進入有限維護狀態，繼續保障基礎可用性、穩定性、安全性和必要的運行維護；但我們不會再把 Bika 當成主要的新功能擴張方向。
這件事在情感上並不好接受。
畢竟你已經投入了那麼多時間，那麼多人也已經開始使用它，你總會忍不住想：
- 能不能再補一點功能？
- 能不能再改一輪首頁？
- 能不能再把這個模組做完整？
- 能不能先別承認資源重心已經變了？
我們確實這樣掙扎了很久。
為什麼 Buda 需要一條獨立路徑
說得直接一點：因為繼續把所有新產品方向都放進 Bika，已經不再是最誠實的選擇。
不是因為 Bika 完全沒有價值，而是因為我們越來越清楚，Buda 背後的方向需要一個不同的產品邊界、技術架構和商業體系。
這條獨立路徑，就是 Buda。
如果要用一句話來概括它們的差別，大概是：
- Bika 是一個把表格、資料庫、文件、自動化、儀表板、agent 和模板包整合在一起的工作系統
- Buda 是一個圍繞 agent 雲端運行環境、沙箱、Drive、Browser、Terminal、Git 和長期任務執行來設計的獨立產品
這不是簡單的品牌升級。
也不是把 Bika 改名叫 Buda。
更不是把 Bika LTD 使用者遷移到另一個方案。
這是一條獨立產品線。
Buda 是什麼
Buda 是一個完全獨立的新產品。
它的出發點不是讓使用者在一個 spreadsheet / database 工作系統裡配置流程，而是讓 agent 在雲端環境中執行任務。
Buda 更強調這些東西：
- 多 agent 協作，而不是單個助手
- 持久工作空間，而不是一次性會話
- Browser、Terminal、Drive、Git 這樣的真實執行環境
- 團隊級編排，而不是個人級試玩
- 可長期運行、可隔離、可管理的基礎設施
更具體一點說，Buda 的關鍵差別在於：
- agent 運行在雲端沙箱裡
- agent 有自己的 獨立 Drive / 工作網盤
- 工作空間是隔離的，不同 agent 的上下文不會混在一起
- agent 可以圍繞真實執行環境去工作，而不是只回傳一段文字結果
- 底層依賴的是更強的 Coding Agent 和 Agent Skills 體系
這些能力和 Bika 的功能、資料結構、使用場景並不相同。
所以我們必須再次強調：Buda 不是 Bika 的替代方案，不是 Bika 的新名字，也不是 Bika 的自然升級路徑。
對 Bika 使用者，這意味著什麼
我們不打算把這件事說得含糊。
從現在開始：
- Bika 會進入有限維護狀態
- 我們會優先保證基礎可用性、穩定性、安全性和必要運行維護
- Bika 不會繼續作為主要的新功能擴張方向
- Buda 會作為獨立產品方向繼續推進
這並不意味著 Bika 立刻下線，也不意味著我們會突然中斷現有使用者的使用。
現有 Bika 使用者可以繼續使用 Bika。
如果你擁有 Bika.ai 的 LTD 權益，你的 LTD 權益仍然適用於 Bika.ai。
如果你擁有 AITable.ai 的 LTD 權益，你的 LTD 權益仍然適用於 AITable.ai。
如果你此前從 AITable.ai 獲得過 Bika.ai benefit，該 benefit 仍然適用於 Bika.ai。
但這些權益不會自動擴展到 Buda。
給 LTD、AppSumo 和 AITable.ai 使用者的說明
現有 Bika.ai LTD 使用者會獲得 Buda 嗎？
不會。
Buda 是獨立產品，不包含在 Bika.ai LTD、AITable.ai LTD 或此前提供的 Bika.ai benefit 中。
Bika.ai Tier 4 或 AITable.ai AppSumo Tier 5 會映射到 Buda 嗎？
不會。
因為 Buda 不是 Bika.ai 或 AITable.ai 的方案更名，也不是它們的升級版本，所以不存在 seats、credits、storage、agents、usage limits 或 plan 的映射。
AppSumo 的 future plan updates 或 plan-name change 條款是否適用於 Buda？
不適用。
這些條款適用於使用者購買或獲得權益的對應產品。Buda 是獨立產品，不是 Bika.ai 或 AITable.ai 的 plan-name change。
Bika.ai 使用者是否可以遷移到 Buda？
目前沒有遷移路徑。
Bika 和 Buda 的功能、使用場景、底層架構和資料模型不同。Bika 中的資料、自動化、模板、agent 或 workspace 內容不能直接遷移成 Buda workspace。
Bika.ai 和 AITable.ai 是否還會繼續維護？
會。
Bika.ai 和 AITable.ai 會繼續維護，以保障基礎可用性、穩定性、安全性和必要的運行表現。
但 Bika.ai 不會繼續作為主要的新功能擴張方向。
是否有退款、credit、grandfathered plan 或 Buda 轉換方案？
目前沒有。
原因是現有 LTD 權益仍然對應並保留在使用者購買或獲得權益的原產品中。Buda 是獨立產品，不屬於 Bika.ai 或 AITable.ai LTD 權益的自動延伸。
為什麼我們想把這件事公開說明
我們不想讓使用者在一堆模糊文案裡猜測到底發生了什麼。
如果資源方向變了，就應該認真說明為什麼。
如果 Buda 是獨立產品，也應該清楚說明它和 Bika 的邊界。
因為使用者值得被坦誠對待。
而且說實話，我們自己也需要這樣一篇文章。
這不是一篇單純的產品介紹，更像是一個階段性的交代：
- 對過去做一個誠實總結
- 對今天的取捨給出理由
- 對現有使用者的權益邊界說清楚
- 對 Buda 為什麼會作為獨立產品方向繼續推進明確說明
這篇文章不是為了把 Bika 說得更差，好讓 Buda 看起來更好。
相反，正是因為 Bika 足夠重要，我們才覺得應該認真寫下這段變化。
如果你願意，歡迎來看看 Buda
如果你一路跟著 Bika 走到這裡，先謝謝你。
你們給過的回饋、提出過的質疑、真正用過產品的那些場景，都是我們做產品時非常重要的經驗。
如果你也關心這些問題：
- AI 到底能不能真的替團隊做事？
- agent 能不能不只是 demo，而是長期工作？
- 未來的軟體，會不會出現專門為 AI agent 準備的工作環境？
那我們真誠地邀請你來看看 Buda。
但請明確理解：Buda 是一個獨立產品，不包含在 Bika.ai、AITable.ai 或 AppSumo LTD 權益中。
Bika 會繼續維護。
而 Buda 會作為一條獨立產品路徑繼續推進。
推薦閱讀
推薦AI自動化模板
