技术方案评审不是"挑刺大会"，而是把一个人的决策风险摊到桌面上、让团队一起买单的过程。本文分享一套在中小型团队里跑了三年的评审方法，从会前准备、会中推进到会后落地，帮你把评审会变成真正能提高命中率的决策仪式。
一、为什么很多评审会开成了形式
我见过最典型的翻车现场：架构师滔滔不绝讲了四十分钟 PPT，最后老板问"所以这个方案到底行不行？"，全场沉默。问题通常出在三个地方：
- 目标不清：评审的是"能不能做"，还是"值不值得做"，还是"有没有更好的做法"，没提前对齐。
- 信息过载：一堆名词轰炸，缺少可量化的对比维度。
- 没有决策机制：讨论了两个小时，没人拍板，会后各干各的。
好的评审会应该像法庭：有原告（提案人）、有被告（挑战方）、有证据（数据与原型）、有法官（决策者），最后必须有判决。
二、会前准备：让评审从"听汇报"变成"审材料"
2.1 提案人必须交的四份材料
| 材料 | 作用 | 篇幅建议 |
|---|---|---|
| 问题陈述 | 说清楚要解决什么、不解决什么 | 半页 A4 |
| 候选方案 | 至少两个可行方案，不能只有一个 | 每个方案 1 页 |
| 决策矩阵 | 用同一套维度给方案打分 | 1 张表 |
| 风险清单 | 列出前三项最大风险和兜底措施 | 半页 A4 |
2.2 问题陈述的 5W2H 模板
提案人可以用下面这个清单自检，避免一上来就聊技术细节：
What：要做什么功能 / 解决什么问题
Why：业务价值是什么，不做会怎样
Who：目标用户是谁，涉及哪些系统
When：时间约束，是否有硬性 deadline
Where：部署环境，是否跨云或跨国
How：初步思路
How much：资源估算（人天、服务器、第三方费用）2.3 一个极简的提案文档结构
我团队现在用的模板长这样，通常写 3 到 5 页就够了：
# 技术方案评审：XX 系统重构
## 1. 背景与目标
- 当前痛点：接口 P99 延迟 1.2s，客诉率上升
- 目标：P99 降到 200ms 以内，支持未来一年 10 倍流量
## 2. 约束条件
- 预算：新增服务器不超过 5 台
- 时间：2 个月内上线
- 人力：后端 2 人，运维 0.5 人
## 3. 候选方案
### 方案 A：引入 Redis 缓存 + 异步化
### 方案 B：分库分表 + 读写分离
### 方案 C：升级为 ClickHouse 分析型查询
## 4. 决策矩阵
（见下文表格）
## 5. 推荐方案与理由
推荐方案 A，理由：改动面最小、风险可控、能在预算内达成目标。
## 6. 风险与兜底
- 风险 1：缓存击穿 → 加互斥锁 + 空值缓存
- 风险 2：数据一致性问题 → 采用 Cache-Aside + 消息队列补偿
- 风险 3：上线回滚 → 保留旧接口，支持灰度切换
三、决策矩阵：让讨论有锚点
决策矩阵是评审会的核心。它把"我觉得方案 A 更好"变成"方案 A 在延迟维度得分更高，但在复杂度维度得分更低"。
3.1 常用维度
| 维度 | 说明 | 权重建议 |
|---|---|---|
| 业务价值 | 是否直接解决用户痛点或带来营收 | 25% |
| 技术风险 | 失败概率、回滚难度 | 20% |
| 实施成本 | 人天、基础设施、License | 20% |
| 可维护性 | 文档、监控、接手难度 | 15% |
| 扩展性 | 能否支撑未来 1-2 年增长 | 10% |
| 团队熟悉度 | 是否有现成经验，学习曲线多陡 | 10% |
3.2 评分示例
假设我们要选一个支付网关的限流方案，三个候选：
| 维度 / 权重 | 方案 A：Redis + Lua | 方案 B：Sentinel | 方案 C：自研计数器 |
|---|---|---|---|
| 业务价值 25% | 8 | 7 | 6 |
| 技术风险 20% | 7 | 8 | 4 |
| 实施成本 20% | 7 | 8 | 5 |
| 可维护性 15% | 7 | 8 | 4 |
| 扩展性 10% | 8 | 7 | 5 |
| 熟悉度 10% | 6 | 9 | 5 |
| 加权总分 | 7.25 | 7.75 | 4.85 |
用 Python 算加权分的脚本可以这样写：
scores = {
"方案 A：Redis + Lua": {"业务价值": 8, "技术风险": 7, "实施成本": 7, "可维护性": 7, "扩展性": 8, "熟悉度": 6},
"方案 B：Sentinel": {"业务价值": 7, "技术风险": 8, "实施成本": 8, "可维护性": 8, "扩展性": 7, "熟悉度": 9},
"方案 C：自研计数器": {"业务价值": 6, "技术风险": 4, "实施成本": 5, "可维护性": 4, "扩展性": 5, "熟悉度": 5},
}
weights = {"业务价值": 0.25, "技术风险": 0.20, "实施成本": 0.20, "可维护性": 0.15, "扩展性": 0.10, "熟悉度": 0.10}
for name, vals in scores.items():
total = sum(vals[k] * weights[k] for k in weights)
print(f"{name}: {total:.2f}")2.4 约束条件要前置
很多方案讨论了半天才发现预算不够或时间不允许。约束条件必须在会前就贴在文档最前面，常见约束包括：
- 时间约束：是否有发布会、大促、监管 deadline 等硬节点。
- 预算约束：新增机器、第三方服务、人力成本的上限。
- 合规约束：数据跨境、等保、SOC2 等安全合规要求。
- 技术约束：必须使用现有技术栈、不能引入新语言、必须兼容旧接口等。
约束不是限制创新，而是缩小搜索空间。没有约束的方案评审，很容易变成纸上谈兵。
四、会中推进：主持人的四个动作
评审会最容易失控的是讨论发散。主持人（通常是技术负责人或架构师）要持续做四件事：
4.1 先对齐决策标准
开场第一句应该是："今天我们用哪几个维度来评估？权重是否需要调整？" 而不是"请主讲人开始"。
4.2 强制"先听后问"
我常用的规则：
- 主讲人 15 分钟陈述，不打断。
- 挑战方每人 3 分钟提问，不能带解决方案。
- 提案人 5 分钟回应。
- 开放讨论 15 分钟。
4.3 把观点拉回维度
一旦有人说"我觉得这个方案不好"，主持人要追问："你是指风险高、成本高，还是可维护性差？"
4.4 明确决策方式
不同事情用不同决策方式：
| 决策方式 | 适用场景 | 注意点 |
|---|---|---|
| 负责人拍板 | 技术细节、低风险改动 | 事后通知相关方 |
| 多数表决 | 多个方案各有千秋 | 权重提前公开 |
| 共识决策 | 高风险、跨团队 | 允许"不同意但执行" |
| 升级决策 | 涉及预算或战略 | 准备一页纸摘要 |
4.5 评审中的心理学
再理性的流程也绕不开人。几个我踩过的坑：
- 沉没成本："这个方案我已经做了两周原型了"——投入的时间不能成为选择的理由。
- 从众压力：大家纷纷点头，其实没听懂。主持人要会停下来问："有谁还没明白，可以现在问。"
- 立场之争：后端觉得前端方案复杂，前端觉得后端接口不合理。这时候要把讨论拉回用户价值。
一个小技巧：把"你错了"换成"这个方案在哪个维度上得分会降低"。同样是否定，后者不会让人立刻进入防御状态。
五、常见陷阱与应对
| 陷阱 | 表现 | 应对 |
|---|---|---|
| 完美方案执念 | 反复比较，迟迟不决策 | 设 deadline，明确"足够好"的标准 |
| 权威绑架 | senior 一开口，其他人不敢说话 | 主持人最后发言， junior 先提问 |
| 技术自嗨 | 为了用新技术而用新技术 | 所有方案必须回答"不这么做会怎样" |
| 忽视运维成本 | 只算开发人天，不算上线和值班成本 | 决策矩阵加入可维护性权重 |
| 没有兜底方案 | 只聊成功路径 | 每个推荐方案必须配回滚策略 |
六、会后落地：把决议变成代码
评审会结束不等于事情做完。我习惯发三份东西：
6.1 会议纪要模板
## 会议结论
- 选定方案：方案 B（Sentinel 限流）
- 决策依据：加权分最高，团队熟悉度最好
- 负责人：张三
- 截止日期：2026-08-20
## 待办事项
- [ ] 搭建 Sentinel 测试环境（李四，8-12）
- [ ] 编写限流规则 DSL（王五，8-15）
- [ ] 补充监控大盘（赵六，8-18）
## 风险跟踪
- 风险：Sentinel 控制台单点故障
- 措施：评估 Nacos 配置中心双活方案，两周内复评6.2 用脚本追踪待办
如果团队用 GitHub/GitLab，可以用 issue 自动创建待办：
# 从会议纪要生成 issue 列表
cat meeting_notes.md | grep -E "^- \[ \]" | sed 's/- \[ \] //' | while read task; do
gh issue create --title "$task" --label "tech-review" --repo myorg/myrepo
done6.3 设立复评节点
任何涉及新技术、新架构的方案，都要在上线后 2 周和 2 个月复评。复评只问三个问题：
- 当初担心的风险发生了吗？
- 实际成本和估算差多少？
- 如果重来，还会选这个方案吗？
6.4 让决议不被遗忘
评审会最大的浪费是：结论很明确，两周后没人记得。除了会议纪要，我还建议：
- 写入 Wiki 或知识库：把决策矩阵和最终结论沉淀下来，方便半年后复盘。
- 关联项目里程碑：把待办事项拆进迭代计划，而不是躺在会议纪要里。
- 指定决策 Owner：每个决议必须有且只有一个负责人，避免"我以为你负责"。
如果团队用飞书或钉钉，可以把待办机器人接进来，到期自动提醒。
七、我的 checklist
每次评审前，我会把这个清单贴在会议邀请里：
□ 问题陈述是否包含 5W2H？
□ 是否至少有两个候选方案？
□ 决策矩阵维度是否提前公开？
□ 推荐方案是否有回滚策略？
□ 风险清单是否列出前三项？
□ 会议是否有明确决策方式？
□ 会后是否有待办和复评节点？八、什么时候必须开，什么时候可以省
评审会不是越多越好。我的判断标准：
| 场景 | 建议 | 替代方式 |
|---|---|---|
| 引入新框架 / 新语言 | 必须评审 | — |
| 跨团队改动 | 必须评审 | — |
| 涉及资金或第三方采购 | 必须评审 | — |
| 单模块内部小改动 | 可以省略 | 代码审查 + 文档备注 |
| 纯 bug 修复 | 可以省略 | PR 说明即可 |
| 已有明确规范的重复工作 | 可以省略 | 按规范执行 |
关键原则是：如果失败成本高于开会成本，就开；否则用异步方式解决。
九、写在最后
技术方案评审的本质不是选"最正确的方案"，而是在信息不完整、资源有限的情况下，让团队以可接受的风险做出最一致的选择。把评审流程化、把决策可视化、把落地责任化，方案评审才会从"不得不开的会"变成"真正值回票价的会"。