写在前面
最近用TRAE的Solo模式做了个AI写真小程序项目，从零到一走了一遍。项目用Taro + React做前端，NestJS + MongoDB做后端，整体完成度大概60%。
这篇文章主要聊聊Solo模式的实际表现，哪些地方省时间，哪些地方还是得自己来。
一、项目概述
1.1 项目背景
这个项目是个AI写真小程序，主要做节日主题（圣诞/跨年）的写真生成。需要同时支持微信和抖音两个平台，功能包括用户登录、图片上传、AI预检、风格选择、付费解锁、AI生成、结果展示这些核心流程。
1.2 技术栈选型
技术选型是在Solo模式下做的，体验不错。描述了项目需求（小程序、跨平台、AI生成等），Solo模式推荐了技术栈并给出理由。比如为什么选Taro而不是uni-app，为什么选NestJS而不是Express，解释比较合理。
最终选定的技术栈：前端用Taro 4.1.9 + React 18.0.0，后端用NestJS 10.0.0 + MongoDB 7.6.3，AI服务用Google Generative AI 0.24.1。这个阶段省了不少调研时间。
1.3 项目完成情况
重新评估了一下，项目完成度确实没有之前估计的那么高。前端大概50%，后端70%左右：
前端完成度：50%
| 模块 | 完成度 | 说明 |
|---|---|---|
| 基础架构 | 100% | Taro框架搭建完成，项目结构清晰 |
| UI组件库 | 70% | MobileLayout、Header、Button等核心组件已实现，但样式与设计规范差距大 |
| 页面实现 | 60% | 主要页面（首页、登录、上传、风格选择、结果页）已实现，但部分功能使用模拟数据 |
| API集成 | 50% | 基础API调用已实现，但很多接口未完全对接 |
| 样式设计 | 40% | UI样式基本实现，但视觉效果与设计规范存在较大差距，需要大量手动调整 |
| 错误处理 | 40% | 基础错误处理已实现，但缺少全局错误处理机制和超时控制 |
主要未完成项：
- 部分页面（如支付页、用户中心）功能不完整
- 结果页使用模拟数据生成，未完全对接后端API
- 缺少全局错误处理和请求超时控制
- UI视觉效果与设计规范存在较大差距，需要大量手动调整
后端完成度：70%
| 模块 | 完成度 | 说明 |
|---|---|---|
| 基础架构 | 100% | NestJS框架搭建完成，模块化设计清晰 |
| 认证模块 | 85% | 微信/抖音登录已实现，JWT认证机制完善，但可能未完全测试 |
| 用户模块 | 80% | 用户管理、VIP系统、购买历史等功能已实现，但可能未完全测试 |
| 图片模块 | 70% | 图片上传、存储、审核功能已实现，但使用本地存储，未集成云存储 |
| AI模块 | 80% | Gemini API集成完成，支持图片预检、生成、文案推荐，但可能未完全测试 |
| 生成模块 | 60% | 任务管理、状态跟踪已实现，但缺少任务队列和重试机制 |
| 订单模块 | 70% | 订单创建、状态管理、支付回调处理已实现，但可能未完全测试 |
| 支付模块 | 50% | 微信/抖音支付框架已搭建，但可能未完全测试和验证 |
主要未完成项：
- 云存储集成（腾讯云COS）未完成，目前使用本地存储
- 支付功能可能未完全测试和验证
- 缺少任务队列和异步处理机制
- 缺少完整的错误日志和监控系统
- 很多模块虽然代码写好了，但可能未完全测试
二、Solo模式实战体验
2.0 技术选型阶段
项目最开始在Solo模式下做技术选型，体验不错。描述了需求，Solo模式推荐了技术栈并给出理由，省了不少调研时间。
2.1 架构设计阶段
技术选型确定后，在Solo模式下生成架构设计文档。根据技术栈自动生成目录结构、组件化方案、状态管理这些基础架构。
架构设计从2-3天缩短到1小时内，生成的目录结构符合Taro规范，WXSS兼容性问题也能自动处理。不过架构设计比较通用，还是得根据项目实际情况调整。
2.2 编码实现阶段
编码阶段用得最多，体验有点两极分化。
做得好的地方：
- 看AI写代码：开启自动跟随模式后，描述需求，AI开始写代码，可以看着它一行行生成。有时候会想"原来可以这样写"，能学到一些新写法
- 组件代码生成：用自然语言描述需求，很快就能生成符合Taro规范的代码，省时间
最大的痛点：UI规范理解能力不足
虽然能读取UI规范文档，但即使给了设计规范，也无法根据规范生成对应的组件。
我试过给它UI规范文档，生成的组件样式和规范差距很大。色彩、间距、字体这些细节都需要手动调整，布局也不够精确。代码语法没问题，但视觉效果完全不符合设计规范。
结果就是代码生成速度快，但UI实现阶段反而要花更多时间手动调整，有点欲速则不达。
开发效率对比：
| 开发阶段 | 传统开发 | Solo模式 | 效率提升 |
|---|---|---|---|
| 组件设计 | 30分钟 | 5分钟 | 6倍 |
| 样式实现 | 20分钟 | 15分钟 | 1.3倍 |
| UI规范调整 | 0分钟 | 25分钟 | - |
| 兼容性处理 | 15分钟 | 自动 | 100%节省 |
| 代码调试 | 25分钟 | 10分钟 | 2.5倍 |
| 总计 | 90分钟 | 55分钟 | 1.6倍 |
代码生成速度快，重复工作减少，平台兼容性自动处理。但最大问题是即使给了UI规范文档，也无法根据规范生成对应组件，需要大量手动调整。复杂组件和动画效果还是得自己来。
2.3 测试优化阶段
测试阶段主要做代码质量检查，还算实用。会自动检测不兼容的CSS特性，比如把border: 'none'改成borderWidth: 0以符合WXSS规范，能省不少调试时间。不过优化建议比较通用，缺乏针对性。
三、开发中遇到的坑
AI写代码很快，审核代码却需要时间；尤其是在项目跑不起来，重复报错，重复循环，让人很崩溃。最后还是不得不自己查文档，改错误。
四、给Solo模式的建议
基于实际开发体验，提几个建议：
执行流程稳定性：API请求缺少超时机制，有时候会卡死，需要手动终止。建议加10秒超时控制，完善全局错误处理机制。
代码生成质量：代码生成缺乏多轮验证，有时候生成的代码能跑但不够优雅。建议引入语法检查、框架规范检查、功能测试等多轮验证机制。
UI规范理解能力（最重要）：虽然能读取UI规范文档，但无法根据设计规范生成对应的组件。这是最大的痛点。建议增强对UI设计规范的理解能力，能准确解析设计文档中的视觉要求，能根据设计规范生成符合规范的组件代码，而不是只生成语法正确的代码。
上下文理解能力：对业务逻辑理解不够深入，有时候生成的代码语法正确但不符合项目实际需求。建议增强项目上下文理解，支持项目特定的代码模板。
临时文档过多：临时文档让AI在处理业务逻辑上起到帮助，但这个文档大部分没有用处，而且会越来越多，增加了阅读的负担。建议完成任务之后自动删除临时文档，没必要占用太多空间，增加心智负担。
五、结论与展望
5.1 总体评价
Solo模式在技术选型和代码生成速度方面表现不错，自动跟随模式和看AI写代码的体验很有意思。但在UI实现上是个短板，虽然能读取UI规范文档，但无法根据设计规范生成对应的组件，需要大量手动调整，拉低了整体效率。
评分：72/100
- 开发效率提升：85分（UI实现需要大量手动调整，但代码生成快）
- 自动跟随模式：90分（看AI写代码很有意思）
- 上下文理解能力：75分
- 代码质量：70分
- UI规范理解能力：50分（即使提供规范文档，也无法生成对应组件）
- 易用性：85分
- 功能完整性：70分
5.2 项目完成情况
前端50%：基础架构和核心组件完成，主要页面和业务流程基本实现，但部分功能用模拟数据，UI样式与设计规范差距大，错误处理和性能优化需完善。
后端70%：核心业务模块实现，AI服务集成和认证系统基本完成，但云存储集成未完成，支付功能需进一步测试，很多模块代码写好了但可能未完全测试。
总体完成度约60%。
5.3 给开发者的建议
Solo模式是辅助，不是替代。核心技术还是要掌握，不要过度依赖。
技术选型阶段体验不错，能快速给出合理的技术栈建议。自动跟随模式值得试试，看AI写代码的过程能学到不少东西。
UI实现要人工介入，即使给了设计规范，Solo模式也无法根据规范生成组件，需要大量手动调整，这个要有心理准备。生成的代码语法正确，但视觉效果和用户体验需要人工审查。
六、写在最后
Solo模式能提升开发效率，特别是在技术选型和代码生成方面。自动跟随模式和看AI写代码的体验不错，有时候看着它写代码，会想"原来可以这样写"，能学到一些新东西。
但在UI实现上还有明显短板------即使给了设计规范文档，也无法根据规范生成对应组件，需要大量人工调整。这是最大的痛点。
Solo模式是很好的辅助，但还不能完全替代开发者。特别是在UI实现这种需要精确理解设计意图的场景，人工介入还是必须的。
如果你也在考虑用Solo模式，建议先试试技术选型和自动跟随模式，看看AI写代码的过程。但UI实现部分，还是要有自己动手的心理准备。