risk-matrix

name	risk-matrix
version	1.0.0
description	基于 MECE 分析法对功能变更做全维度风险评估，按概率与影响在六个不重叠维度（正确性/兼容性/性能容量/安全合规/运维部署/用户体验）打分，产出可决策的风险矩阵报告。触发词："风险评估"、"风险矩阵"、"risk matrix"、"这样改有什么风险"、"/risk"。

风险比对矩阵

版本：v1.0.0 | 状态：已落地 | 触发：/risk、"风险评估"、"风险矩阵"、"risk matrix"

基于 MECE 分析法（Mutually Exclusive, Collectively Exhaustive），对功能变更进行全维度风险评估。

为什么用 MECE

不用 MECE 的风险评估：
  "可能会影响性能"
  "可能会有 bug"
  "可能不兼容"
  → 维度重叠、遗漏多、无法决策

用 MECE 的风险评估：
  ┌─────────────── 所有风险 ───────────────┐
  │                                         │
  │  ┌─────────┐ ┌─────────┐ ┌──────────┐  │
  │  │ 正确性  │ │ 兼容性  │ │ 性能容量 │  │  ← 不重叠
  │  └─────────┘ └─────────┘ └──────────┘  │
  │  ┌─────────┐ ┌─────────┐ ┌──────────┐  │
  │  │ 安全合规│ │ 运维部署│ │ 用户体验 │  │  ← 不遗漏
  │  └─────────┘ └─────────┘ └──────────┘  │
  │                                         │
  └─────────────────────────────────────────┘
  每个格子独立评估 → 有结论 → 可决策

触发词

• "风险评估"、"评估风险"
• "风险矩阵"、"风险分析"
• "risk matrix"、"risk assessment"
• "这样改有什么风险？"
• "帮我评估一下风险"
• "/risk"

核心理念

1. MECE 切分：6 个维度不重叠、不遗漏，确保"没想到的"不会出现
2. 概率×影响：每个风险都有发生概率和影响程度，不是简单的"有/没有"
3. 可决策：每个风险都有明确的缓解措施和决策建议（接受/修复/监控）
4. 对比视角：不只评"新方案"，还要对比"旧方案"或"替代方案"

适用场景

场景	例子	谁发起
方案评审	"Token 预算制 vs 全量注入，风险对比"	技术负责人
破坏性变更	"重构消息系统，影响多大？"	架构师
上线决策	"这个功能能上线吗？"	产品/技术负责人
技术选型	"用 Redis 还是 MongoDB 做缓存？"	开发者
架构演进	"从单体拆微服务的风险"	CTO

---

MECE 六维度模型

维度定义

┌─────────────────────────────────────────┐
│           MECE 风险六维度                 │
│                                         │
│  ① 正确性   ─ 功能对不对？逻辑有没有漏洞？│
│  ② 兼容性   ─ 跟现有系统冲突吗？旧数据行吗？│
│  ③ 性能容量 ─ 慢不慢？扛不扛得住？         │
│  ④ 安全合规 ─ 有没有安全漏洞？合规吗？     │
│  ⑤ 运维部署 ─ 部署顺利吗？出了事能回滚吗？ │
│  ⑥ 用户体验 ─ 用户感知到变化吗？好还是坏？ │
│                                         │
│  MECE 检验：                             │
│  - 不重叠：每个风险只归入一个维度           │
│  - 不遗漏：任何风险都能归入某个维度         │
└─────────────────────────────────────────┘

各维度检查项

① 正确性（Correctness）

功能逻辑本身对不对

检查项	说明
核心逻辑正确性	主流程的输入→处理→输出是否符合预期
边界条件处理	空值、极大值、极小值、并发
分支覆盖	if/switch 的每个分支是否都有正确处理
数据一致性	多处写入同一数据时是否一致
幂等性	重复执行是否会产生副作用

② 兼容性（Compatibility）

跟已有系统、数据、用户行为的兼容

检查项	说明
API 契约	请求/响应格式是否有 Breaking Change
数据模型	新增/删除/重命名字段对旧数据的影响
前后端版本	新后端 + 旧前端能否正常工作
旧数据迁移	已有数据能否在新逻辑下正确处理
依赖方影响	下游服务/调用方是否需要同步改动

③ 性能与容量（Performance & Capacity）

速度、资源占用、极限承受力

检查项	说明
响应时间	用户可感知的延迟变化
资源消耗	CPU/内存/磁盘/网络的增量
吞吐量	高并发下的表现
数据量	随时间增长后是否有性能退化
外部依赖	LLM API / 第三方服务的延迟和限流

④ 安全与合规（Security & Compliance）

安全漏洞、数据保护、合规要求

检查项	说明
认证授权	是否有未保护的端点
数据泄露	敏感数据是否可能暴露
注入攻击	SQL/NoSQL/命令注入风险
审计日志	关键操作是否有日志记录
合规要求	是否符合数据保护法规

