重生之我在大厂搞 AI Coding

本文作者：天猪，TRAE 技术专家

时间线其实很简单：

• 2022 年 11 月 15 日，很幸运地加入了字节。

• 2023 年 11 月 15 日，我被一个电话召集到了杭州闭关室，从此负责起 MarsCode Cloud IDE 团队的云工作区等相关工作，那是疯狂奔跑的一年。

• 2024 年 11 月 15 日，再次进入了闭关室，又是疯狂的半年，于是就有了大家看到的 TRAE 1.0、2.0 的演进。

经常跟朋友调侃说，11.15 是我的受难日，重生之我在大厂搞 AI Coding 。今年的 11 月 15 日又会发生什么呢？我不知道，但有点期待。

满打满算半年过去了，定坤在6月的火山引擎 Force 大会的主题演讲《字节跳动技术副总裁洪定坤：TRAE 想做 AI Development》时，也分享了 TRAE 的月活已经突破了百万用户，我们也算是阶段性交出了一份答卷。

从 MarsCode 到 TRAE

熟悉我们的同学应该知道，2024 一整年我们发布了很多 Cloud IDE 相关产品，包括 MarsCode Cloud IDE、Coze IDE、掘金 AI 刷题等，字节内部的 Cloud IDE 也是我们服务的，用户覆盖率还是蛮高的。

首先，先澄清一个概念，Cloud IDE ≠ Web IDE ，从我的视角看，IDE 分为前端交互层和业务逻辑层：

• 前端交互层可以跑在浏览器里面，也可以跑在本地 Electron 里面，可以是完整版也可以是轻量版。

• 业务逻辑层可以跑在用户本地，可以跑在远端 K8S 容器，也可以跑在浏览器的 WebContainer 里面。

Cloud 意味着 Code Anywhere ，上面的交互层和逻辑层是可以自由组合的，可以是都在一台机器上，也可以是分离通过 SSH Remote 去连接，甚至可以通过 iPad 去使用。这是我所理解的 Cloud IDE。

Cloud IDE 的远端容器，我们也称之为云工作区，它的技术挑战还是蛮大的：

• 常见的微服务都是非实时的，且无状态，可负载均衡，容量不足的时候慢慢扩容即可；

• FaaS 服务是实时调度的，但无状态，所以可以提前预热等；

• Cloud IDE 是实时调度 + 有状态 ，每个项目对应于一个容器，有磁盘数据依赖，对启动速度非常敏感 ，用户打开的时候就直接等着你初始化和加载，才能使用，因为是有磁盘代码数据，因此是有状态的，不能负载均衡，也很难提前预热。

2024 年，我们在这块投入了非常多的精力去优化，不仅仅把 VSCode 进行大幅 Rust 化，还深入到 K8S 层面深度定制，最终在性能、成本、稳定性等方面取得非常不错的产出，我们的端到端启动性能 P90 达到了 5 秒，而 GitHub Codespace 需要 30 秒，Google IDX 需要 1 分钟，我们起码在这个指标上做到了世界级的水平。

当然，技术的成功并不一定代表业务的成功 ，很多时候需要在合适的时机选择合适的路线，对应 Cloud IDE 场景来说，虽然它在字节的覆盖率很高，但 MarsCode 作为一个 2C 的产品，天然就受到用户场景的限制，因为国内企业的代码很难上云，而程序员的 Side Project 又不足以支撑产品的健康发展。

于是，在 2024 年 11 月 15 日，我们回到半山坡，选择了从 Native IDE 这另一条路重新往 AI Coding 的珠峰攀爬。当然，我依然坚信 Cloud IDE 的价值，它会以云端一体的方式跟我们重聚 ，殊途同归，一个都不能少。果不其然，在 2025 年中的时候，业界也开始涉猎到 Remote Agent 场景，而这块我们有着足够的积累，择机待发即可。

我对 AI Coding 的认知

LLM 大模型的本质是预测下一个字符，相比起复杂的自然语言，编程语言是更加简洁、严谨、可预测的，因此 AI Coding 领域成为了这一波浪潮里面的第一个 PMF 产品，在这个领域的实践日新月异，几乎每个月都在刷新我们的认知。

在我的观察视角，AI Coding 有点类似自动驾驶，分为几个阶段：AI 辅助编程 → AI 结对编程 → AI 自驱编程，目前我们的 TRAE Builder / Cursor Composer / Windsurf Cascade 等都是瞄准了 AI 结对编程 这个阶段的。

AI 辅助编程

代码补全

早期我们写代码，主要是代码提示，通过 “下拉列表” 的方式选择对象的方法和属性。

随着 ChatGPT 的出现，我们知道 LLM 大模型的本质是预测下一个字符，相比起复杂的自然语言，编程语言是更加简洁、严谨、可预测的，所以很快我们看到了 Copilot 的横空出世，它在代码补全上有了极大的创新，令人惊艳的 Ghost Text 交互方式，只需一个 Tab 即可快速采纳，对程序员的多巴胺刺激非常强烈。

下拉框提示

