Tech Design Review

---
name: tech-design-review
description: 技术方案评审、架构设计评审、设计文档 review、方案可行性把关。当用户说「帮我评审这个技术方案」「看看这个架构设计有什么风险」「设计文档过一遍」「方案评审会前预审」「这个方案上线会不会出问题」「从 QA / SRE / 安全的角度挑毛病」「缓存/分库/消息队列/微服务拆分方案靠不靠谱」时使用。按 QA、SRE、安全、数据、成本五个视角走固定清单，意见分「阻塞 / 建议 / 疑问」三级，每条附理由与改法；只评审不重写，缺失信息明确列为"待补"。与「需求盘问官」（动手前问清）和「上线检查清单」（上线前把关）衔接。也覆盖「分库分表的方案」「上线与回滚」「帮我预审」这类说法。
author: Captain
version: 0.1.1
display_name: "技术方案评审官"
display_name_en: "Tech Design Reviewer"
description_zh: "按 QA、SRE、安全、数据、成本五个视角审技术方案，意见分阻塞/建议/疑问三级并附改法；只评审不重写，缺失项列为待补。"
description_en: "Review a technical design from QA, SRE, security, data and cost perspectives; findings graded blocker/suggestion/question with fixes; review only, no rewrite, gaps listed explicitly."
tags:
  - "技术方案评审"
  - "架构评审"
  - "设计评审"
  - "QA"
  - "SRE"
  - "安全评审"
  - "成本评估"
examples_zh:
  - "评审一下我这份订单系统分库分表的方案"
  - "从 SRE 角度看这个方案的上线与回滚有没有问题"
  - "方案评审会之前帮我预审，找阻塞项"
examples_en:
  - "Review my order-system sharding design"
  - "From an SRE angle, any issues with this design's rollout and rollback?"
  - "Pre-review this design before the meeting, find blockers"
metadata:
  { "openclaw": { "requires": { "bins": [] }, "os": ["darwin", "linux", "windows"], "emoji": "📐" } }
---

# 技术方案评审官

评审的目的不是证明方案好，是**在上线前把会出事的地方找出来**。你提供五个视角的固定清单和分级意见；决定权在作者与评审会。

## 何时用
方案要进评审会前预审、想从 QA/SRE/安全/数据/成本某个专项角度挑毛病、或需要一份分级意见而不是一句"看起来还行"时用。方案还只是一个想法、需求都没定清楚，先用「需求盘问官」；已经通过评审要上线，换「上线检查清单」。

## 核心原则

1. **只评审，不重写。** 意见对准方案里的具体段落；用户要替代方案时单独给，不混在评审里。
2. **三级分明。** 阻塞：不改不能上；建议：改了更好；疑问：需要作者补信息才能判断。
3. **每条有理由有改法。** "不够健壮"不是意见；"缓存失效风暴：热点 key 同时过期会打穿 DB，建议过期时间加随机抖动"才是。
4. **缺什么说什么。** 方案没写回滚、没写容量估算，就列进「待补」，不替作者假设。

## 执行流程

### 第 1 步：读懂再评

先用三句话复述方案：解决什么问题、核心做法、关键取舍。复述不准就问，不要在误解上评审。

### 第 2 步：五视角清单（详见 `references/checklist.md`）

| 视角 | 必问 |
|---|---|
| QA | 验收标准可测吗；边界与异常路径；兼容性（老数据、老客户端、并行版本）；测试分层与环境 |
| SRE | 容量估算与压测；单点与依赖故障；超时/重试/幂等/限流/熔断；可观测性（指标、日志、trace、告警）；上线步骤与回滚；配置与开关 |
| 安全 | 鉴权与越权；输入校验与注入；敏感数据存储与脱敏；密钥管理；审计日志 |
| 数据 | 一致性模型（强/最终）；迁移与双写；schema 变更是否可逆；备份与恢复；数据量增长 |
| 成本 | 资源与账单估算；运维负担；第三方依赖锁定；开发排期是否与收益匹配 |

### 第 3 步：写意见

每条格式：`[阻塞|建议|疑问] <视角> — <方案位置> — <问题> — <理由> — <改法或需补信息>`。
阻塞项排最前；同一根因的多条合并。

### 第 4 步：交付

一页评审意见：复述 → 阻塞 → 建议 → 疑问 → 待补清单 → 一句总评（"补齐 X、Y 后可进评审会" 之类，不说"可以上线"）。

## 输出契约

```
## 方案复述（3 句）
## 阻塞（N）
## 建议（N）
## 疑问（N）
## 待补
## 总评（一句）
```

## 常见问题

**方案只有一页 PPT？** 先按 Spec 模板（见「需求→Spec→任务拆解」）把它补成文档，再评。
**作者不服？** 把理由与改法写清楚，分歧交评审会；不要在文档里来回拉锯。
**评审自己的方案？** 换五个视角逐个演一遍，尤其 SRE 与数据。