用了 AI Coding，我反而不知道该怎么分任务了

AI Coding 把技术调研的时间压到了一两天，但任务怎么分这件事，反而比以前难。新的 Agent 项目，我两个下午用 Claude Code 把技术方案写到了能直接落地的程度，接下来就开始想：团队怎么分工，才能把这个速度维持住。

AI 把单人执行效率拉上去了，但分工方式如果没跟着变，提速很快到天花板。两条路都踩过：按老方法把任务分出去，结果同事光熟悉背景就花了两三天，对齐成本吃掉了并行的收益；反过来所有模块自己开着 AI 推，效率高是高，但一个人的时间还是有限的，很快成了整个项目的瓶颈。

传统拆任务为什么失效了

过去拆任务有一套说得通的逻辑：一个人写两周的东西，四个人写三天，就算加上一天对齐，也值得。并行执行摊薄了对齐的成本。这套逻辑的底层是《人月神话》里的 Brooks 定律，人手可以并行，总时间可以压缩。AI 之后，这个定律本身没变，但前提失效了。

我把技术方案分给同事，他要读懂背景、确认边界、把设计意图装进脑子，再开始写，这套流程要两三天。同一份方案我自己开着 Claude Code 推下去，半天到一天。AI 不需要读懂背景，对话上下文就在那里，没有来回对齐这道工序。算下来，对齐的开销比写代码本身还大，分出去反而慢。

慢，是因为知识传递这道工序变了。以前必须从一个人脑子传到另一个人脑子，这道工序本来就存在，只是成本可以接受。现在 AI 原生持有上下文，设计意图就在会话里，知识传递这道工序直接消失了。差距换了性质，不只是变大了。

换个角度算成本：给 AI 喂上下文和让同事熟悉项目背景，初始开销差不多。差别在于 AI 的上下文留在会话里，不需要重复传，同事每次接手都得重新装。

有一种情况例外：这个领域需要持续深耕，这时候反而要尽早让人参与，由他长期负责这个域，越晚介入背景越难补。Agent 项目里，Memory 就是这样处理的，单独安排了一个同事长期跟进，从存储到抽取逻辑，他自己驱动 AI 深入研究。

什么时候还值得分给人

我现在的标准：这个任务能不能形成业务闭环，能闭环的可以分。一个人从前端按钮到 API、到数据库、到后台管理页面，端到端自己做完。不需要跟我反复对齐，不需要我中途接手某一段，他掌握整块的上下文，遇到问题自己判断。

Agent 项目里的点赞加反馈功能就是这样分出去的。前端加两个按钮，后端写收集接口，DB 加张表，后台能看能导出。这块功能不依赖主流程的内部状态，做完就做完了。接到这种任务的同事，自己开着 AI 推，效率不会被我拖慢。

Skills 也一样，每个 Skill 边界清晰、接口独立，不需要了解主流程怎么跑，几个完全可以并行开发，互不干扰。

能不能闭环，根本上取决于子域边界清不清、是不是真的独立自洽。DDD 里的限界上下文讲的就是这件事，每个域管好自己的上下文，外部只通过接口进来。这不是 AI Coding 带来的新需求，人脑能处理的上下文一直有限，AI 只是把这个约束变得更硬了。建模做得越扎实，分工就越清楚。

领域建模做扎实之后，分工的粒度也跟着变了。以前拆任务能细到接口级，谁写哪个 API，谁负责哪个页面；往后，粒度主要在子域这一级：这块业务归谁，端到端。

什么情况下不能拆

Memory 的写入和读取接口比较清晰，可以包装成独立服务，由人长期负责这个域完全成立。难拆的是 Memory 怎么集成进整体的上下文工程里。召回回来的内容放在上下文的哪个位置，和系统提示词、工具调用结果、当前对话怎么排布，token 预算怎么分配，这些不是 Memory 模块自己能决定的，必须跟整体的上下文架构一起设计。

把这一块拆出去，对方做出来接回来大概率得重写。按模块划分不等于按任务划分，这是我踩的一个坑。

判断一个任务能不能拆，问一个问题就够了：它需不需要理解主流程的内部状态？需要，拆出去大概率要反复对齐，做完接回来还得重写。

判断的关键只有一个：这块业务能不能形成闭环，有没有人可以长期负责这个域。能闭环的早让人进来，由他驱动 AI 深耕；不能闭环、跟主流程深度绑定的，需要找一个主要同学长期跟进，把这个域吃透，而不是分出去转一圈再接回来。

如果你有过类似的情况，欢迎留言聊聊你的做法。觉得值得继续看，点个关注。