06 · Builder 模式深度解析

Trae 最独特的杀手级功能，把 Bolt.new 搬进桌面 IDE，从一句话到可运行项目只需 30 秒。

01 Builder 到底是什么

Builder 是 Trae 区别于 Cursor、Claude Code 乃至所有其他 AI IDE 的最独特功能。你不妨先想一下这个问题：

你在 Cursor 里从零新建一个项目的时候，流程是什么样的？

答案通常是：你手动 npm create vite 或 git clone 一个模板，再打开 Cursor 让 AI 改。Cursor 没有一个”从空白到运行”的原生工作流——它是”已经有一个项目，AI 帮你改”的助手。

Builder 填补了这个缺口。

Builder 是内嵌在 Trae 桌面 IDE 中的全自动建项目模式。 你用自然语言描述想要的应用，Builder 自己完成整个流程——规划架构、创建文件、写代码、安装依赖、启动开发服务器，然后在右侧 Webview 里给你一个可以交互的实时预览。

用一个比喻来理解：Cursor 的 Agent 模式像一个超级高效的编辑——你有了稿件框架，它帮你填充、润色、调整。而 Builder 像一个出版公司——你跟编辑说你想要一本什么主题的书，他组稿、排目录、请人写每一章、设计封面、印刷装订，最后把样书放在你桌上。

关键在于：你在桌边看着他出稿，随时可以喊”这里改一下”、“那个换个说法”。

02 Builder vs Bolt.new / Lovable

Builder 的体验和 Bolt.new、Lovable、v0 等网页端建项目工具有相似之处，但有几个根本性区别。

相同点

它们本质上都在解决同一个问题：把”想法→代码”这个过程压缩到分钟级。

不同点

核心差异

Bolt.new = 浏览器沙盒 + 远程 AI

Builder = 本地桌面 IDE + 本地 AI

这意味着：

• Bolt.new 里项目的运行依赖于 StackBlitz 的远程沙盒——你看到的预览是通过网络传输回来的渲染结果。复杂项目、需要后端服务的项目、依赖本地数据库的项目，在 Bolt.new 上很难完整实现。
• Builder 的项目就运行在你电脑上——npm install 是本地装的，dev server 是本地起的，Webview 直接连 localhost。这意味着任何技术栈、任何后端服务、任何本地数据库，都能跑。
• 用 Builder 建完的项目就是你电脑上的一个正常文件夹——你可以切换到 SOLO 模式继续开发，可以 commit 到 Git，可以 deploy，可以用你所有的 VS Code 插件。

03 Builder 完整工作流

Builder 的工作流程可以概括为 6 个阶段。理解每个阶段做什么，能帮你用好这个工具。

你输入一句话描述
    ↓
01 需求分析 —— AI 拆解需求，列出实现步骤
    ↓
02 方案确认 —— 你审阅计划，可以调整或直接执行
    ↓
03 代码生成 —— AI 依次创建文件、写代码
    ↓
04 环境搭建 —— 自动装依赖、配置项目
    ↓
05 启动预览 —— 启动 dev server，Webview 展示
    ↓
06 迭代修改 —— 追加描述，AI 增量更新，即时刷新

阶段一：需求分析

当你在 Builder 底部输入框写下需求（比如”用 React + Tailwind 做一个番茄钟计时器”），Builder 不会立刻开始写代码。它先做一件事：拆解需求。

你会看到左侧的步骤列表逐步展开：

1/8  分析需求：番茄钟需要计时、暂停、重置、设置时长
2/8  设计架构：确定组件树和状态管理方案
3/8  创建项目脚手架
4/8  编写 Timer 组件
5/8  编写设置面板
6/8  添加样式（Tailwind）
7/8  安装依赖并启动
8/8  运行预览

这个过程通常耗时 2-5 秒。你可以在这个阶段直接点击”执行”，也可以展开任一步骤看细节，甚至自己编辑计划。

阶段二：方案确认（可选）

Builder 会给出一个简要的技术方案摘要，你可以快速审阅：

📋 技术方案

• 前端框架：React 18 + TypeScript
• 样式方案：Tailwind CSS
• 状态管理：React useState + useEffect
• 组件结构：App → TimerDisplay / SettingsPanel / Controls
• 构建工具：Vite

如果你觉得方案不合适（比如你更想用 Vue 而不是 React），可以在这一步打断 Builder，重新指定。方案确认后，Builder 进入执行阶段。

阶段三：代码生成

Builder 逐文件生成代码。你会看到：

• 编辑器自动打开每个新文件
• 代码逐段写入（不是一次性全写完，而是像人一样逐行写）
• 左侧步骤列表逐个打勾

