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