代的企業(yè)級(jí)應(yīng)用架構(gòu)：從模塊邊界到工程治理的落地實(shí)踐)
1. AI Coding 到底改變了企業(yè)架構(gòu)的什么AI Coding 這個(gè)詞這兩年已經(jīng)從技術(shù)圈的熱搜變成了很多企業(yè)技術(shù)規(guī)劃里的必選項(xiàng)。我最近接觸了幾個(gè)團(tuán)隊(duì)有做供應(yīng)鏈系統(tǒng)的有做內(nèi)部數(shù)據(jù)平臺(tái)的還有做金融交易輔助的幾乎都在問(wèn)同一個(gè)問(wèn)題AI 生成的代碼到底怎么落到企業(yè)級(jí)應(yīng)用架構(gòu)里才不會(huì)變成新的技術(shù)債工具選型其實(shí)只是個(gè)人效率層面的事真正決定這些工具能不能穩(wěn)定產(chǎn)出、安全上線的是架構(gòu)層面的調(diào)整。我自己有一個(gè)很明確的觀點(diǎn)AI Coding 時(shí)代的企業(yè)級(jí)應(yīng)用架構(gòu)核心不是把 AI 變成“寫代碼的人”而是把 AI 產(chǎn)出物當(dāng)成一個(gè)必須經(jīng)過(guò)校驗(yàn)、可以回滾、可以追溯的變更來(lái)源然后圍繞它重新排列研發(fā)流程和系統(tǒng)邊界。這個(gè)思路看起來(lái)抽象但它會(huì)具體影響模塊拆得多細(xì)、接口要怎么定義、CI 流水線卡在哪里、代碼評(píng)審重點(diǎn)看什么。下面從六個(gè)方面展開說(shuō)都是這大半年我在不同團(tuán)隊(duì)里反復(fù)驗(yàn)證過(guò)的做法也不全是成功經(jīng)驗(yàn)踩坑的部分更有參考價(jià)值。1.1 從“寫得慢”到“生成得慢”研發(fā)瓶頸其實(shí)轉(zhuǎn)移了在傳統(tǒng)研發(fā)里一個(gè)需求理解清楚之后瓶頸多半在編碼一行行寫、逐個(gè)方法調(diào)、反復(fù)編譯?，F(xiàn)在 AI 把這一環(huán)大幅提速團(tuán)隊(duì)的注意力反而開始卡在更早和更晚兩個(gè)位置——更早是需求上下文更晚是代碼評(píng)審。我見過(guò)一個(gè)實(shí)際例子三個(gè)開發(fā)者同時(shí)用 AI 生成一個(gè)新模塊一周產(chǎn)出了平時(shí)三倍多的 PR結(jié)果評(píng)審隊(duì)列直接積壓了兩周。代碼評(píng)審的人根本看不過(guò)來(lái)只能挑重點(diǎn)看最后上線的版本帶著兩個(gè)邊界條件錯(cuò)誤其中一個(gè)還是線上事故級(jí)別。問(wèn)題不在 AI而在系統(tǒng)設(shè)計(jì)時(shí)根本沒(méi)有預(yù)留“可評(píng)審性”模塊拆得太粗一個(gè) PR 動(dòng)輒上千行人沒(méi)法在有限注意力里發(fā)現(xiàn)陷阱。所以架構(gòu)設(shè)計(jì)的第一條新約束是讓模塊粒度匹配單次評(píng)審的容量。一個(gè)合理的顆粒度是單個(gè) PR 涉及 3 到 5 個(gè)文件改動(dòng) 200 行左右業(yè)務(wù)語(yǔ)義完整評(píng)審人可以一次看完并給出結(jié)論。這種粒度以前也提倡但現(xiàn)在不是“建議”而是“必須”。AI 生成代碼的速度遠(yuǎn)超人腦評(píng)審速度如果不做這一步后面所有效率收益都會(huì)在評(píng)審環(huán)節(jié)被抵消。這個(gè)約束還會(huì)反過(guò)來(lái)影響服務(wù)拆分的層級(jí)。以前我們可能習(xí)慣把多個(gè)相關(guān)領(lǐng)域放在一個(gè)大模塊里靠人可以記住全局現(xiàn)在 AI 一旦介入大模塊的上下文復(fù)雜度會(huì)直接失控。一個(gè)模塊的職責(zé)邊界越模糊AI 生成代碼時(shí)就越容易“自由發(fā)揮”產(chǎn)出的代碼和真實(shí)業(yè)務(wù)意圖的偏差就會(huì)越大。所以 AI Coding 落地之后DDD 這類領(lǐng)域建模方法的重要性反而更高了因?yàn)樗烊灰笪覀儼涯K邊界、領(lǐng)域術(shù)語(yǔ)、業(yè)務(wù)規(guī)則都顯式化。1.2 模塊邊界本質(zhì)上變成了模型的上下文邊界大模型的行為受上下文窗口限制這聽起來(lái)是個(gè)技術(shù)參數(shù)實(shí)際上直接改變了企業(yè)架構(gòu)的拆分邏輯。以前我們拆模塊主要依據(jù)業(yè)務(wù)領(lǐng)域、團(tuán)隊(duì)歸屬、部署單元現(xiàn)在還要多考慮一個(gè)問(wèn)題模型生成這段代碼時(shí)需要給它多少上下文這個(gè)上下文是否干凈。我接觸過(guò)的團(tuán)隊(duì)里做得好的會(huì)為每個(gè)模塊維護(hù)一個(gè)“上下文包”里面只放三類內(nèi)容。第一類是必須上下文包括接口簽名、領(lǐng)域核心實(shí)體、本模塊的編碼約束第二類是參考上下文包括相似歷史實(shí)現(xiàn)、內(nèi)部工具類第三類是輔助上下文比如設(shè)計(jì)文檔里的決策背景和約束說(shuō)明。其他內(nèi)容一律不進(jìn)包尤其是無(wú)關(guān)配置、其他模塊的細(xì)節(jié)以及已經(jīng)被廢棄的舊代碼。這里可以用個(gè)生活類比以前項(xiàng)目經(jīng)理把需求講給程序員程序員聽完可以存在腦子里長(zhǎng)期記憶容量大現(xiàn)在的模型更像一個(gè)“一次性臨時(shí)工”你交代了什么它就按什么做。如果交代的內(nèi)容里混進(jìn)一堆無(wú)關(guān)信息它很容易被帶偏。我甚至見過(guò)有人把一個(gè)跨五個(gè)模塊的系統(tǒng)說(shuō)明文檔整篇塞進(jìn) prompt結(jié)果模型生成的代碼里到處都是對(duì)別的模塊的臆想調(diào)用。問(wèn)題不在模型在喂給模型的上下文太亂。所以架構(gòu)層面要把“上下文資產(chǎn)管理”當(dāng)成正經(jīng)事模塊文檔要精簡(jiǎn)、接口要顯式、歷史設(shè)計(jì)決策要寫成一兩段話而不是藏在一萬(wàn)行代碼注釋里。理想狀態(tài)下一個(gè)模塊的上下文包應(yīng)該能在幾分鐘內(nèi)讀完并且能讓一個(gè)不熟悉該模塊的開發(fā)者快速理解邊界。模型和人在這里需求是一致的只是模型比人更不能容忍廢話。1.3 統(tǒng)一術(shù)語(yǔ)和命名別讓 AI 自由發(fā)揮AI 生成代碼時(shí)有一個(gè)容易被忽視的偏好它的命名風(fēng)格會(huì)強(qiáng)烈參考現(xiàn)有代碼。如果一個(gè)系統(tǒng)里“訂單號(hào)”有三種寫法模型在生成新邏輯時(shí)可能隨機(jī)參考其中一種長(zhǎng)此以往整個(gè)代碼庫(kù)的命名一致性會(huì)明顯惡化。解決這件事靠的不是模型而是架構(gòu)層的一份輕量領(lǐng)域詞典。核心實(shí)體、狀態(tài)枚舉、錯(cuò)誤碼、事件名都在這份詞典里固定下來(lái)。比如訂單狀態(tài)只能有創(chuàng)建、支付中、已支付、已取消、已關(guān)閉這幾個(gè)字面量模型生成的代碼里如果出現(xiàn)其他同義表達(dá)靜態(tài)分析工具直接卡住。這看起來(lái)是規(guī)范問(wèn)題但在 AI Coding 場(chǎng)景里是硬約束。我之所以強(qiáng)調(diào)這一點(diǎn)是因?yàn)槿丝创a時(shí)會(huì)自動(dòng)腦補(bǔ)看到 userInfo 和 userProfile 能猜到可能是同一個(gè)東西模型不會(huì)。它只會(huì)機(jī)械地推斷類名和字段名的對(duì)應(yīng)關(guān)系。如果詞典不統(tǒng)一AI 生成的新代碼和存量代碼之間會(huì)形成“語(yǔ)義斷層”后續(xù)維護(hù)成本是指數(shù)級(jí)上升的。實(shí)際操作上團(tuán)隊(duì)可以先花一兩個(gè)工作日做一版詞典初稿不用追求完整先把高頻出現(xiàn)的實(shí)體和狀態(tài)定死。然后把它維護(hù)成文檔同時(shí)在靜態(tài)掃描規(guī)則里加上命名校驗(yàn)。每次評(píng)審時(shí)如果發(fā)現(xiàn)命名和詞典不符不是讓開發(fā)者改名字而是先判斷是不是該把新詞加入詞典——這一步很關(guān)鍵否則詞典會(huì)變成新的官僚文檔。2. 技術(shù)選型不是模型越強(qiáng)越好而是場(chǎng)景對(duì)得上2.1 代碼資產(chǎn)安全等級(jí)決定部署模式先說(shuō)一個(gè)很多團(tuán)隊(duì)一開始不會(huì)考慮的問(wèn)題代碼本身是核心資產(chǎn)。一個(gè)跑了幾年的業(yè)務(wù)系統(tǒng)代碼里藏著業(yè)務(wù)規(guī)則、數(shù)據(jù)庫(kù)結(jié)構(gòu)、密鑰調(diào)用邏輯、第三方接口的鑒權(quán)方式。如果 AI 編程工具默認(rèn)把代碼片段發(fā)送到外部 API對(duì)很多企業(yè)來(lái)說(shuō)就已經(jīng)踩到了合規(guī)紅線。所以在選型前我習(xí)慣先畫一條數(shù)據(jù)邊界。按照代碼敏感度分成三類能進(jìn)公有模型的產(chǎn)品代碼、脫敏后才能進(jìn)的產(chǎn)品代碼、絕對(duì)不能進(jìn)模型的代碼。畫完這條線部署模式基本就定了。現(xiàn)在主流的做法有三種本地私有化部署、通過(guò)內(nèi)部網(wǎng)關(guān)調(diào)用外部模型 API、混合部署。它們各有適用場(chǎng)景。部署模式數(shù)據(jù)出境部署成本模型更新速度典型場(chǎng)景本地/私有化完全不出內(nèi)網(wǎng)高需算力資源慢依賴內(nèi)部迭代強(qiáng)合規(guī)行業(yè)、涉密項(xiàng)目企業(yè)API網(wǎng)關(guān)代理受控出境統(tǒng)一審計(jì)中等僅需網(wǎng)關(guān)快跟隨外部版本多數(shù)中大型企業(yè)混合模式按策略分流中高取決于配置大型集團(tuán)、多業(yè)務(wù)線我見過(guò)一家做內(nèi)部數(shù)據(jù)平臺(tái)的公司為了數(shù)據(jù)安全選了本地私有化小模型。模型能力確實(shí)不如公有大模型但團(tuán)隊(duì)把上下文包做得非常精細(xì)生成質(zhì)量反而比之前用公有 API 時(shí)更穩(wěn)。原因很簡(jiǎn)單上下文質(zhì)量彌補(bǔ)了模型參數(shù)差距。在真實(shí)企業(yè)場(chǎng)景里數(shù)據(jù)可達(dá)性和模型上限同等重要甚至數(shù)據(jù)可控性更優(yōu)先。這里還要強(qiáng)調(diào)團(tuán)隊(duì)里如果有人把公司代碼片段貼到公有 AI 工具里無(wú)論選型做了什么都不算真正安全。所以要配合技術(shù)手段在網(wǎng)關(guān)上做檢測(cè)同時(shí)把數(shù)據(jù)安全要求寫進(jìn)研發(fā)守則。制度和技術(shù)兩條腿一起走才是最穩(wěn)的落地方式。2.2 能力分級(jí)補(bǔ)全、生成、重構(gòu)、Agent 各有邊界AI 編程能力不是一個(gè)開關(guān)而是分為四個(gè)層級(jí)補(bǔ)全、生成、重構(gòu)、Agent。每個(gè)層級(jí)的復(fù)雜度不同會(huì)影響多少個(gè)文件、能不能自動(dòng)執(zhí)行多個(gè)步驟所以對(duì)應(yīng)的風(fēng)險(xiǎn)等級(jí)也不一樣接入方式必須分開對(duì)待。補(bǔ)全是最輕的能力適合 IDE 里的單行和小塊代碼延遲要低上下文只需要看當(dāng)前文件。函數(shù)和文件生成需要完整模塊上下文模型要理解接口簽名、業(yè)務(wù)規(guī)則、依賴關(guān)系適合新模塊的骨架開發(fā)。跨文件重構(gòu)風(fēng)險(xiǎn)明顯更高會(huì)同時(shí)改動(dòng)多個(gè)文件必須有完整測(cè)試和人工評(píng)審兜底。Agent 模式則會(huì)讓模型自主規(guī)劃多步任務(wù)、調(diào)用工具、修改多處代碼這種自由度放到核心業(yè)務(wù)鏈路上非常危險(xiǎn)。我見過(guò)一個(gè)團(tuán)隊(duì)讓 Agent 直接處理訂單狀態(tài)遷移模型按照自己的理解把狀態(tài)機(jī)改了上線當(dāng)天就出了訂單卡單。后來(lái)他們立了一條規(guī)矩Agent 只能跑在不會(huì)直接產(chǎn)生業(yè)務(wù)寫入的環(huán)節(jié)比如生成報(bào)表查詢、批量制造測(cè)試數(shù)據(jù)、整理運(yùn)維腳本核心狀態(tài)機(jī)必須由人寫AI 最多補(bǔ)輔助方法。這條規(guī)矩我建議每個(gè)準(zhǔn)備引入 Agent 的團(tuán)隊(duì)都照抄。還有一種常見誤區(qū)是把所有場(chǎng)景都接到最強(qiáng)模型上。實(shí)際做下來(lái)補(bǔ)全場(chǎng)景用輕量模型就夠了響應(yīng)還更快跨文件重構(gòu)反而需要更強(qiáng)的模型和更大的上下文。選型的時(shí)候按場(chǎng)景分級(jí)不要一刀切。分級(jí)之后還要給每個(gè)層級(jí)配置不同的發(fā)布門檻補(bǔ)全直接體驗(yàn)生成走普通 PR 流程Agent 必須套沙箱和完整評(píng)審。2.3 把AI能力做成可插拔的基礎(chǔ)層企業(yè)里用 AI 不應(yīng)該是一個(gè)個(gè)開發(fā)者各接各的。更合理的做法是在平臺(tái)層做一個(gè)統(tǒng)一入口把鑒權(quán)、模型路由、指令模板、日志審計(jì)都收進(jìn)去。我習(xí)慣叫它“AI 編碼網(wǎng)關(guān)”IDE 插件、命令行、CI 流水線都連這個(gè)網(wǎng)關(guān)底層模型只是可替換的供應(yīng)商實(shí)現(xiàn)。這樣做的好處非?，F(xiàn)實(shí)。第一換模型時(shí)不改業(yè)務(wù)代碼只需在網(wǎng)關(guān)層改路由配置第二可以同時(shí)對(duì)兩個(gè)模型做 A/B 對(duì)比看誰(shuí)的產(chǎn)出更穩(wěn)定第三所有生成記錄統(tǒng)一留痕責(zé)任可追溯。這和企業(yè)架構(gòu)里服務(wù)通過(guò)接口依賴數(shù)據(jù)庫(kù)、通過(guò)消息隊(duì)列解耦上下游是一個(gè)道理都是讓使用方依賴抽象不依賴具體實(shí)現(xiàn)。網(wǎng)關(guān)的復(fù)雜度也要控制。不需要一開始就搞成一個(gè)大平臺(tái)重點(diǎn)做三件事統(tǒng)一入口、統(tǒng)一審計(jì)、統(tǒng)一策略。先把門面立住后面再逐步加模型灰度、成本統(tǒng)計(jì)、質(zhì)量報(bào)表這些能力。如果一開始就把網(wǎng)關(guān)做得太重反而會(huì)拖慢 AI Coding 的落地節(jié)奏。我建議網(wǎng)關(guān)至少要記錄四類信息調(diào)用者、模型版本、上下文包的標(biāo)識(shí)、生成時(shí)間。這些信息往后會(huì)變成審計(jì)和排障的基礎(chǔ)。沒(méi)有這套記錄AI 真的在線上出了事故你根本說(shuō)不清這段代碼是怎么來(lái)的。3. 可驗(yàn)證性與可回滾性架構(gòu)設(shè)計(jì)的新約束3.1 測(cè)試先行從最佳實(shí)踐變成必要條件AI 生成的代碼是否可靠很大程度上取決于有沒(méi)有明確的行為邊界。行為邊界最好的表達(dá)就是測(cè)試。我見過(guò)最有效的流程是寫需求時(shí)直接把關(guān)鍵業(yè)務(wù)規(guī)則轉(zhuǎn)成契約測(cè)試先讓測(cè)試跑掛再把測(cè)試交給 AI讓它去實(shí)現(xiàn)。這個(gè)流程看起來(lái)多了一步測(cè)試前置實(shí)際總耗時(shí)反而更短因?yàn)?AI 不用反復(fù)試探需求。比如一個(gè)查詢接口先定義好輸入?yún)?shù)、預(yù)期返回、異常碼再寫正常路徑、邊界值、非法入?yún)⒌臏y(cè)試用例AI 要做的就是把這些用例全部跑綠。測(cè)試一旦先立住模型怎么發(fā)揮都不會(huì)跑偏。這里有個(gè)特別要注意的細(xì)節(jié)契約測(cè)試不要跟 AI 生成代碼放同一個(gè)提交。如果測(cè)試和實(shí)現(xiàn)一起放上去AI 容易“反向編寫”測(cè)試讓測(cè)試適應(yīng)自己代碼的行為那就等于自我打分失去了校驗(yàn)意義。正確做法是測(cè)試先合入主干并標(biāo)記為失敗或跳過(guò)AI 實(shí)現(xiàn)代碼再在另一個(gè)提交里把它修到綠。我在實(shí)際項(xiàng)目里看到過(guò)很多次“單測(cè)全綠但業(yè)務(wù)完全不對(duì)”的情況。因?yàn)槟Ｐ秃苌瞄L(zhǎng)從測(cè)試代碼里推斷出實(shí)現(xiàn)的形狀但無(wú)法理解真實(shí)業(yè)務(wù)的前因后果。所以測(cè)試先行不只是流程控制更是把業(yè)務(wù)知識(shí)固化下來(lái)讓 AI 在有限范圍內(nèi)自主發(fā)揮。3.2 把不可變部分寫進(jìn)代碼約束企業(yè)級(jí)系統(tǒng)里有很多東西不應(yīng)該由 AI 自由決定對(duì)外 API 的簽名、數(shù)據(jù)庫(kù)字段、消息 Topic、錯(cuò)誤碼、權(quán)限模型。架構(gòu)設(shè)計(jì)的任務(wù)是把這些部分用強(qiáng)類型方式固定下來(lái)AI 只能填空不能改框架。這個(gè)思路可以用高速公路的護(hù)欄來(lái)類比好的司機(jī)正常不會(huì)沖出路面但護(hù)欄的意義在于即使操作失誤也不會(huì)造成災(zāi)難。AI 的推理是概率性的再好的模型也可能在上下文不完整時(shí)突發(fā)奇想。如果接口定義文件里聲明訂單金額是強(qiáng)類型小數(shù)模型生成的代碼就不能偷偷換成浮點(diǎn)數(shù)如果數(shù)據(jù)庫(kù)遷移腳本鎖定了表結(jié)構(gòu)模型生成的變更語(yǔ)句就必須經(jīng)過(guò)獨(dú)立評(píng)審。實(shí)際落地上要配合工具鏈嚴(yán)格的類型檢查在編譯期攔接口變更檢查在 CI 攔數(shù)據(jù)庫(kù)變更必須走獨(dú)立流程。這些約束不需要靠抽查而是直接寫進(jìn)自動(dòng)化門禁。我在一個(gè)項(xiàng)目里甚至要求核心模塊引入任何新依賴都需要單獨(dú)審批這一條就把 AI 生成代碼時(shí)胡亂加依賴的風(fēng)險(xiǎn)擋掉大半。還有一類不可變部分容易被忽略團(tuán)隊(duì)內(nèi)部的基礎(chǔ)約定比如統(tǒng)一錯(cuò)誤碼格式、統(tǒng)一日志格式、統(tǒng)一異步消息版本策略。這類約定不寫在代碼里而是寫成“模塊編碼指南”并且作為上下文包的一部分喂給模型。模型生成時(shí)會(huì)更傾向于遵守這些約定偏離的機(jī)會(huì)大大減少。3.3 生成記錄與回滾能力AI 生成的代碼最大的治理問(wèn)題是“來(lái)路不明”。人工寫的代碼寫的人知道自己當(dāng)時(shí)為什么這么寫模型生成的代碼如果不記錄輸入上下文三個(gè)月后沒(méi)人能說(shuō)清這段代碼為什么長(zhǎng)成這樣。所以在工程規(guī)范里建議 AI 輔助的提交都帶上結(jié)構(gòu)化信息模型標(biāo)識(shí)和版本、上下文包 ID、人工改動(dòng)摘要、相關(guān)評(píng)審單號(hào)。CI 可以根據(jù)這些字段把提交標(biāo)記為“AI 輔助”對(duì)這類提交跑更嚴(yán)格的質(zhì)量門。以后要回滾時(shí)能快速定位“哪個(gè)生成版本加人工修復(fù)點(diǎn)”是最后一個(gè)穩(wěn)定組合。我在實(shí)際項(xiàng)目里還會(huì)定期導(dǎo)出生成記錄報(bào)表看哪些模塊 AI 介入最多、哪些模塊生成后被改得最頻繁。被改得頻繁的模塊通常說(shuō)明上下文沒(méi)描述清楚或者接口設(shè)計(jì)不合理這些信號(hào)比任何指標(biāo)都更能暴露架構(gòu)缺陷?；貪L能力同樣要考慮版本管理。模型版本升級(jí)后同一段 prompt 生成的結(jié)果可能完全不同這會(huì)導(dǎo)致“生成版本漂移”。所以上下文包里最好記錄實(shí)用的模型版本和參數(shù)線上要回滾時(shí)能精確還原當(dāng)時(shí)的生成條件。這件事看起來(lái)繁瑣但在出事故時(shí)就是救命的稻草。4. 工程鏈路改造CI/CD 如何接住 AI 產(chǎn)出4.1 評(píng)審流程升級(jí)從看 diff 到看生成前提傳統(tǒng)代碼評(píng)審看的是 diff問(wèn)的是“改了什么”AI 生成的代碼評(píng)審更該問(wèn)的是“為什么這么寫”。原因很簡(jiǎn)單模型不會(huì)告訴你它為什么選擇這個(gè)實(shí)現(xiàn)如果你不給它前置信息評(píng)審人只能對(duì)著代碼猜。所以 PR 模板要增加 AI 描述字段。建議至少包含這次生成用了什么上下文、目標(biāo)是什么、模型版本是什么、人工做了哪幾處調(diào)整。評(píng)審人的關(guān)注點(diǎn)也要調(diào)整不用再盯每個(gè)縮進(jìn)和變量命名重點(diǎn)放在業(yè)務(wù)邊界、異常路徑、事務(wù)邊界、外部依賴調(diào)用這四個(gè)地方。我整理了一份用于 AI 生成代碼的評(píng)審檢查清單團(tuán)隊(duì)可以直接用輸入校驗(yàn)空值、超長(zhǎng)、非法枚舉有沒(méi)有漏事務(wù)邊界多表寫入是否在一個(gè)事務(wù)里回滾邏輯是否完整外部調(diào)用超時(shí)和重試設(shè)了沒(méi)有是否走統(tǒng)一出口日志與返回有沒(méi)有打印敏感字段異常信息是否泄露內(nèi)部結(jié)構(gòu)依賴變化新增依賴是否在白名單內(nèi)版本是否鎖定檢查清單要固化到評(píng)審流程里不能靠口頭強(qiáng)調(diào)。AI 產(chǎn)出量大之后口頭的提醒很快就會(huì)被淹沒(méi)。我在一個(gè)團(tuán)隊(duì)里看到他們把這份清單做成了瀏覽器插件評(píng)審 PR 時(shí)逐項(xiàng)打勾效果比任何培訓(xùn)都明顯。4.2 測(cè)試策略契約測(cè)試和模糊測(cè)試的權(quán)重提上來(lái)常規(guī)開發(fā)里我們用單元測(cè)試覆蓋業(yè)務(wù)邏輯。AI 生成代碼后單測(cè)當(dāng)然還要但它解決不了“模型誤解業(yè)務(wù)規(guī)則”的問(wèn)題。這時(shí)候要引入兩個(gè)補(bǔ)充契約測(cè)試和模糊測(cè)試。契約測(cè)試固定模塊之間的接口行為。比如 A 模塊調(diào)用 B 模塊的服務(wù)先把兩邊的請(qǐng)求響應(yīng)結(jié)構(gòu)用契約定死AI 重構(gòu)其中任何一邊時(shí)如果悄悄改變了行為測(cè)試會(huì)立刻報(bào)警。模糊測(cè)試則是隨機(jī)生成邊界輸入抓 AI 代碼里沒(méi)考慮到的邊界條件。我印象很深的一次事故是一個(gè)內(nèi)部 API 被 AI 重構(gòu)后單測(cè)全綠但把入?yún)恼龜?shù)改成負(fù)數(shù)時(shí)服務(wù)直接拋出了數(shù)據(jù)庫(kù)層的原生異常。原因就是沒(méi)有模糊測(cè)試模型實(shí)現(xiàn)簡(jiǎn)單假設(shè)了所有參數(shù)都是合法的。從那以后CI 里增加了隨機(jī)邊界測(cè)試這類問(wèn)題少了很多。AI 寫單測(cè)確實(shí)很快但關(guān)鍵模塊我更傾向于人工先寫核心 caseAI 補(bǔ)外圍用例。因?yàn)榧冏?AI 寫測(cè)試它容易陷入“路徑依賴”只會(huì)圍繞自己生成的實(shí)現(xiàn)找覆蓋路徑根本不會(huì)去質(zhì)疑實(shí)現(xiàn)的邏輯本身。變異測(cè)試的思路在這里可以參考把一個(gè)條件判斷改掉測(cè)試如果沒(méi)失敗說(shuō)明這個(gè)用例根本沒(méi)校驗(yàn)到關(guān)鍵邏輯。這種查漏方法單靠 AI 是出不來(lái)的。4.3 質(zhì)量門用自動(dòng)化卡點(diǎn)替代人肉把關(guān)AI 產(chǎn)出的量一旦上來(lái)靠人評(píng)審根本不現(xiàn)實(shí)。CI 流水線必須加入自動(dòng)質(zhì)量門把常規(guī)問(wèn)題在提交時(shí)攔下來(lái)。重點(diǎn)卡幾個(gè)位置靜態(tài)代碼掃描、安全掃描、依賴白名單、覆蓋率閾值、構(gòu)建耗時(shí)上限。我常用的閾值配置如下團(tuán)隊(duì)可以按實(shí)際情況調(diào)整質(zhì)量門建議閾值高危安全漏洞0新增代碼單元測(cè)試覆蓋率≥ 80%單次構(gòu)建時(shí)長(zhǎng)上限10 至 15 分鐘未審批依賴0關(guān)鍵模塊評(píng)審人必須指定質(zhì)量門失敗時(shí)AI 提交自動(dòng)進(jìn)草稿狀態(tài)不阻塞低風(fēng)險(xiǎn)的人工改動(dòng)這樣可以減少流程摩擦。關(guān)鍵點(diǎn)是 AI 產(chǎn)出和人工產(chǎn)出在進(jìn)入主干前要用同一套標(biāo)準(zhǔn)否則 AI 帶來(lái)的效率提升最后會(huì)變成技術(shù)債和線上事故。還有一個(gè)小細(xì)節(jié)質(zhì)量門不能只在主干分支跑每個(gè) PR 分支都要跑。否則 AI 生成的代碼在分支里看著沒(méi)問(wèn)題合并以后和主干其他改動(dòng)疊加問(wèn)題才暴露出來(lái)那時(shí)候排查成本就成倍增加了。5. 治理與安全企業(yè)級(jí)繞不開的三道坎5.1 AI 產(chǎn)出里的漏洞基因大模型的訓(xùn)練數(shù)據(jù)來(lái)自海量開源代碼這些代碼里有大量歷史漏洞模式。模型不會(huì)主動(dòng)判斷“這段代碼是否安全”它只是按照概率分布補(bǔ)全最可能的內(nèi)容。因此 AI 生成的代碼天然可能攜帶 SQL 注入、跨站腳本、敏感信息硬編碼、危險(xiǎn)反序列化這類問(wèn)題。企業(yè)級(jí)的應(yīng)對(duì)不是禁用 AI而是把安全掃描前置。很多團(tuán)隊(duì)等到代碼推到 CI 才做安全掃描AI 產(chǎn)出量一大排隊(duì)和等待時(shí)間就會(huì)拖垮流程。更好的做法是讓掃描跑在開發(fā)者本地提交前一個(gè)輕量的快速掃描卡高危問(wèn)題直接阻斷CI 再跑深度掃描。安全掃描的規(guī)則也要基于業(yè)務(wù)定制。比如內(nèi)部系統(tǒng)重點(diǎn)查越權(quán)訪問(wèn)和敏感數(shù)據(jù)泄露交易系統(tǒng)重點(diǎn)查金額計(jì)算和并發(fā)更新。我這里說(shuō)的不是安全團(tuán)隊(duì)單方面定規(guī)則而是讓一線研發(fā)把常見問(wèn)題反饋給安全團(tuán)隊(duì)雙方一起維護(hù)規(guī)則集這樣掃描規(guī)則才會(huì)越來(lái)越貼合真實(shí)場(chǎng)景。5.2 上下文與敏感數(shù)據(jù)邊界模型生成質(zhì)量取決于上下文但不能為了質(zhì)量把敏感數(shù)據(jù)無(wú)差別喂給模型。企業(yè)內(nèi)部至少要有一個(gè)簡(jiǎn)單的分級(jí)可以進(jìn)入上下文接口簽名、領(lǐng)域?qū)嶓w、公開設(shè)計(jì)文檔脫敏后可以進(jìn)入帶示例數(shù)據(jù)的表結(jié)構(gòu)、日志樣例、非生產(chǎn) SQL禁止進(jìn)入密鑰、真實(shí)用戶數(shù)據(jù)、生產(chǎn)環(huán)境數(shù)據(jù)架構(gòu)層圍繞這個(gè)分級(jí)做兩件事。一是在 IDE 插件和網(wǎng)關(guān)上做敏感信息掃描發(fā)現(xiàn)密鑰、身份證號(hào)、手機(jī)號(hào)等模式就打碼并記錄二是保留審計(jì)日志記錄什么時(shí)間段、誰(shuí)、用什么上下文喂給了什么模型。數(shù)據(jù)合規(guī)部門來(lái)查的時(shí)候可以直接拿出證據(jù)鏈。我見過(guò)一個(gè)比較創(chuàng)新的做法給不同敏感等級(jí)的代碼準(zhǔn)備不同的“示例環(huán)境”。比如讓模型看表結(jié)構(gòu)時(shí)表結(jié)構(gòu)里的用戶名字段被替換成“測(cè)試用戶張三”金額字段被替換成“1000.00”。這樣模型可以理解語(yǔ)義但接觸不到真實(shí)數(shù)據(jù)模式。這個(gè)思路在內(nèi)部合規(guī)要求比較嚴(yán)的團(tuán)隊(duì)里很實(shí)用。5.3 許可證與供應(yīng)鏈污染AI 的“原創(chuàng)”有時(shí)候其實(shí)是記憶拼接。模型可能生成一段和某開源項(xiàng)目高度相似的代碼帶來(lái)許可證層面的風(fēng)險(xiǎn)。這個(gè)風(fēng)險(xiǎn)在傳統(tǒng)人工開發(fā)里是偶發(fā)的但在 AI 生成模式下變成了默認(rèn)場(chǎng)景所以供應(yīng)鏈檢查必須常駐。做法是把軟件成分分析加進(jìn)發(fā)布流水線持續(xù)生成依賴清單和 SBOM并維護(hù)許可證白名單。常見的寬松許可證可以直接進(jìn)白名單傳染性強(qiáng)的許可證需要單獨(dú)審批。團(tuán)隊(duì)內(nèi)部也要在 AI 協(xié)作規(guī)范里寫清楚AI 生成代碼不等于無(wú)版權(quán)代碼上生產(chǎn)前要過(guò)成分分析。這件事很多人覺得麻煩但真出了合規(guī)問(wèn)題再回頭補(bǔ)成本高得多。另外還要關(guān)注基礎(chǔ)設(shè)施層面的供應(yīng)鏈風(fēng)險(xiǎn)。AI 生成的代碼可能自己引入新的依賴這些依賴如果不鎖定版本下次構(gòu)建時(shí)可能悄然拉取到有漏洞的新版本。所以在依賴鎖定的基礎(chǔ)上每次發(fā)布前最好都重新跑一遍依賴掃描而不是只在首次引入時(shí)掃描一次。6. 落地路徑從試點(diǎn)到全量推廣6.1 試點(diǎn)項(xiàng)目怎么選不要一上來(lái)就選核心交易系統(tǒng)做 AI 全量試點(diǎn)。我建議從三類項(xiàng)目里挑內(nèi)部管理工具、報(bào)表查詢系統(tǒng)、非核心 CRUD 服務(wù)。選擇標(biāo)準(zhǔn)就三條模塊邊界清楚、測(cè)試覆蓋有一定基礎(chǔ)、團(tuán)隊(duì)愿意接受評(píng)審規(guī)則改變。另一個(gè)穩(wěn)妥的做法是選一個(gè)中等復(fù)雜度的服務(wù)先用 AI 做新增模塊而不是改造老模塊。老模塊里的潛規(guī)則太多模型很難通過(guò)上下文完全理解新模塊沒(méi)有歷史包袱約束可以從第一天就立住。試點(diǎn)周期控制在 4 到 6 周結(jié)束后做一次系統(tǒng)性指標(biāo)對(duì)比再?zèng)Q定是否擴(kuò)大范圍。選錯(cuò)試點(diǎn)項(xiàng)目會(huì)在第一周就被線上問(wèn)題打擊到團(tuán)隊(duì)信心后面再推廣就難了。我甚至見過(guò)一個(gè)團(tuán)隊(duì)在核心支付服務(wù)上試點(diǎn) Agent結(jié)果第三天就回滾整個(gè)公司對(duì) AI Coding 的態(tài)度從此變得極度保守。后來(lái)?yè)Q了報(bào)表系統(tǒng)試點(diǎn)效果不錯(cuò)但前期的信任損傷很難完全挽回。6.2 度量指標(biāo)別拿代碼行數(shù)證明自己快最容易踩的坑是拿“AI 生成代碼行數(shù)和占比”證明成果。這個(gè)指標(biāo)會(huì)誘導(dǎo)團(tuán)隊(duì)為了好看而批量制造重復(fù)代碼反而增加維護(hù)成本。更值得看的是研發(fā)交付鏈路本身需求到上線的周期、平均 PR 評(píng)審耗時(shí)、缺陷逃逸率、自動(dòng)化測(cè)試通過(guò)率、線上事故數(shù)。指標(biāo)類型具體指標(biāo)觀察方式效率類需求到上線周期、人均交付需求數(shù)按周記錄趨勢(shì)質(zhì)量類缺陷逃逸率、線上事故數(shù)、測(cè)試覆蓋率變化對(duì)比引入前后 6 周體驗(yàn)類開發(fā)者滿意度、評(píng)審隊(duì)列積壓數(shù)月度回訪舉個(gè)例子如果引入 AI 之后 PR 數(shù)量暴增但需求上線周期沒(méi)有縮短說(shuō)明流程沒(méi)有接住 AI評(píng)審變成新瓶頸如果缺陷逃逸率在上升說(shuō)明質(zhì)量門沒(méi)站住需要回頭查測(cè)試和掃描配置如果開發(fā)周期在縮短、缺陷率又持平說(shuō)明方向是對(duì)的。建議指標(biāo)按周維度記錄連續(xù)跟蹤 6 周以上再看趨勢(shì)單周數(shù)據(jù)說(shuō)明不了問(wèn)題。還有一點(diǎn)要提醒不要把指標(biāo)搞得太復(fù)雜。我見過(guò)一個(gè)團(tuán)隊(duì)列了二十多項(xiàng)指標(biāo)最后根本沒(méi)人維護(hù)。真正有價(jià)值的指標(biāo)往往不超過(guò)五個(gè)關(guān)鍵是能回答“研發(fā)是否變快、質(zhì)量是否穩(wěn)住”這兩個(gè)基本問(wèn)題。6.3 團(tuán)隊(duì)技能轉(zhuǎn)型與流程再造AI Coding 之后角色分工一定會(huì)變。架構(gòu)師多了一個(gè)核心職責(zé)維護(hù)上下文資產(chǎn)包括領(lǐng)域詞典、模塊說(shuō)明、接口契約、示例代碼庫(kù)。這些資產(chǎn)的維護(hù)比寫架構(gòu)文檔更花時(shí)間但價(jià)值也更大因?yàn)槟Ｐ屯耆蕾囘@套資產(chǎn)來(lái)生成符合預(yù)期的代碼。開發(fā)者的工作重心從“寫代碼”變成“論證 AI 產(chǎn)出合理性”為什么這個(gè)生成方案是合理的、哪些邊界條件被忽略了、有沒(méi)有更好的拆法。評(píng)審人則要習(xí)慣看生成記錄、看生成前提。團(tuán)隊(duì)最好一起定一份簡(jiǎn)短的《AI 協(xié)作規(guī)范》明確哪些代碼可以讓 AI 直接生成、哪些必須人寫、生成時(shí)怎么留痕、哪些模塊禁止 Agent 直接操作。規(guī)范不用長(zhǎng)三五頁(yè)夠用核心是讓 AI 使用保持在可控范圍內(nèi)。我在一個(gè)團(tuán)隊(duì)里觀察到早期大家對(duì) AI 生成的代碼普遍持懷疑態(tài)度后來(lái)項(xiàng)目穩(wěn)了 3 個(gè)月部分開發(fā)者開始過(guò)度信任 AI提交越來(lái)越隨意。這種周期波動(dòng)很正常關(guān)鍵是在規(guī)范里寫清楚“人寫什么、AI 寫什么”的邊界并且評(píng)審人要堅(jiān)持這個(gè)邊界。人不需要對(duì)每行 AI 代碼負(fù)責(zé)但對(duì)生成前提和最終結(jié)果負(fù)責(zé)。我自己這幾年的體會(huì)是AI Coding 引入企業(yè)級(jí)架構(gòu)最耗時(shí)間的不是選模型而是把 AI 產(chǎn)出納入質(zhì)量體系的工程改造。早期我們花了很多時(shí)間比較參數(shù)后來(lái)才發(fā)現(xiàn)真正拉開差距的是模塊的領(lǐng)域說(shuō)明清不清楚、接口契約穩(wěn)不穩(wěn)定、測(cè)試能不能在十幾秒內(nèi)給出反饋。踩過(guò)幾次坑之后我現(xiàn)在的原則很固定先在邊界清晰的地方讓 AI 跑起來(lái)治理流程逐步跟上再慢慢擴(kuò)大應(yīng)用范圍。如果你的團(tuán)隊(duì)正準(zhǔn)備落地我建議把架構(gòu)設(shè)計(jì)的前置約束放在最高優(yōu)先級(jí)這個(gè)收益比換一個(gè)更大參數(shù)的模型實(shí)在得多。 AI Coding時(shí)代的企業(yè)級(jí)應(yīng)用架構(gòu)：從模塊邊界到工程治理的落地實(shí)踐
1. AI Coding 到底改變了企業(yè)架構(gòu)的什么AI Coding 這個(gè)詞這兩年已經(jīng)從技術(shù)圈的熱搜變成了很多企業(yè)技術(shù)規(guī)劃里的必選項(xiàng)。我最近接觸了幾個(gè)團(tuán)隊(duì)有做供應(yīng)鏈系統(tǒng)的有做內(nèi)部數(shù)據(jù)平臺(tái)的還有做金融交易輔助的幾乎都在問(wèn)同一個(gè)問(wèn)題AI 生成的代碼到底怎么落到企業(yè)級(jí)應(yīng)用架構(gòu)里才不會(huì)變成新的技術(shù)債工具選型其實(shí)只是個(gè)人效率層面的事真正決定這些工具能不能穩(wěn)定產(chǎn)出、安全上線的是架構(gòu)層面的調(diào)整。我自己有一個(gè)很明確的觀點(diǎn)AI Coding 時(shí)代的企業(yè)級(jí)應(yīng)用架構(gòu)核心不是把 AI 變成“寫代碼的人”而是把 AI 產(chǎn)出物當(dāng)成一個(gè)必須經(jīng)過(guò)校驗(yàn)、可以回滾、可以追溯的變更來(lái)源然后圍繞它重新排列研發(fā)流程和系統(tǒng)邊界。這個(gè)思路看起來(lái)抽象但它會(huì)具體影響模塊拆得多細(xì)、接口要怎么定義、CI 流水線卡在哪里、代碼評(píng)審重點(diǎn)看什么。下面從六個(gè)方面展開說(shuō)都是這大半年我在不同團(tuán)隊(duì)里反復(fù)驗(yàn)證過(guò)的做法也不全是成功經(jīng)驗(yàn)踩坑的部分更有參考價(jià)值。1.1 從“寫得慢”到“生成得慢”研發(fā)瓶頸其實(shí)轉(zhuǎn)移了在傳統(tǒng)研發(fā)里一個(gè)需求理解清楚之后瓶頸多半在編碼一行行寫、逐個(gè)方法調(diào)、反復(fù)編譯?，F(xiàn)在 AI 把這一環(huán)大幅提速團(tuán)隊(duì)的注意力反而開始卡在更早和更晚兩個(gè)位置——更早是需求上下文更晚是代碼評(píng)審。我見過(guò)一個(gè)實(shí)際例子三個(gè)開發(fā)者同時(shí)用 AI 生成一個(gè)新模塊一周產(chǎn)出了平時(shí)三倍多的 PR結(jié)果評(píng)審隊(duì)列直接積壓了兩周。代碼評(píng)審的人根本看不過(guò)來(lái)只能挑重點(diǎn)看最后上線的版本帶著兩個(gè)邊界條件錯(cuò)誤其中一個(gè)還是線上事故級(jí)別。問(wèn)題不在 AI而在系統(tǒng)設(shè)計(jì)時(shí)根本沒(méi)有預(yù)留“可評(píng)審性”模塊拆得太粗一個(gè) PR 動(dòng)輒上千行人沒(méi)法在有限注意力里發(fā)現(xiàn)陷阱。所以架構(gòu)設(shè)計(jì)的第一條新約束是讓模塊粒度匹配單次評(píng)審的容量。一個(gè)合理的顆粒度是單個(gè) PR 涉及 3 到 5 個(gè)文件改動(dòng) 200 行左右業(yè)務(wù)語(yǔ)義完整評(píng)審人可以一次看完并給出結(jié)論。這種粒度以前也提倡但現(xiàn)在不是“建議”而是“必須”。AI 生成代碼的速度遠(yuǎn)超人腦評(píng)審速度如果不做這一步后面所有效率收益都會(huì)在評(píng)審環(huán)節(jié)被抵消。這個(gè)約束還會(huì)反過(guò)來(lái)影響服務(wù)拆分的層級(jí)。以前我們可能習(xí)慣把多個(gè)相關(guān)領(lǐng)域放在一個(gè)大模塊里靠人可以記住全局現(xiàn)在 AI 一旦介入大模塊的上下文復(fù)雜度會(huì)直接失控。一個(gè)模塊的職責(zé)邊界越模糊AI 生成代碼時(shí)就越容易“自由發(fā)揮”產(chǎn)出的代碼和真實(shí)業(yè)務(wù)意圖的偏差就會(huì)越大。所以 AI Coding 落地之后DDD 這類領(lǐng)域建模方法的重要性反而更高了因?yàn)樗烊灰笪覀儼涯K邊界、領(lǐng)域術(shù)語(yǔ)、業(yè)務(wù)規(guī)則都顯式化。1.2 模塊邊界本質(zhì)上變成了模型的上下文邊界大模型的行為受上下文窗口限制這聽起來(lái)是個(gè)技術(shù)參數(shù)實(shí)際上直接改變了企業(yè)架構(gòu)的拆分邏輯。以前我們拆模塊主要依據(jù)業(yè)務(wù)領(lǐng)域、團(tuán)隊(duì)歸屬、部署單元現(xiàn)在還要多考慮一個(gè)問(wèn)題模型生成這段代碼時(shí)需要給它多少上下文這個(gè)上下文是否干凈。我接觸過(guò)的團(tuán)隊(duì)里做得好的會(huì)為每個(gè)模塊維護(hù)一個(gè)“上下文包”里面只放三類內(nèi)容。第一類是必須上下文包括接口簽名、領(lǐng)域核心實(shí)體、本模塊的編碼約束第二類是參考上下文包括相似歷史實(shí)現(xiàn)、內(nèi)部工具類第三類是輔助上下文比如設(shè)計(jì)文檔里的決策背景和約束說(shuō)明。其他內(nèi)容一律不進(jìn)包尤其是無(wú)關(guān)配置、其他模塊的細(xì)節(jié)以及已經(jīng)被廢棄的舊代碼。這里可以用個(gè)生活類比以前項(xiàng)目經(jīng)理把需求講給程序員程序員聽完可以存在腦子里長(zhǎng)期記憶容量大現(xiàn)在的模型更像一個(gè)“一次性臨時(shí)工”你交代了什么它就按什么做。如果交代的內(nèi)容里混進(jìn)一堆無(wú)關(guān)信息它很容易被帶偏。我甚至見過(guò)有人把一個(gè)跨五個(gè)模塊的系統(tǒng)說(shuō)明文檔整篇塞進(jìn) prompt結(jié)果模型生成的代碼里到處都是對(duì)別的模塊的臆想調(diào)用。問(wèn)題不在模型在喂給模型的上下文太亂。所以架構(gòu)層面要把“上下文資產(chǎn)管理”當(dāng)成正經(jīng)事模塊文檔要精簡(jiǎn)、接口要顯式、歷史設(shè)計(jì)決策要寫成一兩段話而不是藏在一萬(wàn)行代碼注釋里。理想狀態(tài)下一個(gè)模塊的上下文包應(yīng)該能在幾分鐘內(nèi)讀完并且能讓一個(gè)不熟悉該模塊的開發(fā)者快速理解邊界。模型和人在這里需求是一致的只是模型比人更不能容忍廢話。1.3 統(tǒng)一術(shù)語(yǔ)和命名別讓 AI 自由發(fā)揮AI 生成代碼時(shí)有一個(gè)容易被忽視的偏好它的命名風(fēng)格會(huì)強(qiáng)烈參考現(xiàn)有代碼。如果一個(gè)系統(tǒng)里“訂單號(hào)”有三種寫法模型在生成新邏輯時(shí)可能隨機(jī)參考其中一種長(zhǎng)此以往整個(gè)代碼庫(kù)的命名一致性會(huì)明顯惡化。解決這件事靠的不是模型而是架構(gòu)層的一份輕量領(lǐng)域詞典。核心實(shí)體、狀態(tài)枚舉、錯(cuò)誤碼、事件名都在這份詞典里固定下來(lái)。比如訂單狀態(tài)只能有創(chuàng)建、支付中、已支付、已取消、已關(guān)閉這幾個(gè)字面量模型生成的代碼里如果出現(xiàn)其他同義表達(dá)靜態(tài)分析工具直接卡住。這看起來(lái)是規(guī)范問(wèn)題但在 AI Coding 場(chǎng)景里是硬約束。我之所以強(qiáng)調(diào)這一點(diǎn)是因?yàn)槿丝创a時(shí)會(huì)自動(dòng)腦補(bǔ)看到 userInfo 和 userProfile 能猜到可能是同一個(gè)東西模型不會(huì)。它只會(huì)機(jī)械地推斷類名和字段名的對(duì)應(yīng)關(guān)系。如果詞典不統(tǒng)一AI 生成的新代碼和存量代碼之間會(huì)形成“語(yǔ)義斷層”后續(xù)維護(hù)成本是指數(shù)級(jí)上升的。實(shí)際操作上團(tuán)隊(duì)可以先花一兩個(gè)工作日做一版詞典初稿不用追求完整先把高頻出現(xiàn)的實(shí)體和狀態(tài)定死。然后把它維護(hù)成文檔同時(shí)在靜態(tài)掃描規(guī)則里加上命名校驗(yàn)。每次評(píng)審時(shí)如果發(fā)現(xiàn)命名和詞典不符不是讓開發(fā)者改名字而是先判斷是不是該把新詞加入詞典——這一步很關(guān)鍵否則詞典會(huì)變成新的官僚文檔。2. 技術(shù)選型不是模型越強(qiáng)越好而是場(chǎng)景對(duì)得上2.1 代碼資產(chǎn)安全等級(jí)決定部署模式先說(shuō)一個(gè)很多團(tuán)隊(duì)一開始不會(huì)考慮的問(wèn)題代碼本身是核心資產(chǎn)。一個(gè)跑了幾年的業(yè)務(wù)系統(tǒng)代碼里藏著業(yè)務(wù)規(guī)則、數(shù)據(jù)庫(kù)結(jié)構(gòu)、密鑰調(diào)用邏輯、第三方接口的鑒權(quán)方式。如果 AI 編程工具默認(rèn)把代碼片段發(fā)送到外部 API對(duì)很多企業(yè)來(lái)說(shuō)就已經(jīng)踩到了合規(guī)紅線。所以在選型前我習(xí)慣先畫一條數(shù)據(jù)邊界。按照代碼敏感度分成三類能進(jìn)公有模型的產(chǎn)品代碼、脫敏后才能進(jìn)的產(chǎn)品代碼、絕對(duì)不能進(jìn)模型的代碼。畫完這條線部署模式基本就定了。現(xiàn)在主流的做法有三種本地私有化部署、通過(guò)內(nèi)部網(wǎng)關(guān)調(diào)用外部模型 API、混合部署。它們各有適用場(chǎng)景。部署模式數(shù)據(jù)出境部署成本模型更新速度典型場(chǎng)景本地/私有化完全不出內(nèi)網(wǎng)高需算力資源慢依賴內(nèi)部迭代強(qiáng)合規(guī)行業(yè)、涉密項(xiàng)目企業(yè)API網(wǎng)關(guān)代理受控出境統(tǒng)一審計(jì)中等僅需網(wǎng)關(guān)快跟隨外部版本多數(shù)中大型企業(yè)混合模式按策略分流中高取決于配置大型集團(tuán)、多業(yè)務(wù)線我見過(guò)一家做內(nèi)部數(shù)據(jù)平臺(tái)的公司為了數(shù)據(jù)安全選了本地私有化小模型。模型能力確實(shí)不如公有大模型但團(tuán)隊(duì)把上下文包做得非常精細(xì)生成質(zhì)量反而比之前用公有 API 時(shí)更穩(wěn)。原因很簡(jiǎn)單上下文質(zhì)量彌補(bǔ)了模型參數(shù)差距。在真實(shí)企業(yè)場(chǎng)景里數(shù)據(jù)可達(dá)性和模型上限同等重要甚至數(shù)據(jù)可控性更優(yōu)先。這里還要強(qiáng)調(diào)團(tuán)隊(duì)里如果有人把公司代碼片段貼到公有 AI 工具里無(wú)論選型做了什么都不算真正安全。所以要配合技術(shù)手段在網(wǎng)關(guān)上做檢測(cè)同時(shí)把數(shù)據(jù)安全要求寫進(jìn)研發(fā)守則。制度和技術(shù)兩條腿一起走才是最穩(wěn)的落地方式。2.2 能力分級(jí)補(bǔ)全、生成、重構(gòu)、Agent 各有邊界AI 編程能力不是一個(gè)開關(guān)而是分為四個(gè)層級(jí)補(bǔ)全、生成、重構(gòu)、Agent。每個(gè)層級(jí)的復(fù)雜度不同會(huì)影響多少個(gè)文件、能不能自動(dòng)執(zhí)行多個(gè)步驟所以對(duì)應(yīng)的風(fēng)險(xiǎn)等級(jí)也不一樣接入方式必須分開對(duì)待。補(bǔ)全是最輕的能力適合 IDE 里的單行和小塊代碼延遲要低上下文只需要看當(dāng)前文件。函數(shù)和文件生成需要完整模塊上下文模型要理解接口簽名、業(yè)務(wù)規(guī)則、依賴關(guān)系適合新模塊的骨架開發(fā)。跨文件重構(gòu)風(fēng)險(xiǎn)明顯更高會(huì)同時(shí)改動(dòng)多個(gè)文件必須有完整測(cè)試和人工評(píng)審兜底。Agent 模式則會(huì)讓模型自主規(guī)劃多步任務(wù)、調(diào)用工具、修改多處代碼這種自由度放到核心業(yè)務(wù)鏈路上非常危險(xiǎn)。我見過(guò)一個(gè)團(tuán)隊(duì)讓 Agent 直接處理訂單狀態(tài)遷移模型按照自己的理解把狀態(tài)機(jī)改了上線當(dāng)天就出了訂單卡單。后來(lái)他們立了一條規(guī)矩Agent 只能跑在不會(huì)直接產(chǎn)生業(yè)務(wù)寫入的環(huán)節(jié)比如生成報(bào)表查詢、批量制造測(cè)試數(shù)據(jù)、整理運(yùn)維腳本核心狀態(tài)機(jī)必須由人寫AI 最多補(bǔ)輔助方法。這條規(guī)矩我建議每個(gè)準(zhǔn)備引入 Agent 的團(tuán)隊(duì)都照抄。還有一種常見誤區(qū)是把所有場(chǎng)景都接到最強(qiáng)模型上。實(shí)際做下來(lái)補(bǔ)全場(chǎng)景用輕量模型就夠了響應(yīng)還更快跨文件重構(gòu)反而需要更強(qiáng)的模型和更大的上下文。選型的時(shí)候按場(chǎng)景分級(jí)不要一刀切。分級(jí)之后還要給每個(gè)層級(jí)配置不同的發(fā)布門檻補(bǔ)全直接體驗(yàn)生成走普通 PR 流程Agent 必須套沙箱和完整評(píng)審。2.3 把AI能力做成可插拔的基礎(chǔ)層企業(yè)里用 AI 不應(yīng)該是一個(gè)個(gè)開發(fā)者各接各的。更合理的做法是在平臺(tái)層做一個(gè)統(tǒng)一入口把鑒權(quán)、模型路由、指令模板、日志審計(jì)都收進(jìn)去。我習(xí)慣叫它“AI 編碼網(wǎng)關(guān)”IDE 插件、命令行、CI 流水線都連這個(gè)網(wǎng)關(guān)底層模型只是可替換的供應(yīng)商實(shí)現(xiàn)。這樣做的好處非?，F(xiàn)實(shí)。第一換模型時(shí)不改業(yè)務(wù)代碼只需在網(wǎng)關(guān)層改路由配置第二可以同時(shí)對(duì)兩個(gè)模型做 A/B 對(duì)比看誰(shuí)的產(chǎn)出更穩(wěn)定第三所有生成記錄統(tǒng)一留痕責(zé)任可追溯。這和企業(yè)架構(gòu)里服務(wù)通過(guò)接口依賴數(shù)據(jù)庫(kù)、通過(guò)消息隊(duì)列解耦上下游是一個(gè)道理都是讓使用方依賴抽象不依賴具體實(shí)現(xiàn)。網(wǎng)關(guān)的復(fù)雜度也要控制。不需要一開始就搞成一個(gè)大平臺(tái)重點(diǎn)做三件事統(tǒng)一入口、統(tǒng)一審計(jì)、統(tǒng)一策略。先把門面立住后面再逐步加模型灰度、成本統(tǒng)計(jì)、質(zhì)量報(bào)表這些能力。如果一開始就把網(wǎng)關(guān)做得太重反而會(huì)拖慢 AI Coding 的落地節(jié)奏。我建議網(wǎng)關(guān)至少要記錄四類信息調(diào)用者、模型版本、上下文包的標(biāo)識(shí)、生成時(shí)間。這些信息往后會(huì)變成審計(jì)和排障的基礎(chǔ)。沒(méi)有這套記錄AI 真的在線上出了事故你根本說(shuō)不清這段代碼是怎么來(lái)的。3. 可驗(yàn)證性與可回滾性架構(gòu)設(shè)計(jì)的新約束3.1 測(cè)試先行從最佳實(shí)踐變成必要條件AI 生成的代碼是否可靠很大程度上取決于有沒(méi)有明確的行為邊界。行為邊界最好的表達(dá)就是測(cè)試。我見過(guò)最有效的流程是寫需求時(shí)直接把關(guān)鍵業(yè)務(wù)規(guī)則轉(zhuǎn)成契約測(cè)試先讓測(cè)試跑掛再把測(cè)試交給 AI讓它去實(shí)現(xiàn)。這個(gè)流程看起來(lái)多了一步測(cè)試前置實(shí)際總耗時(shí)反而更短因?yàn)?AI 不用反復(fù)試探需求。比如一個(gè)查詢接口先定義好輸入?yún)?shù)、預(yù)期返回、異常碼再寫正常路徑、邊界值、非法入?yún)⒌臏y(cè)試用例AI 要做的就是把這些用例全部跑綠。測(cè)試一旦先立住模型怎么發(fā)揮都不會(huì)跑偏。這里有個(gè)特別要注意的細(xì)節(jié)契約測(cè)試不要跟 AI 生成代碼放同一個(gè)提交。如果測(cè)試和實(shí)現(xiàn)一起放上去AI 容易“反向編寫”測(cè)試讓測(cè)試適應(yīng)自己代碼的行為那就等于自我打分失去了校驗(yàn)意義。正確做法是測(cè)試先合入主干并標(biāo)記為失敗或跳過(guò)AI 實(shí)現(xiàn)代碼再在另一個(gè)提交里把它修到綠。我在實(shí)際項(xiàng)目里看到過(guò)很多次“單測(cè)全綠但業(yè)務(wù)完全不對(duì)”的情況。因?yàn)槟Ｐ秃苌瞄L(zhǎng)從測(cè)試代碼里推斷出實(shí)現(xiàn)的形狀但無(wú)法理解真實(shí)業(yè)務(wù)的前因后果。所以測(cè)試先行不只是流程控制更是把業(yè)務(wù)知識(shí)固化下來(lái)讓 AI 在有限范圍內(nèi)自主發(fā)揮。3.2 把不可變部分寫進(jìn)代碼約束企業(yè)級(jí)系統(tǒng)里有很多東西不應(yīng)該由 AI 自由決定對(duì)外 API 的簽名、數(shù)據(jù)庫(kù)字段、消息 Topic、錯(cuò)誤碼、權(quán)限模型。架構(gòu)設(shè)計(jì)的任務(wù)是把這些部分用強(qiáng)類型方式固定下來(lái)AI 只能填空不能改框架。這個(gè)思路可以用高速公路的護(hù)欄來(lái)類比好的司機(jī)正常不會(huì)沖出路面但護(hù)欄的意義在于即使操作失誤也不會(huì)造成災(zāi)難。AI 的推理是概率性的再好的模型也可能在上下文不完整時(shí)突發(fā)奇想。如果接口定義文件里聲明訂單金額是強(qiáng)類型小數(shù)模型生成的代碼就不能偷偷換成浮點(diǎn)數(shù)如果數(shù)據(jù)庫(kù)遷移腳本鎖定了表結(jié)構(gòu)模型生成的變更語(yǔ)句就必須經(jīng)過(guò)獨(dú)立評(píng)審。實(shí)際落地上要配合工具鏈嚴(yán)格的類型檢查在編譯期攔接口變更檢查在 CI 攔數(shù)據(jù)庫(kù)變更必須走獨(dú)立流程。這些約束不需要靠抽查而是直接寫進(jìn)自動(dòng)化門禁。我在一個(gè)項(xiàng)目里甚至要求核心模塊引入任何新依賴都需要單獨(dú)審批這一條就把 AI 生成代碼時(shí)胡亂加依賴的風(fēng)險(xiǎn)擋掉大半。還有一類不可變部分容易被忽略團(tuán)隊(duì)內(nèi)部的基礎(chǔ)約定比如統(tǒng)一錯(cuò)誤碼格式、統(tǒng)一日志格式、統(tǒng)一異步消息版本策略。這類約定不寫在代碼里而是寫成“模塊編碼指南”并且作為上下文包的一部分喂給模型。模型生成時(shí)會(huì)更傾向于遵守這些約定偏離的機(jī)會(huì)大大減少。3.3 生成記錄與回滾能力AI 生成的代碼最大的治理問(wèn)題是“來(lái)路不明”。人工寫的代碼寫的人知道自己當(dāng)時(shí)為什么這么寫模型生成的代碼如果不記錄輸入上下文三個(gè)月后沒(méi)人能說(shuō)清這段代碼為什么長(zhǎng)成這樣。所以在工程規(guī)范里建議 AI 輔助的提交都帶上結(jié)構(gòu)化信息模型標(biāo)識(shí)和版本、上下文包 ID、人工改動(dòng)摘要、相關(guān)評(píng)審單號(hào)。CI 可以根據(jù)這些字段把提交標(biāo)記為“AI 輔助”對(duì)這類提交跑更嚴(yán)格的質(zhì)量門。以后要回滾時(shí)能快速定位“哪個(gè)生成版本加人工修復(fù)點(diǎn)”是最后一個(gè)穩(wěn)定組合。我在實(shí)際項(xiàng)目里還會(huì)定期導(dǎo)出生成記錄報(bào)表看哪些模塊 AI 介入最多、哪些模塊生成后被改得最頻繁。被改得頻繁的模塊通常說(shuō)明上下文沒(méi)描述清楚或者接口設(shè)計(jì)不合理這些信號(hào)比任何指標(biāo)都更能暴露架構(gòu)缺陷?；貪L能力同樣要考慮版本管理。模型版本升級(jí)后同一段 prompt 生成的結(jié)果可能完全不同這會(huì)導(dǎo)致“生成版本漂移”。所以上下文包里最好記錄實(shí)用的模型版本和參數(shù)線上要回滾時(shí)能精確還原當(dāng)時(shí)的生成條件。這件事看起來(lái)繁瑣但在出事故時(shí)就是救命的稻草。4. 工程鏈路改造CI/CD 如何接住 AI 產(chǎn)出4.1 評(píng)審流程升級(jí)從看 diff 到看生成前提傳統(tǒng)代碼評(píng)審看的是 diff問(wèn)的是“改了什么”AI 生成的代碼評(píng)審更該問(wèn)的是“為什么這么寫”。原因很簡(jiǎn)單模型不會(huì)告訴你它為什么選擇這個(gè)實(shí)現(xiàn)如果你不給它前置信息評(píng)審人只能對(duì)著代碼猜。所以 PR 模板要增加 AI 描述字段。建議至少包含這次生成用了什么上下文、目標(biāo)是什么、模型版本是什么、人工做了哪幾處調(diào)整。評(píng)審人的關(guān)注點(diǎn)也要調(diào)整不用再盯每個(gè)縮進(jìn)和變量命名重點(diǎn)放在業(yè)務(wù)邊界、異常路徑、事務(wù)邊界、外部依賴調(diào)用這四個(gè)地方。我整理了一份用于 AI 生成代碼的評(píng)審檢查清單團(tuán)隊(duì)可以直接用輸入校驗(yàn)空值、超長(zhǎng)、非法枚舉有沒(méi)有漏事務(wù)邊界多表寫入是否在一個(gè)事務(wù)里回滾邏輯是否完整外部調(diào)用超時(shí)和重試設(shè)了沒(méi)有是否走統(tǒng)一出口日志與返回有沒(méi)有打印敏感字段異常信息是否泄露內(nèi)部結(jié)構(gòu)依賴變化新增依賴是否在白名單內(nèi)版本是否鎖定檢查清單要固化到評(píng)審流程里不能靠口頭強(qiáng)調(diào)。AI 產(chǎn)出量大之后口頭的提醒很快就會(huì)被淹沒(méi)。我在一個(gè)團(tuán)隊(duì)里看到他們把這份清單做成了瀏覽器插件評(píng)審 PR 時(shí)逐項(xiàng)打勾效果比任何培訓(xùn)都明顯。4.2 測(cè)試策略契約測(cè)試和模糊測(cè)試的權(quán)重提上來(lái)常規(guī)開發(fā)里我們用單元測(cè)試覆蓋業(yè)務(wù)邏輯。AI 生成代碼后單測(cè)當(dāng)然還要但它解決不了“模型誤解業(yè)務(wù)規(guī)則”的問(wèn)題。這時(shí)候要引入兩個(gè)補(bǔ)充契約測(cè)試和模糊測(cè)試。契約測(cè)試固定模塊之間的接口行為。比如 A 模塊調(diào)用 B 模塊的服務(wù)先把兩邊的請(qǐng)求響應(yīng)結(jié)構(gòu)用契約定死AI 重構(gòu)其中任何一邊時(shí)如果悄悄改變了行為測(cè)試會(huì)立刻報(bào)警。模糊測(cè)試則是隨機(jī)生成邊界輸入抓 AI 代碼里沒(méi)考慮到的邊界條件。我印象很深的一次事故是一個(gè)內(nèi)部 API 被 AI 重構(gòu)后單測(cè)全綠但把入?yún)恼龜?shù)改成負(fù)數(shù)時(shí)服務(wù)直接拋出了數(shù)據(jù)庫(kù)層的原生異常。原因就是沒(méi)有模糊測(cè)試模型實(shí)現(xiàn)簡(jiǎn)單假設(shè)了所有參數(shù)都是合法的。從那以后CI 里增加了隨機(jī)邊界測(cè)試這類問(wèn)題少了很多。AI 寫單測(cè)確實(shí)很快但關(guān)鍵模塊我更傾向于人工先寫核心 caseAI 補(bǔ)外圍用例。因?yàn)榧冏?AI 寫測(cè)試它容易陷入“路徑依賴”只會(huì)圍繞自己生成的實(shí)現(xiàn)找覆蓋路徑根本不會(huì)去質(zhì)疑實(shí)現(xiàn)的邏輯本身。變異測(cè)試的思路在這里可以參考把一個(gè)條件判斷改掉測(cè)試如果沒(méi)失敗說(shuō)明這個(gè)用例根本沒(méi)校驗(yàn)到關(guān)鍵邏輯。這種查漏方法單靠 AI 是出不來(lái)的。4.3 質(zhì)量門用自動(dòng)化卡點(diǎn)替代人肉把關(guān)AI 產(chǎn)出的量一旦上來(lái)靠人評(píng)審根本不現(xiàn)實(shí)。CI 流水線必須加入自動(dòng)質(zhì)量門把常規(guī)問(wèn)題在提交時(shí)攔下來(lái)。重點(diǎn)卡幾個(gè)位置靜態(tài)代碼掃描、安全掃描、依賴白名單、覆蓋率閾值、構(gòu)建耗時(shí)上限。我常用的閾值配置如下團(tuán)隊(duì)可以按實(shí)際情況調(diào)整質(zhì)量門建議閾值高危安全漏洞0新增代碼單元測(cè)試覆蓋率≥ 80%單次構(gòu)建時(shí)長(zhǎng)上限10 至 15 分鐘未審批依賴0關(guān)鍵模塊評(píng)審人必須指定質(zhì)量門失敗時(shí)AI 提交自動(dòng)進(jìn)草稿狀態(tài)不阻塞低風(fēng)險(xiǎn)的人工改動(dòng)這樣可以減少流程摩擦。關(guān)鍵點(diǎn)是 AI 產(chǎn)出和人工產(chǎn)出在進(jìn)入主干前要用同一套標(biāo)準(zhǔn)否則 AI 帶來(lái)的效率提升最后會(huì)變成技術(shù)債和線上事故。還有一個(gè)小細(xì)節(jié)質(zhì)量門不能只在主干分支跑每個(gè) PR 分支都要跑。否則 AI 生成的代碼在分支里看著沒(méi)問(wèn)題合并以后和主干其他改動(dòng)疊加問(wèn)題才暴露出來(lái)那時(shí)候排查成本就成倍增加了。5. 治理與安全企業(yè)級(jí)繞不開的三道坎5.1 AI 產(chǎn)出里的漏洞基因大模型的訓(xùn)練數(shù)據(jù)來(lái)自海量開源代碼這些代碼里有大量歷史漏洞模式。模型不會(huì)主動(dòng)判斷“這段代碼是否安全”它只是按照概率分布補(bǔ)全最可能的內(nèi)容。因此 AI 生成的代碼天然可能攜帶 SQL 注入、跨站腳本、敏感信息硬編碼、危險(xiǎn)反序列化這類問(wèn)題。企業(yè)級(jí)的應(yīng)對(duì)不是禁用 AI而是把安全掃描前置。很多團(tuán)隊(duì)等到代碼推到 CI 才做安全掃描AI 產(chǎn)出量一大排隊(duì)和等待時(shí)間就會(huì)拖垮流程。更好的做法是讓掃描跑在開發(fā)者本地提交前一個(gè)輕量的快速掃描卡高危問(wèn)題直接阻斷CI 再跑深度掃描。安全掃描的規(guī)則也要基于業(yè)務(wù)定制。比如內(nèi)部系統(tǒng)重點(diǎn)查越權(quán)訪問(wèn)和敏感數(shù)據(jù)泄露交易系統(tǒng)重點(diǎn)查金額計(jì)算和并發(fā)更新。我這里說(shuō)的不是安全團(tuán)隊(duì)單方面定規(guī)則而是讓一線研發(fā)把常見問(wèn)題反饋給安全團(tuán)隊(duì)雙方一起維護(hù)規(guī)則集這樣掃描規(guī)則才會(huì)越來(lái)越貼合真實(shí)場(chǎng)景。5.2 上下文與敏感數(shù)據(jù)邊界模型生成質(zhì)量取決于上下文但不能為了質(zhì)量把敏感數(shù)據(jù)無(wú)差別喂給模型。企業(yè)內(nèi)部至少要有一個(gè)簡(jiǎn)單的分級(jí)可以進(jìn)入上下文接口簽名、領(lǐng)域?qū)嶓w、公開設(shè)計(jì)文檔脫敏后可以進(jìn)入帶示例數(shù)據(jù)的表結(jié)構(gòu)、日志樣例、非生產(chǎn) SQL禁止進(jìn)入密鑰、真實(shí)用戶數(shù)據(jù)、生產(chǎn)環(huán)境數(shù)據(jù)架構(gòu)層圍繞這個(gè)分級(jí)做兩件事。一是在 IDE 插件和網(wǎng)關(guān)上做敏感信息掃描發(fā)現(xiàn)密鑰、身份證號(hào)、手機(jī)號(hào)等模式就打碼并記錄二是保留審計(jì)日志記錄什么時(shí)間段、誰(shuí)、用什么上下文喂給了什么模型。數(shù)據(jù)合規(guī)部門來(lái)查的時(shí)候可以直接拿出證據(jù)鏈。我見過(guò)一個(gè)比較創(chuàng)新的做法給不同敏感等級(jí)的代碼準(zhǔn)備不同的“示例環(huán)境”。比如讓模型看表結(jié)構(gòu)時(shí)表結(jié)構(gòu)里的用戶名字段被替換成“測(cè)試用戶張三”金額字段被替換成“1000.00”。這樣模型可以理解語(yǔ)義但接觸不到真實(shí)數(shù)據(jù)模式。這個(gè)思路在內(nèi)部合規(guī)要求比較嚴(yán)的團(tuán)隊(duì)里很實(shí)用。5.3 許可證與供應(yīng)鏈污染AI 的“原創(chuàng)”有時(shí)候其實(shí)是記憶拼接。模型可能生成一段和某開源項(xiàng)目高度相似的代碼帶來(lái)許可證層面的風(fēng)險(xiǎn)。這個(gè)風(fēng)險(xiǎn)在傳統(tǒng)人工開發(fā)里是偶發(fā)的但在 AI 生成模式下變成了默認(rèn)場(chǎng)景所以供應(yīng)鏈檢查必須常駐。做法是把軟件成分分析加進(jìn)發(fā)布流水線持續(xù)生成依賴清單和 SBOM并維護(hù)許可證白名單。常見的寬松許可證可以直接進(jìn)白名單傳染性強(qiáng)的許可證需要單獨(dú)審批。團(tuán)隊(duì)內(nèi)部也要在 AI 協(xié)作規(guī)范里寫清楚AI 生成代碼不等于無(wú)版權(quán)代碼上生產(chǎn)前要過(guò)成分分析。這件事很多人覺得麻煩但真出了合規(guī)問(wèn)題再回頭補(bǔ)成本高得多。另外還要關(guān)注基礎(chǔ)設(shè)施層面的供應(yīng)鏈風(fēng)險(xiǎn)。AI 生成的代碼可能自己引入新的依賴這些依賴如果不鎖定版本下次構(gòu)建時(shí)可能悄然拉取到有漏洞的新版本。所以在依賴鎖定的基礎(chǔ)上每次發(fā)布前最好都重新跑一遍依賴掃描而不是只在首次引入時(shí)掃描一次。6. 落地路徑從試點(diǎn)到全量推廣6.1 試點(diǎn)項(xiàng)目怎么選不要一上來(lái)就選核心交易系統(tǒng)做 AI 全量試點(diǎn)。我建議從三類項(xiàng)目里挑內(nèi)部管理工具、報(bào)表查詢系統(tǒng)、非核心 CRUD 服務(wù)。選擇標(biāo)準(zhǔn)就三條模塊邊界清楚、測(cè)試覆蓋有一定基礎(chǔ)、團(tuán)隊(duì)愿意接受評(píng)審規(guī)則改變。另一個(gè)穩(wěn)妥的做法是選一個(gè)中等復(fù)雜度的服務(wù)先用 AI 做新增模塊而不是改造老模塊。老模塊里的潛規(guī)則太多模型很難通過(guò)上下文完全理解新模塊沒(méi)有歷史包袱約束可以從第一天就立住。試點(diǎn)周期控制在 4 到 6 周結(jié)束后做一次系統(tǒng)性指標(biāo)對(duì)比再?zèng)Q定是否擴(kuò)大范圍。選錯(cuò)試點(diǎn)項(xiàng)目會(huì)在第一周就被線上問(wèn)題打擊到團(tuán)隊(duì)信心后面再推廣就難了。我甚至見過(guò)一個(gè)團(tuán)隊(duì)在核心支付服務(wù)上試點(diǎn) Agent結(jié)果第三天就回滾整個(gè)公司對(duì) AI Coding 的態(tài)度從此變得極度保守。后來(lái)?yè)Q了報(bào)表系統(tǒng)試點(diǎn)效果不錯(cuò)但前期的信任損傷很難完全挽回。6.2 度量指標(biāo)別拿代碼行數(shù)證明自己快最容易踩的坑是拿“AI 生成代碼行數(shù)和占比”證明成果。這個(gè)指標(biāo)會(huì)誘導(dǎo)團(tuán)隊(duì)為了好看而批量制造重復(fù)代碼反而增加維護(hù)成本。更值得看的是研發(fā)交付鏈路本身需求到上線的周期、平均 PR 評(píng)審耗時(shí)、缺陷逃逸率、自動(dòng)化測(cè)試通過(guò)率、線上事故數(shù)。指標(biāo)類型具體指標(biāo)觀察方式效率類需求到上線周期、人均交付需求數(shù)按周記錄趨勢(shì)質(zhì)量類缺陷逃逸率、線上事故數(shù)、測(cè)試覆蓋率變化對(duì)比引入前后 6 周體驗(yàn)類開發(fā)者滿意度、評(píng)審隊(duì)列積壓數(shù)月度回訪舉個(gè)例子如果引入 AI 之后 PR 數(shù)量暴增但需求上線周期沒(méi)有縮短說(shuō)明流程沒(méi)有接住 AI評(píng)審變成新瓶頸如果缺陷逃逸率在上升說(shuō)明質(zhì)量門沒(méi)站住需要回頭查測(cè)試和掃描配置如果開發(fā)周期在縮短、缺陷率又持平說(shuō)明方向是對(duì)的。建議指標(biāo)按周維度記錄連續(xù)跟蹤 6 周以上再看趨勢(shì)單周數(shù)據(jù)說(shuō)明不了問(wèn)題。還有一點(diǎn)要提醒不要把指標(biāo)搞得太復(fù)雜。我見過(guò)一個(gè)團(tuán)隊(duì)列了二十多項(xiàng)指標(biāo)最后根本沒(méi)人維護(hù)。真正有價(jià)值的指標(biāo)往往不超過(guò)五個(gè)關(guān)鍵是能回答“研發(fā)是否變快、質(zhì)量是否穩(wěn)住”這兩個(gè)基本問(wèn)題。6.3 團(tuán)隊(duì)技能轉(zhuǎn)型與流程再造AI Coding 之后角色分工一定會(huì)變。架構(gòu)師多了一個(gè)核心職責(zé)維護(hù)上下文資產(chǎn)包括領(lǐng)域詞典、模塊說(shuō)明、接口契約、示例代碼庫(kù)。這些資產(chǎn)的維護(hù)比寫架構(gòu)文檔更花時(shí)間但價(jià)值也更大因?yàn)槟Ｐ屯耆蕾囘@套資產(chǎn)來(lái)生成符合預(yù)期的代碼。開發(fā)者的工作重心從“寫代碼”變成“論證 AI 產(chǎn)出合理性”為什么這個(gè)生成方案是合理的、哪些邊界條件被忽略了、有沒(méi)有更好的拆法。評(píng)審人則要習(xí)慣看生成記錄、看生成前提。團(tuán)隊(duì)最好一起定一份簡(jiǎn)短的《AI 協(xié)作規(guī)范》明確哪些代碼可以讓 AI 直接生成、哪些必須人寫、生成時(shí)怎么留痕、哪些模塊禁止 Agent 直接操作。規(guī)范不用長(zhǎng)三五頁(yè)夠用核心是讓 AI 使用保持在可控范圍內(nèi)。我在一個(gè)團(tuán)隊(duì)里觀察到早期大家對(duì) AI 生成的代碼普遍持懷疑態(tài)度后來(lái)項(xiàng)目穩(wěn)了 3 個(gè)月部分開發(fā)者開始過(guò)度信任 AI提交越來(lái)越隨意。這種周期波動(dòng)很正常關(guān)鍵是在規(guī)范里寫清楚“人寫什么、AI 寫什么”的邊界并且評(píng)審人要堅(jiān)持這個(gè)邊界。人不需要對(duì)每行 AI 代碼負(fù)責(zé)但對(duì)生成前提和最終結(jié)果負(fù)責(zé)。我自己這幾年的體會(huì)是AI Coding 引入企業(yè)級(jí)架構(gòu)最耗時(shí)間的不是選模型而是把 AI 產(chǎn)出納入質(zhì)量體系的工程改造。早期我們花了很多時(shí)間比較參數(shù)后來(lái)才發(fā)現(xiàn)真正拉開差距的是模塊的領(lǐng)域說(shuō)明清不清楚、接口契約穩(wěn)不穩(wěn)定、測(cè)試能不能在十幾秒內(nèi)給出反饋。踩過(guò)幾次坑之后我現(xiàn)在的原則很固定先在邊界清晰的地方讓 AI 跑起來(lái)治理流程逐步跟上再慢慢擴(kuò)大應(yīng)用范圍。如果你的團(tuán)隊(duì)正準(zhǔn)備落地我建議把架構(gòu)設(shè)計(jì)的前置約束放在最高優(yōu)先級(jí)這個(gè)收益比換一個(gè)更大參數(shù)的模型實(shí)在得多。