solution-review

方案评审

角色：适用于任何拟议方案（代码或非代码）的实施前评审框架。它旨在尽早发现决策层面的问题（问题找错、风险评估失准、忽视可运维性、成本与价值权衡不佳），避免投入精力后才发现。它是一项方法论增强：PDCA 宿主会在 frontmatter dependencies 中声明此技能，并在前置检查后调用它（若缺少此技能，宿主会在启动时中止）。当方案涉及代码时，它与 code-design-review 互为补充；后者负责评审代码层面的设计质量。

详细的框架条目（作者、年份、方法、来源）以及所有阻断／非阻断标准，均见 reference.md。

此技能为何存在

大多数方案评审只关注四个问题：能解决问题吗？会有副作用吗？可行吗？符合惯例吗？ 这些问题必不可少，但还不够。它们能发现实施层面的问题，却会漏掉决策层面的问题：

• 方案解决了正确的问题，却在没有必要时变得不可逆（把单向门当成双向门）。
• 方案的失败模式从未被逐一列出，因此第一次生产事故就会让人措手不及。
• 方案能用，却无法运维——没有监控、没有回滚路径，也没人考虑值班负担。
• 方案的成本超过了价值，却没人算过这笔账。
• 方案在技术上正确，却超出团队的认知能力，难以维护。

此技能新增五个战略维度，用于暴露这些问题，并根据方案的可逆性调整评审深度。核心要义是：

方案即使通过全部四个核心维度，仍可能是错误的决策。评审深度应随不可逆性而增加，而非随信心而增加。

何时使用

强烈的使用信号（符合任意一项即可）：

• 你即将批准、否决或迭代某个拟议方案、计划或设计——在开始实施之前。
• 方案涉及架构决策、迁移、依赖项变更或不可逆操作（架构变更、数据迁移、公共 API 契约）。
• 有人询问“这种做法靠谱吗？”“可能会出什么问题？”或“我们应该这么做吗？”
• 你需要生成一份包含结构化通过／失败理由的评审报告，而不是仅凭直觉判断。

此技能评审的是拟议中的方案（实施前）。它不同于实施后的代码评审技能（后者会依据标准评审已完成的差异）。两者都很重要，但应用于生命周期的不同阶段。

与其他技能的关系

技能	职责	与此技能的关系
code-design-review	代码层面的设计质量（耦合、内聚、复杂度、安全性）	当方案涉及代码时，两者都要使用：此技能检查决策，code-design-review 检查代码工艺。此技能涵盖的范围更广。
PDCA 宿主	宿主工作流	PDCA 宿主通过 frontmatter dependencies 引用此技能（缺少时 → 宿主中止）。此技能深入覆盖宿主工作流中的“评审方案”阶段。对于这层关系，以宿主为 SoT。

评审框架

共九个维度，分为两层。四个核心维度适用于每个方案，均为必需。五个战略维度适用于可逆性超过阈值的方案（见维度 5），并建议用于所有方案。

核心维度（每个方案，每次评审）

1. 有效性 — 方案是否彻底解决了根本原因／需求？核心逻辑是否合理？应用方案后，问题是否仍会在某些方面持续存在？
2. 副作用与风险 — 其他地方会出现什么问题（功能性副作用）？可能出现哪些非功能性退化（性能、安全性、可维护性）？识别出的风险是否配有缓解措施？
3. 可行性 — 变更范围、依赖项以及受影响的文件／模块是否具体且可执行？在当前约束（时间、预算、知识、基础设施）下是否确实可行？
4. 规范与标准合规性 — 方案是否符合原始需求／规范／PRD？是否遵循现有项目模式和文档约定？

战略维度（根据可逆性校准深度，参见维度 5）

5. 可逆性校准（Bezos，Type 1 vs Type 2 Decisions，2016 年 Amazon 股东信）— 这是单向门（不可逆：数据迁移、公共 API、架构变更）还是双向门（可轻松回滚）？单向门需要最严格的评审；双向门则应优先考虑速度。将单向门误判为双向门，是代价最高的评审错误。
6. 失效模式分析（FMEA — Failure Mode and Effects Analysis，ASQ／NASA）— 列举方案可能的失效方式：对于每个组件，存在哪些失效模式？其严重性 × 发生可能性 × 可检测性如何？必须在批准前缓解风险优先级数较高的失效。
7. 可运维性（Google SRE，Production Readiness Review，2016）— 方案上线后是否能够运维？是否有 SLI／SLO？是否具备监控和告警？是否有回滚路径？值班负担如何？无法运维的可用方案，迟早会引发事故。
8. 成本与价值（CBAM — SEI／CMU，Cost Benefit Analysis Method，2003；以及 WSJF — Reinertsen，Principles of Product Development Flow，2009）— 投入是否值得预期成果？延迟的代价是什么？是否有成本更低、但能实现 80% 价值的替代方案？需计入长期维护／变更放大成本。较低的实施成本（包括 AI 辅助编码）本身并不能证明在存在更优且可行的替代方案时，采用结构更弱的设计是合理的。
9. 团队认知适配度（Skelton & Pais，Team Topologies，2019）— 方案是否符合团队当前的认知能力？是否需要团队不具备且无法快速掌握的知识？团队无法维护的技术上更优方案是负担，而非资产。

