从 Bika 到 Buda：一篇关于挣扎、取舍与重新开始的说明

Kelly Chan

April 04, 2026

6 分钟阅读

过去很长一段时间里，Bika 对我们来说都不只是一个产品名字。

它承载了我们对下一代工作软件的很多判断，也承载了我们非常真实的一段创业经历：

我们想让软件不只是记录工作，而是能主动推动工作
我们想让自动化不只是流程拼接，而是能真正理解上下文
我们想让 AI 不只是聊天，而是能参与团队的日常运转

也正因为这样，今天这篇文章并不轻松。

我们想正式说清楚一件事：

Bika 不会彻底消失，但会进入有限维护状态。我们未来的主要产品方向，将转向 Buda。

这不是一句公关话术。它背后是很多轮挣扎、很多次不甘心、很多次试图继续把 Bika 再往前推一步之后，做出的决定。

先说结论：Bika 和 Buda 的愿景，其实从来没有变过

如果要用一句话来概括这两个产品背后的核心愿景，其实一直都是同一句：

AI Organizer，真正去运行一家公司的工作。

不管是 Bika，还是今天的 Buda，我们从来都不是想做一个只会聊天的 AI。

我们真正想做的，是一个能够：

理解上下文
调动工具
持续执行任务
和团队一起工作
最终参与公司日常运转

的系统。

所以这次变化，并不是愿景换了。

变的是技术路线，变的是产品形态，变的是我们终于承认：要实现同一个愿景，Bika 这条路已经不再是最对的那条路。

Bika 帮我们看清了什么

如果没有 Bika，就不会有今天的 Buda。

Bika 不是失败的前身，恰恰相反，它是我们真正把很多关键问题做深、做透之后，才看见边界的那个阶段。

在做 Bika 的过程中，我们越来越确认几件事：

1. Bika 证明了一件事：复杂工作，确实可以被整合进一个强大的系统

我们今天回头看，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 的问题从来不是“不够强”，而是它在试图解决复杂工作时，也把复杂性一并带给了用户。

这是一种非常典型、也非常诚实的 tradeoff。

能力是真的有。

但入门也确实不简单。

而当一个产品的第一感受，开始从“有吸引力的未来工作方式”变成“这是一个功能非常完整、但需要学习成本的系统”，它的产品哲学就会被削弱。

3. 更核心的硬伤，其实在 Agent 引擎本身

再往下看，我们还碰到了一个更本质的问题。

那就是：

Bika 的 Agent 能力，更多还是基于 API 调度。

这在很多场景里当然可以工作，也足以做出很多有价值的事情。但如果你真的想把 agent 往“长期运行的 AI 员工”那条路推进，就会慢慢感受到它的边界。

因为一个真正能持续工作的 agent，不应该只是一段被调度起来的 API 调用链。

它还需要有自己的运行环境。

它需要：

自己独立的工作网盘
自己的持久上下文
自己的文件系统
自己的隔离空间
可以长期运行的沙箱
能真正执行复杂任务的 runtime

而这恰恰是 Bika 在底层路线上的硬伤。

它可以把很多能力接起来，但它并没有从第一天开始，围绕“agent 自己拥有一个长期可工作的空间”来构建。

更具体地说，Bika 没有把 agent 自己的独立沙箱网盘 作为底层第一原则。

而我们后来越来越相信，这件事不是锦上添花，而是核心前提。

如果 agent 没有自己的独立工作网盘，没有自己的隔离沙箱，没有一个可以长期沉淀文件、上下文、执行痕迹的空间，那么它就更像一次次被临时唤起的能力，而不是一个真正能持续工作的 AI 员工。

4. 我们其实已经不满足于做一个“AI feature 丰富”的 SaaS

Bika 越往后做，我们越明显地感觉到，自己真正想做的，不是把 AI 一点点加进旧的软件形态里。

我们更想做的是：

重新定义软件本身，让它从工具，变成组织工作的 AI 系统。

这也是我们内部反复讨论、反复拉扯的地方。

因为一旦承认这一点，就意味着很多原本在 Bika 上继续打磨的工作，其实会越来越偏离真正的未来方向。

这件事在情感上并不好接受。

毕竟你已经投入了那么多时间，那么多人也已经开始使用它，你总会忍不住想：

能不能再补一点功能？
能不能再改一轮首页？
能不能再把这个模块做完整？
能不能先别承认方向已经变了？

我们确实这样挣扎了很久。

我们为什么最终决定 pivot

说得直接一点：因为继续把主要精力放在 Bika 上，已经不再是最诚实的选择。

不是因为 Bika 完全没有价值，而是因为我们越来越清楚，真正值得我们全力投入的，是另一条路线。

这条路线后来变成了 Buda。

如果要用一句话来概括它们的差别，大概是：

