AI Coding 系列三把复杂需求拆成 AI 能可靠完成的小任务前两篇我们建立了协作方式也准备了项目上下文。接下来进入最影响交付质量的一步任务拆解。许多“AI 写得不对”的问题根源并不是模型能力不够而是任务同时包含了需求理解、架构设计、数据迁移、接口实现、异常处理与测试。把这些混在一句提示里任何协作者都很难稳定完成。一、什么是适合 AI 的最小任务一个适合交给 AI 的任务应该同时满足四个条件目标单一。一次只解决一个可描述的问题例如“为现有接口补充分页参数校验”而不是“把列表页体验整体优化掉”。输入清楚。AI 知道要读哪些文件、数据结构是什么、哪些约束不可触碰。输出可检查。你能明确判断它是否完成例如新增一个函数、修改一个接口、补齐三类测试。影响可控。任务失败时改动范围小、容易回滚不会连带破坏多个系统。可以用一句话测试任务是否足够小如果你无法在五分钟内向新同事讲清目标与验收它多半还没有拆好。二、从业务需求到任务清单假设需求是“用户可以取消待支付订单取消后释放库存并记录审计日志。”不要直接把整句话交给 AI。先将它拆成可验证的工作项任务 A确认订单状态定义和现有状态迁移规则。任务 B设计取消订单的接口契约包括请求、响应与错误码。任务 C在订单服务中实现“仅待支付状态可取消”的核心逻辑。任务 D调用库存服务释放预占库存并定义失败策略。任务 E写入审计日志。任务 F覆盖成功、状态不允许、订单不存在、库存调用失败等测试。任务 G更新接口文档与变更说明。每一项都可以独立讨论、实现和验证。更重要的是你能优先处理风险最高的部分例如先确认库存释放到底是同步调用、消息队列还是补偿任务。三、把每个任务写成“可验收卡片”每次请 AI 协作前建议准备一张任务卡任务为 cancelOrder 增加状态校验。背景订单状态由 OrderStatus 枚举定义取消仅允许 PENDING。允许修改order.service.ts、order.service.spec.ts。禁止修改数据库表、公共 DTO、库存模块。完成标准非 PENDING 订单抛出 DomainErrorPENDING 订单继续执行既有流程新增至少两条单元测试npm test 与 npm run lint 均通过。请先复述方案与风险确认后再输出 diff。这张卡把“期待”变成了可检查的合同。AI 给出的代码不再只是看起来合理而是可以逐项验收。四、优先拆边界再拆实现复杂需求里最容易出错的往往不是正常流程而是边界条件。任务拆解时先问这些问题• 操作能否重复执行重复时返回什么• 并发请求会不会产生竞争• 外部服务失败后系统状态如何恢复• 是否涉及权限、金额、隐私或审计• 旧客户端会不会受到接口变更影响把这些问题先变成测试场景再倒推实现任务。这样 AI 生成的代码会被风险边界约束而不是只沿着“happy path”一路向前。五、一个实战节奏先计划、再实现、后验证推荐的执行循环如下第一轮让 AI 只输出任务拆解与依赖关系。第二轮选择一个最小任务让 AI 给出修改计划和风险。第三轮让 AI 实现该任务并限定文件范围。第四轮运行构建、测试、类型检查和 lint。第五轮将真实报错、测试结果和 diff 交给 AI 做修正。第六轮人工 review确认后再进入下一个任务。这个过程看上去比“一次生成全部代码”多了几步但返工显著更少。尤其是在陌生代码库、多人协作和高风险业务中它更接近可靠的软件工程。六、什么时候不该继续拆拆分不是越细越好。如果两个改动共享同一个不变量、必须原子地提交或者拆开会掩盖真实的事务边界就应把它们作为一个整体处理。例如“创建订单并扣减库存”可能需要同一个一致性策略只分别生成两个孤立函数并不能保证系统正确。此时 AI 的任务应该是先分析一致性方案和失败补偿而不是立即编码。结语AI Coding 的效率来自清晰的并行与反馈而不是一次性把所有工作外包出去。把复杂需求拆成目标单一、输入明确、输出可检查、影响可控的小任务你就能让 AI 更稳定地贡献代码也让自己始终掌握系统的方向。下一篇将讨论代码审查面对 AI 生成的改动开发者应该重点检查什么才能既快又不放过真正的风险。