# architecture-review

> 当在评估系统架构、平台设计或高层代码库结构时，关注可扩展性、可靠性、耦合、数据一致性或运行风险时使用。

- Author: Dacheng Gao
- Repository: dacheng-learn/ai
- Version: 20260207114251
- Stars: 0
- Forks: 0
- Last Updated: 2026-02-07
- Source: https://github.com/dacheng-learn/ai
- Web: https://mule.run/skillshub/@@dacheng-learn/ai~architecture-review:20260207114251

---

---
name: architecture-review
description: 当在评估系统架构、平台设计或高层代码库结构时，关注可扩展性、可靠性、耦合、数据一致性或运行风险时使用。
---

# 架构评审

## 概述
基于证据评估风险，输出含风险等级与修复建议的检查清单。除非要求，不做重构/重设计。

## 建议角色
- 🏗️ **解决方案架构师**：主导系统拓扑、一致性与可扩展性评估。
- 🔒 **安全专家**：识别认证、授权与数据流风险。
- 🚀 **DevOps 工程师**：评估部署、回退、SLI/SLO 与可观测性。

## 必需输入（缺失则询问）
- 目标、SLO 与非功能性需求
- 流量、数据规模与增长曲线
- 拓扑图与数据流
- 关键用户路径与故障模式
- 约束：延迟、成本、合规、团队规模
- 事故历史或已知热点

## 输出格式
使用如下结构：

```markdown
检查清单
- 领域: <边界/数据/规模/可靠性/安全/可观测性/部署/成本>
  风险: 严重 (Critical) | 重要 (Important) | 建议 (Suggestion)
  证据: <文件/指标/链路追踪/图示备注>
  影响: <用户或系统影响>
  修复: <具体改动>

摘要
- 阻断发布风险: <数量 + 简短清单>
- 下一步: <前 1-3 个修复项>
```

## 评审流程
1. 明确范围与约束
2. 收集证据（文档、代码触点、指标）
3. 分领域识别风险
4. 提出范围清晰的修复方案
5. 按影响与紧迫度排序

## 检查清单领域
- 边界与耦合
- 数据流与一致性
- 可扩展性与容量
- 可靠性与故障恢复
- 安全与访问控制
- 可观测性与可运维性
- 部署与回滚
- 成本与效率

## 快速参考
| 步骤 | 输出 |
| --- | --- |
| 范围 | 明确假设或缺失输入 |
| 证据 | 引用文档/指标/路径 |
| 风险 | 含严重度的检查清单 |
| 修复 | 具体、可界定的行动 |
| 优先级 | 前 1-3 个修复项 |

## 示例
```markdown
检查清单
- 领域: 可扩展性
  风险: 重要 (Important)
  证据: API 读取全量数据，未做分页
  影响: 峰值负载下 p95 延迟飙升
  修复: 增加分页与索引；限制单页大小

摘要
- 阻断发布风险: 0
- 下一步: 增加分页，增加索引
```

## 常见错误
- 没有证据支撑的泛化建议
- 单项缺少风险等级或修复
- 把评审当成重构或重新设计
- 忽略运行时约束或 SLO
- 输入缺失时不写明假设

## 借口 vs 事实
| 借口 | 事实 |
| --- | --- |
| “没有文档，只能给泛化建议” | 询问缺失输入或明确假设。 |
| “只要一个快速 yes/no” | 给出含阻断发布风险的检查清单。 |
| “架构评审就是重构” | 先诊断，只修被要求的部分。 |
| “我熟悉系统，不需要证据” | 引用工件或指标，避免猜测。 |

## 红旗 - 立刻停止
- 没有范围或约束
- 检查清单缺少风险等级或修复
- 没有证据或假设说明
- 只有摘要，没有检查清单