从补全到智能编辑：Trae 在代码编辑领域的创新与变革

作者｜冯绪

编辑｜李忠良

策划｜AICon 全球人工智能开发与应用大会

随着 AI 编程助手的发展，它已经不再只是一个简单的“补全工具”了，而是变成了一个能够自我规划、协同工作并根据反馈进行迭代的开发伙伴。Trae 团队在这一过程中经历了“补全 + 聊天 → 应用 → 构建 + 提示”的三个阶段，逐步解决了文件定位、跨文件修改以及在效率、准确性和资源消耗之间的平衡问题。InfoQ 特别邀请了字节跳动的冯绪架构师，在 AICon 全球人工智能开发与应用大会·深圳站分享了《Trae 插件在 Agent 代码编辑中的实际应用》。冯绪详细分析了在应用与搜索/替换之间的取舍、智能补全机制 Cue 的运作，以及在“太阳系行星页面”等真实案例中的经验，分享了一些可供借鉴的工程方法。

12 月 19～20 日的 AICon 北京站将聚焦行业前沿，讨论大模型训练与推理、AI Agent、研发新模式和组织创新，诚邀您一同深入探讨：如何构建可信赖、可扩展、可商业化的 Agentic 操作系统，让 AI 成为企业有效降本增效、突破增长瓶颈的核心驱动力。

详细日程请见：

https://aicon.infoq.cn/202512/beijing/schedule

以下是演讲实录（经过 InfoQ 编辑整理）

AI 编程助手正在快速迈向智能化。它不仅能自主定位文件、修改代码，还能自动规划和执行任务，AI Agent 不仅高效完成开发任务，还能自我校正和迭代，极大提升了开发效率。然而，要实现这些功能，依然面临两大挑战：一是文件定位不够精准，二是跨文件修改存在困难。

TRAE 编程助手的发展阶段

在讲解 Trae 如何应对这些挑战之前，先来看看它的发展历程，总体可分为三个阶段。

第一阶段是最初的“补全 + 聊天”。这个阶段主要是通过代码续写来提升编辑能力：当用户在编辑器中输入内容时，系统会自动提供可能的后续代码，并且还有一个聊天面板，用户可以在里面提问并得到代码建议。不过，这个阶段用户还是需要手动复制粘贴，因此效率提升并不明显。

为了克服手动复制粘贴的问题，Trae 进入了第二阶段：Check & Apply。这个阶段的核心变化是提供了“应用”功能，用户只需点击按钮，就可以将生成的代码自动应用到原始文件，实现了一定程度的自动化。同时，我们开始探索模型的自动定位能力：一旦模型生成了代码块，它会同时告诉用户希望应用的目标文件。

第三阶段（也是现在的阶段）是 Builder 和 Cue，致力于打造高度自动化的开发体验。Cue 提供了更智能的补全功能，支持多行编辑和智能改写，甚至能预测下一个光标位置；而 Builder 则能感知项目的上下文，自动规划任务，并完成跨文件的编辑和迭代。在这三个阶段中，模型的编辑能力不断提升：早期只能进行简单的续写；中期具备了一定的文件定位与修改能力；到第三阶段，已经能够自动定位和修改文件，并进行更精确的编辑。

从代码补全到 Agentic Edit

现在，让我们看看 Trae 在代码编辑能力上的三阶段演进。代码补全是大模型最基本、也是最强的能力。通过中间填充和基于最近打开文件的上下文策略，我们进一步提升了光标位置的续写效果。然而，这种方式也有局限性：只能在光标处进行编辑。

为了实现这一目标，我们可以先分析当时 Trae 模型生成的代码块的特点。

如图所示，模型的实际输出并不是完整文件，而是仅展示需要修改的关键部分。比如，这个例子中模型根据指令插入了注释，因此中间部分被完整展示，而未涉及修改的上下文则用 existing code 等简写形式标明，表示这些区域无需改动。

这种输出方式的主要目的是为了显著减少 token 消耗，从而提高生成效率。我们都知道，模型的上下文窗口是有限的。在当时，模型的能力还没有达到今天的水平，应用场景主要以问答式交互为主；由于上下文窗口的限制，模型很难一次性输出完整的文本。而且，在生成回答时，大量 token 还需要用于拼接所采集的上下文信息。

有人可能会问，为什么不采用类似 Git 的 Diff 格式进行输出？其实，我们在实践中也尝试过这种方式，但发现存在两个主要问题。

首先，模型对输出 Diff 格式并不擅长。Diff 格式对语法和符号（比如“+”“-”）等要求非常严格，一旦输出格式不符合标准，就会直接影响代码编辑的准确性。其次，用户在使用过程中需要良好的阅读体验。通常用户在看到模型输出的代码后，会先确认其是否正确、是否符合预期，然后才会采纳。然而，Diff 格式本身可读性较差，阅读和理解起来比较费力。因此，我们最终放弃了将 Diff 格式作为直接输出的方案。

