开篇
编码新时代：国内出品的第一款桌面端 AI IDE
官网：https://www.trae.ai/
自从 2023 年初 GPT-3.5 掀起 LLM 热潮后，每个行业都因为 AI 产生了翻天覆地的变化，AI 开始融入各行各业并产生效率和工作形态的改变。以互联网领域为例，就包含但不限于以下变化：
首先是基建层的逐步完善，各类基础 LLM 模型服务被推出，它们可以类比为操作系统或者各类云厂商平台，大趋势将逐步作为基座形态稳固并开源，随着赛马竞争的产生，最后获胜的几家将成为未来模型行业的底层基座。前几年从零训练模型的工作模式将越来越少，未来更多将是基于这些基础 LLM 模型的微调与扩展。
除模型服务外的基建层，还有多种检索增强的方式用来扩展模型的上下文，使得模型可以更加了解用户，做到真正意义的个性化推荐。就像几年前的今日头条和抖音，之所以能脱颖而出，并不完全是因为技术实现层面多牛逼，而是它在正确时间做出了正确的决策，对用户的个性化视频推荐是最大的卖点。检索增强使得模型可以在各种垂类场景针对用户的习惯、场景进行更精准地答复，未来个性化的模型服务将会成为大的趋势。
而基建层的逐步完善将加速应用层的接入，并从各个层面提高应用层的能力。以 AI 编码为例，在几个月前 Cursor、Windsurf 的出世惊艳了很多开发者，与常规的 AI Extension 不同，Cursor 将 AI 能力集成到 IDE 中，AI 将对用户在 IDE 中所有的操作和行为路径都具备掌控力。
大量的用户路径、代码信息等内容的检索增强下，再配合能力在线的基础能力模型（例如 Cursor 3.5），创造了很多代码编程的奇迹，包含但不限于代码补全、个性化 Chat、问题修复、AI Agent 等多个能力，真正意义上地降低了编程门槛和提高了代码开发的效率。
虽然 Cursor 的能力足够惊艳，但它毕竟是一款由海外开发的应用产品。不考虑 VPN 等海外访问使用难度，收费各方面也是比较昂贵的，同时核心技术在海外会导致国与国竞争的垄断，像 ChatGPT 等应用一直有对中国地区的封闭。但因为 IDE 的开发门槛和技术难度都非常高，所以国内一直没有类似的竞品项目可以发布。
而 Trae AI 就是为了解决这个问题，由字节跳动 IDE 团队开发的对标 Cursor 的 AI IDE，它是第一款由中国团队开发的基于 VSCode 内核的自研 AI IDE 桌面端产品。 Trae AI 团队有大量业内知名专家，比如大家耳熟能详的天猪、死月，技术氛围浓厚平等，而且经过整个团队较长时间周期的研发、测试和严格的功能验证后才正式推出，欢迎大家的试用!
除功能上与 Cursor 对标外，而且目前支持用户免费使用 Claude3.5、GPT-4o 等海外付费模型。不过因为模型协议等原因，Trae AI 目前是作为海外版发布，所以仍需使用 VPN 等方式访问下载使用。当前 Trae AI 已支持 Mac 端和 Windows 版本的下载使用。
Trae AI 的大致信息就给大家介绍到这里了，下文我们来具体聊聊 AI 编程领域各类竞品（Trae AI 、Cursor、AI Extension）之间的差异，Trae AI 在其中的优劣，以及个人层面为什么更推荐国内的开发同学使用 Trae AI 进行开发。
竞品差异：Trae & Cursor & AI Extensions
前文我们了解了什么是 Trae AI，它是由字节跳动 IDE 团队出品的基于 VSCode 内核的 AI IDE，也是国内第一款桌面端 AI IDE。
不过光靠字节跳动、国内第一款等类似背书就说服大家使用是站不住脚的，咱不搞道德绑架，主打的就是坦诚清晰。所以本文阿民将对比几款主流的 AI 编码竞品与 Trae AI之间的差异，以帮助大家更好地选取 AI IDE 的产品。
AI Extensions & Trae
在 AI 编码发展的早期，提效的形态往往以 AI Extensions 为主，AI Extensions 的形态最为灵活，同时开发的成本也可控，只需要依赖 IDE 本身提供的 Extensions API 集成即可，例如 VSCode 团队提供的 Copilot Chat 插件，又或是字节跳动 IDE 团队提供的 MarsCode AI 插件。
在一定意义上，Trae 与 AI Extensions 并不算是竞品关系。一个是游戏的开局者，而另一个入局的游戏方，不过这两者在产品功能上一定层面可以对标，所以在这里专门作为一个竞品来对比两者的差异。
AI Extensions 的优势
AI Extensions 有着许多可见的好处，包含但不限于以下内容：
- 开发成本低，依赖具体 IDE 生态的 Extension API，不需要考虑复杂的 IDE 架构；
- 功能上线快，可以有更频繁的试错机会，因为 IDE 的沙盒机制不会直接影响 IDE 主进程，不用过多担心对 IDE 全局产生的影响；
- 可以适配多个成熟 IDE 容器环境，例如可以在 VS Code、JetBrains、GoLand 等多个 IDE 环境专门开发迭代，适配不同的用户习惯；
- 用户的安装成本低，只需要到对应的插件市场里完成安装即可，而不需要安装新的 IDE；
AI Extensions 的劣势
我们不难理解，AI Extensions 的核心优势主打的就是开发轻松、灵活轻便，对于个体开发和大部分 AI 编程产品团队非常不错的选择，但它最大的问题在于产品上限较低，这个上限问题体现在产品形态、性能和交付功能等三个方面。
产品形态
在产品形态方面，AI IDE 提供的允许 Extension API 变更的沙盒空间是有限的，并不是当前视窗内可以随便开发者更改，以 VSCode 为例，我们可以通过 Extension API 修改状态栏，活动栏，侧边栏等区域，但是如果想在代码编辑区中加一个独立的区域就无能为力了。
性能
同时在性能方面，AI Extensions 的性能上通常是不如 AI IDE 内置能力的。
以桌面端 VSCode 为例，VSCode 基于 Electron 开发，Electron 中有两个核心进程，主进程和渲染进程。主进程是一个 Node.js 进程，用于提供一些系统级的 API，例如 I/O 操作；而渲染进程是一个浏览器进程，用于视窗中元素的渲染，IDE 的原生 UI 能力会直接基于主进程与渲染进程中的 IPC 通信完成。
那么为什么负责在性能方面，AI Extensions 的性能上通常是不如同功能 AI IDE 内置能力的呢？
我们结合上述 VSCode 架构图来看，主要有两点原因：
- 插件负责后台逻辑的进程为插件进程，它是由主进程 fork 出来的插件进程，需要通过 IPC 通信的方式消费主进程中的 Service，相比框架层直接消费多了一层通信耗时；
- 同时插件中使用的 UI 层 webview，也是渲染进程提供出来的类 iframe 沙盒，性能层面不如渲染进程的原生 JS
交付功能
不仅是产品形态和性能上受限，在交付功能上，AI Extensions 的插件上限也远低于 AI IDE。这是因为 AI Extensions 所有的核心功能受限于 Extension API, 不能随意消费主进程中提供的 Service，这将直接导致对 IDE 的掌控力下降，其中包含但不限于以下信息：
- IDE 的用户行为和路径
- 仓库内容，及其向量化
- 上下文的执行意图
而这些信息的缺失，会在 AI 领域应用中效果差异尤其巨大，对比以下的两个 Prompt Demo:
{
"AI Extension": "请为以下代码生成单元测试，需要测试的代码如下xxx",
"AI IDE": "请为以下代码生成单元测试，需要测试的代码如下xxx, 该仓库使用 Jest 为测试框架，react/testing-library 为 UI 辅助测试库，同时检测到该用例存在历史用例，以历史用例的惯例需要在历史基础上增量迭代"
}
显而易见，AI IDE 可以对用户的上下文编码过程形成掌控力，进而拿到更多的上下文信息，根据分析的用户意图，进行上下文信息的权重设置后对最终 Prompt 达到检索增强的效果，这些是 AI Extension 无法做到的。
入局游戏方 & 规则的制定者
这三个上限问题对于 AI Extensions 的开发者来说，是明确但无能为力的，这也是阿民之前提到的，AI Extensions 开发者是入局的游戏方，你必须按照既定的规则玩，而对规则本身不具备掌控力，而 AI IDE 是规则的制定者，对全盘游戏具备掌控力，也可以拿到更多的上下文信息用于检索增强。
不过 AI IDE 也有它的劣势，比如：
- AI IDE 跨平台能力有限，例如 Trae 基于 VSCode 内核，对于 VSCode 用户可以做到较低成本的平迁，但对于 JetBrains、GoLand 等不同 IDE 用户的适配性就不够好了，因为如果要适配的话，要基于对应的 IDE 内核开发，而 AI Extension 只需要根据对应平台的 Extension API 开发即可。
- AI IDE 的开发成本较高，不同的 IDE 产品架构不尽相同，这些差异体现在进程设计、安全隔离、基础 Service 等多个层面，不管是从零设计还是二次魔改都有不小的成本，常规开发人员上手困难。
如果应用的场景和解决的问题是尽可能地提高用户开发的体验和 AI 上限，AI IDE 相比 AI Extension 绝对是一个更为合适的场景。
由于上文的信息量较大，这里我们再做个简单的总结，具体差异如下表格：
Cursor & Trae
相信很多同学都有用过 Cursor 了，Cursor 作为世界级的第一款 AI IDE，效果的成熟度和规划都处于领先地位。两者之间 UI 层的差异这里就不提了，毕竟交互效果这个仁者见仁，我们只聊产品和用户使用层面的优劣对比。
产品功能差异上，因为缺乏直接数据层面的评估对比，所以直接从直观感受上来说。
从个人体验来说（经历了几个月的迭代变化，一直是用 Trae 来开发的，自产自销），Trae 目前相比 Cursor 在效果上仍有一定的差距，不过差异并不是很大。作为开发提效来说，是个非常不错的选择，不过作为国内人才密度最高的工程师团队，相信是未来可期的（暂时还是个饼）。
当然除了饼以外，Trae 还有一些看得见摸得着的好处，例如：
- Trae 目前是免费开放使用，提供了 Claude – 3.5 和 GPT – 4o 等模型，虽然后续肯定会收费，但能白嫖一段时间也不损失什么。
- Cursor 的充值方式需要使用海外信用卡，包含地区认证等，有一定的认证门槛，对于国内的同学并不友好，而 Trae 后续大概率会支持支付宝等国内支付方式，付费体验上会更好。
同样地，我们也做一个简短的总结，Trae AI 和 Cursor 之间的差异如下：
到这里关于 Trae 的竞品差异对比就完成了，下篇文章开始将正式进入基础篇的学习，首先我们将来了解如何安装 Trae 并完成对齐 VSCode 的功能平迁。
基础篇
安装使用：对齐 VSCode 的低成本迁移
该模块使用的示例图取自 Trae AI 官方文档
Trae 下载地址：https://www.trae.ai
前文我们了解了 Trae AI 的相关信息，以及它与其他竞品之间的差异，本文我们将了解 Trae AI 的安装使用以及对齐 VSCode 的低成本迁移。
值得一提的是，Trae AI 之所以能够针对 VSCode 做到低成本迁移，得益于 Trae AI 基于 VSCode 内核开发，虽然在 UI 和功能上有一些特异化的调整，但 IDE 的大局架构仍然是保持的，例如 settings、快捷键、插件生态等都可以做到高度兼容，所以在用户习惯和配置迁移等方面对以 VSCode 对常用 IDE 的用户会非常友好。
安装和配置迁移
安装和配置迁移的步骤可以基本参考 Trae AI 官方文档：
- 访问 Trae AI 官网安装，值得一提的是，因为官网部署在海外，需要通过 VPN 等方式更换本地 IP 访问。
- 安装完成后，点击 Trae 图标打开，按照指引完成背景主题、语言的设置即可。
- 有意思的是，Trae 提供了配置迁移和插件迁移的能力，只要你在基于 VSCode 内核开发的 IDE 中使用中，例如 VSCode 和 Cursor 的配置项都可以直接一键迁移过来
- 在 VSCode 中我们常常会使用 code xx来打开指定的目录，Trae 也提供了类似的功能来设置命令行执行
这一步完成后，我们将可以使用下面的命令方式打开需要的 app 应用
trae my-react-app
- 到这里基础的配置就完成了，我们可以按照指引完成登录后使用。目前支持 Github 和 Google 两种登录方式，大家可以使用自己常用的方式登录。
完成登录后，就可以开始体验 Trae 了，下文我们将开始具体了解 Trae AI 提供了哪些有意思的 AI 功能。
插件迁移
虽然 Trae AI 基于 VSCode 内核开发，但是 Trae 插件市场并没有直接获得 VSCode 授权，这也导致 Trae 目前无法拉到 VSCode 插件市场中的全部插件，可能会遇到插件搜不到的情况。
以前 VSCode 官方市场可以支持下载插件的 vsix 包，我们可以通过下载 vsix 包的方式直接引入到 Trae 中，如下图。
不过目前已经不支持下载对应插件的 vsix 离线包了，但仍有快速引用的方式，我们可以先在 VSCode 或者 Cursor 中下载对应的插件，然后在 Trae 的设置页中点击同步按钮同步插件即可，如下图。
Chat：编码阶段的 AI 即时响应
Trae 下载地址：https://www.trae.ai
本文开始我们将来了解 Trae 提供的基础 AI 功能，首先将给大家安利的就是 Trae 提供的 Chat 功能，Chat 功能根据所处的位置不同分为 SideChat 和 InlineChat 功能。
相信很多同学会有疑问，这样的一个 AI 问答功能在很久以前就烂大街了，包含但不限于 ChatGPT、Kimi 等功能，那这玩意有什么价值呢？所以在介绍实际的功能前，我们先聊聊 Trae 的 AI 问答相比其余的问答功能有什么不同。
Trae AI 问答有什么特殊之处
在前文竞品对比那一章我们有聊到，AI IDE 最大的优势就是可以对整个编码环境形成掌控力，可以拿到包含但不限于仓库向量、用户行为路径、上下文信息等用于检索增强。
对于 Trae AI 的单次问答，有很多内部的细节，比如像意图识别之类的隐性过程。通过分析用户问题的意图，Trae 会有不同的策略选取差异化的上下文信息用于检索增强，进而达到即使用户上下文信息不完整仍然可以高精准度答复的效果。
例如我们来看下面的这个例子：
- 打开某一个编辑区代码
- 询问 Chat 模块，这段代码写了什么
可以看到结果上，虽然我并没有指出这段代码是什么，但 Trae 会帮你自动补充想问的代码块，也就是参考区中呈现的 index.js。
通过这种方式，Trae 做到了真正懂开发者的问答，而不是脱离上下文有点傻乎乎的人工智能。这些特殊处理在 SideChat 和 InlineChat 模块中均有体现，下面我们就来具体聊聊它们分别提供了哪些有意思的功能。
SideChat
SideChat 在 Trae 的右侧区域，我们可以通过快捷键 Command + U 或者点击 IDE 右上角区域的切换 AI 侧栏调起。
SideChat 的问答功能在 Chat Tab 下，Builder Tab 是另一个有意思的 AI Agent 的功能，这个我们会在后续的进阶篇中学习使用。在顶部栏右侧还有三个按钮，分别是：
- 新建聊天
- 历史聊天
- 关闭 / 收缩 SideChat
这个都是老生常谈的基础功能了，这里不赘述，大家自行体验即可。
SideChat 还提供了很多有意思的小细节，比如多模态的支持，通过点击输入框中的图片 Icon，我们就可以上传图片，使用图片媒体去和模型交互，例如下面的这个 case：
有一些需求仅使用文字是很难描述清楚的，而通过 Trae 多模态的图片辅助，帮助问答更好地理解用户需要什么。
InlineChat
InlineChat 在代码编辑器中，便于用户随时在代码开发阶段询问内容，我们可以通过两种方式调起：
- 将光标放在编辑器中并使用快捷键 Command + I
- 在编辑器中选择任意代码，然后使用快捷键 Command + I 或单击浮动菜单中的 “编辑” 按钮
然后我们就能开始问答方向的询问了～
当然还有其他的一些有意思的功能，这里先卖个关子，我们在后续的进阶篇详细介绍它们的用处，和设计它们的意义。这里大家可以先按照自己的想法随意摸索玩耍，可能在后续的交流中能产生新的碰撞。
补全：编码的静默辅助能力
上文我们了解了 Trae AI 提供的问答功能，它利用对 IDE 的掌控力对用户的问答进行了检索增强，使得 Trae 可以根据用户的需求进行精准度更高的答复，真正成为一个懂用户的 AI。
除问答功能外，Trae AI 还提供了一个非常有用的基础功能，也就是补全功能。当我们在代码编辑区写了一些逻辑后，并停留一段时间，Trae AI 会自动为已经生成的代码提供下一段提示，例如下面的case：
我们在编辑区中写一个函数定义 function bubbleSort()
Trae 会自动对当前的代码内容进行识别补全，我们可以通过不停地按 Tab 键接收当前给出的提示内容
最终拿到的冒泡代码效果如下。
如果给出的补全内容不满意，我们也可以后退一个字符再加上，等一会儿刷新最新的补全内容，或者通过增加一些注释来对补全的内容进行增强，同样如果要接收这段代码，也使用 Tab 进行接收。
到这里补全的功能就介绍完了，这是一个非常有用的功能，可以帮助大家更快高效地完成代码的迭代和更新。
设置：AI 功能的个性化配置
上一节我们介绍了 Trae 提供的补全功能，通过补全功能可以支持用户在开发阶段静默提供提示，是个非常好用的功能。当然 Trae 除了提供实用的问答和补全功能外，也提供了一系列针对 AI 功能的个性化配置来帮助大家根据自己的使用习惯灵活调整 AI 功能的一些细节。
AI 功能的个性化配置可以点击右上角人物头像的位置，单击后会弹出一个悬浮弹层，其中有个选项是设置选项
点击设置选项后，会出现一个包含大量配置项的 webview 视窗页，如下图所示。
其中 Trae AI 分类下的设置项为与 Trae AI 功能相关的配置，我们滚动到指定行可以看到目前有三项配置：
- AI 会话语言：这个用于决定 AI 功能使用的交互语言，它与 IDE 的语言没有直接关系，修改这个配置项后 AI 功能会使用对应的语言进行答复。
- 代码索引管理：这个相对比较复杂，我们下面专门介绍。
- 快捷键设置： 用于调整 AI 功能的快捷键设置，如果 AI 功能的某些快捷键覆盖了你的默认热键，可以使用这里进行调整。
值得一提的是，代码索引管理是什么配置项呢？
在 Trae 初次打开某个工作空间后，会为当前工作空间的代码建立向量索引，向量索引是当前工作空间的代码数字化分片，在后续的 AI 功能交互中，会根据上下文的差异进行相似匹配，检索出最为相似的内容用于 AI 的问答增强，这个技术被称为 RAG。
我们举一个简单的例子：
未使用 RAG: 请帮我优化这处代码 xxx
使用 RAG: 这处代码有如下相关上下文信息 xxx，请帮我优化这段代码
可以明显感受到，在 RAG 相似检索准确的前提下，使用 RAG 进行问答的内容效果会高于未使用 RAG 的场景.
这个配置项的作用就是让用户能够主动更新检索，或者在检索构建失败的场景下更新检索，进而增强 AI 功能的综合效果，通常正常状态下不需要用户主动去调整。但如果大家在使用的过程中，发现 AI 变笨了，或者说无法针对项目空间去针对性地解决问题时，就需要考虑去主动更新检索了。
进阶篇
Builder：AI Agent 的编码应用形态
前文我们提到 Trae 中有许多上下文信息，这些上下文信息会根据用户的意图进行不同权重的 Prompt 补充，来增强 AI 的功能。但 Trae 默认设置的上下文信息辅助未必是全面且完美符合用户预期的，所以 Trae 也支持用户主动提供一些信息作为 AI 功能的上下文。
上下文的添加有两种方式，一种是在用户交互界面，另一种是通过 # 的方式快速添加，我们来分别介绍。
用户交互界面
Trae 的用户交互界面中，提供了快速作为引用的方式，支持添加的位置包含代码编辑区和终端区。在代码编辑区中我们可以 hover 任意一段代码点击添加到对话，这样这段代码就会作为一段上下文引用被放置到 AI 功能中。
可以看到问答框中将会出现一个对 index.ts 的引用，单击对话框中的指定引用区也会跳转到对应的代码内容。
除代码块外，终端的引用也是一个常见的操作。我们经常会在终端中执行一些i编译或者构建的脚本，这些脚本可能会出现依赖版本或者冲突的一系列问题，就可以通过语境的方式快速添加指定的报错信息引用到对话框中，添加的方式同样是 hover 点击“添加到对话”。
# 快速添加语境
Trae 也提供了快速添加语境的方式，在问答框中输入 # 号， 将可以调起语境的悬浮弹窗。
除了便捷外，这个功能其实相比用户交互界面的手动添加，其实还有一个额外的好处是，可以支持非单例文件的添加，例如文件夹和工作空间。
毕竟，有的时候作为用户，也不想问个问题前都绞尽脑汁想它的上下文语境是什么，对吧～
这种情况下，如果 AI 功能效果不好，不妨试试主动加一个 #workspace 或者 # folder。当然如果大家心情不错，有耐心的话，# folder 的效果会更好，因为 # workspace 可能会添加过多的无效信息干扰到 AI 需要的重要信息。
至于单文件语境的添加，我还是建议大家采取用户交互界面的方式添加。个人认为，对于大文件使用 # 添加单文件真的是一个低效的交互，一个大型项目用 # 选到某个文件某几行，真的会谢 TT
FastApply：高精准度的 AI 生成应用
我们在日常问 AI 的时候，除了信息的获取场景外，其实有一个更广泛的需求是，希望 AI 能帮我们做完”作业“，也就是直接将结果应用到代码中。
前文在介绍问答功能的时候卖了个关子，有一个有意思的功能我没特别介绍，那就是 Fast Apply。而 Fast Apply 功能就是为了解决这个问题设计的，它可以支持对 AI 问答后的结果进行高精准度的合并，也是在后续进阶篇 Builder 中会大量应用到的一个基础功能。
Fast Apply 功能怎么用
FastApply 使用的方式也非常便捷，每次问答完成后，顶部栏的区域最右侧有一个应用的按钮，单击后会将对应的代码内容应用到项目空间中。
在应用后，右侧的问答区域底部会出现一个审查区域，虽然 Fast Apply 经过多轮测试来保证它的合并效果，但 AI 的功能多少会有一些不符合预期的点。所以每次应用都是作为临时区域合入，大家可以通过吸底的审核区域确认所有 Fast Apply 的任务接受与否。
对于已有的文件 FastApply，会采用类似 Diff 区的交互展示。
可以看到最终写入的结果并不会有冲突，或者插入位置错乱的问题，个人感觉这是 Fast Apply 最有意思的一个点，最低的下限也能保证生成的代码处于可用状态。
而对于效果不理想但误采纳的代码，Fast Apply 也提供了与之配合的回滚功能，通过回滚功能，用户可以更轻松地将某个误采纳的 Fast Apply 结果回滚至之前的状态～
除 Fast Apply 外，问答还有一些其他有意思的基础功能，例如指定添加到新文件等，触发位置也在顶部栏区域，那部分功能就很简单了，这里不做特别介绍，大家可以直接体验试试～
Builder：AI Agent 的编码应用形态
随着 AGI 的发展，现在的 AIGC 应用慢慢地从问答到应用层面发生变更。用户不仅希望可以从与 AI 的问答中获取到片段的信息，也需要拿到一个基础可用的应用，这种交互方式也叫 AI Agent。
前文我们已经了解 Trae 的很多功能，比如 Chat、补全、语境、Fast Apply 等，这些功能的特点是单点完成某项任务，但是与 AI Agent 生成一个成型应用之间仍有差距。
这节我们就来接触 Trae 提供的另一个功能 Builder，它的作用就是让 AI Agent 的编码应用形态得以在 IDE 中落地，支持在编码的任意阶段介入，并从 0 到 1 生成某个基本可用的完整功能。
Builder 功能的唤起同样是使用 Command + U，它位于 Chat Tab 的右侧，与问答不同的是，Builder 由多轮 AI 对话组成，并且会完成文件的只读写入，比如我们使用 Builder 生成一个贪吃蛇游戏。
从这里也可以看到 Builder 是多轮 AI 对话组成的，在每一段内容完成后，会进行下一次 AI 的深度思考。
在整个 Builder 过程完成后，我们可以拿到与 Fast Apply 类似的审查结果，选择全部接受后，就可以运行看看效果了，第一次执行效果如下图。
第一次执行并不顺利，有逻辑上的报错，这个在 AI Agent 的场景中时有发生，不过我们可以先不用手动调整，通过 Builder 尝试修复即可。
修复后我们再次运行，可以看到贪吃蛇游戏已经能正常启动了。
因为 Builder 功能本身基于 Fast Apply 功能，所以 Fast Apply 提供的回退等功能在 Builder 功能中也是保留的，这里就不再赘述了。
除 Demo 外，Builder 功能也可以应用到项目开发中，用于迭代某个具体功能，或者修复 bug，有点像 deepseek 提供的深度思考功能，大家可以体验试试！
Git：AI 异常写入后的必备姿势
前文我们介绍了很多 Trae 提供的各式 AI 功能，可以帮助大家提高编码的效率。但不得不接受的一个事实是，AI 目前还没到可以作为绝对正确成品的程度，有时候会带入一些隐性的 bug，或者生成效果与预期不符。
针对这种情况，Trae 其实提供了回滚的功能帮助大家回退到之前的版本，前提是大家能找到对应的对话，并进行回滚。对于会话过多无法定位，或者已经通过 git 提交的场景，这个功能就很难再完成回退了。
因此了解基本的一些 GIT 回退操作也是非常必要的，虽然这个话题已经是老生常谈了，但是考虑到一些新手同学并不是很熟悉这些操作，为避免 AI 功能对大家的编码造成困扰，所以希望同学们还是允许我赘述一下这些场景下 GIT 操作的姿势。
如果已经是非常熟悉 GIT 的同学，可以跳到下一章实战篇开始学习，节省时间，姿势不完整的地方大家也可以在评论区讨论指正～
风险代码提交了 Commit ，但未推至远程
假设 AI 生成代码后，我们提交了 Commit，但未推至远程，也就是扔在本地
git commit -m "xxxx"
这种我们可以使用软回滚的方式完成回滚，先使用 git log 查询需要回滚至的仓库版本，然后使用 git reset –soft 软回滚撤销本地的 commit 即可。
git log
git reset --soft xxx
值得一提的是，reset 提供了 soft 和 hard 两种参数用于设置回滚的形式，它们分别是软回滚和硬回滚：
- 软回滚：撤销 commit，但是保留工作区修改，也就是可以再次修改后提交
- 硬回滚：本地将丢弃所有的变更，工作区变得与指定 commit 一致
所以在这种场景下，通常使用软回滚是更合适的，因为 commit 的代码仍然需要保留在工作区。
风险代码已经推送至远程分支，但未合入
假设风险代码已经推送至远程开发分支
git commit -m "xxxx"
git push
这种很好解决，我们只需要直接修复，并覆盖 commit
git commit --amend
git push --force-with-lease
如果暂时不确定修复方案，可以先使用软回滚调整工作区内容到本地，并强推
git log
git reset --soft xxx
git push --force-with-lease
需要注意的是，这里的强推需要避免使用 git push -f，在多人合作场景下，push -f可能会覆盖其他人的代码，而 push –force-with-lease 是一种更安全的强推做法，如果强推阶段的本地 git tree 落后于远端 git tree，push –force-with-lease会禁止强推，并引导你完成本地内容的同步后再进行后续操作。
存在风险代码的远程分支合入了主分支
如果存在风险的代码分支已经合入了主分支，这种需要第一时间进行回滚止损。与非主分支的回滚不同，主分支应该禁用直接的强推操作，我们需要使用 revert 完成分支的回滚。
git log
git revert xxx
与 reset 回滚不同的是，revert 会创建一个新的 commit 用来撤销之前变更的内容，常用于主分支的回滚场景。
实践篇
SSR：基于 Next.js 的可登录文档站点
前文我们接触了和 Trae AI 相关的基础功能和进阶功能，从本节开始，我们将正式进入实践篇的学习，以具体的项目出发，基于 Trae AI 从零完成不同类型项目的开发搭建。
值得一提的是，虽然只是小册子的实践，但项目本身还是希望可以脱离过于简单的 Demo 程度，都挑选了一些有实际业务场景和复杂度的项目，所有的代码将尽量用 Trae AI 直接生成，并介绍生成的整个过程以及对应节点的耗时情况，希望对大家的使用能有所启发。
这一节我们来实现一个基于 Next.js 的用户文档站点，类似低配版掘金，它满足几个功能：
- 支持用户注册、登录、退登
- 支持进行用户维度的文档增删改查，并进行数据独立存储
项目初始化（耗时 5 分钟）
在 Builder 模块使用如下提示词完成项目初始化：
在当前工作空间完成 Next.js 项目的创建，并完成依赖安装
根据 Builder 的引导执行指定的 shell 脚本，然后点击预览功能，将在 Trae AI 中打开一个 webview 进行指定端口的访问，可以看到一个初始化的 Next.js 项目已经初始化好了。
登录模块的实现 （耗时 30 分钟）
下面我们实现了一个注册、登录和退登的功能，全过程没有直接上手写一行代码。中间过程的问题排查与修复以及新增的需求都由 Builder 完成。
基础功能的实现非常顺利，数据库选型使用的 mongodb。不过在运行的时候发现页面报错了，第一次修复为 Builder 提供了图片作为多模态辅助判断，但它的自行修复失败了，它给了错误的判断。
所以这里自己调试了一下，提供了更具体的错误信息，初步判断应该是 mongodb 未正常安装启动，Builder 开始指引完成依赖的安装，这个问题顺利修复。
到这里注册、登录的功能就完成了，我们还需要一个退登的交互。退登的逻辑也经过两次询问，初版生成的退登交互的初始状态可能会异常，无法即时同步。
到这里注册、登录和退登的功能就实现完了，我们看看效果，注册的账户是 test，登录后会呈现在右上角。
支持文档的增删改查 （耗时 60 分钟）
与登录模块实现类似，我们先使用 Builder 来实现整体的交互。
期间出现了网络或者模型 API 不稳定的情况，导致失败了，对于这种情况大家可以再补充一个“重试”或者“继续”的 Prompt 保证任务完整，初版交互的生成耗时了同样 30 分钟左右，具体交互如下所示。
不过有个问题是文档的创建无法正常使用，documents 接口（负责文档的增删改查）报错 401 鉴权异常。目前使用的方案是用的 Next.js 提供的 next-auth/jwt 实现 JWT 鉴权，这部分修复坦诚地说花费了不少的时间，约 30 分钟。
前期的修复方案我还是让 Builder 帮我在现有方案基础上进行修复，我尝试了多模态、 语境等手段提供了不同维度的排查信息， 不过 Builder 一直没有修到重点。同时因为最近用得太多，个人账号触发风控策略了，一直限流…这部分体验有点难受，找同事帮忙开了白名单才得以继续。
其实通过这个过程，我们可以意识到，通常一个问题如果询问了 3 – 4 次后，仍然没有修复，说明这个问题大概率 Builder 也解不了了，这时候需要提供更细致的问题原因、补充信息或者换个思路。
另一个原因也是因为我不熟悉 next-auth/jwt 这个库，也不太想专门去看它的文档，没有提供更细致的初步排查归因，所以让它换了常规的 JWT 实现。
现在站点已经支持了文档的增删改查，我们来看看效果吧。
不过看上去还有一些问题，虽然不影响使用，报错是这样的
根据 Next.js 官方文档的说明，服务器端的动态参数需要使用 await 访问属性，我们加上 await 就行。
交互优化（耗时 5 分钟）
最后我们优化一下交互，同样使用 Builder 完成，附带一张掘金的截图作为参考
最后优化效果如下图
当然我们也可以考虑做更多的事情，例如首页推荐、评论区等功能，感兴趣的同学可以课后进一步尝试。
CSR：基于 React 的后台管理平台
前文我们使用 Trae 从零搭建了一个用户文档站点，支持了基本的用户注册登录 + 文档的增删改查，最主要的是整个过程只用了 2 个小时不到的时间，同时我们自己并没有写任何一行代码，这是一个很大的突破。
但是惊艳的同时，其实我们也可以反思得到几个可以进一步加速的行为：
- 由人为控制一定架构，而非完全放权给 AI；
- 降低每次 Builder 的粒度，将大问题拆成 n 个小问题；
- 当一个类型的问题，Builder 多次生成异常的时候，需要考虑换个思路或者提供更多具体方向或者信息进行强化；
这一节我们来进一步强化上面学到的基础概念，在上文 Next.js 的站点基础上我们为它搭建一个 CMS 系统作为后台管理。数据库我们与前文的 SSR 官网复用一套 mongodb，这个 CMS 系统提供两个功能：
- 用户管理
- 文档管理
项目初始化（耗时 10 分钟）
我们在当前的工作空间下，提出 CMS 系统的技术诉求。因为需要与 SSR 官网复用一套 mongodb，所以工作空间我们要在之前的 SSR 项目下，以确保 Builder 功能获取到前者的 mongodb 上下文。
生成完项目后我们正常运行，看到终端执行有一些问题，我们参考语境章节的做法，选取终端中的错误，添加到 Builder 上下文中，完成对应的修复。
然后我们让 Builder 帮我们运行这个项目就可以看到前文 Trae Document 的 CMS 系统雏形就已经搭建好了。
这里技术栈为了呈现简单，所以使用的是 React + webpack 搭建，如果项目复杂，大家也可以考虑使用 qiankun 等框架设计成微前端架构，每个导航模块独立成微前端子模块，非常适合用于复杂维度的 CMS 系统。
用户管理（耗时 30 分钟）
首先还是使用 Builder 完成需求的生成，要求与 ai-ssr 空间的 mongodb 复用。
初版效果创建完成后，打开发现终端存在 ts-loader 的报错，无法运行，让 Builder 修复一下。
修复完成后，虽然可以运行了，但是 user 的路由并没有变化，还是初始化的呈现，排查后发现是 route没有更新，让Builder 进一步修复一下。
修复后终于可以打开了，不过报错获取用户失效，我们在 network 里看看具体原因，发现 404 了。
进一步检查发现，是请求的服务端口号不对，因为 mongodb 的服务 api 是挂在 SSR 项目上的，所以需要配置代理请求 SSR 项目的服务。确认原因以后，让 Builder 进一步修复。
到这里用户管理的功能就可以正常使用了，效果如下图
文档管理（耗时 20 分钟）
有了用户管理的成功案例，文档管理我们照猫画虎就好了，因为有可参考模块，模型的答复也会更加精准。同样地，我们先用 Builder 生成初稿。
不过这次的初稿打开就报错了，看错误栈报错的地方是 antd 的 table 组件。
看错误栈大概率应该是初始化的时候还没读到数据，导致 rawData 不是数组，组件源码中又没兼容异常数据类型导致的，我们尝试让 Builder 完成修复，这里提供了错误栈信息和复现渠道来帮助 Builder 更好地判断。
可以看到 Builder 的判断非常正确！通过添加了兜底的方式规避了这个问题，现在文档管理的功能也实现完成了，效果如下。
经过两个实践课程的学习，我们不难发现 Builder 的使用其实就是几个步骤：
- 拆解需求，将大需求拆成多个小需求，如果能自己完成一定的架构设计，Builder 实现会更精准；
- 使用 Builder 生成需求初稿，这个过程可以提供交互图进行增强；
- 改 bug，生成的初稿会有大大小小的问题，需要针对性修复；如果修复的不顺利，可以考虑提供更多的信息，比如错误栈截图、语境又或是人工的初步错误归因来缩小修复范围。
本节的功能我们就实现到这，进一步扩展我们还可以考虑联表等复用型的功能，感兴趣的同学可以课后进一步尝试。
SSG：基于 Next.js 的静态官网
在现代 Web 开发中，渲染技术是决定应用性能、用户体验和 SEO（搜索引擎优化）的关键因素之一。目前最常见的三种渲染技术分别是 SSR（服务器端渲染）、CSR（客户端渲染） 和 SSG（静态站点生成）。
前文我们使用 Trae Builder 分别实现了 SSR 和 CSR 的渲染应用。这两种渲染技术形态的应用被广泛应用在 C 端和 B 端场景下， 除此之外还剩最后一种常见的渲染技术 —— SSG 。SSG 是一种结合了 SSR 和 CSR 的折中方案。它通过在构建阶段提前生成静态 HTML 文件，并将这些文件部署到 CDN 或静态服务器上。当用户访问时，直接从静态文件中获取内容，常用于对 SEO 要求较高的 to C 场景。
这节我们就来使用 Trae Builder 搭建一个 SSG 的应用， 做一个仿 Trae AI 首页的静态的官网。
项目初始化（10分钟）
老规矩，我们还是使用 Builder 先生成一版初稿，描述清楚希望使用的技术栈、项目背景，补充适当的语境以及截图来扩充效果。
生成的效果如下，可以看到除一些图片视频没有外，大体的结构已经完成了，整体的完成度还是偏高的。
交互优化（40分钟）
虽然交互大部分都完成了，但是还是有很多小细节需要优化的，比如：
- 顶部栏的居中对齐做得不够好；
- 主体部分的交互残缺；
- 缺少入场动画；
我们下面来一一进行优化，首先先调整一下顶部栏的居中问题。
虽然顶部栏的垂直居中调整好了，但上下文的间隔细节不太好看，而且底部的那一栏右侧区域是残缺的，我们让 Builder 补全一下 svg。
最后再让 Builder 给文字添加渐变动画就完工了。
到这里静态站点就实现完成了，我们来看看效果。
结束致辞
拥抱变化：AI 编码的妙笔生花
前文我们已经介绍了 WEB 形态中 Trae AI Builder 功能的应用，有非常亮眼的表现。除了常规的 Web 应用，跨端 APP、桌面端、服务应用、基建都可以在 Builder 功能有一席之地。这个变化对于整个互联网行业，尤其是一些初创团队和个人开发者来说，试错搭建一个全新的应用门槛更加低了，让一些愿望和想法得以有了落地的机会。
Trae 任重道远
坦诚地说，目前 Builder 的效果还是适合解决单个问题，或者复杂度中下的项目，对于复杂度高需要调试的场景仍然是不足的，比如一些体验不好的点：
- 解答思路不对的时候，再怎么问可能也是错的；
- 单次问答的时长过长，繁重的意图识别和上下文检索除了提高了问答的精准度外，也提升了大量的时间；
- 稳定性仍需提高，还是会出现不少网络异常、API 不稳定等原因；
- 自校验机制不够完善，有一些内容无法自搜集，导致生成的结果不能自洽；
对于这些不好的点，我们也可以通过一些另类的手段对功能进行强化：
- 由人为控制一定架构，而非完全放权给 AI；
- 降低每次 Builder 的粒度，将大问题拆成 n 个小问题；
- 当一个类型的问题，Builder 多次生成异常的时候，需要考虑换个思路或者提供更多具体方向或者信息进行强化；
同时 Trae 团队也在持续的优化中，相信在不久的将来也可以有更好的效果呈现出来。
编码的未来
接触了两年多生成式 AI 后，个人越来越觉得编码领域在未来会产生颠覆性的变化，比如：
- 几乎没学过研发的同学也可以借助 AI 完成一些 demo 产品的开发，想法的实现更加简单；
- 学习一门编程语言的成本越来越低，以前需要以月维度计的学习成本，现在被缩短到几周甚至几天；
- 基建层的超预期发展，像 deepseek 、 claude ，不再是暴力砸显卡投成本，而且更关注训练手段；
- 基建层的能力从 2 年前的基本问答，到现在 AI Agent 的应用生成，效果突飞猛进；
最近我也和各行各业的同学朋友们交流了我的担忧和想法：
未来程序员的失业是否会进一步加速？
AI 知识面的深度广度远超过我，技术的未来又是什么？
无可否认，一种可能是，未来中初阶的程序员都会被 AI 取代，行业的门槛被大幅拉高，只需要保留 AI 不能替代的训练人员和专家组。
我们无法确定未来，只能选择拥抱变化，就像以前的工业革命，机器代替纯手工、淘汰纯手工，留下的只剩下操作机器的人和钻研到极致的工匠艺术家。AI 会替代岗位，也会带来新的岗位，更快更敏捷地接触拥抱时代，我们个人才会有更好的发展，而接触 AI 编码可能就是一个起点。
小册初衷还是点燃一个火种，火种的传播和逐步旺盛还需要仰仗大家共同的努力，同学们感兴趣的方向也可以在评论区里讨论交流 case 心得和对未来时代的期望。
经过这章节的学习，我们不难发现，Trae AI Builder 对于初步的 UI 搭建是非常合适的，有几个小技巧：
- 善于使用图片截图来补充信息；
- 设计图可以选取单一元素，来进行强化，比完整的设计图来补全完整元素效果会更好；
- 不好描述一些细节点的时候，可以用画笔进行红框标注，并且新增一些标注数字，来帮助 Builder 确认想新增的元素区域；
