34 · 综合实战项目

把前面 33 篇的知识点串联起来——用 Trae 三种模式完整开发一个全栈 SaaS 应用，从零到上线。

01 · 项目概述：我们要做什么

前面 33 篇教程分别介绍了 Trae 的 Chat、Builder、SOLO 三种模式，以及 MCP、部署、工作流等一系列能力。但单独学每个功能是一回事，把它们组合起来打一场完整的仗是另一回事。

本文的目标是：带领你从零开始，用 Trae 的三种模式完整开发一个全栈项目并部署上线。这个过程模拟真实团队的生产流程，但全部由你一个人在 Trae 中完成。

项目选题：智能任务管理器（TaskFlow）

我们选择的项目是一个轻量级团队任务管理 SaaS，名叫 TaskFlow。它包含以下核心功能：

技术栈选型（由 AI 一起参与决策，详见下一节）：

• 前端：Next.js 14 (App Router) + TypeScript + TailwindCSS
• 后端：Supabase (PostgreSQL + Auth + Storage + Realtime)
• 部署：Vercel (前端) + Supabase (后端)
• 状态管理：Zustand（轻量、类型安全）

贯穿全文的心智模型：三层漏斗

┌─────────────────────────────────────────────────┐
│  层 1：战略层（Chat）                            │
│  做什么？为什么做？技术选型？架构设计？           │
├─────────────────────────────────────────────────┤
│  层 2：战术层（Builder）                          │
│  搭骨架生成完整模块 —— 快速出 MVP                │
├─────────────────────────────────────────────────┤
│  层 3：战斗层（SOLO + 人工）                     │
│  精修每个功能 —— 边界处理、测试、性能优化         │
└─────────────────────────────────────────────────┘

这个漏斗的核心思想是：上层决定方向，中层决定结构，下层决定质量。每一层都依赖上一层输出的确定性。

02 · 第 1 阶段：Chat 做战略规划（AI 辅助 PRD）

2.1 为什么第一步是 Chat？

很多初学者拿到项目后，第一步就打开 Builder 说”帮我做一个任务管理器”。这相当于你还没想清楚房子长什么样，就让施工队挖地基——Builder 确实会生成代码，但方向很可能不对，返工成本极高。

Chat 模式的价值：它是一个无损的对话空间。你可以随意提问、质疑、调整方案，AI 不会不耐烦，也不会因为你改主意就推倒重来。

2.2 实操：用 Chat 生成 AI PRD

在 Chat 窗口输入：

“我想做一个团队任务管理 SaaS，面向 5-20 人的小团队，核心功能包括项目管理、任务看板、成员协作。帮我分析技术选型和架构方案，并输出一份结构化的 PRD。”

Chat 的回答会包含：

1. 市场定位分析（谁在用、解决什么问题）
2. 功能清单（MVP 功能 vs 远期功能）
3. 技术选型对比（Next.js vs Remix vs SvelteKit 的优缺点）
4. 数据模型设计（用户、项目、任务、标签等表结构）
5. API 接口设计（RESTful 路由）
6. 页面路由规划（App Router 的目录结构）
7. 安全策略（认证方式、权限模型）

继续追问：

“帮我细化任务表的数据结构，包括状态字段、优先级、标签系统。”

“请给出 RLS 策略的设计方案，确保一个项目的成员只能看到自己项目内的任务。”

通过 3-5 轮对话，你会得到一份非常完整的 PRD。把它保存到项目目录下的 docs/PRD.md。

2.3 Chat 输出 PRD 模板

以下是一个经过实际验证的结构：

# TaskFlow PRD
 
## 1. 产品概述
- 目标用户：5-20 人团队
- 核心痛点：多头沟通、任务追踪混乱
- 解决方案：可视化任务看板 + 实时协作
 
## 2. 功能范围（MVP）
| 模块 | 优先级 | 预估工时 |
|------|--------|----------|
| 用户注册/登录 | P0 | 2 天 |
| 项目创建/管理 | P0 | 1 天 |
| 任务 CRUD | P0 | 2 天 |
| 看板拖拽 | P1 | 2 天 |
| 评论系统 | P1 | 1.5 天 |
| 文件附件 | P2 | 1 天 |
| 仪表盘 | P2 | 2 天 |
 
