09 · SOLO Builder 深度解析

从一句话需求到可部署的全栈应用——SOLO Builder 的内部工作流、PRD 自动生成和 Todo Pipeline 全拆解。

01 SOLO Builder 是什么

在 Trae 的体系里，SOLO 层包含两个子智能体：SOLO Coder（精细化开发）和 SOLO Builder（快速原型）。简单区分：

一句话总结：SOLO Builder 是你给一句话需求，它帮你走完”需求分析 → 技术设计 → 编码实现 → 测试修复 → 部署上线”的全流程。

02 SOLO Builder vs 基础 Builder：自主程度的本质差异

很多新手会困惑：“Builder 模式不也是给一句话就能建项目吗？SOLO Builder 多了什么？”

理解这个问题的关键，在于AI 的自主程度。

基础 Builder：你指挥，AI 执行

基础 Builder 的工作模式是描述-执行循环：

你："做一个博客"
  AI：创建文件 → 写代码 → 停止
你："加个深色模式"
  AI：修改文件 → 写代码 → 停止
你："加上评论区"
  AI：创建路由 → 写组件 → 连数据库 → 停止

每一步都需要你发起指令，AI 只做当前这一步，做完了等你下一句。

SOLO Builder：AI 自主规划执行

SOLO Builder 的工作模式是目标-交付流程：

你："做一个带深色模式和评论区的博客"
  AI：分析需求
       ↓ 自主
      生成 PRD + 技术方案
       ↓ 自主
      拆解为 12 个 Todo 步骤
       ↓ 自主
      逐项实现（中间无需你介入）
       ↓ 自主
      测试 → 修复 → 部署
       ↓
  你：审核结果，可打断或提修改意见

本质差异：基础 Builder 是”你说一步，它做一步”；SOLO Builder 是”你说目标，它自己管理全过程”。

对比表格

一个直观的比喻：基础 Builder 是你一步步指挥一个实习生，SOLO Builder 是给资深工程师派一个 OKR——他拆任务、做执行、报结果，你只管最后的审核。

03 12 秒的 PRD 自动生成

SOLO Builder 启动后的第一件事：生成一份结构化 PRD（产品需求文档）。

当你输入一句需求（比如”做一个 AI 工具导航网站”），SOLO Builder 不是直接上手写代码，而是在约 12 秒内完成：

1. 需求分析：拆解你的模糊描述，补充业务逻辑
2. 用户故事生成：列出目标用户和核心用例
3. 功能清单：按优先级列出 MVP 和扩展功能
4. 技术选型建议：推荐技术栈并说明理由
5. 数据结构设计：关键数据模型和关系

真实的 PRD 输出样例

以下是 SOLO Builder 为”AI 工具导航网站”生成的 PRD 摘要（非完整文档）：

# AI Tools Navigator - PRD

## 目标用户
- 日常使用 AI 工具的开发者
- 寻找特定类型 AI 工具的一线工程师

## 核心功能 (MVP)
1. 工具分类浏览（文本生成 / 图像 / 代码 / 音频 / 视频）
2. 工具详情页（描述、价格、链接、标签）
3. 搜索（按名称、类别、标签）
4. 提交新工具（用户提交 + 管理员审核）

## 扩展功能 (V2)
5. 用户评分和评论
6. 收藏夹
7. API 集成（自动拉取工具数据）

## 数据模型
- Tool: id, name, description, category, url, pricing, tags, status
- Category: id, name, slug, icon
- Submission: id, toolId, submitter, status, createdAt

## 技术栈建议
- 前端：Next.js 14 (App Router) + Tailwind CSS
- 后端：Next.js API Routes
- 数据库：Supabase (PostgreSQL)
- 部署：Vercel

为什么 PRD 环节重要？

很多开发者会跳过 PRD 直接写代码。那 SOLO Builder 为什么”浪费时间”12 秒做这个？

• 对齐期望：你看了 PRD，发现 AI 理解的方向和你想的不一样——这时改 PRD 比改代码便宜 10 倍
• 减少返工：PRD 确定了数据结构和业务规则，后续代码生成有据可依，不会出现写到一半发现结构不对
• 可追溯性：最终交付的代码和 PRD 对照，你可以检查哪些功能没实现，哪些多做了

实战建议：PRD 生成后，花 30 秒认真看一遍。确认数据模型、功能范围、技术栈符合你的预期。这是整个流程中性价比最高的纠偏节点。

04 技术架构自动设计

PRD 确认后，SOLO Builder 进入技术设计阶段。它不会直接写代码，而是先生成一份技术架构文档。

它会自动决策什么？

SOLO Builder 在你描述需求时，会基于项目类型自动做以下决策：

架构文档长什么样

SOLO Builder 输出的是可执行的架构文档——不仅仅是文字，还包含目录结构和关键文件规划：

