一个人+AI：Solo模式下的高效开发工作流实战

1. 为什么"一个人+AI"必须有一套显式工作流，而不是打开对话框就开干

1.1 单人开发最大的隐性成本是上下文切换

我接手过很多"一个人扛需求"的活：产品经理把需求文档往群里一丢，留下一句"这个不复杂，周一要"，然后人就不见了。没有测试帮你查边界，没有同事帮你 review，连个商量的人都没有。这种状态下，最大的消耗根本不是写代码那几小时，而是脑子在"用户视角、设计视角、实现视角、验收视角"之间反复横跳。切一次视角，少则十几分钟，多则半小时，一天能切上七八次，真正用来写代码的精力所剩无几。

这时候 Trae 这类 AI IDE 确实能顶上来，但前提是——你得先有一套自己的打法。我见过太多人拿着 Solo 模式当高级版聊天框用："帮我写个登录""这个报错帮我看看""把列表改成卡片"。AI 确实都会做，但做完的效果全凭运气。因为你没有给它方向，它只能猜；你没有给它边界，它只能自由发挥；你没有给它验收标准，它就认为"能跑"就是"做完了"。

所以问题不在于 AI 强不强，而在于你有没有一套把需求拆碎、把上下文喂对、把验收前置的流程。Solo 模式的价值不是"你少打字"，而是"你把决策点前移"。文章后面会给你一套可以直接抄的工作流，让你一个人也能把需求从模糊想法推进到可验收的交付物。

1.2 Solo 模式不是 Chat 的加强版，而是协作方式的改变

先澄清一个概念：Trae 的 Solo 模式，和我以前习惯的 Chat 式问答，完全是两种协作方式。

Chat 模式是你一句我一句，AI 更像一个随叫随到的搜索引擎加打字员。你问它一个问题，它给你一段答案；你说一个报错，它给你一段修复建议。所有事情都需要你主动发起，AI 永远不会自己往前多走一步。这种模式适合查资料、改一个小函数、复制一段代码，但撑不起一个完整需求。

Solo 模式则完全不同。你给它一个明确的目标，它会把目标拆成步骤，自己去读项目里的文件，自己分析现有代码结构，自己改动多个文件，然后把改了什么、为什么这么改、以及验证结果一起汇报给你。你的角色从"操作者"变成了"审核者"。这个转变非常关键——你不是不干活了，而是把精力从"怎么实现"转移到"方向对不对、边界全不全、验收过不过"。

我用一个表格直接对比两者，方便你定位自己应该用哪种模式：

这个差异直接决定了操作方式：你如果还在用 Chat 的思维方式去用 Solo，那一定会翻车。因为你只给了一句"帮我写个导出功能"，它真的就只写了一个导出按钮，然后告诉你完成了。这不是 AI 笨，是你没告诉它"导出要考虑权限、要考虑大数据量、要考虑文件名编码、要考虑日志留痕"。

1.3 工作流不是流程束缚，而是给 AI 的"操作轨道"

很多人一听到"工作流"三个字就头疼，觉得又要写文档、又要走流程，反而拖慢速度。我一开始也这么想，直到被 Solo 模式坑了几次才明白：一套好的工作流，不是为了让你多干活，而是为了让 AI 干活的时候不跑偏。

打个比方，Solo 模式像一个很能干的临时队员，你把它扔进项目里，告诉它"把这个功能做了"。如果你们之前没有任何约定，它就按自己的理解干活。你让它做个导出，它可能在 Controller 里写一堆业务逻辑；你让它改个接口，它可能顺手把你配置文件的格式调了。它在技术上没错，但方向和你要的不一致，最后花大量时间返工的是你自己。

工作流在这里的定位，是给这个临时队员一张"操作轨道"：需求先澄清到什么程度才能动手、项目上下文放在哪、验收清单长什么样、改完代码要求它做什么级别的验证。有了轨道，Solo 模式的自主性才真正变成生产力，而不是失控。

所以这篇文章接下来要讲的，不是一套复杂的管理流程，而是一条特别朴素、特别个人的推进链路：需求澄清 → 上下文落库 → 分步实现 → 验证复盘。这套链路我跑了小半年，踩过不少坑，最终固化成下面这套配置。你可以直接复制，再按自己的项目情况微调。

