28 · 工作流模式
掌握 Trae 的四种工作流模式，从单打独斗到团队协作，找到最适合你的 AI 编码节奏。
01 · 为什么需要工作流模式？
使用 Trae 开发项目，很多人的第一反应是：打开聊天窗口，把需求一股脑倒给 AI，然后等结果。这种做法在小脚本上或许能行，但一旦进入真实项目——几十个文件、多轮迭代、团队协作——很快就会陷入混乱。
工作流模式（Workflow Patterns）是我们在大量实践后总结出的可复用的开发节奏。它回答三个核心问题：
- 什么时候该用 Chat（对话）？什么时候该用 Builder（构建）？什么时候该交给 SOLO（独立执行单元）？
- 如何在探索速度和代码质量之间取得平衡？
- 多人协作时，AI 生成的代码如何进入正式的交付流程？
本文不是枯燥的理论。我们会给出四种已被验证的模式，每种都附带实战场景、优缺点分析，以及你可以立即套用的模板。
02 · 三大基础单元：Chat / Builder / SOLO
在进入模式之前，先明确三个基础单元的能力边界。
| 维度 | Chat | Builder | SOLO |
|---|---|---|---|
| 典型场景 | 需求讨论、方案设计、代码审查 | 根据需求文档生成完整模块 | 执行精确的编码任务 |
| 上下文窗口 | 大 — 可回溯整轮对话历史 | 大 — 基于 PRD / 设计稿 | 小 — 聚焦单一文件或功能 |
| 输出控制 | 中 — 受对话引导影响 | 高 — 遵循结构化输入 | 极高 — 精确执行指令 |
| 适合阶段 | 规划 / 探索 / 审查 | 从 0 到 1 的脚手架搭建 | 生产级的精细编码 |
| 质量保障 | 人工判断为主 | 需要全面 review | 内置自我验证 |
一句话总结：Chat 用于”想清楚”，Builder 用于”搭起来”，SOLO 用于”写好它”。
03 · 模式一：Chat → Builder → SOLO 升级模式
这是最基础、也是最常用的一种递进式工作流。它的核心思想是：同一个需求，依次经过三个层级的处理，逐级收敛。
流程
需求（模糊）→ [Chat 讨论] → 方案（清晰）→ [Builder 搭建] → 骨架（完成）→ [SOLO 精修] → 代码（生产级）实战案例
假设你要开发一个「用户订单管理页面」：
Step 1 — Chat 阶段（10 分钟）
在 Chat 中抛出问题：“我要做一个订单管理页面，包含列表展示、筛选搜索、状态变更、导出功能。你觉得技术方案该怎么选？”
Chat 会与你讨论技术选型、接口设计、组件拆分。你可以在对话中快速迭代方案，直到双方对架构达成一致。
Step 2 — Builder 阶段（1 次生成）
将 Chat 确认的 PRD（产品需求文档）或设计稿输入 Builder。Builder 会一次性生成整个模块的代码骨架：路由、页面组件、API 层、类型定义。
此时的代码功能可用，但可能在细节上不够严谨——缺少边界处理、Loading 状态、错误提示等。
Step 3 — SOLO 阶段（逐文件优化）
把 Builder 生成的每个文件逐一带入 SOLO 窗口，下达精确指令：
- “给这个组件补充加载态和空态展示”
- “为这个 API 调用增加错误重试逻辑”
- “按照项目的 ESLint 规则修正代码风格”
SOLO 会精确执行，不偏题、不啰唆。
适用场景
- 不熟悉的技术栈或新项目启动
- 需求明确但实现路径有多个选项
- 需要从零搭建完整功能模块
避坑指南
不要跨过 Chat 直接让 Builder 开工。Builder 生成的代码量很大，如果方向不对，返工成本极高。先花 10 分钟在 Chat 中想清楚，能省下后面几小时的改代码时间。
04 · 模式二：快速原型工作流（Builder → 预览 → 迭代 → 导出）
这个模式专攻前端 UI / 交互原型场景。目标是：用最短时间让可交互的原型跑起来。
流程
设计稿/描述 → [Builder 生成] → [实时预览] → [Chat 反馈调整] → [迭代 N 轮] → [导出代码]实战案例
你要做一个数据仪表盘页面：
- Builder 生成：把 FIgma 设计稿或文字描述扔进 Builder，得到完整的页面代码（HTML + CSS + 基础交互）。
- 实时预览：在 Trae 内置浏览器中查看效果，检查布局、颜色、间距是否与设计一致。
- Chat 反馈调整：截图发给 Chat，告诉它”图表区域的间距太空了，左侧导航栏的选中态改成高亮蓝色”。
- 重复迭代：每轮 Chat 调整后立即预览，直到满意。
- 导出：将最终代码提交到 Git 仓库，或复制到正式项目中。
关键技巧
- 截图反馈优于文字描述：在预览中发现问题时，直接截图（或使用 Trae 的截图功能）发给 Chat，AI 能更准确地理解问题位置。
- 一次只改一个问题：不要在一条消息里说”改间距、换颜色、加动效”，逐条提，逐条验证，避免 AI 遗漏。
- 锁定已通过的部分：告诉 AI”导航栏这块已经 OK 了，不要动它”，防止迭代过程中回归。
适用场景
- Landing Page 快速搭建
- Dashboard / 后台管理界面原型
- 移动端 H5 页面快速实现
- 设计稿还原度验证
05 · 模式三：生产级开发工作流（SOLO → 审查 → 提交）
当你从原型阶段进入真正的产品开发，需要的不是速度，而是可靠性。这个模式把 SOLO 当作最小交付单元，每个单元都经过审查后再合并。
流程
任务分解 → [SOLO 执行] → [Code Review] → [修改确认] → [提交合并]实战案例
实现”用户注册表单校验逻辑”：
- 任务分解：将需求拆成多个 SOLO 任务——“实现邮箱格式校验”、“实现密码强度校验”、“实现表单整体提交前的集中校验”。
- SOLO 执行：每个任务用一个 SOLO 实例。在 SOLO 中给出精确的函数签名、输入输出约定、已有工具函数列表。SOLO 会生成符合约定的代码。
- Code Review：审查 SOLO 输出的代码——边界条件是否覆盖？错误信息是否友好？是否有硬编码值？
- 修改确认：如果发现问题，在 SOLO 中修正（或者返回 Chat 讨论方案调整）。
- 提交合并：确认无误后，提交到 Git，PR 走常规 review 流程。
质量门禁清单
Review SOLO 输出时，建议逐项检查：
- 所有边界条件有处理（空值、超长、特殊字符）
- 错误信息对用户友好（非技术术语）
- 无硬编码值（Magic Number / String）
- 遵循项目已有的代码风格
- 单元测试覆盖核心路径
- 无安全漏洞（XSS / SQL 注入等）
- 日志输出规范，方便排查
适用场景
- 核心业务逻辑开发
- 支付 / 权限 / 数据操作等高可靠性要求的模块
- 多人协作的大型项目
- 需要严格代码规范的团队
为什么不跳过 Review？
SOLO 生成的代码质量很高，但仍然可能存在”它以为它理解了但你其实想要的是别的”的情况。SOLO 擅长的是精确执行，不是理解隐含的业务上下文。 上下文的理解是你需要在 Review 中把关的。
06 · 模式四：混合协作模式（Chat 规划 + SOLO 执行 + 人工关键路径）
这是面向复杂项目的高级模式。它把三种力量组合在一起：AI 的广度、AI 的精度、人的判断力。
心智模型：指挥官 - 士兵 - 将军
Chat = 指挥官（制定策略、分配任务、协调全局）
SOLO = 士兵（精确执行具体战斗任务）
你 = 将军（拍板关键决策、把握最终方向）流程
实战案例：开发一个 SaaS 后台系统
阶段一：Chat 规划（30 分钟）
在 Chat 中完成全局规划：
- 列出所有页面和路由
- 定义数据模型和 API 接口契约
- 确定组件树和状态管理方案
- 产出完整的 Task List
阶段二：任务分配（10 分钟）
将 Task List 中的每个任务标记为：
- 🔵 SOLO 可执行（纯编码任务）—— 约 70%
- 🟡 Chat 辅助（需要讨论的方案型任务）—— 约 20%
- 🔴 人工执行（关键路径或高风险决策）—— 约 10%
阶段三：并行执行
多个 SOLO 实例可以并行工作。你在后台跑 SOLO 处理数据层代码的同时，另一个 SOLO 可能正在生成前端组件。
阶段四：人工整合
所有 SOLO 输出的代码汇合后，你需要集中做三件事：
- 集成测试，确保各模块能正常协作
- 关键路径审查（支付流程、权限校验等）
- 代码风格一致性修正
如何划分”关键路径”？
| 类别 | 示例 | 交给？ |
|---|---|---|
| 纯 CRUD 代码 | 列表展示、表单提交 | SOLO |
| 有明确规范的模式 | 封装 API 请求、类型定义 | SOLO |
| 需要业务判断的逻辑 | 优惠计算规则、审核流程状态机 | Chat + 人工 |
| 安全敏感代码 | 认证、授权、加密 | 人工主导 |
| 性能关键路径 | SQL 优化、缓存策略 | 人工审查 |
| 团队约定事项 | 代码风格、文件命名 | Chat 规则 + SOLO 执行 |
07 · 四种模式横向对比
| 维度 | 升级模式 | 原型模式 | 生产模式 | 混合模式 |
|---|---|---|---|---|
| 核心目标 | 逐级收敛质量 | 快速可视化 | 交付可靠代码 | 大型项目协作 |
| 速度 | 中 | 快 | 中慢 | 中 |
| 质量 | 高 | 中 | 极高 | 高 |
| 适用团队 | 个人 / 小团队 | 个人 | 小团队 | 中大型团队 |
| 学习曲线 | 低 | 低 | 中 | 高 |
| AI 使用率 | 高 | 中高 | 中 | 高（多个 SOLO 并行） |
| 人工介入点 | 方案决策、Review | 方向把控 | 全面 Review | 关键路径 + 集成 |
08 · 最常见的 5 个工作流错误
错误一：只有 Chat 没有输出
表现：和 AI 聊了几十轮，方案讨论得很热烈，但一行代码都没生成。
诊断：Chat 是讨论工具，不是交付工具。当方案明确后，应当立即切换到 Builder 或 SOLO。
解法：设一个时间盒——Chat 讨论不超过 15 分钟，到时间必须出方案或代码。
错误二：Builder 输出不 Review 直接上线
表现：Builder 生成了整个模块，跑起来看着正常，就直接合并上线了。
后果：线上出现只在特定条件下才触发的 bug，如空数组导致页面白屏、权限不足时不显示友好的 403 页面。
解法：Builder 输出的代码必须走 SOLO + Review 流程，至少检查边界条件。
错误三：SOLO 上下文过载
表现：在 SOLO 窗口里塞入”实现整个用户系统”，期望它一步到位。
后果：SOLO 窗口小上下文处理的劣势暴露——输出质量显著下降。
解法：SOLO 任务应该是原子化的：一个 SOLO 只做一个函数、一个组件、一个 hook。
错误四：忽略人工关键路径
表现：在混合模式中把所有任务都扔给 AI。
后果：安全漏洞、业务逻辑偏差、违反团队编码约定。
解法：严格执行”关键路径标记法”——明确哪些任务必须人工完成或人工审查。
错误五：迭代中不锁定已完成部分
表现：在原型模式中说”整体还不错，但帮我改一下图表区域”，AI 改完图表区的同时把导航栏也改坏了。
后果：已通过的部分出现回归，需要重新检查和修复。
解法：提需求时带上约束条件——“仅修改图表区域的样式，不要动任何其他部分”。
09 · 效率提升技巧
1. 建立项目级 Prompt 库
把常用的指令写成模板，随取随用：
SOLO 任务模板 (新增 API 接口):
目标: [填写]
请求方法: [GET/POST/PUT/DELETE]
请求参数: [填写类型]
返回数据: [填写类型]
注意事项: [填写]2. 为 SOLO 准备上下文文件
在项目中维护一个 CONTEXT.md，内容包含：
- 项目技术栈说明
- 代码风格约定
- 已有的工具函数列表
- 常用的设计模式
每次开 SOLO 之前，先把这个文件贴进去。这会显著提升 SOLO 输出的质量。
3. 给 Builder 喂结构化输入
Builder 的输入越结构化，输出质量越高。推荐格式：
## 需求概述
[一句话说明]
## 功能列表
- [功能 1]
- [功能 2]
## 技术约束
- 框架: React 18 + TypeScript
- 样式方案: TailwindCSS
- API 风格: RESTful
- 路由方案: React Router v6
## 设计稿
[截图或链接]4. 使用 Task List 驱动工作流
在混合模式中，先把所有任务写入一个 Task List（可以是 Markdown 清单或项目管理工具）。每完成一个 SOLO 任务就打个勾。这能让你：
- 清晰看到整体进度
- 避免遗漏任务
- 方便并行调度
10 · 选择工作流模式的决策树
需求来了
│
├─ 是全新项目 / 模块？
│ ├─ 是 → 使用升级模式（Chat → Builder → SOLO）
│ └─ 否 → 继续看
│
├─ 是前端 UI / 交互原型？
│ ├─ 是 → 使用原型模式（Builder → 预览 → 迭代）
│ └─ 否 → 继续看
│
├─ 是生产环境的核心逻辑？
│ ├─ 是 → 使用生产模式（SOLO → Review → 提交）
│ └─ 否 → 继续看
│
├─ 项目复杂、模块多、多人参与？
│ ├─ 是 → 使用混合模式
│ └─ 否 → 回到开头重新判断11 · 总结
工作流模式的核心不在于用了多少 AI 能力，而在于在正确的时机用正确的工具。
- Chat 是你的思考伙伴——用它来澄清需求、设计方案、审查代码
- Builder 是你的脚手架搭建机——用它来快速生成模块骨架
- SOLO 是你的精确编码手——用它来交付生产级的代码片段
- 你——永远是最终的决策者
从最简单的升级模式开始练习，逐步尝试混合模式。不需要一次性掌握所有模式——挑一个能解决当下痛点的，用起来，然后迭代。
下一篇：29 · 大型项目实战：从零搭建一个完整 SaaS 系统
本文是 Trae 工作流系列的第 28 篇。
上一篇：27 · AI 辅助代码审查最佳实践
下一篇：29 · 大型项目实战：从零搭建一个完整 SaaS 系统