这个过程类似于一个开发者在你的机器上”远程工作”——你看着他创建 src/App.tsx、src/components/TimerDisplay.tsx，每个文件他都写好、保存。

阶段四：环境搭建

代码写完后，Builder 自动：

1. 打开终端
2. 执行 npm install（或 pnpm install / yarn，取决于你项目里用的包管理器）
3. 安装所有依赖
4. 创建配置文件（不管需要的是 tailwind.config.js、tsconfig.json 还是 next.config.js）

这一步的进度会实时显示在终端面板和步骤列表里。

阶段五：启动预览

依赖装好后，Builder 执行 npm run dev（或等效命令），然后在右侧的 Webview 面板 中自动打开 http://localhost:XXXX。

现在你看到的不再只是代码——你看到的是实际运行的应用。番茄钟在走、按钮可以点、数字在跳动。Webview 就是一个内置的浏览器标签页，你可以在里面正常交互。

阶段六：迭代修改

这是 Builder 最强大的部分——增量更新。你不需要从头再来，只需要在同一个 Builder 对话里追加描述：

• “把计时器文字改成红色”
• “加一个响铃功能，时间到了播放声音”
• “加上 localStorage 保存设置”
• “加一个统计面板，记录每天完成了几个番茄”

Builder 理解上下文，只修改需要的文件，然后自动刷新预览。整个过程像你和 Builder 坐在同一个屏幕前协作。

04 如何写好 Builder 提示词

Builder 的效果很大程度上取决于你的提示词质量。这里有几个实战技巧。

公式：好的提示词 = 框架 + 功能 + 样式 + 约束

框架：      "用 Next.js 14 + TypeScript"
功能：      "做一个博客，支持 Markdown 文章、标签筛选、RSS 订阅"
样式：      "使用 Tailwind CSS，浅色/深色模式切换"
约束：      "不需要数据库，文章用本地 .md 文件"

反面示例 vs 正面示例

写提示词的四个层次

第一层（骨架）：什么技术栈 + 什么功能
   → "用 Vue 3 + Pinia 做一个待办事项应用"

第二层（血肉）：数据结构 + 用户流程
   → "支持添加、编辑、删除、标记完成、按状态筛选"

第三层（风格）：UI 细节 + 交互行为
   → "用 Shadcn Vue 组件库，卡片式布局，支持拖拽排序，加删除确认弹窗"

第四层（约束）：边界条件 + 质量要求
   → "本地存储用 localStorage，不需要后端，不需要用户认证"

关键原则：先给骨架，再给血肉。Builder 的第一次生成决定整体架构走向，最好在第一轮对话里把核心需求说清楚。样式和细节可以在后续迭代中补充。

常见陷阱

• 一次性给太多细节：Builder 的上下文窗口有限，长篇大论反而会遗漏关键信息。核心功能写清楚，细节迭代补充。
• 不说清技术栈：你不说用什么，Builder 自己选——可能选到你不会的，也可能和你要的项目不一致。
• 需求不完整但期望一次到位：Builder 不是读心术。它按你的描述做事，不是按你的”脑补”做事。宁可先写 80% 的功能、2 轮迭代补齐，也不要憋一篇完美需求一次性交付。
• 忽略非功能需求：性能优化、安全策略、可访问性（a11y）——这些 Builder 不会主动做，除非你告诉它。

05 增量修改与版本历史

增量修改的运作机制

Builder 的增量修改不是”重写整个项目”。它的机制是这样的：

1. Builder 维护一个项目上下文——它知道你项目里的所有文件和它们的关系
2. 你追加描述时，Builder 自动判断：哪些文件需要改、哪些文件不需要动
3. 它只修改必要的文件，然后自动更新预览

例如，如果你说”加一个暗色模式开关”，Builder 不会重新生成整个 App——它只修改：

• src/App.tsx —— 加一个 ThemeProvider context
• src/components/ThemeToggle.tsx —— 创建一个新组件
• tailwind.config.js —— 配置 dark mode

其他文件，包括之前的业务逻辑，保持不变。

这个机制的关键在于：你和 Builder 的对话是有状态的。每一条消息都建立在之前的上下文之上。Builder 不会”失忆”——它记得你之前说的所有需求。

版本历史与回滚

Builder 的每次修改自动创建一个快照。你可以随时查看和回滚。

如何操作：

1. 在 Builder 面板顶部点击 Show History（或命令面板输入 Trae: Show History）
2. 看到每个快照的时间戳和修改摘要
3. 点击任一快照→预览文件差异（diff）→点击 Restore 回滚

每个快照包含：