2. 先把需求"嚼碎"：Solo 模式下的需求澄清三板斧

2.1 问题清单比需求文档更重要

一个人干活的时候，最容易跳过的一步就是需求澄清。因为没有人问你"这个登录按钮点击后到底跳哪""数据量超过一万条怎么办""这个字段要不要脱敏"，你就默认自己都懂了。但事实是，你脑子里的"懂了"往往是模糊的，而 Solo 模式需要的是精确指令。你越模糊，它越自由发挥。

我现在的做法是：接到任何一个需求，不管大小，先让 Solo 模式扮演需求分析负责人，向我提问，而不是直接让它写代码。这听起来有点反直觉——让 AI 问我？但实际效果非常好。因为 AI 见得多，它能从一个你完全没意识到的角度问出关键问题。

我常用的提示词长这样：

code复制我正在用 Solo 模式做一个「带登录态的订单导出功能」。
先不要写代码。请你扮演需求分析负责人，向我提出 10 个问题，
目标是把四件事问清楚：使用角色、核心动作、最终产物、验收标准。
问题要具体，不要问"你有什么需求"这种空话。
问完后，把答案整理成结构化的需求澄清结果。

第一次用的时候我很意外，它问的问题包括：导出格式是 CSV 还是 Excel？要不要支持筛选条件？导出的数据量预估多大？超时怎么处理？是否有权限限制，普通用户和管理员导出的范围是否相同？文件名要不要带时间戳？这个粒度，已经比我平时接到的需求文档细多了。

这一步的核心价值在于：把你脑子里模模糊糊的东西，变成一条一条明确的约束。Solo 模式再强，它也没有读心术，它所有的判断都基于你提供的信息。信息越明确，它后面的每一步才越稳。

2.2 用"角色-动作-产物"三段式描述给 AI 建立边界

直接跟 AI 说"我要做个导出功能"，它会有几百种理解。但如果按"角色-动作-产物"三段式来说，AI 的理解范围就会被牢牢框住。这是我个人认为整个工作流中最关键的一步。

具体来说，任何需求都可以拆成这三段：

• 角色：谁在用这个功能，他有什么权限，他在什么场景下用。
• 动作：用户做了哪些操作，系统响应后的行为是什么，异常分支怎么处理。
• 产物：最终交付什么，格式、内容、命名规则、存储位置。

还是拿导出功能举例。我最开始给 Solo 的指令是"帮我写一个订单导出接口"，结果它写了一个最简单的不带任何参数、直接导出全部订单的接口。听起来没毛病，但完全没有可用性。后来我按三段式重新描述：

code复制角色：后台管理员，登录后访问订单管理页，可以按时间范围、订单状态、渠道筛选订单。
动作：管理员点击「导出」按钮，系统根据当前筛选条件生成文件；
     数据量超过 5000 行时，改为后台异步生成，生成后通过站内信通知下载。
     导出期间如果管理员退出登录，任务继续执行，但不展示敏感字段。
产物：CSV 文件，UTF-8 带 BOM 编码（避免 Excel 打开中文乱码），
     文件名格式为 orders_20250101_20250131.csv，
     文件内不包含手机号中间四位，只保留前3后4。

同样是"导出功能"，这样描述之后，Solo 模式产出的东西完全不是一个量级。它知道要处理权限才拿得到订单数据，知道要异步任务，知道字段要脱敏，知道编码细节。而你只是在需求澄清阶段多花了十分钟，后面省下的是几个小时的返工。

2.3 验收标准前置：让 AI 先回答"怎么算做完"

"做完了"这三个字，在单人开发场景里是最危险的词。因为你没有测试帮你把关，没有同事帮你 confirm，你说做完了就是做完了，但可能漏了一堆边界。我也犯过这个错：让 Solo 模式写完一个功能，它回复"已完成"，我复查了主流程发现没问题就合入了，结果第二天运营反馈某个筛选条件下导出是空的，还有一个用户导出的文件名乱码。

从那以后，我把验收标准前置到需求澄清阶段。也就是说，在 Solo 模式动手写任何代码之前，先让它基于需求输出一份验收清单，并且要按照"如果我是测试，我会怎么验证这个功能"来写。

我通常这样要求它：

