企业官网建设流程全解析

1. 从"陪聊式编程"到"独立干活"：Solo模式到底改了什么

先交代一个背景。过去一两年里，AI 编程助手的主流用法，基本是"对话补全"：你在 IDE 里选中一段代码，让它补全、解释、改 bug。这种模式好用是好用，但有一个绕不开的死结——AI 只负责"说"，不负责"做"。

具体表现为：我让它"把这个列表页改成虚拟滚动"，它确实改好了，但依赖没有装、事件监听没清理、滚动容器没设置，跑起来一片白屏。我又得手动装依赖、手动查报错、手动把报错贴回去，一来一回十几轮。最后代码确实是 AI 写的，但活全是我盯下来的，完全没有"解放生产力"的感觉。

这也是我把 Trae 的 Solo 模式盯了很久的原因。Solo 这个名字起得很直白：你把它当成一个能独立干活的初级工程师来用，而不是一个只会接话的对话机器人。我不需要事无巨细地把每一步都拆好喂给它，只需要给一个相对完整的任务描述，它会自己去拆解、去改代码、去跑命令、去看报错、去修完再验证，一个人把一整套流程走完，中间可以不怎么打扰我。

我实际用下来的感受是：这个模式确实把 AI 编程从"回答者"往前推了一大步，变成了"执行者"。它的价值不在某一次代码生成的正确率，而在于它开始承担流程责任了。

为了方便对比，我做了个表，看一下它跟常规对话补全的差异。

这张表不一定代表每个人的体感，但骨架是准的。换句话说，Solo 模式的核心逻辑不是"更聪明的对话"，而是"能闭环的执行"。

那它是怎么做到闭环的？这里要先理解 Solo 在技术层面的几个关键设计。

1.1 任务粒度的变化：从"一句话需求"到"工程任务"

你给 Solo 的输入，可以是一句话，但真正跑得好的任务描述，通常是一个结构化的工程描述。它会先解析任务，自己规划步骤，然后按步骤执行。这跟我过去用对话补全时"给一句、写一段、调一次"的交互方式完全不同。

我记得第一次用 Solo 时，它还提示我可以先给出需求背景、技术栈、验收标准。我当时试了一个相对完整的需求描述，结果它自动拆出了四个阶段：分析现有代码结构、设计数据层接口、实现核心逻辑、补充单元测试。这四步它完全是自己列出来的，我没做任何引导。

当然了，它拆得好不好，跟任务描述的质量有直接关系。你要是只丢一句"优化这个项目"，它能做的大概也就是帮你重命名几个变量。这条经验后面我会专门展开。

1.2 工具调用的链路：它不是"嘴上说说"而已

Solo 模式另一个关键点是它能直接调用 IDE 里的工具链，包括读取文件、修改文件、在终端执行命令、查看输出结果。这意味着它的"改完了"是经过实际验证的。

我遇到过这样一个场景：它改完一个 Python 脚本后，自己在终端跑了测试，发现有一个 import 报错，然后又回去改了依赖引入，再重跑一遍测试，最后告诉我"已通过全部用例"。整个过程我没有插手，它从"查出问题"到"修复问题"到"验证完成"形成了一条完整链路。这是我过去用对话补全很难体验到的——过去这些循环完全靠人在中间跑腿。

当然了，工具调用不是万能的。它跑命令时如果环境变量有问题、网络受限、权限不足，同样会卡住。但关键在于它具备"发现卡点并尝试解决卡点"的能力，而不是一遇到报错就停下来问人。

注意：Solo 模式擅长的是"代码库范围内可执行、可验证"的任务。如果任务依赖外部服务才能验证，比如需要连一个线上数据库、调用某个第三方登录，它就无法完整闭环了。这个后面会专门讲。

2. 为什么要做一个"会自己跑"的编程模式：我理解的演进逻辑

既然要聊 Solo 的体验，就不能只停留在"它好用"或"它不好用"的表面判断。一个产品能做出这种新东西，背后一定有它想解决的问题。我站在使用者的角度，把这条逻辑线捋一遍。

