三、一个能力，一个Skill / 沟通汇报提示词+skill
风险沟通ROAM状态 + 五步速查表（进展汇报 1）
人都习惯把坏消息埋在好消息后面，结果领导看到最后才发现有个雷，所以汇报风险是最见功力的一环。
这里有一套硬规矩风险要早报、要具体、每个风险都带应对方案。核心是一个四状态的 ROAM 框架 + 一个五步汇报风险句式，可以"可能有点问题"说成"谁在管、影响多大、我要什么"。
方法简介：ROAM + 五步速查表
ROAM 四状态（给每个风险定个状态）：
| 状态 | 含义 |
|---|---|
| Resolved 已解决 | 风险不再是问题 |
| Owned 有人管 | 已认领，有人正在管 |
| Accepted 接受 | 明知有风险，但选择不应对、继续走 |
| Mitigated 已缓解 | 已采取措施降到可接受 |
汇报风险五步句式：
有风险，[某事] 因为 [原因] 可能发生，
一旦发生，后果是 [量化影响]，
这属于 [很可能 / 可能 / 不太可能]，因为 [证据]，
我们正在通过 [行动] 管理它，
我们需要 [具体帮助] 来进一步降低风险。
在什么场景用
| 场景 | 经常卡在哪 | 这个能力可以做什么 |
|---|---|---|
| 有风险要往上报 | 吞吞吐吐，或埋在好消息里 | 逼你风险前置，按五步讲清楚 |
| 风险不知道谁管 | 只说"有风险"，没人认领 | 给每个风险定状态、定负责人 |
| 报了风险没下文 | 光报问题，不给应对，没人理 | 强制"每个风险都配一个应对方案" |
不适合的场景：
- 风险已经解决、只是补记录
- 你只想安抚情绪。风险沟通关键就是说清楚，不是打圆场
适合谁用
| 职能 | 什么时候用 |
|---|---|
| 产品 / 项目经理 | 把风险升级给管理层，给每个风险定负责人 |
| 研发负责人 | 暴露技术风险、卡点，说明在做什么应对 |
| 创始人 / 高管 | 向董事会、投资人讲述风险，获得应对举措和资源 |
立刻上手，把这个能力用作提示词
帮我把这个风险按五步讲清楚：是什么、影响多大、可能性、在怎么应对、需要什么帮助。一个更完整的例子：
帮我整理当前项目风险，并写成可以往上汇报的样子。要求：
- 先给每个风险定 ROAM 状态：已解决 / 有人管 / 接受 / 已缓解
- "有人管"的写 owner + 应对方案；"接受"的写接受理由；"已解决 / 已缓解"写做了什么
- 每个还没解决的风险，按五步句式写：
1. 有风险，[某事] 因为 [原因] 可能发生
2. 一旦发生，后果是 [影响]
3. 属于 [很可能/可能/不太可能]，因为 [证据]
4. 我们正在通过 [行动] 管理它
5. 我们需要 [具体帮助]
- 重要风险放最前面，不要埋在好消息后面
- 不要写"可能有点延迟"这种含糊话，写清是什么、多久、为什么把"进展汇报"写入 agent skill 方法
下面对三个知识点，我逐个详细解释：1. 应该掌握的核心思维和专业洞察。 2. 你可以用来教 AI 的方法。3. 提示词 Prompt
可复制方法指令，可以作为Skill的一部分
- 提示词可复制，分析方法可作为prompt使用，连同任务一起交给AI，
- 如果需要这些分析方法，可以按需写入 Agent Skill，作为处理相关任务的方法和步骤。你还可以结合具体工作，补充相关资料、输出要求等。
用把风险讲成"可以进行处理的信息"
1. 应该掌握的核心思维和专业洞察：
ROAM 四状态，给每个风险一个归属：
- Resolved（已解决）：风险不再是问题，记录怎么解决的
- Owned（有人管）：已被认领、有人主动管理，写明 owner 和应对方案
- Accepted（接受）：明知风险但选择不应对继续走，记录理由
- Mitigated（已缓解）：采取措施已把风险降到可接受，记录做了什么
报风险五步句式：说清风险 → 量化影响 → 说可能性 → 给应对 → 提要求。
2. 你可以用来教 AI 的方法：
大模型默认的是：报风险吞吞吐吐、含糊其辞，甚至学人类把坏消息埋在好消息后面。它不明白：早报的风险是规划，晚报的风险是救火。
所以要给三句约束：① 重要风险前置；② 具体到"是什么、多久、为什么"；③ 每个风险都必须配一个应对方案。
3. 提示词 Prompt：
你是风险沟通助手。任务是把风险讲成"可被处理"的信息，而不是吓人的坏消息。
先给每个风险定 ROAM 状态：
- Resolved 已解决：风险不再是问题，记录怎么解决的
- Owned 有人管：写明 owner + 应对方案
- Accepted 接受：明知风险但选择不应对，写接受理由
- Mitigated 已缓解：写做了什么把它降到可接受
对每个还没解决的风险，按五步句式写：
1. 说清风险：有风险，[某事] 因为 [原因] 可能发生
2. 量化影响：一旦发生，后果是 [影响]
3. 说可能性：这属于 [很可能 / 可能 / 不太可能]，因为 [证据]
4. 给应对：我们正在通过 [行动] 管理它
5. 提要求：我们需要 [具体帮助] 来进一步降低风险
硬规则：
- 重要风险前置，不要埋在好消息后面
- 禁止"可能有点延迟"这种含糊话，写清是什么、多久、为什么
- 每个风险都必须配应对方案，不能只报问题不报对策原文：
## Risk Communication
### ROAM Framework for Risk Management
- **Resolved**: Risk is no longer a concern. Document how it was resolved.
- **Owned**: Risk is acknowledged and someone is actively managing it. State the owner and the mitigation plan.
- **Accepted**: Risk is known but we are choosing to proceed without mitigation. Document the rationale.
- **Mitigated**: Actions have reduced the risk to an acceptable level. Document what was done.
### Communicating Risks Effectively
1. **State the risk clearly**: "There is a risk that [thing] happens because [reason]"
2. **Quantify the impact**: "If this happens, the consequence is [impact]"
3. **State the likelihood**: "This is [likely/possible/unlikely] because [evidence]"
4. **Present the mitigation**: "We are managing this by [actions]"
5. **Make the ask**: "We need [specific help] to further reduce this risk"
### Common Mistakes in Risk Communication
- Burying risks in good news. Lead with risks when they are important.
- Being vague: "There might be some delays" — specify what, how long, and why.
- Presenting risks without mitigations. Every risk should come with a plan.
- Waiting too long. A risk communicated early is a planning input. A risk communicated late is a fire drill.联系与支持
编号05.7.7
本篇基于 Anthropic knowledge-work-plugins （开源库）与 04_skill_md_series（我的内部资料）的研读系列
想继续看其他能力 / 职能，或对本系列有反馈，
请联系顾问：程老师
微信号：kciagent
