同样的复杂任务，有人让 Agent 一次搞定结果翻车，有人拆成小步稳扎稳打。差距不在 Agent，在于你会不会"切蛋糕"——以及用什么框架来切。

---

开篇：一个真实的崩溃场景

小王想让 Claude Code 帮他重构一个烂摊子项目，于是一句话甩过去：

"帮我把这个项目重构一下，代码太乱了。"

结果呢？来回折腾了 20 轮，改了又改，最后还是一团糟。

问题出在哪？

不是 Agent 能力不够，是任务太大、太模糊。Agent 不知道从哪下手，也不知道什么叫"重构好了"。

---

一、为什么复杂任务必须分解？

1.1 Agent 的"脑容量"限制

问题	表现	后果
理解困难	一次性塞太多要求，理解偏差	做出来的不是你想要的
执行混乱	步骤之间互相打架	代码改了又改，越改越乱
上下文溢出	对话太长，Agent "忘记"前面的	前后不一致，返工重做
难以验证	不知道什么叫"完成"	永远在改，没有终点

1.2 分解的本质

分解不是把大任务切成小块就完了，而是：

1. 降低认知负担 —— Agent 一次只专注一件事
2. 明确验收标准 —— 每一步都知道什么叫"完成"
3. 控制风险 —— 问题早发现，不用等到最后

---

二、任务分解的黄金法则

2.1 法则一：MECE —— 不重不漏

MECE（Mutually Exclusive, Collectively Exhaustive）是咨询行业的方法论：

要求	含义	检查方法
相互独立	子任务之间不重叠	两个子任务不会做同样的事
完全穷尽	合起来覆盖全部	所有要做的事都在子任务里

错误示例：

子任务1：写登录功能的前端
子任务2：写登录页面的样式
子任务3：写登录表单的验证

→ 子任务1和子任务2重叠，子任务2和子任务3也重叠

正确示例：

子任务1：创建登录页面组件结构
子任务2：实现表单验证逻辑
子任务3：对接后端登录接口
子任务4：添加加载状态和错误提示

2.2 法则二：粒度适中 —— 一口能吃下

粒度	特征	判断标准
太粗	一个任务包含多个步骤	"实现用户系统" —— 模糊
适中	3-5 步能完成	"实现登录表单验证" —— 清晰
太细	一步就能搞定	"创建一个 input 标签" —— 过度

2.3 法则三：可验证 —— 知道对不对

验收标准公式：

验收标准 = 可观察的结果 + 可测量的指标

示例：

任务	好的验收标准	差的验收标准
登录功能	点击登录按钮后，成功则跳转首页，失败则显示错误提示	"登录功能正常"
性能优化	页面加载时间从 3 秒降到 1 秒以内	"快一点"
代码重构	所有测试通过，代码覆盖率 > 80%	"代码质量提高"

---

2.5 提问框架：用 S.C.O.P.E 结构化你的需求

学会了分解法则，接下来问题是：怎么把分解后的任务清晰地告诉 Agent？

这就需要用到提问框架。

2.5.1 为什么需要框架？

同样是"帮我重构代码"：

无框架：

"帮我把这个项目重构一下，代码太乱了。"

有框架：

背景：这是一个 Express.js 项目，有 3 年历史，代码风格不统一 目标：提升代码可读性和可维护性 要求：保持所有测试通过，不改变业务逻辑 期望：每个模块重构后单独提交

两种问法，Agent 的理解完全不同。

2.5.2 S.C.O.P.E 框架（Agent 专用）

S.C.O.P.E 是 2026 年专为 AI Agent 场景设计的提问框架，六个元素覆盖了 Agent 执行任务需要的所有信息：

元素	含义	说明