TL;DR

本文核心观点：

  1. AI 自动生成 — Execution Plan 由 AI 基于 Product Intent 和 Architecture Spec 自动生成任务拆解，消除人工拆解的随意性
  2. 依赖显式建模 — 所有任务依赖以机器可读的图结构存储，支持关键路径分析和动态计划调整
  3. 数据驱动估算 — 告别直觉估算法，基于历史 velocity 和团队能力模型输出可量化的 hour 估算
  4. 实时进度追踪 — Execution Plan 持续比较计划与实际进度，AI 预测延期风险并触发自动调整

传统任务管理的困境

估算偏差的规模

软件项目的估算偏差远比直觉预测的要大。业界观察反复印证：软件项目估算偏差常常达到数倍量级，即实际工作量往往是初始估算的 2-4 倍（因项目复杂度、团队经验、需求稳定性等因素而异）。更令人警醒的是，传统瀑布式项目管理中按时交付的功能比例往往偏低，超出预算的项目相当普遍——这些现象不是个别案例，而是整个行业的系统性困境。可参考业界经典资料：Standish Group CHAOS Report 与 McKinsey 软件交付研究。

那么，估算偏差的根因在哪里？依赖考虑不全是首要因素——任务之间的隐式依赖在拆解阶段未被识别，到执行时才发现前后置阻塞。风险预估不足次之：复杂技术实现、第三方集成、外部依赖等风险因素在初始估算中被低估。任务粒度不一致则让估算失去可比性——有人把一个 epic 拆成 40 小时的 story，有人拆成 2 小时的任务，两者的估算精度根本不在同一个量级。

隐式依赖：管理者的盲区

传统任务管理中，最大的隐形成本是”依赖黑洞”——任务之间的依赖关系只存在于项目经理的脑海中，既没有结构化存储，也不对团队透明。一个 task 标注为”完成”，但它的下游任务可能还在等待某个 API 接口就绪，而这个接口从未在任何任务列表中明确标注。依赖在人的脑子里，不在系统里，就意味着它不可见、不可计算、不可追踪。

这带来一个直接后果：关键路径是模糊的。当团队规模超过 5 人、任务数超过 50 个时，没有任何工具能回答”如果这个 task 延误一天，整个项目的交付日期会推迟几天”这个问题。Execution Plan 的做法是把依赖关系显式建模为图结构中的有向边，每个节点是一个任务，每条边是一个可计算的依赖关系——机器看得见，团队也看得见。

粒度之谜：同一史诗，不同切法

同一个 epic，不同的人会拆出截然不同的粒度。经验丰富的工程师倾向于拆出 4-8 小时的精细任务，每个任务对应一次可独立提交的代码变更；而刚入职的工程师可能直接写出一个 40 小时的”实现登录模块”。这两种拆法本身没有对错，但放在一起，velocity 失去了可比性，sprint planning 上的故事点数字变成了一场谁也说不清的心理博弈。

Execution Plan 的解法是标准化。通过 WBS（工作分解结构）的四层约束——Epic、Story、Task、Subtask——AI 引擎在拆解时遵循统一的粒度标准：Level 3 Task 对应技术实现单元，估算单位为小时；Level 4 Subtask 对应最小执行单元，通常对应一次 commit。粒度标准化之后，不同团队的 velocity 数据第一次具有了跨团队可比性，历史数据也才能真正用于数据驱动的估算。

上下文蒸发：任务孤立无援

传统的任务描述是孤立的信息片段。”实现登录”——这五个字背后有多少东西没有写进去？产品意图是什么（防谁登录？登录失败后的降级策略？），Architecture Spec 参考了哪份文档（是用 JWT 还是 Session？），团队的技术栈和能力边界是什么（这个模块之前是谁维护的？）。这些上下文在任务创建时存在于某个人脑子里，但没有被嵌入任务本身。

结果是执行者不得不花大量时间”找回上下文”——翻 Slack 记录、查 Architecture Spec 文档、问产品经理当时为什么这么设计。Execution Plan 的核心设计原则之一就是上下文内嵌：Product Intent 和 Architecture Spec 作为输入，AI 在生成每个 Task 时自动将相关上下文注入任务描述，使每个任务从诞生起就携带完整的执行依据，而不是一个孤立的信息碎片。

静态之困：计划赶不上变化

