在 AI 编程领域国内外有一堆能叫的上号的应用：

CursorWindsurfTrae阿里的「通义灵码」百度的「文心快码」字节跳动的「MarsCode」科大讯飞的「iFlyCode」GitHub 的「Copilot」等等等...

这么多的 AI 编程应用，它们到底有什么区别？

这些编程应用的实现原理到底是什么样的？

如果你也对上述问题怀有好奇心，那么接下来这篇文章就会彻底打消你的疑惑！

以后再在朋友面前聊天的时候也可以略带装 X 的说一声：“啊，那个「Trae」的原理不就是 XXX + XXX 开发的嘛，其实并没有那么复杂，哈哈。😄”

/ AI IDE 和 AI Extensions /

目前市面上所有的 AI 编程工具都可以分为两类。

一类是：AI IDE（AI 集成开发环境）

这类应用通常和开发环境深度集成，比如上面提到的 Cursor、Windsurf、Trae 这些都属于 AI IDE 应用。

这类工具的最大特点就是：

它们本身就是一个单独的软件开发工具在原有软件开发工具的基础上，通过代码魔改使得该开发工具，具备了 AI 的功能。

而另外一类则是：AI Extensions（AI 插件）

阿里的「通义灵码」、百度的「文心快码」、字节跳动的「MarsCode」、科大讯飞的「iFlyCode」、GitHub 的「Copilot」

这类应用都属于 AI 插件，所谓 AI 插件，就是这类应用必须被集成进对应的开发环境中才能被使用。

比如常用的 VSCode 和 IntelliJ IDEA，我们只要在这两个开发工具的扩展插件中搜索上述的 AI 应用，就可以直接下载并安装使用了。

两种类型应用的区别

那么了解了所有 AI 编程应用的分类后，这些应用的最大区别又是什么呢？

先说 AI Extensions：

由于 AI Extensions 本身只是 IDE 的一个插件，所以 AI Extensions 所能拿到当前代码仓库的相关信息必须依赖于该 IDE 所提供的插件 API 接口。

如果 IDE 的 API 接口不支持获取详尽的代码历史数据，那么这些 AI 插件能够获取的上下文信息就会受到限制。而这种限制的上下文信息对于模型准确分析和理解用户意图来说，则是相对不利的。

而对于 AI IDE 来说：

由于 AI IDE 本身就是作为集成开发环境，所以 AI IDE 能够直接访问代码仓库中的丰富上下文信息。

通过分析用户意图，并据此调整上下文信息的权重，AI IDE 能够显著增强检索效果，这是 AI Extensions 所无法实现的。

如果看到这里你还是会觉得，这都啥跟啥啊，完全不理解啥意思。

不要急，秋豆麻袋！

接下来我们就拿一个示例来做一个演示。

Trae 和通义灵码

Trae 目前是国内最强的 AI IDE 工具，至于为什么说它是目前国内最强，下篇文章详细讲解 Trae 的使用技巧时会细说。

通义灵码也是目前国内 Top 级的 AI 插件。

我们拿通义灵码和 Trae 来做一个小小的比对，你就能一目了然双方的区别了。

通义灵码

此时我从 GitHub 上下载一个之前自己写过的代码仓库 smart-heart

IDEA 打开该仓库后，使用通义灵码的“AI 程序员模式”来问一个简单的问题：“请帮我分析一下当前整个项目空间中所有项目的主要功能是什么？”

一般当我们学习一个新的项目，不知道从何开始看起的时候，就可以让 AI 帮我们快速总结一下该项目的主要功能和特点了。

我们可以看到通义灵码给出的答案是：“由于我们未提供任何上下文信息，所以它无法分析当前该项目的主要功能。”

Trae

此时我们问 Trae 一个相同的问题：“请帮我分析一下当前整个项目空间中所有项目的主要功能是什么？”

此时我们可以看到 Trae 读取了我当前整个工作空间的代码数据，并进行分析后，给出了对应的项目总结。

总结

此时你可能会有一个问题，“通义灵码” 已经说了，请你提供对应的上下文信息，然后它会给你进行对应的代码总结，你给它提供对应的代码信息不就好啦？

这里我可以非常明确的告诉你，不是这样的。

就算你这里选择了对应的上下文信息也只能选中几个代码文件给对应的“通义灵码”，他只会根据这几个提供的代码文件来进行分析。

而 Trae 则不同，在 Builder 模式，默认情况下，就是直接读取你当前整个 WorkSpace 空间下的所有代码内容。

所以此时使用 Trae 来进行自然语言交互时，就会非常顺畅，比如：“帮我把 A 文件中的内容修改为 XX ”

Trae 此时会直接定位到你的 A 文件具体内容，然后根据你具体的指令来进行文件修改。

而“通义灵码”则不同，当你告诉它 “帮我把 A 文件中的内容修改为 XX ”时，此时你还需要手动的先把 A 文件添加到“通义灵码”的上下文当中才行。

这就是一个非常大的差别，因为正常情况下，用户在描述一个需求时，通常是会涉及到非常多的相关代码文件的，此时作为用户的你在问一个问题前，还需要把所有的相关文件都先一个个的添加到对应的上下文中，这简直是太痛苦了。

ps：通义灵码在 AI 插件领域其实已经做的非常好了，此处只是为了对比出和 AI IDE 的差距，所以以上下文这个 Case 来举一个例子。

实际开发场景中，使用通义灵码来进行编码辅助，效率实际上也是非常高的。

