SuperAPI AI 工具集

task-decomposition

编程与开发

查看项目

更新于 10-15 13:37

技能介绍

用途

Task Decomposition 是一个任务拆解诊断技能,目标是把令人不知所措的开发任务转化为可管理的单元。它强调尊重认知极限、建立清晰边界、支持并行工作。资料称,经过恰当拆解的任务可获得 3 倍更高的完成率和 60% 更少的缺陷。

其核心理念是:目标不是产生更多任务,而是产生正确的任务——小到可以完全理解,大到足以交付价值,独立到足以避免阻塞。

何时使用

资料列出以下适用场景:

  • 任务大到难以估算
  • 不确定从哪里开始
  • 被依赖关系阻塞
  • 任务不断变大(范围蔓延)
  • 需要拆分一个史诗(epic)或特性

以下情况不应使用:

  • 任务已经足够小且清晰
  • 正在做实现工作
  • 需要做架构决策(应使用 system-design)

认知极限参考

技能给出了一组认知极限阈值:

  • 工作记忆:7±2 项,即每个任务最多容纳的概念数
  • 上下文切换恢复:23 分钟,应尽量减少任务切换
  • 检查文件数:最多 15-20 个,用于界定任务范围
  • 完成率开始下降的天数:2-3 天,任务应保持在此之内

任务时长与成功率的关系:

  • 小于 2 小时:95%
  • 2-4 小时:90%
  • 4-8 小时(1 天):80%
  • 2-3 天:60%
  • 1 周:35%
  • 超过 2 周:低于 10%

诊断状态与干预

技能将问题归纳为六种诊断状态,每种都配有症状与干预手段:

TD1:大到无法理解 症状:估算范围波动极大、无法在脑中保持全部需求、需要跟踪的概念超过 7 个。 干预:应用 INVEST 标准(Independent 独立、Negotiable 可协商、Valuable 有价值、Estimable 可估算、Small 小、Testable 可测试);使用垂直切片(每个切片可独立部署);应用行走骨架(先做最小端到端)。

TD2:没有清晰入口 症状:存在多个有效起点、陷入瘫痪、一切似乎都相互关联。 干预:前置风险,从不确定性最高的项开始;使用曳光弹(最小概念验证);找到行走骨架,即贯穿所有层的最薄切片。

TD3:依赖问题 症状:“被 X 阻塞”、菱形依赖、协调开销大。 干预:接口契约,先定义 API,实现时用 mock;功能开关,独立部署、就绪后启用;通过抽象分支,创建一层再替换实现。

TD4:没有清晰的完成标准 症状:永远处于“快完成了”、无法验证是否完成。 干预:定义验收标准(Given/When/Then);用时间盒强制排优先级;明确列出范围之外的事项。

TD5:范围蔓延 症状:任务不断增长、“既然都到这儿了”式的追加。 干预:冻结范围,追加内容另开新任务;定义最小可行版本;交付能解决问题的最小版本。

TD6:需要先做技术验证(Spike) 症状:估算方差超过 4 倍、涉及新技术、存在多种方案。 干预:时间盒验证(最多 8 小时);交付物包括选项、概念验证、权衡与修订后的估算;采用先验证再实现的模式。

拆解模式

垂直切片(特性首选) 以“用户资料管理”为例:

  • 切片 1:查看基本资料(4 小时)——UI 资料展示、API GET /profile、DB 读取资料
  • 切片 2:编辑资料名称(6 小时)——UI 编辑对话框、API PATCH /profile/name、DB 更新资料

每个切片都可独立部署。

行走骨架(用于新系统) 先做最小端到端:1. Hello World 页面;2. 一个 GET 端点;3. 单张表;4. 基本部署。然后再逐步充实。

曳光弹(验证架构)

  • 步骤 1:最小服务 A(1 小时)——硬编码响应
  • 步骤 2:最小服务 B(1 小时)——简单转换
  • 步骤 3:集成(2 小时)——证明二者可通信

总计 4 小时到达决策点。

估算技术

复杂度规模(斐波那契)

  • 1:琐碎,小于 1 小时
  • 2:简单,1-2 小时
  • 3:标准,2-4 小时
  • 5:中等,4-8 小时
  • 8:复杂,1-2 天
  • 13:非常复杂,2-3 天
  • 21:过大,必须拆解

三点估算 O = 乐观(一切完美)、L = 可能(正常情况)、P = 悲观(出现重大问题)。 PERT 估算:(O + 4L + P) / 6

反模式

  • 大爆炸式交付:在没有任何交付前构建完整系统。修正:垂直切片、增量价值。
  • 没有价值的技术任务:“搭建数据库”“创建服务层”。修正:并入特性任务,如“用户可查看商品(含数据库)”。
  • 无限研究:无边界调查。修正:带交付物的时间盒验证。
  • 完美拆解:开始前过度分析。修正:只拆解未来两周,后续细节会自然浮现。

拆解检查清单

开始任何任务前:

  • 能否在工作记忆中保持全部需求?
  • 时长是否在 2-3 天以内?
  • 是否存在清晰的验收标准?
  • 依赖是否已识别并尽可能打破?
  • 能否独立完成?
  • 是否交付可验证的价值?
  • 估算信心是否高?

任何一项为“否”,就需要进一步拆解。

相关技能

  • github-agile:把拆解后的工作作为 issue 跟踪
  • system-design:理解架构边界
  • requirements-analysis:澄清不清晰的需求
  • code-review:实现后评审

限制

资料未提供该技能的具体安装方式、支持平台、收费模式或价格信息,这些内容暂未提供。