由此带来的核心挑战是：如何将模型输出的带有缩略格式的代码块精准地合并到原始文件中？

由于代码在格式和内容上差异巨大，不同开发者的代码风格也千差万别，如果仅依赖规则匹配来完成合并，几乎无法覆盖所有情况。

### 代码编辑的智能革命

说到上下文和语义的改写，大家可能都知道这是大模型特别擅长的领域。为此，我们特别训练了一个专门用于代码编辑的 Apply 模型。这个模型其实接收两种输入：第一是原始文件的内容，第二是来自 Chat 模块或 Chat 模型的缩略代码块（我们称之为 Plan）。拿到这些信息后，模型就会对内容进行改写和编辑，最后输出一份完整的编辑文件。然后，我们会用这份新内容替换掉原文件，同时以 Diff 的形式展示给用户，这样他们就能轻松判断哪些修改值得采纳，哪些可以忽略。

为了实现这一目标，我们在选择和训练模型时有几个要求：首先，要低延迟；其次，要有很好的指令遵循能力；最后，得支持长上下文。其实，低延迟的目的是为了让用户在点击 Apply 按钮后，能快速看到结果。而在编辑的时候，模型需要严格按照 Plan 的指令来输出，所以指令遵循能力至关重要。同时，在处理跨片段和跨文件的编辑时，长上下文的支持也是必不可少的。因为输入和输出共享同一个 Token 窗口，我们的方案要求把完整的原始文件交给模型处理，这样会占用不少上下文空间，导致留给生成内容的空间变少。因此，模型必须具备处理长上下文的能力，以确保能覆盖更广的修改范围。

在确定了这些选型后，我们在训练数据的构建上投入了大量精力。具体来说，我们根据不同 Chat 模型的输出习惯，生成了多种缩略格式的数据。不同的 Chat 模型在缩略格式的表达上并不一致，甚至同一模型在不同的输出中也可能使用不同的方式：有的可能会说“existing code”，有的则只用一个“.”来占位。为了提高任务的准确性，我们对模型进行了微调。

除了缩略格式，我们还针对不同的场景构造了数据。例如，为了满足“添加注释”、“import 依赖”、“删除代码”、“代码重构”等需求，我们准备了相应的样例。通常需要先理解用户的意图，然后再生成对应的数据，以提高模型在具体场景下的准确性。此外，我们也为常用的编程语言构造了数据，使模型能够处理更加丰富多样的场景。

经过一系列的训练后，Apply 方案终于上线了。这里有个实际的例子：如果我想为某个文件里的每个函数添加文档注释，只需输入“请为每个函数补上文档”这句话，模型就会自动生成相应的内容；它会输出相关内容，部分函数的细节可能会使用省略形式。接着，当我点击 apply 按钮后，模型就能根据生成的结果为整个文件自动补充完整的注释。

这一方案的推出确实大大提升了用户体验，但也存在三个方面的不足：首先，额外的资源消耗——除了要调用 Chat 模型生成代码块，还需要再调用一个模型来进行编辑，整体资源消耗上升；其次，效率问题——在某些场景下，Chat 模型只需要改一行，而 Apply 模型却可能重写整个文件，这样效率就显得较低了；最后，长文件的限制——输入和输出共享上下文窗口，文件过长可能处理不了，甚至会影响生成结果的准确性。我们在工程上通过设置长度上限来规避这个风险，但当超长文件被拒绝服务时，用户体验还是会受到影响。

尽管有这些限制，Apply 的上线确实带来了明显的体验提升，也让我们开始反思：代码补全不仅仅是“续写”，还需要进一步优化整体的使用体验。

基于这个想法，我们推出了更智能的代码补全功能 Cue。Cue 允许多点编辑，不再局限于续写，而是可以在多行中同时进行删除、替换和插入；同时它还具备光标预测能力，比如当用户在某一行引入方法时，它会提示在文件开头补充相关的 import；此外，它还能跨文件编辑，智能识别需要变更的目标文件，突破了“仅限当前文件与当前行”的限制。

标题：在代码编辑中，如何选择最合适的工具？

说到 Cue，相比于 Apply，它的挑战可就大多了。为什么呢？因为 Cue 需要更好地理解用户的潜在需求。用户在输入大量字符或频繁移动光标时，这些行为往往藏着需求的线索，但却不直接表现出来。因此，我们通过分析用户的编辑记录来揣测他们真正想要的内容。而且，Cue 还得支持跨文件的编辑，这样就能打破只在当前文件或行内修改的限制。我们利用 RAG 技术来实现上下文感知，这样就能知道与当前编辑内容相关的其他部分是否也需要一并修改，进而提供更智能的补全功能。

随着模型能力的迅速提升，我们进入了 Authentic Edit 的新阶段。这个阶段的特点就是，模型能够独立地完成整个文件的编辑。同时，我们也在探索更适合这种模式的代码编辑方法。