## 3. 技术架构
- Frontend: Next.js 14 + TailwindCSS + Zustand
- Backend: Supabase (PostgreSQL/Auth/Storage/Realtime)
- Deployment: Vercel + Supabase
 
## 4. 数据模型
[表结构定义...]

2.4 Chat 阶段的”刹车信号”

当你发现 Chat 开始重复回答、或者在细节上转圈时，就该打住了。标志性信号：

经验法则：Chat 阶段不超过整个项目时间的 15%。对于 TaskFlow，规划阶段控制在 30-45 分钟。

03 · 第 2 阶段：Builder 搭建项目骨架

3.1 Builder 的”黄金输入”

规划完成后，将 PRD 喂给 Builder。但是——不要直接把 PRD 全文扔进去。Builder 需要结构化、可执行的指令，而不是散文化的描述。

经过实践检验的 Builder 输入模板：

## 项目类型
全栈 Next.js 14 + Supabase 应用
 
## 技术约束
- 使用 App Router（非 Pages Router）
- 使用 TypeScript，严格模式
- 使用 TailwindCSS，自定义主题色 #6366F1
- 使用 @supabase/supabase-js 客户端库
- 使用 Zustand 做状态管理
- 所有组件使用箭头函数 + 命名导出
 
## 需要生成的功能模块
1. 项目初始化（package.json、next.config、tailwind.config）
2. Supabase 客户端封装（lib/supabase.ts）
3. 登录/注册页面（auth/login 和 auth/register）
4. 项目列表页面（dashboard/projects）
5. 项目详情 + 看板页面（projects/[id]）
6. 任务 CRUD API 层
7. 布局组件（侧边栏、顶栏）
 
## 不需要
- 不要生成 mock 数据
- 不要生成测试文件（将在 SOLO 阶段补充）
- 不要包含部署配置（后续手动处理）

关键差异：Builder 的输入要像”施工图纸”而不是”创意简报”。越精确，输出越可用。

3.2 Builder 输出评估

Builder 运行后，你会得到一个完整的项目目录结构。以下是对 TaskFlow 的真实评估（来自我们的实测）：

结论：Builder 输出了一个可运行但尚未完工的 MVP。70% 的代码可以直接用，30% 需要 SOLO 精修。

3.3 Builder 后的”三件套”检查

Builder 完成后，不要急着改代码。先做三件事：

1. 确认项目能跑起来：npm run dev 无报错
2. 确认页面能渲染：访问所有生成的路由，确保不白屏
3. 确认数据流通顺：检查 API 路由是否能正确连接数据库

如果这三件事中有任何一件不通，说明 Builder 输出有结构性问题——不要往下走，回到 Builder 修复。结构性问题在后续阶段修复的成本是指数级上升的。

04 · 第 3 阶段：SOLO Coder 精修功能

4.1 从 Builder 到 SOLO 的过渡

拿到 Builder 生成的骨架后，你需要做的是：把大任务拆成小任务。每个小任务就是一个 SOLO 任务。

TaskFlow 的任务分解示例：

🏗 Builder 输出（已完成）
├── SOLO Task 01: 登录页加 loading 态和表单校验
├── SOLO Task 02: 注册页加密码强度指示器
├── SOLO Task 03: 实现看板拖拽（@dnd-kit）
├── SOLO Task 04: 任务详情页 Markdown 编辑器
├── SOLO Task 05: 评论组件（实时订阅）
├── SOLO Task 06: 文件上传组件
├── SOLO Task 07: 仪表盘统计图表
├── SOLO Task 08: 补充 RLS 策略
├── SOLO Task 09: 添加错误边界组件
└── SOLO Task 10: 补全 TypeScript 类型

4.2 SOLO 的精髓：精确指令

SOLO 的上下文窗口小，这既是它的劣势也是优势。劣势是不能处理跨文件的复杂任务；优势是不会偏离指令，专注于你要求的事情。

写好 SOLO 指令的公式：

## 目标
[一句话说明要做什么]

## 上下文（关键！）
- 涉及的文件：[具体文件路径]
- 已有工具函数：[已存在的函数名、类型定义]
- 遵循的风格：[项目约定，如"使用命名导出"]

