任务拆解：把大需求切成 Agent 能稳跑的小块
系列入口：如何使用 Agent。拆好之后怎么让它先出方案，看 Plan 模式深挖。
一、为什么 Agent 在「大需求」上容易翻
给 Agent 一句「帮我做个用户系统」，它大概率会翻车——不是能力不够，而是这个任务里塞了太多东西：数据模型、注册登录、密码加密、接口、校验、前端页面、错误处理……一次性丢给它，它要么改动一大片难以审查，要么在某个细节上想当然，错误还会顺着后续步骤不断累积。
人做这种需求也不会上来就写，而是先拆。差别在于：Agent 尤其依赖你替它把任务切到合适的粒度。切得好，每一步都小到容易做对、做错也容易发现；切不好，就只能在一堆改动里碰运气。
二、拆解的四条原则
1. 按「可验证的结果」切，而不是按动作切。 一个好任务的产出是能被检验的东西，比如「建好 users 表，字段和迁移脚本完成」，而不是「去看看数据库怎么设计」。有了可验证的结果，你才知道这一步到底做没做完。
2. 每步只解决一个问题。 一个任务既改数据结构又写接口又调样式，就太大了。单一目标让 Agent 的注意力集中，也让你容易定位问题出在哪。
3. 给每步划清边界。 明确「这一步只许动哪些文件、不要碰什么」。边界清楚，它才不会为了解决一个小问题顺手重构半层楼。
4. 顺序按依赖排，先打地基。 先做被别人依赖的部分（数据模型 → 接口 → 界面），让每一步都站在上一步已验证的基础上，而不是并行铺开一堆半成品。
为什么这四条对 Agent 比对人更关键？因为人在执行大任务时会下意识地自我纠偏：写到一半发现假设错了会停下来、看到相邻代码不对劲会调整、对模糊处会主动回来跟你确认。而 Agent 在一个任务里，倾向于把接到的目标一路推进到完成，它不会天然替你「抬头看路」，也可能在你没要求的地方不回头。任务越大、步骤越多，中途偏离或想当然的空间就越大，而且早期的一个错误假设会顺着后续步骤不断被放大。
把任务切到合适粒度，本质上是你在替循环设置「检查点」：每完成一个可验证的小步，都强制回到现实——跑测试、看结果、由你确认，然后才允许它带着正确的基础进入下一步。这样错误还没来得及累积就会被截住。可以把它理解成给一个特别能干、但容易埋头猛冲的执行者设定的节奏：不是不让它跑，而是让它每跑完一小段就回到你这里对一次表。理解了这一层，你就明白拆解不是给 Agent「降低难度」，而是在为可靠地交付设置结构。
三、粒度：多小才算合适
粒度是这事儿的核心，太大失控、太碎又啰嗦。两个可操作的判断口径：
- 看 diff 的体量：一个任务产生的改动应该能让你在几分钟内读完并看懂。一眼看不过来，就是大了。
- 看你能不能一句话说出它的验收标准。说不清楚「怎样算做完」，说明这一步还该继续拆。
以「用户系统」为例，一种合适的切法：
| 步骤 | 任务 | 验收标准 |
|---|---|---|
| 1 | 定义 users 表结构 + 写迁移 | 迁移能执行，字段/类型/约束符合约定 |
| 2 | 实现注册接口（含密码哈希） | 能注册成功；明文密码不入库 |
| 3 | 实现登录 + 签发会话 | 正确账密通过，错误被拒 |
| 4 | 加入参数校验与错误返回 | 非法输入返回明确错误，不崩溃 |
| 5 | 接上前端注册/登录页面 | 页面走通完整流程 |
每一步都小到 Agent 容易做对，又各自有明确的完成判据。
关于粒度，再给你几个「过大 / 合适」的直接对照，帮你校准手感：
- 「重构支付模块」——过大：既说不清改完什么样，diff 也没法一次读完；合适的切法是先「梳理支付模块当前的调用关系并产出说明」，再「把其中下单逻辑单独抽成服务且行为不变」，分步推进。
- 「优化这段代码」——过大且模糊：优化什么、为了性能还是可读性？合适：「在不改变接口和行为的前提下，把这个超过两百行的函数拆成若干单一职责的小函数，并补测试锁定行为」。
- 「给这个接口加缓存」——接近合适，但还差验收；补上「命中缓存时不查库、数据更新后缓存失效、命中率可观测」，它才是一个边界清晰、可验证的任务。
还要避免另一个方向的误区：拆得过碎同样有害。 比如把「写一个函数」拆成「先写函数签名、再写第一行、再写第二行」，这会让你自己淹没在大量审批和切换里，Agent 的自主能力完全没发挥，比手写还累。合适的粒度不是「越小越安全」，而是「大到能产出一个可独立验证的结果、小到你能一次读完 diff」。一个粗略的经验区间：一个子任务让它跑两到五轮、产出你三到五分钟能审完的改动，往往就是甜区；复杂任务可以略大，但仍要保证每步能独立验证。
四、每步都把验收标准说在前面
新手常犯的错，是任务派出去了却没说「什么算完成」，等 Agent 说做好了才发现双方标准不一样。正确做法是下任务时就带上验收条件：
- 「实现注册接口，要求：密码用 bcrypt 哈希、邮箱重复时返回 409、补上对应单元测试。」
这样 Agent 有明确靶子，你验收时也有据可依，而不是凭感觉。验收条件不必复杂，能客观判断过/不过就好——能跑通某个命令、测试通过、某个输入给出某个结果。
你可以用一个很简单的「完成定义」句式来写每个子任务，长期用会变成直觉：
在【某范围 / 只动某些文件】内，实现【具体能力】，使得【可运行的验证，如某测试通过、某输入得某结果】；同时明确【不要做什么】。
例如：「在 auth 模块内实现注册接口，使得正常邮箱可注册、重复邮箱返回 409、且新增单测全部通过；本步不做登录、不改公共中间件。」一句话里同时包含了范围、目标、验收和边界，Agent 几乎没有自由发挥到失控的空间。
为什么要把「不要做什么」也写进去？因为 Agent 常出于「热心」而越界——为了让这一步更完整，顺手重构相邻代码、升级依赖、改动无关文件。明确点出「本步不做 X」，比事后发现越界再回退便宜得多。尤其在它能力很强、又特别愿意「多做一点」的时候，清晰的负面清单反而是对它最好的引导。
五、拆不动时，先让 Agent 帮你探路
如果你对代码库不熟、自己都不知道从哪拆起，不用硬拆。可以先给 Agent 一个只读的调研任务（配合 Plan 模式）：「先别动代码，搞清楚要实现 X 需要改哪些地方、分几步，给我一个方案。」
它调研后给出的分解，你审一遍、调整粒度，再按确认后的顺序一步步执行。拆解本身也可以和 Agent 协作完成，但粒度的拍板权在你。
六、一个完整的拆解实战：从一句话到可执行清单
光看原则还不够，跟着一个更贴近日常的需求走一遍，看拆解是怎么逐层落地的。这次的原始需求来自产品同学，只有一句话：「我们那个导出报表的功能，数据一多就经常转圈转到超时，你想办法弄弄。」
注意这是一个典型的「又模糊又真实」的需求：没有说清多少算「多」、超时是前端还是后端、期望快到什么程度。直接把这句丢给 Agent 让它「优化」，它很可能乱猜方向。所以第一步不是拆实现，而是先派一个只读调研任务：
- 调研（只读）：让 Agent 搞清楚导出功能现在的完整链路——数据从哪查、怎么组装、是同步返回还是异步、超时发生在哪一层、现在大概多大数据量会触发。产出一份现状说明，不改代码。
拿到调研结果后，问题才真正显形：原来导出是同步接口，一次性把全部记录查进内存、在请求里拼装，数据量过万后接口耗时超过网关的 30 秒超时，而且内存占用也危险。到这一步，真实问题从「转圈」收敛成了「同步全量导出不适合大数据量」。然后才是把解决方案拆成可验证的小步：
- 定契约：把导出改成异步任务模式——接口立即返回一个任务 ID，后台生成文件，前端轮询状态。先只确定接口契约和状态定义，验收是契约文档和相关类型/校验就位。
- 后台生成：实现后台分页查询 + 逐批写文件，不再一次性载入全量。验收是大数据量下内存平稳、文件内容正确、有测试。
- 状态与查询：实现任务状态存储和查询接口（排队 / 处理中 / 完成 / 失败）。验收是状态流转正确、失败可被标记和重试。
- 前端改造：把原来点击后干等改成提交任务、轮询、完成后给下载链接。验收是完整流程走通、超时不再发生。
- 兜底与观测：加任务过期清理、失败提示和基本的耗时/失败监控。验收是相关用例通过、异常路径有明确反馈。
你看这个实战里有几个关键点：先调研把模糊需求变成明确问题，再拆实现；每一步都只解决一个问题、产出可验证结果、边界清楚；顺序上先定契约再分头落地，避免前后端互相等待。 如果一开始不调研直接让它「加个缓存试试」或「优化 SQL」，很可能根本没解决「同步全量」这个真正的病根。
这也回应了一个常见疑问：拆解不只是把一个已经清楚的大任务切碎，它的前半段往往是帮你把不清楚的问题搞清楚。对真实工作中大量含糊的需求，这个「先只读探路、再分解落地」的两段式做法，比一上来就要一份完美拆解更实用。最后仍然强调：调研和初步分解可以交给 Agent，但「问题定义对不对、粒度合不合适、验收标准是否抓住了真正诉求」，要由你拍板。
七、拆解里最常见的几种错误
把新手在拆解阶段的高频错误集中点出来，对照避免：
- 按技术分层硬切，而不看依赖。 比如先让它写前端页面、再补接口，结果页面建立在还不存在的契约上，反复返工。先打地基、按依赖顺序走。
- 每个子任务的验收标准互相矛盾或缺连贯。 上一步允许的行为，下一步又被推翻。拆完后整体扫一遍，确认各步的「完成」能拼回最初的大目标。
- 把「探索」当成「实现」派给它。 你其实还不确定方案，却下了一个实现任务，它只能猜着做。不确定时先派只读调研任务，想清楚再实现。
- 拆完不回头核对大目标。 一头扎进子任务，做完一串才发现这些步骤即使全对，也没满足最初的真实需求。每完成几步就抬头对照一次大目标。
- 任务之间留了模糊的灰色地带。 两个相邻步骤都「以为对方会处理」某件事，结果谁都没做。边界要明确到具体文件和职责，别留「相关部分」这种含糊说法。
一个很实用的整体校验：全部子任务列出来后，问自己三句——如果每一步都按验收标准完成，拼起来是不是最初那个大目标？有没有重叠或遗漏？顺序是否保证每步都站在已验证的基础上？ 这三问能在开工前发现大多数拆解缺陷。
八、常见问题
Q：拆解花的时间，会不会把用 Agent 省下的时间又耗掉？ 前期确实要投入，但它换来的是显著更少的返工、失控和调试。大需求上一次方向错误的代价，往往远超拆解的几分钟。熟练后这个过程会非常快，常常在脑子里几分钟就完成，是净收益很高的习惯。
Q：我该自己拆，还是让 Agent 拆？ 可以让它先做只读调研、给出建议的分解，尤其是你不熟的代码库；但粒度拍板、验收标准和边界应由你确认。把它当擅长梳理信息的搭档，而不是替你决定范围的人——这也避免它把任务拆成对它自己方便、却不好验收的形态。
Q：拆好的步骤，必须严格串行做完吗？ 有依赖关系的要串行，保证每步基于已验证的基础；彼此独立的部分以后可以用并行的子代理同时推进（多 Agent 章节会讲）。新手先练熟串行拆解，再考虑并行，顺序不要反。
Q：执行到一半发现当初拆错了怎么办？ 很正常。停下来，回到规划层面重新拆解，必要时回退已做改动，而不是硬着头皮沿着错误分解往下走。拆解不是开工后就不能改的圣旨，它服务于把事做对，发现偏差及时修正是成熟的表现。
总结
让 Agent 稳跑的秘诀不是更详细的咒语，而是把大目标切成「单一问题、边界清楚、带明确验收」的小步——每一步都小到容易做对、做错也立刻看得见，再让它一步步往前走。