1. 摘要
我用 TRAE SOLO 从 0 到 1 实现了一个 AI 驱动的思维导图视频生成平台——用户只要输入一句主题，平台就会自动拆解成结构化大纲，在分镜内容确认/调整后，一键生成带动画的知识视频。整个产品从 PRD、产品需求文档、技术架构文档，到 UI、前端、后端都由 SOLO 协同产出，实际开发耗时从我预估的 1-2 周压到了 2 天。
体验网站：https://mindmap.vuseai.com/
2. 背景
我是一名全栈开发，平时一个人 hold 住前端 + 后端 + 部署的全链路。这种"一个人即一个团队"的模式有两个长期痛点：
-
上下文切换成本极高：一会儿写界面，一会儿写接口，一会儿调样式，节奏一断思路就散；
-
样板劳动太重：PRD、目录结构、设计规范、CRUD 接口、环境变量分离这些"前置工作"，没做完根本进不了正题，常常导致一个想法卡在第 0 步。
我希望 SOLO 能成为"另一个我"，把跨栈的脚手架和样板一次性铺好，让我专注在业务流和体验决策上。
3. 实践过程
3.1 我是怎么拆解任务的
我把项目拆成五条主线，按依赖顺序串起来交给 SOLO：
-
产品定义（三层文档）
- 第一层：我先和 SOLO 一起写一份高层 PRD，定下产品定位、目标用户、核心链路；
-
第二层：让 SOLO 基于 PRD 进一步细化出"产品需求文档"，把每个页面的模块、字段、交互细节落到能直接对应组件的颗粒度；
-
第三层：让 SOLO 再基于上面两份文档输出"技术架构文档"，包括架构图、技术选型、路由定义、数据模型、接口契约；
这三份文档之后是后续所有产出的"唯一事实源"，每次写代码前都让 SOLO 引用对应章节。
-
设计语言：定下主色、字体、动效，让 UI 风格一次性收敛；
-
前端骨架：路由、状态管理、API 客户端、UI 基础组件；
-
业务页面：首页、工作台、大纲编辑、视频配置、进度跟踪、预览导出共 7 个页面；
-
后端服务：FastAPI + 模块化接口 + 大纲生成的 mock 实现。
每一条主线交付完才进下一条，避免来回返工。
3.2 用了 SOLO 哪些能力
-
多文档分层细化：从一句话产品定位 → PRD → 产品需求文档 → 技术架构文档，让 SOLO 像产品 + 架构师一样逐层"放大"，越往下越接近代码颗粒度；
-
以文档驱动代码：写代码时不再描述需求，而是直接引用文档章节号，SOLO 的幻觉率显著下降；
-
多文件协同修改：环境变量、代理转发、API 配置等跨文件改动一次性贯通，不用我自己来回切；
-
设计令牌驱动 UI：定好色板和动效之后，SOLO 在所有页面里都自觉沿用，UI 一致性几乎不用我手动收敛；
-
跨栈类型对齐：让它先在前端写好类型，再到后端镜像出对应模型，前后端字段命名一次性对齐;
-
Lint / 类型自修复闭环：写完后让 SOLO 自己跑检查、自己改红线，我只看最终绿灯后的结果。
3.3 关键操作思路
-
文档先行，分层细化：先把"是什么 → 长什么样 → 怎么实现"三层文档全部写齐，再开始写代码；
-
令牌先行：先把 UI 规范定死再写页面，比"每次都描述风格"高效十倍；
-
类型先行：让 SOLO 先把数据结构写清楚，再生成接口和页面，全栈联调时几乎不用扯皮字段名；
-
小步交付：每完成一段功能就 review + 跑检查，不让问题堆到最后。
3.4 踩过的坑
-
环境变量没分离：最早开发和生产共用同一份配置，浏览器一直发 CORS 预检。后来明确"开发走代理、生产走真实域名"，问题立即消失。
-
状态持久化的引用陷阱：把响应式数据直接塞进本地存储后，刷新就丢了响应性。SOLO 的修法是先做一次结构化快照再写入，干净利落。
-
命名风格漂移：SOLO 一会儿叫 BaseButton、一会儿叫 UIButton。我在文档里把命名规范写死，一致性就稳住了。
4. 成果展示
-
产品形态：一个完整的 Web 应用，包含首页、工作台、大纲编辑、视频配置、进度跟踪、预览导出、个人中心 7 个页面，桌面端完整体验；
-
核心链路：输入主题 → AI 拆解大纲 → 思维导图编辑 → 配置声线/BGM/主题 → 提交渲染 → 实时进度 → 预览导出；
-
三份核心文档（全部由 SOLO 协同产出）：
-
docs/prd.md：高层 PRD，定义产品定位与主流程； -
.trae/documents/产品需求文档.md：基于 PRD 细化的页面 / 模块 / 交互级需求； -
.trae/documents/技术架构文档.md：基于上面两份文档输出的架构图、技术选型、路由、数据模型与接口契约。
-
-
体验网站 ： https://mindmap.vuseai.com/
5. 效果与总结
5.1 提效到底有多少
| 维度 | 没用 SOLO 的预估 | 用 SOLO 实际 | 提效 |
|---|---|---|---|
| 三份文档（PRD + 需求 + 架构） | 2-3 天 | 2小时 | ~80% |
| 设计规范 + UI 令牌 | 1 天 | 2 小时 | ~75% |
| 前端骨架 + 7 个页面 | 5-6 天 | 2小时 | ~65% |
| 后端服务 + 接口 | 2-3 天 | 半天 | ~80% |
| 联调与收尾 | 1-2 天 | 半天 | ~60% |
| 整体 | 1-2 周 | 2天 | ~70% |
5.2 SOLO 在我流程里到底做了什么
作为全栈，我最怕的就是"上下文切换税"。SOLO 给我的最大改变是：它替我承担了大部分跨栈的样板劳动，让我能始终保留在"业务决策者"这一层。
-
它做：写 PRD、细化需求文档、写技术架构、立设计规范、跨栈对齐字段、写样板代码、改 lint、写文档；
-
我做：定方向、拍体验、做取舍、review 每一次产出——尤其是涉及"用户感受"和"业务边界"的部分，仍然必须由我决策。
5.3 可复用的方法论
-
三层文档驱动：先写 PRD，再让 AI 基于 PRD 细化出"产品需求文档"，再细化出"技术架构文档"——三份文档落地后，写代码就只剩"翻译"工作；
-
规范先行：UI 令牌、命名风格、目录结构在第一阶段就定死，后面省心十倍；
-
类型先行：数据结构是前后端的合同，AI 协作时尤其需要这份合同；
-
mock 优先：把外部依赖暂时屏蔽掉，让主链路先跑通，再逐个换成真实实现；
-
小步红绿闭环：把检查和修复交给 SOLO 自己收敛，人只看最终结果。
最直观的感受是：SOLO 让"一个全栈独立做完整产品"这件事第一次在我手上变成了真的可以交付的工程，而不是 demo。
