AI Coding 之后，任务能不能拆，上下文说了算

上一篇说，AI Coding 改变了团队分工的成本结构，分工标准也得跟着变。很多人看完说，道理听起来对，但实操起来不知道从哪里下手，这块业务到底能不能独立出去，怎么判断？这篇把判断方法讲具体。

判断标准：上下文是否完整

我的起手动作只有两个问题：这个功能是否需要在同一个上下文中完成？如果拆分到多个业务域，是否反而会增加沟通成本和对齐的成本？

上一篇提到的点赞反馈功能满足这两点，整条链路自己成立，负责的人不需要了解主流程，拿到任务自己驱动 AI 推完。

Memory 模块不一样。怎么根据对话和业务系统的信息构建 Memory、怎么存储、怎么检索，这一层边界清晰，完全可以由一个人长期负责。难拆的是另一件事，召回的内容怎么加载进上下文，放在哪个位置，和系统提示词、工具调用结果怎么排布，token 预算怎么分，这些决策属于上下文工程，必须跟主流程一起设计。把这部分也一起分出去，对方做完接回来大概率要重写。

区别在于数据所有权和决策权有没有落在这个域内——Memory 接入主流程的部分，输入来自主流程的内部状态，决策权也在主流程那边。

DDD 里的限界上下文管的就是这个约束：人脑能处理的上下文有限，AI 的上下文窗口也有限，领域划分一直是在管这个约束。AI 做的事是把这个约束从软的（人的注意力）变成了硬的（context window），让你没法再绕过去。建模做得越扎实，「这块能不能分出去」这个决策就越清楚，不需要靠感觉判断。

随着系统演变、流程变复杂，Memory 模块本身也可能再往下拆，但判断的原则不变，边界在不在，决策权落在不落在这个域内。

分工逻辑变了的两个原因

以前子域级已经是分工的基本单位，但碰到代码量大、实现复杂的子域，还会再往下拆一层：谁写哪几个 API，谁负责哪个页面，靠人手并行来压时间。AI 之后这层细拆不再必要，原因有两个。

第一，子域拆碎了，上下文就断了。 一个人开着 AI，代码产出速度已经不是问题。真正稀缺的是对这个子域的完整理解，业务逻辑、设计决策、各模块之间的关系。把子域拆碎分给多人，每个人只拿到一块，反而做不快。

第二，编程语言的门槛基本消失了，前后端的职责边界不再成立。 以前前端写页面、后端写接口是因为两边的技术栈差距很大，跨栈的成本高。AI 把这个门槛抹平了，后端工程师可以直接写前端，前端工程师可以直接写 API，一个人从按钮到数据库端到端推下去，不比前后端分工慢，还省掉了联调和对接的来回。按技术层拆人，是在制造不必要的协调成本。

子域就是现在合理的分工粒度。负责这块的人拿到完整的业务域，自己驱动 AI 深耕，沟通只发生在子域边界上，不是每一个接口上。

Conway’s Law 说的就是这件事，《人月神话》里提到的那条：系统架构会和团队结构趋同，按技术层分人，架构就会沿技术层割裂；按子域分人，代码边界和团队边界才能对齐。

OpenClaw 创始人 Peter Steinberger 说过：大多数代码不过是把数据从一种形状变成另一种形状。他发布大量自己没有逐行读过的代码，那些管道工活交给 AI。他始终要看的一层是架构，模块间怎么通信、数据在哪里转手。

边界不清楚时怎么处理

不是所有地方边界都一目了然，有时候一个功能看起来独立，实现时发现依赖了主流程的内部状态，拿出来就缺东西。判断方法是：这个依赖能不能通过接口传进来？能，那边界还在，把接口定义清楚就行。不能——也就是对方必须理解主流程才能用这个依赖，接口传不了这层语义——那这块就不适合独立出去。

另一种情况是边界本身会变。早期划定的子域，随着功能迭代，可能开始和其他域耦合。这时候重新梳理一次边界成本不小，但不做越往后越难分。

这两种情况，主流程最集中。上下文工程、工具编排、错误处理逻辑全部缠在一起，任何一段拿出来单独看都不完整，「能不能通过接口传进来」的判断也往往在这里失效。主流程本身也是一个域，可以叫编排域——它负责调度和协调，有自己的边界，只是内部还没到拆的时机。当某个环节复杂到足够程度，就会像 Memory 那样，从主流程里独立出去，成为自己的子域。判断的原则还是那一套，只是时机的问题。

AI Coding 对软件开发流程的冲击还在展开，分工方式、协作节奏、工程师的角色，很多组织和人都还在摸索。这两篇记录的是我现在的理解，也许未来几周、几个月就会有新的认识。

如果你在用 AI 做项目，主流程这块有没有找到更好的分法，欢迎留言聊。