越来越多的玩家开始涌入 AI Coding 赛道。
从面向普通用户的低代码平台，到服务专业程序员的 IDE，几乎每个场景都在尝试 AI 的可能性。
作为国内首个 AI Native 的 IDE，TRAE 对于 AI 如何更好参与程序员的工作流程，甚至于软件开发的全流程，有很多自己的想法。
TRAE 的产品经理 Leon 认为，真正的未来在于「AI+工具」的模式，即构建一个以 AI 对话为核心的统一工作空间。也是基于此，TRAE 推出了 Solo 模式。
在 AGI Playground 2025 上，Leon 详细分享了构建一个真正的「AI 工程师」所需的核心能力、对于 AI Coding 产品未来形态等思考，以及 TRAE 的核心功能及使用场景。
以下内容基于演讲内容，由 Founder Park 整理。
超 7000 人的「AI 产品市集」社群！不错过每一款有价值的 AI 应用。
-
最新、最值得关注的 AI 新品资讯；
-
不定期赠送热门新品的邀请码、会员码；
-
最精准的AI产品曝光渠道
01
编程语言的发展
是不断抽象和求简的过程
代码和软件作为基石，塑造了互联网时代的繁荣。在 AI 驱动的今天，它正在开启下一轮的跃迁。
让我们把时钟拨回到计算机诞生之初，写代码这件事情是如何一步一步演进到当前这个阶段的？
最开始的一个阶段是机器语言和汇编语言。那个时候的开发者，需要在纸带上进行穿孔来表示 0 和 1，用这种方式来进行编程。随着 50 年代左右高级语言的诞生，程序开发者们逐渐地从直孔打带的编程方式中解脱出来；到了 60、 70 年代， C 语言横空出世，奠定了面向过程的函数式编程的基础，同时 C 语言的出现也为大型软件的出现提供了可能；80 年代，整个软件开发的范式逐渐面向了一些对象化、封装化；直到 90 年代到互联网的兴起，Java、Python、 Javascript 这些语言的出现，真正让编码这件事情走向了大众化，
但编程语言的改进始终没有停滞，从 2000 年开始到现在，随着语音技术的不断发展，不断有新兴语言出现。比如像 Go、Rust、 Scala 等语言的出现，都在围绕着一种更高效、更加并行化、更加稳定的方式去演进。
纵观整个编程语言的发展史，其实是一个不断抽象和求简的历史。在同一个功能上，最开始的汇编语言可能需要 2000 行代码来实现；用 C 语言的时候可能 500 行就可以了；到了 Python 可能 100 行就能完成整个逻辑的书写，这大大降低了大家重复工作的成本。
随着编程门槛的不断降低，也带来了开发者人群的指数级增长。 90 年代左右，全球开发者大概有百万量级；2023 年，仅 GitHub 的注册开发者就达到了破亿的规模。每一次代码的抽象升级，都在围绕着代码更少、效率更高、参与者更多而进行。
如今， AI Coding 正在酝酿下一次的飞跃，通过自然语言生成代码、自动补全你的代码逻辑、智能调试 debug 的方式，让写代码这件事情不再是少数人的技能，而成为更多人实现想法的手段。这不仅是生产力的飞升，更是开发者边界的重塑。
02
好的 AI IDE：
模型、产品、工程缺一不可
我们团队希望通过 AI 的能力，帮助全球开发者提升整体的研发效能、加速软件的创新。不仅是想提供一个更强大的 AI 编程工具，我们更希望通过构建一个智能的 AI 工程师来实现这个目标。我们希望它能成为每位开发者的智能协作伙伴，就像一个真正的 AI 工程师。在我们的设想里，这个 AI 工程师不仅能编写代码，更具备自主理解、思考、优化和协作的能力。它不再是被动执行指令的工具，而是能够分析需求、优化方案、提供智能建议，并且能持续学习，去理解和适应开发者的风格，实现真正的人机深度协作。
这其实正是 TRAE 这个名字的由来——The Real AI Engineer，一个能够与人类协同工作的 AI 工程师。
如同过去的织布机能让织工从手工抛梭中解脱出来一样，TRAE 也希望能把开发者从重复性的业务代码中解放出来，让他们可以更专注于架构设计和产品构建。
一个好的 AI IDE，应该是产品能力、工程能力和模型能力三者的有机结合。
首先，产品得「听得懂人话」，这样它才能参与到和工程师的协作中。在 TRAE 里，我们不是通过写命令或点按钮的方式来操纵 AI，而是希望从底层构建一种目标驱动的交互模式。开发者可以用自然语言描述希望实现的目标和任务，由 AI 来理解任务、生成文件结构、自主拆解模块、补全代码，并自动构建出整个网站的页面。
AI 要想完成整个开发任务，还需要具备处理执行细节的能力，比如：如何拆分任务目标？任务之间如何衔接？流程卡住时如何中断和恢复？为了解决这些问题，TRAE 从底层构建了一个任务调度框架来支持 Agent 模式，使其具备并行执行、异步控制、中断回调与状态追踪的能力。
比如，用户可能会对 AI 说：「我需要一个管理页面，帮我配置一下权限，再把这个页面和我的数据库打通。」 这时候，AI 就需要根据需求自主地拆解任务，生成一系列子任务，例如：生成页面、配置权限、构建数据表等等。
同时，我们希望 AI 能够根据这些任务间的依赖关系，按顺序进行调度执行。在执行任务的过程中，AI 难免会遇到失败，但它也能够自动回滚或重试。所有这些交互和执行的底层逻辑，其实仍然是基于模型本身的能力，比如模型的自然语言理解、结构化推理、代码生成等能力，这些决定了 AI 对用户意图的把握程度和对复杂上下文的处理深度。再比如说，你可能会给 AI 一段业务代码，对它说：「你帮我优化一下这段代码。」 这时，AI 就必须去理解当前代码的业务逻辑，识别出其中的冗余和可改进之处，并生成语义上等价的优化代码。
这三种能力其实并非孤立，而是相互支撑的。就像人一样，在这个过程里我们觉得，模型能力更像是负责理解问题的「大脑」，工程能力则像是负责执行任务的「手和脚」，而产品能力就是与人沟通的「语言」。通过 TRAE，我们正试图将这三者有机地结合起来，希望让一个懂意图、会思考、能动手的 AI 成为可能。
03
发布一年，
月活突破 100 万
接下来，我通过对 TRAE 最新版本的介绍，带大家了解它的核心功能和使用场景。
第一个场景是代码补全，我们把这个功能叫做 「cue」，也就是「提示」的意思。在最新版本中，我们新增了两个核心能力：一是预测代码的补全位置，二是支持连续补全。当你在编辑区写代码时，AI 会根据当前整个文件的上下文，以及你之前的编辑历史，来揣测你接下来的编辑意图，并给出下一步的代码和位置推荐。你可以非常方便地使用 Tab 键来采纳这些建议。
我们从用户访谈和数据分析中发现，「cue」 这个功能对专业开发者来说非常重要。一方面，它能实实在在地帮助开发者提升效率；另一方面，我们也发现，在使用「cue」的过程中，开发者非常容易进入「心流」状态。
第二个场景是用自然语言写代码。也就是用聊天的方式来开发，把 AI 当成一个非常了解项目的开发搭档，或者一个非常懂你代码的专家。
比如说，当你想在当前项目中新增一个需求，按传统做法，你可能要先弄明白这个需求的项目背景，再去做方案调研和技术预研，最后还要对整个代码库有足够的理解，才能真正动手去写代码、改代码。
在这个流程里，你完全可以把这些工作都交给 AI。AI 会根据你的需求去理解项目、研究技术文档，并为你提供合适的解决方案。你可以审查 AI 给出的结果，如果符合预期，就可以快速将这些代码应用到项目中；如果不满意，也可以继续向 AI 提出修改要求，或者随时回滚到你认为稳定的版本。
如果说前面的「cue」功能，是帮助开发者在知道「写什么」的时候写得更高效，那么自然语言编程，则更像是为那些「有想法，但不太确定怎么写」的用户服务的。
我们发现，在不同的开发场景中，人与 AI 的协作模式其实是动态变化的。开发者可以根据自己的实际需要、业务场景和技术栈，在 AI 主导和 AI 辅助之间自由切换，找到最适合自己的协作方式。
你可以通过多轮对话与 AI 协作完成任务。TRAE 中引入了多个智能体（Agent），每个智能体都集成了自己的工具集（MCP）。用户可以将 prompt 提交给这些 Agent，它们会基于不同的上下文，处理用户在各类场景下的代码任务。
比如你希望创建一个偏前端的 APP，我们可能会推荐你使用前端智能体。你直接告诉它，「我想实现一个类似记事本的功能，用来记录每天的待办事项」，TRAE 就会调用相应的前端智能体，设计好代码结构，并根据你的代码风格，生成你想要的项目代码，同时还会给出它背后的思路和解释。
同时，我们也注意到一些开发者对 AI 生成代码会有「失控感」。但在 TRAE 的 AI 代码生成过程中，你可以非常清晰地看到 AI 生成的代码所带来的每一处变化。如果你认可，就能轻松快速地应用到项目中。此外，TRAE 还在 IDE 中集成了自动运行终端命令的能力。比如在任务过程中，TRAE 可以自动帮你安装依赖、运行脚本或执行代码检查等。同时，对于生成的前端页面，也可以通过内置的网页预览实时查看效果，帮助你快速调整和优化。当然，如果你不满意，也随时可以回滚到之前的版本。
除了功能介绍，我们也来回顾下 TRAE 团队的开发历程。
从 2024 年 6 月发布豆包的 MarsCode 插件开始，到 2025 年 1 月发布 TRAE IDE 海外版，再到 3 月上线国内版 IDE。4 月，我们又把豆包的 MarsCode 插件正式升级为 TRAE 插件，同时整个插件的产品能力也与 TRAE IDE 全面对齐，让 VS Code 和 JetBrains 用户也能获得和 TRAE IDE 一致的 AI 体验与开发效率。
这里有几个数字：截至 2025 年 5 月底，TRAE 的月活跃开发者用户已经超过 100 万，累计生成了超过 60 亿行被采纳的代码，每天都会源源不断地处理超过 150 万次的用户查询（query）。
04
未来，在 TRAE 中完成软件开发的全流程
回到今天的主题——「从代码生成到软件生成」，我们想分享一个字节内部的真实案例。
这是我们一位产品经理王俊强的项目。他是一个纯粹的非技术背景产品人，之前没有写过代码，更没有从 0 到 1 开发并上线过一个完整的应用。但有一天，他特别想做一款用于身材和健康管理的 APP，可以通过拍照识别食物中的卡路里和营养成分。
如果按照传统方式开发这样一个 APP，可能需要一位产品、一位设计师、一位前端、一位后端，甚至还得加一位运维。可是在这个案例里，这位产品经理独自一人就完成了整个开发任务。
他还为自己的工作流程做了非常完整的总结：从业务构思、产品计划、设计稿编写，到程序测试、部署上线，甚至还包括后期的营销、客服和商业化思考。他的目标是基于用户反馈，持续优化和迭代这个产品。
在这个过程中，他用了很多 AI 工具来协助完成每个环节：比如用豆包做战略分析和产品设计，用即梦做 UI 和品牌设计，而关键的代码部分则通过 TRAE 来编写。可以说，正是 AI 在每个环节的加持，让他具备了独立完成项目的能力。
不过，在和他交流的过程中，我们也发现，虽然 AI 确实解决了很多问题，但要真正独立完成一款产品，对用户本身的要求还是非常高的。他必须有非常强的执行力，能够处理长流程中的各种突发问题；同时也要有足够的好奇心和想象力，才能在多个 AI 应用之间手动操作、转换上下文。因为目前的 AI 还不足以端到端地完成一个完整的复杂任务，用户仍然需要极大的耐心去跟 AI 进行多轮对话，并且需要理解如何组合使用不同的 AI 工具，在它们之间不断切换。
在此背景下，我想到 Andrej Karpathy 提出的 「Vibe coding」 这一概念。他在一次分享中提到一个观点：如果你只想做一个简单的 Demo，展示一下效果，那么目前的 AI 已经能很好地解决你的问题了。但一旦你想将这个 Demo 推向市场，打造成一个真正的工业化产品，用他自己的原话说，这个过程会「非常痛苦」。因为只有人类才能掌握完整的上下文，从而在不同的应用间自如切换。如果我们想把 AI 引入软件生产流程时，就必须要有更多的耐心去和 AI 交互。
实际上，我觉得到今天为止，无论是 AI 模型还是 AI 产品，都还处于一个相对早期的阶段。在提升用户体验、降低 AI 产品使用门槛方面，我们还有很大的提升空间。比如，从这个案例的开发流程中可以看到，整个开发流程实际上是分散在不同产品和平台上的。
在前 AI 时代，从文档工具、设计平台到 IDE 和终端，开发者一直扮演着「调度」的角色。作为调度者，开发者需要在不同系统间不断切换、同步上下文，他们需要在不同系统间同步意图，并解决系统间出现的各种问题和偏差。
而在 AI 时代，我们面临着一个新问题：当 AI 参与进来时，我们同样需要在不同的 AI 之间切换上下文，同步意图，并消除它们之间的理解偏差。
基于此，我们有一个想法：如果我们能围绕 AI 打造一个统一的工作空间，而不是为每个工具单独配备一个 AI Copilot 呢？我们希望将所有工具模块化、组件化，由一个统一的 AI 进行整体调度，让完整、一致的上下文在同一个工作空间内流动。这样，用户只需要通过与一个 AI 对话，就能下达指令。
这个 AI 能够获取完整、闭环的上下文，并调用足够丰富的工具来完成用户的任务和指令。然后，用户可以审查结果并给反馈，这样能实现 AI 与用户在同一工作空间内的协同合作。基于这个认知，我们的思路也从「将 AI 集成到工具中」，转变为「将工具集成到 AI 中」。基于这个思考，我们对 TRAE 进行了一次非常大的迭代，并推出了全新的 Solo 模式。
我们未来的产品形态会分为两个主要区域：一个是 AI 交互区，一个是工具集区。关于这个产品形态，我们内部也有很多讨论和思考。
首先，我们考虑到人类从左到右的视觉习惯，并且我们相信未来 AI 的能力会持续增强，工具也会愈发丰富和强大。所以，我们认为，人与 AI 的交互界面才是最核心的工作区，我们将 AI 放在左侧，工具集区放在右侧。我们的 IDE 也作为一个工具，被整合进了右侧的工具集里。
除此之外，在 TRAE 中，还集成了文档、Terminal 和预览工具。这样一来，用户可以在文档工具里表达需求、写创意，在 IDE 中编写代码，通过 Terminal 执行命令，最后在预览工具里看到实时的结果。未来，我们也会持续集成更多的智能体和工具，同时把这种集成能力开放出来。我们也会与第三方及广大开发者们共同构建一个丰富的智能体和工具生态。我们相信，对话将成为新的终端，用户的输入不再是代码，而是任务、目标和标准。
AI 在统一的工作空间中理解、组织并交付结果。从「AI 写代码」到「AI 做开发」，从「工具增强」到「流程重构」，这就是我们对未来开发形态的思考，也希望和大家一起见证未来。
（文：Founder Park）