1. 從一次差點(diǎn)翻車的接口設(shè)計(jì)說起去年秋天我接手了一個(gè)訂單履約系統(tǒng)的重構(gòu)項(xiàng)目。需求本身不算復(fù)雜把原來單體應(yīng)用里的下單、庫存扣減、履約單生成三段邏輯拆成獨(dú)立服務(wù)通過消息隊(duì)列解耦。我花了大概兩個(gè)小時(shí)把領(lǐng)域模型和時(shí)序圖畫完正準(zhǔn)備動(dòng)手寫詳細(xì)設(shè)計(jì)文檔同事丟給我一個(gè)AI編程助手說“你試試讓它幫你出個(gè)初稿能省不少時(shí)間”。我確實(shí)試了。把需求描述和幾張草圖丟進(jìn)去不到三十秒它吐出來一份看起來相當(dāng)完整的設(shè)計(jì)方案服務(wù)拆分、接口定義、消息格式、異常處理、甚至還有一段偽代碼。第一眼的感覺是“這東西真能處”。但當(dāng)我逐行讀下去冷汗就下來了——它在庫存扣減和履約單生成之間設(shè)計(jì)了一個(gè)同步RPC調(diào)用而這兩個(gè)服務(wù)恰恰是我要解耦的核心。如果按它的方案落地消息隊(duì)列就白引入了高峰期依然會(huì)級(jí)聯(lián)阻塞。這件事讓我重新思考了一個(gè)問題AI在技術(shù)設(shè)計(jì)里到底該扮演什么角色它不是不能信而是你得知道什么時(shí)候該信、什么時(shí)候必須自己拍板。這篇內(nèi)容就是把我這大半年和AI結(jié)對(duì)做設(shè)計(jì)的經(jīng)驗(yàn)拆開講包括哪些環(huán)節(jié)它確實(shí)能提效、哪些環(huán)節(jié)它給的答案必須打問號(hào)、以及我是怎么建立一套“信任分級(jí)”機(jī)制的。如果你也在用AI輔助架構(gòu)設(shè)計(jì)或技術(shù)方案評(píng)審這些踩過的坑應(yīng)該能幫你少走點(diǎn)彎路。2. AI在技術(shù)設(shè)計(jì)里真正擅長的三件事2.1 把零散需求整理成結(jié)構(gòu)化文檔技術(shù)設(shè)計(jì)最耗時(shí)的部分往往不是“想”而是“寫”。你腦子里已經(jīng)有方案了但要把背景、目標(biāo)、非目標(biāo)、約束條件、接口定義、數(shù)據(jù)模型、異常分支一條條寫清楚這個(gè)過程非常磨人。AI在這件事上表現(xiàn)相當(dāng)好——你把需求要點(diǎn)用大白話列出來它能幫你擴(kuò)寫成一份格式規(guī)整的設(shè)計(jì)文檔初稿。我現(xiàn)在的習(xí)慣是先用自由文本把需求背景、核心流程、關(guān)鍵約束寫下來不需要講究結(jié)構(gòu)想到哪寫到哪。然后讓AI基于這段文字生成一份帶章節(jié)的設(shè)計(jì)文檔骨架。它會(huì)把“非功能需求”單獨(dú)拎出來會(huì)把“邊界條件”列成表格這些確實(shí)比我自己從零搭要快。但注意它整理的是你給它的信息不會(huì)幫你發(fā)現(xiàn)你沒說出來的隱含需求。比如你忘了提“庫存扣減必須冪等”它大概率也不會(huì)主動(dòng)補(bǔ)上除非你在提示詞里明確要求它檢查冪等性。2.2 快速生成多種方案供你對(duì)比技術(shù)設(shè)計(jì)里經(jīng)常遇到“條條大路通羅馬”的情況緩存用本地還是分布式、消息用Kafka還是RocketMQ、服務(wù)間調(diào)用用同步還是異步。AI的優(yōu)勢(shì)在于它能快速把幾種常見方案的優(yōu)缺點(diǎn)列出來形成一個(gè)對(duì)比矩陣。雖然這些對(duì)比未必完全準(zhǔn)確但至少能幫你快速建立一個(gè)決策框架。我一般會(huì)這樣問它“針對(duì)XX場(chǎng)景列出三種可能的實(shí)現(xiàn)方案分別從一致性、可用性、運(yùn)維復(fù)雜度、團(tuán)隊(duì)熟悉度四個(gè)維度做對(duì)比?！彼o出的表格通常能覆蓋七八成需要考慮的因素剩下的兩成——比如你們團(tuán)隊(duì)對(duì)某個(gè)中間件的實(shí)際運(yùn)維經(jīng)驗(yàn)、公司基礎(chǔ)設(shè)施的現(xiàn)狀——只有你自己知道。AI給的是通用視角的對(duì)比你要做的是把通用視角和你的具體上下文做減法。2.3 對(duì)已有設(shè)計(jì)做“盲審”式挑刺這是我覺得AI最有價(jià)值的一個(gè)用法。當(dāng)你已經(jīng)寫完一份設(shè)計(jì)文檔自己反復(fù)看容易陷入思維定勢(shì)這時(shí)候讓AI扮演一個(gè)“挑刺的評(píng)審者”角色往往能發(fā)現(xiàn)一些你忽略的點(diǎn)。我會(huì)在提示詞里明確要求它“假設(shè)你是一個(gè)嚴(yán)格的架構(gòu)評(píng)審者找出這份設(shè)計(jì)中可能導(dǎo)致線上故障的三個(gè)隱患并說明觸發(fā)條件?！睂?shí)測(cè)下來它確實(shí)能指出一些我沒想到的邊界情況比如“如果消息消費(fèi)失敗后重試三次仍然失敗死信隊(duì)列的告警閾值設(shè)了嗎”“庫存扣減和訂單狀態(tài)更新不在同一個(gè)事務(wù)里中間宕機(jī)怎么恢復(fù)”。這些問題不一定都是真問題但它提供了一個(gè)外部視角的檢查清單比我自己對(duì)著文檔干想要高效得多。3. 那些AI一本正經(jīng)胡說八道的時(shí)刻3.1 它會(huì)把“常見做法”當(dāng)成“最佳做法”塞給你AI的訓(xùn)練語料里包含了大量技術(shù)博客、開源文檔和問答社區(qū)的內(nèi)容這導(dǎo)致它有一個(gè)明顯的傾向把出現(xiàn)頻率最高的方案當(dāng)成推薦方案。比如你問它“服務(wù)間通信怎么做”它大概率會(huì)推薦RESTful API或者gRPC因?yàn)檫@兩種在公開資料里出現(xiàn)得最多。但你的場(chǎng)景可能恰恰需要基于消息的異步通信或者基于共享存儲(chǔ)的批處理模式。我踩過的一個(gè)坑是在設(shè)計(jì)一個(gè)對(duì)賬系統(tǒng)時(shí)AI建議用定時(shí)任務(wù)輪詢數(shù)據(jù)庫來比對(duì)兩邊數(shù)據(jù)。這個(gè)方案本身沒錯(cuò)但它沒有考慮數(shù)據(jù)量——我們的對(duì)賬表每天新增千萬級(jí)記錄輪詢?nèi)頀呙韪静滑F(xiàn)實(shí)。AI不知道你的數(shù)據(jù)規(guī)模、QPS、延遲要求它只能給“平均情況”下的答案。所以每次它給出方案建議我都會(huì)追問一句“這個(gè)方案在數(shù)據(jù)量達(dá)到XX、并發(fā)達(dá)到XX的情況下還成立嗎”這一問往往能逼出它方案里的隱含假設(shè)。3.2 它會(huì)在你不熟悉的領(lǐng)域編造看似合理的細(xì)節(jié)這是最危險(xiǎn)的情況。當(dāng)你對(duì)某個(gè)技術(shù)領(lǐng)域不夠熟悉時(shí)AI生成的錯(cuò)誤內(nèi)容你根本識(shí)別不出來。我在設(shè)計(jì)一個(gè)基于事件溯源的審計(jì)模塊時(shí)AI建議了一種“快照事件回放”的混合存儲(chǔ)方案聽起來很專業(yè)術(shù)語也用得對(duì)。但我后來查了資料才發(fā)現(xiàn)它把快照的生成時(shí)機(jī)和事件版本號(hào)的對(duì)應(yīng)關(guān)系搞錯(cuò)了——按照它的方案回放時(shí)會(huì)出現(xiàn)狀態(tài)不一致。判斷AI是否在編造的一個(gè)實(shí)用技巧是讓它給出具體的數(shù)字或公式。比如它說“這個(gè)方案能支撐高并發(fā)”你就問“具體支撐多少Q(mào)PS怎么算出來的”。如果它給不出合理的計(jì)算過程只是重復(fù)“高并發(fā)場(chǎng)景下表現(xiàn)良好”這類空話那大概率是在糊弄。真正靠譜的方案一定能落到具體的參數(shù)和計(jì)算上。3.3 它傾向于過度設(shè)計(jì)把簡單問題復(fù)雜化AI似乎有一種“炫技”傾向。你讓它設(shè)計(jì)一個(gè)內(nèi)部管理后臺(tái)的權(quán)限模塊它可能會(huì)給你搬出RBAC、ABAC、策略引擎、屬性加密一整套。但你的實(shí)際需求可能只是“管理員能看所有數(shù)據(jù)普通用戶只能看自己的”。這種過度設(shè)計(jì)如果落地會(huì)帶來巨大的維護(hù)成本。我的應(yīng)對(duì)方式是在提示詞里加一個(gè)約束——“用最少的組件和最簡單的方案實(shí)現(xiàn)優(yōu)先考慮團(tuán)隊(duì)現(xiàn)有技術(shù)?！?。這句話能顯著降低它“堆砌技術(shù)名詞”的概率。另外每次它給出一個(gè)復(fù)雜方案我都會(huì)問自己這個(gè)復(fù)雜度是需求本身帶來的還是AI為了顯得專業(yè)而加上去的4. 我總結(jié)的“信任分級(jí)”實(shí)操框架4.1 把設(shè)計(jì)任務(wù)按風(fēng)險(xiǎn)等級(jí)分類經(jīng)過大半年的磨合我現(xiàn)在會(huì)把技術(shù)設(shè)計(jì)任務(wù)分成三類對(duì)應(yīng)不同的AI參與程度任務(wù)類型典型場(chǎng)景AI參與度我的角色低風(fēng)險(xiǎn)整理類文檔格式化、術(shù)語統(tǒng)一、方案羅列高度信任直接采用初稿審核事實(shí)準(zhǔn)確性中風(fēng)險(xiǎn)分析類方案對(duì)比、邊界條件檢查、風(fēng)險(xiǎn)識(shí)別參考其輸出逐條驗(yàn)證結(jié)合上下文篩選高風(fēng)險(xiǎn)決策類核心鏈路設(shè)計(jì)、數(shù)據(jù)一致性方案、容量規(guī)劃僅用作“反面教材”完全自主決策這個(gè)分類的關(guān)鍵在于風(fēng)險(xiǎn)等級(jí)不是由技術(shù)難度決定的而是由“出錯(cuò)后的修復(fù)成本”決定的。文檔格式錯(cuò)了改一下就行但核心鏈路設(shè)計(jì)錯(cuò)了可能導(dǎo)致線上故障修復(fù)成本天差地別。4.2 用“三問法”快速判斷AI輸出的可信度每次AI給出一個(gè)設(shè)計(jì)建議我會(huì)快速問自己三個(gè)問題這個(gè)方案依賴哪些我沒告訴它的假設(shè)比如它假設(shè)網(wǎng)絡(luò)可靠、假設(shè)消息不丟、假設(shè)數(shù)據(jù)量不大。把這些假設(shè)列出來逐個(gè)核對(duì)是否成立。如果這個(gè)方案錯(cuò)了最壞的結(jié)果是什么如果最壞結(jié)果是“文檔需要重寫”那可以放心用如果是“線上數(shù)據(jù)不一致”那就必須自己重新設(shè)計(jì)。我能不能用一句話向團(tuán)隊(duì)解釋清楚這個(gè)方案為什么是對(duì)的如果解釋不了說明我還沒真正理解它這時(shí)候采用就是盲目信任。這三個(gè)問題花不了兩分鐘但能過濾掉大部分“看起來對(duì)但實(shí)際有問題”的AI輸出。4.3 建立自己的“AI輸出檢查清單”針對(duì)技術(shù)設(shè)計(jì)這個(gè)場(chǎng)景我整理了一份檢查清單每次AI給出方案后逐項(xiàng)過一遍一致性方案里提到的所有組件它們之間的數(shù)據(jù)流是否閉環(huán)有沒有“只寫不讀”或“只讀不寫”的環(huán)節(jié)邊界空值、零值、超大值、并發(fā)沖突這些邊界情況方案里有沒有覆蓋失敗路徑每個(gè)網(wǎng)絡(luò)調(diào)用、每次磁盤寫入、每條消息消費(fèi)失敗后怎么處理重試策略是什么可觀測(cè)性方案上線后怎么知道它運(yùn)行正常關(guān)鍵指標(biāo)有哪些告警閾值怎么定回滾如果上線后發(fā)現(xiàn)有問題怎么快速回退有沒有數(shù)據(jù)遷移的逆向操作這份清單里的問題AI有時(shí)候能答上來有時(shí)候答不上來。答不上來的部分就是我必須自己補(bǔ)上的部分。5. 一次完整的“人機(jī)結(jié)對(duì)”設(shè)計(jì)過程還原5.1 需求拆解階段我主導(dǎo)AI輔助回到開頭那個(gè)訂單履約系統(tǒng)的例子。這次我沒有直接讓AI出方案而是先自己把需求拆成幾個(gè)核心問題下單和庫存扣減之間一致性要求是什么允許短暫不一致嗎履約單生成的觸發(fā)條件是什么是支付成功還是庫存扣減成功如果庫存扣減成功但履約單生成失敗怎么補(bǔ)償我把這三個(gè)問題寫清楚然后讓AI針對(duì)每個(gè)問題列出可能的答案和對(duì)應(yīng)的技術(shù)方案。它給出的選項(xiàng)確實(shí)拓寬了我的思路比如它提到“可以用本地消息表實(shí)現(xiàn)最終一致性”這個(gè)方案我之前沒考慮過。但最終選哪個(gè)是我根據(jù)團(tuán)隊(duì)對(duì)消息中間件的熟悉程度和運(yùn)維成本決定的。5.2 方案設(shè)計(jì)階段AI出草稿我逐行審方案設(shè)計(jì)階段我讓AI基于我確定的核心決策生成一份詳細(xì)設(shè)計(jì)文檔。它寫得很快接口定義、消息格式、狀態(tài)機(jī)都列出來了。但我逐行審的時(shí)候發(fā)現(xiàn)了幾個(gè)問題它把庫存扣減的響應(yīng)設(shè)計(jì)成了同步返回扣減結(jié)果但我們的場(chǎng)景是異步消息這里它“習(xí)慣性”地用了同步模式。它定義的消息格式里缺少一個(gè)關(guān)鍵字段——業(yè)務(wù)流水號(hào)沒有這個(gè)字段就無法做冪等。它的狀態(tài)機(jī)里少了一個(gè)“已取消”狀態(tài)而我們的業(yè)務(wù)里用戶是可以取消訂單的。這三個(gè)問題都不是“AI能力不足”而是它不知道我的具體約束。同步還是異步、需不需要冪等、有沒有取消操作這些信息只有我有。所以方案設(shè)計(jì)的正確姿勢(shì)是AI負(fù)責(zé)把框架搭出來我負(fù)責(zé)往里填業(yè)務(wù)約束。5.3 評(píng)審階段讓AI扮演“魔鬼代言人”設(shè)計(jì)文檔寫完后我讓AI扮演一個(gè)“專門挑刺的評(píng)審者”提示詞是這樣的“你是一個(gè)嚴(yán)格的架構(gòu)評(píng)審者你的任務(wù)是找出這份設(shè)計(jì)中可能導(dǎo)致線上故障的隱患。重點(diǎn)關(guān)注數(shù)據(jù)一致性、失敗恢復(fù)、并發(fā)沖突、容量瓶頸。每個(gè)隱患要說明觸發(fā)條件和影響范圍?！彼o出了五條意見其中三條是真問題兩條是過度擔(dān)心。真問題里有一條特別有價(jià)值它指出“庫存扣減和履約單生成之間的消息如果重復(fù)消費(fèi)會(huì)導(dǎo)致重復(fù)履約”。這個(gè)問題我確實(shí)沒考慮到后來在消息消費(fèi)端加了冪等校驗(yàn)。AI在“找問題”這件事上比“給方案”靠譜得多因?yàn)檎覇栴}不需要了解你的全部上下文只需要基于通用經(jīng)驗(yàn)做邏輯推演。6. 比工具選型更重要的事建立自己的判斷錨點(diǎn)6.1 為什么同一個(gè)AI在不同人手里效果差很多我觀察到一個(gè)現(xiàn)象同一個(gè)AI工具在不同工程師手里產(chǎn)出的設(shè)計(jì)質(zhì)量差異巨大。有人用AI寫出高質(zhì)量的設(shè)計(jì)文檔有人用AI寫出一堆看似專業(yè)但無法落地的廢話。差異不在于提示詞寫得好不好而在于使用者自己有沒有判斷錨點(diǎn)。判斷錨點(diǎn)就是你腦子里的一套標(biāo)準(zhǔn)什么樣的設(shè)計(jì)是好設(shè)計(jì)、什么樣的方案在你的場(chǎng)景下可行、什么樣的復(fù)雜度是可以接受的。有了這套錨點(diǎn)AI的輸出就是“素材”你可以快速篩選、組合、修正。沒有這套錨點(diǎn)AI的輸出就是“答案”你只能全盤接受或全盤否定。6.2 我的判斷錨點(diǎn)是怎么建立起來的說實(shí)話這個(gè)錨點(diǎn)不是看幾篇文章就能建立的它來自實(shí)際踩坑。我經(jīng)歷過消息重復(fù)消費(fèi)導(dǎo)致數(shù)據(jù)錯(cuò)亂、經(jīng)歷過緩存和數(shù)據(jù)庫不一致導(dǎo)致用戶看到臟數(shù)據(jù)、經(jīng)歷過同步調(diào)用鏈過長導(dǎo)致雪崩。這些經(jīng)歷在我腦子里形成了條件反射看到同步調(diào)用就想到超時(shí)和重試、看到消息就想到冪等和順序、看到緩存就想到失效和穿透。AI可以幫你加速設(shè)計(jì)過程但它不能替你積累這些條件反射。所以我的建議是不要因?yàn)橛辛薃I就跳過“自己動(dòng)手設(shè)計(jì)”的階段。你可以讓AI出初稿但一定要自己逐行審、自己推演失敗路徑、自己算容量。這個(gè)過程本身就是建立判斷錨點(diǎn)的過程。6.3 把AI當(dāng)成“陪練”而不是“代練”我現(xiàn)在對(duì)AI的定位很明確它是一個(gè)不知疲倦的陪練。它可以隨時(shí)陪我推演方案、幫我查漏補(bǔ)缺、給我提供不同視角。但它不能替我上場(chǎng)打比賽。技術(shù)設(shè)計(jì)的最終責(zé)任人是我線上出了故障背鍋的也是我。這個(gè)責(zé)任邊界想清楚了使用AI的心態(tài)就穩(wěn)了——用它提效但不對(duì)它產(chǎn)生依賴參考它的輸出但保留自己的判斷。7. 幾個(gè)讓我印象深刻的“AI翻車”案例7.1 它把“最終一致性”理解成了“最終會(huì)一致”在設(shè)計(jì)一個(gè)跨服務(wù)的余額扣減方案時(shí)AI建議用“異步對(duì)賬補(bǔ)償”來實(shí)現(xiàn)最終一致性。聽起來沒問題但它的補(bǔ)償邏輯是“定時(shí)掃描差異記錄發(fā)現(xiàn)不一致就重新執(zhí)行扣減”。這里有個(gè)致命問題重新執(zhí)行扣減可能導(dǎo)致重復(fù)扣款。它把“最終一致性”簡單理解成了“最終會(huì)一致”但忽略了達(dá)成一致的過程中可能引入新的不一致。正確的做法應(yīng)該是補(bǔ)償操作必須是冪等的或者補(bǔ)償?shù)氖恰靶拚倍皇恰爸胤拧?。比如發(fā)現(xiàn)A服務(wù)扣了款但B服務(wù)沒記賬應(yīng)該補(bǔ)記賬而不是重新扣款。這個(gè)區(qū)別AI沒有區(qū)分因?yàn)樗鼘?duì)“一致性”的理解停留在概念層面沒有落到操作層面。7.2 它給出的容量估算缺少關(guān)鍵變量有一次我讓AI估算一個(gè)消息隊(duì)列的容量需求它給了一個(gè)公式日均消息量 × 峰值系數(shù) ÷ 單機(jī)吞吐。公式本身沒錯(cuò)但它沒有考慮消息大小、副本數(shù)、磁盤IO這些因素。按照它的估算三臺(tái)機(jī)器就夠了但實(shí)際上因?yàn)橄Ⅲw較大加上三副本至少需要六臺(tái)。AI做容量估算時(shí)傾向于用“教科書公式”而忽略工程實(shí)踐中的放大因子。我的經(jīng)驗(yàn)是AI給的估算值至少乘以1.5到2的安全系數(shù)然后再根據(jù)自己的經(jīng)驗(yàn)做調(diào)整。更好的做法是讓它列出估算所依賴的所有假設(shè)你逐個(gè)核對(duì)哪些假設(shè)在你的場(chǎng)景下不成立。7.3 它在“非功能需求”上幾乎從不主動(dòng)展開技術(shù)設(shè)計(jì)里有一類需求叫“非功能需求”性能、可用性、安全性、可維護(hù)性、可觀測(cè)性。AI在功能設(shè)計(jì)上表現(xiàn)不錯(cuò)但在非功能需求上幾乎從不主動(dòng)展開除非你明確要求。比如它設(shè)計(jì)了一個(gè)API但不會(huì)主動(dòng)說這個(gè)API的QPS上限是多少、超時(shí)時(shí)間設(shè)多少、限流策略是什么。我的做法是在提示詞里強(qiáng)制要求它輸出“非功能需求”章節(jié)并且給出具體的數(shù)值而不是定性描述。比如不要寫“高性能”要寫“P99延遲小于200ms支撐5000 QPS”。如果它給不出具體數(shù)值說明它沒有認(rèn)真考慮這個(gè)維度這時(shí)候就需要我自己補(bǔ)上。8. 寫給正在用AI做技術(shù)設(shè)計(jì)的你如果你剛開始用AI輔助技術(shù)設(shè)計(jì)我的建議是先從低風(fēng)險(xiǎn)任務(wù)開始逐步建立信任邊界。不要一上來就讓AI設(shè)計(jì)核心鏈路先讓它幫你整理文檔、列方案對(duì)比、做檢查清單。在這些低風(fēng)險(xiǎn)場(chǎng)景里你會(huì)慢慢摸清它的能力邊界和犯錯(cuò)模式。然后養(yǎng)成“追問假設(shè)”的習(xí)慣。每次AI給出一個(gè)方案不要只看結(jié)論要看它依賴了哪些假設(shè)。這些假設(shè)往往藏在字里行間需要你主動(dòng)追問才能暴露出來。比如它說“用緩存提升性能”你就問“緩存失效時(shí)怎么辦”它說“異步解耦”你就問“消息丟了怎么補(bǔ)償”。最后保留自己動(dòng)手設(shè)計(jì)的習(xí)慣。AI可以幫你寫初稿、做檢查、提供參考但核心決策必須自己拍板。這不是因?yàn)锳I不可靠而是因?yàn)橹挥心阕约簩?duì)業(yè)務(wù)上下文負(fù)責(zé)。AI不知道你的團(tuán)隊(duì)能力、不知道你的運(yùn)維現(xiàn)狀、不知道你的用戶特征這些只有你知道。把AI的輸出和你的上下文結(jié)合才是技術(shù)設(shè)計(jì)的正確打開方式。我在實(shí)際使用中最大的體會(huì)是AI讓“寫設(shè)計(jì)文檔”這件事變快了但讓“想清楚設(shè)計(jì)”這件事變得更重要了。因?yàn)楫?dāng)生成變得廉價(jià)判斷就變成了稀缺能力。你得知道什么是對(duì)的、什么是錯(cuò)的、什么是在你的場(chǎng)景下可行的。這個(gè)判斷力AI給不了你只能自己練。