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