1. 从单线程到多线程为什么一个人干不完就得分工很多人用 AI 编程助手习惯了一个人从头到尾跟它聊到底。写个脚本、改个函数、调个 bug确实够用。但一旦项目稍微大一点比如要同时处理前端页面、后端接口、数据库迁移、测试用例你就会发现一个很尴尬的事你只有一个对话窗口AI 的上下文是有限的聊到后面它开始忘前面你不得不反复贴代码、反复解释背景效率反而比不用还低。这个问题的本质不是 AI 不够聪明而是单会话的上下文容量和注意力分配是有限的。你可以把单个 AI 会话想象成一个工位这个工位上只有一个人他既要写代码又要 review又要跑测试还要记着整个项目的架构。人多了会乱AI 也一样——上下文里塞的东西越多它越容易分心越容易在细节上出错。所以一个人干不完就分工这句话放在 AI 编程的语境里说的不是让你去招人而是把一个大任务拆成几个独立的、边界清晰的子任务每个子任务交给一个独立的 AI 会话去处理。每个会话只关心自己那一块上下文干净、目标明确输出质量自然就上去了。我最早意识到这件事是在做一个全栈小项目的时候。当时我试图用一个会话搞定所有事让它先设计数据库再写后端 API再写前端页面最后写测试。结果聊到前端的时候它已经忘了数据库字段的具体命名写出来的接口调用对不上我纠正它它又改错了后端。来回折腾了两个小时最后我干脆关掉重来拆成三个会话分别做四十分钟就搞定了。这个对比让我彻底明白分工不是为了并行而是为了隔离。隔离上下文隔离关注点隔离错误传播。1.1 单会话模式的三个隐形天花板在讲怎么分工之前得先把单会话模式的问题说透不然你不会真正重视分工这件事。第一个天花板是上下文窗口的物理限制。不管模型宣称支持多长的上下文实际使用中你会发现当对话轮次超过一定数量早期信息的权重会明显下降。你前面定义的接口规范、字段命名、目录结构到后面它可能就记不清了。这不是 bug是注意力机制的固有特性。第二个天花板是任务切换的认知损耗。同一个会话里你让它从写后端逻辑切换到调前端样式它需要重新建立对当前任务的认知。切换越频繁出错概率越高。这跟人是一样的——一个人同时干三件事哪件都干不精。第三个天花板是错误传播的不可控性。单会话里如果它在某个环节理解错了这个错误会像滚雪球一样影响后续所有输出。你改了一个地方它可能把之前对的地方也改错了。而在分工模式下每个子任务的错误被隔离在自己的会话里不会污染其他部分。理解了这三个天花板你就知道分工的核心目标是什么了让每个 AI 会话的上下文尽可能短、尽可能聚焦、尽可能独立。1.2 分工的粒度拆到多细才算合适分工不是越细越好。拆得太粗等于没拆拆得太细会话之间来回传递信息的成本又太高。我的经验是一个子任务的边界应该以能否用一段话描述清楚输入和输出为标准。比如实现用户登录接口就是一个合适的粒度输入是用户名密码输出是 token 或错误信息依赖是数据库里的用户表。这个任务一个会话能独立完成不需要知道前端长什么样。而实现整个用户模块就太粗了它包含了注册、登录、鉴权、改密码、找回密码等一堆子任务塞一个会话里又会回到单会话的老问题。反过来写一个校验邮箱格式的正则又太细了这种任务不值得单独开一个会话直接在父任务里顺手做了就行。我一般会把项目拆成这么几层架构层定规范、模块层写核心逻辑、接口层对接边界、验证层写测试。每一层开独立的会话层与层之间通过明确的契约来传递信息。这个契约可以是接口文档、可以是类型定义、也可以是一段简短的说明。2. 分工之前先定契约接口先行的工作方式分工最大的坑不是拆得不对而是拆完之后各干各的最后拼不起来。我踩过这个坑后端会话按自己的理解定义了返回字段叫userName前端会话按自己的理解写成了username大小写差一个字母联调的时候找了半天。解决这个问题的办法只有一个在分工之前先把契约定下来。契约就是各个子任务之间的接口约定包括数据结构、字段命名、错误码、调用方式。契约定好了每个会话都按契约来拼装的时候就不会出问题。2.1 契约应该包含哪些内容一份能用的契约至少要包含这几样东西数据结构定义每个接口的请求体和响应体长什么样字段名、类型、是否必填。命名规范变量用驼峰还是下划线文件用横线还是下划线常量全大写还是别的。这个必须统一不然拼装时全是小毛病。错误约定错误码怎么定义错误信息什么格式是抛异常还是返回错误对象。目录结构文件放在哪个目录模块怎么组织。这个决定了各会话产出的代码能不能直接放到一起。我通常会在第一个会话里专门做这件事让 AI 根据需求生成一份接口契约文档然后我把这份文档保存下来后续每个子会话开始时都把它作为背景信息贴进去。这样每个会话都知道我这一块要跟谁对接、按什么格式对接。提示契约文档不要写得太长控制在能一屏看完最好。太长了每个会话都要读半天反而浪费上下文。2.2 用类型定义代替口头约定口头约定容易忘写在文档里也可能被忽略。最可靠的办法是用类型定义来当契约。如果你用的是 TypeScript那就先写.d.ts或者types.ts如果是 Python就写dataclass或者TypedDict如果是 Go就写struct。类型定义的好处是它是可执行的契约。AI 在写代码的时候如果字段名对不上类型检查会直接报错不用等到联调才发现。而且类型定义本身就是一种强约束AI 看到类型定义就知道自己必须按这个来不会自由发挥。我现在的习惯是项目一开始先花十分钟让 AI 把所有核心数据结构用类型定义写出来存成一个文件。后面每个子会话都把这个文件贴进去当上下文。实测下来拼装时的字段不匹配问题基本消失了。2.3 契约变更了怎么办项目做到一半需求变了契约要改这是常事。这时候最忌讳的是只改一个会话其他会话不管。契约是全局的改一处就得同步所有相关会话。我的做法是契约变更必须回到架构会话里改。也就是专门维护契约的那个会话改完之后生成新的契约文档然后通知所有受影响的子会话更新。如果子会话已经产出了代码就把新契约贴进去让它按新契约调整。这个过程听起来麻烦但比各改各的、最后拼不起来要省事得多。而且契约变更的频率通常不高大部分时间契约是稳定的。3. 会话之间的信息传递怎么让子任务接得上分工之后最大的挑战是信息怎么在会话之间传递。你不能指望每个子会话都自动知道其他会话干了什么必须主动把必要的信息喂给它。喂多了浪费上下文喂少了它接不上这个度得把握好。3.1 每个子会话应该带哪些行李我给每个子会话准备的行李通常包括三样第一样是契约文档前面说过这是必须的。第二样是上游产出的关键代码比如后端会话要对接数据库那就把数据库的 schema 定义贴进去前端会话要调接口那就把接口的类型定义贴进去。第三样是本任务的具体要求用一段话说清楚这个会话要干什么、输入是什么、输出是什么、有什么约束。注意不要把所有上游代码都贴进去。比如前端会话不需要知道后端的具体实现逻辑它只需要知道接口的输入输出格式。贴多了反而干扰。我一般会控制每个子会话的初始上下文在两千字以内。超过这个量AI 的注意力就开始分散了。如果确实需要更多背景就拆成多轮对话第一轮先建立背景认知第二轮再干活。3.2 用任务简报代替长篇大论与其写一大段背景介绍不如写一份任务简报。任务简报的格式我一般是这样任务实现用户登录接口 输入用户名、密码 输出成功返回 token失败返回错误码 依赖用户表 schema见附件 约束密码必须加密存储token 有效期 24 小时 验收标准能用正确的用户名密码登录成功错误密码返回 401这种格式的好处是信息密度高、没有废话。AI 一看就知道自己要干什么不用在背景描述里找重点。而且这种格式强迫你自己先想清楚任务边界避免让 AI 自己理解的偷懒做法。3.3 会话产出的交付物怎么整理每个子会话干完活会产出一堆代码。这些代码不能直接扔到项目里得先整理。我一般会让 AI 在产出代码的同时附上一段简短的说明这个文件是干什么的、放在哪个目录、依赖哪些其他文件。然后我会把这些交付物按目录结构归位。如果发现某个文件跟契约对不上就回到对应的会话里让它改而不是自己手动改。手动改容易引入新问题而且下次 AI 再生成的时候又会覆盖掉。注意不要让 AI 直接操作你的项目文件系统除非你用的是有文件操作能力的工具。大部分情况下让 AI 输出代码文本你自己复制粘贴到对应位置更可控。4. 实战拆解一个全栈小项目的分工全过程光讲理论没意思我拿一个真实做过的小项目来拆解。项目很简单一个待办事项管理工具有前端页面、后端接口、数据库。麻雀虽小五脏俱全正好用来演示分工。4.1 第一步架构会话定契约我开的第一个会话是架构会话。我给它的任务是根据需求设计数据库表结构、定义后端接口、定义前端调用的类型。这个会话的产出是一份契约文档包含数据库表todos的字段id、title、completed、created_at后端接口GET /todos返回列表POST /todos创建PATCH /todos/:id更新DELETE /todos/:id删除前端类型Todo接口定义字段名跟数据库保持一致这份文档我保存成contract.md后面每个会话都带上它。4.2 第二步后端会话写接口第二个会话是后端会话。我把契约文档贴进去然后说按这个契约用 Node.js Express 实现所有接口数据先存在内存里不用接真实数据库。这个会话的上下文很干净只有契约和任务要求。它不需要知道前端长什么样也不需要知道数据库怎么连。产出的代码就是几个路由处理函数结构清晰字段名跟契约完全一致。4.3 第三步前端会话写页面第三个会话是前端会话。同样贴契约文档然后说按这个契约用 React 写一个待办列表页面能增删改查调用后端接口。这个会话也不需要知道后端怎么实现的它只需要知道接口的 URL 和数据结构。产出的代码就是几个组件调用的字段名跟契约一致跟后端能对上。4.4 第四步验证会话写测试第四个会话是验证会话。我把契约文档和后端代码贴进去说给这些接口写单元测试覆盖正常流程和边界情况。这个会话的产出是测试文件。跑一遍发现两个问题一个是删除不存在的 id 时返回了 500 而不是 404一个是创建时没校验 title 是否为空。我把这两个问题反馈给后端会话它很快就修好了。4.5 分工带来的实际收益这个项目如果用一个会话做我估计要来回折腾两三个小时而且中间肯定会出现字段对不上、逻辑冲突的问题。拆成四个会话之后每个会话都是十几分钟搞定总耗时不到一小时而且拼装的时候几乎没出问题。更重要的是每个会话的产出质量都更高。因为上下文干净AI 不用在无关信息里分心写出来的代码更聚焦、更符合要求。后端会话不会去操心前端样式前端会话不会去纠结数据库索引各司其职。5. 分工模式下的常见翻车场景与应对分工不是银弹用不好照样翻车。我总结了几个最常见的翻车场景以及对应的应对办法。5.1 契约漂移说着说着就变了最常见的翻车是契约漂移。比如后端会话写着写着觉得某个字段名不好自己改了一个前端会话不知道还按老的写。最后拼装时对不上。应对办法是在任务简报里明确写死不得修改契约。如果确实需要改必须回到架构会话改改完同步所有会话。我一般会在每个子会话的开头加一句严格遵守契约文档不得自行修改字段名和接口格式。5.2 上下文污染贴了不该贴的东西第二个常见问题是上下文污染。比如前端会话里我顺手把后端的实现代码也贴进去了结果 AI 开始参考后端的实现细节写出了一些不该它操心的东西。应对办法是只贴必要信息。前端会话只需要接口的类型定义不需要后端的实现逻辑。贴之前问自己一句这个信息对这个任务真的必要吗不必要就不贴。5.3 会话失忆聊太久忘了前面第三个问题是会话失忆。一个子会话如果聊得太久轮次太多它也会开始忘前面。比如写测试的会话写到第十个测试用例的时候已经忘了第一个用例的约定。应对办法是控制单个会话的轮次。我一般会把一个子任务控制在十轮对话以内。如果超过十轮还没搞定说明这个任务拆得还不够细应该再拆一层。或者把已经完成的部分固化下来开一个新会话继续。5.4 拼装冲突两个会话改了同一个文件第四个问题是拼装冲突。两个子会话可能都产出了对同一个文件的修改拼装的时候冲突了。应对办法是在契约里明确文件归属。哪个文件由哪个会话负责提前说清楚。如果确实有共享文件就把它放到架构会话里统一维护子会话只读不写。6. 把分工变成习惯我的日常工作流讲了这么多最后说说我现在的日常工作流你可以直接参考。6.1 项目启动先开架构会话任何项目不管大小我都先开一个架构会话。任务很简单根据需求产出契约文档。这个会话通常只聊两三