task_decomposition_thinking_survey_20260303_deep_research

Z3 全文↑ Z2 条目

方法论库 · 引用级 · none

本页是 <code>contexts/methodology/task_decomposition_thinking_survey_20260303_deep_research.md</code> 的逐字投影（仅隐私清洗，零改写）。

时点提示：本页是仓内文件 contexts/methodology/task_decomposition_thinking_survey_20260303_deep_research.md 的逐字投影（仅做隐私清洗：仓库根绝对路径→相对路径、家目录→~/；除此零改写）。若源文件后续有修订，以仓内真源为准。

报告元数据（frontmatter）

name: task_decomposition_thinking_survey_20260303_deep_research
description: 拆解思维模式综述
domain: infra
consumption:
  surface: none
  trigger: ""
  consumer: orchestrator
status: library
promoted_to: null

AI Agent 任务拆解思维：深度调研报告

调研日期: 2026-03-03
核心关注: 用户给出一个 prompt 后，如何初始拆解为任务？实践者们是怎么做的？
不关注: 多 agent 编排执行细节

一、核心结论

1.1 任务拆解的本质

任务拆解不是"让 AI 自己想"，而是"给 AI 一个结构化的问题"。

来源: Damian Galarza - How I Use Claude Code

"One thing I've learned is that developers who have experience managing or delegating tasks tend to adapt quickly. They already understand how to break down problems into small pieces for someone else to work on."

关键洞察:

有管理/委托经验的开发者适应更快
他们已经知道如何把问题拆成小片给别人做
AI 和人类一样，需要结构化的问题定义

1.2 最重要的发现：Plan Mode 的 5 阶段工作流

来源: articles.gg - How Claude Code Plan Mode Works（逆向工程分析）

Claude Code 的 Plan Mode 通过 tool_result 消息注入一个5 阶段工作流：

Phase 1: Initial Understanding
    │  启动最多 3 个 Explore agents 并行探索
    │  目标：理解用户请求
    ▼
Phase 2: Design
    │  启动 Plan agent(s) 设计实现方案
    │  目标：设计实现方法
    ▼
Phase 3: Review
    │  读取关键文件，确保与用户意图一致
    │  使用 AskUserQuestion 澄清问题
    ▼
Phase 4: Final Plan
    │  写入计划文件
    │  包含：推荐方法、关键文件、验证方式
    ▼
Phase 5: ExitPlanMode
    │  呈现计划等待批准

原文摘录:

"Plan mode is NOT a sub-agent - it's a behavioral state of the main agent controlled entirely through a tool_result message containing detailed workflow instructions."

二、拆解思维的 7 种模式

2.1 Least-to-Most 分解（从最简单开始）

来源: NeoLabHQ/context-engineering-kit - Tech Lead Agent

这是最系统化的分解方法论：

核心原则: 从零依赖的原子任务开始，逐层构建

问题: 用户认证系统

Level 0 (零依赖):
├── 数据结构定义 (User, Token 类型)

Level 1 (依赖 Level 0):
├── 凭证验证逻辑
├── Token 生成逻辑

Level 2 (依赖 Level 0, 1):
├── 认证服务组合

Level 3 (依赖 Level 2):
├── API 端点暴露

Level 4 (依赖 Level 3):
└── 应用集成

原文摘录:

"Apply Least-to-Most decomposition - break complex problems into simpler subproblems, then solve sequentially from simplest to most complex. Each solution builds on previous answers."

分解决策表:

Level	子问题	依赖	为什么这个顺序
0	数据结构	-	所有其他的基础
1	验证逻辑	Level 0	需要数据结构
1	Token 生成	Level 0	需要数据结构
2	认证服务	Level 0, 1	需要验证 + tokens
3	API 端点	Level 2	需要认证服务
4	应用集成	Level 3	需要 API

2.2 顺序 vs 并行任务识别

来源: Michael Brenndoerfer - Breaking Down Tasks

顺序任务（Sequential）:

每一步依赖前一步
例如：选目的地 → 查天气 → 订酒店 → 计划活动

并行任务（Parallel）:

步骤相互独立
例如：检查日历、查邮件、查天气

原文摘录:

"Notice the dependencies: you can't book accommodation until you've chosen a destination. You can't create a packing list until you know the weather. The agent needs to recognize these logical dependencies."