project-root/
├── src/
│   ├── app/                    # Next.js App Router
│   │   ├── layout.tsx          # 根布局（含导航栏和主题）
│   │   ├── page.tsx            # 首页（工具分类展示）
│   │   ├── tools/[slug]/       # 工具详情页
│   │   ├── submit/             # 提交工具页面
│   │   └── search/             # 搜索结果页
│   ├── components/
│   │   ├── ui/                 # 通用 UI 组件
│   │   ├── ToolCard.tsx        # 工具卡片组件
│   │   ├── CategoryList.tsx    # 分类列表
│   │   └── SearchBar.tsx       # 搜索栏
│   ├── lib/
│   │   ├── supabase.ts         # Supabase 客户端
│   │   └── types.ts            # TypeScript 类型定义
│   └── data/
│       └── seed.ts             # 初始数据种子
├── public/
├── package.json
├── tailwind.config.ts
└── tsconfig.json

关键点：架构文档生成后，你不只是看看——可以直接在 SOLO 面板里修改文件路径、增删目录，AI 会以你的修改为准重构调整。

05 Todo Pipeline 拆解

架构确认后，SOLO Builder 把整件事拆成可执行的 Todo 步骤，在面板里以列表形式展示：

□ 01/14 初始化 Next.js 项目并安装依赖
□ 02/14 配置 Tailwind CSS + 全局样式 + 深色模式
□ 03/14 创建 TypeScript 类型定义 (types.ts)
□ 04/14 初始化 Supabase 项目并设置数据库表
□ 05/14 创建数据库种子数据 (AI 工具初始数据)
□ 06/14 实现根布局 (导航栏 + 页脚 + 主题切换)
□ 07/14 实现首页 (分类展示 + 精选工具)
□ 08/14 实现工具详情页
□ 09/14 实现搜索功能
□ 10/14 实现工具提交页面
□ 11/14 实现管理员审核功能
□ 12/14 添加错误边界和加载状态
□ 13/14 运行测试并修复问题
□ 14/14 配置 Vercel 部署

Pipeline 的执行机制

每个 Todo 条目不是简单的”开始 → 完成”——它有更精细的状态机：

待处理 (pending)
    ↓
执行中 (running)  ← 你可以随时点「跳过」或「编辑」
    ↓
已完成 (completed)  ← 显示 diff，你可以点「回滚」
    ↓ (如果失败)
出错 (failed)  ← AI 自动尝试修复，最多 3 次
    ↓ (修复不了)
等待人工介入 (blocked)  ← 你去看看出了什么问题

两个隐藏操作

• 拖拽重排：Todo Pipeline 的步骤可以拖拽调整顺序——你先做后端还是先做前端，由你决定
• 折叠/展开：点击任一 Todo 可以展开看到 AI 写的详细实现说明，方便你理解它的实现思路

打断和修正

SOLO Builder 执行 Todo 的过程中，你随时可以：

1. 点 Pause 暂停当前步骤
2. 在对话里说”这里不要用 Prisma，直接用 Supabase SDK”
3. AI 会修改当前步骤的实现方式，继续往下走
4. 如果已经完成了某一步你想改——点那一步的 Rollback 回滚，重新指定方向

心智模型：Todo Pipeline 是 AI 的”开发看板”——它在执行，你在管理 backlog。你不是旁观者，是 Scrum Master。

06 部署集成：Vercel + Supabase

SOLO Builder 的区别性功能之一，是内置的部署集成。

Vercel 部署

项目开发完成后，SOLO Builder 在 Todo Pipeline 的最后一步（或你手动触发）执行 Vercel 部署：

1. 检查项目是否有 vercel.json 或正确的 Next.js 配置
2. 如未安装 Vercel CLI，自动处理
3. 运行 npx vercel --prod 触发部署
4. 返回部署 URL

如果 Vercel 构建失败，SOLO Builder 会自动读取构建日志，定位错误，修复代码，重新部署。

Supabase 集成

对需要数据库的项目，SOLO Builder 会：

1. 自动检测你是否已登录 Supabase
2. 创建或复用 Supabase 项目
3. 运行 SQL 建表语句（从数据模型自动生成）
4. 注入环境变量到本地 .env.local
5. 可选：注入种子数据

实战配置建议

# .env.local（SOLO Builder 自动生成）
NEXT_PUBLIC_SUPABASE_URL=https://xxxxx.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJxxx...

注意：SOLO Builder 部署时会把 Supabase 凭据写入环境变量，但不会把 .env 文件提交到 Git。部署到 Vercel 时，它会在 Vercel 项目设置里自动配置对应的环境变量。

07 实战：从零构建 AI 工具导航站

接下来用一个完整的端到端案例，展示 SOLO Builder 的真实工作流。

第一步：一句话启动

输入：
"做一个 AI 工具导航网站，用户可以按分类浏览 AI 工具、
搜索工具、提交新的工具。用 Next.js + Tailwind + Supabase，
部署到 Vercel。"

第二步：PRD 确认（~12 秒）

SOLO Builder 生成 PRD 后，检查几个关键点：

• 分类方式是否符合预期（文本/图像/代码/音频/视频）
• 用户提交是否需要审核（默认需要，可取消）
• 数据模型是否覆盖了核心字段

第三步：架构确认

确认目录结构和选型：