第一个问题是：传统对话式编程助手，到底卡在哪？

我之前很长一段时间都以"对话式"为主要工作方式。用得越久越发现，它最大的瓶颈不是模型能力，而是上下文管理。你让 AI 改代码，它改完自己不看一眼；你让它处理报错，它可能压根不知道报错全文长什么样。这套模式从设计上就天然要求"人负责运行、人负责反馈、人负责验证"——人是唯一能闭环的执行者。

这种模式偶尔写写函数还行，一旦任务跨文件、多步骤、涉及运行环境，人就成了项目的瓶颈。我在做一个小的 Node.js 自动化脚本时感受特别深：AI 确实帮我写了入口文件，但账号配置、依赖安装、cron 触发的 crontab 写法都要我一步步替它跑通，不然它写的代码根本无法运行。

那能不能换个思路：不只是让 AI 懂代码，而是让 AI 有"工作流"权限，从任务拆解到执行验证全包了？这就是 Solo 模式出现的逻辑。它想解决的根本问题不是"一次生成更多代码"，而是"把人从执行链条中解放出来"。

2.1 Solo 不是"更智能"，而是"更有主动性"

很多第一次接触 Solo 的人会有一个误判——觉得 Solo 模式就是模型更聪明，什么题都会解。我自己测下来，它的模型选型可能确实会针对任务型场景做路由，但更核心的差异是"主动性"。

它主动读文件、主动跑测试、主动查文档、主动修复失败。这些动作不是模型本身自带的神通，而是产品层赋予了它调用工具的机会。这相当于给模型安了一双手和一双眼睛，让它能自己动手验证自己的想法。

我用一个生活例子来类比：过去用 AI 编程助手，就像请了一个很懂理论的顾问，他口若悬河地给你讲思路，但从不帮你动手装修；Solo 模式则像一个有经验的施工队长，你说清楚要什么风格，他会自己带着工人干活，中途遇到管线问题自己处理，最后交给你一个实际可以住的效果。理论上他也有答错的时候，但因为是自己动手干出来的，很多错误在过程中就被它自己发现了。

2.2 为什么"闭环"比"正确率"更重要

用过一段时间 Solo 之后，我慢慢有个感触：在真实开发里，AI 一次生成代码的正确率当然重要，但更重要的是它能不能自己发现问题、自己修、自己验证。因为真实现场最大的成本不是"写错代码"，而是"没人及时发现错在哪"。

我以前一排代码让 AI 改完，得瞎一顿操作才发现衔接处变量名不一致；现在 Solo 跑任务，它会自己跑测试，跑不通过就继续修，修完再跑，直到通过为止。就算它最终没有完全通过，它也会把执行过程、失败原因、下一步建议打包交给你。这比"我给你一段大概率有 bug 的代码"要有用得多，因为交付物里带着验证过程。

所以我的判断是：Solo 模式代表了一个值得关注的方向——AI 编程助手的核心竞争点，正在从"生成代码的智能程度"转向"执行任务的完整度"。

3. 我的完整实跑记录：让 Solo 独立完成一次模块重构

光说概念容易虚，我拿一个自己跑过的任务来说说实操全过程。这个任务是：把一个单体 Python 脚本中的配置解析、数据抓取、结果输出三部分拆成独立模块，并补充测试。规模不大不小，适合 Solo。

3.1 写任务描述时，我最在意的四个要素

我在写任务描述前，先想清楚了四个要素：背景、目标、约束、验收。

• 背景：现有analyze.py文件里混着配置解析、httpx 请求、SQLite 写入逻辑，越来越难维护。
• 目标：按职责拆成config.py、fetcher.py、storage.py，保留对外入口main.py。
• 约束：不换技术栈，不引入新依赖，保持原脚本的调用方式。
• 验收：所有单元测试通过；main.py输出的 CSV 与原脚本逐行一致。

