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 的问题从来不是“不够强”，而是它在试图解决复杂工作时，也把复杂性一并带给了用户。
这是一种非常典型、也非常诚实的 tradeoff。
能力是真的有。
但入门也确实不简单。
而当一个产品的第一感受，开始从“有吸引力的未来工作方式”变成“这是一个功能非常完整、但需要学习成本的系统”，它的产品哲学就会被削弱。
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自动化模板
