架構評審這件事做久了真的會有點“麻”。我參加過的評審會少說也有幾十場最典型的一個畫面是架構師打開文檔講了一個小時評審團在最后十分鐘提了幾個問題然后結論是“總體方案可行按計劃推進”。等系統(tǒng)上線后出了性能問題、擴展性不夠、安全漏洞被通報回頭看當時的評審記錄發(fā)現(xiàn)那些隱患其實早就有征兆只是當時沒人問、沒人提。后來我開始琢磨一件事能不能把評審從“靠人發(fā)揮”變成“靠流程兜底”答案落在了一張清單上。但傳統(tǒng)清單有個很尷尬的問題——它太“通用”了翻來覆去就是性能、安全、可用性那幾項放哪個項目都能用放哪個項目都不疼不癢。直到我開始用AI輔助生成架構評審清單把每個項目獨特的背景、約束、風險喂進去讓它按需生成有針對性的檢查問題評審會的質量才真正上了一個臺階。這篇文章我就把自己的完整做法、提示詞寫法、清單框架、踩過的坑一次性講清楚。1. 先聊透架構評審為什么需要一張好清單1.1 評審不是在找茬是在補認知盲區(qū)很多人對架構評審有個誤解覺得評審就是挑毛病、找漏洞是站在對立面審問架構師。但真正做過評審的人會明白評審最有價值的地方是幫整個團隊補齊認知盲區(qū)。我見過一個真實場景一個做訂單中臺的方案架構師把微服務拆分、消息隊列選型、數(shù)據一致性方案講得頭頭是道評審會上大家也都集中在討論“訂單狀態(tài)機怎么設計”“Kafka和RocketMQ該選哪個”。結果方案通過了上線后運維同事問了一句這個系統(tǒng)的日志規(guī)范、監(jiān)控指標、告警閾值定義了嗎全場安靜了。沒人想過這件事因為大家的目光都被“架構亮點”吸引走了。這就是評審最大的風險——它被“看起來重要的東西”牽著走而不是被“容易出問題的東西”牽著走。人的注意力天生會集中在方案中最復雜、最亮眼的部分而真正的隱患往往藏在那些沒有人提過的角落里。清單的作用就是把這些角落一個個翻出來逼著評審者挨個過一遍。1.2 AI的定位用清單把“隱性經驗”顯性化既然清單這么重要為什么很多團隊還是不做我觀察下來就一個原因寫清單這件事看起來太簡單做起來太難。簡單地說任何人都能寫“檢查系統(tǒng)性能”“評估系統(tǒng)安全性”這種大而化之的條目。但要寫出一份真正有用的清單需要你能針對當前這個具體方案提出具體的、可驗證的問題。比如“訂單查詢接口在峰值1萬TPS下數(shù)據庫連接池和緩存命中率的預期是多少超時閾值怎么設”這種問題。這種問題來自哪里來自豐富的實戰(zhàn)經驗來自你對這個業(yè)務領域、這個技術棧的深入理解。大多數(shù)評審參與者并沒有這種經驗儲備。這時候AI就能幫上忙了。它的角色不是“評審專家”而是一個“經驗放大器”你把方案的上下文告訴它它用海量的歷史知識幫你想出那些你沒想到的檢查角度你再用自己的判斷去篩選、校準、補充。AI負責拓寬覆蓋面人負責判斷深度配合起來比任何一方單干都強。我把它總結為一個公式高質量評審清單 AI的覆蓋面 × 人的校準力。AI的價值不在“替代經驗”而在“把隱性經驗顯性化”讓一個經驗沒那么豐富的人也能拿出經驗豐富的人才會問的問題。2. 怎么設計評審清單框架六個檢查維度的取舍2.1 我從老清單里歸納出的六維骨架用AI生成清單的第一步不是直接讓它列問題而是先給它一個框架。沒有框架的AI生成很容易給你鋪出一張包含七八十個問題的長紙看著很豐富實際沒法用。我自己用下來比較穩(wěn)定的框架是六個維度這六個維度幾乎能覆蓋我遇到過的所有架構評審場景維度核心關注點典型風險信號功能與業(yè)務匹配方案是否真正解決業(yè)務問題技術方案“過度設計”與業(yè)務規(guī)模不匹配性能與容量峰值場景下的響應時間、吞吐量、資源用量只在壓測環(huán)境驗證過平均負載沒驗證峰值安全與合規(guī)認證鑒權、數(shù)據加密、隱私保護、審計日志把安全放“二期再做”擴展性與演進新節(jié)點如何接入、舊邏輯如何兼容模塊耦合嚴重加一個字段要改五個服務可維護性與可觀測性日志、監(jiān)控、告警、排障鏈路是否完整系統(tǒng)上線后“全黑”出問題只能重啟部署與運營灰度、回滾、災備、配置管理發(fā)布流程靠手工沒有標準預案這六個維度不是我想出來的而是復盤了大量“上線后出問題”的案例后歸納出來的。你會發(fā)現(xiàn)一個規(guī)律絕大多數(shù)事故都能映射到至少一個維度被評審時忽略了。2.2 每個維度里最容易漏掉的三個子問題框架有了接下來要讓AI在每個維度里“往深挖”。我自己的經驗是直接讓AI“列六個維度的問題”它給出來的東西還是會偏泛。但如果你在提示詞里逐個維度做引導告訴它這個維度下容易漏掉哪些子問題效果會好非常多。性能與容量維度最容易漏掉的是數(shù)據增長曲線很多方案只算了“現(xiàn)在的數(shù)據量”沒算“一年后的數(shù)據量”。訂單表三個月增長兩千萬行之后當前索引還撐得住嗎AI 會引導你從“存量”和“增量”兩個視角去問問題。慢請求雪崩一個接口變慢導致上游服務線程池被占滿拖垮整個鏈路。這屬于性能問題的“傳染性”評審時單看一個接口是看不出來的。資源預算的歸屬每個服務擴容的預算誰出、容量誰來評估這看似是管理問題但架構方案里如果完全不寫容量規(guī)劃后面必然扯皮。安全與合規(guī)維度最容易漏掉的是默認憑據和默認配置中間件裝完用默認密碼、默認端口這在評審文檔里經常出現(xiàn)但也經常被一筆帶過沒人較真。數(shù)據流視角的權限設計功能上每個接口都有權限控制但數(shù)據導出的接口是不是也能被普通用戶調用權限不能只看功能入口要看數(shù)據能走到哪里。第三方組件的漏洞響應機制方案里引入了一個開源組件誰負責跟蹤它的安全公告沒有Owner的安全是空談?？删S護性與可觀測性維度最容易漏掉的是失敗時的可診斷性系統(tǒng)正常時的觀測大家都想到了但系統(tǒng)失敗時能不能快速定位錯誤日志里有沒有traceId貫穿全鏈路配置變更的審計線上配置被改了一個參數(shù)有沒有記錄誰改的、什么時候改的、影響范圍多大依賴故障的降級方案依賴的第三方服務掛了我們是跟著掛還是有降級預案降級后的體驗邊界是什么你會發(fā)現(xiàn)我舉的這九個子問題都不是從“教科書”上來的而是從實際事故里長出來的。這也說明了AI輔助的一個關鍵用法你不需要自己記住所有經驗但你需要能識別AI給出來的哪些問題是真正切中要害的。3. AI生成清單實操從上下文輸入到三遍打磨3.1 第一遍把背景喂足讓AI“知道自己在審什么”很多人用AI生成清單時有個壞習慣直接一句話過去“幫我寫一份架構評審清單”。AI這時候只能給你一份放之四海而皆準的“標準答案”看起來工整實際沒用。我實際的用法是先用一個“上下文描述模板”把當前方案的關鍵信息喂給AI。我常用的模板大致是我正在評審一個軟件系統(tǒng)的架構設計方案請幫我生成一份架構評審清單。 以下是方案的背景信息 - 系統(tǒng)定位[一句話描述系統(tǒng)是干什么的比如“面向內部運營人員的工單管理平臺”] - 核心使用場景[列出主要場景比如“客服創(chuàng)建工單、工單流轉審批、數(shù)據報表導出”] - 目標用戶規(guī)模[預估用戶數(shù)/并發(fā)量寫不準確沒關系寫量級即可] - 關鍵約束[技術棧限定、部署環(huán)境、合規(guī)要求等比如“必須部署在私有云使用XX框架”] - 技術亮點與主要選型[比如“微服務架構Kafka異步削峰MySQL分庫分表Redis緩存”] - 我擔心的重點[把你心里最沒底的方向寫出來比如“數(shù)據一致性問題”“高可用切換機制”] - 已知風險[已經識別出來的問題比如“目前只壓測了單節(jié)點性能集群模式未驗證”] 請基于以上信息從功能與業(yè)務、性能與容量、安全與合規(guī)、擴展性與演進、 可維護性與可觀測性、部署與運營六個維度分別生成評審檢查問題。 要求每個問題具體、可驗證不要使用“是否考慮”“是否充分”這類模糊表述。這里有個關鍵點就是“我擔心的重點”這一欄。很多人的直覺是希望AI全面覆蓋所以不給任何重點提示。但我的經驗恰恰相反告訴AI你最擔心什么它反而能生成得更全面。因為你擔心的方向意味著這個方案確實有風險AI會順著這個風險去發(fā)散出相關聯(lián)的問題——這會觸發(fā)它尋找“連鎖風險”的能力比你讓它漫無目的地掃描要好得多。3.2 第二遍用角色和邊界約束AI的評審視角第一遍生成的清單通常問題數(shù)量在30到60之間質量還行但仍然會有不少“通用項”夾在里面。第二遍要做的事情是讓AI切換不同角色去審視這份方案。架構評審很有意思的一點在于不同角色眼里同一個方案的風險是完全不同的。我做過的評審里最有價值的問題常常不是架構師提的而是運維、安全、測試、業(yè)務方從自己視角拋出來的“跨界問題”。為了讓AI也具備這種“跨界視角”我會在提示詞里追加一段請再分別從以下角色視角對剛才的方案提出額外的問題每個角色3~5個 1. 運維工程師關注部署、監(jiān)控、日志、故障恢復、容量規(guī)劃 2. 安全工程師關注認證鑒權、數(shù)據泄露、漏洞管理、合規(guī)審計 3. 測試工程師關注可測性、測試環(huán)境、數(shù)據構造、灰度驗證 4. 業(yè)務產品經理關注交付時間、功能邊界、非功能需求的業(yè)務影響 5. 新加入團隊的初級開發(fā)關注文檔是否充分、代碼是否容易上手、架構是否過度復雜 這些角色視角的問題如果與上一輪的六個維度問題重復請自動去重 最終請把不同角色提出的問題整合分節(jié)不要按角色分類輸出要按問題歸屬的技術主題分類。這一步做完的體驗通常很驚喜。運維視角經常能問出“沒有預案如何處理失敗節(jié)點”這種硬核問題安全視角能問出“接口是否暴露了內部網絡結構”這種細節(jié)問題而新員工視角能問出“沒有架構文檔如何讓人接手”這種讓架構師冷汗直冒的問題。3.3 第三遍按風險等級分級把問題變成可執(zhí)行的檢查項第二遍生成的清單已經比較全了但還有一個致命問題沒法直接用。一份六十個問題的清單在評審會上根本走不完。你不可能讓評審團逐條過一遍大家會疲勞到最后再重要的問題也流于形式。所以第三遍打磨的目標是“分級”而且不是簡單地標個高/中/低而是要讓每個問題都變成“可執(zhí)行的檢查項”。我通常讓AI做三件事第一把問題按風險等級分成三檔請把上面的所有問題分成三組 - P0必須當場確認并有明確結論的問題如果沒有結論評審不通過。 - P1必須在啟動開發(fā)前給出明確方案的問題可以在評審會后由架構師補充。 - P2可以留到開發(fā)/測試階段持續(xù)跟蹤的問題不影響評審通過但要記錄在案。第二給每個P0問題補充“通過標準”。這是我認為整個流程里最有價值的一步對于所有P0問題請補充什么情況下算“通過”什么情況下算“不通過” 請給出明確的判斷條件比如數(shù)據指標閾值、必須有文檔、必須有壓測報告等。第三把整個清單導出成表格。這一步是落地到評審會動作的關鍵我會讓AI輸出一個包含“問題描述、風險等級、檢查方法、通過標準、負責人、備注”的表格框架我再用它整合評審記錄。到這一步一份可用的評審清單就成型了。以我最近評審的一個訂單系統(tǒng)為例三遍之后輸出的清單大概是這樣的結構P0問題 9 個包括“分庫分表鍵如何選取按什么維度路由”“訂單狀態(tài)與支付狀態(tài)的最終一致性如何保證對賬機制是什么”“峰值下單場景下庫存扣減的并發(fā)上限和超賣容忍度是多少”等P1問題 18 個包括“緩存與數(shù)據庫的雙寫一致性問題容忍多少秒不一致”“消息隊列積壓超過閾值如何告警積壓恢復策略是什么”等P2問題 27 個包括“是否需要有定時清理歷史訂單的機制”“是否提供批量導出接口給財務系統(tǒng)”等這個量級評審會兩個小時是能走完的。P0的問題逐條過P1快速過方案P2記錄跟蹤節(jié)奏會清晰很多。4. 清單落地從“生成出來”到“評審好用”4.1 讓問題可驗證而不是“正確的廢話”AI生成清單最容易出現(xiàn)的問題我給它起了個名字叫“正確的廢話”。典型表現(xiàn)是“系統(tǒng)是否具備足夠的性能冗余”“方案是否充分考慮了安全性”“數(shù)據一致性是否得到保障”。這種問題你沒法回答因為“足夠”“充分”“保障”這些詞根本沒法量化架構師只能說“我們認為OK”評審就滑過去了。我的實踐是在提示詞里硬性要求“禁止使用無法量化的判斷詞”并強制AI把每個問題改寫成可以驗證的形式。改寫的方法是“加條件、加指標、加場景”。來看三個例子“系統(tǒng)是否具備足夠的性能冗余”→ 改為“在峰值流量按預估1萬TPS運行30分鐘的情況下核心接口的P99響應時間是否低于800ms是否給出過壓測報告”“方案是否充分考慮安全性”→ 改為“管理后臺的登錄是否支持多因素認證API網關是否對全部外部請求做了鑒權是否提供最近一次安全掃描的報告”“數(shù)據一致性是否得到保障”→ 改為“訂單創(chuàng)建和支付回調之間的狀態(tài)不一致窗口期最長是多少秒如果出現(xiàn)狀態(tài)不一致采用何種補償機制是否設計了定時對賬任務”你對比一下就能看出來前者是態(tài)度問題后者是事實問題。態(tài)度問題在評審會上永遠得不到真實答案事實問題則逼著架構師要么拿出報告、要么承認沒做。一份好清單的本質就是讓“蒙混過關”變得不可能。4.2 校準與裁剪AI生成清單后的三小時工作法AI生成的清單不管質量多高我都不會直接拿進評審會。我自己的習慣是留出三個小時做“人工校準”這三步一個都不能省。第一步通讀去噪大約30分鐘。把AI生成的問題從頭到尾過一遍刪掉那些和當前項目完全無關的比如你的方案里根本沒有引入消息隊列AI還追問消息積壓的處理策略這就是噪音刪掉。同時合并表達重復的問題通常能刪掉20%左右。第二步補充領域特有項大約60分鐘。AI再強也缺少你所在業(yè)務領域的特有知識。我們這個系統(tǒng)涉及財務對賬我會額外加上“對賬差異的處理時效”“差錯交易的退款路徑”等問題。這類問題AI問不出來因為它的訓練語料里沒有你公司內部的業(yè)務流程。這是AI和人的能力邊界問題——AI給你廣度你給它深度缺一不可。第三步指派Owner和設定時限大約90分鐘。這個環(huán)節(jié)最容易被忽略但恰恰決定清單能不能落地。每個P0問題我都要在評審會前指定一個具體的人去回答并且明確要求“帶著證據來開會”。例如“緩存一致性方案”這個問題的Owner是負責訂單服務的開發(fā)者他在評審會上需要帶來一份一致性設計說明文檔和驗證方案。沒有這一步清單只會停留在紙面上開會還是老樣子。5. 踩坑記錄與常見問題的處理辦法5.1 高頻踩坑清單含現(xiàn)場表現(xiàn)與排查建議AI輔助生成評審清單這件事我前前后后試過不下十幾次踩過的坑比成功經驗還值得分享。我把高頻問題整理成了一張表對應的“排查建議”都是我自己試過有效的方法?？狱c現(xiàn)場表現(xiàn)排查與解決辦法問題太泛、不可回答清單里有大量“是否考慮XX”句式評審時大家直接跳過在提示詞里寫上“禁止使用‘是否充分’‘是否考慮’等表達每個問題必須包含場景、指標或邊界條件”覆蓋面嚴重偏向技術細節(jié)全是數(shù)據庫索引、緩存設置這類技術點業(yè)務價值和演進方向沒人問加入“業(yè)務產品經理”和“技術債務”兩個視角并明確要求按六個維度均衡輸出清單太長無法評審一次生成80多個問題評審會根本走不完分P0/P1/P2三級評審會上只逐條過P0其余記錄在案問題之間重復率高同一個風險點以不同表述出現(xiàn)了三次要求AI“去重合并同類項”并在人工校準環(huán)節(jié)統(tǒng)一把關AI“編造”不存在的約束系統(tǒng)明明是單機部署AI卻追問集群的腦裂處理策略喂背景信息時把約束寫清楚部署形態(tài)、規(guī)模、技術棧缺一不可生成后人工刪掉不符合約束的問題清單缺少“通過標準”大家討論了半小時最后還是不知道結論怎么收對P0問題強制補充判斷條件比如閾值、文檔名稱、報告名稱寧可嚴格不可模糊其中“AI編造不存在的約束”這一點我想多提醒一句。大模型有個特點就是會“順著問題往下順”。如果你的背景信息里沒寫清楚部署形態(tài)是“單機”它默認你會用集群方案于是生成一堆關于“集群腦裂”“分布式事務”“節(jié)點間數(shù)據同步”的問題。這在單機系統(tǒng)里純屬浪費時間。所以喂背景時務必要寫約束把“不存在的選項”提前排除掉。5.2 怎么判斷一份AI清單到底好不好不是所有AI生成的清單都一樣好用時間久了你會發(fā)現(xiàn)差距很大。我判斷一份清單質量的標準特別簡單就三條。第一條每個問題都能想出“怎么去驗證”。當我看到一個問題時如果腦子里第一反應是“這個能查API文檔確認”“這個可以拿壓測報告對比”或者“這個看代碼就知道”那就是好問題。如果我的第一反應是“這得問架構師才知道”那這個問題大概率還是會流于形式。第二條覆蓋面上有至少20%的問題是“團隊原來沒想到的”。如果AI生成的50個問題里有10個以上是團隊里大部分人看完會“哦——對這個怎么沒想到”的這份清單就值回票價了。如果全程看下來大家波瀾不驚說明這個方案比較成熟或者你喂給AI的上下文不夠深。第三條問題能分成清晰的優(yōu)先級。好的清單不是一個平均用力的大列表而是有明顯“重點區(qū)”的——P0問題讓人一眼就能看出來這套方案真正的命門在哪里。如果所有問題都差不多重要說明AI沒有真正理解方案的取舍人工校準的余地還很大。再把前面幾輪的東西串起來看一份靠譜的AI輔助清單產出過程無外乎是“提供充分的背景上下文”加“按六維框架生成”加“切換多角色補充視角”加“分級與通過標準校準”加“人工通讀去噪裁剪”。流程不復雜但每一步都有講究。我自己現(xiàn)在的工作習慣是評審會前三天開始準備清單先花半天時間整理方案材料、喂給AI生成初稿再做三小時人工校準給問題指派Owner。評審會上嚴格按P0/P1/P2的節(jié)奏走會后把P1、P2問題錄入跟蹤表在下一個迭代的檢查點逐項驗收。要說最大的體會其實是關于AI輔助這件事的定位。AI不會替代你做判斷也不會替你積累項目經驗和領域知識但它能在你經驗不足的地方幫你撐開視野在你注意力局限的地方幫你補上盲區(qū)。把AI當成一個“永遠有時間、永遠有耐心、讀過很多失敗案例的評審參謀”它的價值才能最大化。這種用法我認為比讓AI直接給你評審結論靠譜得多。