## 输入/输出约定
- 函数签名：[参数类型、返回类型]
- API 端点：[如果涉及，写出 URL 和请求体格式]

## 边界条件
- [ ] 空状态怎么处理
- [ ] 加载过程怎么展示
- [ ] 错误怎么显示
- [ ] 超长内容的截断策略

实战案例——SOLO Task 03 看板拖拽的指令：

“在 app/projects/[id]/kanban/page.tsx 中使用 @dnd-kit/core 和 @dnd-kit/sortable 实现拖拽排序。列包含：‘待处理’、‘进行中’、‘已完成’。拖拽结束后调用 PATCH /api/tasks/[id]/status 更新数据库。现有 Zustand store 路径 store/kanban-store.ts，导出了 useKanbanStore，有 tasks、moveTask、columns 三个属性。边界条件：拖拽中显示半透明占位，拖拽结束前不真正移动数据，网络请求失败时回退到原位置。”

这个指令精确到——SOLO 不会猜你要什么，它直接执行。

4.3 SOLO 产生的 Todo Pipeline

Trae 的 SOLO 模式有一个被低估的功能：在指令中包含阶段性检查点。在每个 SOLO 任务的指令中加入一个 Todo List，SOLO 会按顺序执行并标记进度：

请按以下步骤执行：

Step 1 [完成] 安装 @dnd-kit/core 和 @dnd-kit/sortable
Step 2 [完成] 定义拖拽上下文 Provider
Step 3 [进行中] 实现列内拖拽
Step 4 [待开始] 实现跨列拖拽
Step 5 [待开始] 拖拽结束后发起 API 调用
Step 6 [待开始] 添加失败回滚逻辑

这种 Todo Pipeline 让你能实时看到 SOLO 的执行进度，也方便在某个步骤出问题时及时介入。

4.4 SOLO Coder vs SOLO Builder 的分工

在精修阶段，我们需要区分两种 SOLO 的用法：

一个经验法则：如果任务涉及 3 个以上文件，可以考虑用 SOLO Builder；否则用 SOLO Coder。

05 · 第 4 阶段：人工微调与”自愈循环”

5.1 为什么需要人工介入？

AI 生成的代码在以下方面天生薄弱：

5.2 自愈循环：一种有效的微调节奏

“自愈循环”是我们从实践中沉淀出的一个微调方法论。它本质是一个快速反馈闭环：

[修改] → [预览] → [检查] → [发现问题] → [回到修改]

但它的关键不在于”循环”本身，而在于每次循环的粒度控制。

不好的循环（新手常见）：

✗ "帮我改进一下这个页面" → AI 改了 10 处地方 → 3 处改好了，7 处改坏了 → 花 20 分钟排查

好的循环（自愈循环）：

✓ "看板列标题字体改成 16px Semibold" → 改好 → 预览没问题 → 锁定这处 → 
  "列间距从 12px 改成 16px" → 改好 → 预览没问题 → 锁定这处 →
  "卡片圆角 8px → 12px" → 改好 → 预览没问题 → 锁定

自愈循环的四个原则：

1. 一次一个改动：每次只要求改变一个东西，验证后再做下一个
2. 每次改动可回滚：改之前确保 Git 有干净的提交点，随时可以 git checkout .
3. 锁定已通过部分：在指令末尾加一句”以上改完后，不要改变任何其他部分的代码”
4. 视觉类问题用截图反馈：在预览窗口发现问题时截图，圈出问题区域，发给 Chat

5.3 实战：自愈循环微调看板页面

轮次 1: "把列标题的左内边距从 16px 改为 12px" → 预览 → 通过 ✓
轮次 2: "列标题的图标和文字间距 8px" → 预览 → 通过 ✓
轮次 3: "卡片底部加灰色分割线" → 预览 → 分割线颜色太深 → 
轮次 4: "分割线颜色用 gray-200" → 预览 → 通过 ✓
轮次 5: "拖拽时卡片的阴影加大，用 shadow-xl" → 预览 → 通过 ✓

总共 5 轮对话，每次只看一个变量，花了不到 5 分钟，结果完全可控。

5.4 Git 版本控制：微调的”后悔药”

在自愈循环中，Git 是你的安全网。推荐的操作节奏：

# 阶段开始前
git checkout -b feat/kanban-dnd
 
