实测新版TRAE：豆包工作越能干，专业IDE越尴尬

国庆结束后，一名TRAE开发者发现，自己要多走一步，才能回到熟悉的编程界面。

他此前一直使用TRAE IDE。升级之后，客户端默认打开的是Agent工作，想继续写代码，需要手动切换到IDE，再重新选择之前的项目。更让他不满的是，软件没有提供明确的默认启动模式设置，关闭窗口后，还会留下一个常驻托盘图标。他在TRAE官方社区发帖，问能不能给只想使用IDE的人留一个选择。

10月9日，TRAEWork和TRAECode正式合并。前者主要处理文档、数据和办公任务，后者服务软件开发。合并后的TRAE同时保留Agent和IDE两种模式，希望用户从提出需求开始，一直做到开发、测试和交付，不必再分别打开两个客户端。

不到两个月前，字节刚刚对AI办公做过一轮整合。TRAE、扣子团队整体并入豆包体系，原有办公能力向豆包集中，TRAE IDE及CLI继续作为编程产品线发展。字节回应称，调整是为了加强产品和技术资源协同，第二天，统一的AI办公产品“豆包工作”正式发布。

更早的7月30日，字节已经将飞书产品团队与豆包产品团队整合，交由豆包负责人赵祺管理；飞书的销售、市场和客户服务团队则与火山引擎整合。这几次调整指向同一目标：把原本分散在不同团队里的模型、办公产品和企业客户资源，尽可能放在一起。

字节在组织上做减法，TRAE却在产品上做加法。按照8月的安排，外界原本有理由认为，通用AI办公会越来越集中到豆包工作，TRAE则继续服务开发者。但10月的新版本并没有沿着这条界线往下走。

TRAE不仅保留了对文档、汇报和数据处理，还把管理多个Agent的工作台放到了产品的重要位置。豆包工作同样能制作PPT、生成网页和应用，也已经开始支持复杂任务规划、多Agent协作，两款产品的能力，仍然有很大一部分重叠。

如果豆包工作已经能够处理这些任务，TRAE为什么还要再做一遍？而如果TRAE留下来的主要理由是编程，为什么又要把这么多编程之外的工作放进来？

豆包工作能干的活，TRAE为什么还要再做一遍？

TRAE原本是一款面向开发者的AI编程工具。

2025年1月，TRAE国际版上线。半年后，它开始尝试让AI接手更多编程步骤。7月21日推出的SOLO模式，可以根据需求理解项目、生成代码、调用工具，再运行程序并检查结果。

原来，开发者写代码，AI在旁边给出建议。到了SOLO模式，用户可以直接交代一个任务，由AI决定先做什么、后做什么，人再回来检查。

TRAE也由此积累了一批使用频率很高的开发者。去年12月26日发布的2025年度报告显示，TRAE全球注册用户超过600万，月活超过160万。全年约有6000名用户，使用TRAE写代码的天数超过200天。

问题也从这里出现，当AI开始负责完成一个开发任务，写代码反而只是其中的一部分。TRAE在10月的产品介绍中，举过一个活动报名网站的例子。开发者需要先整理报名规则，决定页面应该有哪些内容，用户填写的表单如何处理，再编写代码、测试功能，最后准备说明文档。

如果网站只是为了在会议上演示，生成一个能打开的页面可能就够了。但真正投入使用后，事情还没有结束。报名人数多了，要增加新的筛选条件；有人提交了错误信息，需要修改表单；活动规则发生变化，原来的代码也得跟着调整。

以前，这类工作分散在不同软件里。TRAEWork可以处理文档、表格、PPT等办公任务，TRAECode负责代码编辑和调试。一个项目从需求变成软件，再从软件变成可以交付给别人的成果，往往要在两个客户端之间来回切换。需求在一个地方，代码在另一个地方，测试结果可能还留在某次聊天记录中。

对开发者来说，切换工具真正麻烦的，是接下来还得弄清楚，上次的工作究竟做到了哪里。