一个迭代的计划，通常在迭代第一天制定完成。但第三天，一个关键 task 被发现预估不足需要延长，第五天产品需求变更导致 scope 调整，第七天某个第三方 API 突然下线需要换方案——计划在制定的那一刻就已经过时了。传统管理的应对是人工调整甘特图：重新排布任务、通知相关人、更新 ETA。但人工调整的成本高、反应慢，团队往往选择”先扛着，晚点再说”，直到迭代结束才发现目标严重偏离。

Execution Plan 的架构天然支持动态调整。当某个 task 的实际执行时间超出估算，依赖图自动重新计算受影响的下游任务的开始时间，新的关键路径随之生成。变化不是被”人工应对”的，而是被系统自动传播的——这是 Execution Plan 与传统任务管理最本质的区别之一。

什么是 Execution Plan

定义

Execution Plan（执行计划）：基于 Product Intent、Architecture Spec 和团队能力模型，由 AI 自动生成的、结构化的、可追踪的工程执行蓝图，包含任务拆解、工作量估算、依赖关系、资源分配和进度追踪。

Execution Plan vs 传统任务列表

维度 传统任务列表 Execution Plan
来源 人工拆解 AI 自动生成
粒度 不一致 标准化
依赖 隐式 显式、可计算
估算 直觉 数据驱动
上下文 分离 内嵌完整上下文
更新 人工 自动同步变更

核心组成

Execution Plan 由六个相互关联的组件构成，共同支撑从需求到可执行任务的完整转换链路。

Product Intent 输入层是整个 plan 的起点：产品意图以结构化的 Epic 形式注入，包含业务目标、用户价值、成功标准。这与传统的”feature list”不同——Product Intent 描述的是”为什么要做”，而不是”做什么”。

Architecture Spec 输入层提供技术上下文：技术选型、模块边界、接口契约。AI 引擎在拆解任务时引用这份文档，确保每个 Task 都与整体架构保持一致，而不是各行其是。

Task Decomposition 引擎是核心 AI 组件，负责将 Epic 和 Story 级别的需求，按照 WBS 四层结构拆解为标准化的 Task 和 Subtask。引擎依赖团队能力模型——了解谁擅长什么、团队的 velocity 基线、历史上各类任务的平均耗时——来生成合理的拆解结果。

** Estimation Model**将历史 velocity 数据、任务复杂度评分和团队能力因子三者结合，输出数据驱动的 hour 估算。与直觉估算法不同，这里的每个数字都能追溯到历史数据和计算逻辑，而不是某个人拍脑袋的结果。

Dependency Graph以有向无环图（DAG）结构存储所有任务之间的依赖关系。每条边代表一个”必须先完成 X 才能开始 Y”的约束，图结构使关键路径分析和影响传播成为可能。

Tracking / Logging Layer持续记录实际进度 vs 计划进度，捕获 velocity 趋势，在延期风险出现时触发预警并触发动态计划调整。整个 Execution Plan 不是一次性产物，而是一个持续运转的状态机。

四层拆解：Epic → Story → Task → Subtask

层次化工作分解结构（WBS）

四层任务拆解结构

Level 1: Epic

定义：可独立交付的业务价值单元，通常对应一个产品功能模块。

Level 2: Story

定义：从用户角度描述的功能点，对应 User Story Pack。

Level 3: Task

定义：技术实现单元，对应具体的开发工作。

Level 4: Subtask

定义：最小执行单元，通常对应一次代码提交。

AI 驱动的任务生成与估算

从规格到任务的自动生成

整个生成管线分为四个阶段，首尾相连形成闭环。

第一阶段：输入解析。 AI 引擎同时读取 Product Intent 和 Architecture Spec，前者提供”做什么”的需求语义，后者提供”怎么做”的技术约束。两者在语义层面对齐——确保产品意图中的每个功能点都能映射到架构文档中的对应模块。

第二阶段：任务拆解。 基于 WBS 四层结构，AI 引擎将 Epic 拆解为 Story（用户视角的功能点），Story 拆解为 Task（技术实现单元），Task 进一步拆解为 Subtask（最小执行单元）。每一步拆解都参照团队能力模型，避免生成团队当前技术栈无法支撑的任务。

第三阶段：依赖解析。 拆解完成后，AI 引擎扫描所有任务，识别隐式依赖（两个任务操作同一个数据库表、A 任务的输出是 B 任务的输入）并将其显式建模为 DAG 中的边。这一步是消除”依赖黑洞”的关键。

第四阶段：估算输出。 基于 Estimation Model，AI 为每个 Task 生成 hour 估算，结合 Dependency Graph 计算出整个 Epic 的工期和关键路径。整个管线在秒级完成，人工拆解通常需要数小时的工作量。

