07 · SOLO 模式入门

认识 Trae 的旗舰功能——AI 全自动工程师。你给目标，它给结果，中间过程它自己管理。

01 从”辅助”到”自主”的飞跃

回想一下你之前使用 AI 编程工具的方式：你写一个 prompt，AI 生成一段代码，你复制粘贴，发现问题，再写一个 prompt 修复。这是典型的问答式协作——AI 是助手，你是决策者和执行者。

但如果你能把”写一个用户登录功能”这样的需求直接丢给 AI，让它自己分析项目结构、设计方案、逐行写代码、跑测试、发现 Bug、修复、再测试…直到功能完整交付，最后告诉你”搞定了，你看看”——这就是 SOLO 模式。

Trae 的 SOLO 模式不是简单的”AI 自动补全”或”AI 对话助手”的升级版。它是架构层面的范式转变：

用一个比喻来理解差异：Chat 模式像是你雇了一个实习生，你说一句他做一步；Builder 模式像是你雇了一个熟练工，你说清楚要什么，他搭出个框架给你看；SOLO 模式则像是你雇了一个全栈工程师——你告诉他”给项目加上用户登录功能”，他先看完现有代码，出方案，你点头，他干完，然后叫你验收。

02 设计哲学：“你给目标，它给结果”

SOLO 的全称是 The Real AI Engineer 的全自动形态。它的设计理念是六个字：

你给目标，它给结果。

这六个字背后对应了 SOLO 的四个核心设计原则：

原则一：目标导向，而非指令导向

传统编程工具是指令导向的——你告诉 AI “在第 42 行加一个 validate 函数调用”，AI 照做。SOLO 是目标导向的——你说”给注册表单加上密码强度校验”，SOLO 自己决定在哪里加、怎么加、加什么校验规则。

原则二：自规划，自执行

SOLO 不会拿到需求就开写。它会先：

1. 理解项目结构和技术栈
2. 分析需求的影响范围
3. 生成规划文档（PRD + 技术方案）
4. 拆解为可执行的子任务列表
5. 然后开始写代码

这就是”先想清楚再动手”——而不是”边写边想”。

原则三：自检闭环

SOLO 写完代码不会等你来测试。它会：

• 自动运行你项目中的测试套件
• 如果测试失败，读取错误日志
• 定位问题代码
• 生成修复方案
• 修改并重新测试
• 直到测试全部通过

这个过程叫 Self-Check Loop，是 SOLO 区别于其他 AI 编程工具的核心能力。

原则四：人机协作，而非人机替代

SOLO 不是要替代开发者。它的目标是把你从”写代码”的执行者，提升为”审核代码”的决策者。你不需要关心每一行怎么实现，但你必须在关键节点上把关：方案评审、Diff 审核、验收确认。

心智模型：SOLO 像一个独立工作的全栈工程师，你作为技术负责人，每周和他开一次站会对齐方向，每天看他的 PR 做 Code Review。

03 两个子智能体：SOLO Coder vs SOLO Builder

SOLO 模式内部不是”一个 AI 干所有事”。它有两个明确分工的子智能体，分别对应不同的开发场景。

SOLO Builder：从 0 到 1

SOLO Builder 是最早推出的 SOLO 智能体（2025 年 7 月 Beta 版），专为从零创建项目设计。

当你有一个新想法，想”5 分钟内看到它跑起来”——用 SOLO Builder。

SOLO Coder：从 1 到 100

SOLO Coder 是 SOLO 正式版（2025 年 11 月）新增的智能体，面向已有项目的复杂开发。

当你有一个几万行代码的项目，需要”为 API 网关加上限流功能”——用 SOLO Coder。

对比表格

如何选择

你的任务是：
  ├─ 从零开始一个新项目 → SOLO Builder
  ├─ 在现有项目中加功能 → SOLO Coder
  ├─ 重构已有代码       → SOLO Coder（开启 Plan 模式）
  ├─ 快速验证想法       → SOLO Builder
  └─ 复杂系统级开发     → SOLO Coder（多智能体模式）

04 完整工作流：从 PRD 到部署

SOLO 的完整工作流可以分为六个阶段。让我们用一个真实的例子来走一遍。

场景：你有一个 Node.js 项目，想要加上”用户注册和登录功能”。