• 修改时间
• 修改描述（“添加暗色模式”、“修复移动端布局”）
• 受影响文件的列表
• 完整的文件级 diff 对比

回滚是文件级的，不是全量级的——你可以只回滚某个文件的修改，而不是整个项目。这意味着如果你对新建的暗色模式不满意，可以只把 ThemeToggle.tsx 回滚到之前的版本，其他改动保留。

为什么增量修改很重要

想象一下没有增量修改的 AI 编程工具是什么样——

你让 AI 建了一个博客。然后说”加一个评论区”。AI 重新生成了整个项目。之前的 20 篇文章内容？丢了。你定制的那个独特布局？没了。

这就是逐一代写（non-incremental generation）的致命问题。Builder 的增量机制让它从”一次性玩具”变成了”真正可用的开发工具”。你不是只在建原型的那一刻用它，你可以在整个项目周期里持续和它协作。

06 多模态输入

Builder 支持多种输入方式，不只是文字。

支持的输入类型

图片输入的机制

你在 Builder 的输入框里拖入一张图片时，Trae 会：

1. 将图片发送给 AI 模型（Claude / GPT / 豆包 —— 取决于你的版本和设置）
2. AI 对图片进行视觉分析（Visual Understanding）
3. 提取布局结构、颜色方案、UI 组件、文字内容
4. 用这些信息作为代码生成的依据

这不是”截图转代码”那种简单的像素匹配——Builder 理解的是设计意图，而不只是视觉布局。你给一张 Figma 截图，它不光还原布局，还会分析你用了什么组件库风格、间距体系、颜色系统。

实战：一张 Figma 截图到可运行页面

你拖入一张设计稿截图
    ↓
Builder 分析：导航栏（顶部）、Hero 区域（大标题+按钮）、
功能卡片（三列网格）、页脚（深色背景）
    ↓
生成代码：React 组件 + Tailwind 样式
    ↓
Webview 预览：和截图 95% 相似
    ↓
你追加："Hero 区域按钮改成蓝色渐变"
    ↓
Builder 局部修改对应样式代码 → 预览自动刷新

多模态的最佳实践

• 截图 + 文字一起给：一张图加上一段说明（“React + Tailwind，卡片部分支持点击跳转”）比纯截图效果好得多
• 草图不必精致：纸上画的布局图都可以——Builder 更关注”布局结构”而不是”线条是否整齐”
• 多张图按顺序给：你可以依次给首页、详情页、设置页的截图，Builder 会理解它们属于同一个项目并生成对应的路由结构
• 参考截图注意版权：拿别人的应用截图做参考没问题，但避免生成和原设计几乎一模一样的 UI——这涉及设计版权

07 支持的技术栈

Builder 的技术栈覆盖取决于底层 AI 模型的知识范围。以下是经过验证的常见技术栈支持情况：

前端

后端

数据库

Builder 不像 Bolt.new 那样有沙盒限制——因为项目跑在你本地，它可以安装任何数据库。

常见组合：

• 本地开发：SQLite（通过 Prisma 或 Drizzle）
• 需要 SQL 数据库：PostgreSQL（通过 Docker 或本地服务）
• 文档数据库：MongoDB（本地或 Atlas）
• BaaS：Supabase（数据库 + Auth + Storage 一站式）

选择技术栈的策略

Builder 默认会选最流行的技术栈组合。如果你没有明确偏好，它通常会走：

React + Vite + TypeScript + Tailwind CSS

这是最安全、最稳定的组合。如果你想要其他技术栈，必须在第一轮需求描述中就明确指定。Builder 不会主动问你”用什么框架”——你说了它就用，你没说它自己猜。

08 什么时候用 Builder，什么时候切 SOLO

Builder 和 SOLO 是 Trae 的两个独立模式，但很多初学者会困惑到底用哪个。

一句话区分

Builder → 从零建项目、快速原型

SOLO → 在现有项目上做功能开发

详细对比

决策矩阵

你是要从零建一个项目吗？
├── 是 → 用 Builder
└── 否 → 你是在已有项目上加功能吗？
        ├── 功能独立且简单（单个组件、单页面）
        │   └── 你想看实时预览？ → 用 Builder
        │   └── 不需要预览 → 用 SOLO Coder
        └── 功能涉及多个文件、现有代码深耦合
            → 用 SOLO Coder

实际工作流建议

最佳实践是用 Builder + SOLO 的组合流程：

Builder 阶段：快速建项目骨架
    ↓
项目有了基础结构
    ↓
SOLO 阶段：逐模块实现业务逻辑
    ↓
功能稳定了
    ↓
Chat 阶段：逐行 review 重要代码
    ↓