2.3 3-10 子任务原则

来源: 多个实践来源的综合

维度	建议	来源
深度	2-3 层足够	OneUptime
数量	3-10 个子任务	Skywork AI
粒度	1-2 天完成	NeoLabHQ

原文摘录（Intelligent Tools）:

"CRITICAL Rule: If a step is estimated as larger than Large, you MUST break it into smaller steps."

2.4 实现 Top-Down vs Bottom-Up

来源: NeoLabHQ Tech Lead Agent

策略	何时使用	示例
Top-Down	流程清晰、UI 优先	写 `processOrder()` → 实现各子函数
Bottom-Up	算法复杂、数据层优先	实现工具函数 → 组合成工作流
Mixed	不同部分不同复杂度	核心用 Bottom-Up，工作流用 Top-Down

原文摘录:

"Top-to-Bottom: Start by implementing high-level workflow and orchestration logic first, then implement the functions/methods it calls."

"Bottom-to-Top: Start by implementing low-level utility functions and building blocks, then build up to higher-level orchestration."

2.5 复杂度阈值触发

来源: Pierce Freeman - Under the hood of Claude Code

Claude Code 内部的 TodoWrite 工具定义了何时触发分解：

原文摘录:

"Complex multi-step tasks - When a task requires 3 or more distinct steps or actions"

分解触发条件:

✅ 3+ 个不同步骤
✅ 涉及多个文件
✅ 有隐含步骤需要明确
❌ 单行修改
❌ 简单查询

2.6 上下文注入增强分解

来源: Damian Galarza - 实践工作流

核心洞察: 分解质量取决于输入的上下文丰富度

原文摘录:

"Context is King. When I dig deeper into these frustrations, I typically ask how they prompted the LLM. The answer is usually a fairly vague prompt."

14 步实现工作流中的上下文收集:

1. Fetch Linear Issue    → 获取完整需求
2. Gather Context        → 搜索 Obsidian、Sentry、GitHub
3. Move to In Progress   → 更新状态
4. Create Branch         → 命名约定
5. Analyze & Plan        → 分解需求
6. Save to Memory        → 存储计划
7. Review Plan           → 等待用户批准 ← 关键检查点
8-14. 执行阶段...

2.7 显式指令 vs 希望 AI 猜对

来源: Intelligent Tools - Six Strategies

原文摘录:

"This might be my most important strategy: I never hope that Claude will do something my way. I tell it explicitly."

"Be explicit. Assume nothing. Tell Claude exactly what you want, every time."

有效 vs 无效对比:

无效（希望 AI 猜）	有效（显式指令）
"重构这个模块"	"将 UserService.ts 中的所有方法改为 async/await，保持现有行为"
"优化性能"	"识别 N+1 查询，添加批量加载，保持 API 签名不变"
"修复这个 bug"	"定位 null reference 原因，添加防护检查，写回归测试"

三、Plan Mode 的内部机制

3.1 EnterPlanMode 工具

来源: articles.gg 逆向工程

工具 Schema:

{
  "name": "EnterPlanMode",
  "description": "Transitions into plan mode for designing implementation approaches...",
  "input_schema": {
    "type": "object",
    "properties": {},
    "additionalProperties": {}
  }
}

关键发现: 没有参数 - 只是一个状态触发器

3.2 Tool Result 注入的内容

原文摘录:

Entered plan mode. You should now focus on exploring the codebase
and designing an implementation approach.

In plan mode, you should:
1. Thoroughly explore the codebase to understand existing patterns
2. Identify similar features and architectural approaches
3. Consider multiple approaches and their trade-offs
4. Use AskUserQuestion if you need to clarify the approach
5. Design a concrete implementation strategy
6. When ready, use ExitPlanMode to present your plan for approval

Remember: DO NOT write or edit any files yet. This is a read-only
exploration and planning phase.

3.3 Plan Sub-Agent vs Plan Mode

来源: articles.gg

概念	类型	模型	能编辑	用途
Plan Mode	行为状态	Opus (相同)	技术上可以	编排规划工作流
Plan Sub-Agent	独立 Agent	Haiku	否	设计实现策略
Explore Sub-Agent	独立 Agent	Haiku	否	查找和理解代码

原文摘录:

