季度评审时把风险登记表投到屏幕上，十四条里有九条描述的是已经发生的事：某个接口还没联调、某个供应商的报价还没回、某个关键人已经离职、某个需求还没排期。这些条目每一条都需要今天有人去处理，但它们躺在"风险"栏里，看起来像未来的事。
风险是尚未发生、有概率的事件；问题是已经发生、需要处置的事实。 两者的管理动作完全不同，混在一张表里，结果是既没人做预案，也没人负责解决。
1. 分界与两个方向的错位
判断一个条目属于哪一类，只需要问：它现在正在发生吗？
| 维度 | 风险 | 问题 |
|---|---|---|
| 状态 | 尚未发生 | 正在发生 |
| 概率 | 有概率不发生 | 概率为 1 |
| 需要什么 | 预案 + 触发信号 + 责任人 | 处置方案 + 负责人 + 截止时间 |
| 成功的标准 | 没有发生，或发生后影响可控 | 已消除，且不再复发 |
| 复盘时的位置 | "我们预判到了，预案起了作用" | "我们处置得快/慢" |
| 关闭条件 | 到期未发生、或前提消失 | 状态恢复 |
两个方向的错位都很常见，后果不同：
| 错位 | 表现 | 后果 |
|---|---|---|
| 风险写成问题 | "供应商可能延期"被记成"供应商延期" | 直接进入处置，没人做备选方案 |
| 问题写成风险 | "接口还没联调"记在风险栏 | 没人负责解决，只等它自己好 |
| 两者混排 | 一张表里既有预案又有待办 | 优先级无法排序，周报读不出重点 |
| 长期不分 | 表越来越大，没人再看 | 风险管理退化为填表 |
第二种错位最常见。它的信号是：某条"风险"已经连续三个月出现在表里，状态一直是"高"。风险不该长期停留在高风险状态——要么它发生了（转成问题），要么它的前提消失了（关闭），要么预案被写出来了（风险降级）。
2. 字段决定了一张表能不能用
两类条目需要的字段不同，共用一套字段必然有一半是空的。
| 字段 | 风险必填 | 问题必填 | 说明 |
|---|---|---|---|
| 描述 | 是 | 是 | 风险写"可能"，问题写"已" |
| 概率 | 是 | — | 高中低三档即可，不追求精确 |
| 影响面 | 是 | 是 | 风险写"若发生"，问题写"已影响" |
| 触发信号 | 是 | — | 见下一节 |
| 预案 | 是 | — | 谁在什么条件下做什么 |
| 责任人 | 是（预案执行人） | 是（处置负责人） | 不是"相关方" |
| 截止时间 | — | 是 | 问题必须有期限 |
| 处置方案 | — | 是 | 具体的下一步动作 |
| 状态 | 观察中 / 已触发 / 已关闭 | 待处置 / 处置中 / 已闭环 | 两套状态机 |
// 一次查询同时暴露四类字段缺失，把"填表"变成可判定的检查
SELECT id,
CASE WHEN signal IS NULL THEN '缺触发信号'
WHEN plan IS NULL THEN '缺预案'
WHEN owner IS NULL THEN '缺责任人' END AS risk_gap,
CASE WHEN due_date IS NULL THEN '缺截止时间'
WHEN next_step IS NULL THEN '缺下一步' END AS issue_gap
FROM entry
WHERE kind = 'risk' AND (signal IS NULL OR plan IS NULL OR owner IS NULL)
OR kind = 'issue' AND (due_date IS NULL OR next_step IS NULL);
// 空值计数比"表填得全不全"这种主观判断可靠
"责任人"这一栏最容易写坏。写成"技术组"等于没有责任人；写成"相关方：张三"也等于没有。责任人的定义是"如果这件事没被处理，第一个被问的人"。
3. 触发信号是风险条目的核心
没有触发信号的风险条目，本质上是一条备忘录——它记录了某种担忧，但没有告诉任何人"什么时候该动手"。
| 风险描述 | 无触发信号（无效） | 有触发信号（有效） |
|---|---|---|
| 供应商可能延期 | "关注交付进度" | "若 T-10 个工作日未收到样品，启动备选供应商" |
| 关键人可能离职 | "注意人员稳定性" | "若核心模块只有 1 人熟悉，启动结对与文档补齐" |
| 三方接口可能不稳 | "保持沟通" | "若连续 3 天错误率高于 1%，切备用通道" |
| 需求可能变更 | "及时同步" | "若需求冻结后新增 P0 需求，重排范围并走变更流程" |
触发信号必须是可观测且可判定的。"关注""注意""保持沟通"都不满足这个条件，因为它们无法回答"现在到点了没有"。
// 风险条目的完整形态：触发信号、预案、责任人三者缺一不可
risks:
- id: R-07
desc: "关键模块仅一人熟悉，离职或长期请假将导致交付中断"
probability: medium
impact: high
signal: // 必须可观测
metric: modules_with_single_owner
condition: ">= 1"
check: weekly
plan: // 触发后要做什么，写动作不写态度
- "30 天内完成结对：第二人独立提交过该模块变更"
- "补一份运行手册，覆盖排错路径"
owner: "张三" // 没处理时第一个被问的人
review_by: 2026-12-31 // 到期必须重估，不重估就自动降级
review_by 这一栏解决风险清单只增不减的问题：到期没有重新确认，条目自动失效。强制重估比强制检查有效——检查只会加条目，重估会删条目。
4. 风险转问题的那一刻
转化必须有明确动作，否则这件事会在两个体系之间掉出去。
| 时刻 | 必须做的动作 | 常见遗漏 |
|---|---|---|
| 触发信号命中 | 记录触发时间与证据 | 只口头说"好像出了" |
| 转成问题条目 | 建立新条目，链接原风险 | 直接在原条目上改状态 |
| 启动预案 | 指定执行人，给出截止时间 | 预案留在文档里没人执行 |
| 通知相关方 | 明确影响范围与预期恢复 | 通知了但没写影响 |
| 风险条目归档 | 保留记录，标注已转化 | 删掉风险，历史断裂 |
第三项是最常掉的一环：预案写得很完整，触发时却没人执行，因为预案里没有写"谁"。预案的执行人必须在写预案时就确定，不能留到触发时再找。
// 触发信号的自动检查：把"关注"变成一条可执行的判定
bin/check-risk-signals --config risks.yaml --format table
// 输出示例（每周跑一次，结果进周报）
// R-07 medium/high signal HIT modules_with_single_owner=2 -> 转问题 Q-31
// R-09 low/low signal OK dependency_age_days=41
// R-11 medium/high OVERDUE review_by=2026-11-01 已过期 38 天 -> 强制重估
第三个状态 OVERDUE 是这套机制里最有价值的输出：它把"没人管的条目"变成一个可见的数。
5. 评级在两类条目里含义不同
"高风险"这个词在两种语境下指向不同的东西。
| 评级含义 | 风险 | 问题 |
|---|---|---|
| 高的意思 | 发生的可能性大 | 已经造成的影响大 |
| 由什么决定 | 概率 × 影响 | 影响面 × 恢复难度 |
| 降级方式 | 预案到位、前提消失 | 处置完成 |
| 常见误用 | 把"影响大但概率极低"标成高 | 把"提出人级别高"当成影响大 |
评级还可以用一个两维矩阵来定，避免"感觉很重要"式的判断：
// 风险等级 = 概率 × 影响；问题等级 = 影响面 × 恢复难度（不含概率，概率恒为 1）
影响：低 中 高
概率：高 中 高 极高
中 低 中 高
低 低 低 中
// 极高 = 现在就做预案，不等触发信号
// 高 = 有触发信号与预案，进入周报
// 中 = 登记，季度重估
// 低 = 只登记，不占用注意力
第一行最容易出错：一个"影响极大但几乎不可能发生"的事件，标成高风险会让它挤占所有注意力；正确做法是保留它，但把资源投给"影响中等且很可能发生"的那些。
第二行同样常见：问题的优先级应该看影响面（多少用户、多少数据、是否可逆），而不是看谁提的。按提出人排序是组织病，它会让真问题排在小问题后面。
6. 排错：五种"表填了但没起作用"
| 现象 | 成因 | 处理方向 |
|---|---|---|
| 风险连续数月停在"高" | 无触发信号，也无重估机制 | 补 signal 与 review_by，过期强制重估 |
| 预案写了但触发时没人动 | 预案没有执行人 | 写预案时同步指定人 |
| 周报里"风险"越来越多 | 问题被记进风险栏 | 分栏上报，问题单独一栏 |
| 同样的问题反复出现 | 闭环时没写根因 | 关闭条件加"根因已消除" |
| 没人看风险清单 | 条目太多且全是套话 | 砍到十条以内，每条带信号 |
排错时可以先做一次"条目年龄"统计，它比任何主观判断都准：
// 条目年龄分布：长期存活的条目要么该转化，要么该关闭
awk -F, 'NR>1 {print $2}' entries.csv \
| while read d; do echo $(( ( $(date +%s) - $(date -d "$d" +%s) ) / 86400 )); done \
| sort -n | awk '{a[NR]=$1} END {print "中位:", a[int(NR/2)], "天; 最老:", a[NR], "天; 条数:", NR}'
// 中位年龄超过一个季度，说明这张表已经变成档案而不是管理工具
第五条值得展开：风险清单的价值与条目数量反向。一张有十条以内、每条都带触发信号的清单，看的人会记住；一张有四十条套话的清单，谁都不会看第二眼。
7. 边界：什么情况不需要分账
| 场景 | 为什么可以合并 | 做法 |
|---|---|---|
| 个人任务，无跨方依赖 | 处置与预案可由同一人即时切换 | 一份带状态的待办 |
| 周期短于两周 | 风险来不及转化 | 只记问题，风险口头提示 |
| 完全确定的工作 | 不存在"可能发生" | 只记问题 |
| 高度重复的运维 | 风险已被流程覆盖 | 用检查单代替风险清单 |
判断口径一句话：这件事有没有"还没发生但需要提前准备"的性质。有，就必须分账；没有，合并成一份带状态的清单更省事。
8. 自测
- 用一句话区分风险与问题。为什么"现在正在发生吗"这一个问题就够？
- 风险写成问题、问题写成风险，各自会造成什么具体后果？
- 为什么"关注""注意""保持沟通"不构成触发信号？可观测且可判定具体指什么？
- 风险转问题时，最常掉的一环是哪个动作？如何在写预案阶段就避免？
- "高风险"在两类条目里分别指什么？把"影响极大但概率极低"标成高风险有什么害处？
- 为什么风险清单的价值与条目数量反向？强制重估比强制检查有效在哪里？