| 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"
核心理念
- MECE 切分：6 个维度不重叠、不遗漏，确保"没想到的"不会出现
- 概率×影响：每个风险都有发生概率和影响程度，不是简单的"有/没有"
- 可决策：每个风险都有明确的缓解措施和决策建议（接受/修复/监控）
- 对比视角：不只评"新方案"，还要对比"旧方案"或"替代方案"
适用场景
| 场景 | 例子 | 谁发起 |
|---|
| 方案评审 | "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: 代码/方案扫描
git diff --name-only HEAD~N
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 追踪流程 多角度验证 文档/测试
"有什么风险" "怎么跑的" "做对了吗" "能上线吗"
│ │ │ │
└──────── 冒烟测试（贯穿各阶段）──────────┘ │
周报总结
"做了什么"
输出质量规则
必须遵循
- 六维度全覆盖：即使某个维度完全无风险，也要写"无风险"，不能跳过
- 每个风险有缓解措施：不能只说"有风险"不说"怎么办"
- 概率和影响分开评：不能笼统说"风险高"，要说"概率低但影响高"还是"概率高但影响低"
- 对比评估要有结论：不能只列表不下结论，必须说"建议选 X"
- 大白话列要有：在对比矩阵中，每行都要有普通人能懂的解释
禁止
- 禁止模糊结论："可能有风险"不行，必须说清楚是什么风险、多大概率
- 禁止遗漏维度：MECE 的 CE（Collectively Exhaustive）要求每个维度都检查
- 禁止重复计算：MECE 的 ME（Mutually Exclusive）要求一个风险只归入一个维度
- 禁止没有决策：每个风险项必须有"修复/监控/接受"的明确建议
实际示例
示例：评估"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-2 个文件且逻辑简单，写一段总结即可，不需要展开六维度
- 对比模式优先：当用户在两个方案间犹豫时，主动用对比模式
- 与路径追踪配合：风险矩阵发现可疑点 → 用路径追踪深入看具体链路
- 诚实评估：宁可高估风险让团队注意，也不要低估风险导致上线事故
- 定期回顾：重大功能上线后，对比"预估风险"和"实际问题"，校准评估能力