只能说通义灵码本身并不差，但是 Trae 作为不同形态的 AI 编码工具，它本身的形态差距，使得 Trae 在某些场景下可以做的更好罢了。

/ AI 编程工具的原理 /

上面我们一直有提到说要给 AI 模型提供对应的代码上下文，否则模型无法进行代码运算。

此时你可能会有一个疑问，为什么？

不是说模型被训练出来后，就已经达到了人类博士水平了吗？为什么还需要我再给它提供一些代码片段才行？

如果你对这个问题有疑问，可以先看一下这篇文章：人人都能搞定的大模型原理 - 神经网络

看完以后你会得到一个基本的概念：即当前基于 transform 架构的预训练模型，由于在预训练阶段本身所学习的知识仅限于当前所训练的数据，所以对于新的知识内容模型本身是不知晓的。

换句话说，如果模型本身是 2024 年被训练出来的，如果你问它 2025 年的知识，那么模型是不可能知道的。

所以，当你在问模型一个关于自己代码仓库的问题时，首先要做的就是先给它提供对应的代码上下文，然后基于你所提供的代码上下文再进行优化。

但如果每次都需要人类自己先把上下文丢给模型，这岂不是太麻烦。

是的。所以一项新的技术就此诞生，它的名字叫做 RAG（Retrieval-Augmented Generation，检索增强生成）

RAG

RAG 的使用场景非常的广泛，构建私有知识库、内容创作、数据分析、AI 编程等，只要是需要模型需要外挂知识源来进行处理的场景都需要用到 RAG。

那么 RAG 是什么？

简单来说：其实就是将数据库和大模型本身做了结合，然后给它起了一个名字叫做「检索增强生成」，英文缩写就叫做 RAG。

既然模型本身不知道 2025 年的知识，那么在问它一个 2025 年的内容时，先去数据库中查找 2025 年的相关知识，然后作为模型的输入一并提供给模型不就好了吗。

比如下面这个场景：“问 ChatGPT 一个关于 OpenAI CEO 的问题”

Trae 的向量检索

先解释一下什么是向量检索，向量检索实际就是数据库检索，只是这个数据库本身是向量数据库。

当我们把文本存储到向量数据库中时，会将该文本转换为向量值来进行存储，而并不是存储原始的文本数据。

向量数据库针对高维向量的相似性搜索效率较高，RAG 模型需要在大量的文本中检索与当前生成上下文最相关的片段，这通常通过计算向量之间的相似度来实现。所以我们一般情况下构建 RAG 时通常则是使用向量数据库来存储原始数据。

那么当我们在问 Trae 一个问题：“帮我把当前的代码给优化一下” 时，此时是先把当前的本地代码和该问题一起丢给模型，然后让模型来优化完再输出的吗？

不是这样的。

首先我们的请求是先到 Trae 自己的服务器上，然后 Trae 自己的服务器再去请求对应的模型，然后返回数据。

其次，当我们发送一个问题：“帮我把当前的代码给优化一下” 时，此时并不会真正的把当前本地的代码文件也发送到 Trae 的云端，而只是发送你的“文件名”加“问题”给到 Trae 的云端即可。

而对于你当前的这个代码文件，实际在最开始 Trae 打开你的项目进行索引构建的时候，已经将你的项目文件全部在云端构建好了。

我们来抓包验证一下：

此时我选中代码文件的 13-16 行，然后问题是“帮我优化一下这个代码”

然后抓包看该请求的具体内容：

首先我们可以看到该请求是直接先发送到了 Trae 自己的服务器，然后我们把对应的请求内容 json 格式化看一下：

可以看到最终 input_content 参数中的内容，实际只是携带了当前要优化的文件名和该代码文件中从 13-16 行这个代码标识，而并不是直接上传了 13-16 行的代码块。

所以当请求到达 Trae 的云端后，Trae 会先在自己的向量数据中，检索该代码片段，然后再针对该代码片段和对应的提示词优化后丢给对应的模型进行处理，最终将模型输出的结果再输出到 Trae 的客户端。

换句话说：当你使用 Trae 这类 AI 编程工具进行开发时，实际上你的代码本身已经被传递到了 Trae 的服务器上。

这个东西对我们会有什么影响吗？个人用户对代码不是很在意的其实不影响。

但是对于企业级用户，对代码安全性要求较为严格的场景下，则需要有所注意了。

具体也可以翻一翻 Trae 的用户协议，这些内容在用户协议上都会有所说明。

/ 结尾 /

看到这里，相信你已经对 AI 编程工具的执行逻辑有了新的认知。无论是「AI IDE」的全域掌控力，还是「AI Extensions」的轻量便捷性，本质上都是 AI 时代下人类意图的「翻译官」——将自然语言转化为精准的代码指令。

但更值得思考的是：当我们的代码在云端被检索、分析与重构时，开发者正在经历一场静默的范式转移。未来或许不再需要「记住语法规则」，而是要「学会与 AI 共舞」——用清晰的意图表达驾驭庞大的知识库，用精确的上下文检索激活模型的创造力。

或许某天，当我们对着屏幕说出「构建一个能预测宇宙热寂时间的分布式系统」时，AI 早已在暗流中完成了代码宇宙的熵减。而此刻，不妨先打开 Trae，让它帮你优化掉今天的第一个 if 嵌套——毕竟装 X 的第一步，是先写出值得被优化的代码。

文章内容来自公众号：数字生命贾克斯