10月9日的合并，首先想解决这件事。新TRAE把Agent工作台与IDE放在一起。用户可以在Agent模式下管理多个项目，让不同Agent分别处理需求、代码、测试和文档；需要仔细检查程序时，再进入IDE，查看文件、修改代码、调试运行。自动化任务、模板和项目产物也被放进统一的工作流程。代码变更、HTML、Word、PPT和报告，都可以在“我的产物”中集中查看。

从这个角度看，TRAE并非突然决定进入办公市场。它原本服务的开发工作，正在变得不那么容易与办公分开。但这些能力，并非TRAE独有。8月25日发布的豆包工作，已经能够完成文档、PPT、数据分析和轻量应用生成。用户可以在授权范围内操作电脑、调用外部服务，也可以让多个Agent分别完成任务。

9月23日，豆包工作又推出“目标模式”和“计划模式”。前者允许用户提前设定验收条件，由Agent在交付前检查结果；后者则先生成任务方案，等用户审阅、修改和确认之后再执行。这两种模式，都在试图减少Agent长时间执行任务时出现的偏差。

如果只是整理需求、生成网页，再准备一份演示材料，两个产品都已经具备相应能力。

《新立场》将12条模拟员工反馈分别交给豆包工作和TRAE，要求制作离线管理看板，并交付评审说明和验收记录。两边使用相同材料与指令，保留各自起始模式。

客户端显示，豆包首轮用时3分45秒，TRAE为19分25秒，统计、搜索和筛选均通过独立检查。随后，我们追加同一组修改：关闭旧反馈、增加新反馈，加入逾期筛选，让状态修改在刷新后保留。两边也都完成了任务，豆包用时4分钟，TRAE为18分5秒。

TRAE自行做了浏览器测试，修复了一处逾期标注遗漏；豆包没有做浏览器实测，但交付后的独立检查通过了这些功能。对只想整理反馈、准备评审的负责人，豆包工作已经更快交出了可用、可继续修改的小工具。

至少对这套只有12条模拟反馈的小工具来说，专业开发环境还没有表现出不可替代的优势。

如果整理需求、生成网页、修改功能和准备评审材料，豆包工作都能更快完成，那么开发者究竟要把项目做到什么程度，才需要打开TRAE？

生成之后，TRAE还能留下什么？

《新立场》的测试只进行了两轮任务。那套反馈看板虽然通过了功能检查，但它只有12条模拟数据，没有接入真实业务系统，也不需要处理不同员工的账号和权限。如果把它真正交给一个部门使用，接下来要解决的事情，可能比生成网页复杂得多。

对字节来说，同时保留两个入口，未必是一件不合理的事。两款产品虽然能够完成相似的任务，但原本积累的资源不同，用户进入产品时，想解决的问题也不一样。

豆包工作的优势，不只是它能调用模型。7月30日，飞书产品团队与豆包整合时，字节明确表示，飞书现有产品和服务保持不变。彼时，豆包企业版已在部分飞书客户中内测，支持在授权范围内使用飞书文档、表格、会议和群聊等信息。9月15日，飞书又推出豆包工作伙伴，尝试让Agent拥有独立身份、权限和记忆，直接参与团队协作。

梁汝波也在飞书未来无限大会暨豆包工作开工大会上解释了整合豆包、飞书和火山引擎的原因。他认为，Agent进入可用阶段后，模型、Agent和协作环境必须更紧密地结合。

这让豆包工作获得了TRAE原本并不擅长的一种资源：企业已经积累的工作关系。

拿《新立场》测试的反馈看板来说。如果将来真正接入一家公司的工作系统，员工反馈可能来自飞书表格，也可能散落在群聊和文档中。哪些反馈由谁处理、哪些内容只能由管理者查看，往往已经有相应的账号和权限规则。

如果Agent能够在员工现有权限内读取这些资料，就不必每次重新上传文件、解释业务背景。反馈处理完毕，也可以继续留在原来的协作环境里，让相关同事查看和修改。

用户未必需要重新搭建一套办公环境。他需要的是AI知道公司原本怎么工作，再替他完成其中一部分。飞书积累多年的账号、成员关系、业务资料和权限，正是豆包工作可以借助的东西。

