（来源：光子星球）
撰文| 郝 鑫 高晓阳
编辑| 郝 鑫
10月9日，字节宣布TraeWork与TraeCode合并为全新的TRAE。TRAE的定位从“AI Coding工具”升级为“AI Development平台”，一个入口承接所有任务，Agent模式和IDE模式无缝切换，从一句想法直接走到能打开、能点击、能交付的产品。
恰好在合并官宣的同一天，TRAE原负责人石扬被曝离职，其个人平台确认字节任期到2026年9月结束，同月开启新项目，状态为“Stealth Mode”。
TRAE的前身是豆包MarsCode，2024年推出，石扬接手后主导了从插件形态向AI原生IDE的转型。
2025年1月，TRAE国际版正式发布，3月国内版上线，搭载豆包模型并支持DeepSeek切换，完成全球市场覆盖。同年7月，SOLO模式发布，将浏览器、终端等工具纳入同一上下文，探索端到端开发。8月，TRAE与扣子团队整体并入豆包体系，组织归属调整为编程产品线，由赵祺统一管理。
在Workbuddy的影响下，大厂一头扎进了AI办公的竞争中，开始收拢内部AI产品线，转向平台化协同。字节也不例外，一手主导了以豆包为品牌核心的整合。
在内部调整下，TRAE两面夹击的困境逐渐暴露。外部，Claude断供动摇了技术信任，Cursor等竞品持续分流；内部，并入豆包后，TRAE从独立产品降级为体系中的一条产品线，服从于豆包的推进节奏。
再次出发的TRAE，“新”在哪里？又将面临怎样的挑战？
组织、品牌和产品的三级落地
首先需要定义TRAE此次的合并性质，两款产品的合并只是最外层的表现，内核是TRAE在字节AI大盘中重新找到了自己的位置：不做泛办公，专注做开发。
在今年8月份的整合中，字节已经画出了一条分割线，TraeWork、扣子与豆包在工作场景的产品能力进行整合；TRAE IDE及CLI则作为豆包品牌下的编程产品线继续发展。
这意味着，在字节的大盘中，办公场景归豆包工作，而编程场景归TRAE。背后体现了字节整体战略逻辑的切换，过去依靠多团队并行试错的“赛马机制”，正在让位于更强调组织效率和商业落地的“合兵模式”。
字节CEO梁汝波在全员会上将豆包定位为“主干”AI业务，明确要求“高度优先、粗主干”。TRAE作为“主干”上的编程分支，必须找到自己在主干中的位置，而不是另立一根枝干。
组织划清后，品牌必须跟着划清。保留TraeWork和TraeCode两个品牌对外并行，等于继续向用户传递“这是两个产品”的认知。因此，10月的合并，本质是一次品牌层面的身份收拢。TraeWork不再作为一个独立产品存在，其开发相关能力被吸收进TRAE，办公相关能力则交还给豆包体系。
官方表述也印证了这一点，“过去TraeWork更偏向办公、任务和内容生成，TraeCode更专注专业开发者的编码需求。双端融合后，全新TRAE用一个统一入口承接这些连续任务”。
品牌统一后，产品层面才能做真正的融合。合并后的TRAE提供了两种模式。Agent模式适合从想法拆解到交付结果，支持跨项目调度多个Agent并行推进；IDE模式保留完整的智能开发环境，适合单项目深度代码编辑与精细调试。两种模式共用同一套工程上下文，切换时无需重新导入项目，聊天记录、账号数据、积分等完整迁移。
调整后，TRAE把两个产品的身份合并成一个开发平台，不再需要同时扮演“办公助手”和“编程工具”两个角色，其产品形态变得更纯粹。
这也让TRAE在字节AI大盘中重新找到了定位。不跟豆包工作抢通用办公、文档、协作入口，把资源押在AI原生开发平台上，覆盖从需求拆解、编码、调试到任务管理的完整链路。
通过合并，TRAE最终完成了战略聚焦，收缩的是场景边界，集中的是资源和定位。
合并是结果，不是原因。真正变化的是TRAE在字节AI版图中的生态位，从办公AI之一变成了豆包体系下的开发平台。
实测1：生成记账工具并修改bug
借着这回TRAE的升级，我们来实测一下新的功能。
首先，直接验官方最核心的功能，“从想法到可打开、可点击、可迭代的Demo”。
官方举的例子是制作活动报名网站。我们换了个场景，生成一个记账工具。理由很简单，在验证官方DEMO能力外，记账工具比报名网站多了一层数据可视化，需要接图表库，更能看出代码成色。
在Agent模式下输入需求，制作一个记账网页应用，需要有表单、有账单列表、有月度收支统计、有支出分类的饼图，数据存在本地，能删记录，最后提供一份说明文档。
TRAE把任务拆成了两步，先搭项目结构，再实现记账表单。20分钟后，我们拿到了一个能直接在浏览器里打开、能用的工具。
开发的过程是可视化的，你可以看到TRAE正在做的事情，调试、测试的过程一清二楚。这是一个很新奇的体验，因为TRAE不只让用户看到它的思考过程，执行过程也摆在了明面上。
当然，这些之前的TRAE也能做到，这次合并之后的新功能，是双模式切换。我们点击右上角的“IDE”按钮就可以切换页面，然后就可以在IDE模式查看或者修改刚才Agent模式下生成的代码。
这一步的意义在于，以前做这种小工具，得在AI对话工具和编辑器之间来回切换。现在同一个软件里就把创作和修改都包括，这是合并带来效率提升。
Vibe coding出一个项目不会一帆风顺，偶尔会遇到一些bug。这些bug或大或小，大bug还好描述，一些文本框里面出现的显示问题，这种小bug才是最烦人的。我们需要花一定的篇幅去描述bug出现的位置，而且Agent最后还可能把相邻区域同步修改掉。
我们今天就遇到了这种情况，有个文本框出现了文字重叠的bug。这次我们没打字描述位置，直接选定编辑模式，用鼠标点中有问题的文本框，通过语言描述来修改。
结果是，修改一次到位，精准修改出bug的地方，也没有出现多余改动。
这个“指哪改哪”的体验，对经常要调前端页面的人来说，是实打实的效率提升。它把“描述位置”这个最容易出错、最费口舌的环节，直接省掉了。
实测2：制作一份AI日报
“代码”之后，我们想看看TRAE在“办公”方面的成色，也就是从TraeWork继承过来的自动化能力。
“自动化任务”无非就是把重复流程交给Agent定时跑。我们直接测试了它的招牌场景，让TRAE每个工作日早上7点，自动搜集过去24小时的AI行业新闻，整理成带标题、摘要、来源链接的简报。
我们手动触发跑了一次，成功出了一份简报，内容相关性也不错。
可问题不在于它能不能出结果，在于结果的可信度如何。
我们跑出来的那份简报，明显偏向国外新闻，大概率是因为我们没在指令里指定国内信源。
更根本的问题是幻觉。目前市面上大部分AI自动化日报的短板，都不在“获取信息”的能力上，而在“信息处理”上。模型有时会一本正经地胡说八道，包括但不限于新闻发生的时间和新闻中主体之间的关系，这是影响日报准确性的最大因素。
指望模型自己进化到没有幻觉，那是后话。现阶段更实际的做法，是别让自动化任务停留在简单的提示词驱动，要结合代码程序把流程拆开，把任务切成很小的块再交给模型处理，用工程手段把准确性抬上去。
实测3：模板库和助理还有优化空间
最后再来看“模板库”和“我的助理”两个功能，这是TRAE所强调的“整合能力”。
先看模板库。数量不少，大概150个模板，覆盖内容创作、数据分析、投资与金融等9个场景。TRAE的思路是，高频任务不用每次从空白页开始，而是基于模板快速启动。
理想很丰满，现实很骨感，我们实测发现，点“做同款”按钮，根本没反应。 功能上线的初衷很好，但很显然上线初期还没完善。
万事没有绝对，当我们最后要截图的时候，点击“做同款”突然可以跳转了，当时心情很复杂，就像考试时自己发现了卷子上的题是无解的，然后举手示意老师，老师走到跟前还没开口，自己又发现了是因为自己少看了一部分印刷不清楚的题干。
为什么是“一部分印刷不清楚的题干”呢，我们第一次测试“模板库”时，点击“做同款”这个按钮确实没有反应。我们复盘了测试流程发现，在第一次和第二次测试之间，我们只执行了一次飞书扫码连接“我的助理”的测试，所以推测是因为这两个模块之间存在一种bug。
为了严谨，在解绑“我的助理”之后，再次做了测试，结果如图所示，又无法正常跳转了。
事情并没有到此结束，第三次测试时，即便已经用飞书连接了“我的助理”，“模板库”中的功能依旧无法正常使用，最后我们用重启TRAE的方法才成功让“模板库”中功能恢复正常。
结合这三次对“模板库”测试来看，只能得出这个bug，并没有固定触发方式的结论，真是“一个bug是bug，几个bug能work”。
所有的测试完成之后，我们还发现了一个贯穿始终的问题，“我的产物”里面始终是空白。不同于“我的模板”里面不固定触发的bug，“我的产物”到最后也没有任何文件被呈现。
官方把“项目产物统一管理”当成一个重点来讲，说代码、文档、图片、报告都会统一进入“我的产物”，不用再从聊天记录里翻找结果，让每次AI协作沉淀为可回看的资产。
这个痛点是真实存在的，谁用AI干过活谁知道，结果散在一堆聊天记录里，找起来要命。
但这次TRAE只是把产出的代码文件放在了本地文件夹，根本没有同步到云端的产物里。也就是说，官方宣称的“统一沉淀”，在当前这个版本里是缺席的。一个用来解决“结果散落”痛点的功能，本身就是散落状态的。这个bug还是需要官方来抓紧修复。
合并之后
TRAE合并之后的挑战才刚刚开始。组织收拢和品牌收拢可以在一个月内完成，但产品收拢能否真正成立，还需要更长时间来验证。
从合并后用户社区和开发者的实际反馈来看，情况比“有待完善”要复杂得多。以我们亲身体验来看，至少还没有达到全链路开发平台的目标，出现了模板库“做同款”失灵和“我的产物”为空白等情况。
更加现实的考验在于，TRAE的商业化能否进一步落地。字节架构调整后，TRAE企业版不再独立获客，而是通过火山引擎的GTM组织触达企业客户。
这个安排在效率上有一定合理性，企业客户可以通过一个入口采购算力、模型和开发工具，避免了过去飞书、火山引擎、豆包三条线各跑各的客户和各自报价的内耗局面。但问题也很明显，TRAE在火山引擎的销售优先级处于什么位置？
TRAE在客单价和营收贡献上远低于模型调用业务，销售团队天然后向高价值产品倾斜。TRAE能否获得足够的销售推力，取决于火山引擎内部如何设定优先级。即使定价有竞争力的情况下，TRAE仍然要先在豆包和火山引擎体系内跑通。
总体来看，组织和品牌收拢，解决了TRAE归谁管、叫什么的问题。
而产品收拢要回答的是，在一个竞争不断，内部资源需要持续争取，用户心智尚未完全稳固的环境下，TRAE能不能把双模式融合的“真功夫”，扩展为一个真正完整的开发链路。
微信号｜TMTweb
公众号｜光子星球
别忘了扫码关注我们！