code复制基于上面的需求澄清结果，列出一份验收清单。
清单必须包含：
1. 正常路径验证（核心流程能跑通）
2. 边界条件（空数据、超大数据量、特殊字符、并发操作）
3. 异常输入（没有权限、参数非法、文件生成失败）
4. 隐私与安全（敏感字段是否脱敏、日志是否记录了不该记录的字段）
每一条都要写出：操作步骤、预期结果、如何判断通过。

这份验收清单在后面的实现阶段有两个用途：一是作为 Solo 模式自测的对照表，二是作为你 review 代码和手动验证时的 checklist。有了它，你就不需要用"感觉差不多了"来判断是否完成，而是逐条打勾。

3. 从澄清到落库：搭建个人的需求上下文工作台

3.1 项目级规则文件就是 Solo 模式的"团队手册"

Solo 模式虽然能读项目文件，但它每次会话开始时，对项目背景的了解是从零开始的。如果每个需求你都把项目背景重新解释一遍，效率会非常低。更靠谱的做法是：在项目根目录维护一个规则文件，让 Solo 模式每次开工前先读它。

Trae 对这类项目规则文件有优先读取机制。它的作用相当于"团队手册"：告诉 Solo 模式这个项目是什么技术栈、代码怎么组织、命名规范是什么、用户权限模型是怎样的、哪些区域绝对不能乱动。

我自己的项目规则文件大概长这样：

markdown复制# 项目规则

## 技术栈
- Python 3.11 + FastAPI + SQLAlchemy
- 前端：Vue3 + Vite
- 数据库：MySQL 8，ORM 管理表结构

## 代码组织
- 业务逻辑写在 services/ 目录，Controller 只做参数校验和路由转发
- 数据库查询统一走 repository 层
- 工具函数放 utils/，禁止在业务代码里内联

## 安全红线
- 所有涉及用户数据的查询必须带 tenant_id 过滤
- 日志只记录操作行为，禁止记录手机号、身份证号等敏感字段
- 外部接口统一加签名校验，不允许裸调

## 约定
- 接口返回值统一使用 { code, message, data } 结构
- 文件名用 snake_case，类名用 PascalCase
- 不要修改 migration 目录下已执行过的历史迁移文件

这个文件每次帮我把 Solo 模式的行为框在一个正确的范围内，它不需要我重复说"注意租户隔离""别忘了脱敏"，它读完规则文件自己就知道。这个文件的维护成本很低，收益却非常高。

3.2 需求、接口、设计备注三件套

规则文件解决的是"项目长什么样"的问题。但每一个具体需求，还需要一个临时的上下文工作台。我习惯在 docs/requirements/ 目录下为每个需求建一个文件夹，里面放三件套：

• 需求文档：需求澄清的结果，包含角色、动作、产物、验收清单。
• 接口约定：和前端联调时用到的接口定义，包括路径、方法、请求参数、响应结构。哪怕你没有前端同事，这个文档也能让 Solo 模式写接口的时候保持一致。如果你用 Trae 接了 Figma 这类设计协作工具，还可以把设计稿上的字段说明也贴进去，信息更完整。
• 设计备注：实现过程中做过的关键决策，比如为什么用异步任务而不是同步导出、为什么字段只保留前3后4。这些备注是给未来的你看的，防止过两周自己都忘了当时为什么这么设计。

目录结构看起来是这样：

bash复制docs/
└── requirements/
    └── order-export/
        ├── requirements.md
        ├── api-contract.md
        └── design-notes.md

这个习惯一开始看起来像是给自己增加工作量，但实际用下来会发现：Solo 模式在实现阶段会频繁回来查这些文档，而你在 review 阶段也需要一个明确参照物。三件套一放，等于给整个需求画了一张地图，AI 和你自己都不会迷路。

3.3 Context 管理：每次会话只喂"够用"的信息，不贪多

Single 开发最容易被忽略的问题，是 AI 的上下文窗口。有人为了让 Solo 模式"更懂"项目，把整个项目的说明文档、代码目录结构、历史需求全部一股脑塞给它。结果就是：真正重要的需求信息被淹没在无关内容里，AI 反而开始输出跑偏的方案。

