项目计划崩盘的典型路径：列任务不按影响排序、没人显式 Own、风险藏在一张没人再打开的 slide。下面这些 Prompt 强制你写出里程碑级交付物、显式假设、按概率×影响排序的风险登记、以及一份提前准备好的削减菜单——这样第三周现实砸下来时，是有计划地砍而不是悄悄延期。深入做风险可配合 项目风险分析 Prompt。
这套 Prompt 适合用在哪
- Sprint 规划
- 新方向 / Initiative 范围界定
- 跨团队项目
- 跨职能产品上线计划
- 个人大项目（出书、搬家、备考）
1. 目标 → 里程碑（含假设）
目标：{1 句}。约束：{时间 / 团队 / 预算}。请拆成 4-6 个里程碑。每个：交付物、成功标准、1 个可能 invalidate 它的关键假设。标出假设最不牢靠的那个里程碑——那是要最先验证的地方。2. 里程碑 → 任务
里程碑：{描述}。Owner：{团队}。可用时间：{N 周}。请拆成 ≤2 天的任务。标依赖关系。每个任务给出乐观 / 现实 / 悲观三种工期估算（天）。3. 2 周 Sprint 计划
给定 backlog（粘贴）、团队容量 {N 点}、最高优先级 {目标}：规划 2 周 Sprint。输出：1 句 Sprint 目标、承诺项、Stretch 项、风险。预留 20% 容量给未计划任务。
{粘贴}4. 风险登记
项目计划（粘贴）。请识别 Top 8 风险。每个：概率（低 / 中 / 高）、影响（低 / 中 / 高）、缓解、应急方案、owner。按 概率×影响 排序。区分"风险"（不确定）与"问题"（已发生）。
{粘贴}5. RACI 矩阵
项目：{摘要}。Stakeholders：{含角色}。请为 8 个最重要工作流构建 RACI。标出任何有超过 1 个 Accountable 的工作流——那是出问题的信号。6. 关键路径识别
下面是项目任务 + 依赖。请识别关键路径，标出"延 1 天，整个项目延 1 天"的 3 个任务。再给出 2 种压缩关键路径的方式：fast-track（并行化）或 crash（加资源）。
{粘贴}7. 计划 + 现实 → 状态更新
计划：{粘贴}。本周实际：{粘贴}。请写 150 字状态更新：on track / 风险 / 阻塞，附下周一个具体优先级，以及一条"我需要你做什么"的具体诉求。8. Scope 削减菜单
还剩 3 周但工作量约 5 周。计划：{粘贴}。请给"scope 削减菜单"：5 项可删项，删了失什么、保什么、谁会注意到。按最不痛排序。9. 计划的 Pre-mortem
项目：{摘要}。计划：{粘贴}。假设 6 个月后项目失败了。请写一份事后复盘：失败的 Top 5 原因，按可能性排序。每条标出"如果真朝这个方向走，第 2 周就能看到的先行指标"是什么。
{粘贴}10. Stakeholder 沟通节奏
项目：{摘要}。Stakeholders：{含级别 + 关心程度}。请设计沟通节奏：谁收更新、用什么格式（Slack 串 / 周邮件 / 月评审）、多久一次、每次更新要支持的决策是什么。避免"为汇报而汇报"。11. Kickoff 会议议程
项目：{摘要}。团队：{列表}。请设计 60 分钟的 Kickoff 议程，结束时要产出这些产物：1 句话共识目标、Top 3 风险、每个工作流的 owner、"现在不问就一定会后悔"的那 1 个问题。包含每段大致时长。容易踩的坑
- 列任务不挂里程碑 / 结果——计划读起来像 to-do list 不像项目
- 风险只在 kick-off 写一次，后续新风险冒头没再更新
- 没显式 Accountable，每个人都以为别人在 own
- 没识别关键路径，团队把力气优化在错的任务上
- 没提前准备削减菜单，真要砍时只能在恐慌中砍
- 状态更新只汇报活动量（“做了 12 件事”）而不是对照目标的结果