Bika 更像是在探索如何把 AI、表格、文档、自动化整合进一个强大的工作系统
Buda 则是在构建一个真正以 agent 为中心的运行时，让 AI Organizer 可以直接去运行一家公司的工作

这不是简单的品牌升级，而是产品范式变了。

在 Buda 的视角里，我们不再从“一个人在操作一个系统”出发，而是从：

多个 agent
多种岗位
共享上下文
持续运行的工作空间
面向团队和组织的编排能力

出发来设计整个产品。

这也解释了为什么我们会觉得，Buda 不是 Bika 的一个子功能，也不是某个大版本升级，而是必须独立出来的一次重建。

Buda 到底承接了什么

Buda 并不是突然冒出来的一个新故事。

它承接的，恰恰是我们在 Bika 上这些年最核心的那批判断，只是把焦点收得更准，也把产品边界推得更远。

如果说 Bika 让我们确认了：

AI 不应该只是聊天
自动化不应该只是定时触发
系统应该有上下文
工作软件应该能主动执行

那么 Buda 进一步追问的是：

如果 AI 真的要成为团队成员，那它需要怎样的运行时、怎样的组织方式、怎样的产品形态？

而在这件事上，Buda 的技术原理和 Bika 已经明显不一样了。

Buda 从第一天开始，就是围绕 agent 的工作空间和运行时来搭的。

它更强调这些东西：

多 agent 协作，而不是单个助手
持久工作空间，而不是一次性会话
Browser、Terminal、Drive、Git 这样的真实执行环境
团队级编排，而不是个人级试玩
可长期运行、可隔离、可管理的基础设施

更具体一点说，Buda 的关键差别在于：

agent 运行在云端沙箱里，而不是薄薄的一层 API 调度
agent 有自己的 独立 Drive / 工作网盘
工作空间是隔离的，不同 agent 的上下文不会混在一起
agent 可以围绕真实执行环境去工作，而不是只返回一段文本结果
底层依赖的是更强的 Coding Agent 和 Agent Skills 体系

这意味着，Buda 更像是一个给 AI 员工准备的 operating environment，而不只是一个把 AI 接进来的 SaaS。

它不是简单地“支持 agent”。

它是先把 独立沙箱 + 独立网盘 + 持久工作空间 建起来，再让 agent 真正住进去工作。

简单说，Bika 让我们看到“AI 软件化”的起点，Buda 则是我们决定押注的下一阶段。

这不是一个轻松决定

我们知道，任何一次 pivot，外部看起来都可能像一句简单的话：

“团队调整方向了。”

但内部真实发生的，远不是一句话那么简单。

它通常意味着：

你要承认之前很多努力不能再按原计划继续展开
你要接受并不是所有积累都能原样延续
你要面对老用户、老页面、老叙事和新方向之间的张力
你要重新回答团队最难的问题：我们接下来究竟要为什么而战

对我们来说，最难的不是“想出一个新名字”，而是承认：

继续把 Bika 当成主战场，并不会把我们带到最想去的地方。

创业里有很多时候，真正难的不是做决定，而是停止自我说服。

我们经历了这个过程。

对 Bika 用户，这意味着什么

我们不打算把这件事说得含糊。

从现在开始：

Bika 会进入有限维护状态
我们会优先保证基础可用性，而不是持续扩张功能版图
新的核心产品投入，会更多放在 Buda

这并不意味着 Bika 立刻下线，也不意味着我们会突然中断现有用户的使用。

但它意味着一件更重要的事：

如果你想理解我们接下来的产品方向，或者想跟着我们未来的能力演进走，应该开始关注 Buda。

为什么我们想把这件事公开说明

我们不想偷偷把流量换掉，也不想让用户在一堆模糊文案里猜测到底发生了什么。

如果方向变了，就应该认真说明为什么。

因为用户值得被坦诚对待。

而且说实话，我们自己也需要这样一篇文章。

它不是一篇单纯的产品介绍，更像是一个阶段性的交代：

对过去做一个诚实总结
对今天的取舍给出理由
对未来的路线明确下注

这篇文章不是为了把 Bika 说得更差，好让 Buda 看起来更好。

相反，正是因为 Bika 足够重要，我们才觉得应该认真写下这段变化。

如果你愿意，欢迎来 Buda 看看

如果你一路跟着 Bika 走到这里，先谢谢你。

你们给过的反馈、提出过的质疑、真正用过产品的那些场景，都是 Buda 能走到今天的重要原因。

而如果你也关心这些问题：

AI 到底能不能真的替团队做事？
agent 能不能不只是 demo，而是长期工作？
未来的软件，会不会从“工具集合”变成“AI 员工组织系统”？

那我们真诚地邀请你来看看 Buda。

访问 Buda

我们不会说这条路已经完全清晰，也不会假装一切答案都已经准备好了。

但至少这一次，我们比以前更清楚自己要解决什么问题。

Bika 帮我们走到了这里。

而接下来，我们想把未来建在 Buda 上。