AI Coding 走到今天早就不是能不能生成代碼的問題而是生成的代碼你敢不敢合進(jìn)主干的問題。我自己在團(tuán)隊(duì)里推 AI 輔助開發(fā)這半年多最深的感受是AI 寫代碼的速度越快質(zhì)量治理的手段就越不能停留在舊時(shí)代。你不可能再用逐行 review 全量回歸去對抗 AI 一分鐘生成幾百行代碼的節(jié)奏那會(huì)被活活累死而且依然攔不住事故。我們需要一套新的治理思路用工程規(guī)范卡住源頭用代碼評審識(shí)別風(fēng)險(xiǎn)用風(fēng)險(xiǎn)驅(qū)動(dòng)的測試策略把有限的驗(yàn)證資源投到最可能出事的地方。這套組合拳打下來不敢說 AI 代碼零事故但至少能把驚喜變成已知風(fēng)險(xiǎn)把崩塌式的返工變成可控的迭代。這篇文章不聊概念就聊我在真實(shí)項(xiàng)目里怎么把這三件事落地的。1. AI 代碼帶來的是新問題還是老問題先弄清質(zhì)量退化在哪AI 代碼的缺陷表面上和人類程序員寫出來的缺陷很像邏輯錯(cuò)、邊界漏、命名爛。但底層成因完全不同。人類寫錯(cuò)代碼往往是理解偏差或者粗心AI 寫錯(cuò)代碼很多時(shí)候是因?yàn)樗鼘ι舷挛牡睦斫馐蔷植空_、全局缺失。我在項(xiàng)目里實(shí)際摸過一輪 AI 生成代碼的質(zhì)量歸納下來有三類最常見的問題。第一類是 API 幻覺型缺陷。AI 會(huì)給你寫出一個(gè)看起來很合理的調(diào)用但那個(gè)方法的參數(shù)名、返回值的語義、甚至整個(gè)方法是否存在它都敢編。比如我讓 AI 寫一個(gè)配置熱更新模塊它直接調(diào)用了一個(gè)從未在項(xiàng)目里定義過的ConfigLoader.refreshWithRetry()編譯報(bào)錯(cuò)還算好的更坑的是它在某些動(dòng)態(tài)語言里頭不做任何校驗(yàn)運(yùn)行到線上才知道崩。第二類是職責(zé)混淆型缺陷。AI 很擅長看起來完成了任務(wù)。你讓它寫一個(gè)緩存刷新函數(shù)它把緩存失效邏輯、數(shù)據(jù)庫回源邏輯、還有告警邏輯全部塞進(jìn)同一個(gè)函數(shù)里代碼量巨大、耦合度拉滿。單元測試能過代碼能編譯但換一個(gè)人來維護(hù)就是噩夢。這類問題在純邏輯推導(dǎo)上沒問題可一旦放到真實(shí)工程環(huán)境就是架構(gòu)腐化的種子。第三類是上下文截?cái)嘈腿毕?。AI 的注意力窗口有限它看到最近 20 行代碼時(shí)邏輯是對的但沒看到 200 行之前的全局狀態(tài)假設(shè)。最典型的是權(quán)限校驗(yàn)AI 在某個(gè)服務(wù)里生成的新接口完全沒有沿用服務(wù)原有的鑒權(quán)中間件因?yàn)樗鼪]看到。這一類最危險(xiǎn)因?yàn)樗粫?huì)暴露在編譯期和單測期只會(huì)在生產(chǎn)環(huán)境給你致命一擊。那為什么傳統(tǒng)質(zhì)量流程守不住這些坑原因很簡單傳統(tǒng)流程建立在人類作者可控的前提下。逐行 code review 要求人完全理解每一行代碼的意圖但 AI 生成的代碼往往量太大、來得太快人的注意力根本覆蓋不過來。傳統(tǒng)測試要求你基于需求文檔寫用例但 AI 代碼經(jīng)常在需求不明確的時(shí)候就開始自由發(fā)揮。所以不是老方法錯(cuò)了是它的假設(shè)前提失效了。我們需要的不是更慢更細(xì)的 review而是更聰明的治理。2. 工程規(guī)范把AI 能干什么變成AI 被允許干什么很多團(tuán)隊(duì)引入 AI Coding 的第一反應(yīng)是放開用然后發(fā)現(xiàn)質(zhì)量失控再一刀切禁止用。這兩條路我都見過也都不贊成。正確的方式是給 AI 劃定一個(gè)施工圍欄在圍欄內(nèi)它隨便跑圍欄外一律禁止。2.1 一套在我團(tuán)隊(duì)里跑通的 AI 操作規(guī)范我沒有搞那種掛在 Wiki 上吃灰的長篇制度而是定了一條簡單到可以貼在顯示器上的規(guī)范我管它叫AI 操作三段式。第一段是任務(wù)描述必須完整。給 AI 的任務(wù)里必須包含四樣?xùn)|西需求目標(biāo)、輸入輸出邊界、受影響模塊清單、可執(zhí)行的驗(yàn)收標(biāo)準(zhǔn)。比如不能只說寫一個(gè)用戶列表接口要說為用戶管理模塊提供一個(gè)分頁查詢接口輸入 page/pageSize輸出 id/name/email/status 字段狀態(tài)字段只允許 enabled/disabled 兩種取值需遵循該模塊現(xiàn)有的統(tǒng)一異常處理規(guī)范驗(yàn)收標(biāo)準(zhǔn)是單測覆蓋分頁邊界與非法參數(shù)分支。信息密度完全不同產(chǎn)出的代碼質(zhì)量也完全不同。第二段是強(qiáng)制小步提交。AI 生成的代碼不允許一次提交超過一個(gè)模塊的變更。哪怕它一次生成了三個(gè)關(guān)聯(lián)文件也要拆成三次提交每次提交之間可以穿插人類 review。這一步極其重要因?yàn)?AI 代碼一旦聚集成大塊出問題時(shí)你根本不知道是哪一段引入的。第三段是禁止 AI 單飛。AI 生成的代碼必須由一個(gè)人類所有者認(rèn)領(lǐng)后續(xù)改動(dòng)、故障排查、評審意見都掛在這個(gè)人名下。沒有所有者的代碼不允許合入主干。這條規(guī)則在心理層面上的效果遠(yuǎn)大于流程層面它杜絕了這不是我寫的所以我不負(fù)責(zé)的甩鍋心態(tài)。2.2 上下文工程把約束寫進(jìn)提示詞里規(guī)范再好看如果只靠人肉提醒很快就會(huì)被遺忘。更靠譜的做法是把約束直接寫進(jìn)提示詞里頭把工程規(guī)范變成 AI 的默認(rèn)上下文。我現(xiàn)在給團(tuán)隊(duì)搭了一個(gè)內(nèi)部的項(xiàng)目上下文包里面包含五類內(nèi)容項(xiàng)目目錄結(jié)構(gòu)說明、核心模塊職責(zé)表、通用返回格式定義、全局異常處理約定、以及依賴組件的版本清單。這些內(nèi)容每一次與 AI 交互時(shí)都會(huì)附帶進(jìn)去。有人覺得這太麻煩我可以負(fù)責(zé)任地說這五分鐘的麻煩能省掉后面五個(gè)小時(shí)的返工。我在一個(gè)模塊開發(fā)里做過對比實(shí)驗(yàn)直接把同樣的需求發(fā)給 AI一遍是純文字描述一遍是帶上下文包的描述。前者生成的代碼里有 30% 的接口路徑不符合項(xiàng)目現(xiàn)有的 RESTful 約定需要人工修正后者的代碼一次就貼近了項(xiàng)目風(fēng)格。再一個(gè)經(jīng)驗(yàn)是上下文寧可冗余不要缺失。有些團(tuán)隊(duì)為了讓 AI 更高效喜歡把上下文精簡到極致這恰恰是災(zāi)難的開始。我自己踩過的坑是讓 AI 改一個(gè)日志工具類沒給它附上項(xiàng)目的日志脫敏要求結(jié)果它引入了大量敏感字段的打印邏輯差點(diǎn)把用戶手機(jī)號(hào)打到日志里去。從那以后我的原則變成上線前的 AI 代碼上下文寧可多給 20% 也不要少給 1%。2.3 測試概念前置讓 AI 先寫測試再寫實(shí)現(xiàn)在做工程規(guī)范時(shí)我強(qiáng)烈建議加一條對復(fù)雜邏輯模塊要求 AI 先輸出測試用例再輸出實(shí)現(xiàn)代碼。有人說這太理想化但實(shí)際操作下來這一條對質(zhì)量提升的效果立竿見影。原理也不復(fù)雜。AI 在先寫測試的模式下必須把需求轉(zhuǎn)化成可驗(yàn)證的行為描述它就會(huì)被迫去明確邊界條件、異常分支、返回值類型。這些原本是藏在代碼邏輯里的隱含假設(shè)被測試用例逼著顯性化了。等它在寫實(shí)現(xiàn)的時(shí)候其實(shí)是照著測試用例去湊邏輯對需求的偏離就少了一個(gè)量級(jí)。我在某個(gè)數(shù)據(jù)處理模塊里試過這個(gè)流程。AI 先生成了 8 個(gè)測試用例正常值、空數(shù)組、全 null、非法類型、邊界值、并發(fā)調(diào)用、超時(shí)場景、以及數(shù)據(jù)量超過閾值時(shí)的降級(jí)行為。然后照著這些測試去寫實(shí)現(xiàn)最后跑測試第一版就通過了 7/8只有一個(gè)并發(fā)場景暴露了共享狀態(tài)未加鎖。未加測試先行的一版同樣是這個(gè)模塊核心功能跑通但邊界場景掛了三個(gè)排查花了我一個(gè)下午。3. 代碼評審給 AI 代碼做分級(jí)審查而不是逐行死磕代碼評審是 AI Coding 質(zhì)量治理里最容易被誤解的一環(huán)。有很多人聽說 AI 代碼危險(xiǎn)就要求團(tuán)隊(duì)保持逐行 review的傳統(tǒng)。我的看法恰恰相反如果 AI 代碼還需要你逐行 review說明前面的工程規(guī)范和任務(wù)切分沒有做好。評審的正確姿勢是識(shí)別風(fēng)險(xiǎn)等級(jí)只對高風(fēng)險(xiǎn)區(qū)域做深度審查其余部分走常規(guī)檢查。3.1 從審代碼升級(jí)為審風(fēng)險(xiǎn)我把 AI 代碼評審的關(guān)注點(diǎn)從這行寫得對不對遷移到這段代碼會(huì)給系統(tǒng)帶來什么不可控的風(fēng)險(xiǎn)。具體來說有三個(gè)問題優(yōu)先回答它改變了哪些模塊之間的邊界它是否引入了新的第三方依賴它是否觸碰了全局共享狀態(tài)。這三個(gè)問題指向的是同一種擔(dān)心AI 生成的代碼最薄弱的不是單行邏輯而是它和外圍世界的交接處。一個(gè)負(fù)責(zé)用戶登錄的函數(shù)內(nèi)部邏輯寫得再漂亮如果它在邊界處沒有透傳原有的事故追蹤 ID那出了故障你連日志都串不起來。這種問題靠逐行看很難發(fā)現(xiàn)但用邊界視角去看一眼就能暴露。我的建議是評審 AI 代碼時(shí)先看 diff 的接縫部分文件頭部的 import、函數(shù)的簽名、與外部模塊的調(diào)用關(guān)系、錯(cuò)誤處理是否落入全局兜底機(jī)制。接縫干凈了內(nèi)部邏輯出問題的概率就會(huì)低很多。3.2 四層審查深度的選擇我把評審強(qiáng)度分成四層根據(jù)代碼的風(fēng)險(xiǎn)評分來選擇。第一層是變更范圍審查只核對 Diff 是否在任務(wù)描述聲明過的文件范圍內(nèi)找出偷偷改了不該改的文件的 AI 行為。第二層是接口契約審查核對新的函數(shù)簽名、參數(shù)結(jié)構(gòu)、返回結(jié)構(gòu)與調(diào)用方是否對齊有沒有破壞已有契約。第三層是邏輯深度審查針對核心算法、狀態(tài)機(jī)、并發(fā)控制等高風(fēng)險(xiǎn)代碼做逐行推演。第四層是安全合規(guī)審查主要檢查敏感數(shù)據(jù)、鑒權(quán)邏輯、注入風(fēng)險(xiǎn)、加密算法的選用是否合規(guī)。我要求團(tuán)隊(duì)給每個(gè)評審任務(wù)打一個(gè) 1 到 4 的等級(jí)。新增一個(gè)無關(guān)緊要的展示接口走 1 級(jí)就夠改動(dòng)支付狀態(tài)流轉(zhuǎn)的至少走到 3 級(jí)涉及用戶數(shù)據(jù)導(dǎo)出、密鑰管理、權(quán)限提升的直接頂?shù)?4 級(jí)。這樣分級(jí)的好處是節(jié)省人力不流于形式。團(tuán)隊(duì)成員不會(huì)因?yàn)槊恳粋€(gè) AI 提交都做深度 review 而疲于奔命也不會(huì)因?yàn)樯疃?review 只存在于口號(hào)中而形同虛設(shè)。3.3 一份可以抄走的 AI 代碼評審清單我整理了一份評審檢查清單不一定適合所有團(tuán)隊(duì)但作為起點(diǎn)非常實(shí)用。清單分成八個(gè)問題評審人只需要逐項(xiàng)回答是或否。第一條AI 是否修改了任務(wù)描述未提及的文件如果有理由是否可靠。第二條是否新增第三方依賴如果是版本有無鎖定來源是否可信。第三條是否存在看起來正確但永遠(yuǎn)走不到的分支比如無用的異常處理、不可能為真的條件判斷。第四條錯(cuò)誤處理是否會(huì)被外層攔截還是吞掉了關(guān)鍵錯(cuò)誤信息。第五條是否直接訪問了全局可變的共享狀態(tài)繞過所屬模塊的接口。第六條敏感數(shù)據(jù)是否做了脫敏和最小化訪問。第七條函數(shù)或類是否保持了單一職責(zé)有沒有把兩個(gè)以上不相關(guān)邏輯揉在一起。第八條變更有沒有配套的測試測試是否覆蓋了邊界和失敗分支。這套清單執(zhí)行了三個(gè)月我最大的體會(huì)是AI 代碼評審中最高頻的問題不是邏輯錯(cuò)誤而是多管閑事。AI 特別容易在實(shí)現(xiàn)需求順手把日志格式改了、把某個(gè)常量重命名了、把無關(guān)模塊的格式調(diào)整了。這類問題雖然不致命但會(huì)污染 Git 歷史、加大 diff 審查難度、增加未來排查的噪音。清單第一條就是沖著這個(gè)去的。4. 風(fēng)險(xiǎn)驅(qū)動(dòng)測試把稀缺的測試資源投向高危區(qū)AI Coding 帶來的一個(gè)隱性問題是代碼產(chǎn)出量上升測試資源并沒有同比上升。如果繼續(xù)按照所有代碼同樣對待的策略去寫測試要么測試覆蓋跟不上要么測試深度不足最后還是漏。所以必須引入風(fēng)險(xiǎn)驅(qū)動(dòng)的測試?yán)砟畎羊?yàn)證資源集中到風(fēng)險(xiǎn)最高的那部分 AI 代碼上。4.1 什么是 AI 代碼的變更地圖在規(guī)劃測試策略時(shí)我先畫一張 AI 代碼變更地圖。地圖的橫軸是變更面積指一次 AI 提交涉及的代碼范圍比如新增文件數(shù)、修改行數(shù)、涉及的模塊數(shù)?？v軸是業(yè)務(wù)影響指這個(gè)模塊一旦出錯(cuò)會(huì)造成的損失級(jí)別比如影響用戶資金、影響核心鏈路、只影響邊緣頁面。這兩個(gè)維度一交叉就得到四個(gè)象限。大面積高影響區(qū)域是最優(yōu)先保障區(qū)必須做全量回歸加集成測試最好還要有性能壓測。大面積極低影響區(qū)域可以做冒煙級(jí)別的檢查不用投入過多精力。小面積高影響區(qū)域一定要做深度測試因?yàn)樽兏〔淮盹L(fēng)險(xiǎn)小支付模塊改三行也是大事。小面積低影響區(qū)域交給常規(guī)的單元測試覆蓋就夠了。這個(gè)地圖的價(jià)值在于它能把有限的測試資源從均勻撒胡椒面變成精準(zhǔn)滴灌。我有一段時(shí)間團(tuán)隊(duì)測試人力特別緊張靠這個(gè)地圖硬是把上線前的測試時(shí)間壓縮了 40%同時(shí)線上事故沒有上升核心原因就是我們把時(shí)間花在了能產(chǎn)生驗(yàn)證價(jià)值的地方。4.2 風(fēng)險(xiǎn)評分卡把直覺變成可計(jì)算的分?jǐn)?shù)為了讓風(fēng)險(xiǎn)地圖不靠拍腦袋我設(shè)計(jì)了一個(gè)五維度的風(fēng)險(xiǎn)評分卡。評審人或負(fù)責(zé)人拿到一份 AI 代碼變更后按以下維度打分每個(gè)維度 1 到 5 分總分 5 到 25 分。第一個(gè)維度是變更密度新增代碼行數(shù)除以涉及文件數(shù)密度越高風(fēng)險(xiǎn)越高。一個(gè)文件塞了 500 行新代碼與五文件各加 50 行前者風(fēng)險(xiǎn)大得多。第二個(gè)維度是依賴廣度變更代碼直接調(diào)用的外部模塊數(shù)量調(diào)用越多出問題的波及面越廣。第三個(gè)維度是共享狀態(tài)觸碰頻率是否操作了全局配置、共享緩存、數(shù)據(jù)庫連接等公共資源觸碰越多越危險(xiǎn)。第四個(gè)維度是歷史缺陷密度該模塊過去三個(gè)月內(nèi)缺陷單數(shù)量歷史包袱越重越容易翻車。第五個(gè)維度是修復(fù)復(fù)雜度假設(shè)上線后出了問題回滾容易嗎緊急修復(fù)需要在多長時(shí)間內(nèi)完成涉及跨團(tuán)隊(duì)協(xié)調(diào)的自動(dòng)加高分。我建議團(tuán)隊(duì)定一個(gè)閾值大于等于 18 分的變更必須走測試強(qiáng)化通道也就是不僅要跑常規(guī)測試還要額外加一輪針對性的集成測試和故障演練。15 到 17 分走標(biāo)準(zhǔn)測試流程低于 15 分的走輕量驗(yàn)證即可。這個(gè)評分卡跑起來以后團(tuán)隊(duì)的測試決策就從感覺哪個(gè)模塊重要升級(jí)成依據(jù)分?jǐn)?shù)分配資源。測試工程師再也不用為了哪些用例該優(yōu)先執(zhí)行跟開發(fā)扯皮分?jǐn)?shù)就是依據(jù)。4.3 紅隊(duì)測試主動(dòng)給 AI 代碼找茬對于高評分模塊我還建議引入紅隊(duì)測試的思路。這個(gè)做法本身在安全領(lǐng)域很常見但用在 AI 代碼質(zhì)量治理上同樣有效。具體做法是在 AI 完成一個(gè)高風(fēng)險(xiǎn)模塊后測試人員不按需求文檔測試而是扮演一個(gè)惡意破壞者去嘗試擊穿系統(tǒng)。輸入極端參數(shù)、模擬鑒權(quán)繞過、直接修改變量權(quán)限、用并發(fā)請求沖擊狀態(tài)機(jī)、在配置文件中混入非法格式——所有你能想到的壞招都往上面招呼。紅隊(duì)測試在 AI 代碼上特別有價(jià)值因?yàn)?AI 生成代碼往往在正常路徑上表現(xiàn)良好但在對抗性路徑上容易出岔子。比如它可能對正常輸入做了詳盡的校驗(yàn)但對空字符串加超長字符串拼接的組合場景完全沒有防御直接導(dǎo)致內(nèi)存異常。有一次我們讓 AI 寫了一個(gè)數(shù)據(jù)導(dǎo)出功能正常測試全過紅隊(duì)測試時(shí)測試伙伴傳了一個(gè)包含 500 萬行的請求AI 代碼直接把所有數(shù)據(jù)一次性加載進(jìn)內(nèi)存服務(wù)差點(diǎn)被打掛。如果不是紅隊(duì)測試提前暴露這一版上線就是一個(gè)嚴(yán)重的穩(wěn)定性事故。4.4 回歸策略AI 代碼能不能合入最終看回歸是否可信風(fēng)險(xiǎn)驅(qū)動(dòng)測試的最后一個(gè)環(huán)節(jié)是回歸策略。我的原則是高風(fēng)險(xiǎn) AI 變更要過兩輪回歸第一輪在合入前跑完該模塊的關(guān)聯(lián)用例第二輪合入后的夜間回歸覆蓋全天鏈路。低風(fēng)險(xiǎn)變更只需要合入后的常規(guī)回歸。很多團(tuán)隊(duì)在 AI 代碼合入后只跑一遍對應(yīng)模塊的測試就大功告成這其實(shí)是不對的。AI 代碼的隱性耦合經(jīng)常體現(xiàn)在改動(dòng) A 模塊影響 B 模塊的非功能性表現(xiàn)比如性能下降、內(nèi)存占用升高、響應(yīng)超時(shí)概率變大。這些只有放到全鏈路回歸環(huán)境里才能暴露出來。我現(xiàn)在在團(tuán)隊(duì)里推的是AI 代碼變更必須帶一條回歸基線基線內(nèi)容包含該模塊近兩周的調(diào)用量峰值、P99 時(shí)延、錯(cuò)誤率。合入前對比這三個(gè)指標(biāo)發(fā)現(xiàn)任何一個(gè)劣化超過 20%立即回退不給 AI 代碼帶病合入的機(jī)會(huì)。5. AI 代碼質(zhì)量治理的本質(zhì)是把信任變成驗(yàn)證走到這一步我想坦白分享一件事AI Coding 質(zhì)量治理最大的敵人不是 AI 本身而是我們自己對AI 很聰明的過度信任。很多事故的根源是開發(fā)者在 AI 生成代碼后下意識(shí)地認(rèn)為它既然能寫出來應(yīng)該就是對的于是放松了審查和測試的標(biāo)準(zhǔn)。我在團(tuán)隊(duì)里反復(fù)強(qiáng)調(diào)一句話AI 代碼不是代碼它是建議是需要被驗(yàn)證的建議。你可以把它當(dāng)成一個(gè)極其高效、從不抱怨、但偶爾極具創(chuàng)造力的初級(jí)工程師你當(dāng)然用它的產(chǎn)出物但 absolut 需要你來把關(guān)。這個(gè)心態(tài)上的轉(zhuǎn)變可能比任何工具和規(guī)范都重要。實(shí)際跑了一段時(shí)間之后我團(tuán)隊(duì)里 AI 代碼的合入率沒有變低但線上事故率顯著下降。原因很簡單前期該卡的口子都卡住了所以后期的火警自然變少了。我個(gè)人最深的體會(huì)是質(zhì)量治理不是一套靜態(tài)的制度而是一個(gè)和人、和工具、和流程持續(xù)磨合的動(dòng)態(tài)過程。今天適用的規(guī)則可能下個(gè)月就隨著模型能力的提升而需要調(diào)整保持視驗(yàn)證為常態(tài)的態(tài)度才是長期穩(wěn)定的基石。最后再分享一個(gè)小的實(shí)操技巧每當(dāng)我發(fā)現(xiàn)某個(gè) AI 生成的模塊質(zhì)量特別差我不會(huì)只修代碼而是回去追問當(dāng)初給 AI 的上下文里到底缺了什么。十有八九會(huì)發(fā)現(xiàn)是任務(wù)描述缺少了某個(gè)邊界約定或者項(xiàng)目規(guī)范沒有沉淀成 AI 可讀的文檔。把這一次失敗轉(zhuǎn)化成上下文包里新增的一條規(guī)范團(tuán)隊(duì)的質(zhì)量水位就會(huì)往上走一格而且是不可逆的那種。