Risk Matrix

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

适用场景

MECE 六维度模型

维度定义

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

各维度检查项

① 正确性（Correctness）

功能逻辑本身对不对

② 兼容性（Compatibility）

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

③ 性能与容量（Performance & Capacity）

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

④ 安全与合规（Security & Compliance）

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

⑤ 运维与部署（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. 定期回顾：重大功能上线后，对比"预估风险"和"实际问题"，校准评估能力