Trae用了小半年日常的开发工作基本都丢给它了。最近升级后多了一个SOLO模式我一开始以为是套壳的“独立窗口”没太当回事。结果实际用下来这个模式跟原来的Chat、Builder完全是两码事工作流变化比想象中大得多。这篇文章不聊官方文档里的介绍性内容就从一个普通使用者的角度说说我上手SOLO模式这段时间的体验、踩过的坑以及我觉得它真正适合干什么活。1. SOLO模式到底是什么跟Chat和Builder有什么本质区别先给还没用过Trae的朋友说一下背景。Trae是一个AI原生的IDE界面跟常见的编辑器长得差不多但它核心的能力在于内置了AI对话交互。之前用的时候主要分成两种模式Chat和Builder。Chat模式就是你在侧边栏跟AI对话它可以回答问题、解释代码、给修改建议但改不改、怎么改决定权在你自己手上。Builder模式更进一步你直接提出需求它会自动扫描项目相关文件动手改代码改完你只需要点接受或拒绝。这次新增的SOLO模式最直观的变化是——AI对话不再挤在侧边栏了而是独立成一个可拖拽、可缩放的窗口。听起来好像只是“窗口独立了”这点小事实际用下来远不止如此。SOLO模式和Builder一样也会自动分析项目、修改代码但它在交互体验上重新做了设计。开启之后AI的工作面板和主编程区域可以并排显示互不遮挡你甚至可以一边让AI帮你重构着某个模块一边在主编辑器里继续改另一个文件。模式交互方式改动方式适合场景Chat侧边栏对话只给建议不动手问问题、解释代码、讨论方案Builder侧边栏对话自动搜索并修改文件改功能、修bug、按需求直接动手SOLO独立窗口对话自动搜索并修改文件主面板不打断多任务并行、需要盯代码改动细节我自己理解SOLO这个名字其实很直白就是“单独干活”。它把AI从“编辑器的附庸”变成了一个可以独立工作的角色。主窗口是你的AI窗口是AI的两边可以同时操作。这种物理上的分离不是UI层面追求新鲜感而是为了解决一个实际问题当AI帮你改一个核心文件时你不想整个编辑器都被它的操作占满你还有其他文件要看、要改。实际写代码的场景里侧边栏模式最大的痛点是什么是遮挡。编辑器本来就这么宽侧边栏再占掉三四百像素代码区就剩个窄条。SOLO模式把对话窗口独立出来代码区完整保留动手改代码的体验舒服太多了。我现在用Trae基本都开SOLO模式用回侧边栏会觉得非常局促。1.1 解决了侧边栏模式最让人难受的“操作黑盒”问题用Builder模式时不知道大家有没有一个感受AI在侧边栏里跟挤牙膏一样一条一条地吐修改日志你看到的是“已修改xxx文件”这种结果但修改前后的diff、为什么这么改信息都被压缩了。有时候AI一顿操作猛如虎你点完接受才发现它把别的逻辑顺带一起动了但它在侧边栏里根本没详细说。SOLO模式在这方面做得明显更好。因为窗口独立信息密度可以做高。修改了哪个文件、改了哪些函数、改动前后的逻辑对比、有没有副作用这些在独立窗口里展示得更完整。我放大了窗口开始工作AI做了什么修改每一步过程都看得到不再是等它全改完了再告诉我“好了”。这一点对维护老项目尤其重要。老项目的代码往往不是理想化的结构有很多历史包袱。AI在没有足够上下文时容易出现想当然的重构。SOLO模式下我能及时看到它动了哪块发现苗头不对直接打断让它在当前窗口调整不用切来切去心理上的负担小了很多。1.2 多任务并行这才是SOLO模式真正的杀手锏用过Builder模式的人都知道Builder在改代码的时候你在主编辑器里操作其他文件侧边栏会一直跳动你需要不停切换视线。但“多任务”体验真正顺畅还得是SOLO这种独立窗口模式。举个具体场景。我之前在做一个跨平台小系统的前端页面适配需要同时调整一个页面的响应式布局和另一个页面的一处接口对齐逻辑。以前的做法是开两个编辑器窗口或者一边开浏览器预览一边切回编辑器。用了SOLO模式后我直接把AI窗口拖到屏幕右侧让它在这个窗口里帮我重构那个响应式布局组件。同时我在主编辑器里继续处理接口对齐的代码。两边互不干扰AI窗口是一个独立的逻辑空间它跑它的任务我跑我的任务修改汇集到同一份文件上。虽然本质上还是同一个编辑器在管理项目但视觉和交互上的隔离感明显不同。不需要切Tab不需要来回找侧边栏到哪了。对于手头事情多、时间碎片化严重的开发者来说这种爽感是实打实的。2. 从Chat到Builder再到SOLOTrae的工作流逻辑到底是怎么演进的理解了SOLO模式是什么再深一层的问题是为什么Trae要专门做一个独立窗口模式要回答这个问题得先梳理一下AI编程工具本身的工作流演进。早期的AI编程工具本质上就是一个带上下文的聊天框。你问一句它答一句给你的代码建议需要手动复制粘贴到编辑器里。这个阶段的核心是“参考”和“查询”。后来开始有了内联补全AI根据注释和上下文直接生成代码片段你Tab一下就能接受。这个阶段的核心是“补全”。再后来出现了Builder这类自主编码模式AI可以直接读写你的项目文件完成一个相对完整的功能开发。核心变成了“执行”。经历这几个阶段你会发现一个问题AI帮你执行任务时人往哪儿放早期的自动编码模式AI在侧边栏行动你像个监工站在旁边看它操作。它能干的事越来越多你反而越来越闲但它干出来的东西你不一定满意。这个“监工”体验很尴尬。SOLO模式本质上是在回答一个问题当AI能独立完成越来越复杂的编码任务时人应该以什么角色参与进来我的理解是它给出的答案是“并行协作”。不是让AI替代你也不是让你盯着它干活而是让AI去独立处理一个任务同时你继续做自己的事。两个任务在时间线上重叠最后在代码层面汇合。这比“你提需求、AI干活、你审查结果”这种流水线式协作效率高得多因为流水线是有阻塞的而并行协作没有。阶段核心模式人的角色存在的问题Chat问答对话式提问者只说不做效率依赖人手动搬运行内补全单点生成打工人只适合短片段复杂逻辑无能为力Builder/自动编码全自动监工过程不透明改动像黑盒盯得累SOLO模式独立窗口协作并行协作者需要适应的新习惯总体效率更高2.1 窗口独立性背后是“注意力分配”的重新设计为什么窗口独立会带来这么大的体验差异我觉得核心在“注意力分配”。侧边栏模式下你的视觉焦点始终被局限在编辑器内部。AI要改动一个文件必然导致编辑器内容变化你的注意力被迫跟随。你很难在AI做批处理的时候专心干另一件事。因为右下角一跳你就想知道它改成什么样了这种强迫性切换非常消耗精力。SOLO模式的独立窗口相当于把AI的任务从你的主视野里“剥离”出去了。你能看到它但它不强行占用你的注意力。它是一个并行的工作进程你愿意看它的时候瞄一眼不愿意看的时候就让它自己跑。这种注意力分配的自由度对需要长时间专注编码的人太重要了。我实测过开SOLO模式处理一个多文件重构任务时我先让它自己跑着我继续写另外模块的业务逻辑。等我把手头这段逻辑写完了回头再看它它已经把重构方案做完了改动列表完整列在窗口里。这种感觉有点像同时有两个协作者在写同一个项目互不干扰又共享同一份代码。2.2 从“对话式修改”到“任务式协作”指令思维要跟着变Chat和Builder模式下你的指令往往比较口语化。比如“这段代码为什么报错”“帮我优化一下这个函数”。但SOLO模式下因为AI的处理能力更强、操作更自主下指令的方式也需要调整。我最开始用SOLO模式时还是按Builder的思维跟它对话“帮我看看这个页面怎么优化。”结果它就真的只是“看看”守着一堆分析不出下一步。后来我发现在SOLO模式下更高效的指令方式是任务式的目标要清晰范围要明确验收标准要可检查。举个例子同样是优化一个页面Builder模式下你可能会说“这个页面加载太慢了帮我优化一下”。AI会检索很多方面给出一个泛泛的优化。而SOLO模式下的指令应该是“把列表页的图片加载改为懒加载同时把首屏无用JS拆包做完后给我一份改动清单并说明每个文件的改动目的。”这样AI会按任务去执行分步完成最后交付一个可验证的结果。这不是说SOLO模式多高级而是工具的形态决定了交互方式。独立窗口让你跟AI的协作时间变长协作内容变复杂自然需要更工程化的沟通方式。如果你现在还停留在“一句简单对话让AI猜你心思”的阶段用SOLO模式会发现效率提升有限。但如果把指令拆成“目标 约束 验收标准”SOLO模式能发挥出比Builder大得多的威力。3. 用SOLO模式完整开发一个功能实测操作过程和我的指令模板光讲概念没意思分享一下我是怎么用SOLO模式完成一个实际功能的。过程不复杂但里面很多细节值得说说。为了测试我做了一个非常经典的东西一个待办事项页面包含添加任务、标记完成、删除任务、本地存储这几块功能。这种项目看着简单但能完整覆盖SOLO模式的基础能力——生成代码、修改样式、修bug、加功能全部都在一个功能里体现。我开启SOLO模式后在窗口里输入了第一段指令“创建一个待办事项页面要求设计简洁有输入框和添加按钮。已添加的事项展示在列表中支持勾选完成和删除。数据用localStorage保存刷新页面不丢失。界面用现代风格支持手机访问。”AI很快就给出了整体方案直接生成了对应的HTML和JS代码并预览了页面效果。这里要提一句SOLO模式的预览能力确实好用。它能在独立窗口里直接展示页面效果你不用自己开浏览器刷新来看。对前端开发来说这个实时预览省掉一多半重复操作。以前写一个样式要切到浏览器F5一下在SOLO里直接看结果不满意就让它马上改反馈循环短了很多。3.1 让AI动手改细节我用的是“三步走”指令法生成完基础版本后我对样式进行了调整。我让AI“把页面背景改成浅灰色卡片式设计给每个待办事项加上圆角和阴影”。AI迅速给出了修改后的代码主窗口里的界面实时更新。接下来我又要求增加了一个“显示待办数量统计”的小功能同时要求“数据变动后更新统计数字”。这些指令都很快完成。整个过程中我发现一个比较实用的沟通技巧把它总结成三步走第一步先描述最终效果不要描述具体代码写法。比如“我想让每个事项在鼠标移上去时显示一个删除按钮”而不是“你帮我写一个mouseenter事件绑定在li上”。AI自己能决定实现方式给它空间反而效果更好。第二步指定改动范围告诉它改哪个文件、哪个函数还是全局都在改动范围内。如果不说清楚AI有时候会顺手把无关代码也重构了事后追查起来很头疼。第三步明确验收标准。比如“改完之后我点击任意事项的删除按钮对应事项从列表消失并且localStorage同步更新”。这个标准越具体AI自我检查的准确度就越高你事后验收成本就越低。3.2 让AI自查代码而不是你自己把代码一个字一个字读完做开发的都知道AI生成的代码不能无脑信任。一个常见的陷阱是AI生成了功能代码但边界情况处理不完善。比如那个待办事项应用如果添加的内容是空字符串会怎样如果localStorage里存的旧数据格式跟新代码不兼容会怎样按以前的做法我得自己读代码去检查这些边界逻辑。SOLO模式下我换了一种做法让它自己自查。我跟它说“帮我把所有可能出错的边界场景找出来包括空输入、重复提交、本地存储数据格式异常等等检查完之后把问题列出来并给出修复方案。”这一步做下来AI果然发现了几个问题比如输入空字符串时仍会添加一项空数据连续快速点击添加按钮会生成重复任务localStorage中如果存在旧的损坏数据页面加载会报错。其中有几个细节点是我自己看都不一定能立刻察觉的。用SOLO模式的好处在于AI有足够的上下文和思考空间能对我的要求做更深入的推敲。3.3 让它批量改代码时一定要求它输出改动清单SOLO模式下让AI做批量改动这是它最擅长也是风险最高的场景。自动改代码一改就是好几个文件。最怕的就是它改完你不知道它到底动了哪里。我的习惯是每次批量改动前在指令里加一句“改完之后把涉及的文件列表、每个文件的核心改动点、以及改动可能影响的功能列在窗口里”。别小看这句话它能强制AI在完成时给你一份可审计的摘要。也许你觉得看diff更准确但AI自己总结的改动点往往比diff更聚焦因为它是按“意图”来总结的而不是按“文本变化”来罗列的。我用这个方法改了一次项目里一个老模块的接口调用方式。让AI把某个旧接口的调用全部迁移到新接口上涉及了六个文件。它完成后的改动摘要非常清晰每个文件为什么改、改了什么一目了然。我花了几分钟审阅摘要后直接接受。这种体验在侧边栏模式下是做不到的侧边栏空间太小AI不会主动列这种清单都是在一个小框里含糊其辞。4. 用SOLO模式踩过的坑和排查技巧全给你列出来任何工具都有坑SOLO模式也不例外。用了一段时间我把自己踩过的、身边朋友踩过的坑都整理了出来。这些问题不算致命但知道了能帮你少走不少弯路。4.1 旧项目第一次打开时先别急着让它动手先让它摸清结构这个坑我踩得最深。有次我拿SOLO模式打开一个维护了大半年的老项目上来直接让AI加一个新功能。AI倒是不含糊很迅速地在项目里找到相关代码开始动手改。结果我回头检查时发现它把另一个旧模块里一个同名函数也顺手改了。问题出在哪出在它对这个项目的整体结构认知不足。它只看到了与我描述相关的局部代码并不知道这个同名函数在别处是干什么的更不知道它是被好几个地方共用。它基于有限上下文做了过度大胆的重构。后来我的做法是拿到一个不熟悉的项目第一件事不是派任务而是先在SOLO模式下让它通读项目结构和关键配置文件。我会让它“先不用改任何代码请你先分析这个项目的目录结构、技术栈、核心模块的职责输出一份项目概览给我。”等它总结完确认它对你手里的项目真正理解了再来派任务。这个“热身”步骤花不了几分钟但能让后续合作顺畅非常多。4.2 别一口气给它一个超大任务拆成几步更稳有不少人用AI工具时喜欢一次性提一个很大的需求“帮我把这个系统改成微服务架构吧。”这种需求人听了都头大AI更做不到一次到位。它只会在有限上下文里构建一个残缺方案改出来的东西漏洞百出。SOLO模式虽然能力强但也不是“越大的任务做越好”——它是“越清晰的任务做越好”。我实测下来一个任务控制在“单一目标 文件数不超过十来个”这个范围内效果最稳定。如果任务太大了哪怕你在SOLO模式里硬让它做它做到后面也会把自己绕晕。推荐的拆法是把任务按功能边界拆。比如“把商品列表接口从单页加载改成滚动分页”“把用户登录后的token存储在cookie中并统一处理过期时间”“在管理后台增加一个导出订单的Excel功能”。每一个都是独立的小任务任务之间逻辑没有强依赖AI做起来准确率高你验收也容易。与其让AI做一个大而全的事然后疯狂修bug不如让它做十个精确的小事每个都做扎实。4.3 AI改完代码后你最好保留自己的“代码审查”习惯SOLO模式确实能替代很多重复劳动但绝对替代不了代码审查。AI生成的代码格式整洁、注释规范看上去专业得不得了但你深入研究时会发现一些隐藏的坑。举个例子我让它生成过一个数据校验的函数它用了非常漂亮的正则表达式。代码看起来完美但实际测试时发现某些非典型输入会导致判断失误。这让我意识到AI的代码是“看起来正确”的概率性输出它没有真正理解业务只是基于训练数据模拟了“一种可能的实现”。所以不管SOLO模式生成的代码多顺滑核心逻辑我仍然会自己过一遍。尤其是涉及结算、权限、数据一致性这类敏感逻辑的更是不能跳过。不要因为AI工具好用了就放松了自己该做的那道防线。4.4 一次会话里如果改错了别慌乱用好“恢复”和“再描述”还有一个实际使用中很常见的情况AI在SOLO模式下改坏了代码你慌了一下不知道怎么回退。我自己第一次也遇到这种情况。那次它改了一段CSS直接让页面的整体布局垮了。我第一反应是去找备份文件后来发现其实不用那么麻烦。遇到改错的情况我的经验是分三层去处理。第一层是让AI自己纠错你把出错的截图或报错信息贴在窗口里说清楚“你刚才改的代码导致了什么现象请修复”。大多数情况下它能自己意识到问题并给出修正方案。第二层是如果它改乱了多个文件你可以点开改动记录逐一回退具体文件的改动而不是整个项目一起回退。第三层是确实救不回来了那就恢复到最近一次保存的版本重新描述需求并且这次在描述里加上一点具体的约束避免它再犯同样的错。5. 关于SOLO模式我的使用心得和适合的场景工具毕竟是工具没有万能的。SOLO模式也不是所有场景都适合我自己用下来的体感是它在某些场景下效率提升极其明显但在另外一些场景下跟用原来的Chat/Builde r差别不大。给大家一个参考标准避免捧杀。最适合用SOLO模式的场景第一类是纯前端或全栈的快速原型开发。因为这些项目通常不涉及复杂的既有架构AI生成代码的自由度很高配合它的实时预览能力做出来的效果非常直观。你做一个小工具页面、做一个内部使用的管理后台demo、做一个验证想法的MVPSOLO模式都能给你极高的初始版本完成度。第二类是“改样式 调布局”这种琐碎且重复的活。这类工作技术含量不高但极其耗时。在SOLO模式下你只需要描述视觉要求AI自己调CSS同时你可以在一旁开着浏览器看实际效果不满意继续提要求。一趟下来原本要花掉一晚上的样式调整工作可能一小时就搞定了。第三类是接口联调和数据格式转换的脏活。比如对接新后端接口、把旧的XML数据转成JSON结构、批量修改字段命名规范等。这些工作具有极强的规则性AI处理起来非常擅长。而且SOLO模式把过程展示得清晰你能确切看到它改动的每一个环节。5.1 不太适合的场景我也说说真心话不太适合的是什么一个是需要强业务理解的复杂架构设计。举个例子设计一套多租户系统的权限模型牵扯到角色、资源、数据隔离、审计日志等多层概念还受到历史数据、性能约束、既有接口兼容等各方面限制。这种情况下AI的一个核心问题是它对“你当前的业务准确含义”的理解不够。你来来回回解释时间成本也很高不如自己设计好方案后让AI去实现具体模块。另一个是重重构场景。把多年历史原因堆积的老代码、所谓“大泥球”架构完全丢给AI去梳理成型风险很高。它可能会通过简单的重构手法在局部上让代码变得更“干净”但无法从整体上理解业务为何长成今天这样也就无法做出真正适合的结构调整。这种情况下我更建议人主导架构、AI做执行而不是反过来。5.2 用了这么久我的总体感受是什么市面上AI编程工具不少各有各的优势。SOLO模式作为Trae的一个特色功能核心价值还是在“并行协作”的交互上。它没有把AI包装成一个“全知全能的神”而是在承认AI能干的活越来越复杂这个前提下把人的参与方式重新设计了。对我个人而言它最直接的影响是我不用再像以前那样提心吊胆盯着AI改代码了。我可以让它干它的活我干我的活。这种默契感一旦建立起来整个开发的节奏会顺畅很多。但话说回来AI仍然是在创造“大量需要被检查的代码”而不是创造“完全可信的代码”。你越早学会与它高效协作就越能从中受益。5.3 最后再分享一个我已经养成习惯的小技巧最后分享一个小技巧是我用了很久才养成的习惯也确实提升了体验。每次在SOLO模式下开启一个新的开发任务前我会把相关的说明文档、原型文件或接口说明文档直接拖进对话窗口喂给它。这个步骤很关键。很多人在使用AI工具时默认AI什么都知道但实际项目里的业务背景、接口字段含义、特殊规则都需要输入给它。你喂给它的上下文越充分它输出的质量就越对得起SOLO模式这个独立窗口的设计初衷。像我们做某个内部项目时里面老旧的接口文档格式特别乱字段命名也完全没有规律。第一次让AI帮忙对接接口它完全基于猜测写代码结果字段映射一片混乱。后来我把整理好的接口字段映射文档直接拖进去告诉它“严格按照这个文档来”效果立竿见影。现在我做新功能时都会提前把关键背景材料塞给它这已经成了固定习惯。
