周四的技术方案焦虑
周一接到需求，周二设计架构，周三写方案。到了周四，方案写完了。
但你心里隐隐不安。
性能会不会扛不住？安全有没有漏洞？以后维护的人会不会骂你？
你把这个方案丢给同事看，对方说"还行吧"。但你不确定他是不是在敷衍。
大多数技术方案的问题，不是写方案的人看不到的。
你陷在细节里，盯着自己写的那几行代码，容易忽略全局风险。同事看了一眼，说"还行"，但不一定真的看懂了。
这个模板的作用就是：让AI当你的技术雷达，用三个维度帮你扫一遍方案，提前发现那些上线后会炸的坑。
不吹毛求疵。不找茬。只找真正会影响上线风险的问题。
核心模板：技术方案评审器
把下面这段复制到 Claude 或 ChatGPT（推荐 Claude，对技术内容的理解更精准）：
你是一位有10年以上经验的资深架构师，擅长做技术方案评审。你的风格是：直接、务实、关注风险而非风格偏好。
【项目背景】
- 项目名称：[一句话描述]
- 业务场景：[这个方案解决什么业务问题]
- 预期规模：[比如：日活10万 / 并发峰值1000 / 数据量级TB级]
- 技术栈：[主要语言和框架]
- 团队情况：[比如：3人后端团队 / 有专职运维]
【技术方案文档】
[粘贴你的技术方案，可以是Markdown、纯文字描述、或伪代码]
【你特别担心的点】（可选）
[如果你心里已有疑虑，比如：这个架构能不能支撑大促？缓存策略对不对？]
请帮我从以下三个维度做评审：
第一部分：性能风险
- 在高负载情况下，哪些环节会成为瓶颈？
- 数据库查询有没有N+1、全表扫描、缺少索引的风险？
- 缓存策略是否合理？有没有缓存击穿/穿透/雪崩的隐患？
- 外部依赖（第三方API、消息队列）有没有超时和熔断机制？
- 给出性能评分（1-10分，10分最好）
第二部分：安全风险
- 有没有常见的安全问题？（SQL注入、XSS、CSRF、越权访问等）
- 敏感数据（用户信息、支付数据）的处理是否合规？
- 认证和授权机制是否完善？
- 有没有日志泄露敏感信息的风险？
- 给出安全评分（1-10分，10分最好）
第三部分：可维护性风险
- 代码结构是否清晰？有没有过度耦合？
- 有没有\"未来改不动\"的设计？
- 扩展性如何？业务量翻10倍时会怎样？
- 文档和注释是否足够？
- 给出可维护性评分（1-10分，10分最好）
第四部分：总结建议
- 总分（三个维度加权平均）
- 最危险的3个问题（按紧急程度排序）
- 如果只能改一个地方，改哪里收益最大？
- 整体评价：这个方案可以上线吗？还是建议回去重做？
三种高频场景变体
变体一：数据库设计评审
你的方案重点是数据库设计，需要AI帮你检查表结构是否合理：
我正在设计一个[业务场景]的数据库，表结构如下：
[粘贴你的建表SQL或ER图描述]
请帮我做以下检查：
1. 范式 vs 反范式——当前设计在查询效率和数据冗余之间平衡得如何？
2. 索引设计——哪些字段应该加索引？哪些索引可能是多余的？
3. 数据类型——有没有用错类型的地方？（比如用VARCHAR存日期、用INT存大数字）
4. 扩展性——如果业务量翻10倍，这张表会成为瓶颈吗？怎么优化？
5. 有没有潜在的数据一致性问题？
只说问题，不说好话。
变体二：API架构评审
你的方案是一个新的API服务，需要检查接口设计是否合理：
我要设计一个新的[业务名称]API服务，接口设计如下：
[粘贴你的接口设计文档，包括路径、方法、请求参数、响应格式]
请帮我检查：
1. 接口设计是否符合RESTful规范？有没有不合理的PUT/DELETE？
2. 参数校验是否完整？边界情况考虑了吗？
3. 错误处理是否统一？有没有遗漏的错误码？
4. 分页、排序、过滤的设计是否合理？
5. 接口之间的耦合度——有没有可以拆分的独立能力？
6. 鉴权设计是否到位？有没有越权风险？
用表格列出问题和修改建议。
变体三：系统架构图评审
你的方案是一个分布式系统，需要检查整体架构：
我正在设计一个[系统名称]的分布式架构，整体架构如下：
[粘贴架构图描述或文字说明，包括：服务划分、通信方式、数据存储、中间件选型]
请帮我从架构角度评审：
1. 服务划分是否合理？有没有应该拆分或合并的？
2. 服务之间的通信方式（同步/异步）是否恰当？
3. 数据一致性方案（CAP取舍）是否合理？
4. 单点故障在哪里？有没有合适的容灾方案？
5. 可扩展性——水平扩展的瓶颈在哪个环节？
6. 运维复杂度——这个架构需要多少运维投入？
请指出最影响长期健康的3个架构决策。
快速版（5分钟搞定）
赶时间？用这个精简版：
帮我评审以下技术方案：
[粘贴方案描述]
重点检查：
1. 上线后最可能出问题的3个点
2. 每个问题的影响范围和修复建议
3. 一句话总结：这个方案能上线吗？
不用客套，直接说问题。
使用技巧
把方案写详细。 AI评审的质量取决于你提供信息的详细程度。只丢一段话进去，得到的回复也会很泛。尽量提供：业务背景、技术选型、核心逻辑、数据量级。
先问风险，再问建议。 评审的顺序很重要。先让AI找出风险点，再让它给修改建议。如果你反过来，AI可能会先夸你写得不错，然后才淡淡提一两个小问题。
让AI扮演"魔鬼代言人"。 在模板末尾加一句："假设你是一个挑剔的CTO，会对这个方案提出什么质疑？"这样能帮你看到方案中你一直没注意到的弱点。
对比多个AI的回答。 同一个方案，分别丢给Claude和ChatGPT，对比它们的评审结果。不同模型的关注点不同，交叉验证能发现更多盲点。
评审完别放着。 把AI指出的问题列成TODO，安排在接下来几天逐一修复。评审的价值不在于"发现问题"，而在于"解决问题"。
效果示例
输入：
【项目背景】
- 项目名称：用户积分系统
- 业务场景：电商平台用户消费后获得积分，积分可兑换商品或抵扣现金
- 预期规模：日活50万，峰值并发1000 QPS
- 技术栈：Java Spring Boot + MySQL + Redis
- 团队情况：3人后端团队
【技术方案】
积分系统核心逻辑：
1. 用户下单后，MQ异步通知积分服务
2. 积分服务消费MQ消息，调用积分核心逻辑
3. 积分变化写入MySQL，同时更新Redis缓存
4. 用户查询积分时，先读Redis，缓存未命中则读MySQL
5. 每天凌晨对账，确保MySQL和Redis数据一致
AI输出：
第一部分：性能风险
- MQ消费延迟风险：50万日活、峰值1000 QPS的情况下，如果订单量集中爆发（比如秒杀活动），MQ消息堆积可能导致积分更新延迟。建议：增加消费者并行度，设置消费延迟告警。
- Redis缓存穿透：如果用户查询一个不存在的用户ID的积分，会穿透到MySQL。建议：对不存在的用户缓存一个空值（TTL 5分钟）。
- 对账窗口期的数据不一致：凌晨对账期间，MySQL和Redis可能出现短暂不一致，用户查询积分可能不准。建议：对账时加版本号，前端查询时校验版本。
性能评分：7/10
第二部分：安全风险
- 积分篡改风险：如果积分接口没有严格的权限校验，恶意用户可能通过修改请求参数来增加自己的积分。建议：所有积分变动接口必须服务端计算，不接受客户端传入的积分值。
- 并发导致积分超发：如果同一个订单被重复消费（MQ重复投递），可能导致积分重复发放。建议：加幂等性校验，用订单ID做唯一键。
安全评分：6/10
第三部分：可维护性风险
- 对账逻辑耦合在核心代码中：如果每天凌晨的对账逻辑和业务逻辑混在一起，维护成本高。建议：将对账逻辑抽成独立模块或服务。
- 缺少监控和告警：方案中没有提到积分系统的监控指标（消费延迟、错误率、缓存命中率）。建议：补充监控方案。
可维护性评分：6/10
第四部分：总结建议
总分：6.3/10
最危险的3个问题：
- 并发导致积分超发（安全风险，直接影响资损）
- MQ消费延迟在高峰期可能导致用户体验问题
- 缺少监控，出问题后无法快速定位
如果只能改一个地方：加幂等性校验，防止积分超发。这是资损风险，必须优先解决。
整体评价：方案整体可行，但有几个关键风险需要在上线前修复。建议先解决幂等性和监控问题，再上线。
技术方案评审 vs Code Review的区别
|| 维度 | Code Review | 技术方案评审 | ||——|————|————-| || 对象 | 代码 | 设计思路 | || 时机 | 代码写完后 | 代码写之前 | || 视角 | 实现细节 | 架构和系统性 | || 问题类型 | bug、风格、可读性 | 性能、安全、扩展性 | || 修复成本 | 低（改几行代码） | 高（可能推倒重来） | || 最佳搭档 | 每周固定做 | 每个重要方案做 |
什么时候不该用
- 简单CRUD接口。 如果只是标准的增删改查，没有复杂业务逻辑，不需要技术评审。
- 方案还没成型。 如果你只有一个模糊的想法，评审没有意义。先想清楚再评。
- 你已经有了技术评审会议。 这个模板是补充，不是替代。如果你有code review机制，先用模板做一轮自检，再开会。
- 你对技术栈完全不熟悉。 如果你用AI评审一个你不熟悉的语言或框架，AI可能会给出错误的建议。确保你对技术栈有基本了解。
组合使用技巧
技术方案评审 + 周四代码质量审查。 方案评审在前，代码审查在后。方案评审确保方向对，代码审查确保细节好。两个步骤结合，质量和风险都有保障。
技术方案评审 + 周四向上管理。 评审完成后，用thursday-upward-report模板把评审结果整理成一份汇报，发给上级和技术团队。让评审结论成为团队共识。
技术方案评审 + 周五数据复盘。 如果方案涉及数据查询或性能优化，周五用friday-data-analysis做数据验证，确认方案在实际数据下的表现是否符合预期。
什么时候用这个模板
- 新系统的架构设计完成后
- 重要功能的方案评审前
- 技术方案需要向团队或上级汇报前
- 自己对方案质量没把握时
- 上线前想做最后一道安全审查
进阶用法
让AI生成评审检查清单。 评审完后，让AI根据你项目的具体情况生成一份"上线前检查清单"，逐项确认后再上线。
建立你的评审知识库。 把每次评审的结果保存下来。三个月后回头看，你会发现自己最常犯的错误类型——这就是你的避坑手册。
把评审结果变成文档。 评审通过后，让AI把评审过程和结论整理成一份正式的技术方案文档，存入团队的知识库。
写在最后
周四下午，方案写完了。
你可以直接丢给同事看，等对方说"还行"。也可以花10分钟用这个模板，让AI帮你扫一遍。
前者靠运气。后者靠方法。
好的技术方案不是写出来的，是改出来的。 第一次写出来的方案永远不完美——性能盲点、安全漏洞、维护陷阱，总有一些是你看不到的。
用AI当你的第一道筛子，把明显的问题提前筛掉。剩下的，再交给同事做人工评审。
上线前的最后一道防线，不是测试，是评审。
现在就打开你的技术方案，跑一遍这个模板。你会惊讶于AI指出的那些你一直忽略的风险。