智能任务拆解

示例：从 User Story 生成任务

智能拆解引擎接收一个完整的 User Story Pack——包含用户故事、功能验收标准和涉及的架构模块——然后输出符合 WBS L3 标准的技术 Task 列表。以”用户修改配送地址”这个 story 为例，引擎拆解出的 Task 包括：更新地址表单组件、调用地址校验 API、修改订单服务层的地址字段、更新数据库订单记录、触发下游物流系统通知。每一个 Task 都携带 Architecture Spec 引用、预估工时、所属模块和前置依赖任务。拆解的一致性来自引擎内部的团队能力模型——它知道这个团队使用什么技术栈、各模块的代码分布、历史 velocity 如何，所有拆解决策都基于这些结构化数据而非个人经验。

数据驱动的估算

传统的估算依赖项目经理的直觉，Execution Plan 的估算依赖数据。Estimation Model 的输入有三个维度：

历史 velocity 数据：团队过去 5-10 个迭代的完成工时记录，经过平滑处理后作为基准。引擎不会直接用平均值，而是考虑最近的 velocity 趋势——如果最近两个迭代明显提速，估算会相应调低。

任务复杂度评分：AI 对每个 Task 进行复杂度评分，考虑因素包括：代码改动范围（涉及多少文件/表）、技术风险（是否涉及新技术栈或第三方集成）、上下文切换成本（是否需要跨模块知识）。评分结果映射到历史数据中同类任务的实际耗时分布。

团队能力因子：不同团队做同一个 Task 的耗时不同。引擎维护团队能力画像，包含各模块的熟练度评级、成员轮换情况、远程协作效率等因子，对基准估算进行微调。

三者加权输出的估算结果，不是单一数字，而是一个区间： optimistic（一切顺利）、expected（正常情况）、pessimistic（出现已知风险）。团队在 sprint planning 时可以基于这个区间做缓冲决策，而不是对单一数字盲目自信或保守。

依赖管理与关键路径

依赖关系建模

Execution Plan 中，每个依赖关系是一个有向边 （上游任务 → 下游任务），整张依赖图是一个有向无环图（DAG）。边的构建有两种方式：显式依赖——在 User Story Pack 或 Architecture Spec 中明确标注的接口契约、数据流关系；隐式依赖——AI 引擎在拆解过程中自动推断出的依赖，例如两个 Task 操作同一张数据库表，或者 Task B 的测试需要 Task A 的代码先合入。

依赖图的显式化解决了传统管理中”PM 脑子里知道但系统里没有”的问题。它使两件事第一次成为可能：第一，关键路径分析——在 DAG 上做一次拓扑排序和最长路径计算，就能精确识别哪些任务落在关键路径上，任何一个任务的延误都会直接影响最终交付日期。第二，影响传播计算——当某个任务实际执行时间超出估算时，系统从该节点出发沿 DAG 向下游传播，重新计算所有受影响任务的开始时间和新的 ETA，生成更新的甘特图。整个过程在秒级完成，人工调整甘特图通常需要数小时。

关键路径分析

Execution Plan 依赖管理与关键路径

动态计划调整

动态调整的核心是变更的自动传播。当一个 Task 的实际执行时间与估算产生偏差，Tracking Layer 捕获这个信号，Dependency Graph 触发重新计算：所有以该 Task 为直接上游或间接上游的下游节点，其计划开始时间顺延，整个关键路径随之刷新。如果新的关键路径导致最终 ETA 超出原定交付日期，系统自动生成预警并推荐应对策略——压缩非关键路径任务的工期，或协商延后低优先级的 Story。

这个机制之所以有效，是因为依赖关系已经显式存储在 DAG 中。没有显式依赖，变更的影响只能靠人判断遗漏；有 DAG，传播是确定性的、机械化的。Execution Plan 的动态调整不是”重新做一遍计划”，而是增量更新：只重新计算受影响的部分，未受影响的任务和依赖关系保持原样。这使得调整的成本从”数小时的人工劳动”降到”秒级的算法执行”。

实战：订单功能的 Execution Plan

场景：订单管理模块

让我们用一个具体例子完整走一遍 Execution Plan 的生成过程。

Epic：订单管理模块——用户可以下单、修改配送地址、取消订单，系统同步更新库存和物流信息。

Story（Level 2）：

  • S1: 用户提交订单，系统锁定库存
  • S2: 用户修改配送地址，物流系统同步更新
  • S3: 用户取消订单，库存释放，财务退款

