AI Coding 系列（三）：把复杂需求拆成 AI 能可靠完成的小任务
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 订单抛出 DomainError；
- PENDING 订单继续执行既有流程；
- 新增至少两条单元测试；
- npm test 与 npm run lint 均通过。
请先复述方案与风险，确认后再输出 diff。
这张卡把“期待”变成了可检查的合同。AI 给出的代码不再只是看起来合理，而是可以逐项验收。
四、优先拆边界，再拆实现
复杂需求里最容易出错的往往不是正常流程，而是边界条件。任务拆解时，先问这些问题：
• 操作能否重复执行？重复时返回什么？
• 并发请求会不会产生竞争？
• 外部服务失败后，系统状态如何恢复？
• 是否涉及权限、金额、隐私或审计？
• 旧客户端会不会受到接口变更影响？
把这些问题先变成测试场景，再倒推实现任务。这样 AI 生成的代码会被风险边界约束，而不是只沿着“happy path”一路向前。
五、一个实战节奏：先计划、再实现、后验证
推荐的执行循环如下：
第一轮：让 AI 只输出任务拆解与依赖关系。
第二轮：选择一个最小任务，让 AI 给出修改计划和风险。
第三轮：让 AI 实现该任务，并限定文件范围。
第四轮：运行构建、测试、类型检查和 lint。
第五轮：将真实报错、测试结果和 diff 交给 AI 做修正。
第六轮：人工 review，确认后再进入下一个任务。
这个过程看上去比“一次生成全部代码”多了几步，但返工显著更少。尤其是在陌生代码库、多人协作和高风险业务中，它更接近可靠的软件工程。
六、什么时候不该继续拆
拆分不是越细越好。如果两个改动共享同一个不变量、必须原子地提交，或者拆开会掩盖真实的事务边界，就应把它们作为一个整体处理。
例如“创建订单并扣减库存”可能需要同一个一致性策略；只分别生成两个孤立函数，并不能保证系统正确。此时 AI 的任务应该是先分析一致性方案和失败补偿，而不是立即编码。
结语
AI Coding 的效率来自清晰的并行与反馈，而不是一次性把所有工作外包出去。把复杂需求拆成目标单一、输入明确、输出可检查、影响可控的小任务，你就能让 AI 更稳定地贡献代码，也让自己始终掌握系统的方向。
下一篇将讨论代码审查：面对 AI 生成的改动，开发者应该重点检查什么，才能既快又不放过真正的风险。