devcxl 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 步：拆到可执行行动
判断标准：
- 能在 30-60 分钟内完成
- 不需要再思考"怎么做"
| ❌ 不合格 | ✅ 合格 |
|---|---|
| 分析代码 | 用 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 分钟的微任务 | 合并相关任务 |
| 跳过量化 | 无法判断进度 | 每个目标必须有可衡量标准 |
| 只分解第一层 | 后续步骤仍然模糊 | 递归分解到可执行层 |
| 忽略依赖关系 | 任务顺序错误导致阻塞 | 明确标注任务间的前置依赖 |
输出格式
分解完成后，使用以下格式输出任务清单：
## 目标：[具体目标，包含时间和可量化结果]
### 阶段 1：[阶段名称] (预计 X 天)
- [ ] 任务 1.1：[可执行行动] (30min)
- [ ] 任务 1.2：[可执行行动] (45min)
- 依赖：任务 1.1
### 阶段 2：[阶段名称] (预计 X 天)
- [ ] 任务 2.1：[可执行行动] (1h)
- 依赖：阶段 1 完成
...
核心心法
好的目标分解，让你每一刻只需要回答一个问题： "下一步，我该做什么？"