# Goal Decomposition

> Use when facing complex, vague, or large-scope tasks that need to be broken down into clear, actionable steps before execution. Triggers include multi-step features, unclear requirements, or goals that cannot be completed in one hour.

- Skill: `devcxl/goal-decomposition` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add devcxl/goal-decomposition`
- Raw SKILL.md: https://api.skillmd.com/api/skills/devcxl/goal-decomposition/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: devcxl (https://skillmd.com/u/devcxl)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/devcxl/goal-decomposition

---


# Goal Decomposition

## Overview

**将模糊、宏大的目标逐层拆解为清晰、具体、可执行的小任务，直到每一步都能在一小时内完成。**

核心原则：拆到最后一层时，不需要再"想"，只需要"做"。

## When to Use

**触发条件：**
- 任务目标模糊或宏大（如"优化系统性能"、"重构模块"）
- 预估完成时间超过 1 小时
- 不清楚"下一步该做什么"
- 任务涉及多个模块或系统
- 需要协调多个子任务

**不适用场景：**
- 单文件、单函数的简单修改
- 目标已足够清晰，可直接执行
- 纯粹的信息查询任务

## Quick Reference

| 层级 | 描述 | 时间跨度 |
|------|------|----------|
| **愿景/长期目标** | 最终想要达成的状态 | 年 |
| **阶段目标** | 必须经历的里程碑 | 月/季 |
| **具体目标** | 可量化的交付物 | 周 |
| **关键任务** | 完成目标必做的事项 | 天 |
| **可执行行动** | 30-60分钟内可完成 | 小时 |

## 分解流程

### 第 1 步：明确终极目标

**必须包含三要素：时间 + 结果 + 状态**

| ❌ 错误 | ✅ 正确 |
|---------|---------|
| 提升代码质量 | 2周内将测试覆盖率从 60% 提升到 80% |
| 优化性能 | 3天内将 API 响应时间从 500ms 降到 100ms |
| 重构模块 | 1周内将 UserService 拆分为 Auth 和 Profile 两个服务 |

### 第 2 步：反向拆解阶段目标

核心问题：**"要实现这个目标，必须经历哪几个阶段？"**

```
目标：1周内将 UserService 拆分为 Auth 和 Profile 两个服务

阶段拆解：
1. 分析阶段：梳理 UserService 所有方法和依赖关系
2. 设计阶段：定义 Auth 和 Profile 的接口边界
3. 实施阶段：逐步迁移代码
4. 验证阶段：测试 + 回归
```

### 第 3 步：量化阶段目标

**没有量化 = 无法管理**

| ❌ 模糊 | ✅ 量化 |
|---------|---------|
| 熟悉代码 | 输出 UserService 的依赖关系图 |
| 写测试 | 为 Auth 模块编写 15 个单元测试 |
| 完成迁移 | Profile 相关的 8 个方法全部迁移到新服务 |

### 第 4 步：拆成关键任务

核心问题：**"要完成这个阶段目标，必须做哪些事？"**

```
阶段目标：输出 UserService 的依赖关系图

关键任务：
- 识别所有 public 方法
- 追踪每个方法的调用链
- 识别外部依赖（DB、缓存、第三方服务）
- 绘制依赖图
```

### 第 5 步：拆到可执行行动

**判断标准：**
1. 能在 30-60 分钟内完成
2. 不需要再思考"怎么做"

| ❌ 不合格 | ✅ 合格 |
|-----------|---------|
| 分析代码 | 用 grep 找出所有调用 UserService.login() 的位置 |
| 写文档 | 在 docs/architecture.md 中添加 Auth 模块的接口说明 |
| 做测试 | 为 AuthService.validateToken() 编写 3 个边界测试 |

## SMART 校验

每个分解后的目标都必须通过 SMART 校验：

| 原则 | 校验问题 |
|------|----------|
| **S** - Specific | 目标是否足够具体？ |
| **M** - Measurable | 如何判断已完成？ |
| **A** - Achievable | 现有资源能否实现？ |
| **R** - Relevant | 是否与上级目标相关？ |
| **T** - Time-bound | 有没有明确期限？ |

## Common Mistakes

| 错误 | 问题 | 修复 |
|------|------|------|
| 分解太粗 | 单个任务仍需 2+ 小时 | 继续拆分直到 < 1 小时 |
| 分解太细 | 产生大量 5 分钟的微任务 | 合并相关任务 |
| 跳过量化 | 无法判断进度 | 每个目标必须有可衡量标准 |
| 只分解第一层 | 后续步骤仍然模糊 | 递归分解到可执行层 |
| 忽略依赖关系 | 任务顺序错误导致阻塞 | 明确标注任务间的前置依赖 |

## 输出格式

分解完成后，使用以下格式输出任务清单：

```markdown
## 目标：[具体目标，包含时间和可量化结果]

### 阶段 1：[阶段名称] (预计 X 天)
- [ ] 任务 1.1：[可执行行动] (30min)
- [ ] 任务 1.2：[可执行行动] (45min)
  - 依赖：任务 1.1

### 阶段 2：[阶段名称] (预计 X 天)
- [ ] 任务 2.1：[可执行行动] (1h)
  - 依赖：阶段 1 完成
...
```

## 核心心法

> **好的目标分解，让你每一刻只需要回答一个问题：**
> **"下一步，我该做什么？"**