架构评审这件事做久了真的会有点“麻”。我参加过的评审会少说也有几十场最典型的一个画面是架构师打开文档讲了一个小时评审团在最后十分钟提了几个问题然后结论是“总体方案可行按计划推进”。等系统上线后出了性能问题、扩展性不够、安全漏洞被通报回头看当时的评审记录发现那些隐患其实早就有征兆只是当时没人问、没人提。后来我开始琢磨一件事能不能把评审从“靠人发挥”变成“靠流程兜底”答案落在了一张清单上。但传统清单有个很尴尬的问题——它太“通用”了翻来覆去就是性能、安全、可用性那几项放哪个项目都能用放哪个项目都不疼不痒。直到我开始用AI辅助生成架构评审清单把每个项目独特的背景、约束、风险喂进去让它按需生成有针对性的检查问题评审会的质量才真正上了一个台阶。这篇文章我就把自己的完整做法、提示词写法、清单框架、踩过的坑一次性讲清楚。1. 先聊透架构评审为什么需要一张好清单1.1 评审不是在找茬是在补认知盲区很多人对架构评审有个误解觉得评审就是挑毛病、找漏洞是站在对立面审问架构师。但真正做过评审的人会明白评审最有价值的地方是帮整个团队补齐认知盲区。我见过一个真实场景一个做订单中台的方案架构师把微服务拆分、消息队列选型、数据一致性方案讲得头头是道评审会上大家也都集中在讨论“订单状态机怎么设计”“Kafka和RocketMQ该选哪个”。结果方案通过了上线后运维同事问了一句这个系统的日志规范、监控指标、告警阈值定义了吗全场安静了。没人想过这件事因为大家的目光都被“架构亮点”吸引走了。这就是评审最大的风险——它被“看起来重要的东西”牵着走而不是被“容易出问题的东西”牵着走。人的注意力天生会集中在方案中最复杂、最亮眼的部分而真正的隐患往往藏在那些没有人提过的角落里。清单的作用就是把这些角落一个个翻出来逼着评审者挨个过一遍。1.2 AI的定位用清单把“隐性经验”显性化既然清单这么重要为什么很多团队还是不做我观察下来就一个原因写清单这件事看起来太简单做起来太难。简单地说任何人都能写“检查系统性能”“评估系统安全性”这种大而化之的条目。但要写出一份真正有用的清单需要你能针对当前这个具体方案提出具体的、可验证的问题。比如“订单查询接口在峰值1万TPS下数据库连接池和缓存命中率的预期是多少超时阈值怎么设”这种问题。这种问题来自哪里来自丰富的实战经验来自你对这个业务领域、这个技术栈的深入理解。大多数评审参与者并没有这种经验储备。这时候AI就能帮上忙了。它的角色不是“评审专家”而是一个“经验放大器”你把方案的上下文告诉它它用海量的历史知识帮你想出那些你没想到的检查角度你再用自己的判断去筛选、校准、补充。AI负责拓宽覆盖面人负责判断深度配合起来比任何一方单干都强。我把它总结为一个公式高质量评审清单 AI的覆盖面 × 人的校准力。AI的价值不在“替代经验”而在“把隐性经验显性化”让一个经验没那么丰富的人也能拿出经验丰富的人才会问的问题。2. 怎么设计评审清单框架六个检查维度的取舍2.1 我从老清单里归纳出的六维骨架用AI生成清单的第一步不是直接让它列问题而是先给它一个框架。没有框架的AI生成很容易给你铺出一张包含七八十个问题的长纸看着很丰富实际没法用。我自己用下来比较稳定的框架是六个维度这六个维度几乎能覆盖我遇到过的所有架构评审场景维度核心关注点典型风险信号功能与业务匹配方案是否真正解决业务问题技术方案“过度设计”与业务规模不匹配性能与容量峰值场景下的响应时间、吞吐量、资源用量只在压测环境验证过平均负载没验证峰值安全与合规认证鉴权、数据加密、隐私保护、审计日志把安全放“二期再做”扩展性与演进新节点如何接入、旧逻辑如何兼容模块耦合严重加一个字段要改五个服务可维护性与可观测性日志、监控、告警、排障链路是否完整系统上线后“全黑”出问题只能重启部署与运营灰度、回滚、灾备、配置管理发布流程靠手工没有标准预案这六个维度不是我想出来的而是复盘了大量“上线后出问题”的案例后归纳出来的。你会发现一个规律绝大多数事故都能映射到至少一个维度被评审时忽略了。2.2 每个维度里最容易漏掉的三个子问题框架有了接下来要让AI在每个维度里“往深挖”。我自己的经验是直接让AI“列六个维度的问题”它给出来的东西还是会偏泛。但如果你在提示词里逐个维度做引导告诉它这个维度下容易漏掉哪些子问题效果会好非常多。性能与容量维度最容易漏掉的是数据增长曲线很多方案只算了“现在的数据量”没算“一年后的数据量”。订单表三个月增长两千万行之后当前索引还撑得住吗AI 会引导你从“存量”和“增量”两个视角去问问题。慢请求雪崩一个接口变慢导致上游服务线程池被占满拖垮整个链路。这属于性能问题的“传染性”评审时单看一个接口是看不出来的。资源预算的归属每个服务扩容的预算谁出、容量谁来评估这看似是管理问题但架构方案里如果完全不写容量规划后面必然扯皮。安全与合规维度最容易漏掉的是默认凭据和默认配置中间件装完用默认密码、默认端口这在评审文档里经常出现但也经常被一笔带过没人较真。数据流视角的权限设计功能上每个接口都有权限控制但数据导出的接口是不是也能被普通用户调用权限不能只看功能入口要看数据能走到哪里。第三方组件的漏洞响应机制方案里引入了一个开源组件谁负责跟踪它的安全公告没有Owner的安全是空谈。可维护性与可观测性维度最容易漏掉的是失败时的可诊断性系统正常时的观测大家都想到了但系统失败时能不能快速定位错误日志里有没有traceId贯穿全链路配置变更的审计线上配置被改了一个参数有没有记录谁改的、什么时候改的、影响范围多大依赖故障的降级方案依赖的第三方服务挂了我们是跟着挂还是有降级预案降级后的体验边界是什么你会发现我举的这九个子问题都不是从“教科书”上来的而是从实际事故里长出来的。这也说明了AI辅助的一个关键用法你不需要自己记住所有经验但你需要能识别AI给出来的哪些问题是真正切中要害的。3. AI生成清单实操从上下文输入到三遍打磨3.1 第一遍把背景喂足让AI“知道自己在审什么”很多人用AI生成清单时有个坏习惯直接一句话过去“帮我写一份架构评审清单”。AI这时候只能给你一份放之四海而皆准的“标准答案”看起来工整实际没用。我实际的用法是先用一个“上下文描述模板”把当前方案的关键信息喂给AI。我常用的模板大致是我正在评审一个软件系统的架构设计方案请帮我生成一份架构评审清单。 以下是方案的背景信息 - 系统定位[一句话描述系统是干什么的比如“面向内部运营人员的工单管理平台”] - 核心使用场景[列出主要场景比如“客服创建工单、工单流转审批、数据报表导出”] - 目标用户规模[预估用户数/并发量写不准确没关系写量级即可] - 关键约束[技术栈限定、部署环境、合规要求等比如“必须部署在私有云使用XX框架”] - 技术亮点与主要选型[比如“微服务架构Kafka异步削峰MySQL分库分表Redis缓存”] - 我担心的重点[把你心里最没底的方向写出来比如“数据一致性问题”“高可用切换机制”] - 已知风险[已经识别出来的问题比如“目前只压测了单节点性能集群模式未验证”] 请基于以上信息从功能与业务、性能与容量、安全与合规、扩展性与演进、 可维护性与可观测性、部署与运营六个维度分别生成评审检查问题。 要求每个问题具体、可验证不要使用“是否考虑”“是否充分”这类模糊表述。这里有个关键点就是“我担心的重点”这一栏。很多人的直觉是希望AI全面覆盖所以不给任何重点提示。但我的经验恰恰相反告诉AI你最担心什么它反而能生成得更全面。因为你担心的方向意味着这个方案确实有风险AI会顺着这个风险去发散出相关联的问题——这会触发它寻找“连锁风险”的能力比你让它漫无目的地扫描要好得多。3.2 第二遍用角色和边界约束AI的评审视角第一遍生成的清单通常问题数量在30到60之间质量还行但仍然会有不少“通用项”夹在里面。第二遍要做的事情是让AI切换不同角色去审视这份方案。架构评审很有意思的一点在于不同角色眼里同一个方案的风险是完全不同的。我做过的评审里最有价值的问题常常不是架构师提的而是运维、安全、测试、业务方从自己视角抛出来的“跨界问题”。为了让AI也具备这种“跨界视角”我会在提示词里追加一段请再分别从以下角色视角对刚才的方案提出额外的问题每个角色3~5个 1. 运维工程师关注部署、监控、日志、故障恢复、容量规划 2. 安全工程师关注认证鉴权、数据泄露、漏洞管理、合规审计 3. 测试工程师关注可测性、测试环境、数据构造、灰度验证 4. 业务产品经理关注交付时间、功能边界、非功能需求的业务影响 5. 新加入团队的初级开发关注文档是否充分、代码是否容易上手、架构是否过度复杂 这些角色视角的问题如果与上一轮的六个维度问题重复请自动去重 最终请把不同角色提出的问题整合分节不要按角色分类输出要按问题归属的技术主题分类。这一步做完的体验通常很惊喜。运维视角经常能问出“没有预案如何处理失败节点”这种硬核问题安全视角能问出“接口是否暴露了内部网络结构”这种细节问题而新员工视角能问出“没有架构文档如何让人接手”这种让架构师冷汗直冒的问题。3.3 第三遍按风险等级分级把问题变成可执行的检查项第二遍生成的清单已经比较全了但还有一个致命问题没法直接用。一份六十个问题的清单在评审会上根本走不完。你不可能让评审团逐条过一遍大家会疲劳到最后再重要的问题也流于形式。所以第三遍打磨的目标是“分级”而且不是简单地标个高/中/低而是要让每个问题都变成“可执行的检查项”。我通常让AI做三件事第一把问题按风险等级分成三档请把上面的所有问题分成三组 - P0必须当场确认并有明确结论的问题如果没有结论评审不通过。 - P1必须在启动开发前给出明确方案的问题可以在评审会后由架构师补充。 - P2可以留到开发/测试阶段持续跟踪的问题不影响评审通过但要记录在案。第二给每个P0问题补充“通过标准”。这是我认为整个流程里最有价值的一步对于所有P0问题请补充什么情况下算“通过”什么情况下算“不通过” 请给出明确的判断条件比如数据指标阈值、必须有文档、必须有压测报告等。第三把整个清单导出成表格。这一步是落地到评审会动作的关键我会让AI输出一个包含“问题描述、风险等级、检查方法、通过标准、负责人、备注”的表格框架我再用它整合评审记录。到这一步一份可用的评审清单就成型了。以我最近评审的一个订单系统为例三遍之后输出的清单大概是这样的结构P0问题 9 个包括“分库分表键如何选取按什么维度路由”“订单状态与支付状态的最终一致性如何保证对账机制是什么”“峰值下单场景下库存扣减的并发上限和超卖容忍度是多少”等P1问题 18 个包括“缓存与数据库的双写一致性问题容忍多少秒不一致”“消息队列积压超过阈值如何告警积压恢复策略是什么”等P2问题 27 个包括“是否需要有定时清理历史订单的机制”“是否提供批量导出接口给财务系统”等这个量级评审会两个小时是能走完的。P0的问题逐条过P1快速过方案P2记录跟踪节奏会清晰很多。4. 清单落地从“生成出来”到“评审好用”4.1 让问题可验证而不是“正确的废话”AI生成清单最容易出现的问题我给它起了个名字叫“正确的废话”。典型表现是“系统是否具备足够的性能冗余”“方案是否充分考虑了安全性”“数据一致性是否得到保障”。这种问题你没法回答因为“足够”“充分”“保障”这些词根本没法量化架构师只能说“我们认为OK”评审就滑过去了。我的实践是在提示词里硬性要求“禁止使用无法量化的判断词”并强制AI把每个问题改写成可以验证的形式。改写的方法是“加条件、加指标、加场景”。来看三个例子“系统是否具备足够的性能冗余”→ 改为“在峰值流量按预估1万TPS运行30分钟的情况下核心接口的P99响应时间是否低于800ms是否给出过压测报告”“方案是否充分考虑安全性”→ 改为“管理后台的登录是否支持多因素认证API网关是否对全部外部请求做了鉴权是否提供最近一次安全扫描的报告”“数据一致性是否得到保障”→ 改为“订单创建和支付回调之间的状态不一致窗口期最长是多少秒如果出现状态不一致采用何种补偿机制是否设计了定时对账任务”你对比一下就能看出来前者是态度问题后者是事实问题。态度问题在评审会上永远得不到真实答案事实问题则逼着架构师要么拿出报告、要么承认没做。一份好清单的本质就是让“蒙混过关”变得不可能。4.2 校准与裁剪AI生成清单后的三小时工作法AI生成的清单不管质量多高我都不会直接拿进评审会。我自己的习惯是留出三个小时做“人工校准”这三步一个都不能省。第一步通读去噪大约30分钟。把AI生成的问题从头到尾过一遍删掉那些和当前项目完全无关的比如你的方案里根本没有引入消息队列AI还追问消息积压的处理策略这就是噪音删掉。同时合并表达重复的问题通常能删掉20%左右。第二步补充领域特有项大约60分钟。AI再强也缺少你所在业务领域的特有知识。我们这个系统涉及财务对账我会额外加上“对账差异的处理时效”“差错交易的退款路径”等问题。这类问题AI问不出来因为它的训练语料里没有你公司内部的业务流程。这是AI和人的能力边界问题——AI给你广度你给它深度缺一不可。第三步指派Owner和设定时限大约90分钟。这个环节最容易被忽略但恰恰决定清单能不能落地。每个P0问题我都要在评审会前指定一个具体的人去回答并且明确要求“带着证据来开会”。例如“缓存一致性方案”这个问题的Owner是负责订单服务的开发者他在评审会上需要带来一份一致性设计说明文档和验证方案。没有这一步清单只会停留在纸面上开会还是老样子。5. 踩坑记录与常见问题的处理办法5.1 高频踩坑清单含现场表现与排查建议AI辅助生成评审清单这件事我前前后后试过不下十几次踩过的坑比成功经验还值得分享。我把高频问题整理成了一张表对应的“排查建议”都是我自己试过有效的方法。坑点现场表现排查与解决办法问题太泛、不可回答清单里有大量“是否考虑XX”句式评审时大家直接跳过在提示词里写上“禁止使用‘是否充分’‘是否考虑’等表达每个问题必须包含场景、指标或边界条件”覆盖面严重偏向技术细节全是数据库索引、缓存设置这类技术点业务价值和演进方向没人问加入“业务产品经理”和“技术债务”两个视角并明确要求按六个维度均衡输出清单太长无法评审一次生成80多个问题评审会根本走不完分P0/P1/P2三级评审会上只逐条过P0其余记录在案问题之间重复率高同一个风险点以不同表述出现了三次要求AI“去重合并同类项”并在人工校准环节统一把关AI“编造”不存在的约束系统明明是单机部署AI却追问集群的脑裂处理策略喂背景信息时把约束写清楚部署形态、规模、技术栈缺一不可生成后人工删掉不符合约束的问题清单缺少“通过标准”大家讨论了半小时最后还是不知道结论怎么收对P0问题强制补充判断条件比如阈值、文档名称、报告名称宁可严格不可模糊其中“AI编造不存在的约束”这一点我想多提醒一句。大模型有个特点就是会“顺着问题往下顺”。如果你的背景信息里没写清楚部署形态是“单机”它默认你会用集群方案于是生成一堆关于“集群脑裂”“分布式事务”“节点间数据同步”的问题。这在单机系统里纯属浪费时间。所以喂背景时务必要写约束把“不存在的选项”提前排除掉。5.2 怎么判断一份AI清单到底好不好不是所有AI生成的清单都一样好用时间久了你会发现差距很大。我判断一份清单质量的标准特别简单就三条。第一条每个问题都能想出“怎么去验证”。当我看到一个问题时如果脑子里第一反应是“这个能查API文档确认”“这个可以拿压测报告对比”或者“这个看代码就知道”那就是好问题。如果我的第一反应是“这得问架构师才知道”那这个问题大概率还是会流于形式。第二条覆盖面上有至少20%的问题是“团队原来没想到的”。如果AI生成的50个问题里有10个以上是团队里大部分人看完会“哦——对这个怎么没想到”的这份清单就值回票价了。如果全程看下来大家波澜不惊说明这个方案比较成熟或者你喂给AI的上下文不够深。第三条问题能分成清晰的优先级。好的清单不是一个平均用力的大列表而是有明显“重点区”的——P0问题让人一眼就能看出来这套方案真正的命门在哪里。如果所有问题都差不多重要说明AI没有真正理解方案的取舍人工校准的余地还很大。再把前面几轮的东西串起来看一份靠谱的AI辅助清单产出过程无外乎是“提供充分的背景上下文”加“按六维框架生成”加“切换多角色补充视角”加“分级与通过标准校准”加“人工通读去噪裁剪”。流程不复杂但每一步都有讲究。我自己现在的工作习惯是评审会前三天开始准备清单先花半天时间整理方案材料、喂给AI生成初稿再做三小时人工校准给问题指派Owner。评审会上严格按P0/P1/P2的节奏走会后把P1、P2问题录入跟踪表在下一个迭代的检查点逐项验收。要说最大的体会其实是关于AI辅助这件事的定位。AI不会替代你做判断也不会替你积累项目经验和领域知识但它能在你经验不足的地方帮你撑开视野在你注意力局限的地方帮你补上盲区。把AI当成一个“永远有时间、永远有耐心、读过很多失败案例的评审参谋”它的价值才能最大化。这种用法我认为比让AI直接给你评审结论靠谱得多。