Menu
基于 MECE 分析法对功能变更做全维度风险评估，按概率与影响在六个不重叠维度（正确性/兼容性/性能容量/安全合规/运维部署/用户体验）打分，产出可决策的风险矩阵报告。触发词："风险评估"、"风险矩阵"、"risk matrix"、"这样改有什么风险"、"/risk"。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | risk-matrix |
| version | 1.0.0 |
| description | 基于 MECE 分析法对功能变更做全维度风险评估，按概率与影响在六个不重叠维度（正确性/兼容性/性能容量/安全合规/运维部署/用户体验）打分，产出可决策的风险矩阵报告。触发词："风险评估"、"风险矩阵"、"risk matrix"、"这样改有什么风险"、"/risk"。 |
版本：v1.0.0 | 状态：已落地 | 触发：
/risk、"风险评估"、"风险矩阵"、"risk matrix"
基于 MECE 分析法（Mutually Exclusive, Collectively Exhaustive），对功能变更进行全维度风险评估。
不用 MECE 的风险评估：
"可能会影响性能"
"可能会有 bug"
"可能不兼容"
→ 维度重叠、遗漏多、无法决策
用 MECE 的风险评估：
┌─────────────── 所有风险 ───────────────┐
│ │
│ ┌─────────┐ ┌─────────┐ ┌──────────┐ │
│ │ 正确性 │ │ 兼容性 │ │ 性能容量 │ │ ← 不重叠
│ └─────────┘ └─────────┘ └──────────┘ │
│ ┌─────────┐ ┌─────────┐ ┌──────────┐ │
│ │ 安全合规│ │ 运维部署│ │ 用户体验 │ │ ← 不遗漏
│ └─────────┘ └─────────┘ └──────────┘ │
│ │
└─────────────────────────────────────────┘
每个格子独立评估 → 有结论 → 可决策
| 场景 | 例子 | 谁发起 |
|---|---|---|
| 方案评审 | "Token 预算制 vs 全量注入，风险对比" | 技术负责人 |
| 破坏性变更 | "重构消息系统，影响多大？" | 架构师 |
| 上线决策 | "这个功能能上线吗？" | 产品/技术负责人 |
| 技术选型 | "用 Redis 还是 MongoDB 做缓存？" | 开发者 |
| 架构演进 | "从单体拆微服务的风险" | CTO |
┌─────────────────────────────────────────┐
│ MECE 风险六维度 │
│ │
│ ① 正确性 ─ 功能对不对？逻辑有没有漏洞？│
│ ② 兼容性 ─ 跟现有系统冲突吗？旧数据行吗？│
│ ③ 性能容量 ─ 慢不慢？扛不扛得住？ │
│ ④ 安全合规 ─ 有没有安全漏洞？合规吗？ │
│ ⑤ 运维部署 ─ 部署顺利吗？出了事能回滚吗？ │
│ ⑥ 用户体验 ─ 用户感知到变化吗？好还是坏？ │
│ │
│ MECE 检验： │
│ - 不重叠：每个风险只归入一个维度 │
│ - 不遗漏：任何风险都能归入某个维度 │
└─────────────────────────────────────────┘
功能逻辑本身对不对
| 检查项 | 说明 |
|---|---|
| 核心逻辑正确性 | 主流程的输入→处理→输出是否符合预期 |
| 边界条件处理 | 空值、极大值、极小值、并发 |
| 分支覆盖 | if/switch 的每个分支是否都有正确处理 |
| 数据一致性 | 多处写入同一数据时是否一致 |
| 幂等性 | 重复执行是否会产生副作用 |
跟已有系统、数据、用户行为的兼容
| 检查项 | 说明 |
|---|---|
| API 契约 | 请求/响应格式是否有 Breaking Change |
| 数据模型 | 新增/删除/重命名字段对旧数据的影响 |
| 前后端版本 | 新后端 + 旧前端能否正常工作 |
| 旧数据迁移 | 已有数据能否在新逻辑下正确处理 |
| 依赖方影响 | 下游服务/调用方是否需要同步改动 |
速度、资源占用、极限承受力
| 检查项 | 说明 |
|---|---|
| 响应时间 | 用户可感知的延迟变化 |
| 资源消耗 | CPU/内存/磁盘/网络的增量 |
| 吞吐量 | 高并发下的表现 |
| 数据量 | 随时间增长后是否有性能退化 |
| 外部依赖 | LLM API / 第三方服务的延迟和限流 |
安全漏洞、数据保护、合规要求
| 检查项 | 说明 |
|---|---|
| 认证授权 | 是否有未保护的端点 |
| 数据泄露 | 敏感数据是否可能暴露 |
| 注入攻击 | SQL/NoSQL/命令注入风险 |
| 审计日志 | 关键操作是否有日志记录 |
| 合规要求 | 是否符合数据保护法规 |
上线过程、监控、回滚
| 检查项 | 说明 |
|---|---|
| 部署步骤 | 是否需要特殊的部署流程 |
| 回滚方案 | 出问题能否快速回到上一版 |
| 配置变更 | 是否需要新增/修改环境变量 |
| 监控告警 | 新功能是否有对应的监控指标 |
| 依赖变更 | 是否需要新的中间件/服务 |
用户能感知到的变化
| 检查项 | 说明 |
|---|---|
| 可见变化 | 用户能否察觉到行为变化 |
| 预期管理 | 变化是否符合用户预期 |
| 降级感知 | 降级/截断时用户是否得到清晰提示 |
| 学习成本 | 用户是否需要改变操作习惯 |
| 错误体验 | 出错时的提示是否友好 |
用户说 "评估 XXX 的风险" 或 "这样改有什么风险"
│
├─ 识别变更对象：功能名 / 方案名 / 代码变更
│
├─ 确定评估模式：
│ ├─ 单方案评估：只评一个方案的风险
│ └─ 对比评估：新方案 vs 旧方案（或方案 A vs 方案 B）
│
└─ 扫描变更文件，理解变更范围
# 1. 获取变更范围
git diff --name-only HEAD~N
# 2. 按维度扫描
# 正确性 → 读核心逻辑代码，找分支和边界
# 兼容性 → 检查 DTO、API 签名、数据模型变更
# 性能 → 检查循环、数据库查询、外部调用
# 安全 → 检查认证中间件、输入验证
# 运维 → 检查配置项、部署依赖
# 体验 → 检查前端变更、错误消息
# [方案名] 风险评估报告
> **评估对象**: [一句话描述变更内容]
> **变更范围**: [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 追踪流程 多角度验证 文档/测试
"有什么风险" "怎么跑的" "做对了吗" "能上线吗"
│ │ │ │
└──────── 冒烟测试（贯穿各阶段）──────────┘ │
周报总结
"做了什么"
# 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 后上线（已修复）
识别每日验收、PR 验收、commit 验收、未发布分支验收、缺陷复测、视觉回归和发布前验收等场景，并为 create-visual-test-to-kb 生成测试范围、指差法步骤、预期结果、证据链、截图回读和报告结构。Use when the user asks to optimize or run visual acceptance across different scenarios, asks whether yesterday's changes, a PR, a commit range, or an unpublished branch were really accepted, or needs PR/commit results to map to screenshots and MAP knowledge base reports.
Convert PRs, commits, yesterday's changes, or release scope into a test-minded acceptance design before visual execution. Use when the user asks for daily acceptance, visual acceptance, PR/commit acceptance, proof that code changes really affected product behavior, coverage planning, fusion testing, evidence strength, or when screenshots/reports looked related but failed to prove the assigned task.
工业级功能验收/视觉测试全流水线（MAP 验收标准 v2）——模拟人类的浏览器取证 + 标准化验收报告 + 归档进 CDS 验收中心并出直达深链。职责分离：验收报告永远按项目归 CDS（平台自带、证据链内置），MAP 等系统通过知识库开放协议从 CDS 拉取展示，技能不再分流到 MAP 知识库。一个技能内含三段：标准/模板、模拟人类浏览器取证（点击导航进入、禁地址栏直达、双主题截图、ZZ 照做风画框标序号 stepClick/stepShot）、报告归档（命名结构固定，**每次归档强制输出可达地址**：CDS 直达深链 /reports，匿名对外用 /r/token）。默认报告走 **ZZ 照做风**（全大标题 + 一句话一步 + 逐步配图 `{{IMG:}}` + 文字在上图在下 + 变化处画框 + 分支顺序讲，同岗位照做必复现）。归档前有**强制准入校验**：目标/档位/Verdict/截图数/证据完整性/报告结构不达标直接拒收（入口准则，杜绝"什么都能进"）。项目无关，改 acceptance.config.json 即可跨仓库复用；无 CDS/离线退化为本地 md+截图。触发词："视觉验收"、"验收"、"视觉测试"、"验收归档"、"归档验收报告"、"create visual test"、"/视觉验收"、"/验收"。
CDS (Cloud Dev Space) core skill — hosts the canonical cdscli Python CLI, handles authentication (static AI_ACCESS_KEY / dynamic pairing / project key), manages env vars and project keys, owns CDS service self-update, defines the preview-URL slug formula, and acts as dispatcher when the user's intent is ambiguous between cold-path scanning and hot-path debugging. Activates when the user mentions CDS generically without specifying scan-or-deploy, configures CDS credentials, manages env / keys, updates the CDS service code itself, or asks about preview URL conventions. Does NOT directly perform project scanning (delegates to cds-project-scan, the cold path) or deployment debugging (delegates to cds-deploy-pipeline, the hot path). Trigger phrases include "cds 认证", "AI_ACCESS_KEY", "项目 key", "cds 自更新", "cds self-update", "预览地址公式", "配 cds 环境变量", "/cds", "/cds-auth", and the bare word "cds" when the user has not yet picked a direction.
Generates weekly project reports from git history. Collects commits, PRs, and contributor data, analyzes and categorizes changes, then produces a structured Chinese-language weekly report (overview, completed items, next-week priorities) saved to doc/report.YYYY-WXX.md. Trigger words: "生成周报", "写周报", "weekly report", "本周总结".
从 git 历史生成「今日大事早知道」开发日报，并发布到知识库（文档空间）。按「新增功能多讲 → 优化/修复次之 → 计划/遗留垫底」的固定权重分层叙事。自动 find-or-create「日报知识库」并出分享链。触发词："生成日报"、"写日报"、"今日大事"、"日报"、"daily report"、"/daily"、"今天干了啥"。