这四条不是刻意写成模板的，而是我在跟 Solo 打了几个任务后自然总结出的"让 AI 少走回头路"的最小信息量。尤其是"验收标准"这一条，它直接影响 Solo 自己能验证到什么程度。没有验收标准的话，它跑完测试也不知道自己算不算完成，会一直在代码里打转。

3.2 Solo 的执行过程：四个阶段全记录

任务提交后，我盯着它跑了大约二十分钟，整个过程大致是下面这个节奏。

第一阶段是结构梳理。它先读了原脚本的完整内容，然后在执行计划里列出来：原脚本哪部分是配置、哪部分是抓取、哪部分是存储，哪个函数被重复引用。这一步相当于传统开发里的"代码走读"。它读码的时候如果发现边界不清晰，会停下来在计划区标注"此处存在隐式全局变量，需拆解时注意"。

第二阶段是拆解实现。它按功能边界建了新文件，逐个把函数搬过去。搬的过程中它做了件很细的事：它没有直接把原代码复制过去，而是在新模块里改了少量命名，同时用显式方式导入了依赖。原脚本里有session = requests.Session()这种全局对象，它把这些包到了fetcher.py的初始化函数里。

第三阶段是联调验证。它在终端里跑了原有脚本的调用命令，对比输出 CSV 的每一列。我记得过程中还真是出过一次问题：storage.py里 SQLite 的表字段映射顺序写错了，导致输出列顺序变了。它自己在对比时发现不一致，然后回去改了建表语句里的列顺序，再重跑验证通过。这一步是最让我觉得"像真人干活"的地方——不是改完就算，而是改完还会自己验证结果。

第四阶段是补充测试。它给各模块写了一批单元测试用例，覆盖了配置缺失、网络超时、JSON 解析异常等边界。然后跑pytest，边跑边修，直到全绿。整轮下来它大概自己跑了六七次测试命令，我没动手敲过一条命令。

3.3 结果评估：客观说一下它做得好和不好的地方

先说不好的地方：它拆完模块后，代码风格虽然一致，但模块注释写得比较"模板化"，缺少对这个项目业务语境的描述。比如storage.py的 docstring 只写了"数据库存储模块"，但没说明表的设计逻辑为什么按这个粒度切分。这类"业务语义的传递"还是得我自己补一遍。

再说做得好的地方：整个任务从拆解到测试是通过一轮完整执行闭环下来的，中间除了我看它跑外，基本没有人力介入。而且它最后交付的拆包结构清晰，main.py入口没有变动，原来调用它的人不用改任何接口。这算是典型的"Solo 模式适合干"的活：约束明确、有验证方式、改动范围可控。

3.4 实测中极易被忽略的一个前提

跑这个任务之前，我把项目的测试框架、依赖管理方式、代码目录结构都提前整理好了。至少pytest.ini已经存在，依赖项也已经装好。如果让 Solo 从零开始给一个完全没有工程化基础的项目搭测试框架，它也能做，但时间会耗在"先解决环境"而不是"完成目标"上。

所以我的建议是：Solo 模式最好在已有基本工程约定的项目里跑。你不用把环境做到完美，但至少让它知道用什么命令跑测试、用什么方式装依赖。这跟带一个新人实习是一样的，你先把工具链给他备好，他才有可能自己干活；不然他一上来光折腾环境就要花半天，产出自然好不到哪去。

4. Solo 模式的边界与踩坑记录：它不超神，但有套路

任何工具都有它的能力边界，Solo 也一样。我用了大概两三周，踩了不少坑，也琢磨出一些规避套路。挑几个典型的讲，至少能帮后来的人少花点冤枉时间。

4.1 任务链条太长，中间失败难以恢复

我第一次跑的一个任务是让 Solo 做一个"从数据库读数据→生成图表→往企业微信推送"的完整脚本。这个任务本身不难，但链条很长，涉及数据库驱动、图表库安装、Webhook 推送三块。它跑到一半的时候，卡在图表中文字体显示的问题上，反反复复试了好几次都失败，最后整个任务缓冲超时报错了。

