讨论下字节和鹅厂work和code产品的跨产品交叉使用

为什么公司选择：自研 Agent，复用 Code‑OSS（而不是从头写 IDE） 

 商业上算账非常清晰：  

1. 在code的产品中， IDE 是 “必须有，但不是卖点”。 因为我没有IDE还可以通过插件的方式 提供给IDE工具。 

用户使用的目的是为了体验和使用 AI Agent，不是为了一个新编辑器或者一个新的IDE。 如果编辑器体验差、快捷键不对、插件少，用户直接跑路。 

2. Agent 才是核心新的新质生产力，是能卖钱、吸引用户的东西。 而且初期开发一个AI Agent 是简单可使用的Demo速度很快的，可以快速的先把用户引流进来，然后持续迭代和改进。

3. 复用 Code‑OSS： 团队规模可以集中在 AI 侧，不用养一大堆编辑器底层工程师。 

那么今天我们主要是分享下work 设计和开发完的项目工程，如何无缝的且到code产品下去继续维护代码？

字节 Trae work和Trae code

字节的产品团队在初始阶段，就已经考虑到了。 通常我们用work， 设计了产品、初始化了代码工程。 接下来我们需要人工review、人工局部代码修复 并和AI Agent结合工作时，此时我们必然需要使用到 trae code了。 不可能所有的工程过程，我们完全依靠一个 “提示词输入窗口”全部搞定了。至少目前传统的工程师还是很难完全接受的。 

此时我们在work的当前工作任务当中，在AI Agent 工作窗口标题处右侧，有一个下拉选项，点击后，可以看到有如下选项（本人是MacOs）

1.Trae code （国际版本 trae code）

2.Trae code CN （中国版本 trae code）

3. terminal 

4. finder （文件浏览）

鹅厂的  work buddy和 code buddy

获取工作空间产出文件的目录，然后在code buddy（ide）中手动选择打开项目目录。

如下图示例，点击…更多操作后，可以选择保存到工作空间。此时就不是work默认的工作目录了。 

然后再选择打开文件夹

此时获取到最新的文档目录，再用 code buddy（ide）打开该目录。

这么看鹅厂的work buddy和code buddy压根没有过多的考虑2个产品的直接关联而是作为完全独立的2个产品来做。所以我用work buddy的时候，完全可以用idea 或者jetbrain的IDE 加上 code buddy的AI agent插件 完全可以替代 code buddy(IDE)独立版本。

孰优孰劣，不做评价。如果AI Agent插件的能力真的和 code Agent（IDE)版本的能力一样的话无可厚非。

实际上，当 Agent 能力强到一定程度，原有 Code‑OSS 插件 API 不够用的时候，就必须要去 fork、修改内核（Cursor/Trae 目前就是这个阶段）。 插件 API 能力有上限：插件只能被动接收事件，不能无缝接管整个文件缓冲区、不能深度接管终端执行链路，做真正自主 Agent 会受限。

所以code buddy早晚还是可能会考虑 修改vsCode 内核源代码，其对应的IDE AI Agent也是重要的一环产品。

此篇文章已被阅读7 次