我的原则是"够用就好"。每一次 Solo 会话开始前，我会明确告诉它本次会话只围绕哪个目录下的哪个需求进行。比如：

code复制本次任务基于 docs/requirements/order-export/requirements.md，
涉及代码范围是 service/export_service.py 和 api/controllers/order_controller.py。
其他文件不需要改动，也不要顺手优化无关代码。

这句话看起来简单，但极其好使。它划定了两个边界：信息边界（只参考这个需求文档）和动作边界（只改这两个文件）。有了边界，Solo 模式就不会自己脑补出别的任务。等这个功能验证通过、合入之后，如果下一个需求要改动同一片代码，再开一个新会话，重新让 Solo 模式读取最新的项目状态和相关文档。

4. 从需求到验收：一次完整 Solo 推进的实例拆解

4.1 先定个实例背景

前面讲的全是方法论，这一节我拿一个真实跑过的需求来串一遍完整链路。这个需求是：后台订单管理中增加"导出订单"功能，支持按筛选条件导出 CSV 文件，并区分不同角色的导出范围。

需求澄清阶段我们已经产出过验收清单，这里直接回顾关键约束：

• 管理员可以导出全部订单；运营只可以导出自己渠道的订单。
• 导出字段包括订单号、用户手机号（脱敏）、商品名称、金额、下单时间。
• 数据量预估最大 5 万条，超过 5000 条走后台异步任务，完成后通过站内信通知。
• CSV 编码 UTF-8 with BOM，文件名带时间范围。
• 导出操作写审计日志，记录操作人、时间、筛选条件。

这个例子覆盖了单人开发最常见的难点：权限过滤、大数据量处理、异步任务、脱敏、审计。

4.2 完整会话链路：让 Solo 模式分阶段推进

我通常不会让 Solo 模式一口气写完所有东西，而是分成四个阶段，每个阶段之间我来做审核和决策。

阶段一：方案设计

先不写代码，要求 Solo 模式基于需求文档输出实现方案：

code复制请阅读 docs/requirements/order-export/requirements.md，
基于项目现有代码结构，输出实现方案：
1. 涉及哪些文件，每个文件做什么改动（新增还是修改）
2. 权限过滤如何复用现有逻辑
3. 异步任务用现有队列组件还是新增
4. 脱敏实现的具体位置
方案控制在 800 字以内，不要写代码。

这个阶段是我觉得最值得花的十分钟。因为方案一出来，你可以提前知道它打算怎么干，有没有违背项目约定，有没有走弯路。如果方案有问题，这时候调整成本最低。

阶段二：按方案实现

确认方案没问题后，第二阶段让它动手：

code复制按确认的方案开始实现。
要求：
- 只改动方案里列出的文件
- 每完成一个子任务，简要说明改动点和原因
- 敏感字段脱敏必须用统一的掩码工具函数
- 接口返回值遵循项目统一结构
实现完成后，总结改动文件清单，供我 review。

这个阶段 Solo 模式会自己跑一段时间。你不需要一直盯着，但要在它给出阶段性汇报时检查一下方向有没有偏。

阶段三：自测与补充

实现完成后，我不会直接合入，而是把验收清单丢给它，让它对着清单自测：

code复制这是本需求的验收清单：docs/requirements/order-export/requirements.md 中的「验收标准」部分。
请对照清单逐条自测：
- 能跑到的，贴出关键代码路径或运行结果
- 跑不到的，说明为什么以及需要什么环境
- 发现缺陷的直接修复，并说明修复内容
自测完成后，输出「已通过」和「未验证」两份列表。

这一步非常关键。Solo 模式在自测阶段通常能自己发现并修掉一批低级问题，比如空指针、参数名不一致、漏了某字段脱敏。

阶段四：人工 review 收尾

前面三个阶段做完，最后一步是我自己亲自把关。我会让 Solo 模式生成一份变更清单摘要：

code复制汇总本次需求的所有变更：
1. 新增文件列表
2. 修改文件列表及每处修改理由
3. 是否对外部接口或数据库结构有变更
4. 是否存在与本次需求无关的改动

然后我打开 git diff 重点看两个东西：一是权限过滤逻辑是不是真的覆盖了运营只导出自己渠道这个规则；二是异步任务里有没有把敏感字段意外写入日志。确认没问题后我手动从前端页面上点一遍主流程，验收清单上的关键项逐条勾掉，然后合入。

