AI IDE 正在撞上一堵墙，但不是大多数人以为的那堵墙。

过去两年，代码生成从补全片段进化到项目级 Agent，Cursor 的 ARR 在 18 个月内从零冲到 4 亿美元，Windsurf、CodeBuddy 们前赴后继涌进同一条赛道。

模型能力在进步，推理成本在下降，工具链在完善。如果你问一个开发者，AI 编程工具的上限在哪，他大概会说：在模型。

但真的如此吗？

AI IDE 真正的上限，不是模型能力，是用户范围。现有这批工具，把自己锁死在了一个从诞生之日起就只服务开发者的容器里。容器外面，需求早就溢出来了

——只是没有一款工具去接。

门槛才是产品的真正天花板

过去三十年，每一次界面范式切换，都是一次用户基数的数量级扩张。命令行时代，电脑是程序员的专属；GUI 出现，普通人才上了桌；移动触屏，让十亿人第一次用上智能设备。

AI IDE 这波浪潮，没有完成这个切换。

工具本身的能力不是问题。

腾讯的推出 AI IDE 产品 CodeBuddy 后，又顺势推出 WorkBuddy，本质上就是在寻找出路。

腾讯云 AI 智能体产品总监黄广民在会上接受采访时提到，内部用了 CodeBuddy 之后，"一个需求原来可能需要两周，现在两天就能完成"，代码生产效率翻了 4 到 5 倍。Cursor、Windsurf 们也都把代码生成做到了项目级别。

但这些工具服务的，始终是同一批人。

IDE 这种范式，本质上是为开发者设计的认知系统。目录树、编辑器、终端窗口——进去之后先要花时间理解我在哪、能做什么，面对纷繁的按钮和入口，不知道从何下手。

这是开发者第一次用 CodeBuddy 时的感受，对非开发者来说只会更陌生。

据说腾讯内部超过 1 万个非开发者在深度使用 CodeBuddy。他们不写代码，但在忍着看不懂的目录树和编辑器，硬撑着用下去——整理数据、做报告、跑流程。

这 1 万人不是目标用户，是越狱用户。他们的存在同时说明两件事：需求在，但门槛挡住了更大的市场。真正大量存在的泛生产力用户，根本没进来过。

WorkBuddy 的立项逻辑，就是从这个异常数字里长出来的。

进来是一个输入框，场景化入口告诉你能做什么，做完有预览，预览完能分享。

黄广民把这条路径叫做"使用生命周期"，说人话就是：从进门到用完，每一步不让人懵。他还提到，WorkBuddy 专门做了"非常多的产物预览能力，这在 CodeBuddy 里是没有的"，为的就是满足泛生产力人群"做了一个东西需要看结果"的需求。

把 WorkBuddy 理解成"简化版 CodeBuddy"是个误读。

两个产品的差异不在功能多少上，而在范式上。

开发者需要 Code Review、评论、改动追踪；非开发者需要产物预览、结果可见、流转分享。这两套需求本质上不兼容，混在一起只会让两边都难受。

还有一个容易被忽略的时间线细节：WorkBuddy 立项时，OpenClaw 还没火爆。黄广民在采访中说得很干脆："我们做的时候其实完全没有参考养虾热、生态兼容、MCP 接入，是 OpenClaw 突然爆火之后才接过来做兼容的运营动作，不是产品的起点。

OpenClaw 点火，谁来接盘

OpenClaw 做了一件很微妙的事：它制造了需求，然后没能接住。

它让几百万非开发者第一次意识到，AI 可以帮我执行任务，不只是回答问题。但 OpenClaw 本身的体验对小白极不友好——权限要求高，Token 消耗归用户自己，装完了不知道能做什么。大量用户装了卸、卸了装，在"想用"和"用不了"之间反复横跳。

这在商业上造成了一个特殊结构：需求被点燃了，供给侧没有接住。

WorkBuddy 正好卡在这个缺口里。它的定位不是跟 OpenClaw 竞争，而是承接 OpenClaw 失去的那批用户，降低门槛，提供专家入口，告诉用户虾能帮你做什么。

更值得关注的是 WorkBuddy 内测版的诞生方式。

黄广民在采访中说："这个产品只用了一个周末，就 2 天的时间，我们就完成了它从 0 到内测版本的生成，而且这个版本是由产品经理用 CodeBuddy 这个软件做的。"

没有开发同学参与，从 0 到能用。这个细节的意义不只是"迭代速度快"——它是一次自我验证，证明了"用 AI 工具造 AI 工具"这件事，产品经理可以独立完成。

本地是起点，不是终点

打破 IDE 的边界，是第一步。打破"本地"本身，才是更大的问题。

黄广民在发布会上画了一个两轴四象限：横轴是 Agent 运行环境（本地/云端），纵轴是解决的问题域（软件生产力/泛生产力）。

CodeBuddy 和 WorkBuddy 目前都在左侧——本地。

Workbuddy真正想做的，是往右边走。

逻辑是软件开发流程里，只有编码阶段必须在本地机器上跑。他描述过一个理想状态："围绕一个产品，当你的需求、你的 Idea 提出的时候，后续所有的流程完全可以在云端调度 Agent 帮你完成，人需要做的只做最后的验收。

"云端 WorkBuddy 的想象则更直接：几个人加入同一个对话，各自驱动自己的 Agent 完成分工，产物在会话里合并，交付。现在协作做 PPT 的方式，要么共享文档各自编辑，要么各做各的最后拼，在这个框架下都会被替代。

这里有一个被低估的产品命题：现有的协作工具，从来不是围绕 Agent 设计的。

腾讯文档、飞书做的是"人与人协作"，路径是共享文档、评论、权限管理。

但如果每个人背后都有一个 Agent 在帮他干活，协作的单元就不再是"人"，而是"人+Agent"的组合。

没有一款现有的协作工具为这种模式设计过。

拿来对标的参照物是 Manus。Manus"更多是解决了泛生产力在云端的问题，但解决的更多还是超级个体怎么在云端解决问题"，没有做本地产品，也没有做云端团队协作。"本地还有空间，云端团队协作还没人做好。"

这个判断合不合理，取决于时间窗口能不能守住。

黄广民回答采访时说云端协作"可能在 1 到 2 年就能看到"，最大的瓶颈不是技术，而是数据，"每个人都能让自己的 Agent 连接好自己的数据、自己的上下文"，这个前提条件现在还没有成立。

AI 产物能不能回流到原有 SaaS 里，每个人的私域数据能不能被自己的 Agent 顺畅调用，这些才是协作落地真正的卡点。

谁先解决数据孤岛，谁才真正控制了云端的入口。

写在最后

WorkBuddy 的诞生不是战略推演的产物，是一个统计异常被认真对待的结果。1 万个不该在 IDE 里的人，用行动告诉产品团队，容器外面有更大的市场。

接下来要打破的是本地的边界。这次有规划，有路线图，有悄悄开着的云端内测入口。但真正的竞争不在于谁的 Agent 能力更强，而在于谁先把数据从孤岛里解放出来。

AI 工具的下半场，拼的不是智力，是管道。