我花了一周时间把 TRAE 的 solo 模式从头到尾用了个遍不是为了写评测是真的拿它去生成自动化项目。前后做了四个小工具踩了不下十个坑最后摸清楚了这个模式到底该怎么用。先把结论放在前面solo 模式不是让你省去写代码的功夫它是让你从“一个一个文件地写”变成“向 AI 描述需求AI 自己拆任务、写代码、跑调试、改 bug、给结果”。如果你还在用普通对话模式一次一次问它那 TRAE 最值钱的那部分你基本没用上。这篇文章写给两拨人。一拨是已经在用 TRAE 写代码、但 solo 模式开了三四次又关掉的另一拨是想做自动化项目、但不知道从哪下手、也不敢让 AI 全权负责的人。我把这一周的完整过程拆开讲包括我是怎么给需求、任务拆到什么程度、中间踩了哪些坑、最后怎么验收产物的全部按实操记录写下来。1. solo模式到底是什么先把它和普通对话模式的区别搞明白1.1 普通对话模式与solo模式的本质差异用过 TRAE 的人应该熟悉这个场景你在对话框里问“帮我写一个自动整理桌面文件的脚本”它给你一份 Python 代码你复制到项目里跑一遍报错再粘贴回去问“为什么报错”它改完你再跑循环三五轮结束。这不叫自动化这叫人工搬运。solo 模式做的事情是把上面整个流程接管了。你开启 solo 模式之后TRAE 会把你的需求理解成一个项目任务自己规划实现步骤自己创建文件、写代码、执行命令、看运行结果发现报错就自己回去改改完再跑直到达到它认为的完成标准最后给你一份摘要。我自己用下来最大的感受是普通对话模式是一次处理一个信息片段solo 模式是在模拟一个开发者的完整工作过程。这个差异说起来简单真正用起来影响很大。比如同样是“自动整理桌面文件”这个需求对话模式给你的是一份脚本而 solo 模式给你的会是一个包含脚本、依赖说明、运行日志、测试用例的小项目。前者解决你“缺代码”的问题后者解决你“要一个能跑的自动化工具”的问题。这个区别尤其体现在自动化项目的生成上。自动化项目本身讲究“能落地、能独立运行、有容错、有日志”这些不是一个代码片段能覆盖的。1.2 solo模式的“自动化”和你想要生成的“自动化项目”是两层意思很多人第一次看到“TRAE的solo模式生成自动化项目”这个说法会绕进一个误区solo 模式在自动写代码然后它生成的又刚好是个自动化项目那是不是我只要说句话就有一个现成的自动化工具冒出来没那么神但也没那么复杂。拆开看其实是两层自动化。第一层是开发过程的自动化。任务拆解、代码编写、命令执行、错误修复这几个环节由 AI 接管你多了一个不需要午休的“干活搭子”。第二层是产出物的自动化。你让 solo 模式做的项目本身是一个自动化脚本或工具比如自动整理文件的、自动发周报的、自动备份数据库的这部分是传统意义上的自动化。明白这两层之后你才会知道怎么给 solo 模式提需求。如果你的目标只是“写一段能用的脚本”solo 模式会显得有点大材小用如果你是想“拥有一套以后能持续使用的自动化流程”它才对得上胃口。我在实际使用中发现solo 模式最擅长的项目有一个共同特征需求边界清楚、验收标准明确、实现步骤可以拆成清单。比如“每天定时把某个文件夹里的临时文件归档”“每周一自动汇总上个月的销售数据并生成表格”这种命令式需求它上手非常快。反过来如果你给的是一句“做一个智能办公系统”solo 模式大概率会拆出一个你根本收不住的大型任务。2. 用solo模式生成自动化项目的完整实操记录2.1 先选一个适合练手的自动化项目自动归档下载目录我建议不管你的真实需求是什么第一次用 solo 模式都拿一个小而完整的项目练手。我这次选的是“自动归档下载目录”。为什么要拿这个项目做第一次实验因为它具备三个关键特征第一功能足够具体任何人一看就知道要做什么第二涉及文件操作、时间判断、异常处理能逼出 solo 模式真正的能力第三结果可以快速被验证跑一遍就知道成没成。我打开 TRAE新建了一个工作目录文件名叫download_archiver然后启用 solo 模式在对话框里输入了我准备好的需求描述写一个 Python 脚本自动整理我的下载目录 1. 扫描指定目录下的所有文件 2. 按扩展名分类图片、文档、压缩包、可执行文件、其他 3. 每个分类一个文件夹把文件移动过去 4. 已经按照分类整理过的文件不要重复移动 5. 运行时要输出日志记录移动了哪些文件、移动到哪里 6. 支持通过命令行参数指定目录 7. 运行平台是 Windows这里有个细节值得专门说一下我给的描述包含了“指定目录”“不要重复移动”“输出日志”“命令行参数”这些词每一个都是经过考虑的。“指定目录”和“命令行参数”决定了工具的可复用性没有参数硬编码固定路径的脚本换个电脑就得改代码。“不要重复移动”是自动化项目里最容易被忽略的容错逻辑如果脚本把已经归档过的文件再来一遍轻则报错重则把用户整理好的目录搞得乱七八糟。“输出日志”保证了你不在电脑前时也知道它执行完之后干了什么。2.2 完整执行过程从任务拆解到最终产物刚开始我也有点没底输入完需求之后我盯着屏幕看它自己折腾。先说结论它能跑通但过程不是一条直线。solo 模式收到需求之后第一步是在界面侧边栏给出一个任务拆解列表我没有手动干预但可以把鼠标放上去看它拆了什么。这次它列出的大致是分析需求确定脚本功能边界设计目录结构创建主脚本文件编写文件扫描和分类逻辑处理重复移动问题使用配置文件记录已归档文件的原始路径添加日志模块添加命令行参数解析运行测试修复报错看到这个拆解我才真正理解了 solo 模式的设计思路。它没有直接开写而是先建立一个“实现计划”并且把“重复移动”单独列成一个任务点说明任务拆解确实把细节吃进去了。接下来它就自己开始干活了。创建了main.py、requirements.txt、README.md、config.json这几个文件。中间有一段我印象很深它写完代码之后自己打开终端跑了一条测试命令结果因为测试目录不存在报错了然后它自己改了代码加了“目录不存在就自动创建”的逻辑重新跑通了。我在整个过程中只做了两次干预。一次是它生成的 README 里把功能名写得太复杂我让它简化另一次是它把图片分类的扩展名列表漏掉了.heic我跟它说“加上苹果手机照片的常见格式”。这符合 solo 模式的定位——它负责执行你负责把关和补充领域知识。最终跑完它用一条命令运行了脚本python main.py --directory D:\Downloads\test输出日志是我看了都觉得舒服的程度2025-11-20 10:24:31 - INFO - 扫描到 23 个文件 2025-11-20 10:24:31 - INFO - 移动 5 个图片文件到 D:\Downloads\test\图片 2025-11-20 10:24:31 - INFO - 移动 8 个文档文件到 D:\Downloads\test\文档 2025-11-20 10:24:31 - INFO - 移动 3 个压缩包到 D:\Downloads\test\压缩包 2025-11-20 10:24:31 - INFO - 已完成全部归档这就是我第一次完整跑通 solo 模式的体验。它并不是像魔法一样“啪”地变出一个项目而是像带了一个执行力很强的实习生你要在关键节点把方向、验收标准讲清楚剩下的重复劳动它来干。2.3 给solo提需求的标准模板四件事缺一不可一次成功不能说明方法可靠我又用同样思路做了几个项目之后总结出一个给 solo 模式提需求的标准模板。不管你做的是什么自动化项目这个模板里的四件事必须写清楚。第一件事目标和范围。一句话说清楚“做什么”。比如“写一个脚本把指定目录里的文件按扩展名分类归档”。“指定目录”就是范围不能让 AI 自己去猜。第二件事边界和禁忌。这是大家最容易漏的。比如“只整理下载目录其他目录不要动”“已经归档过的文件不要重复处理”“不要修改 .git 文件夹”。边界不写清楚solo 模式可能会发挥过头做出一些你意料之外的操作。第三件事运行方式和产出。写清楚脚本怎么被调用有没有命令行参数是否依赖第三方库最终需要输出什么。比如“通过命令行参数指定目录”“运行日志保存在 logs 文件夹下”。第四件事验收标准。这是 solo 模式能不能“自检”的关键。“怎么样算做完”——是“脚本运行一次不报错”还是“日志里显示全部文件移动完成”还是“目标文件夹被正确创建”。验收标准不明确solo 模式没办法判断自己有没有完成任务容易陷入自我循环或者跑完了连一份结果摘要都不给你。我推荐的提示词结构是这样的任务一句话描述目标功能 约束必须遵守的限制条件路径、文件类型、不改动范围 操作输入参数、运行方式、依赖环境、日志格式 验收运行成功的标准、输出结果的形态我后来所有项目都按这个结构输入solo 模式的表现稳定得多尤其是在“停在该停的地方”这一项上。3. 别踩这些坑solo模式高频翻车点实录3.1 任务太大solo模式拆出一个收不住的大摊子我第一次翻车就是栽在这儿。我当时想让 solo 模式做一个“团队周报自动汇总工具”本来心里的预期是读取几个 Excel 表格、合并数据、生成一张汇总表、输出一份文档。但我在输入需求的时候顺嘴加了句“最好还能做数据可视化顺便对异常数据自动发出提醒”。solo 模式立刻把这句顺着往上长拆解出来的任务列表直接多了一倍出现了“前端展示页面”“邮件自动发送模块”“定时任务调度”这些我没打算做的内容。它开始建前端目录、装第三方库、设计数据库表结构眼看着项目从一个脚本变成一个小型系统。这事给我自己的教训是给 solo 模式的输入必须做减法。你加一个“顺便”它就会加两个模块。自动化项目最核心的边界感在提需求的那一刻就决定了。3.2 环境依赖冲突AI跑得很欢你的电脑根本没那个环境solo 模式执行时会把代码在你本地环境里跑起来。这带来了一个很现实的问题它认为你的电脑上应该有 Python 3.11、应该装好了某些依赖库但你的实际环境可能根本不是这样。我遇到过一次很典型的情况。它写了一个需要pandas的脚本然后自己在终端执行pip install pandas因为网络原因安装失败它就开始一遍一遍地重试任务卡在第三层自动循环里。后来我的解决办法是在需求描述里直接写明“已安装的 Python 版本是多少”“是否允许在安装第三方依赖时自动执行命令”“依赖尽量只用标准库”。这些本来属于“环境约束”的信息如果你不告诉它solo 模式会按最简单的方式去实现也就是自己装包、自己改配置不管它访问的外网环境稳不稳。3.3 验收标准不明确AI把“不报错”当成“已完成”这是 solo 模式最隐蔽的一个问题它不报错不代表它做对了。举个例子。我让它写一个自动清理日志的脚本它从第一行代码跑到了最后一行没有任何报错solo 模式在摘要里说“任务已完成脚本运行成功”。但我去看它的实现发现它写的是删除指定目录下所有.log文件再自己往目录里创建一个测试日志文件验证删除效果。问题就在这儿。它执行的时候是把整个日志目录当成了测试现场测试结束之后目录里原来的日志确实被删了但新增的“测试日志”也留下了。这个结果和“自动清理日志”的真实需求有偏差可持续运行的结果里会残留垃圾文件。所以我在后续使用里一直强调验收标准要写成“可观察的行为结果”而不是“不报错”。比如“删除之后目录里不存在 .log 后缀文件”“清理前后目录文件数量减少”。这类标准能让 solo 模式在自检环节真正去验证功能而不是仅凭“没抛异常”就宣布完事。3.4 常见问题速查表整理一份这段时间遇到的问题速查表如果你在 solo 模式里遇到类似情况直接照着排查现象可能原因排查思路与处理方式solo模式反复执行同一操作停不下来割裂的“任务完成”判定标准检查验收标准是否明确在提示词里加“运行通过后立即停止不需要额外优化”生成的代码在我的电脑上报环境错误它在用理想化环境推测依赖在需求里写明 Python 版本、允许安装的库范围、注意离线环境AI一直在跑相当长的时间任务拆解过细目标不收敛提高需求和边界优先级拆小交付明确“一次会话只做一件事”生成的项目缺少日志和异常处理验收标准里没有提到“日志”在需求里显式要求“输出执行日志”“捕获异常并写入日志”它对文件操作无确认直接执行缺了“操作确认或安全边界”约束在需求里加“文件移动前先打印操作列表”“非交互模式下需要先演练”4. 进阶玩法让solo生成的自动化项目真正“融”进日常工作4.1 把产物变成常驻任务定时执行与日志追踪自动化项目生成之后离“真正自动运行”还差一步调度。这一步不在 TRAE 的任务范围内需要你自己接上。我在第一周做的“下载目录归档工具”最后就是用 Windows 任务计划程序接起来的每两小时自动跑一次。重点不是怎么建任务计划而是建设计划时给它折叠的几条配置经验。第一入口统一。我给脚本加了main.py作为统一入口所有参数都通过这里传不允许乱改脚本内部路径。之后定时任务的命令就固定成一条python D:\projects\download_archiver\main.py --directory D:\Downloads第二日志滚动。自动化任务最怕“跑了又没跑”看不出来。我给脚本加了日志模块每次运行写到logs目录下的按日期命名的文件里。这样即使任务计划执行了一百次你打开日志文件就能一眼看出哪次成功、哪次失败、失败原因是什么。第三测试先行。接进任务计划之前我手动用命令行跑了好几遍包括重复跑、目录为空、目录不存在、文件名含特殊字符这些情况。等把所有反例都验证过了才接进计划任务。这个步骤不能省AI 生成的项目第一件事永远是人工验证边界而不是直接丢进生产环境。4.2 用MCP扩展让solo模式能指挥外部工具TRAE 支持 MCP server 接入这一点对自动化项目来说含金量很高。简单说MCP 给了 TRAE 一个“外接工具接口”让 AI 可以通过安全的方式操作外部软件而不是只能读写文件、跑命令行。我之前看到讨论“怎么让 AI 直接操控 Burp Suite”的话题本质上也属于这一类场景——通过 MCP server 把 Burp Suite 的操作能力暴露给 AI然后 AI 可以自己发请求、看响应、分析数据。TRAE 里配 MCP server 的大体思路是在配置里加入服务端地址和工具名AI 在对话或 solo 模式下就能调用这些工具。不过我建议如果刚上手 solo 模式先别一上来就接 MCP。我自己的路径是先用纯脚本模式把自动化项目做出来跑通再接入 MCP 扩展能力。比如我后面做的一个“自动汇总销售表格”的项目就是接了一个操作 Excel 的 MCP serversolo 模式直接读数据、生成图表、输出报告比纯脚本实现省事得多。核心思路是MCP 是给 AI 增加“手和眼睛”solo 模式是给 AI 增加“脑袋和干活流程”。两者配合起来AI 生成的自动化项目才能真正具备“自动化操作外部软件”的能力。4.3 给solo模式建一个个人项目模板库用一段时间之后我发现自己反复在做类似的自动化任务文件整理、数据汇总、日志分析、定时备份。一开始每次都需要从头写需求后来我干脆整理了一个模板文件夹里面放了几套标准化的提示词按“任务类型”分类。比如文件整理类的模板长这样任务整理指定目录下的文件按扩展名分类归档 约束只处理 {directory} 目录下的文件不递归子目录不修改其他位置 操作通过命令行参数 --directory 传入目标目录默认目录为 {default_dir}将移动结果写入 logs/archive_YYYYMMDD.log 验收运行完毕后 target 分类目录存在原目录只剩无法识别类型文件日志中显示已处理文件数量把里面的大括号变量替换一下直接丢进 solo 模式就能用。这个方法帮我省了非常多时间。solo 模式擅长理解结构化输入你给它越规范的输入它产出的结果就越稳定。4.4 一个人也能维护的“自动化项目清单”最后分享一个实用习惯每跑通一个 solo 模式生成的自动化项目就在 README 里记三样东西——它做了什么、它运行需要什么环境、它上一次验证通过是哪一天。这本来是我自己为了不忘记项目内容做的记录后来发现对 AI 协作同样有价值。你想想如果一个自动化项目三个月没碰你需要重新捡起来改功能你打开 TRAE把 README 里的记录发给 solo 模式它三分钟就能理解项目现状直接进入修改状态。这套“先记录、再复用”的工作流比让 AI 从头分析代码高效得多。我个人的体会是TRAE 的 solo 模式真正适合用它的人不是那种“什么都不会、想让 AI 全包”的用户而是愿意把需求讲清楚、能在关键节点把控方向的人。它把写代码的体力活接了过去但项目的边界、验收、环境适配这些判断还是得靠人。搞清楚这个分工你用它生成自动化项目就不会有一种“它在替我瞎忙”的失控感。