# 每完成一个 SOLO 任务后
git add .
git commit -m "feat: implement kanban drag-and-drop"
 
# 每完成一次成功的微调后
git add .
git commit -m "style: adjust column spacing"
 
# 如果改坏了，回滚到上一个安全点
git checkout -- .  # 丢弃所有未提交的改动

这个节奏让你可以大胆尝试：改坏了就回滚，没有任何心理负担。

06 · 第 5 阶段：测试（AI 辅助 + 人工验证）

6.1 测试策略：不追求覆盖率，追求信心

对于 AI 辅助开发的项目，一上来就要求 90% 的代码覆盖率既不现实也没必要。更好的测试策略是基于风险的测试（Risk-Based Testing）：

6.2 用 SOLO 生成测试

在 Chat 中先确定测试策略，然后让 SOLO 生成具体的测试代码。

Chat 阶段：

“TaskFlow 的核心用户路径是：注册 → 创建项目 → 添加任务 → 拖拽任务到’进行中’列。帮我设计 E2E 测试用例。”

Chat 输出测试用例清单：

Test Case 01: 用户注册并验证邮箱
Test Case 02: 创建项目并邀请成员
Test Case 03: 在项目中创建任务
Test Case 04: 拖拽任务变更状态
Test Case 05: 在任务下添加评论
Test Case 06: 上传文件附件
Test Case 07: 非项目成员访问项目 403
Test Case 08: 删除项目后相关内容同步删除

SOLO 阶段（以 Test Case 04 为例）：

“使用 Playwright 编写看板拖拽测试。在 tests/e2e/kanban.spec.ts 中：登录已有测试用户 → 打开指定项目看板 → 定位’待处理’列的第一个任务卡片 → 拖拽到’进行中’列 → 验证 API 返回 200 → 验证页面刷新后状态正确。”

SOLO 会生成完整的 Playwright 测试脚本，包含等待、断言、截图对比。你只需要运行 npx playwright test 来执行。

6.3 人工验证清单

AI 生成的测试无法覆盖的是人的直觉判断。上线前，你应该亲自走一遍以下路径：

注册流程：□ 正常注册完成 □ 密码太短提示 □ 邮箱格式校验
登录流程：□ 正常登录 □ 密码错误提示 □ 空表单校验
项目列表：□ 有项目显示 □ 无项目空态 □ 创建项目
看板页面：□ 三列展示 □ 拖拽流畅 □ 状态更新实时
任务详情：□ Markdown 渲染 □ 评论发送 □ 文件上传
权限校验：□ 未登录重定向 □ 非成员 403 □ 管理员可见全部
响应式：□ 桌面端 1440px □ 平板 768px □ 手机 375px

一个建议：每完成一个 SOLO 任务，就立刻做一次人工验证。不要攒到最后一次性做。Bug 发现得越晚，修复成本越高——这个规律在 AI 开发中同样成立。

07 · 第 6 阶段：部署上线（从 Trae 到生产环境）

7.1 部署前的准备检查

在点击”部署”按钮之前，先核对以下内容：

代码准备

• 所有环境变量使用 .env.local 管理，不硬编码
• .env.local 已加入 .gitignore
• npm run build 零报错通过
• npm run dev 完整走一遍核心流程

Supabase 准备

• 所有表已开启 RLS（Row Level Security）
• Auth 提供商已配置（至少邮箱登录）
• Storage bucket 已创建且 policy 正确
• 数据库迁移脚本已整理

7.2 一键部署：Vercel

在 Trae 中，你可以直接在终端操作：

# 1. 安装 Vercel CLI
npm i -g vercel
 
# 2. 登录
vercel login
 
# 3. 部署（第一次会自动创建项目）
vercel
 
# 4. 设置环境变量
vercel env add NEXT_PUBLIC_SUPABASE_URL
vercel env add NEXT_PUBLIC_SUPABASE_ANON_KEY

第一次部署后，Vercel 会返回一个预览 URL（如 taskflow-xxxx.vercel.app）。访问它，确认所有功能正常。

7.3 部署后的验证流程

部署完成不等于上线完成。你应该在生产环境上重新跑一遍核心流程：

