工作流 02：从混乱需求到可执行项目计划的 AI 多专家工作流¶
适用岗位：项目经理、产品经理、团队负责人、技术负责人
真实场景：你收到一封邮件，或者开完一个需求会议，手里攥着一堆零散的需求描述、口头承诺和模糊目标，领导要求三天内给出项目计划。
最终目标：产出一套可执行的项目计划，包括需求清单、任务拆解、风险清单、排期计划和沟通计划。
输入材料清单¶
开始前请准备以下材料：
- 原始需求文本（邮件正文、会议记录截图文字、口头说明整理稿）
- 项目截止日期或期望上线时间
- 可用的人力资源信息（几个人、各自擅长什么）
- 已知的约束条件（预算上限、技术限制、外部依赖）
工作流总览¶
节点 1：需求澄清专家
↓ 输出：结构化需求陈述清单
节点 2：干系人识别专家
↓ 输出：干系人清单（角色、关注点、影响程度）
节点 3：任务拆解专家
↓ 输出：任务清单（含依赖关系）
节点 4：风险识别专家
↓ 输出：风险清单（含应对措施）
节点 5：排期规划专家
↓ 输出：项目排期表
节点 6：资源评估专家
↓ 输出：资源需求报告
节点 7：沟通计划专家
↓ 输出：项目沟通计划
节点 8：项目复盘专家
↓ 输出：复盘框架模板
最终交付：完整项目计划文档
专家节点详解¶
每个节点包含六部分：节点定位、输入与输出、使用顺序、提示词包（A 快速 / B 专家 / C 自查 / D 返修）、交付给下游节点、人工验收清单。
重要说明：C 自查审稿版和 D 返修优化版是当前节点内部的工作模式，不是新的专家角色。
节点 1：需求澄清专家¶
1.1 节点定位¶
将原始混乱需求整理为结构清晰的需求陈述，识别模糊点和缺失信息。没有清晰的需求，后续的任务拆解和排期都是建在沙滩上的计划。
1.2 输入与输出¶
输入：原始需求文本（邮件、会议记录、口头说明整理稿）
输出：结构化需求陈述清单（含背景、核心目标、功能需求、非功能需求、待确认项）
1.3 使用顺序¶
- 先用「快速生成版」得到结构化需求初稿。
- 需要进行 MoSCoW 优先级分类或识别需求矛盾时，改用「专家增强版」。
- 用「自查审稿版」检查验收标准是否完整、待确认项是否有指向。
- 有问题则用「返修优化版」修正。
- 对照 1.6 验收清单确认，通过后交给节点 2 和节点 3。
1.4 提示词包¶
A. 快速生成版¶
请将以下混乱的需求描述整理为结构化的需求陈述。
原始需求：【粘贴原始需求文本】
输出：
1. 项目背景（一句话）
2. 核心目标（不超过 3 条）
3. 功能需求清单（每条一句话，编号）
4. 非功能需求（性能、安全、兼容性等）
5. 待确认项（模糊或缺失信息，标注"需向谁确认"）
B. 专家增强版¶
你是一位资深产品经理，专注于需求分析和问题澄清。
任务：对以下原始需求进行系统性分析，输出可执行的需求陈述。
输入：
- 原始需求：【粘贴原始需求文本】
分析步骤：
1. 区分"必须有"、"应该有"、"可以有"三类需求（MoSCoW 法）
2. 对每条功能需求，判断是否有明确的验收标准
3. 识别需求之间的矛盾或冲突
4. 列出所有假设前提（未经确认就默认成立的条件）
5. 给出 5 个关键澄清问题，按优先级排序
输出：需求分类表 + 假设前提清单 + 澄清问题清单
C. 自查审稿版¶
此为当前节点的自查模式，不是新的专家角色。
请检查以下需求陈述是否存在以下问题：
1. 是否有需求没有明确的验收标准？
2. 是否有"必须有"和"可以有"被混淆的需求？
3. 待确认项是否每条都指明了需要向谁确认？
4. 是否有两条需求实际上描述的是同一件事？
【粘贴需求陈述清单】
逐条说明问题。
D. 返修优化版¶
1.5 交付给下游节点¶
将结构化需求清单（含待确认项）完整复制，同时交给：
- 节点 2（干系人识别专家）：用于识别相关干系人。
- 节点 3（任务拆解专家）：用于拆解具体任务。
注意：待确认项必须在排期前完成确认，或者在排期中明确标注"待确认后调整"。
1.6 人工验收清单¶
- [ ] 每条功能需求是否都有明确的验收标准？
- [ ] 待确认项是否每条都注明了"需向谁确认"？
- [ ] 是否区分了必须有和可以有的需求？
- [ ] 需求之间是否没有明显矛盾？
节点 2：干系人识别专家¶
2.1 节点定位¶
识别项目所有相关干系人，明确他们的关注点和对项目的影响程度。干系人识别的结果直接决定沟通计划的设计，遗漏重要干系人会在项目中途造成阻力。
2.2 输入与输出¶
输入：节点 1 的结构化需求清单
输出：干系人清单（含角色、关注点、影响程度、参与方式）
2.3 使用顺序¶
- 先用「快速生成版」得到干系人初稿。
- 需要做权力/利益矩阵分析时，改用「专家增强版」。
- 用「自查审稿版」检查是否遗漏了隐性干系人、关注点是否具体。
- 有问题则用「返修优化版」补充。
- 对照 2.6 验收清单确认，通过后交给节点 3 和节点 7。
2.4 提示词包¶
A. 快速生成版¶
请根据以下项目需求，识别所有可能的干系人。
项目需求摘要：【粘贴需求清单中的核心目标和功能需求】
对每个干系人输出：
- 角色（发起人/用户代表/技术负责人/外部供应商等）
- 主要关注点（他们最在意什么）
- 对项目的影响程度（高/中/低）
- 参与方式（决策者/执行者/知情者/审批者）
B. 专家增强版¶
你是一位资深项目经理，擅长干系人管理。
任务：根据以下项目信息，完成干系人分析并给出管理策略。
输入：
- 项目概要：【粘贴项目背景和核心目标】
- 组织背景：【填入组织类型，例如：互联网公司/政府单位/制造业】
分析步骤：
1. 识别显性干系人（主动参与的相关方）
2. 识别隐性干系人（会被项目影响但未主动参与的部门）
3. 完成权力/利益矩阵（高权力高利益 / 高权力低利益 / 低权力高利益 / 低权力低利益）
4. 给出每类干系人的管理策略（密切合作/保持满意/随时告知/监控即可）
5. 识别潜在干系人冲突（哪两个干系人利益可能冲突）
输出：干系人清单表格 + 权力利益矩阵 + 冲突分析段落
C. 自查审稿版¶
此为当前节点的自查模式，不是新的专家角色。
请检查以下干系人清单是否存在以下问题：
1. 是否遗漏了会被项目影响但未被列入的人或部门？
2. 是否有干系人的关注点描述过于模糊（例如只写"关注项目进度"）？
3. 影响程度评估是否有明显不合理的地方？
【粘贴干系人清单】
逐条说明问题。
D. 返修优化版¶
2.5 交付给下游节点¶
将干系人清单（含参与方式）完整复制，同时交给：
- 节点 3（任务拆解专家）：了解各角色职责边界。
- 节点 7（沟通计划专家）：作为设计沟通机制的直接依据。
2.6 人工验收清单¶
- [ ] 是否包含了所有会影响项目或被项目影响的关键角色？
- [ ] 每个干系人的关注点是否具体（而不是"关注项目成功"这类废话）？
- [ ] 是否标注了每人的参与方式（决策者/知情者）？
节点 3：任务拆解专家¶
3.1 节点定位¶
将功能需求拆解为可执行的具体任务，明确每个任务的负责人类型、工作量和依赖关系。任务清单是排期的直接输入，拆解粒度不够或依赖关系不清，排期就是空架子。
3.2 输入与输出¶
输入：节点 1 的需求清单 + 节点 2 的干系人清单
输出：任务清单（含任务名、负责人角色、预估工作量、依赖关系、交付物）
3.3 使用顺序¶
- 先用「快速生成版」得到任务清单初稿。
- 需要三级 WBS 拆解或识别关键路径时，改用「专家增强版」。
- 用「自查审稿版」检查交付物完整性和依赖关系。
- 有问题则用「返修优化版」修正。
- 对照 3.6 验收清单确认，通过后交给节点 4、节点 5、节点 6。
3.4 提示词包¶
A. 快速生成版¶
请将以下功能需求拆解为具体可执行的任务清单。
功能需求：【粘贴功能需求列表】
对每个任务输出：
- 任务编号（T-001 格式）
- 任务名称（动词开头，20 字以内）
- 负责人角色（前端/后端/产品/设计/测试/运营）
- 预估工作量（人天）
- 前置依赖（哪个任务完成后才能开始）
- 交付物（任务完成的标志是什么）
B. 专家增强版¶
你是一位资深项目经理，专注于工作分解结构（WBS）设计。
任务：对以下需求进行三级任务分解，并识别关键路径。
输入：
- 功能需求：【粘贴需求清单】
- 团队构成：【填入团队成员角色，例如：1 名产品、2 名前端、3 名后端、1 名测试】
分解层级：
- 第一级：功能模块（如：用户系统、支付模块）
- 第二级：功能点（如：用户注册、用户登录）
- 第三级：具体任务（如：设计注册页面原型、开发注册接口、编写注册测试用例）
同时输出：
- 任务总工作量估算（合计人天）
- 关键路径标识（不能延误的任务）
- 可并行执行的任务组
输出格式：三级任务表 + 关键路径说明
C. 自查审稿版¶
此为当前节点的自查模式，不是新的专家角色。
请检查以下任务清单是否存在以下问题：
1. 是否有任务描述过于模糊，无法判断完成的标志？
2. 是否有任务工作量估算明显不合理（过大或过小）？
3. 依赖关系是否有遗漏（某个任务实际上依赖另一个任务但未标注）？
4. 是否所有功能需求都能在任务清单中找到对应任务？
【粘贴任务清单】
原始需求：【粘贴需求清单】
逐条说明问题。
D. 返修优化版¶
3.5 交付给下游节点¶
将任务清单（含依赖关系和工作量）完整复制，同时交给：
- 节点 4（风险识别专家）：用于识别任务执行中的风险。
- 节点 5（排期规划专家）：作为排期的核心输入。
- 节点 6（资源评估专家）：用于统计各角色工作量。
3.6 人工验收清单¶
- [ ] 每个任务是否都有明确的交付物（完成的标志）？
- [ ] 所有功能需求是否都能在任务清单中找到对应任务？
- [ ] 关键路径上的任务是否已被标识？
节点 4：风险识别专家¶
4.1 节点定位¶
基于任务清单和约束条件，识别项目执行中的潜在风险，并为每个风险提供具体可操作的应对措施。风险识别必须在排期前完成，否则排期不含缓冲，一旦风险触发就会全线崩塌。
4.2 输入与输出¶
输入：节点 3 的任务清单 + 已知约束条件（截止日期、人力、技术限制）
输出：风险清单（含风险描述、发生概率、影响程度、风险等级、应对措施）
4.3 使用顺序¶
- 先用「快速生成版」得到主要风险清单。
- 需要覆盖全维度风险或为高风险项设计应急预案时，改用「专家增强版」。
- 用「自查审稿版」检查应对措施是否可操作（不能是"密切关注"这类废话）。
- 有问题则用「返修优化版」补充具体应对措施。
- 对照 4.6 验收清单确认，通过后交给节点 5。
4.4 提示词包¶
A. 快速生成版¶
请根据以下项目任务清单，识别主要风险。
任务清单：【粘贴任务清单摘要】
已知约束：【填入截止日期、人力、技术限制等】
对每个风险输出：
- 风险描述（一句话）
- 发生概率（高/中/低）
- 影响程度（高/中/低）
- 风险等级（高/中/低）
- 应对措施（具体操作，不能只写"密切关注"）
B. 专家增强版¶
你是一位资深项目风险管理专家。
任务：对以下项目进行系统性风险识别，覆盖所有风险维度，并为高风险项设计应急预案。
输入：
- 项目概要：【粘贴项目背景、任务量和约束条件】
风险识别维度（必须覆盖）：
1. 需求风险（需求变更、需求不清晰）
2. 技术风险（技术难点、第三方依赖）
3. 资源风险（人员变动、工作量低估）
4. 时间风险（节假日、外部审批周期）
5. 沟通风险（干系人意见不一致、信息传递失真）
对每个风险输出：
- 风险触发条件（什么情况下这个风险会变成现实）
- 预防措施（在风险发生前能做什么）
- 应急预案（风险发生后的处理方案，格式：如果 X 发生，则立即执行 Y）
输出：风险登记表 + Top 3 高优先级风险的详细应对方案
C. 自查审稿版¶
此为当前节点的自查模式，不是新的专家角色。
请检查以下风险清单是否存在以下问题：
1. 是否有风险的应对措施是"密切关注"或"及时沟通"这类空洞表达？
2. 是否遗漏了明显的常见项目风险类型？
3. 高风险项是否都有具体的应急预案（"如果 X 则执行 Y"格式）？
【粘贴风险清单】
逐条说明问题。
D. 返修优化版¶
4.5 交付给下游节点¶
将高风险项列表复制，连同任务清单一起交给节点 5（排期规划专家），高风险任务前需要在排期中预留检查点和缓冲时间。
4.6 人工验收清单¶
- [ ] 每个风险的应对措施是否是具体可操作的动作（而不是"密切关注"）？
- [ ] 是否覆盖了需求、技术、资源、时间四类基本风险？
- [ ] 高风险项是否都有"如果 X 则执行 Y"格式的应急预案？
节点 5：排期规划专家¶
5.1 节点定位¶
基于任务清单、依赖关系和资源情况，生成可视化的项目排期计划。排期的核心不是把所有任务塞满日历，而是识别关键路径、合理分配资源、在关键节点前留出缓冲。
5.2 输入与输出¶
输入：节点 3 任务清单（含依赖关系、工作量）+ 节点 4 风险清单（高风险项）+ 可用人力和截止日期
输出：项目排期表（甘特图文字版）+ 里程碑清单
5.3 使用顺序¶
- 先用「快速生成版」得到排期初稿。
- 需要按关键路径法排列或做资源平衡时，改用「专家增强版」。
- 用「自查审稿版」检查依赖关系是否被违反、人员是否过载、总工期是否在截止日期内。
- 有问题则用「返修优化版」调整。
- 对照 5.6 验收清单确认，通过后将里程碑清单交给节点 6、节点 7、节点 8。
5.4 提示词包¶
A. 快速生成版¶
请根据以下任务清单和资源信息，生成项目排期计划。
任务清单：【粘贴任务清单】
项目开始日期：【填入日期】
截止日期：【填入日期】
团队人力：【填入人数和角色】
输出：
1. 以周为单位的甘特图文字版（每周列出进行中的任务）
2. 关键里程碑清单（3-5 个，每个注明日期和交付内容）
3. 缓冲时间说明（在哪里留了缓冲，留了多少）
B. 专家增强版¶
你是一位资深项目排期专家，熟悉关键路径法（CPM）。
任务：根据以下信息生成详细的项目排期方案。
输入：
- 任务清单（含工作量和依赖）：【粘贴清单】
- 团队资源：【填入每人角色和可用工作日】
- 项目开始日期：【填入日期】
- 硬性截止日期：【填入日期】
- 已知不可用时间段：【填入节假日或不可用时段】
排期要求：
1. 按关键路径优先排列任务
2. 避免同一人同一天超过 8 小时工作量
3. 高风险任务前一周设置检查点
4. 在截止日期前至少保留 5% 工期作为缓冲
输出：里程碑清单（日期 + 交付内容）+ 分周任务分配表（每周各角色做什么）
C. 自查审稿版¶
此为当前节点的自查模式，不是新的专家角色。
请检查以下排期计划是否存在以下问题：
1. 是否有任务的前置依赖未完成就开始排期（违反依赖关系）？
2. 是否有某人或某角色在某周明显过载（超过合理工作量）？
3. 是否在关键节点前预留了检查和缓冲时间？
4. 排期总工期是否在截止日期以内？
【粘贴排期计划】
截止日期：【填入日期】
逐条说明问题。
D. 返修优化版¶
5.5 交付给下游节点¶
将里程碑清单和分周计划复制，同时交给：
- 节点 6（资源评估专家）：用于对照排期评估资源缺口。
- 节点 7（沟通计划专家）：作为设计汇报节奏的依据。
- 节点 8（项目复盘专家）：作为预设复盘节点的依据。
5.6 人工验收清单¶
- [ ] 排期是否在截止日期之前完成所有任务？
- [ ] 是否有明确的里程碑节点和验收说明？
- [ ] 关键路径上是否留有缓冲时间？
节点 6：资源评估专家¶
6.1 节点定位¶
评估项目所需的人力、工具和外部资源，识别资源缺口并提出补充方案。本节点职责是识别"哪里缺资源"并给出解决方案，不是重新做一遍任务分配（那是节点 5 的工作）。
6.2 输入与输出¶
输入：节点 3 任务清单（工作量统计）+ 节点 5 排期计划（分周安排）
输出：资源需求报告（含已有资源、缺口资源、补充方案）
6.3 使用顺序¶
- 先用「快速生成版」得到资源需求初稿。
- 需要完整评估工具和外部依赖时，改用「专家增强版」。
- 用「自查审稿版」检查是否遗漏关键资源类型、补充方案是否可行。
- 有问题则用「返修优化版」完善。
- 对照 6.6 验收清单确认，通过后将资源需求报告纳入项目计划文档。
6.4 提示词包¶
A. 快速生成版¶
请根据以下项目任务和排期，评估资源需求并识别资源缺口。
任务清单：【粘贴任务清单（角色和工作量部分）】
当前可用资源：【填入现有人力、工具清单】
输出：
1. 各角色人力需求汇总（需要 vs 实际可用）
2. 工具/系统需求清单
3. 资源缺口列表（哪些不足）
4. 补充方案（外包/临时借调/推迟需求）
B. 专家增强版¶
你是一位资深项目资源经理。
任务：对以下项目做完整的资源评估，识别缺口并给出优化建议。
输入：
- 任务清单和工作量：【粘贴相关内容】
- 排期计划：【粘贴里程碑和分周安排】
- 现有资源：【填入人力和工具信息】
- 预算上限（可选）：【填入预算信息】
评估维度：
1. 人力资源分析（各角色需求量 vs 实际可用量，缺口说明）
2. 技术工具评估（项目需要哪些工具，是否已有授权）
3. 外部依赖资源（第三方 API、外包团队、采购周期）
4. 关键资源瓶颈（哪个资源如果出现问题会卡住关键路径）
5. 优化方案（如何用最少的资源完成最核心的需求）
输出：资源需求表 + 缺口分析 + 优化建议
C. 自查审稿版¶
此为当前节点的自查模式，不是新的专家角色。
请检查以下资源评估报告是否存在以下问题：
1. 是否遗漏了关键资源类型（例如测试环境、上线权限）？
2. 资源缺口的补充方案是否在项目时间范围内可行？
3. 是否识别了关键路径上的资源瓶颈？
【粘贴资源评估报告】
逐条说明问题。
D. 返修优化版¶
6.5 交付给下游节点¶
将资源需求报告和缺口清单纳入最终项目计划文档。如有重大资源缺口，需在排期计划中标注风险，并通知节点 7（沟通计划专家）在沟通计划中安排资源申请节点。
6.6 人工验收清单¶
- [ ] 是否列出了所有角色的人力需求和缺口？
- [ ] 资源补充方案是否在项目时间范围内可执行？
- [ ] 是否识别了最关键的资源依赖？
节点 7：沟通计划专家¶
7.1 节点定位¶
设计项目的沟通机制、报告节奏和升级流程，确保干系人在正确的时间收到正确的信息。沟通计划设计得好，可以大幅减少项目中途的意外升级和返工。
7.2 输入与输出¶
输入：节点 2 干系人清单（含参与方式）+ 节点 5 里程碑清单
输出：沟通计划（含会议节奏、报告模板、升级机制）
7.3 使用顺序¶
- 先用「快速生成版」得到沟通计划初稿。
- 需要设计信息需求矩阵或完整的升级路径时，改用「专家增强版」。
- 用「自查审稿版」检查干系人覆盖完整性和升级触发条件是否明确。
- 有问题则用「返修优化版」完善。
- 对照 7.6 验收清单确认，通过后将沟通计划纳入项目计划文档。
7.4 提示词包¶
A. 快速生成版¶
请根据以下干系人清单和项目排期，设计项目沟通计划。
干系人清单：【粘贴干系人清单】
项目周期：【填入开始和结束日期】
输出：
1. 定期会议安排（每种会议的频率、参与人、时长、议程要点）
2. 状态报告模板（谁写、给谁看、多久一次、包含哪些内容）
3. 升级机制（什么情况需要升级，升级给谁）
B. 专家增强版¶
你是一位资深项目经理，擅长干系人沟通管理。
任务：设计完整的项目沟通计划，可直接在项目启动会上使用。
输入：
- 干系人清单（含权力/利益矩阵）：【粘贴干系人清单】
- 里程碑清单：【粘贴里程碑列表】
- 项目规模：【填入团队规模和项目周期】
沟通计划要素：
1. 信息需求矩阵（每个干系人需要收到什么信息，频率和格式）
2. 会议设计（区分决策会/同步会/汇报会，各自议程结构）
3. 状态报告设计（交通灯模式：绿/黄/红，含触发条件）
4. 升级路径（问题 → 项目经理 → 项目发起人 → 紧急处置）
5. 反馈收集机制（如何让团队成员反馈风险和阻碍）
输出：沟通计划文档
C. 自查审稿版¶
此为当前节点的自查模式，不是新的专家角色。
请检查以下沟通计划是否存在以下问题：
1. 是否有重要干系人没有被纳入任何沟通机制？
2. 会议频率是否过于频繁（占用太多工作时间）或过于稀疏（信息滞后）？
3. 升级机制是否有明确的触发条件（不能是"视情况而定"）？
【粘贴沟通计划】
逐条说明问题。
D. 返修优化版¶
7.5 交付给下游节点¶
将沟通计划文档纳入最终项目计划文档。如有重大资源缺口（来自节点 6），需在沟通计划中安排资源申请会议节点。
7.6 人工验收清单¶
- [ ] 是否每个关键干系人都有对应的沟通安排？
- [ ] 升级机制是否有明确的触发条件（而不是"视情况"）？
- [ ] 会议安排是否已评估过总时间成本，不会压占过多工作时间？
节点 8：项目复盘专家¶
8.1 节点定位¶
在项目规划阶段预设复盘框架，确保项目结束时有结构化的复盘产出。很多团队在项目结束后临时凑复盘材料，导致复盘变成"回忆大会"——这个节点解决的就是这个问题。
8.2 输入与输出¶
输入：项目核心目标 + 节点 5 的里程碑清单
输出：复盘报告模板 + 里程碑回顾问题 + 改进建议跟踪机制
8.3 使用顺序¶
- 先用「快速生成版」得到复盘框架初稿。
- 需要设计数据收集计划或完整的改进跟踪机制时，改用「专家增强版」。
- 用「自查审稿版」检查复盘问题是否开放、是否有失败分析、改进建议是否有跟踪。
- 有问题则用「返修优化版」完善。
- 对照 8.6 验收清单确认，通过后将复盘框架纳入项目计划文档。
8.4 提示词包¶
A. 快速生成版¶
请为以下项目设计复盘框架。
项目目标：【粘贴项目核心目标】
主要里程碑：【粘贴里程碑列表】
输出：
1. 复盘报告模板（含：目标完成情况、进度偏差分析、质量问题、团队问题、经验总结）
2. 复盘会议议程（含时长建议和各环节时间分配）
3. 10 个关键复盘问题（覆盖需求、进度、质量、团队、沟通五个维度）
B. 专家增强版¶
你是一位项目管理专家，擅长设计有实际价值的复盘机制。
任务：为以下项目设计完整的复盘体系，在规划阶段就预设好，避免结束时临时凑材料。
输入：
- 项目目标和关键结果：【粘贴 OKR 或核心目标】
- 风险清单摘要：【粘贴 Top 5 风险】
复盘体系包含：
1. 数据收集计划（执行中要记录哪些数据用于复盘）
2. 里程碑回顾问题（在每个里程碑节点要问的 3 个问题）
3. 最终复盘报告结构（每个模块说明目的和填写方式）
4. 改进行动跟踪机制（复盘产生的改进建议如何落地追踪）
5. 反模式清单（什么样的复盘是没有价值的，帮助团队避免）
输出：可直接发给团队使用的复盘体系文档
C. 自查审稿版¶
此为当前节点的自查模式，不是新的专家角色。
请检查以下复盘框架是否存在以下问题：
1. 复盘问题是否都是开放性问题（而不是只能回答"是/否"的封闭问题）？
2. 是否有失败分析维度（而不只是总结成绩）？
3. 改进建议是否有跟踪机制（防止复盘后没有落地）？
【粘贴复盘框架内容】
逐条说明问题。
D. 返修优化版¶
8.5 交付给下游节点¶
将复盘报告模板和里程碑回顾问题纳入最终项目计划文档。这是工作流的最后一个节点，输出直接进入最终输出模板。
8.6 人工验收清单¶
- [ ] 复盘问题是否覆盖了需求、进度、质量、团队、沟通五个维度？
- [ ] 复盘报告模板是否是空白格式，可以直接填写？
- [ ] 是否有改进建议的跟踪机制（防止复盘流于形式）？
节点交接说明¶
| 上游节点 | 交接内容 | 下游节点 |
|---|---|---|
| 节点 1 需求澄清 | 将结构化需求清单（含待确认项）完整复制 | 节点 2、节点 3 |
| 节点 2 干系人识别 | 将干系人清单（含参与方式）复制 | 节点 3、节点 7 |
| 节点 3 任务拆解 | 将任务清单（含依赖关系和工作量）复制 | 节点 4、节点 5、节点 6 |
| 节点 4 风险识别 | 将高风险项列表复制，一并输入排期 | 节点 5 |
| 节点 5 排期规划 | 将里程碑清单和分周计划复制 | 节点 6、节点 7、节点 8 |
| 节点 6 资源评估 | 将资源需求报告和缺口清单纳入项目计划文档 | 最终输出模板 |
| 节点 7 沟通计划 | 将沟通计划文档纳入项目计划文档 | 最终输出模板 |
| 节点 8 项目复盘 | 将复盘框架模板纳入项目计划文档 | 最终输出模板 |
最终输出模板¶
【项目名称】项目计划文档
版本：1.0 | 日期：【日期】 | 撰写人：【姓名】
一、需求概要
【粘贴节点 1 的核心目标和功能需求清单】
二、干系人清单
【粘贴节点 2 的干系人表格】
三、任务清单
【粘贴节点 3 的任务表格】
四、风险清单
【粘贴节点 4 的 Top 5 风险和应对措施】
五、排期计划
【粘贴节点 5 的里程碑清单和分周计划】
六、资源需求
【粘贴节点 6 的资源需求表和缺口说明】
七、沟通计划
【粘贴节点 7 的会议安排和报告模板】
八、复盘框架
【粘贴节点 8 的复盘报告模板】
待确认事项：
【粘贴节点 1 的待确认项清单，注明确认截止日期】
常见错误¶
错误 1：跳过需求澄清，直接排期
表现：需求还没说清楚，就急着排时间表，导致计划做完了需求大幅变更。
修复：节点 1 的待确认项必须在排期前完成确认，或者在排期中明确标注"待确认后调整"。
错误 2：风险应对措施写成"密切关注"
表现：风险识别很详细，但应对措施是"密切监控""保持沟通"，发生风险时没人知道该怎么办。
修复：每个高风险项必须有"如果 X 发生，则立即执行 Y"格式的应急预案。
错误 3：复盘放到项目结束后才开始设计
表现：项目过程中没有收集数据，复盘时全靠回忆，复盘报告变成"感受总结"。
修复：在节点 8 确定"在项目执行中要记录哪些数据"，从项目第一天就开始收集。
人工验收清单¶
- [ ] 需求清单中，是否每条功能需求都有验收标准？
- [ ] 任务清单中，所有功能需求是否都有对应任务？
- [ ] 排期是否在截止日期之前完成，并留有缓冲？
- [ ] 所有高风险项是否都有具体的应急预案（而不是"密切关注"）？
- [ ] 沟通计划中，每个关键干系人是否都有对应的沟通方式？
延伸玩法¶
- 变体 1：敏捷版：将任务拆解为 Sprint 周期，用节点 3 + 节点 5 生成两周迭代计划，而不是瀑布式全量排期。
- 变体 2：微型版：对于周期不超过 2 周的小任务，只执行节点 1（需求澄清）+ 节点 3（任务拆解）+ 节点 4（风险识别），省略其余节点。
- 进阶组合：与"工作流 15（领导汇报工作流）"结合，用本工作流的里程碑清单直接驱动下一次汇报材料生成。