⑤ 运维与部署（Operations & Deployment）

上线过程、监控、回滚

检查项	说明
部署步骤	是否需要特殊的部署流程
回滚方案	出问题能否快速回到上一版
配置变更	是否需要新增/修改环境变量
监控告警	新功能是否有对应的监控指标
依赖变更	是否需要新的中间件/服务

⑥ 用户体验（User Experience）

用户能感知到的变化

检查项	说明
可见变化	用户能否察觉到行为变化
预期管理	变化是否符合用户预期
降级感知	降级/截断时用户是否得到清晰提示
学习成本	用户是否需要改变操作习惯
错误体验	出错时的提示是否友好

---

执行流程

Phase 1: 确定评估范围

用户说 "评估 XXX 的风险" 或 "这样改有什么风险"
  │
  ├─ 识别变更对象：功能名 / 方案名 / 代码变更
  │
  ├─ 确定评估模式：
  │   ├─ 单方案评估：只评一个方案的风险
  │   └─ 对比评估：新方案 vs 旧方案（或方案 A vs 方案 B）
  │
  └─ 扫描变更文件，理解变更范围

Phase 2: 代码/方案扫描

# 1. 获取变更范围
git diff --name-only HEAD~N

# 2. 按维度扫描
# 正确性 → 读核心逻辑代码，找分支和边界
# 兼容性 → 检查 DTO、API 签名、数据模型变更
# 性能    → 检查循环、数据库查询、外部调用
# 安全    → 检查认证中间件、输入验证
# 运维    → 检查配置项、部署依赖
# 体验    → 检查前端变更、错误消息

Phase 3: 输出风险矩阵

---

输出模板

单方案评估

# [方案名] 风险评估报告

> **评估对象**: [一句话描述变更内容]
> **变更范围**: [N 文件, +X/-Y 行]
> **评估日期**: [日期]

## MECE 风险矩阵

| # | 维度 | 风险项 | 概率 | 影响 | 风险等级 | 缓解措施 | 决策 |
|---|------|--------|------|------|----------|----------|------|
| 1 | 正确性 | [具体风险] | 高/中/低 | 高/中/低 | 高/中/低 | [具体措施] | 修复/监控/接受 |
| 2 | 兼容性 | [具体风险] | 高/中/低 | 高/中/低 | 高/中/低 | [具体措施] | 修复/监控/接受 |
| 3 | 性能 | [具体风险] | 高/中/低 | 高/中/低 | 高/中/低 | [具体措施] | 修复/监控/接受 |
| 4 | 安全 | [具体风险] | 高/中/低 | 高/中/低 | 高/中/低 | [具体措施] | 修复/监控/接受 |
| 5 | 运维 | [具体风险] | 高/中/低 | 高/中/低 | 高/中/低 | [具体措施] | 修复/监控/接受 |
| 6 | 体验 | [具体风险] | 高/中/低 | 高/中/低 | 高/中/低 | [具体措施] | 修复/监控/接受 |

### 风险等级计算

高风险 = 概率高 × 影响高，或 概率中 × 影响高 中风险 = 概率中 × 影响中，或 概率高 × 影响低 低风险 = 概率低 × 影响低/中

### 决策标准

修复（上线前必须解决）: 高风险项 监控（上线后重点观察）: 中风险项 接受（已知可控风险） : 低风险项

## 各维度详细分析

### ① 正确性

**扫描范围**: [相关文件列表]

| 检查项 | 状态 | 分析 |
|--------|------|------|
| 核心逻辑 | 无风险 / 有风险 | [具体分析] |
| 边界条件 | 无风险 / 有风险 | [具体分析] |
| 分支覆盖 | 无风险 / 有风险 | [具体分析] |
| 数据一致性 | 无风险 / 有风险 | [具体分析] |

[...其余五个维度同样展开...]

## 总结

| 指标 | 值 |
|------|-----|
| 总风险项 | [N] |
| 高风险 | [N] — 必须修复 |
| 中风险 | [N] — 建议监控 |
| 低风险 | [N] — 可接受 |

**上线建议**: 可上线 / 修复后上线 / 暂缓上线

**修复优先级**（如有高风险）:
1. [最紧急的修复] — 原因
2. [次紧急的修复] — 原因

对比评估

# [方案A] vs [方案B] 风险对比

> **对比目的**: [为什么要对比]
> **评估日期**: [日期]

## MECE 对比矩阵

| 维度 | 方案A 风险 | 方案B 风险 | 胜出方 | 大白话 |
|------|-----------|-----------|--------|--------|
| 正确性 | 低 [描述] | 中 [描述] | A | [一句话对比] |
| 兼容性 | 中 [描述] | 低 [描述] | B | [一句话对比] |
| 性能 | 中 [描述] | 中 [描述] | 平手 | [一句话对比] |
| 安全 | 低 [描述] | 低 [描述] | 平手 | [一句话对比] |
| 运维 | 高 [描述] | 低 [描述] | B | [一句话对比] |
| 体验 | 低 [描述] | 中 [描述] | A | [一句话对比] |