1. 打开部署 URL → 确认加载正常无白屏
2. 注册一个新账号 → 确认 Auth 流程走通
3. 创建项目 → 确认数据写入 Supabase
4. 添加任务 → 确认前端展示正常
5. 拖拽任务 → 确认实时同步正常
6. 退出登录 → 确认路由守卫生效
7. 用手机浏览器打开 → 确认响应式布局

7.4 部署模式的对比

对于 TaskFlow 这样的个人/SaaS 项目，Vercel CLI 一键部署是最优选择。

08 · 三种模式的总投入产出分析

让我们回顾一下 TaskFlow 的完整构建过程，统计每种模式的投入时间。

8.1 时间投入明细

总耗时：约 3.5 小时（从零到上线）。

8.2 与传统开发对比

8.3 三种模式的”性价比”曲线

代码质量
  ↑
  │          ● 人工微调（最后 10%）
  │        ↗
  │      ● SOLO 精修（接下来 30%）
  │    ↗
  │  ● Builder 骨架（核心 60%）
  │↗
  │● Chat 规划（确定方向）
  └────────────────────────→ 时间投入

关键洞察：Builder 用最少时间产出最多代码（60%），SOLO 在中等时间内提升质量（30%），人工微调用最少代码改动追求最后 10% 的精致。三者的结合实现了时间投入和质量回报的最优平衡。

09 · 心智模型与核心理念

9.1 指挥官 - 工程师 - 匠人

Chat     = 指挥官（定方向、定策略、定标准）
Builder  = 施工队（快速搭结构、出毛坯）
SOLO     = 精装师（精细处理每个模块）
你       = 业主（验收、决策、微调）

这个模型的核心是：不要让 AI 做它不擅长的事，也不要抢 AI 擅长的事。

• 不要让 Chat 生成大量代码（它有想法但执行效率低）
• 不要让 Builder 做 UI 微调（它一次性改动太多）
• 不要让 SOLO 做架构决策（它的上下文不足以看清全局）
• 不要自己手写 CRUD 代码（Builder 做这些比你快 10 倍）

9.2 自愈循环的深层原理

自愈循环之所以有效，背后有一个认知科学原理：每次只变一个变量，隔离因果链。

当你一次改变 10 个变量（比如”优化这个页面”），AI 的输出结果和你的期望之间会出现不可预知的差距。你很难判断究竟是哪个变量导致了偏差。但当每次只改一个变量时：

1. 因果明确——效果不对，100% 是刚改的这个变量的问题
2. 可回滚——“Ctrl+Z”就能回到上一步
3. 可信赖——每步都验证，最终结果的可预测性大大增加

这就是为什么在微调阶段，慢就是快。

9.3 Todo Pipeline 的隐性价值

很多教程把 Todo Pipeline 简单理解成”任务清单”，但它的深层价值在于状态透明：

这种透明度让你在 SOLO 执行多个步骤时，不再需要一直盯着屏幕等结果。扫一眼状态就知道：一切正常，继续；或者这里卡住了，我来看看。

10 · 完整项目结构参考

以下是 TaskFlow 在完成所有阶段后的最终目录结构：

taskflow/
├── .env.local                  # 本地环境变量（不提交）
├── .gitignore
├── package.json
├── next.config.js
├── tailwind.config.ts
├── tsconfig.json
├── docs/
│   └── PRD.md                  # Chat 阶段产出的需求文档
├── src/
│   ├── app/
│   │   ├── layout.tsx          # 根布局
│   │   ├── page.tsx            # Landing / 重定向
│   │   ├── auth/
│   │   │   ├── login/page.tsx
│   │   │   └── register/page.tsx
│   │   ├── dashboard/
│   │   │   ├── layout.tsx
│   │   │   ├── page.tsx        # 项目列表
│   │   │   └── settings/page.tsx
│   │   └── projects/
│   │       └── [id]/
│   │           ├── page.tsx    # 项目概览
│   │           └── kanban/page.tsx  # 看板（SOLO 精修）
│   ├── components/
│   │   ├── ui/                 # 通用 UI 组件
│   │   ├── kanban/             # 看板组件（拖拽逻辑）
│   │   ├── task/               # 任务相关组件
│   │   └── charts/             # 仪表盘图表
│   ├── lib/
│   │   └── supabase.ts         # Supabase 客户端
│   ├── store/
│   │   └── kanban-store.ts     # 看板状态（Zustand）
│   ├── types/
│   │   └── index.ts            # 类型定义
│   └── middleware.ts           # 路由守卫
├── supabase/
│   └── migrations/             # 数据库迁移脚本
└── tests/
    ├── e2e/                    # Playwright 端到端测试
    └── unit/                   # Vitest 单元测试