Inline Edit：微调细节

这个流程的核心思路是：Builder 做”广度”，SOLO 做”深度”。Builder 帮你快速覆盖表面功能，SOLO 深入实现每一个细节。

09 Builder 的局限与应对

Builder 很强大，但不是万能的。了解它的边界能帮你避开常见的坑。

局限一：不适合大型已有项目

Builder 的设计假设是从零开始。如果在一个几万行代码的项目里打开 Builder 模式，它能”看懂”当前打开的文件，但对整个项目的理解和 SOLO Coder 不是一个量级。

应对：复杂项目加功能 → 切 SOLO Coder。Builder 可以偶尔用来”加一个独立的页面”。

局限二：非主流技术栈质量下降

Builder 对 React + Vite + Tailwind 的组合输出质量最高。换到 Angular + NgRx + RxJS，或者换成 Rust + Leptic，生成质量会明显下降。

应对：长期使用冷门技术栈的团队，可以把 Builder 用来做原型验证，然后手动调整生成的代码。

局限三：没有测试自动生成

Builder 不会自动给你写测试。如果你需要测试覆盖，需要明确告诉它。

应对：在需求里加一句”包括单元测试（Vitest）“，Builder 会为生成的组件写对应的测试文件。

局限四：不处理部署

Builder 到”本地可运行”就停止了。它不会帮你配置 CI/CD、不会帮你部署到服务器。

应对：项目建好后用 SOLO 模式执行”帮我部署到 Vercel”。

局限五：对话上下文衰减

Builder 的增量修改依赖对话上下文。随着对话轮次增加（超过 30-50 轮），Builder 可能开始在之前已经写好的文件上”跑偏”——比如重新创建了一个功能相同的文件，或者修改了之前已经稳定的代码。

应对：长对话建议”存档重启”——当 Builder 开始出现退化行为时，开一个新的 Builder 会话，把核心需求重新描述一遍。

10 实战：用 Builder 从零做一个项目

最后用一个完整的实战演示，让你看到 Builder 的实际用法。

需求场景

假设你想做一个个人项目展示站，用来展示你的作品集和写技术博客。

第一轮：建骨架

用 Next.js 14 + TypeScript + Tailwind CSS 做一个个人作品集网站。
首页展示：头像+简介、项目作品卡片（3 个案例）、技能标签云。
博客页面：Markdown 文件的文章列表，支持标签筛选。
用 App Router 模式，不需要数据库，文章内容用本地 .md 文件。

Builder 执行结果（约 20 秒）：

• 创建 Next.js 项目结构
• 生成 app/page.tsx（首页）
• 生成 app/blog/page.tsx（博客列表）
• 创建 content/posts/ 目录 + 示例文章
• 安装依赖 → 启动 dev server
• Webview 显示可浏览的网站首页

第二轮：加细节

把博客列表改成网格卡片布局，每张卡片显示文章标题、摘要和发布日期。
卡片悬停时有一点放大效果。
首页的"技能标签云"改成可点击的，点击后跳到博客页并自动筛选该标签。

Builder 增量修改（约 5 秒）：

• 修改博客列表组件 → 网格布局
• 添加 CSS hover 动效
• 将标签改为可点击链接
• 给博客页添加 URL query 筛选
• Webview 自动刷新

第三轮：加暗色模式

加上暗色模式切换，用 next-themes 库实现。
在导航栏加一个太阳/月亮切换按钮。
暗色模式的配色方案：#1a1a2e 背景，#16213e 卡片，#e94560 强调色。

Builder 增量修改（约 8 秒）：

• 安装 next-themes
• 创建 ThemeProvider 组件
• 修改导航栏加入切换按钮
• 配置 Tailwind dark mode
• 更新配色方案
• Webview 自动刷新

第四轮：部署

最后，切到 SOLO 模式，执行”帮我把这个项目部署到 Vercel”。SOLO 会自动处理 Git 和 Vercel 对接。

全过程耗时：从打开 Trae 到看到可交互的网站，约 3-5 分钟。

11 小结

Builder 的真正价值不在于”替代你写代码”——它在于降低”想法→可运行物”的摩擦。在没有 Builder 之前，你要先想好技术栈、手动搭架子、写路由、配样式——才能看到你的想法长什么样。有了 Builder，“试一下”的成本趋近于零。

Builder 心智模型：像一个不用沟通成本的外包团队——你给需求说明，他们搭好雏形，你验收，你说哪里改，他们当场改。而你坐在他们旁边，看着他们一步步做出来。

下一篇：07 SOLO 模式 —— SOLO 模式深度解析：AI 全自动工程师到底能做什么。