最近一段时间，我把日常改 Bug 的主力工具，从 Cursor 换成了 Trae。原因其实很简单：Cursor 的 Auto 开始额外收费之后，成本实在有点扛不住，只能现实一点——哪个便宜先用哪个。
Trae 首月 3美 元、600 次额度，对我这种每天都在写代码、改 Bug 的后端来说，还是很有吸引力的。用了一段时间之后，我发现 Solo 模式如果用对方式，效率是真的能提升，但前提是你要知道它“擅长什么、不擅长什么”。
下面是我比较真实的一些使用经验。
一、简单 Bug：直接文字描述，让它改，我来 Review
在日常开发中，其实有大量 Bug 都属于「低复杂度但很耗时间」的那一类，比如：
- 判空遗漏导致的 NPE
- 字段映射写错
- if / else 逻辑条件有问题
- 前端参数没传，后端却假定一定存在
- 日志、异常处理不规范
这类问题，我现在基本都是直接用文字描述丢给 Solo 模式。
例如：
这个接口在 accountId 为空时会抛 NPE，帮我补齐判空逻辑，返回结构不要变。
或者：
列表页排序不生效，检查一下是 SQL 里没加 order by，还是前端参数没透传。
Trae 的 Solo 模式会直接去改代码，改完之后我做的事情只有两步：
- 快速 review diff，确认没有“顺手多改”
- 本地跑一下关键场景，或者看一眼关键逻辑是否合理
这类 Bug 的特点是：你非常清楚正确答案是什么，只是不想自己敲。
Solo 模式在这里的定位非常清晰：执行型助手，而不是决策者。
二、复杂 Bug：必须告诉它「改哪里、别改哪里」
但只要 Bug 稍微复杂一点，Solo 模式就不能靠一句“帮我修一下”来解决了。
比如：
- 涉及多个模块（controller / service / mapper）
- 有明确的业务约束（审批流、状态机、权限）
- 改动必须兼容线上逻辑
- 不能影响其他流程
这种情况下，如果提示不清楚，很容易出现两个问题：
- 改错位置（AI 猜了一个它认为合理的入口）
- 改多了（顺手“优化”了你没打算动的代码）
我现在的做法是：复杂任务一定要把指令写成“任务说明” 。
我一般会明确三点：
- 改动入口：具体到类和方法
- 改动边界：哪些行为不能变
- 验证方式：用什么 case 验证是对的
比如我常用的提示方式是这样的：
Bug 出现在订单审批通过后的导出逻辑，入口在
OrderExportService#buildExportRows。
需要把「实际生产产品」和「开票产品」合并导出，字段和线上保持一致，不能影响其他导出类型。
你先给我一个 plan，列出会修改的文件和逻辑点，我确认后再执行。
当你把边界画清楚，Solo 模式的表现会稳定很多。
它不负责“想怎么改”，但非常擅长“按你说的改”。
三、自动生成 commit，这点真的很省心
Trae 让我比较惊喜的一点是：改完代码之后可以直接生成 commit。
对于那种一天要修很多零碎 Bug 的情况，这个体验非常好：
- 不用自己整理改动点
- commit message 相对规范
- 基本可以做到：review → 提交 → 下一个任务
我现在很多修复都是：
改代码 → 看 diff → 生成 commit → 提交
流程非常顺。
四、Plan → 再执行，是我最认可的使用方式
在 Trae 里，我最常用、也最认可的一种模式是：
先 plan，再执行
也就是先让它生成一个「改动计划 / 文档」，我看一眼确认没跑偏，再让它真正去改代码。
这一步对我来说非常关键。
AI 在写代码这件事上，最大的问题从来不是“不会写”，而是不可控。
以前用 Cursor 的 Auto 模式时，有时它会非常自信地改一大堆你没让它动的地方，review 成本反而变高。
而 plan 的好处是：
- 我能提前看到它打算改哪些文件
- 能判断它的理解是否正确
- 能在执行前就发现风险点
把“不可控的执行”变成“可审查的计划”，体验差别非常大。
五、价格很香，但 600 次真的不经用
现实也要说清楚：首月 3美元确实便宜，但 600 次额度消耗得非常快。
尤其是如果你习惯：
- plan 一次
- 执行一次
- 让它解释一次
- 再让它优化一次
几轮下来，次数消耗很明显。
所以我现在的策略是：
- 简单 Bug：Solo 快速搞定
- 复杂任务：plan 写清楚，尽量一次执行成功
- 超大需求 / 重构：还是自己主导，AI 辅助局部
总结：Trae Solo 适合谁？
我的结论很简单：
- ✅ 适合：对业务和代码有掌控力，只想提升执行效率的开发者
- ❌ 不适合：希望 AI 全权理解业务、自动设计方案的人
对我来说，工具不是信仰，能把活干完、成本可控，就是好工具。
在 Cursor 成本上来之后，Trae 的 Solo 模式，至少在改 Bug 这件事上，确实帮我兜住了效率和钱包。
如果你也是重度开发者，建议试一试，但一定要记住一句话：
你越清楚自己要什么，Solo 模式就越好用。
