名称: chain-spec-risk-metrics 描述: 在规划高风险倡议（如迁移、启动、战略变化）时使用，这些倡议需要清晰的规格、主动的风险识别（预死分析/风险登记）和可衡量的成功标准。当用户提到“计划这个迁移”、“启动策略”、“实施路线图”、“什么可能出错”、“我们如何衡量成功”，或者当高影响决策需要全面规划，包括风险缓解和仪表化时调用。
规格风险指标链
目录
目的
此技能帮助您为高风险倡议创建全面计划，通过将三个关键组件链式结合：清晰规格、主动风险分析和可衡量成功指标。确保倡议定义明确、风险预测和缓解、进展可客观追踪。
何时使用此技能
使用此技能当您需要：
- 规划复杂实施 - 迁移、基础设施变更、系统重新设计需要详细规格
- 启动新倡议 - 产品、功能、程序需要风险评估和成功测量
- 做出高风险决策 - 战略选择，其中失败模式必须被识别和监控
- 协调跨职能工作 - 倡议需要清晰规格以对齐和风险透明
- 请求全面规划 - 用户询问“计划这个迁移”、“创建实施路线图”、“什么可能出错？”
- 建立问责制 - 需要明确的成功标准和风险所有者进行治理
触发短语：
- “计划这个[迁移/启动/实施]”
- “为…创建路线图”
- “…什么可能出错”
- “我们如何衡量…的成功”
- “编写包含风险和指标的规格”
- “带风险缓解的全面计划”
何时不使用此技能
跳过此技能当：
- 快速决策 - 低风险选择不需要完整的预死分析处理
- 仅规格 - 如果用户只需要规格而不需要风险/指标分析（使用一页PRD或ADR架构代替）
- 仅风险分析 - 如果只专注于识别风险（使用项目风险登记或事后分析代替）
- 仅指标 - 如果只定义KPI（使用指标树代替）
- 已决定并执行 - 使用事后分析或回顾反思进行回顾
- 头脑风暴替代方案 - 使用头脑风暴发散收敛首先生成选项
这是什么？
规格风险指标链是一个元技能，将三种互补技术结合成一个全面的规划工件：
- 规格 - 清晰定义您正在构建/更改的内容（范围、要求、方法、时间线）
- 风险分析 - 通过预死分析（“想象我们失败了 - 为什么？”）识别可能出错的地方，并创建带缓解措施的风险登记
- 成功指标 - 定义可衡量的结果以跟踪进展和验证成功
快速示例：
倡议： 从单体架构迁移到微服务
规格： 分解为5个服务（认证、用户、订单、库存、支付）、API网关、共享数据模式
风险：
- 服务间数据一致性问题（高） → 实施带有补偿的saga模式
- 网络跳转导致的性能下降（中） → 使用生产流量模式进行负载测试
指标：
- 部署频率（目标：每周10+次，基线：每周2次）
- API p99延迟（目标：< 200ms，基线：150ms）
- 平均恢复时间（目标：< 30分钟，基线：2小时）
工作流程
复制此清单并跟踪进度：
规格风险指标链进度：
- [ ] 步骤1：收集倡议上下文
- [ ] 步骤2：编写全面规格
- [ ] 步骤3：进行预死分析并构建风险登记
- [ ] 步骤4：定义成功指标和仪表化
- [ ] 步骤5：验证完整性并交付
步骤1：收集倡议上下文
询问用户倡议目标、约束（时间/预算/资源）、利益相关者、当前状态（基线）和期望结果。澄清这是绿场构建、迁移、增强还是战略变化。参见resources/template.md获取完整上下文问题。
步骤2：编写全面规格
创建详细规格，覆盖范围（包含/排除内容）、方法（架构/方法论）、要求（功能/非功能）、依赖项、时间线和成功标准。对于标准倡议，使用resources/template.md；对于复杂多阶段程序，参见resources/methodology.md获取分解技术。
步骤3：进行预死分析并构建风险登记
运行预死分析练习：“想象从现在起12个月后，这个倡议失败了。出了什么问题？”识别技术、操作、组织和外部维度的风险。为每个风险记录可能性、影响、缓解策略和所有者。参见预死分析技术和风险登记结构部分，或resources/methodology.md获取高级风险评估方法。
步骤4：定义成功指标和仪表化
识别领先指标（早期信号）、滞后指标（结果测量）和反指标（您不愿意牺牲的内容）。为每个指标指定当前基线、目标值、测量方法和跟踪频率。参见指标框架并使用resources/template.md获取标准结构。
步骤5：验证完整性并交付
使用resources/evaluators/rubric_chain_spec_risk_metrics.json自检完整工件。确保规格清晰可操作、风险全面带缓解措施、指标测量实际成功，并且所有三个组件相互增强。最低标准：所有标准平均得分≥3.5。
常见模式
预死分析技术
- 设置场景：“这是[6/12/24]个月后。这个倡议灾难性地失败了。”
- 头脑风暴失败原因：每个利益相关者写3-5个失败原因（首先独立）
- 聚类和优先级排序：分组相似失败，投票可能性和影响
- 转换为风险登记：每个失败模式成为带缓解计划的风险
风险登记结构
对于每个识别出的风险，记录：
- 风险描述：特定失败模式（不是模糊的“项目延迟”）
- 类别：技术、操作、组织、外部
- 可能性：低/中/高（或概率%）
- 影响：低/中/高（或成本估计）
- 缓解策略：您将做什么来减少可能性或影响
- 所有者：谁监控和响应此风险
- 状态：开放、缓解、接受、关闭
指标框架
领先指标（预测未来成功）：
- 部署频率、代码审查速度、事件检测时间
滞后指标（测量结果）：
- 正常运行时间、用户采用、收入影响、客户满意度
反指标（您不愿意牺牲的内容）：
- 代码质量、团队士气、安全态势、用户隐私
护栏
- 不要跳过任何组件 - 没有风险的规格 = 盲点；没有指标的风险 = 未验证的缓解措施
- 在规格中具体 - “提高性能”不是规格；“将API p99延迟从500ms减少到200ms”是
- 量化风险 - 使用可能性×影响分数来优先级排序；不要平等对待所有风险
- 使指标可衡量 - “更好的UX”不可衡量；“将结账完成率从67%提高到75%”是
- 分配所有者 - 每个风险和指标需要清晰的监控和执行所有者
- 明确陈述假设 - 记录您对资源、时间线、依赖项的假设
- 包括反指标 - 总是定义成功不意味着牺牲什么
- 随着学习更新 - 这是一个活文档；在里程碑后重新访问以更新风险/指标
快速参考
| 组件 | 何时使用 | 资源 |
|---|---|---|
| 模板 | 具有已知模式的标准倡议 | resources/template.md |
| 方法论 | 复杂多阶段程序、新颖风险 | resources/methodology.md |
| 示例 | 查看好的样子 | resources/examples/ |
| 评分标准 | 交付前验证 | resources/evaluators/rubric_chain_spec_risk_metrics.json |