采用 Ghost Text，只需一个 Tab 即可采纳

但这种方式只能针对新增代码的补全，于是我们看到了 Codeium 和 Cursor 在 Super Completion，也叫 Tab Tab 这块的进一步创新，从 预测下一个字符 → 预测下一个编辑位置，从新增代码 → 修改存量代码，一个直观的例子就是：一个前端的地区下拉列表，一开始是英文，后面改为中文，如果你改了第一行中间的字段，然后只需再一次 Tab，就能一键把下面所有的字段全部更新了。我们也在最近发布了 TRAE Cue 超级代码补全功能。

从 “代码提示” → “代码补全” → “超级补全”，这是 AI Coding 的一个能力跃迁体现。

代码生成

接着聊一聊 “代码生成”，在 ChatGPT 刚出来的时候，对程序员的另一个震撼是，对话式生成算法或页面，不过它需要在 Chatbot 里人肉对话，然后再复制回去 IDE，太麻烦了。

那我们是不是可以直接在 IDE 里面跟 AI 对话呢？于是 IDE 里面开始出现了 SideChat，这阶段更多是以插件方式，如 Copilot Chat、Codeium 等，它的优势在于可以直接拿到 IDE 和代码仓库的上下文，不用人肉复制。

大家别看这玩意比较高大上，其实原理上很直白，譬如你跟 AI 说 “帮我把这个 HTTP 请求函数实现下”，它背后其实在拼一段话：“用户现在正在打开 xx 文件，当前他的光标在 xx 行，这行的函数名和注释是 xxx，最近他访问过 a，b，c 文件，整个项目的目录结构是 xxx，现在他要求你在当前位置实现一个 HTTP 请求逻辑”，然后把这段话丢给 LLM 那边去生成，回来后再做代码合并。是不是跟你人肉去对话 ChatGPT 差别不是很大？就是 IDE 帮你把合适的 Context 上下文组装起来了。

这里的技术含量就是：项目理解能力、上下文 Context 裁剪、模型的能力以及工程上 PE 的能力，Cursor 就是在这块做的很不错，从而脱颖而出。这其中 Claude Sonnet 3.5 功不可没，因为它的出现代表了模型能力到了一个里程碑，从而在去年掀起一波热潮。

到这一步，开发者可以直接在 IDE 里面，和 AI 共享相同的上下文，无需累赘的转述，那下一个要解决的问题是生成后的代码，不要人肉复制回到编辑器的各个文件去，这就是 Fast App ly 代码合并 场景。

简单的说，就是如何让 AI 生成一段合适的代码，并自动把代码合并到合适的地方，这里有不少实现方式，譬如全文重写、Search Replace 代码片段替换、Diff 合并，在业界有多种实践结合使用，Cursor 则是自己训练了一个 Fast Apply 小模型，我们 TRAE 则是几种方式都支持了。

上面这 2 个能力的这个阶段，我称之为 AI 辅助编程。

AI 结对编程

AI Agent 是什么？

随着 AI 能力的持续增长，用户的需求也越来越复杂，我们更期望 AI 能更多一点自主性，就像是一个高潜力的实习生跟着我们一起结对编程，社区也称之为 AI Agent。

那一个典型的 Agent 是咋样运作的呢？Manus 之前的文章提到：

『在接收用户输入后，Agent 通过一系列工具使用来完成任务。在每次迭代中，模型根据当前上下文从预定义的动作空间中选择一个动作。然后该动作在环境中执行以产生观察结果。动作和观察结果被附加到上下文中，形成下一次迭代的输入，这个循环持续到任务完成。』

简单的说，Agent 的核心点是：AI 具备了思考能力和调度能力，也有了上下文环境感知能力和工具调用能力。它能感知到自己所处的环境，并根据接受到的目标进行思考和拆解子任务，然后调度各种工具去帮它实现这个任务。

TRAE Agent 1.0

TRAE Agent 立项于 2024-12-17，猛肝了 20 天，就有了大家看到的 TRAE 1.0 版本。

在 Agent 1.0 架构中，由于当时大模型的能力还不够强大，我们的流程会更依赖 Workflow 流程，即 思考 → 规划 → 执行 → 观察 的循环开展。它在 TRAE IDE 环境中运行，借助 IDE 的功能采集信息、构建上下文，并依靠大语言模型来进行思考和规划。同时，利用 IDE 提供的文件操作、命令行操作等功能来进行工具调用，完成编码相关的需求。

除了 Agent 的流程外，还有 Code Knownledge Graph 知识图谱（代码召回）、Fast Apply 代码合并等等。

顺便吐槽下：有时看到社区一些人说 AI IDE 都只是 LLM 的套壳，只能说他连领域认知的门槛都没碰到。

TRAE Agent 2.0

随着大量用户的使用反馈，我们收到了很多吐槽，猛肝出来的 1.0 架构在很多场景下的效果并不太好，同时随着 LLM 大模型能力的持续提升，这种依赖于 Proposal + Plan 固定 Workflow 方式，反而会导致大模型降智，限制了它的发挥。

