一、实现速度快，不等于交付速度快#

没有任务拆分时，开发过程很容易被局部细节牵着走。

一个参数校验还没想清楚，就开始优化数据库访问；主流程还没有验证，就先抽象一个未来可能复用的组件；发现另一个模块也有问题，又顺手扩大修改范围。每个动作看起来都有价值，但都不一定服务于当前交付。

AI 辅助开发会放大这个问题。只输入一句「帮我实现这个功能」，AI 可能一次生成接口、数据模型、异常处理和测试。内容看起来很完整，却可能包含不存在的需求、未经确认的假设和超出范围的修改。

交付速度应该从「确认需求」算到「验证通过」。自顶向下拆任务，就是先把这条路画出来，再决定每一步写什么。

二、先确定终点，再拆实现步骤#

拆任务首先要确认最终要交付什么，暂时不用急着设计类和方法。

以「给现有申请流程增加一项校验」为例，开始前至少需要明确：

• 哪个入口需要这项校验？
• 校验失败时，用户应该看到什么结果？
• 历史数据和另一个入口是否受影响？
• 本次明确不修改哪些行为？

这些问题构成验收边界。边界不清楚时，不急着让 AI 或自己生成实现。

接下来，把目标拆成一条可以验证的主流程：

1. 接收并检查请求参数。
2. 读取校验所需的数据。
3. 执行业务规则。
4. 保存结果或返回错误。
5. 验证正常流程和异常流程。

到这里才需要空方法。空方法用来固定主流程，让每一步都有明确输入、输出和完成条件。实现某一步时，暂时不被其他步骤的细节干扰。

三、临时想法进 TODO，不立即扩大范围#

开发过程中总会冒出新想法：这里可以优化，那里可以抽象，另一个接口似乎也应该一起修改。

这些想法不一定没有价值，但出现的时间未必合适。立即处理，会不断切换上下文，也会让本次修改越来越难以验证。

更稳妥的方式是先把它们写进 TODO，并简单注明原因。完成当前主流程后，再逐项判断：

• 不处理会不会影响本次验收？
• 属于当前需求，还是另一项独立改进？
• 如果现在处理，需要新增哪些测试和回归范围？

AI 也会不断提出类似建议，比如引入新的设计模式、增加一层抽象，或者顺带重构相关代码。对这些建议同样先放入 TODO，别因为 AI 给出了一段完整实现，就直接扩大交付范围。

TODO 用来保护当前最重要的工作，避免它淹没在新增想法里。

四、小步实现，让每一步都有反馈#

主流程确定后，再按最小可验证步骤推进。

可以先完成数据模型及对应测试，再连接接口和业务逻辑，随后检查返回结构，最后验证完整流程。每一步只处理一个主要问题，并尽早得到测试、运行结果或代码 Review 的反馈。

「小步」强调每一步都能回答：刚刚完成了什么，如何证明它没有破坏已有行为。提交是否够小，也应该用这一点判断。

如果某一步需要同时修改多个模块、补大量代码，甚至只能靠完整上线后才能验证，通常说明任务还需要继续拆分。

五、用 AI 开发时，把任务拆分写进提问#

AI 很适合承担局部实现，但前提是我们能清楚描述当前步骤。给 AI 的信息不应只有一句需求描述，还应包括目标、边界和验收方式。

一个实用的提问框架是：

1
目标：本次要改变什么行为？
2
已知事实：哪些代码、文档或运行结果已经确认？
3
边界：哪些文件、入口和行为不在本次范围内？
4
当前步骤：现在只完成哪一步？
5
验收条件：需要运行哪些测试，检查哪些结果？

这套框架既是给 AI 的上下文，也是给自己的开发约束。

当 AI 返回实现后，先检查它是否引入了未经确认的概念，是否修改了边界外的代码，是否满足验收条件。当前步骤验证通过后，再进入下一步，别一次性接受整个功能的所有改动。

使用 AI 时，可以按这个方式分工：AI 加速实现、补充反例和检查遗漏；工程师确认目标、安排顺序、控制范围，并对验证结果负责。

六、主流程可以边做边调整#

拆任务不意味着在开发前预测所有细节，也不等于用大量文档延迟实现。

一开始只需要画出主流程和验收边界。开发中获得新证据后，可以调整后续步骤，但调整仍然要回到整体目标，别让临时发现牵着走。

日常开发时，可以用五个问题检查自己的进度：

1. 最终要交付的结果是什么？
2. 主流程可以拆成哪几个可验证步骤？
3. 当前只做哪一步？
4. 哪些新想法应该先进入 TODO？
5. 用什么证据确认这一步已经完成？

无论由人写代码，还是由 AI 生成代码，这些问题都不会消失。

AI 时代更需要开发规划，主要因为实现变得太快。先想清楚要去哪里，才能用生成速度缩短交付时间。