Menu
基于 MECE 分析法对功能变更做全维度风险评估，按概率与影响在六个不重叠维度（正确性/兼容性/性能容量/安全合规/运维部署/用户体验）打分，产出可决策的风险矩阵报告。触发词："风险评估"、"风险矩阵"、"risk matrix"、"这样改有什么风险"、"/risk"。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
| 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"、"今天干了啥"。