于是在 2025-04-08 时我们再次闭关肝了 21 天发布了 Agent 2.0 架构，通过给予 LLM 更大的自主权，让它主动去理解需求，感知环境，并驱动工具执行和获取反馈，从而大幅发挥出 LLM 的能力。

同时，我们也对各种 Tool 进行专项优化，譬如 File 工具优化了代码合并成功率、代码召回抽象为 Search Codebase 工具供 AI 按需调用，并支持了语义化多路召回。

和 AI 去斗智斗勇的过程，也是一个很磨人的过程，分享一个 PUA 的案例：

• 背景：我们期望让 AI 在更少的轮次里面做完一个任务。

• 方法：PUA 它，告诉它只有 N 轮的机会了，让它有紧迫感。

• 结果：在 claude 3.5 里面非常有效，从线上数据看，轮次明显下降。

• 意外：然而在 claude 3.7 里面，我们发现 AI 反而变懒了，分析后发现是因为 3.7 的性格更发散，当它发现自己只剩有限次数完成任务的时候，就直接摆烂了，要我们踢一脚动一次。结果又花了不少时间摸清它的个性才解决了这个问题。

TRAE Agent 3.0：

Agentic 和 Workflow 不是非黑即白的开关，而是一个连续的光谱。我们的架构要提供可持续的迭代能力，从而在 LLM 能力足够的地方更自主化，在 LLM 还不太擅长的地方通过固定编排把专家经验固定下来，随着模型的进化可以低成本的替换节点实现逻辑。

施工中，欢迎加入我们一起加速这个过程。

TRAE SOLO 模式

随着 TRAE 的持续演进，我们逐渐意识到，AI 和 IDE 的主导关系在翻转：

• 以前是在 IDE 里面 Coding，AI 打辅助。

• 现在更像 AI 在更主导 Coding，而 IDE、Browser、Terminal 这些只是它的一个 Tool。

因此，我们推出了 SOLO 模式，从『从 AI 辅助 IDE』升级为『AI 主导 IDE』的新的编码模式，在 SOLO 中，AI 可以使用包含内置的编辑器、浏览器等不同的工具，未来 SOLO 还将集成更多工具。

这次发布的 2.0 版本，主要提供了：

• SOLO 这种以 AI 为中心的交互模式。

• 内置了一个针对 Web APP 场景的端到端交付 Agent，未来还会有更多 Agent。

这是我们一些邀测用户做出来的效果：

如何正确地和 AI 实习生协作？

我一直以来对 AI 的定义都是：一个私人独属的高潜实习生。

现在很多人觉得 AI 编程很震撼，也很多人觉得是垃圾，其实就是没找到如何与不同阶段的实习生相处的方式，没管理好自己的预期，短期高估长期低估。

我的认知是：对当下的实习生，应该安排合适的任务，给予合适的指导及信息输入，并随时做好帮它兜底，并随时接手，就像你带一个真人实习生一样没啥区别，要么没用好，要么没雇好。

1. 甩手掌柜 → 不给充分的上下文，就想着一句话需求能让 AI 完成正式项目。
2. 给予超出能力边界之外之事 → 它是写代码的，你期望它生成黄图。
3. 招聘标准低 → 想干 claude 4 的事却只舍得用 openai 3.5 free。
4. 一分价钱一分货 → $20 月费想实现$2000 的 token 用量产出。

在社区观察不同人如何评价 AI Coding 也挺好玩的，能管中窥豹平时是如何带实习生新人：

1. 有些人会事无巨细的拆解和提供信息，强指挥，给我闷头干别 BB。

2. 有些人会适当放权，仅给必要的信息输入，但会随时准备兜底。

3. 有些人会没有耐心，一有问题就骂骂咧咧，然后放养一边，自己上，只丢一些打杂过去。

写在最后

记得刚立项的时候，TL 跟我们说：“我们有意愿、有能力、有机会、有想法、有支持，我坚信我们有能干出一款世界级的产品。” ，我当时是当作**“愿景”** 去听的。但没想到 2024 底做年底总结时看着 MarsCode 的技术指标，2025 年中看着 TRAE 的百万月活数据，看着团队积累的一篇篇 Insight，我突然发现我们确实是在踏踏实实的走在这条路上奔跑着了，我真心 Believe 了。

本着 “预研一代、部署一代、分享一代”的理念，我们正在落地 TRAE Agent 3.0 架构，从而可以支撑 Multi Agent 和 Remote Agent 等探索。

路漫漫其修远兮，吾将上下而求索，AI Coding 这条路我们还在摸索前行中，比起行业的很多先行者还有很多需要学习的地方，但请相信我们是很认真的在做这事。

专业生产力工具的颠覆式创新，必然会全面重塑开发者的认知和开发方式 ，未来的 IDE 很有可能不再是当前 IDE 的 “以代码为中心” 形态，这很可能会发生在 3 年内。阶段性看，我们需要在变革性终态到来前，维持且抬升团队、市场和公司投资主体的信心，给终态变革留出战略空间。