• 路由方案：App Router（对，不要用 Pages Router）
• 组件拆分：ToolCard、CategoryList、SearchBar 够用
• 状态管理：不需要额外库，Server Component + Supabase 客户端组合

第四步：观察 Todo Pipeline 执行

SOLO Builder 从步骤 01 开始逐项执行。以步骤 06 为例，展开后可以看到：

实现根布局 (layout.tsx):
- 导入 Inter 字体
- 创建 Navbar 组件（Logo + 导航链接 + 主题切换按钮）
- 创建 Footer 组件
- 添加 Tailwind CSS 深色模式支持
- 包裹 children

这就是 AI 的”实现备注”——它写每段代码前会先想清楚要做什么。

第五步：中途打断修正

执行到步骤 06 时，你发现导航栏的链接顺序不对，可以说：

"导航栏顺序改成：首页 → 分类 → 提交工具 → 搜索"

SOLO Builder 会：

1. 暂停当前生成
2. 标记步骤 06 为”已修改”
3. 按新顺序重新生成 Navbar
4. 确认无误后继续步骤 07

第六步：审核 + 部署

全部 Todo 完成后：

1. 展开每个已完成步骤，查看改动的 diff
2. 点 Preview 在 Webview 中验证功能
3. 点击 Deploy to Vercel 一键部署
4. 得到线上 URL

时间线

08 SOLO Builder 的高光场景

它天生擅长的

需求描述的最佳实践

SOLO Builder 输出质量的关键变量是你的输入质量。对比：

黄金公式：技术栈 + 核心功能 + 数据存储 + 部署目标

09 SOLO Builder 的短板——什么时候需要重写

SOLO Builder 不是万能的。以下场景，它生成的代码往往需要大量手动修改，甚至不如自己写：

1. 复杂的业务逻辑

问题：涉及多步骤状态机、时间线推理、条件分支复杂的业务规则。

• 案例：订票系统的座位分配算法、排期冲突检测
• SOLO Builder 输出：能用，但边界条件处处是坑
• 建议：让 SOLO 搭架子，核心算法手写

2. 定制化 UI——非 Tailwind 三件套

问题：SOLO Builder 默认使用 Tailwind CSS + Shadcn/ui。如果你的项目使用 Ant Design、Material UI 或其他组件库：

• SOLO Builder 输出：它会尝试用该组件库，但样式和布局的细节往往不太对
• 建议：在需求描述中明确指定 UI 库，并准备好组件库的配置示例

3. 存在大量现有代码的 legacy 项目

问题：SOLO Builder 的设计前提是”从零构建”。在已有项目上新增模块，它的上下文理解有限：

• SOLO Builder 输出：可能不符合现有代码风格
• 建议：这种情况用 SOLO Coder 而不是 SOLO Builder

4. 认证和权限系统

问题：用户注册、登录、角色权限——SOLO Builder 能做，但安全细节容易遗漏：

• SOLO Builder 输出：基本登入登出没问题，但细粒度权限（如”普通用户只能编辑自己的内容”）可能需要手动补充
• 建议：用它搭认证框架，安全策略自行 review

5. 非 Web 项目

问题：SOLO Builder 目前主要针对 Web 前端/全栈项目。CLI 工具、桌面应用、移动端原生项目：

• SOLO Builder 输出：质量明显下降
• 建议：用 Chat 或 SOLO Coder 逐步引导

诊断清单

用 SOLO Builder 前问自己三个问题：

• 这是我的项目核心业务逻辑吗？→ 是的话，手写或逐行 review
• 对代码质量的要求是什么？→ 生产级还是”能跑就行”？生产级需额外 review
• 如果我不得不修改 AI 输出，修改量会不会超过自己写的量？→ 会的话，别用

10 和基础 Builder 的协同策略

SOLO Builder 和基础 Builder 不是替代关系，而是互补。一个成熟的 Trae 用户在不同阶段切换使用：

1. 想法阶段 → 基础 Builder 5 分钟搭原型（试想法可行性）
2. 原型 OK → SOLO Builder 重建项目（带 PRD 和 Todo Pipeline）
3. 模块开发 → SOLO Builder 逐模块添加（每个模块一个 Todo Pipeline）
4. 细化调整 → 基础 Builder 局部修改（不再需要 PRD 和架构设计）
5. 最终 review → Chat 模式逐文件检查

高阶用法：先用基础 Builder 跑一个最小原型验证需求，确认方向正确后，让 SOLO Builder “重写”同一项目——它不会覆盖你的思考，而是从 PRD 开始重构出一个更健壮的版本。

11 小结

记住一条铁律：SOLO Builder 是帮你加速执行的工具，不是帮你做决策的工具。PRD 你审、架构你定、代码你 review——AI 负责跑腿，你负责把关。

使用心态：把它当成一个全栈工程师实习生。活干得快，但你可能要改他的设计评审文档——而改文档总比自己从零写代码快。

下一篇：10 Trae 部署实战 —— 从 Vercel 到 Supabase，Trae 两键部署的真正用法和避坑指南。