把问题拆成智能体能执行的任务

用智能体做事的效率差异，绝大多数不出在模型上，而出在任务是怎么交出去的。同一个模型，收到"帮我优化一下这个项目"和收到一份拆好的任务清单，产出质量能差出一个量级。

先说结论

• 拆解的目标不是"分得细"，而是每个执行单元都有可验证的产出；
• 拆之前先找判定标准：说不清"做完是什么样"的需求，拆了也没用；
• 边界（明确不做什么）和产出（交付什么）同等重要，缺一个就会跑偏。

一、四个层次

我实际用的拆解是四层，从上往下逐层收紧：

层次	内容	判断标准
目标	要解决的真实问题	能用一句话说清"为什么做"
判定	做完是什么样	可以客观判断（测试通过 / 指标达标 / 人工确认）
子任务	相对独立的工作块	有明确输入输出，能单独验收
执行单元	一次派给智能体的任务	一次会话内可完成，且失败可重试

三层往下走的过程里，最常见的错误是从"目标"直接跳到"执行单元"：目标很宏大，执行单元很具体，中间缺少判定标准与子任务划分，于是智能体只能自己猜——猜出来的方向通常和你想的不一样。

二、拆之前先回答三个问题

一、"做完是什么样？" 如果答不上来，先别拆——先去把验收标准想清楚。这一步经常暴露真正的问题：有些需求之所以难派出去，是因为提出者自己也没想清楚要什么。

二、"最小可验证单元是什么？" 能独立跑通、独立判断对错的最小集合。先做这一个单元，确认整条链路的方向正确，再放开规模。

三、"哪些绝对不能做？" 边界比产出更容易被忽略。例如"只读、不要改文件""不要动这个目录""不要引入新依赖"——不写清楚，智能体会按它自己的判断行事，而这种"自主"往往不是你想要的。

三、拆的粒度：一次可验证的产出

我用一条经验判断粒度是否合适：这个执行单元的产出，能不能不依赖上下文就判断对错？

• 能 → 粒度合适，可以派出去；
• 不能（比如"优化了一部分代码"） → 说明还没拆到位，或者判定标准缺失。

粒度太细也浪费：把一个连续的工作拆成十个需要来回交接的碎片，交接成本会超过收益。三种情况我基本不拆：单文件的小修改、判断类问题（直接问比拆更省）、以及探索性工作（先让智能体自己看，再决定要不要拆）。

四、串行与并行

拆完之后不是所有子任务都能同时跑：

• 数据依赖：后一步要用前一步的产出 → 必须串行；
• 接口未定：并行改同一个接口会互相冲突 → 先定接口再并行；
• 共享可变状态：多个执行单元改同一份文件或同一份数据 → 要么串行，要么先把状态隔离。

我踩过的最典型的坑是第三种：两个子任务同时改同一批文件，最后合并时互相覆盖。并行的前提是"互不触碰同一份可变状态"，不是"看起来独立"。

五、常见拆解错误

一、按"工种"拆而不是按"产出"拆。 "让 A 写后端、B 写前端"看起来合理，但如果接口没定，两边都要猜；按产出拆应该是"先定接口（一个单元），再分别实现"。

二、把探索与实现塞进同一个子任务。 探索需要穷举和试错，实现需要收敛；放在一起，智能体会用"实现"的心态做"探索"，过早收敛到第一个看起来可行的方案。

三、子任务带着一大堆无关上下文。 上下文不是越多越好：无关历史会稀释判断质量。只给它需要的输入。

性价比最高的一步

在派发前，用一句话写下这个子任务的"完成定义"。写不出来，说明你还没想清楚——这时候派出去，大概率要返工。

六、一个真实例子

一次论文语料处理的任务，最初的需求是"把这几万篇论文整理成知识库"。按四层拆下来是这样：

• 目标：让文献检索能带着出处；
• 判定：随机抽 50 篇，条目内容与原文一致、且每条都能追溯到原文位置；
• 子任务：解析分块 / 推理抽取 / 落库与证据链 / 质量抽检；
• 执行单元：例如"实现内容哈希幂等与任务表读写"（半天内可完成、有测试可判断）。

最终跑成 11.2 小时的连续任务且中途断网能自愈——不是因为模型强，而是因为拆完之后每个环节都能独立验证。这个过程记在另一篇笔记里。