chain-spec-risk-metrics

链式规范、风险与指标

目录

• 工作流
• 常见模式
• 护栏
• 快速参考

概述

此技能将三个组成部分整合为一份全面的规划文档：

1. 规范 - 清晰定义你要构建或更改的内容（范围、需求、方法、时间线）
2. 风险分析 - 通过事前复盘（“假设我们失败了——原因是什么？”）识别可能出错的地方，并创建包含缓解措施的风险登记表
3. 成功指标 - 定义可衡量的结果，用于跟踪进展并验证是否成功

不适用场景： 如果只需要编写规范，请使用 one-pager-prd 或 adr-architecture。如果只需要风险分析，请使用 project-risk-register。如果只需要指标，请使用 metrics-tree。如果要集思广益，探索不同方案，请使用 brainstorm-diverge-converge。

快速示例：

计划： 将单体架构迁移到微服务

规范： 拆分为 5 个服务（身份验证、用户、订单、库存、支付），设置 API 网关和共享数据模式

风险：

• 服务间的数据一致性问题（高）→ 实施带补偿机制的 saga 模式
• 网络跳转导致性能下降（中）→ 使用生产环境流量模式进行负载测试

指标：

• 部署频率（目标：每周 10 次以上，基线：每周 2 次）
• API p99 延迟（目标：< 200ms，基线：150ms）
• 平均恢复时间（目标：< 30min，基线：2 小时）

工作流

复制此清单并跟踪进度：

Chain Spec Risk Metrics Progress:
- [ ] Step 1: Gather initiative context
- [ ] Step 2: Write comprehensive specification
- [ ] Step 3: Conduct premortem and build risk register
- [ ] Step 4: Define success metrics and instrumentation
- [ ] Step 5: Validate completeness and deliver

步骤 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。

常见模式

事前验尸法

1. 设定场景：「现在是 [6/12/24] 个月后。这项计划遭遇了灾难性失败。」
2. 集思广益，分析失败原因：每位利益相关者分别先独立写出 3-5 个失败原因
3. 归类并排序：将相似的失败原因分组，并投票评估其可能性和影响
4. 转化为风险登记表：将每种失败模式转化为一项风险，并制定缓解计划

风险登记表结构

对于每项已识别的风险，记录：

• 风险描述：具体的失败模式（不要写含糊的「项目延期」）
• 类别：技术、运营、组织、外部
• 可能性：低/中/高（或概率 %）
• 影响：低/中/高（或成本估算）
• 缓解策略：你将采取什么措施来降低可能性或影响
• 负责人：负责监控和应对这项风险的人
• 状态：开放、已缓解、已接受、已关闭

指标框架

先行指标（预测未来的成功）：

• 部署频率、代码审查速度、事件检测时间

滞后指标（衡量结果）：

• 正常运行时间、用户采用率、收入影响、客户满意度

反向指标（你不愿牺牲的方面）：

• 代码质量、团队士气、安全态势、用户隐私

护栏

• 不要跳过任何组成部分——没有风险分析的规范会留下盲点；没有指标的风险分析则无法验证缓解措施
• 明确具体地编写规范——「提升性能」不算规范；「将 API 的 p99 延迟从 500ms 降至 200ms」才算
• 量化风险——使用可能性 × 影响评分来确定优先级；不要一视同仁地对待所有风险
• 确保指标可衡量——「改善用户体验」无法衡量；「将结账完成率从 67% 提高到 75%」才可以
• 指定负责人——每项风险和指标都需要明确的负责人来监控并采取行动
• 明确说明假设——记录你对资源、时间安排和依赖项的假设
• 纳入反向指标——始终明确成功不意味着牺牲什么
• 根据经验持续更新——这是一份持续更新的文档；在里程碑之后重新审视并更新风险和指标

快速参考

组成部分	使用时机	资源
模板	具有已知模式的常规计划	resources/template.md
方法论	复杂的多阶段项目、新颖的风险	resources/methodology.md
示例	了解优秀成果的样子	resources/examples/
评分标准	交付前进行验证	resources/evaluators/rubric_chain_spec_risk_metrics.json