这个失败给我一个教训：Solo 不是不能处理长链路任务，而是任务链路中不该有"不可控的外部依赖"。字体问题是系统级配置，不是代码库内能解决的，它磨再久也很难自己搞定。所以再遇到类似任务，我会先把"依赖系统环境的部分"自己处理好，或者明确告诉它不要管这部分。

后来我重新试了一次，任务描述里加了一句"中文字体问题无需处理，已由系统配置完成"，后面就顺畅了。Solo 的厉害之处在于它确实会限制自己按约束执行，前提是你把约束说清楚。

4.2 任务目标太抽象，它容易"自由发挥"

我个人观察到一个很强烈的规律：任务描述越模糊，Solo 发挥的空间越大，往往就越容易偏离你心里的期望。有一次我想让它"优化项目结构"，它直接把utils.py里的十几个工具函数按主题拆成了四五个新文件。从代码组织角度看，它做得没问题，合理也干净。但问题是，这些函数只是我临时放一起的一堆小工具，拆完反而增加了项目复杂度。

这个事让我意识到：Solo 是一个"给多大自由度就发挥多大自由度"的执行者。你不能只告诉它"优化一下"，而是要说清楚"只做 A 不做 B、保持对外函数不变、专项文件不拆"。这跟给外包团队写需求很像，需求越精确，结果越可控。

4.3 自己写测试、自己改代码，也可能"自欺欺人"

再有一个坑是：Solo 会自己写测试用例来验证自己的代码，但测试用例的水平参差不齐。说得直白一点，它天然会偏向"证明我写的东西是对的"，而不是"证明你的需求是对的"。

举一个真实的例子：我让它"修复金额格式处理函数中边界情况导致的舍入错误"，它写了一条测试用例，断言format_amount(0.1 + 0.2) == "0.30"，然后修了舍入逻辑，测试通过。表面看没问题，但它完全没有测试"金融场景下常见的负数金额、超大金额、精度位数不一致"这些边界条件。这个不是它能力不够，而是它在没有明确验收要求时，倾向于选择最容易验证成功的用例。

针对这个情况，我的办法是在任务描述里明确列出"必须覆盖的边界场景清单"。你可以把它当成一个劣化版的测试驱动开发：你把测试点列出来，Solo 去逐条实现并验证，比它自己自由发挥要踏实得多。

4.4 不同模型在同一任务上的表现差异

Trae 的 Solo 模式下，模型是可以切换的。因为我用过不同的模型跑同一个任务，所以这个点深有体会。有的模型在代码生成质量上明显更好，但对任务规划很偷懒；有的模型规划得很细，但实现时频繁踩一些低级语法坑。

我一般会根据任务选择倾向：偏算法、偏逻辑的任务，选代码能力强的模型；偏工程重构、偏多文件组织的任务，选规划能力强的模型。这也是个经验之谈，没有绝对的"哪个模型一定最好"，只能说不同任务"匹配度"不同。

提示：如果你发现 Solo 跑任务的时候总在一个步骤上反复失败但又不换思路，可以试试切到另一个模型重跑同一任务。不用改任务描述，光是换模型，有时候就能绕过卡点。

4.5 权限与成本：看着不用管，实际要心里有数

Solo 自动执行命令是有实际成本代价的。它每跑一条命令，每调一次模型接口，都消耗 token 类资源。如果任务描述不清晰，它会持续反复打磨细节，消耗会远高于预期。

我有个真实的对比经历：同一个重构任务，第一次任务描述写得很草，它跑了两轮"计划重做、代码推翻重写"的循环，最后消耗是第二次的将近三倍。而第二次我只多花五分钟把验收标准写清楚，它一次就跑通。所以任务描述的投入，在 Solo 模式下是用真金白银的成本来兑现的。

另外，Solo 执行的命令范围完全基于它在当前工作区里的权限。我建议让它处理代码库内任务时，不要开太高的系统级权限，避免它执行不必要的危险命令。虽然它一般不会乱来，但风险控制这件事，工具用多了还是要有点敏感性。