但能读到公司的资料，不等于这套看板就能在公司里长期使用。员工提交新反馈后，数据能否自动更新；管理员关闭一条反馈，其他人的页面会不会同步变化；如果业务部门提出新的统计要求，原来的程序又该怎么修改？

这些事情陆续加进来，原本只需要演示的小工具，就可能变成一个要持续开发的软件项目。TRAE原来的开发环境，在这里才可能体现出更多价值。

开发者可以从Agent工作台开始，等项目复杂起来，再进入IDE检查代码、修改文件、运行测试。如果一处修改影响了其他功能，也可以回到原来的项目中定位问题，而不是重新生成一套网页。

不过，拥有专业IDE，并不等于一定能把项目维护得更好。在《新立场》的测试中，TRAE进行了浏览器测试，豆包工作没有执行同样的步骤，但最终都通过了功能检查。两轮任务还不足以判断，当项目需要连续修改几个月时，哪款产品更可靠。

两款产品的边界，还不止在开发能力上变得模糊。根据TRAE官方文档，用户授权之后，可以通过飞书CLI直接读取云文档、多维表格等资料，也可以修改相应内容。开发者甚至能够在TRAE中读取飞书里的需求文档，生成代码和测试用例，再将开发进度写回飞书。

豆包工作开始接手开发任务，TRAE也开始进入企业办公环境。两款产品正在从不同方向靠近。

但能够访问同样的资料，不等于可以接续彼此的工作。如果一名员工在豆包工作中整理好需求，开发者随后在TRAE中修改程序，最后又交给业务部门在飞书里验收，这中间不仅涉及几份文件，还涉及任务记录、代码版本，以及不同员工可以查看和修改哪些内容。

TRAE已经能够在授权范围内操作飞书资料，但公开资料还不足以证明，它与豆包工作之间的任务状态、对话历史和项目文件已经完全互通。

甚至在TRAE自己的办公助理里，这种衔接也存在限制。官方文档显示，通过不同通讯工具发起的会话，不会自动合并上下文。在群聊中，目前只有办公助理的创建者能够委托任务，其他成员只能查看记录。

豆包工作伙伴则尝试另一种方式：让Agent拥有独立身份、权限和记忆，作为团队中的一个协作对象。不过，这项产品能力也还需要在更多真实企业环境中接受检验。能从飞书里向TRAE发出指令，与让TRAE真正接手团队的一项工作，是两回事。

字节已经让两个团队在组织上更接近，也让两款产品接入越来越多相似的能力。对用户而言，问题却没有因此自动消失。今天在豆包工作中整理的需求，明天可能要交给TRAE开发；TRAE完成的工具，最后又要回到飞书，让业务部门使用。

如果每次换一个产品，都得重新交代任务、确认文件和处理权限，那么字节保留的两个入口，仍然会让用户多做一部分工作。

字节可以让两个产品继续扩展各自的能力，但用户的工作不会因为团队完成了整合，就自动知道该从哪里开始，又该在哪里结束。

10月9日那名抱怨新版TRAE的开发者，想要的其实很简单：打开软件，继续写代码。

但在《新立场》的测试中，豆包工作已经能够更快地完成一套反馈管理看板，第二轮修改也通过了检查。至少对于这类轻量任务，用户暂时没有多少非得打开TRAE的理由。

另一个问题是新用户会不会持续回来。如果一名运营人员只是用TRAE做了一次网页演示，它与豆包工作的区别并不明显。但如果这个网页后来变成一套内部系统，需要不断增加功能、修改代码、修复问题，那么TRAE原来的开发环境就可能变得更有价值。

TRAE需要同时服务这两种人：一批已经习惯在IDE里工作的开发者，以及一批可能从办公需求开始、逐渐需要开发工具的新用户。

如果豆包工作逐渐具备更可靠的开发、测试和维护能力，TRAE能够留下的工作还可能继续减少。反过来，如果用户愿意在TRAE中持续修改、维护一套应用，而不是生成一次就离开，它也就有了独立入口的价值。

*题图及文中配图来源于网络。