4.3 卡点处理：AI 跑偏、改错文件、无限循环时怎么止损

Solo 模式再强，也会有跑偏的时候。我遇到最多的三种情况，和处理方法很简单：

情况一：改了无关文件。 原因往往是它觉得"这个命名不够好""这个函数顺手可以优化一下"。处理办法是立即止损：用 git checkout 把无关文件的改动还原，然后在对话里明确重申动作边界，要求它只做当前需求范围内的修改，并且自查是否还有多余改动。

情况二：同一个问题反复绕圈。 比如权限过滤改了三轮还不对，每次都在同一个地方打转。这时候我的处理是打断它，让它停下来解释现状，而不是继续改。让它描述：当前逻辑是怎么写的、为什么判断不通过、卡在了哪个具体条件。它解释完，往往是自己发现了盲点，然后我再决定是继续还是换一个实现路径。

情况三：改了功能但没考虑边界。 常见于只验证了正常路径，数据量一大就超时或者内存溢出。这种情况我会在自测阶段让它明确标注"大数据量分支是否已验证"，如果没验证，就要求它单独针对这个分支写测试或打印运行日志。

这几类卡点不用怕，它们本质上是协作过程的一部分。关键是你要有止损意识，及时判断是继续还是回退，而不是让 AI 自己无限试错。

5. 单人团队最容易踩的坑：Solo 模式的五大翻车现场

5.1 一次喂太多需求，上下文被打爆

我犯过最典型的错误，是攒了三四个需求一次性丢给 Solo 模式："顺便把这个列表页面的搜索也改一下，再把那个弹窗的 bug 也修了。"结果它做完了主需求，搜索功能改了但没测，弹窗 bug 修到一半把样式搞乱了。

原因很简单：一个会话里的目标越多，上下文越长，AI 的注意力就越分散。最佳实践是一次会话只推进一个需求单元，最小粒度到"一个功能点"。如果你确实有多个需求要处理，按优先级排队，一个一个来。你可能会说这样慢，但实际上它等于让你每天都有一条干净的交付线，远比一口气处理三件事然后全部返工要快。

5.2 AI 改完代码不回归测试，只顾着往前写

Solo 模式默认是往前冲的，它写完新功能后，倾向于继续写下一个功能，而不是回头验证之前的功能有没有被改坏。尤其是在多人维护的老项目里，改一个公共工具函数可能会影响几个调用方，但 AI 不会主动去把所有调用方都跑一遍。

这也解释了为什么前面要前置验收清单，并在实现完后进自测阶段。自测的关键不是让 AI 说"我测试过了"，而是让它把验证方式具体化：是跑了单测？还是打了日志手动验证？还是用脚本调了接口？验证方式越具体，你越容易判断它是不是真的在测。

5.3 不看 diff 直接信任，等上线才发现问题

一个人干活的另一个风险，是容易把 AI 当成可靠同事。我见过有人让 Solo 模式改完代码，看一眼"已完成"就直接推送。AI 生成的代码里，大概率不会有大问题，但可能存在和你项目约定不符的写法、性能隐患、或者它自己引入的辅助逻辑。

现在我给自己定了一个硬规矩：Solo 模式每次交付后，我必须要看最终 diff，而且重点不是看正确性，而是看"有没有出现我没让改的东西"。AI 偶尔会自作主张加一个配置文件、改一行缩进、升级一个依赖版本。这些改动的风险不在当前功能，而在未来——你根本不知道哪一天依赖升级后项目起不来了，而查了半年才发现是那次"顺手升级"埋的雷。

5.4 模型选型不当，复杂任务频繁翻车

Trae 里不同模型的能力侧重不一样，选错了直接效率减半。我自己的经验是：简单任务、快速脚本、格式整理这类纯体力活，接 DeepSeek 这类性价比高的模型完全够用；但涉及跨多文件重构、复杂业务逻辑、权限建模这类高认知密度任务，一定要用能力更强的模型，不要省那点积分。

