没人更新的 risk register 就是一张装饰品：每行都写”monitor”然后再也不打开。下面这 12 个 Prompt 强制你把风险写具体、诚实地打 likelihood 和 impact、从 PMBOK 的四种应对里选一个（mitigate / accept / transfer / avoid），并把 register 通常漏掉的依赖、scope、干系人风险翻出来。还在做计划本身时，配合 项目计划 Prompt 一起用。
一句话总结
- 把项目概要丢进第 1 个 Prompt 生成六类初始 register，再跑 2–6 号攻击扁平 register 藏起来的那几类（失败模式、依赖、时间、scope、干系人）。
- 第 7 个 Prompt 最值钱：它禁止偷懒写”monitor”，逼你给每一行配一个 owner 和一个日期。
- Pre-mortem（第 2 个）有真实研究背书——假设项目”已经失败”再倒推原因（即 prospective hindsight，前瞻式后见之明），在 1989 年的原始研究（Mitchell、Russo、Pennington）里让风险识别的准确率提升了约 30%；Gary Klein 在 2007 年《哈佛商业评论》一文中把它正式化。
- 要一次性粘贴整份项目文档或一份长 register，用 1M token 上下文的模型：Claude Opus 4.7 或 Gemini 3.1 Pro（截至 2026 年 6 月都是 1M）。要严格按固定表格列输出，Opus 4.7 对列格式的遵循最稳。
这套 Prompt 适合用在哪
- 项目启动期的 risk register（或更宽的 RAID log：Risks、Assumptions、Issues、Dependencies）
- 中期重评估
- 上线前的 GO / NO-GO 审查
- 外部依赖与供应商风险
- 干系人与沟通风险规划
1. risk register 初始
项目：[project]。请为 6 个类别生成初始 risk register：technical、dependency、
schedule、scope、stakeholder、regulatory。每类 2-3 条具体风险，标 likelihood
（L/M/H）、impact（L/M/H）、owner、mitigation。区分"风险"（不确定的未来事件）
与"问题"（已经发生）。用表格输出。2. Pre-mortem 预复盘
项目：[summary]。假设 6 个月后失败了。请写 200 字 pre-mortem：哪里出了问题、
我们当时应该不同地做什么、第 2 周本可看见但漏掉的早期信号。挖非显然的失败模式，
而不只是"timeline 滑了"。Pre-mortem 把问题从”可能会出什么错”翻成”到底出了什么错”，这正是它管用的原因：用过去时谈一个确定的失败，触发的就是那种胜过普通头脑风暴的前瞻式后见之明。趁团队的乐观还没固化成 groupthink 时跑它。
3. 依赖风险审计
列出 [project] 的外部依赖（其他团队、供应商、基础设施、API）。每条：
(a) 我们需要他们交付什么、(b) 准时交付的可能性、(c) 如果延迟我们怎么办、
(d) 有没有备选。不要把任何依赖当成默认会到位。4. 时间风险分解
项目时间表：[timeline]。识别 3 个最可能导致 slip 的时间风险：关键路径任务、
不熟悉的技术、依赖、节假日、PTO。每条标：要加多少 buffer + "现在就该动"的
预警信号。5. scope 蔓延审计
审计 [project] 的 scope：kickoff 之后加了什么？每项新增问：(1) 对原目标是否
必要？(2) 要砍掉什么来塞进去？(3) 谁批的？输出一份 scope 纪律 note，加 3 句话
用来挡掉未来的新增。6. 干系人风险地图
按 影响力 x 支持度 把 [project] 的 stakeholders 分类：
(a) 高影响 + 支持（engage）、
(b) 高影响 + 反对（mitigate）、
(c) 高影响 + 中立（convert）、
(d) 低影响（inform）。
对 (b) 和 (c) 每人写出具体干预动作 + owner。7. mitigate / accept / transfer / avoid
对 register（粘在下面）中每条风险，只选一个应对：MITIGATE（具体动作 + owner +
日期）、ACCEPT（一行 rationale + 监控日期）、TRANSFER（保险 / 外包 / 合同条款）、
AVOID（descope）。任何一行不能停留在裸"monitor"且没日期。
[粘贴 register]这是把清单变成计划的那个 Prompt。用一条简单的决策规则去核对模型的选择：
| likelihood | impact | 默认应对 |
|---|---|---|
| 高 | 高 | avoid 或 mitigate |
| 高 | 低 | mitigate 或 accept |
| 低 | 高 | transfer（保险、外包、条款）或 mitigate |
| 低 | 低 | accept（带一个复查日期） |
accept 是合法选择，不是甩锅——但被 accept 的风险仍然要有指定 owner 和一个回看日期。
8. 上线前风险审查
[project] 距上线 T-14 天。审查 register（粘在下面）：(1) 哪些已解决？
(2) 哪些恶化？(3) 有没有新冒头的？输出 GO / DELAY / CONDITIONAL 建议，
并写明 1-2 个会翻转判断的条件。
[粘贴]9. 外部供应商风险
供应商 [vendor] 承担关键服务 [service]。请做风险画像：(1) 历史 SLA、
(2) 是否为单点故障、(3) 失败时的合同补救、(4) 备选供应商或自己兜底方案、
(5) 下线 / 切换计划。输出风险分 + 拖延最久的一个动作。10. 沟通风险
审计 [project] 的项目沟通：(1) 超过 2 周没收到我们更新的 stakeholders、
(2) 为了好看故意低估风险的更新、(3) 在 DM 里做了但没写到任何持久文档的决策。
输出修复清单 + owner。11. 给老板的风险 memo
为 [project] 写 200 字风险 memo 给高管：(1) 具体写出 Top 3 风险、
(2) 我们各自在做什么、(3) 需要他们做的具体决定、(4) 下次更新时间。
不要打太极，不要把诉求埋在中间。12. 风险复盘
[project] 已完成。把 register（粘在下面）对照现实复盘：(1) 哪些风险真的发生了、
(2) 哪些 mitigation 真的起作用、(3) 漏识别了哪些、(4) 标"高"但实际没事的有哪些。
输出 5 条 learnings 喂给下一份 register。
[粘贴]怎么用才到位
- 把真实上下文喂给 AI。 模型变不出你的关键路径，也变不出供应商的 SLA 历史。把真实的计划、时间表、register 原文粘进去——这些 Prompt 是脚手架，不是项目认知的替代品。
- 按任务挑模型。 一次粘贴长 register 或整份项目文档，用 1M token 的模型：Claude Opus 4.7 或 Gemini 3.1 Pro（截至 2026 年 6 月都是 1M）。ChatGPT Plus 的应用内上下文大约 320 页，完整 1M 窗口只在 $200 的 Pro 档。要把模型锁死在固定表格列上，Opus 4.7 对列指令的遵循最稳。
- register 和 RAID log 一起跑。 risk register 只追踪风险；RAID log 还加上 Assumptions（假设）、Issues（已发问题）、Dependencies（依赖）。没验证的假设和没追踪的依赖，搞垮项目的频率不输给点名的风险。两者每周都要过，而不是 kickoff 过一次就完。
- 把输出当草稿。 AI 打的 likelihood / impact 只是起步猜测。在任何东西到达干系人之前，找真正负责这块活的人重新打一遍分。
容易踩的坑
- 风险写得太泛（“schedule risk”）——要点名具体任务、依赖或人。
- likelihood / impact 凭直觉打一次，事实变化后再没更新。
- 每条风险都选 mitigate——accept 是合法且经常更对的选择。
- 风险没 owner，没人可以升级。
- 把”风险”（未来不确定事件）和”问题”（已经发生需要立刻响应）混在一起。
- 团队太乐观所以不做 pre-mortem——其实那正是最该做的时刻。
FAQ
做风险分析用哪个 AI 模型最好？ 要一次性粘贴长 register 或整份项目文档，用 1M token 上下文的模型——Claude Opus 4.7 或 Gemini 3.1 Pro（截至 2026 年 6 月都是 1M）。Opus 4.7 对固定表格 schema 的遵循最稳，列要保持一致时它最省心；Gemini 3.1 Pro 在科学推理基准上领先且每 token 更便宜。ChatGPT Plus 处理较短的 register 没问题，但应用内上下文上限约 320 页。
用 risk register 还是 RAID log？ risk register 只追踪风险。RAID log 把 Risks、Assumptions、Issues、Dependencies 放在一处。小项目一份 register 就够；较大或跨团队的项目，保留详细的 register 并在 RAID log 里引用它，让假设和依赖也一直可见。
风险和问题有什么区别？ 风险是你还能提前规划的不确定未来事件；问题是已经发生、需要现在就响应的事。第 1 个 Prompt 逼 AI 把两者分开——把它们混在一起，是让 register 失效最快的方式。
Pre-mortem 真的有用，还是只是换个名字的头脑风暴？ 它比普通头脑风暴更强。假设项目”已经失败”再倒推（即前瞻式后见之明），在 1989 年的原始研究里让风险识别准确率提升了约 30%；Gary Klein 在 2007 年《哈佛商业评论》一文中把它做成了标准实践。窍门在过去时——“它失败了，原因是”比”可能会出什么错”能逼出更具体的成因。
要不要让 AI 来打 likelihood 和 impact 分？ 只当第一版草稿用。模型对你的团队、供应商、历史没有内部信息，所以在 register 交到任何要据此做决定的人手里之前，找真正负责这块活的人把每一行重新打一遍分。