没人更新的 risk register 就是一张装饰品——每行都写”monitor”然后再也不打开。下面这些 Prompt 强制你把风险写具体、诚实地打 likelihood 和 impact、明确选 mitigate / accept / transfer / avoid，并把 register 通常漏掉的依赖、scope、干系人风险翻出来。还在做计划本身配合 项目计划 Prompt。
这套 Prompt 适合用在哪
- 项目启动期的 risk register
- 中期重评估
- 上线前的 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 滑了"。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. 干系人风险地图
按 影响力 × 支持度 把 {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}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。
{粘贴}容易踩的坑
- 风险写得太泛（“schedule risk”）——要点名具体任务、依赖或人
- likelihood / impact 凭直觉打一次，事实变化后再没更新
- 每条风险都选 mitigate——accept 是合法且经常更对的选择
- 风险没 owner，没人可以升级
- 把”风险”（未来不确定事件）和”问题”（已经发生需要立刻响应）混在一起
- 团队太乐观所以不做 pre-mortem——其实那正是最该做的时刻