怎么判断该用哪个？一个很土但我一直在用的标准：如果这个需求你在脑子里想一遍就觉得"有点绕"，那就默认选更强的模型。等任务复杂度上去以后再换模型，执行到一半切换，上下文全丢，代价更大。关于积分的消耗，建议在开始复杂任务前分配好预算，别做到一半发现积分不够被迫切换，那种体验会直接打断你的状态。

5.5 环境问题不是小事，自动更新和版本不匹配早晚坑你

最后这个坑看起来和技术工作流无关，但它坑了我一次完整的交付。Solo 模式做需求做到一半，IDE 弹了个自动更新提示，更新完以后项目里的某些配置需要重新适配，AI 的上下文也丢了，整个会话被迫重启。从那以后，我干活前会主动关掉自动更新，一切以当前任务的稳定优先。等一个需求完整交付后再统一升级。

还有一些环境问题也需要提前排查：MCP 配置是否生效、本地模型是否加载正常、Python 环境依赖是否完整。Solo 模式跑任务时如果频繁遇到环境报错，它会花大量时间在"排查环境"而不是"实现需求"上。开工前花五分钟把环境检查一遍，后面能省一小时。

6. 把 Solo 模式用成"团队"：放权边界与复盘沉淀

6.1 哪些事可以完全交出去，哪些必须你亲自把关

一个人用 Solo 模式，最难把握的是放权的度。放太多，它跑偏你兜不住；放太少，等于你自己重新把活干了一遍。我的放权策略分三层，分享给你参考：

这条分界线的核心逻辑是：可逆程度越高，越可以放给它；不可逆或者影响面大的操作，无论如何都要握在自己手里。比如改一个测试文件，错了就删了重来，随便放；改数据库 Schema，一旦上线出问题，想回滚非常痛苦，这种我永远自己先出方案。

6.2 用"复盘纪要"把每次 Solo 会话变成团队经验

单人开发最可悲的是：同一个坑踩两次。因为没有人帮你记着你上次是怎么解决的。Solo 模式帮你干活的同时，还会产生大量有价值的对话信息——哪些方案被否了、为什么被否、最终选了哪条路径。这些信息如果不沉淀下来，下次遇到类似需求，AI 还是会从零开始。

我现在会在每个需求交付后，花五分钟写一份简短的复盘纪要，存在需求的 design-notes.md 里。内容包括：

• 这次需求实现过程中，Solo 模式在哪些地方表现好、哪些地方严重跑偏
• 被否掉的方案和原因
• 下次遇到同类需求时，提示词里应该提前写清什么
• 验收清单里有没有新增的检查项

比如做完订单导出后，我在复盘里记了一条："运营角色导出权限的判断必须写在 service 层，不能写在 controller，因为接口将来可能不止一个入口。"下一次做报表导出时，这个经验直接就能用上，不需要再让 AI 绕一圈。

6.3 进阶玩法：把高频需求固化成工作流模板

当你用这套流程跑通几个需求之后，你会发现自己接的很多需求都有共性。比如"管理后台的列表页 + 筛选 + 导出"这个组合，我一个月能遇到三次。与其每次都从需求澄清做起，不如把这类高频需求抽象成模板。

我现在项目里维护了一个 docs/solo-workflows/ 目录，里面是各种常用模板：

• crud-list-template.md：列表页三件套（查询、分页、筛选）的需求澄清提示词和验收要点
• export-template.md：导出功能模板，包含编码、文件名规范、异步任务、审计日志
• refactor-template.md：重构任务模板，强调影响面分析、测试路径梳理
• bugfix-template.md：问题修复模板，强制要求复现步骤、根因分析、回归范围

使用方式很简单：接到新需求，先判断它属于哪个模板，复制模板到 docs/requirements/xxx/ 下，然后按实际场景补充差异部分。这样你每次开工前不用从零想提示词，上下文也天然齐全，Solo 模式的表现会稳定很多。

这套东西从头用到尾，最核心的收获是：我不再依赖 AI 的"灵光一现"，而是依靠一套可以让 AI 稳定输出高质量结果的系统。哪怕今天用的不是 Trae，换一个 AI IDE，这套工作流照样成立——因为真正决定交付质量的，不是工具的功能列表，而是你喂给工具的上下文结构和决策节奏。Solo 模式给了你一个可以连续干活的数字队员，你要做的，是当好那个知道方向、守住边界、最终拍板的项目经理。