---
title: "Claude Code 拆解复杂问题：分步骤解决难题"
description: "复杂任务别整包丢给模型。这一节给一套四步拆法、一棵两层任务树，和一段能直接套用的拆解提示词。"
updated: 2026-11-13
canonical: https://docai.cc/learn/break-down-complex-problems/
markdown_mirror: https://docai.cc/learn/break-down-complex-problems.md
---
## 一句话丢过去，拿回来的都是套话

「帮我策划一场产品发布活动。」这句话给出去，拿回来的多半是流程表加几句正确的废话：定目标、定受众、做宣传、做准备。它不是错，只是没有一个字能直接用。

换成「帮我排一场两小时线上发布会的议程，听众是中小客户，产品是财务软件，中间要留十五分钟答疑」，回答立刻有了形状。

差别不在模型，在问题被切到了多细。

## 四步拆法

先写下最终要拿到的东西。不是「做好活动」，而是「一场五百人在线、结束后能拿到报名名单的发布会」。终点越具体，拆解越省力。

再把目标切成几块互不重叠的部分。线上发布会大致是：内容与议程、推广引流、技术保障、当天执行。四块之间不交叉，才方便分别推进。

然后看依赖。议程不定，宣传物料就没法定稿；技术方案不定，彩排就没法排。把这些先后关系标出来，顺序自然浮现。

最后排期。先做阻塞别人的那件事，先做返工代价最大的那件事。

## 拆到第二层就够用

第一层是四块，第二层每个再拆四到六项：

```text
内容与议程
├── 定主题与一句话主张
├── 排议程与时间轴
├── 约分享人并确认档期
└── 收齐演示材料
推广引流
├── 划目标人群与名单来源
├── 出宣传文案与海报
├── 选渠道与投放节奏
└── 设报名表与提醒
```

再往下拆「打开电脑」「登录后台」这种，只会浪费时间。判断标准很简单：这一块能不能独立交给一个人去做，做完能不能拿出来看。

## 每个子任务带三样东西

材料、产出、验收。缺哪样都会返工。

| 子任务 | 需要什么 | 交付什么 | 算完成 |
|---|---|---|---|
| 排议程 | 时长、受众、必讲内容 | 带时间点的流程表 | 每段有主讲人和目标 |
| 出宣传文案 | 卖点、受众痛点、渠道字数 | 三版短文案 | 每版不超字数且含报名入口 |

第三列最容易被跳过，也最值钱。没有它，你会在收到东西时才发现「不是我要的」。

再给每个子任务编号（1.1、1.2、2.1）。后续对话、进度表、邮件里都用编号指代，比说「那个做海报的」清楚，也方便你在对话里直接说「先做 2.3」。

## 让模型帮你拆，但别让它替你定

卡住时可以直接要一版拆法：

```text
我要在两周内办一场线上产品发布，目标 500 人报名。
请先不要写方案，只做三件事：
1. 拆成 5-8 个工作块，说明每块交付什么；
2. 标出块与块之间的先后依赖；
3. 指出哪几块需要我本人决策，哪些可以直接交给你起草。
```

第三问是关键。模型擅长起草、整理、比较，不擅长替你拍板。哪些环节必须人来定，这条线要在开工前划好，参见[人在回路](/concepts/human-in-the-loop/)。

## 三个场景各拆一遍

**商业计划书。** 先定读者与核心记忆点，再出大纲，然后逐章填，最后通读查逻辑与数据。每章单独一轮对话，比一次要全文稳。财务预测那章的数字必须自己核，别让它算。

**客户投诉。** 先把投诉按产品、服务、沟通三类归拢；再逐条查证每条说法站不站得住，哪些只是理解偏差；然后对属实的定补偿、对误会定澄清话术；最后合并成一封回信。回信可以让它写，事实必须你来认。

**月度数据报告。** 取数、清洗、算指标、写解读、做图、复核。前两步适合交出去，最后一步绝不能省。

## 拆完先过三关

第一关是覆盖：从最终交付倒推，每个子任务都能指向一个具体产物，合起来正好拼出终点；有产物没人认领，说明漏了。第二关是不重叠：两块如果改的是同一份文件、同一段内容，就说明边界没切干净，执行时必然互相踩。第三关是可结算：每块都能单独验收、单独叫停，砍掉一块不影响其他块交付。三关都过，拆解才算合格；只过一两关，先别排期。这三关背后的动作——拆开、找规律、定标准——在[编程思维入门](/learn/programming-thinking-basics/)里有更基础的练习。

判断边界还有一个笨办法：写下每块的产出文件名。两个子任务产出同一个文件，边界就有问题。

反过来，有些任务根本不该拆：一小时内能做完的，直接做；步骤之间咬合很紧、拆开反而要大量交接的，也别拆，按一条线推进更省事。拆解是为了降低认知负担，不是为了产出漂亮的清单——如果清单本身成了负担，就说明拆错了。

## 返工前的三个信号

**信号一：每块只有一句话，说不出交付物。** 这是拆得太粗，执行到中途才发现活干不完。挑最关键的那块再往下切一层，切到能看见具体产物为止。

**信号二：做完一半发现方向不对。** 终点写得太虚，比如「做好这次活动」。回头把验收条件改写成一句可检查的话，再按依赖重排顺序，已经完成的部分能复用的先标出来。

**信号三：两块的时间总是互相等。** 说明依赖关系没画出来，或者顺序排反了。把「谁等谁」写成箭头，先做被最多块依赖的那件。

## 两个常见坑

拆得太细，清单比事情本身还长，执行时反而被清单拖住。拆完发现某块做不了，别硬塞给模型，标上「待人工」放在一边，先推进能推进的。

拆解结果要写下来。凭记忆推进到第三天，你一定会漏掉某条依赖。

下一节把拆好的块排成一条能落地的路径：[设计解决方案](/learn/systematic-solution-design/)。