阶段一：需求输入

在 SOLO 模式下，你只需在输入框写一句话：

“给这个项目加上用户登录和注册功能，使用 JWT 鉴权，用户信息存 SQLite。”

按下回车，工作流启动。

阶段二：自动化 PRD 生成

SOLO 不会立刻写代码。它做的第一件事是生成文档。约 12 秒后，你看到两份文档：

1. 产品需求文档（PRD）：包含用户角色、功能清单、页面模块、用户流程
2. 技术架构文档：技术选型说明、API 路由设计、数据库建表语句、鉴权流程

这是 SOLO 最独特的价值——它不是”写代码的工具”，而是先想清楚再动手。

你可以：

• 在对话框中提出修改：“改成邮箱+密码登录，不要用户名”
• 点击”查看变更”查看 Diff
• 也可以直接编辑文档内容
• 确认无误后，点击”确认，开始开发”

阶段三：Todo Pipeline 自动拆解

PRD 确认后，SOLO 将整个需求拆解为一个可执行的 Todo Pipeline：

□ 1/8  创建 users 表（SQLite）
□ 2/8  实现注册 API（/api/auth/register）
□ 3/8  实现登录 API（/api/auth/login）
□ 4/8  实现 JWT 中间件
□ 5/8  创建登录页面
□ 6/8  创建注册页面
□ 7/8  添加路由保护
□ 8/8  编写测试用例

每个 Todo 项都对应一个具体的交付物。SOLO 按顺序逐项执行，每完成一项就自动勾选，并展示变更的代码 Diff。

阶段四：自检 — 修复闭环

这是 SOLO 最让人放心的能力。假设 SOLO 写完了第 1 步到第 4 步，自动运行测试：

测试失败：JWT 签名报错 "secret must be provided"

→ SOLO 读取错误日志
→ 定位到 auth.js 第 23 行缺少 JWT_SECRET 环境变量
→ 修改代码：添加默认 secret 配置
→ 重新运行测试
→ 测试通过 ✅

整个过程中，你不需要做任何事。SOLO 自行完成”发现错误 → 定位问题 → 生成修复 → 验证修复”的闭环。

测试全绿后，SOLO 进入下一项任务。

阶段五：进度监控

在 SOLO 执行过程中，左侧任务面板实时展示：

• 整体进度条：从 0% 到 100%
• 当前执行步骤：正在写哪个文件
• 已完成的 Todo 列表：带勾选标记
• 执行日志：每一步的终端输出
• 耗时统计：每项任务花了多久

你可以随时：

• 暂停：让 SOLO 停在当前步骤
• 查看 Diff：检查已修改的文件
• 打断：在对话框中输入”停，这里改一下思路”
• 回滚：撤销某一步的修改

阶段六：一键部署

功能开发完成、测试通过后，SOLO 支持一键部署：

• Vercel：前端 / 全栈 SSR 应用，首次部署约 55 秒
• Supabase：数据库建表、数据迁移、RLS 策略全自动
• Cloudflare Pages：静态站点部署
• 自定义服务器：通过 SSH 部署到自有服务器

整套流程从 PRD 到上线，一个中等复杂度功能，3 小时内可完成全链路交付。

05 Todo Pipeline 的两种规划模式

SOLO 提供了两种规划模式，对应不同复杂度的任务。

Plan 模式（中小型功能）

适合：单个功能模块、中等规模的代码变更

流程：

1. AI 生成一份规划文档
2. 你审阅并编辑
3. 确认后，自动拆解为 Todo Pipeline
4. 逐项执行

Plan 模式的特点是轻量——一份文档 + 一个 Todo 列表，上手快、迭代快。

Spec 模式（复杂系统级任务）

适合：跨多模块的系统级变更、架构重构

流程：

1. AI 生成三阶段文档组：
   • spec.md：总体设计大纲（架构图、模块划分、数据流）
   • tasks.md：细颗粒度的任务分解，带依赖关系
   • checklist.md：验收标准清单，按 P0/P1/P2 优先级分层
2. 所有文档存储在 .trae/specs/ 目录下
3. 你逐份审阅确认
4. 执行阶段按依赖关系顺序推进
5. 测试覆盖 checklist 中的每一项

