从 Bika 到 Buda：一篇关于挣扎、取舍与重新开始的说明
过去很长一段时间里，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。
我们不会说这条路已经完全清晰，也不会假装一切答案都已经准备好了。
但至少这一次，我们比以前更清楚自己要解决什么问题。
Bika 帮我们走到了这里。
而接下来，我们想把未来建在 Buda 上。
推荐阅读
推荐AI自动化模板