Task 拆解（Level 3，以 S1 为例）：

  • T1.1: 实现订单创建 API（4h），依赖 Architecture Spec §3.2
  • T1.2: 实现库存锁定逻辑（6h），前置：T1.1
  • T1.3: 订单入库并发送库存扣减事件（3h），前置：T1.2
  • T1.4: 实现库存服务消费订单事件（4h），前置：T1.3（T1.3 和 T1.4 可以并行，因为消费方独立）
  • T1.5: 集成测试：库存锁定完整流程（3h），前置：T1.2, T1.4

依赖图（简化）：T1.1 → T1.2 → T1.3 → T1.4；T1.3 → T1.5。T1.3 和 T1.4 并行，两者都完成后 T1.5 才能开始。

关键路径分析：T1.1(4h) + T1.2(6h) + T1.3(3h) = 13h（非并行段），加上并行段的 max(T1.4, 虚线等待) = 4h，总工期 17h。T1.1 → T1.2 → T1.3 是关键路径，T1.4 在并行支路上。

实际执行第一天的状态：T1.1 实际用时 6h（超出估算 2h）。系统检测到偏差，Dependency Graph 传播：T1.2 的最早开始时间顺延 2h → T1.3 顺延 2h → T1.4（并行，仍按原计划开始但 T1.5 的窗口收窄）→ T1.5 顺延 2h。新的 ETA 更新，无需人工介入。

这个例子展示了 Execution Plan 的完整闭环：从 Epic 输入，到 WBS 拆解，到依赖图构建，到关键路径分析，再到实际进度的实时追踪和偏差的自动传播。

AI 辅助的进度追踪

Execution Plan 的 Tracking Layer 不是简单的”任务完成/未完成”二元状态机，而是一个持续运转的预测引擎。每一天，它对比每个 Task 的计划进度和实际进度，计算 velocity 趋势——这个团队最近平均每天完成多少工作？按照当前趋势，这个 Sprint 结束时能完成多少 story points？

当 velocity 数据显示某个 Story 的完成率落后于计划超过 20%，系统触发延期风险预警。预警不是简单的”任务 X 延误”，而是带上下文的：”按照当前 velocity 趋势，S2（用户修改配送地址）预计延误 2 天，建议：① 检查 T1.4（库存服务集成）是否有阻塞，② 考虑将 T1.5（集成测试）拆分为两阶段以并行验证部分功能。”这种级别的预警信息，来自于 Execution Plan 内部各组件共享的数据：Dependency Graph 知道哪些任务受影响，Estimation Model 知道延误对下游的影响量级，Velocity Trend 知道团队的承载能力。

Tracking Layer 的另一个关键输出是燃尽图和趋势预测图。传统燃尽图只能展示”今天剩多少工作”；Execution Plan 的趋势预测在此基础上叠加一条预测曲线——按照当前 velocity，这批任务将在哪天完成，如果要提前 N 天需要提升多少 velocity。这种”可预测”能力，是 Execution Plan 区别于传统看板工具的核心价值之一。

写在最后：从甘特图到可执行计划

范式转移

传统项目计划：

  • 项目经理手工制定
  • 甘特图展示，静态展示
  • 变更时人工调整
  • 进度追踪滞后

Execution Plan：

  • AI 自动生成
  • 结构化规格，动态更新
  • 变更自动传播
  • 实时进度追踪和预测

Execution Plan 的核心价值

价值 说明
准确性 数据驱动的估算，减少偏差
透明性 依赖关系清晰可见
适应性 动态调整，快速响应变化
可追溯 任务与需求、代码自动关联
可预测 AI 预测延期风险，提前干预

实施建议

阶段 1：工具化

  • 使用支持结构化 Execution Plan 的工具
  • 建立历史项目数据库

阶段 2：自动化

  • AI 辅助任务拆解
  • 自动生成依赖图和关键路径

阶段 3：智能化

  • 预测性进度管理
  • 自动资源调配建议

📚 延伸阅读

项目管理

  • The Mythical Man-Month: Fred Brooks
  • Agile Estimating and Planning: Mike Cohn
  • Critical Chain: Eliyahu Goldratt

AI 与项目管理

  • AI in Project Management: 研究论文
  • Predictive Analytics for Software Projects

工程效能

  • Accelerate: Nicole Forsgren et al.
  • DORA Metrics: DevOps 效能指标

AI-Native SDLC 交付件体系 #06
深度阅读时间：约 20 分钟

下一篇预告：《Quality Contract：质量验证的契约化》