TRAE终于把Code和Work合并了

< img id="wx_img" src="https://www.qbitai.com/wp-content/uploads/imgs/qbitai-logo-1.png" width="400" height="400"> TRAE终于把Code和Work合并了 十三 2026-10-09 17:19:57 来源： 量子位 金磊 发自 凹非寺 量子位 | 公众号 QbitAI TRAE ，刚刚做了个大动作。 以前的你，如果要改个bug，得打开TraeCode；要是还得出份技术方案，那又得一个 “闪身步” ，跳到TraeWork…… 现在，不需要这么麻烦了。 因为它俩今天已经正式 双端融合 ，统一升级成了 新的TRAE 。 新TRAE的一个亮点，就是它有Agent模式和IDE模式两种。 其中， Agent模式 主打的是 全局工作台 ，大家可以在一个窗口里管理项目，把不同工作分给多个Agent，写代码、出文档、准备交付材料都在这里推进。 IDE模式 里面依旧保留了SOLO和IDE两种玩法。两种模式的切换入口就在右上角，点一下就能过去。 例如前阵子让整个AI圈“卧槽”的 3D版鹈鹕骑自行车 ，在新TRAE里的“打开方式”可以是这样的。 我们在同一个项目文件夹里，新建三个任务，三个Agent各司其职： Agent 1：写代码，把鹈鹕、自行车和场景做出来； Agent 2：当测试，打开页面截图检查，列出一份问题清单； Agent 3：按给出的清单逐条修复存在的问题。 最终，它们就像一个小团队那样接力干活，把一个具备完整功能的3D版鹈鹕骑自行车给做出来了： 于是乎，这只鹈鹕，在新TRAE里就这么水灵灵地完整走完了开发、测试、修复、交付这一圈。 并且这期间所产生的测试报告、修复报告和交付说明等等，都自动存到了新TRAE里的 “我的产物” ，每个产物也都可以 直接分享给别人 。 清清楚楚，一目了然。 那么作为AI Coding领域 资深玩家 的TRAE，为什么要突然把这两个双端给合并了？ 对于小白和专业开发者，新TRAE又有什么区别？ 带着这些问题，我们不妨通过深度实测来感受一下。 小白也能从一个想法做出一款游戏 我们先来看下新TRAE能否让一个不会编程的小白，也能把自己的想法变成游戏。 恰巧Minecraft之父Notch之前还说AI Coding很糟糕，结果后来又发帖称自己还挺享受的，而且正给自己的地牢游戏做地图编辑器。 所以，我们第一个实测也来做一个能自己搭地牢、还能进去走的 3D地牢游戏做地图编辑器 。 这一次，我们在新TRAE里建好项目后，先同时开两个任务，一个负责写游戏策划，一个负责出界面设计稿： 可以看到，在我们下达指令之后，两个Agent便立即开始各忙各的了。 没过多久，两份成果就都交了出来。 策划Agent交出的是一份 Word版策划案 ，外加一份内容一致的Markdown文件，操作流程、每种元素的用途、验收标准，都写得明明白白。 设计Agent则是真的画出了一张高保真 设计稿 ，编辑模式和第一人称试玩模式两个界面都在一张图里，整体走的是低多边形的地牢风格： 接下来，我们再新建第三个任务，让它读取策划和设计的成果，开始 写代码 。 不过在这一步，出现了一个非常真实的小插曲。因为策划和设计是同时进行的，两个Agent谁也看不到对方的成果，结果就各写各的了。 比如设计稿里的网格是20×20，策划案里却是32×32；擦除工具的快捷键，一个定成了E，另一个定成了X；就连怪物刷新点，一个说全图只放1个，另一个说要放3个。 好在负责开发的Agent读完两份文件后，按照“先做出能玩的简单版本”的原则，把这些冲突逐条做了取舍，还把理由都写进了交付说明里： 这也说明，Agent一多，光有分工还是不够的，总得有个角色出来统筹全局。 在写完代码之后，开发Agent还自己打开浏览器测了一遍，顺手修掉了6个问题，比如一进试玩模式就弹出“已暂停”的窗口，又比如试玩画面太暗，连走廊都看不清。 最终做出来的编辑器，地板、墙、门、宝箱、拉杆、怪物刷新点都能随手放，撤销重做、自动保存、JSON导入导出也都一应俱全： 视频地址： https://mp.weixin.qq.com/s/tckIeqpzcq2jB11STQLTBg 值得一提的是，Notch正在做的新游戏，名字就叫《Levers and Chests》，直译过来正是“拉杆和宝箱”。 我们编辑器里的这两样东西，就当是给他的一点小致敬了[solute]。 同样的，在这个项目跑完之后，Word策划案、设计稿、设计说明，还有测试交付说明等等，全都整整齐齐地躺在“我的产物”里。 这要放到以前，这些产物要么埋在聊天记录里，要么散落在各个文件夹里；现在打开一个页面就能找到，想接着改，随时回来点开就行。 那如果我们要改特别细节的内容呢？ 一键切换IDE模式 ，了解一下。 我们在右上角切换成IDE模式之后，直接在对话框里输入： 把第一人称行走的速度调到70%。 没过一会，它就把行走速度从每秒3.4格降到了2.4格，奔跑速度也跟着同步下调： 简单来说，我们平时可以在Agent模式里让AI放手去干那些 复杂开发 ，到了要抠细节的时候，再回到IDE里一行一行地看，两种模式各有各的用处。 真实工作里也好用 做游戏固然好玩，但对于专业开发者来说，他们更关心的，可能还是新TRAE能不能扛住日常的工作。 那么接下来的实测，我们就直击程序员们经常会头疼的一个工作—— 接手老项目 。 为此，我们准备了一个名为TeamDesk的模拟项目。这是一个小型的任务管理网页，大约20个文件，数据全部是虚构的，项目里还附带了一份问题单。 这一次，我们直接在项目里一口气新建了三个任务，让三个Agent同时开工： Agent 1：读代码、搞懂项目，产出一份给新人看的架构说明； Agent 2：只负责修bug，不许碰测试文件； Agent 3：只负责补回归测试，不许碰业务代码。 Agent 1交出的架构说明是一份网页报告，用大白话讲清楚了这个项目分成哪几层、页面上的操作会怎样改动数据、数据最后又存在了浏览器的哪个位置。 负责修Bug的Agent 2则是先按问题单复现了一遍，找到原因之后，只改了一行代码，给统计加上了一个排除已归档任务的条件： 最后，Agent 3在补回归测试之后，呈现出了最终结果： 事后我们又对照了一遍原始代码，三个Agent都老老实实地守住了各自的分工，业务代码只改了一行，测试文件夹里也只多了一个新文件。 像这种回归测试，日常其实还可以交给新TRAE的 自动化功能 ，比如设定每天早上自动跑一遍，发现问题再提醒你。感兴趣的小伙伴可以自己试试： 再来看一个更贴近日常的场景， 一个人交付一个完整的迭代 。 这一次，我们给自己定的任务，是做一个名为FeedbackDesk的反馈处理台，拿到内部评审会上去演示。评审要用的东西包括一份产品需求文档、一个能操作的网页Demo，再加一份评审PPT。 同样的，我们还是一口气新建了三个任务： Agent 1：写产品需求文档； Agent 2：做网页Demo； Agent 3：出评审PPT。 没过多久，三个Agent就交出了各自的成果，分别是一份4页的Word需求文