Spec 模式的文档是可版本化的项目知识资产——以后团队新成员加入，看这些 spec 就能理解当时的架构决策。

06 高阶工作流：6A 方法论

对于更复杂的项目，Trae 社区总结了一套 6A 工作流，可以作为 .trae/rules 配置固化到项目中：

这六个阶段覆盖了从”模糊想法”到”可部署代码”的完整链路。你可以将 6A 流程写入 .trae/rules 中，让 SOLO 每次处理复杂任务时自动套用。

07 使用场景边界：什么时候用，什么时候不用

SOLO 很强大，但它不是万能的。理解它的边界，比学会用它的功能更重要。

推荐使用 SOLO

不建议使用 SOLO

五个实战铁律

铁律一：新项目用 SOLO Builder，老项目用 SOLO Coder
        → 别拿 Builder 改老代码，上下文差异会导致风格不一致

铁律二：大需求先 Plan 再执行
        → 一句话塞 5 个功能，AI 容易丢上下文。拆成子任务分批交付

铁律三：.trae/rules 是定海神针
        → 在项目根目录写好技术栈、代码规范、约束条件，SOLO 会遵守

铁律四：报错直接"添加到对话"
        → 批量推日志比逐行粘贴效率高 10 倍

铁律五：思考次数用尽 = 任务太复杂
        → 将大需求拆成模块，每模块独立执行，减少上下文长度

08 安全边界与人类控制

SOLO 的自主性可能会让人担心：“AI 会不会把项目改坏了？它会不会执行危险命令？”

Trae 为 SOLO 设计了一套多层安全机制。

沙箱隔离

SOLO 执行的所有命令都运行在沙箱环境中：

使用 macOS 的 sandbox-exec（桌面端）或容器（云端）实现进程级隔离。

命令执行策略

你可以在 设置 → Conversation Flow → Auto-Run 中配置命令执行策略和白名单。

人类干预节点

在 SOLO 工作流的每一个关键阶段，你都有机会叫停和纠正：

用户输入需求
    ↓
[审核点] AI 生成 PRD → 你审阅 → 可以修改
    ↓
[审核点] AI 生成 Todo Pipeline → 你审阅
    ↓
[审核点] 每完成一项 Todo → Diff 预览 → 你可以接受/回滚
    ↓
[审核点] 测试结果 → 你查看测试报告
    ↓
[审核点] 部署前 → 最终确认

SOLO 的目标不是”取代人类的判断”，而是把人类从执行层提升到决策层。

什么时候需要手动干预

1. 需求不完整时：SOLO 会假设缺失的部分，如果假设不对，你需要立刻纠正
2. 安全敏感操作时：删除文件、修改配置、连接外部服务——确认后再放行
3. 架构方向偏离时：SOLO 选择了你不同意的技术方案——在 Plan 阶段就叫停
4. 上下文丢失时：长任务中 AI 可能”忘记”了之前的约定——追加约束指令

09 与其他模式的协作策略

SOLO 不是孤立运行的。在真实项目中，它和其他模式配合使用效果最好：

收到一个新需求
    ↓
Chat 模式讨论方案（"用 JWT 还是 Session？SQLite 还是 PostgreSQL？"）
    ↓
方案达成一致
    ↓
如果是全新项目 → SOLO Builder
如果是现有项目加功能 → SOLO Coder（开启 Plan 模式）
    ↓
执行过程中 → 随时 Chat 模式问细节（"这段生成的代码为什么这么写？"）
    ↓
阶段完成 → Chat 模式逐文件 Review
    ↓
微调 → Inline Edit（Cmd+K）做局部修改
    ↓
没问题 → SOLO 跑测试 → 确认全绿 → Commit

关键原则：AI 负责执行和探索，人负责判断和决策。

10 小结

一句话记住 SOLO：它不是一个更聪明的代码补全工具，而是一个能自己规划、自己执行、自己检查、自己修复的 AI 工程师。你的角色从”写代码的人”变成了”审核代码的人”——方向仍然在你手里，但驾驶交给了 AI。

下一篇：08 SOLO 模式进阶 —— 深入学习 Plan 和 Spec 模式的差异，掌握 .trae/rules 配置和 6A 工作流的最佳实践。