每个维度的详细方法、应用步骤和来源引文见 reference.md。

如何应用

1. 首先对可逆性进行分类。 在评审其他内容之前，先判断：这是单向门还是双向门？这将决定后续所有维度的评审深度。（参见 reference.md → Reversibility。）
2. 评估四个核心维度。 任何方案都必须评估这些维度。每个维度都要给出通过／不通过的结论，并提供具体理由。
3. 根据可逆性分类要求的深度，评估五个战略维度。 对于双向门，快速评估即可；对于单向门，每个战略维度都应进行专门评估。
4. 生成结构化评审报告（见下方“输出”），内容包括：各维度的结论、按严重程度排序的问题、阻塞／非阻塞分类，以及总体结论。
5. 以阻塞问题作为准入门槛。 任何阻塞问题都意味着方案未通过。非阻塞问题应作为建议记录，但不会阻止方案通过。

阻塞项与非阻塞项（摘要）

阻塞项（符合任意一条 → 方案不通过）：

• 方案未能完全覆盖根本原因 / 需求（有效性缺口）。
• 已识别的中 / 高风险没有缓解措施。
• 变更范围或依赖关系不明确，无法据此制定可执行的计划。
• 方案与现有设计模式或编码规范冲突。
• 可能的副作用会引入新错误或破坏现有功能，却未得到处理。
• （仅限不可逆决策） 严重性高 × 发生可能性高的故障模式没有缓解措施。
• （仅限不可逆决策） 方案没有回滚路径且不可逆。
• （仅限不可逆决策） 成本明显超过收益，且没有考虑更低成本的替代方案。
• 明显存在一种结构性 / 架构性替代方案，在长期可维护性方面更优、在当前范围内可行，却仅因较弱的方案实现起来更快而被拒绝，且没有审慎、经过深思熟虑地接受债务。（当方案涉及代码时，应遵循 code-design-review 的架构审查门槛。）

非阻塞项（作为建议指出，不要阻止通过）：

• 已有缓解措施的低风险事项。
• 不影响正确性或结构的风格偏好。
• 可推迟到后续迭代的性能改进（非结构性改进）。
• 不会影响结构 / 变更放大效应的风格层面优化。
• 有意为之且有文档记录、并制定了偿还计划的技术债（包括明确接受较弱的架构）。

完整的阻塞 / 非阻塞标准及针对不同框架的阈值见 reference.md。

输出

审查报告的结构如下：

【Solution review report】
- Subject: [solution name / summary]
- Reversibility: [one-way door / two-way door] → review depth: [maximum / standard]
- Core dimensions:
  1. Effectiveness: ✅/❌ [reasoning]
  2. Side effects & risks: ✅/❌ [reasoning]
  3. Feasibility: ✅/❌ [reasoning]
  4. Spec compliance: ✅/❌ [reasoning]
- Strategic dimensions (by reversibility depth):
  5. Reversibility calibration: [classification + rationale]
  6. Failure-mode analysis: ✅/❌/N/A [top failure modes + RPN]
  7. Operability: ✅/❌/N/A [monitoring/rollback/on-call assessment]
  8. Cost vs value: ✅/❌/N/A [cost-value assessment]
  9. Team cognitive fit: ✅/❌/N/A [team fit assessment]
- Issue list: [#] [description] [severity: blocking/non-blocking]
- Verdict: ✅ pass / ❌ fail
- [On ❌] Optimization guidance: [per-issue improvement direction]

反模式（禁止的做法）

1. 对非代码方案跳过战略维度——配置 / 流程 / 工具变更也可能是不可逆决策（迁移一旦执行就无法撤销；流程变更也难以恢复）。决定评估深度的是可逆性，而非方案类型。
2. 风险评估含糊——只说“可能存在一些风险”，却不列明故障模式、严重性和发生可能性。应使用维度 6 中的 FMEA 结构，而不是凭直觉判断。