**综合建议**: 选 [方案X]，因为 [理由]

## 各维度详细对比

### ① 正确性

| 对比项 | 方案A | 方案B |
|--------|-------|-------|
| [对比项1] | [A 的情况] | [B 的情况] |
| [对比项2] | [A 的情况] | [B 的情况] |

**结论**: [哪个更好，为什么]

[...其余五个维度同样展开...]

---

与其他技能的协作关系

方案设计完成
  │
  ▼
"评估风险" → 【风险矩阵技能】(MECE 六维度)
  │
  ├─ 高风险 → 修改方案 → 重新评估
  │
  ├─ 中风险 → "追踪一下" → 【路径追踪技能】(看清具体链路)
  │                  └─ "验证一下" → 【人工验证技能】(验证代码)
  │
  └─ 全部低风险 → "冒烟测试" → 【冒烟测试技能】(端到端确认)
                         └─ "交接" → 【交接清单技能】(准备上线)

完整的质量保障链条：

设计阶段           实现阶段           验收阶段           上线阶段
    │                  │                  │                  │
风险矩阵           路径追踪           交叉验证           交接清单
  MECE              追踪流程           多角度验证         文档/测试
"有什么风险"      "怎么跑的"         "做对了吗"         "能上线吗"
    │                  │                  │                  │
    └──────── 冒烟测试（贯穿各阶段）──────────┘                │
                                                          周报总结
                                                         "做了什么"

---

输出质量规则

必须遵循

1. 六维度全覆盖：即使某个维度完全无风险，也要写"无风险"，不能跳过
2. 每个风险有缓解措施：不能只说"有风险"不说"怎么办"
3. 概率和影响分开评：不能笼统说"风险高"，要说"概率低但影响高"还是"概率高但影响低"
4. 对比评估要有结论：不能只列表不下结论，必须说"建议选 X"
5. 大白话列要有：在对比矩阵中，每行都要有普通人能懂的解释

禁止

1. 禁止模糊结论："可能有风险"不行，必须说清楚是什么风险、多大概率
2. 禁止遗漏维度：MECE 的 CE（Collectively Exhaustive）要求每个维度都检查
3. 禁止重复计算：MECE 的 ME（Mutually Exclusive）要求一个风险只归入一个维度
4. 禁止没有决策：每个风险项必须有"修复/监控/接受"的明确建议

---

实际示例

示例：评估"Token 预算制"的风险

# Token 预算制 风险评估报告

> **评估对象**: 多文档上下文组装引入 Token 预算管理（60K 文档 + 30K 历史）
> **变更范围**: 3 文件, +189/-8 行
> **评估日期**: 2026-03-06

## MECE 风险矩阵

| # | 维度 | 风险项 | 概率 | 影响 | 等级 | 缓解措施 | 决策 |
|---|------|--------|------|------|------|----------|------|
| 1 | 正确性 | 章节摘要只展示顶层，丢失子章节 | 高 | 中 | 中 | 改为递归遍历 Children | 修复 |
| 2 | 正确性 | 两个 EstimateTokens 公式不一致 | 低 | 低 | 低 | 正常流程用入库值，fallback 概率低 | 接受 |
| 3 | 兼容性 | 单文档场景行为变化 | — | — | 低 | 代码中明确 `Count > 1` 分支，单文档走原逻辑 | 无风险 |
| 4 | 性能 | 摘要生成增加少量 CPU 开销 | 低 | 低 | 低 | 纯字符串操作，< 1ms | 接受 |
| 5 | 安全 | — | — | — | 低 | 无新增端点、无敏感数据处理 | 无风险 |
| 6 | 运维 | 预算硬编码，不可动态调整 | 中 | 低 | 低 | 当前 100K 适配 128K 窗口，后续可抽配置 | 接受 |
| 7 | 体验 | AI 对摘要文档的理解不够深入 | 中 | 中 | 中 | 提示用户追问触发完整注入 | 监控 |

**上线建议**: 修复 #1 后上线（已修复）

---

注意事项

1. 不过度分析：如果变更只有 1-2 个文件且逻辑简单，写一段总结即可，不需要展开六维度
2. 对比模式优先：当用户在两个方案间犹豫时，主动用对比模式
3. 与路径追踪配合：风险矩阵发现可疑点 → 用路径追踪深入看具体链路
4. 诚实评估：宁可高估风险让团队注意，也不要低估风险导致上线事故
5. 定期回顾：重大功能上线后，对比"预估风险"和"实际问题"，校准评估能力