5. 什么信号说明你适合用 Solo：几个判断标准

很多朋友问我"Solo 模式适合做什么、不适合做什么"，我根据自己的实践，整理了几条判断标准，不一定全对，但至少能帮人少走弯路。

5.1 适合 Solo 的任务特征

我总结了四个特征，符合得越多越适合交给 Solo。

• 结果可验证：任务有明确的通过标准，比如"测试通过""输出与某文件一致""接口返回正确"。只要结果可验证，Solo 的自动循环就能真正闭环。
• 改动范围清晰：任务只涉及某个模块、某个目录、某类文件，不会牵扯到多团队的协作面。
• 工程环境已具备：依赖安装基本完成，测试命令可用，项目本身不是一片废墟。这个前面讲过，很重要。
• 目标描述可以结构化：你能把"背景、目标、约束、验收"用几句话说清楚。说不清楚，Solo 就会替你发挥，结果就可能跑偏。

我常用的一个场景是给同事的代码补单元测试。我把测试文件和被测函数的路径写清楚，把要覆盖的边界情况列成清单，Solo 就能自己把用例补齐、跑通、修好，一整套下来非常省心。

5.2 不适合 Solo 的任务特征

反过来，下面这几类任务，我一般不交给 Solo，或者只交给它做其中一段。

• 强业务语义判断：比如"把首页策略改成新的推荐逻辑"。推荐策略背后的业务权衡、用户意图、数据口径，都不是代码库内能被完整理解的东西，AI 做不了这个决策。
• 跨系统联调：涉及多个服务之间没有明确契约、需要反复对账的任务。Solo 在单一工作区里很难感知到另一个系统的最新状态。
• 性能调优中的经验判断：比如"优化接口性能到 300ms 以下"。AI 可以帮你定位瓶颈，但最终的技术选型（上缓存、改索引、换协议）背后有太多工程权衡，它可能给一个"可行的方案"，但不一定是"最合适的方案"。
• 纯创意类工作：比如"重新设计一个交互流程"。Solo 模式擅长执行，不太擅长创造性的发散与取舍。

5.3 如果团队要用 Solo，我的三条建议

如果是一个团队想在项目里推广 Solo，我有三条实操建议。

第一，建立任务描述模板。团队内部统一一个"背景、目标、约束、验收"的格式，减少 Solo 的自由发挥空间。模板不需要多复杂，关键是逼着提需求的人把话说清楚。

第二，验收环节要保留人的判断。Solo 说"测试全部通过"不等于"需求全部完成"，人还是要把交付代码看一遍。我自己就遇到过它把测试写弱了导致误判通过的情况，所以代码 review 不能省。

第三，从小任务开始积累信任。别一上来就扔一个重构整个后端的大任务。先让它修几个 bug、补几个测试、写一个小工具函数，摸清它在你们代码库里的能力水平，再逐步放大任务范围。这个节奏比较稳。

6. 我最终对 Solo 模式的理解

连续用了两三周 Solo 之后，我对它的评价基本稳定下来了：它不是"比 AI 更 AI"的神器，而是一个把 AI 编程从"对话建议"推向"自主执行"的产品方向。它最大的价值是让 AI 开始对"流程"负责，而不是只对"片段"负责。

它的适用场景我归纳起来就是：任务描述清晰、结果可验证、工程环境可跑、改动在一个可控范围。这四个条件同时满足时，Solo 的体验确实接近"带了一个能自己画图、自己找 bug、自己交付的初级开发"。但条件不满足时，它也会用执行力放大错误的方向，所以任务描述和验收把关始终都得留一手。

最后分享一个我在使用中养成的小习惯：每次给 Solo 分配任务之前，我会先花十分钟写一个"验收清单"，列清楚我期望它最终通过哪些检查项。这个清单跟着任务一起发给它，既能让它执行时有方向，也能让我验收时不漏项。以前我总是凭感觉看一下代码就放行，现在有了清单，交付质量明显稳了。这个习惯对于用 Solo 的人来说，我认为是性价比最高的投入。