复杂需求的分治策略

什么时候需要分治

上一课讲的三层模型对中等复杂度的任务已经够用了。但总有些需求，一上来就让人犯怵：

“从零搭建一个带用户系统、支付、订单管理的电商后台”

这种级别的需求，你坐下来试着用三层模型拆一次就会发现——光是「步骤层」就能列出几十条，每一条本身又是一个中型任务。单次拆解不够用了，你需要把三层模型递归地用下去。

这其实就是算法里经典的分治思想：大问题拆成小问题，小问题各个击破。

拿电商后台这个需求来说，我通常会做三轮拆解。

第一轮是按模块拆，把大系统拆成功能相对独立的模块：

电商后台
├── 用户系统（注册、登录、权限）
├── 商品管理（CRUD、分类、搜索）
├── 订单系统（创建、支付、状态流转）
└── 基础设施（数据库、认证中间件、错误处理）

第二轮是模块内部再拆。每个模块各自套用三层模型：定目标、列步骤、想验证方式。比如「用户系统」又可以拆成注册流程、登录流程、权限管理三个子任务，每个子任务都是一次独立的 Claude Code 对话。

第三轮是确定执行顺序。模块之间有依赖关系，不能随便挑一个就开始做。在这个例子里，合理的顺序是：基础设施 → 用户系统 → 商品管理 → 订单系统。后面的模块依赖前面的，反过来做会不断返工。

做过几次大型项目拆解后，我总结了几条经验。

第一，基础设施永远放第一位。数据库连接、错误处理、认证中间件——这些东西不起眼，但它们是所有业务模块的地基。我见过不少人急着写业务逻辑，后面补基础设施时发现跟已有代码冲突，改得焦头烂额。先花半天把地基打好，后面会顺畅很多。

第二，先跑通最小路径，再补全功能。不要上来就把用户系统的每个功能都做完再去做商品管理。更好的做法是先跑通「注册 → 登录 → 创建商品 → 下单」这条最小路径，证明各模块之间能跑通，然后再回头补全每个模块的细节功能。这样做的好处是你能尽早发现模块间的集成问题，而不是等到最后才踩雷。

第三，模块之间要用接口隔离。定义清楚模块间的调用接口——入参是什么、返回值是什么、错误怎么处理。接口定好了，每个模块的内部实现可以独立迭代，改一个不会影响另一个。

在开始编码之前，我习惯先让 Claude Code 帮我画一张模块间的依赖关系图。花不了十分钟，但能帮你看清楚哪些模块有隐含的依赖、执行顺序是否合理。这点小投入经常能避免后面几小时的返工。