過去半年我大部分精力都花在推動企業(yè)內(nèi)部的AI能力建設(shè)上。其中最核心的兩件事一是把散落在各個團(tuán)隊手里的大模型接入收斂到一個統(tǒng)一的“大模型網(wǎng)關(guān)”二是把“自動化編程”從少數(shù)人的玩具變成研發(fā)流程里的常規(guī)環(huán)節(jié)。整個過程沒有想象中那么科幻反而充滿了配置表格、評審流程和成本賬單。這篇文章就是我對這段實踐的一次系統(tǒng)梳理不講虛的只講從基礎(chǔ)到落地模型網(wǎng)關(guān)怎么搭、自動化編程怎么用、中間會遇到哪些坑以及我最后堅持下來的幾個原則。1. 為什么企業(yè)需要一個“大模型網(wǎng)關(guān)”而不是多套API直接對接1.1 碎片化接入帶來的失控先描述一個很典型的場景。公司里銷售部想用大模型寫營銷文案研發(fā)部想用大模型做代碼解釋數(shù)據(jù)團(tuán)隊又想用大模型處理報表。大家各自去注冊平臺賬號各自申請API密鑰然后把密鑰直接寫在腳本里、寫在內(nèi)部系統(tǒng)配置里、甚至寫在聊天群里互相轉(zhuǎn)發(fā)。這種模式在只有兩三個人的實驗階段沒問題一旦團(tuán)隊規(guī)模上來麻煩立刻出現(xiàn)。密鑰泄露了沒法統(tǒng)一輪換同一個需求可能在不同的地方被重復(fù)調(diào)用每個月賬單出來都不知道錢花在哪每個業(yè)務(wù)方對模型能力的理解不一樣選的模型參差不齊效果反饋也亂七八糟。我接手的時候公司里光是不同團(tuán)隊申請的模型平臺賬號就有十個以上密鑰在代碼倉庫里搜一遍都能查出好幾個硬編碼。這個狀態(tài)如果不去治理后面不管上什么AI應(yīng)用都等同于在流沙上蓋房子。所以第一件事就是決定做一個統(tǒng)一的入口把所有對大模型能力的訪問收攏起來這個入口就是大模型網(wǎng)關(guān)。1.2 網(wǎng)關(guān)解決的四件大事大模型網(wǎng)關(guān)本質(zhì)上是一個介于業(yè)務(wù)系統(tǒng)和大模型服務(wù)之間的中間層。你可以把它理解成微服務(wù)架構(gòu)里的API網(wǎng)關(guān)只不過它轉(zhuǎn)發(fā)的是對大模型的請求。它解決的是企業(yè)應(yīng)用大模型時的四件大事統(tǒng)一接入、統(tǒng)一治理、統(tǒng)一觀測、統(tǒng)一安全。統(tǒng)一接入的意思是說業(yè)務(wù)方不再需要自己對接各種不同渠道的模型服務(wù)只要調(diào)用網(wǎng)關(guān)提供的統(tǒng)一接口就行。網(wǎng)關(guān)背后接的是哪個模型、哪個版本對業(yè)務(wù)方透明。好處是模型升級、切換、新增能力都不需要業(yè)務(wù)方改代碼只要在網(wǎng)關(guān)里調(diào)整配置。統(tǒng)一治理是核心價值。沒有網(wǎng)關(guān)的時候每個調(diào)用方的調(diào)用頻率、配額、權(quán)限都是各自為政。有了網(wǎng)關(guān)之后所有請求集中經(jīng)過可以讓管理員統(tǒng)一配置每個業(yè)務(wù)方的訪問權(quán)限、每分鐘調(diào)用上限、每個月的Token額度。這樣一來預(yù)算控制、異常流量攔截、敏感數(shù)據(jù)過濾都有了落點。統(tǒng)一觀測和統(tǒng)一安全其實是基礎(chǔ)能力但對企業(yè)來說特別關(guān)鍵。每一次經(jīng)過網(wǎng)關(guān)的請求都能記錄下是哪個部門、哪個應(yīng)用、用了什么模型、花費了多少Token、耗時多久。這些數(shù)據(jù)匯總之后就是一張非常清晰的企業(yè)AI成本看板。安全層面則可以做敏感信息脫敏、數(shù)據(jù)出境校驗、密鑰集中托管這類動作。1.3 判斷你的企業(yè)是否需要網(wǎng)關(guān)不是所有企業(yè)都需要大模型網(wǎng)關(guān)。如果公司只有三五個人做實驗每個月調(diào)用成本幾百塊那直接用一個平臺的API就夠了。但當(dāng)出現(xiàn)下面幾個信號的時候網(wǎng)關(guān)基本就是剛需了接入方超過三個團(tuán)隊或部門、使用超過兩家以上的模型供應(yīng)商、每個月API調(diào)用成本上了一定規(guī)模、有敏感數(shù)據(jù)經(jīng)過模型調(diào)用需要留痕審計。我見過一些企業(yè)跳過網(wǎng)關(guān)階段直接買了一堆AI平臺的企業(yè)版賬號結(jié)果成本翻了好幾倍問題一個都沒少。也有企業(yè)一上來就追求特別重型的網(wǎng)關(guān)方案結(jié)果部署了三個月還在調(diào)配置業(yè)務(wù)方早就不耐煩了。網(wǎng)關(guān)的引入節(jié)奏應(yīng)該跟著問題走出現(xiàn)管理問題再上不要為了趕時髦而上。2. 大模型網(wǎng)關(guān)能力拆解路由、流控、安全、觀測四位一體2.1 模型路由是網(wǎng)關(guān)的靈魂大模型網(wǎng)關(guān)最核心的功能是模型路由。所謂路由就是在收到業(yè)務(wù)方的請求之后按規(guī)則決定把這個請求轉(zhuǎn)發(fā)給背后的哪個模型服務(wù)。為什么要做這個因為不同模型的能力特色不同成本差異也很大。比如處理客服場景需要較強(qiáng)的對話理解能力這時候可以路由到能力更全面的高端模型而做文本摘要、關(guān)鍵詞提取這類相對簡單的任務(wù)完全可以用便宜很多的輕量模型。如果高成本模型服務(wù)臨時不可用還能降級到次選模型保證業(yè)務(wù)不中斷。我在落地的時候習(xí)慣把路由規(guī)則設(shè)計成兩層。第一層是業(yè)務(wù)策略層比如某個業(yè)務(wù)方固定用某一家供應(yīng)商第二層是請求特征層比如根據(jù)請求里攜帶的任務(wù)類型標(biāo)簽來決定模型選擇。這樣設(shè)計的好處是容易維護(hù)業(yè)務(wù)方要換模型只需要改標(biāo)簽不需要改代碼。2.2 限流與配額預(yù)算不能被一個腳本打穿大模型API的成本和數(shù)據(jù)庫不一樣一個死循環(huán)腳本就可以在幾十分鐘內(nèi)燒掉幾百上千的費用。網(wǎng)關(guān)上的限流和配額管理本質(zhì)上是在技術(shù)和成本之間加了一個強(qiáng)制保險絲。限流的經(jīng)典做法是令牌桶算法。網(wǎng)關(guān)維護(hù)一個桶桶里裝著令牌每次請求需要消耗一個令牌令牌按固定速率補(bǔ)充。桶滿了令牌就丟棄請求就會被拒絕或者排隊。這樣可以平滑掉突發(fā)的調(diào)用峰值不至于某個時刻把所有預(yù)算全部打穿。配額管理的粒度我建議按“組織-應(yīng)用-模型”三個維度去做。組織維度對應(yīng)到哪個部門應(yīng)用維度對應(yīng)到哪個業(yè)務(wù)系統(tǒng)模型維度對應(yīng)到具體調(diào)用哪類模型。這樣做的好處非常明顯出問題時能快速定位是哪里超了也能針對不同業(yè)務(wù)方的真實需求給不同配額而不是一刀切。2.3 密鑰托管與數(shù)據(jù)安全企業(yè)級的模型調(diào)用絕對不能允許業(yè)務(wù)方各自保管上游密鑰。網(wǎng)關(guān)把密鑰統(tǒng)一收走業(yè)務(wù)方只需要使用網(wǎng)關(guān)簽發(fā)的訪問憑據(jù)訪問網(wǎng)關(guān)即可這個憑據(jù)的有效范圍、權(quán)限范圍都可以單獨配置。安全層面還要做兩層過濾。一層是請求內(nèi)容過濾一些敏感字段在發(fā)送到上游之前做脫敏另一層是響應(yīng)內(nèi)容過濾防止模型生成的內(nèi)容帶出業(yè)務(wù)敏感信息。這里面的原則和數(shù)據(jù)庫審計類似越是在敏感行業(yè)越需要把審計日志做得細(xì)。至少應(yīng)該記錄請求方身份、請求內(nèi)容摘要、模型響應(yīng)、調(diào)用時間、Token消耗。2.4 觀測與成本歸因網(wǎng)關(guān)天然是模型調(diào)用的全鏈路觀測點。我在儀表盤上主要盯幾個數(shù)據(jù)請求量、成功率、平均延遲、Token消耗量、按部門/按應(yīng)用/按模型的成本分布。這些數(shù)據(jù)不能只是好看更重要的是能直接指導(dǎo)決策。比如我看到某個業(yè)務(wù)的請求量持續(xù)增長但成功率在下降那我就要去查是不是路由規(guī)則需要調(diào)整看到某個團(tuán)隊的Token成本突然翻了三倍那就是有人上線了新功能沒有配好模型選擇策略需要馬上溝通。觀測體系和成本歸因的數(shù)據(jù)不僅給管理層看也要給業(yè)務(wù)方開放查詢權(quán)限。讓業(yè)務(wù)方自己能看到當(dāng)前調(diào)用情況、花費成本他們才會主動去優(yōu)化調(diào)用方式。閉門造車地把他當(dāng)被告知對象反而容易引發(fā)不配合。3. 自動化編程落地場景、流程、工程化3.1 自動化編程不等于讓AI寫所有代碼先說一個常見誤區(qū)很多人提起自動化編程第一反應(yīng)是讓AI生成一個完整項目。實際在企業(yè)落地中最靠譜的不是讓AI輸出巨無霸代碼而是把它嵌入到研發(fā)的具體環(huán)節(jié)里做有邊界的自動化。邊界的意思是給AI一個明確的任務(wù)范圍。比如幫開發(fā)者補(bǔ)全一個函數(shù)根據(jù)注釋邏輯生成一段獨立工具代碼為一個已有模塊批量編寫測試用例對代碼做格式化或小范圍重構(gòu)。這些任務(wù)的特點是邊界清晰、結(jié)果容易驗證、出問題不會殃及整個項目。企業(yè)級自動化編程要的是穩(wěn)定性和可控性而不是追求單次生成的驚艷效果。把這個觀念傳遞清楚后面所有流程設(shè)計都會順暢很多。3.2 四個適合優(yōu)先落地的場景按我自己的實踐經(jīng)驗企業(yè)里最先適合上自動化編程的四個場景是這樣排序的。第一個是測試用例生成痛點最痛、邊界最清晰生成的測試代碼驗證起來也容易。第二個是重復(fù)性工具函數(shù)和腳本編寫這類代碼模式固定AI生成效率極高。第三個是已有代碼的重構(gòu)和優(yōu)化建議需要結(jié)合靜態(tài)檢查工具一起做。第四個才是新功能代碼生成這個場景要放到團(tuán)隊已經(jīng)熟練之后再做。這四個場景有一個共同特點都有明確的輸入輸出和可驗證標(biāo)準(zhǔn)AI生成結(jié)果的偏差不會直接影響線上運行。不要一開始就拿核心業(yè)務(wù)代碼讓AI去寫出了問題復(fù)盤成本極高也會讓團(tuán)隊失去信任。3.3 給模型足夠的“工程上下文”生成代碼這件事模型的水平只是一方面更重要的是它掌握了多少項目上下文。同一個“寫一個分頁查詢接口”的訴求你的項目用的是Spring Boot還是Go Gin返回值風(fēng)格是什么字段命名規(guī)范是什么這些信息模型都不知道直接讓它生成出來的東西大概率沒法用。所以我的做法是在工程倉庫存一份“開發(fā)上下文說明”把技術(shù)棧、目錄結(jié)構(gòu)、編碼規(guī)范、常用組件、錯誤處理約定都寫清楚。調(diào)用大模型的時候把它作為系統(tǒng)提示的一部分傳進(jìn)去。還可以用代碼向量檢索的方式把當(dāng)前任務(wù)涉及的相關(guān)代碼片段檢索出來一起發(fā)給模型效果比單純描述好很多。這個環(huán)節(jié)是最需要持續(xù)投入的。上下文越完善模型輸出和團(tuán)隊規(guī)范的貼合度越高返工量越少。我見過很多團(tuán)隊自動化編程效果不好十有八九是工程上下文沒喂夠。3.4 質(zhì)量門禁與人工評審生成出來的代碼不能直接合進(jìn)主干必須過質(zhì)量門禁。我配置的自動化編程流水線里至少要有三道卡關(guān)。第一道是靜態(tài)檢查生成代碼必須通過代碼風(fēng)格檢查、復(fù)雜度檢查、基礎(chǔ)安全掃描。第二道是單元測試覆蓋率對于新生成邏輯最少要求覆蓋率不低。第三道是人工code review但review重點不是逐行看代碼而是看邏輯設(shè)計、業(yè)務(wù)語義、邊界條件是否正確。人工評審這個環(huán)節(jié)不要省。AI生成的代碼擅長處理已知模式但對業(yè)務(wù)場景的隱含含義理解并不可靠人的判斷仍然是最后一道保險。也不要高估AI寫測試的能力AI補(bǔ)的測試往往都符合格式規(guī)范但可能沒有覆蓋真正的邊界情況。3.5 跟CI/CD怎么配合自動化編程要真正產(chǎn)生價值不能停留在開發(fā)者本地用一下而是要嵌入CI/CD流水線。我的做法是把自動化編程作為一個流水線階段在代碼提交之后自動執(zhí)行產(chǎn)出結(jié)果以評審請求的形式提交給開發(fā)者確認(rèn)。以生成測試為例開發(fā)提交一個功能模塊后觸發(fā)流水線測試生成器自動分析代碼和接口定義生成一批測試用例提交成一個提案。開發(fā)者確認(rèn)之后代碼進(jìn)測試環(huán)境不確認(rèn)就直接丟棄。這套流程的好處是讓自動化能力成為研發(fā)流程里一個穩(wěn)定環(huán)節(jié)而不是看某個開發(fā)者的個人習(xí)慣。CI/CD集成還有一個重要作用是留痕。每次AI參與生成的代碼、評審意見、最終是否合入都有記錄這對于后期追蹤問題、評估工具效果很有價值別把這步省略了。4. 從零到一的落地實操網(wǎng)關(guān)配置與自動化流水線搭建4.1 網(wǎng)關(guān)安裝與供應(yīng)商接入我采用的網(wǎng)關(guān)方案基于開源網(wǎng)關(guān)項目做二次封裝這比完全自研省太多事。部署形態(tài)采用容器化部署前端接一個負(fù)載均衡后端主節(jié)點負(fù)責(zé)路由決策從節(jié)點負(fù)責(zé)請求轉(zhuǎn)發(fā)配置中心統(tǒng)一管理所有規(guī)則。部署完成后第一步是接入模型供應(yīng)商。以接入一個兼容主流協(xié)議的服務(wù)為例需要配置供應(yīng)商的端點和密鑰。為了安全密鑰先放入密鑰管理服務(wù)再通過環(huán)境變量注入網(wǎng)關(guān)不要寫進(jìn)任何配置文件。供應(yīng)商接入的核心配置項有網(wǎng)絡(luò)端點、訪問憑據(jù)、模型清單。每一類模型要單獨建立記錄并標(biāo)注能力標(biāo)簽比如“高精度通用對話”“輕量級速概括”“代碼生成專用”等。這些標(biāo)簽是后續(xù)路由策略的基礎(chǔ)。4.2 路由與會話管理的配置方案路由規(guī)則我建議用配置文件維護(hù)而不是寫死在代碼里。配置文件的好處是修改后可以走上線評審流程方便審計。一條路由規(guī)則包含三部分匹配條件、目標(biāo)模型、降級策略。匹配條件可以用業(yè)務(wù)方、請求頭、任務(wù)類型等字段組合判斷。降級策略必須明確當(dāng)目標(biāo)模型服務(wù)返回錯誤或超時時是直接拒絕還是轉(zhuǎn)給備用模型備用模型的配額是否足夠支撐突發(fā)流量。會話管理要結(jié)合業(yè)務(wù)場景考慮。長對話場景需要維持上下文但上下文會越積越多Token成本急速上升。我建議網(wǎng)關(guān)里對會話長度做上限控制超出之后做摘要或截斷。這個操作看起來小實際成本優(yōu)化效果很明顯。4.3 自動化編程的流水線設(shè)計實例這里給一個簡化但可以直接照著套的流水線設(shè)計。假設(shè)場景是開發(fā)者提交一個新接口的實現(xiàn)代碼觸發(fā)自動化編程階段。# 觸發(fā)條件合并請求創(chuàng)建或更新 steps: 1. 拉取合并請求的代碼差異 2. 對差異中的新增函數(shù)簽名進(jìn)行解析 3. 檢索倉庫上下文中與接口相關(guān)的已有實現(xiàn)和調(diào)用方式 4. 構(gòu)建提示詞包含工程上下文函數(shù)簽名接口說明編碼規(guī)范 5. 調(diào)用網(wǎng)關(guān)上的代碼生成專用模型生成測試用例 6. 對生成的測試代碼執(zhí)行格式化和靜態(tài)檢查 7. 自動添加到合并請求中標(biāo)注為“AI建議” 8. 等待開發(fā)者在合并請求中確認(rèn)或拒絕這套流程中有一個關(guān)鍵點AI生成的代碼要以“建議”的形式合并到開發(fā)者的提交中而不是直接覆蓋開發(fā)者本地代碼。保持人機(jī)協(xié)作的主動性讓開發(fā)者始終擁有最終決定權(quán)這是團(tuán)隊接受度的重要保障。落地過程中可以先讓工具自動運行但只生成“建議”不直接進(jìn)測試環(huán)境。跑上兩周觀察建議的接受率和代碼缺陷率再決定是否擴(kuò)大自動化范圍。我發(fā)現(xiàn)很多團(tuán)隊一上來就想全自動結(jié)果一個瑕疵就把信任打沒了。5. 實戰(zhàn)中踩過的坑與排查思路5.1 生成代碼乍看正常一跑就崩這是自動化編程最高頻的問題。AI生成的代碼經(jīng)常在語法、結(jié)構(gòu)上很規(guī)范但一遇到邊界條件就崩潰。比如生成了一個批量處理數(shù)據(jù)的函數(shù)沒有做空列表保護(hù)生成了一個日期解析工具沒有處理閏年。排查下來原因很簡單模型看到的上下文集中在少量的代碼片段上對完整的業(yè)務(wù)約束知道得不多。我的解決思路是給模型提供異常處理規(guī)范在提示詞里明確要求生成代碼必須包含參數(shù)校驗、異常捕獲、邊界情況處理。同時增加一組“邊界測試樣例庫”讓流水線自動驗證生成代碼對特定邊界條件的處理不通過就直接打回。5.2 網(wǎng)關(guān)性能瓶頸與單點故障網(wǎng)關(guān)上線初期最大的問題是性能和為可用性。所有業(yè)務(wù)的模型請求都經(jīng)過網(wǎng)關(guān)網(wǎng)關(guān)處理能力直接成為瓶頸網(wǎng)關(guān)掛掉全公司AI能力都掛。做高可用是必須的。網(wǎng)關(guān)多實例部署之外還要在配置里做好網(wǎng)關(guān)自身的集群模式。另一個容易被忽視的是超時控制。模型服務(wù)上游響應(yīng)時間不穩(wěn)定如果不給網(wǎng)關(guān)配置合理的超時時間一個慢請求就會拖垮網(wǎng)關(guān)的線程池。建議給不同模型配置不同超時時間。簡單文本類任務(wù)超時時間可以短一些長文本生成類任務(wù)需要更長的等待。超時而不是無限等待網(wǎng)關(guān)才不會成為整個系統(tǒng)里最脆弱的一環(huán)。5.3 成本突增的監(jiān)測與治理成本突增是我最關(guān)注的問題。曾有一次某個應(yīng)用上線新功能后忘了設(shè)置模型選擇策略所有請求都默認(rèn)打到高成本的大模型上一晚跑出了平時一周的成本。找到原因是靠網(wǎng)關(guān)觀測看板復(fù)盤時發(fā)現(xiàn)如果早點配置成本告警這個問題可以更快被發(fā)現(xiàn)。我現(xiàn)在會配置三道防線第一道是按單次請求成本告警第二道是按小時維度成本環(huán)比突增告警第三道是每日成本匯總推送。三道防線出現(xiàn)任何一道觸發(fā)都能及時介入。治理成本的核心思路不是砍用量而是把請求分級。簡單任務(wù)用低成本模型復(fù)雜任務(wù)用高能力模型。這個分級可以依托網(wǎng)關(guān)的路由功能自動完成讓業(yè)務(wù)方無感遷移。5.4 推廣自動化編程時的組織阻力技術(shù)問題都好解決組織阻力才是最耗心力的。很多開發(fā)者的第一反應(yīng)是“AI不行”“生成的代碼我不信任”“引入這個工具是在培養(yǎng)人偷懶”。我在推行時做了一件很關(guān)鍵的事不強(qiáng)調(diào)提效而是強(qiáng)調(diào)減少重復(fù)勞動。把團(tuán)隊里最煩人的、寫著沒成就感的測試代碼生成、文檔編寫、格式調(diào)整這幾個場景交給自動化工具讓開發(fā)者把時間留給真正需要思考的設(shè)計和核心邏輯。這樣一來大家并不是被替代而是工作內(nèi)容變了。量化工具效果也很重要。我統(tǒng)計了兩個口徑AI建議的實際接受率以及通過AI生成的單測代碼占提交總量的比例。這兩個數(shù)據(jù)能逐漸讓團(tuán)隊看到工具價值而不是空口說它好。6. 經(jīng)驗總結(jié)與后續(xù)擴(kuò)展建議6.1 從“能用”到“好用”的三個階段大模型網(wǎng)關(guān)和自動化編程的建設(shè)都不是一蹴而就。我把它分成三個階段。第一階段是收斂把散落的模型接入統(tǒng)一收到網(wǎng)關(guān)把自動化工具先部署起來能跑通流程。第二階段是治理路由、配額、觀測、密鑰管理這些能力逐步完善自動化工具清單和規(guī)范也開始固化。第三階段才是智能把模型能力嵌入更多業(yè)務(wù)環(huán)節(jié)從單點使用變成體系化能力。很多團(tuán)隊死在第二階段原因不是技術(shù)能力不足而是沒有把治理體系做實。模型數(shù)量還在增加、業(yè)務(wù)方還在變化規(guī)則跟不上節(jié)奏就會重新亂套。所以第二階段不要急著擴(kuò)張場景先把管理規(guī)則打牢固。6.2 我堅持的幾個原則實踐到現(xiàn)在我有幾條原則一直在堅持。第一網(wǎng)關(guān)是基礎(chǔ)設(shè)施基礎(chǔ)設(shè)施的首要指標(biāo)是穩(wěn)定和可觀測而不是功能多。第二自動化編程永遠(yuǎn)保留人的終審權(quán)AI只做建議者不做決策者。第三一切成本都可見、可歸因、可追溯這個原則在預(yù)算緊張時是護(hù)身符。還有一條也很重要不要把這兩件事當(dāng)項目來做要當(dāng)產(chǎn)品來做。項目有結(jié)束日期產(chǎn)品需要持續(xù)運營。模型在更新、業(yè)務(wù)在變化、團(tuán)隊在擴(kuò)大網(wǎng)關(guān)規(guī)則和自動化工具都需要持續(xù)迭代維護(hù)。只有產(chǎn)品化運營才能在AI實踐這條路上走得長久。6.3 一個值得立即嘗試的小技巧最后分享一個我實際用下來性價比極高的小技巧。如果你暫時不想全量上網(wǎng)關(guān)可以先從一個簡單的統(tǒng)一代理服務(wù)開始它做的事情只是轉(zhuǎn)發(fā)請求和記錄日志。部署成本很低但能立刻帶來成本觀測和密鑰收斂的效果。自動化編程也一樣不需要一開始接全套流水線先從測試用例生成這一個場景切入在團(tuán)隊內(nèi)部跑出效果再逐步擴(kuò)展。技術(shù)落地很多時候不是考驗?zāi)芰ι舷薅强简炌七M(jìn)的節(jié)奏感。先把最小閉環(huán)跑起來讓數(shù)據(jù)說話后面的事情就順其自然地發(fā)生了。