11 · 常见问题

Q1：Builder 生成的代码不符合预期怎么办？

第一步：检查你的 Builder 输入是否足够结构化。Builder 对”结构化指令”的响应质量远高于”散文化描述”。第二步：如果输入没问题，回到 Chat 讨论为什么方向不对。Builder 的”理解”基于你的指令——指令有模糊，输出就有偏差。第三步：如果方向正确但执行质量差，交给 SOLO 精修，不要期望 Builder 一次输出生产级代码。

Q2：SOLO 任务应该拆多细？

一个好用标准：如果 SOLO 指令超过 15 行，这个任务可能太大了。拆到每个 SOLO 任务只做一件事——“实现拖拽”和”拖拽后调用 API”最好是两个 SOLO 任务，而不是一个。

Q3：什么时候该从 SOLO Coder 切换到 SOLO Builder？

刚才提到 3 个文件的阈值，但还有一个更直觉的判断方式：当你在写 SOLO 指令时发现需要描述”其他文件已经做了什么”这句话出现 3 次以上，就该切到 SOLO Builder。SOLO Builder 有更大的上下文窗口，更擅长处理跨文件的改动。

Q4：自愈循环中，Chat 和 SOLO 怎么分工？

视觉/UI 类问题 → Chat（因为需要讨论和方案对比）。代码逻辑类问题 → SOLO（因为需要精确修改）。一个例外：如果 UE/UI 问题已经讨论出明确方案（“按钮从圆角改成直角”），直接用 SOLO 执行，不需要再经过 Chat。

Q5：没有 Supabase 经验，如何在 Chat 中快速学习？

Chat 是你的即时老师。直接问：“我是 Supabase 新手，请解释 RLS 策略的工作原理，并给出 TaskFlow 项目所有表的最小权限配置。“Chat 会输出完整教程 + 代码示例。但要记住——Chat 的解释可能有错误。对于涉及安全的配置（RLS、Auth），一定要交叉验证官方文档。

12 · 总结

核心回顾

本文通过 TaskFlow 这个完整的全栈 SaaS 项目，展示了 Trae 三种模式如何协作完成从零到上线的全过程：

三个可以带走的核心理念

1. 三层漏斗——战略 > 战术 > 战斗

• Chat 负责”想清楚”（战略），Builder 负责”搭起来”（战术），SOLO 负责”写好它”（战斗）
• 不要跳过上层直接进入下层，每一层的输出是下一层的输入

2. 自愈循环——慢就是快

• 一次只改一个变量
• 每步验证再继续
• 改之前 Commit，改坏了就回滚

3. Todo Pipeline——状态透明

• 把大任务拆成有状态的步骤
• 每个步骤独立可执行、可验证
• 颜色标记让你一眼看到进度

最后的话

本文用了一个比较复杂的全栈项目作为例子，但核心方法论适用于任何规模的项目——从一个小工具到企业级系统。

关键不在于你用 Builder 生成了多少代码，也不在于你写了多少条 SOLO 指令，而在于你知道什么时候用什么模式。 这是从”会用 Trae”到”用好 Trae”的分水岭。

如果你只记住一句话，那就是：

Chat 想清楚，Builder 搭起来，SOLO 写好它，你把关。 这四件事做好了，一个 AI 时代的全栈开发者就诞生了。

下一篇

35 · Trae vs Cursor 深度对比

从第 01 篇到第 34 篇，我们已经完整覆盖了 Trae 的安装、三种模式、工作流、高级配置和实战项目。接下来，我们将把 Trae 和它的主要竞争对手 Cursor 放在一起做深度的横向对比——技术底座、功能差异、适合场景、成本分析——帮助你在两个工具之间做出最适合自己的选择。

本文是 Trae 系列教程的第 34 篇。
上一篇：29 · 入门实战：从零到上线
下一篇：35 · Trae vs Cursor 深度对比