"Plan mode is NOT a sub-agent - it's a behavioral state of the main agent controlled entirely through a tool_result message."

"Plan sub-agent IS a real sub-agent - spawned via the Task tool with subagent_type: 'Plan'."

四、实践者的真实工作流

4.1 Damian Galarza 的 Linear Issue 工作流

来源: damiangalarza.com

原文摘录:

"One thing worth highlighting: step 7 (Review Plan) is a key part of this workflow. After gathering context and creating a plan, Claude presents it and waits for my approval before writing any code."

关键原则:

先收集上下文（Linear + Obsidian + Sentry + GitHub）
创建计划
等待用户批准 ← 防止跑偏
才开始执行

4.2 Intelligent Tools 的六个策略

来源: intelligenttools.co

策略 1: 不自动循环，保持控制

"I tried it. The results weren't convincing - certainly not for production code I have to maintain. The problem isn't Claude's ability to follow a plan; it's returning to code I don't fully understand."

策略 2: 所有事情都用 Plan Mode

"Plan mode in Claude Code has become my default. Instead of Claude immediately executing changes based on my prompt, it first explores the codebase, researches relevant documentation, generates a detailed plan, and then waits for my approval."

策略 5: 显式表达

"Yes, Claude might have done some of this anyway. But why hope? I'd rather give explicit instructions and increase my chances of getting the right output the first time."

4.3 Auto-Planning System Prompt

来源: claudefa.st

可以直接使用的 System Prompt:

MANDATORY PLANNING STEP: Before executing ANY tool, you MUST:
1. Use exit_plan_mode tool to present your plan
2. WAIT for explicit user approval
3. ONLY THEN execute the planned actions
ZERO EXCEPTIONS: Each new user message requires fresh planning approval.

五、如何写出更好的分解 Prompt

5.1 分解 Prompt 的关键元素

来源: Michael Brenndoerfer

原文摘录:

"Each subtask should be:

1. Specific: Clear enough that the agent knows exactly what to do

2. Achievable: Something the agent can actually accomplish with its available tools

3. Ordered: Arranged in a logical sequence where later steps can build on earlier ones"

5.2 显式要求分解

原文摘录:

# Good: Explicit instruction
prompt = """Break this request into specific, actionable subtasks:
{user_request}

List each subtask on a new line."""

# Less effective: Vague prompt
prompt = "Help me with this: {user_request}"

5.3 要求排序和依赖

原文摘录:

prompt = """Break down this task into ordered steps.
Arrange them so that each step can build on previous steps.

Task: {user_request}

Provide a numbered list."""

5.4 指定粒度级别

原文摘录:

# For high-level decomposition
prompt = "Break this into 3-5 major steps: {user_request}"

# For detailed decomposition
prompt = "Break this into detailed, specific subtasks, aiming for 8-10 items: {user_request}"

5.5 常见分解错误及修复

来源: Michael Brenndoerfer

问题	示例	修复
太模糊	"做研究"、"创建内容"、"完成项目"	要求更具体的输出
顺序错误	订机票 → 决定目的地	要求重新排序或手动调整
遗漏步骤	晚宴：发邀请 → 做饭 → 打扫	要求扩展列表

六、系统提示词中的分解逻辑

6.1 TodoWrite 工具的分解指导

来源: Pierce Freeman - Claude Code 内部分析

原文摘录:

"Complex multi-step tasks - When a task requires 3 or more distinct steps or actions"

进度跟踪的状态管理:

"Mark tasks as in_progress BEFORE beginning work. Ideally you should only have one todo as in_progress at a time"

完成标准:

"ONLY mark a task as completed when you have FULLY accomplished it"

6.2 防止过度编码

来源: Pierce Freeman

原文摘录:

"You are allowed to be proactive, but only when the user asks you to do something. You should strive to strike a balance between:

1. Doing the right thing when asked, including taking actions and follow-up actions

2. Not surprising the user with actions you take without asking

3. Do not add additional code explanation summary unless requested by the user."

6.3 Tech Lead Agent 的强制分解

来源: NeoLabHQ/context-engineering-kit

原文摘录:

"Before ANY step creation, explicitly decompose the task into ordered subproblems. This decomposition is MANDATORY - skipping it leads to fragmented, inconsistent task lists."

自我检查循环:

7.1 生成 5 个验证问题
7.2 回答每个问题
7.3 验证清单
    [ ] Stage 2 decomposition table is present
    [ ] Dependencies explicitly stated
    [ ] No forward dependencies
    [ ] All steps have Goal, Output, Success Criteria
    ...

七、何时应该分解 vs 不分解

7.1 分解决策框架

来源: OneUptime

应该分解:

✅ 涉及多个不同操作
✅ 涉及多个文件或组件
✅ 有隐含步骤需要明确
✅ 需要验证检查点

不应该分解:

❌ 单个原子操作
❌ 一步可以完成
❌ 进一步分解会增加开销而无益处

7.2 任务复杂度分类

来源: claudefa.st

复杂度	触发条件	建议模式
Trivial	单行修改、typo	直接执行
Simple	1-2 个文件、清晰范围	可选 Plan Mode
Complex	3+ 文件、架构影响	必须 Plan Mode
Unclear	需求不明确	先问问题再规划

八、信息源汇总

官方/逆向工程分析

articles.gg - Plan Mode 逆向工程: https://articles.gg/64xt9sqpfb/how-claude-code-plan-mode-works
Pierce Freeman - Claude Code 内部: https://pierce.dev/notes/under-the-hood-of-claude-code
claudefa.st - Planning Modes: https://claudefa.st/blog/guide/mechanics/planning-modes
claudefa.st - Auto Planning: https://claudefa.st/blog/guide/mechanics/auto-planning-strategies

实践者分享

Damian Galarza - 完整工作流: https://damiangalarza.com/posts/2025-11-25-how-i-use-claude-code/
Intelligent Tools - 六个策略: https://intelligenttools.co/blog/claude-code-strategies-that-work
Michael Brenndoerfer - 任务分解教程: https://mbrenndoerfer.com/writing/breaking-down-tasks-task-decomposition-ai-agents

系统提示词/Agent 配置

NeoLabHQ Tech Lead Agent: https://github.com/NeoLabHQ/context-engineering-kit/blob/master/plugins/sdd/agents/tech-lead.md
everything-claude-code - AGENTS.md: https://github.com/affaan-m/everything-claude-code/blob/main/AGENTS.md

理论/方法论

Prompt Engineering Guide - ReAct: https://www.promptingguide.ai/techniques/react
OneUptime - Task Decomposition: https://oneuptime.com/blog/post/2026-01-30-task-decomposition/view
Skywork AI - 5 Steps: https://skywork.ai/blog/ai-agent/ai-task-decomposition-step-by-step/

九、可操作的总结

9.1 写出更好分解 Prompt 的检查清单

[ ] 显式要求分解 - 不要假设 AI 会自动做
[ ] 指定粒度 - 3-5 大步骤 vs 8-10 详细步骤
[ ] 要求排序 - 说明依赖关系
[ ] 提供上下文 - 相关文件、现有模式
[ ] 定义成功标准 - 每个子任务如何验证完成
[ ] 等待批准 - 让 AI 呈现计划后再执行

9.2 分解的黄金规则

从零依赖开始 - Least-to-Most 分解
保持 3-10 个子任务 - 太多太少都不好
单一任务单线程 - 一次只做一个 in_progress
显式 > 隐式 - 永远不要希望 AI 猜对
Plan Mode 是默认 - 复杂任务必须先规划

9.3 立即可用的 System Prompt

你是一个任务分解专家。当收到用户请求时：

1. 分析请求复杂度
   - 如果涉及 3+ 个不同操作，必须分解
   - 如果涉及多个文件，必须分解
   - 如果有隐含步骤，必须分解

2. 分解原则（Least-to-Most）
   - Level 0: 零依赖的原子任务
   - Level N: 只依赖 Level 0 到 N-1 的任务

3. 输出格式

## 任务分解

### Level 0 (基础)

[ ] 任务1: [具体描述] → 输出: [预期产物]

### Level 1 (依赖 Level 0)

[ ] 任务2: [具体描述] → 依赖: 任务1

### 并行机会
任务 A 和 B 可以并行执行

### 关键路径
任务1 → 任务2 → 任务3
```

等待批准

呈现计划后，等待用户确认再执行


---

**报告完成**: 2026-03-03

← 返回方法论库索引 · 返回方法论区