接着，随着模型能力进一步增强，Builder 这个产品形态也应运而生。它就像一个智能的编程助手，能够在整个代码仓库中自主搜索，判断需要编辑的文件，并且可以对多个文件或同一文件进行多次编辑，同时保持逻辑的一致性。围绕着这个新形态，我们也提供了更符合需求的编辑功能。

具体来说，Builder 配备了一整套丰富的编辑工具，比如 Write to File（用于新建文件）、Delete File（用于删除文件）和 Update File（用于编辑文件）。在这些工具中，Update File 是最复杂的应用场景。

在 Builder 模式下，Apply 的局限性则显得更加明显。为什么呢？因为 Agentic 的一次任务往往涉及多次文件修改。如果每次都要经过“Chat 模型输出”和“Apply 模型编辑”这两个步骤，系统的负担就会非常重。而且，这种双阶段的处理不仅会消耗更多资源，还可能导致误差增大，从而增加整体编辑失败的概率。尤其是对于长文件，Apply 的处理能力显得捉襟见肘，这在 Agentic 场景中尤为明显。

基于这些考虑，我们在这个阶段转向了 Search/Replace 方案。这个方案的核心机制其实很简单：先有一个原始文件，模型会明确指出需要查找和替换的旧内容，并提供对应的新内容。最后，系统根据这些信息去查找和替换，得出编辑后的结果。这个方案的好处也很明显。一方面，它不需要二次调用，从而避免了多余的开销和误差叠加；另一方面，它不受上下文窗口的限制，也就是说，无论文件多长，模型只需输出需要查找的那一行内容，就能准确找到。

不过，这一方案也不是没有挑战。首先，对模型输出的要求相当高。模型必须严格遵循指定格式，并确保 _old_str_ 与原文完全一致。此外，工具调用通常使用 JSON 格式，但在将 _old_str_ 等字符串写入 JSON 时，得进行转义，否则会导致解析失败。而转义本身就是模型容易出错的环节。

再者，这个方案在效率上也会遇到问题。当大规模变更时， _old_str_ 和 _new_str_ 可能非常冗长，再次触发上下文窗口的限制。虽然可以通过拆分为多次编辑解决，但效率却会下降。我们也试过用数组的方式来提升效率，但这样对模型输出的规范性要求更高。

最后，工程的复杂度也比 Apply 方案高。为了应对输出的不确定性，我们需要引入更多的防御机制，比如模糊匹配、相似度查找，以及在出错时进行自动修复和重试。

因此，这两种方案其实并不是互相取代，而是适用于不同的场景。在 Chat 模式下，我们更倾向于使用 Apply 方案，以提升用户体验；而在 Builder 模式下，则优先采用 Search/Replace 方案，因为它的准确性更高，并且不受文件长度的限制。

探索 Agentic Edit 的新视角

嘿，大家好！今天我们聊聊 Agentic Edit 的一些有趣发现。看看上面的图，这是我们在Builder模式下创建一个简单太阳系行星运行页面的示例。在这个过程中，我会向系统反馈那些不太准确的部分，而系统会根据我的反馈不断调整，直到这个页面完成，并逐渐丰富相关的展示功能。

接下来，让我们总结一下这次分享的内容。

这次分享回顾了 TRAE 编程助手 的三个发展阶段以及它们对应的产品形态，还探讨了背后代码编辑能力的演变过程。我们从最初专注于完成代码编辑任务的 Apply 模型，到提供更即时和智能的补全体验的 Cue 功能，再到如今充分利用大模型能力的 Agentic Edit。展望未来，我们计划从三个方向继续深入：提高编辑的准确性和效率；探索 Multi-Agent 协作框架；持续激发模型的思考与规划能力。感谢大家的聆听！

接下来，给大家介绍一下我们的嘉宾。

冯绪是字节跳动的 Trae 插件架构师，之前在腾讯工作，积累了丰富的一线研发和实践经验。现在他专注于 AI 编程助手的建设，参与了从零到一的搭建过程及 Apply 能力的开发。他一直在探索大模型与编程工具的深度结合，致力于在 AI Agent 架构设计和代码编辑技术优化等方面持续努力，为提升开发者的编程效率贡献力量。

最后，我想推荐一个活动给大家。

AI 正在重塑组织的未来，Agentic 企业时代已经来临！如今，AI 不再只是一个辅助工具，而是深入到商业核心，推动组织形态和运作逻辑的全面革新。

把握这个行业变革的关键时机，12 月 19 日至 20 日，AICon 全球人工智能开发与应用大会（北京站）即将隆重开启！本次大会将聚焦大模型训练与推理、AI Agent、研发新范式和组织革新，期待与大家一起探讨：如何建立一个可信赖、可扩展、可商业化的 Agentic 操作系统，让 AI 真正成为企业降本增效、突破发展瓶颈的核心动力。