前言
前面分享《AI编程实战：使用Trae从零开始实现写作助手的后端开发及前后端联调》时，我们采用了 TRAE + IDE 模式实现了写作助手的后端接口，整体还算顺利。
其实，最初我是打算使用 TRAE SOLO 模式搞定的，结果发现不支持，我还在分享中专门提了一下。
昨天看到 TRAE 新的发布会才知道，8月1号分享当天，SOLO 其实已经更新了，更新内容就包括后端生成能力。
我：……
今天，我们就补上当时的缺憾，采用完全相同的代码场景，重新测试一下 TRAE SOLO 的后端生成能力。
项目介绍
老读者都知道，这个“写作助手”是我开发给自己用的一个小项目，整个过程都做了分享。
初衷很简单：
现有的写作工具，要么体验不太符合我的预期，要么 AI 能力太弱，关键是每次写文章都需要在多个工具之间切换使用，太不高效了。
第一版功能比较简单：
实现基本的写作管理（增删改查） 方便输出为公众号、知乎等平台样式 支持自定义 AI 快捷操作（比如一键扩写、改风格）
这次，我们尝试下新升级的 TRAE SOLO + Claude-4，看看有什么提升。
前期工作
为了保证对比公平，我完全复刻了上回的环境。
工程结构还是老样子，拆成两个：
chengzhang-vue：前端工程 chengzhang-rest：后端工程
各自初始化 Git，方便后续看生成差异。
后端功能已经清的干干净净。
实战记录
整个过程都是 TRAE SOLO + Claude-4 完成的，和上次仅仅更换了 TRAE 模式。
初版生成
指令
一个专为自媒体博主设计的写作编辑器，现在前端页面已经完成，请帮我完成后端接口的开发。
后端接口需要使用Spring Boot框架，orm采用hibernate，数据库采用mysql 5.7。
后端代码放置在chengzhang-rest工程中，D:\Project\other\chengzhang2\chengzhang-rest。
除了最后增加了后端工程地址，避免生成位置错误，其它内容和上回是一模一样的。
过程
首先，进行需求的分析设计，并生成相关技术文档。
在你确认文档没问题，并点击“确认开发”后，自动开始代码生成。
整个生成过程分为以下几个阶段：
初始化后端框架 初步生成代码 安装 maven 依赖并修复编译问题 创建“任务列表”详细地检查并完善需求实现 不断编译并修复错误，直至编译成功 启动后端服务，并修复启动过程中的问题 总结任务
下面针对重点过程截图说明。
初始化后端框架
直接通过脚本下载官方脚手架进行项目初始化工作。
初步生成代码
这一步比较整成，根据文档生成各类代码文件。
安装 maven 依赖并修复编译问题
这个过程是自动迭代的，TRAE 修改后会再次编译，并修复新的问题，直至编译成功。
创建任务列表详细的检查并完善需求实现
我执行时，没有从一开始就出发“任务列表”规划，由于使用次数比较少，何时会触发任务列表，目前尚不清楚，感觉像是 AI 自行分析创建的。
任务列表辅助生成的效果如下：
任务1：检查并完善ArticleController的所有API接口实现
任务2：创建ImageController和ImageService实现图片上传管理功能
这个过程中，我发现了一个挺有意思的地方：TRAE 的任务列表在执行过程中是会更新任务顺序的，虽然有些人会感觉不怎么稳定，但我更希望这是一个 TRAE 有意识的自我改进的新特性。
不断编译并修复错误，直至编译已成功
这一步花费了挺久时间，我甚至已经在想，不会看起来过程很高大上，最终给我来个反复修改也无法编译通过的结果吧。
还好都解决了，编译成功。
启动后端服务
通过 maven 命令启动后端服务。
然后就是启动的错误修复，依然不需要干涉，自动迭代修复。
总结任务执行内容
最后都会总结一下，方便我们了解这次任务都做了什么。
结果
整个过程时间花费挺久的，大概在40-50分钟。
但如果回顾上面的过程，这个时间应该还能接受，毕竟，整个过程和我们开发的思路很类似，但快了很多。
包括测试数据都已经构建好了。
后端不好预览效果，我们直接进行前后端联调。
前后端联调
和前次分享不一样的是，生成过程中已经自动集成了自检步骤，我们直接联调即可。
指令
实现前端已有功能与后端java api的对接。
前端工程：D:\Project\other\chengzhang2\chengzhang-vue
后端工程：D:\Project\other\chengzhang2\chengzhang-rest
过程
我第一次尝试是在生成后端代码的对话中执行的上述指令，TRAE 直接进行开发生成，结果不是太好。
后来选择了新开对话。这次，TRAE 先进行了分析，并形成相关技术文档，然后才开始的开发，一次过。
重要过程截图如下：
TRAE 先是了解前后端代码，分析方案。
然后生成前后端对接文档，作为后续代码开发的参考依据。
人工确认开发后，开始分解任务并执行，可以看到确认开发后，上文生成的文档是作为上下文传给 TRAE 的。
按照任务规划执行完成后，TRAE 会自动进行检测，并修复问题，直至运行成功。
结果
整个过程大概花费了 10 几分钟，考虑到前后端了解、接口对接以及各种数据格式转换，时间还可以。
TRAE 自动在内置浏览器中实现预览，简单新增一篇文章测试下。
可以看到，数据也确实落库了。
上面就是本次实测的全过程记录。
由于界面效果和前次分享没有区别，这里就不专门进行最终效果的截图了。
下面和大家聊聊这次更新发布的新特性和直观的使用感受吧。
TRAE IDE vs SOLO
SOLO 新特性速览
先帮大家整理下8月1号发布的内容：
后端生成能力：很直观，也是本次分享核心实测的内容，实现了前后端的闭环。
技术架构文档：在编码过程中，增加了技术架构文档生成步骤，更加规范，也更能保证生成质量。
任务列表：将 AI 的规划能力可视化，方便我们了解开发过程及进度。
Supabase：Baas的一种实现方式，毕竟前端已经可以通过 vercel 一站式部署了，后端也得有个简便的部署方式嘛。
直观感受
以上是官方发布内容，下面谈谈实测后的直观感受。
能够解决的任务复杂度大大提升
首先就是后端生成能力的拓展，不再局限于 Web 开发，更接近一个全栈工程师了。
同时，不像 IDE 模式跑久了容易出现“幻觉”，SOLO 模式的上下文更大、可处理任务的时间也更长，更加适合处理复杂任务场景。
自动化程度更加完善
IDE 模式下，需要手动发起“生成”、“自检”、“修复”过程，并且很多上下文信息需要手动添加进对话。
SOLO 模式，不论是技术文档、任务列表的开发辅助，还是开发、自检、迭代的研发流程，SOLO 需要更少的干预。
并且，目前已经可以很好地完成 java 编译问题、浏览器 console 错误自动获取并修复，大大释放了我们的精力。
更像一个独立的开发者
这一点其实更多的是上面两点的必然结果。
IDE 模式更像是和一个初级程序员配合，我们给出详细的指令，包括各种上下文，它非常尽职地完成任务。
SOLO 模式则更像一个独立的开发者，获取目标后，自行规划、拆解，直至交付。
结语
实测之后，说实话，心里有些感触。
虽然，SOLO 目前还不完美，比如：
任务解决方案的选择有时不够最优，甚至比不上人工选择上下文和指令的效果。 缺陷定位不精准，需要多次尝试后方能解决问题。
但它的进化速度，已经超出预期了。
也许我们真的能够见证 “AI 独立开发者”的诞生，希望 SOLO 越来越能 SOLO。
