哈佛上個(gè)月那份研究挺扎心700多家公司、70萬(wàn)開(kāi)發(fā)者AI編碼代理上線后代碼量漲了30%但交付的功能數(shù)幾乎沒(méi)變。多出來(lái)的代碼全堵在更長(zhǎng)的審查流程里。大廠能扛這種30%的冗余——人多、流程厚、容錯(cuò)高。但我?guī)У氖且粋€(gè)不大的研發(fā)團(tuán)隊(duì)清一色資深研發(fā)能力挺突出我作為技術(shù)負(fù)責(zé)人。在團(tuán)隊(duì)全員用AI編程已經(jīng)滿一年了本以為一支「能打」的隊(duì)伍配上AI會(huì)大幅提效結(jié)果滿一年回頭算賬體感不是「提效」是「賬算不平了」——錢(qián)、審查時(shí)間、調(diào)試時(shí)間、維護(hù)債全都肉眼可見(jiàn)地漲真正上線的功能卻沒(méi)跟上。作為技術(shù)負(fù)責(zé)人的身份把這用AI一整年真實(shí)踩的坑捋了一遍。AI編碼的「能效失控」不是某一個(gè)點(diǎn)的問(wèn)題而是一連串真實(shí)痛點(diǎn)疊出來(lái)的。下面逐個(gè)拆每個(gè)都附我給團(tuán)隊(duì)定下的落地規(guī)則。能效 產(chǎn)出 ÷ 投入。代碼量是「投入」的假象交付才是「產(chǎn)出」。這篇復(fù)盤(pán)所有結(jié)論都圍繞這一條。痛點(diǎn)一Token賬單在悄悄失控最容易被忽略的成本。一個(gè)看起來(lái)不大的需求Agent在目錄里來(lái)回讀文件、自我修正、跑了三十幾輪不知不覺(jué)燒掉幾美元而同一個(gè)需求一個(gè)熟手兩小時(shí)就能寫(xiě)完。機(jī)制很明確上下文窗口一膨脹每次補(bǔ)全AI都要把大文件重讀一遍成本隨對(duì)話輪次線性甚至指數(shù)往上走更糟的是agentic loop往往沒(méi)有退出條件——它「覺(jué)得自己還沒(méi)改對(duì)」就一直轉(zhuǎn)。團(tuán)隊(duì)里大家各自開(kāi)訂閱滿一年我拉過(guò)幾次賬單AI花的錢(qián)已經(jīng)是一筆不小的固定開(kāi)支占掉我們本可以投在工具鏈和人力上的預(yù)算。作為技術(shù)負(fù)責(zé)人這種「沒(méi)人實(shí)時(shí)盯著值不值」的狀態(tài)我必須止住。我給團(tuán)隊(duì)定的規(guī)則每個(gè)任務(wù)設(shè)token上限超了就停檢索 / 分類 / triage 用便宜模型貴模型只留給關(guān)鍵實(shí)現(xiàn)。CLAUDE.md里寫(xiě)死單次任務(wù)循環(huán)不超過(guò)15輪重復(fù)同一錯(cuò)誤立即轉(zhuǎn)人工。我每周看一次總賬單按任務(wù)類型歸類——某類需求consistently燒錢(qián)就說(shuō)明該拆小或換做法。痛點(diǎn)二審查反噬老手也成了瓶頸哈佛那個(gè)「30%代碼、0%功能」的結(jié)論根因就是審查工位被堆爆了。以前一天審10個(gè)PR現(xiàn)在AI一天吐 20 個(gè)人審不過(guò)來(lái)。我們團(tuán)隊(duì)這個(gè)瓶頸很反直覺(jué)人人都是資深本來(lái)能寫(xiě)能審按理說(shuō)審查不該是問(wèn)題。但 AI讓每個(gè)人的產(chǎn)出都翻倍PR隊(duì)列從「當(dāng)天清」變成「排一周」要么我硬著頭皮降質(zhì)量合入要么整個(gè)交付堵死。這事兒最后一定壓到我這兒。更陰的是AI代碼的「看起來(lái)對(duì)」——結(jié)構(gòu)工整、命名規(guī)范、注釋齊全但你不能因?yàn)楹每淳秃稀Ｎ覀冞@群老手反而更費(fèi)眼AI出錯(cuò)的位置從來(lái)不在我們預(yù)期的地方而資深工程師最容易被「它寫(xiě)得很規(guī)范」騙過(guò)去掃一眼就合。人寫(xiě)的代碼雖然糙但我知道哪該重點(diǎn)看AI的代碼得逐行確認(rèn)它真理解了需求、邊界處理對(duì)了、沒(méi)埋hidden bug。我給團(tuán)隊(duì)定的規(guī)則小步提交需求拆成 ≤ 半天能完成的小任務(wù)AI實(shí)現(xiàn)我只審diff和接口契約不審「它怎么寫(xiě)出來(lái)的」。PR模板強(qiáng)制「本PR改了哪些接口 / 依賴」我先驗(yàn)這部分——架構(gòu)和公共契約必須由人拍板AI不許擅自引入新依賴、新表。審查左移讓AI自己跑lint / 類型檢查 / 測(cè)試并在PR描述寫(xiě)清「我改了什么、為什么、風(fēng)險(xiǎn)點(diǎn)」。我只審三件事意圖對(duì)不對(duì)、接口穩(wěn)不穩(wěn)、有沒(méi)有越界。痛點(diǎn)三膨脹的代碼 膨脹的維護(hù)債AI有個(gè)天性傾向于「寫(xiě)更多」而不是「寫(xiě)更少」。能50行搞定的它可能給你 100行因?yàn)檫@樣「看起來(lái)更全面」。GitHub上火的caveman類Skill就是反著來(lái)的——強(qiáng)制極簡(jiǎn)、無(wú)填充Token省65%、速度快3倍作者說(shuō)簡(jiǎn)潔約束下準(zhǔn)確率反而更高。大廠多寫(xiě)的代碼有人重構(gòu)、有架構(gòu)師收口我們團(tuán)隊(duì)雖強(qiáng)但沒(méi)有專職重構(gòu) / 架構(gòu)崗AI寫(xiě)的「胖」代碼維護(hù)債照樣攤到每個(gè)人頭上新功能改不動(dòng)因?yàn)槟嵌芜壿嫑](méi)人完全懂大家都不想碰AI的生成物更多代碼還意味著更大的bug 面、更大的攻擊面、更長(zhǎng)的構(gòu)建和測(cè)試時(shí)間。作為負(fù)責(zé)人這筆債最后都是我來(lái)兜底收拾哪怕團(tuán)隊(duì)人人資深也沒(méi)人自愿去清理別人或AI留下的代碼。我給團(tuán)隊(duì)定的規(guī)則Prompt紀(jì)律寫(xiě)死「只實(shí)現(xiàn)被要求的功能不寫(xiě)額外代碼 / 注釋 / 抽象復(fù)用現(xiàn)有工具不引入新依賴?！棺孉I先寫(xiě)測(cè)試再寫(xiě)實(shí)現(xiàn)或至少給最小驗(yàn)證路徑——測(cè)試是逼它聚焦、防止過(guò)度生成的最實(shí)用手段。「禁止投機(jī)功能」寫(xiě)進(jìn)項(xiàng)目規(guī)則文件新會(huì)話第一天就加載不靠每次口頭提醒。痛點(diǎn)四調(diào)試黑洞——不是你寫(xiě)的老手也調(diào)不動(dòng)這是最反直覺(jué)、卻最少被討論的一點(diǎn)。我們都是資深研發(fā)本該什么坑都見(jiàn)過(guò)。但AI生成的代碼一旦出bug誰(shuí)都不是作者得先「讀」一遍AI的思路才能定位問(wèn)題。資深不代表能秒懂AI的黑盒邏輯——反而因?yàn)槲覀兞?xí)慣自己掌控每一處細(xì)節(jié)被一段AI代碼卡住時(shí)更難受AI用了個(gè)冷門(mén)庫(kù)或過(guò)期API本地能跑一上生產(chǎn)就報(bào)錯(cuò)排查全靠搜。更糟的是AI寫(xiě)錯(cuò)方向時(shí)老手也難判斷該修還是該重寫(xiě)因?yàn)閷?duì)它的「設(shè)計(jì)意圖」沒(méi)有肌肉記憶。滿一年我最大的感慨是AI沒(méi)有降低我們的調(diào)試成本只是把「寫(xiě)」的成本轉(zhuǎn)移成了「讀和猜」的成本。我給團(tuán)隊(duì)定的規(guī)則關(guān)鍵模塊堅(jiān)持「人寫(xiě)骨架、AI 填肉」接口、數(shù)據(jù)模型、錯(cuò)誤處理的契約由人來(lái)定AI只補(bǔ)實(shí)現(xiàn)。出了事人至少知道骨架在哪。每個(gè)AI生成的PR要求附「關(guān)鍵決策說(shuō)明」為什么選這個(gè)方案、踩了哪些坑。把隱性知識(shí)逼到臺(tái)面上而不是鎖在它的上下文里。建團(tuán)隊(duì)內(nèi)部的「AI踩坑本」把反復(fù)出現(xiàn)的坑某庫(kù)版本、某API用法固化成規(guī)則下次直接規(guī)避。痛點(diǎn)五虛假進(jìn)度和我對(duì)老板沒(méi)法交待最容易騙自己的地方。AI上來(lái)之后commit數(shù)、LOC、PR數(shù)全漲了周會(huì)很好看。但真相是需求到上線的周期cycle time沒(méi)短線上缺陷率可能還升了。我是那個(gè)要跟老板交帳的人。如果只拿LOC和PR數(shù)說(shuō)事老板會(huì)覺(jué)得「AI真香再加預(yù)算」可真實(shí)的交付節(jié)奏沒(méi)變快能效還在往下掉。直到某次生產(chǎn)事故把賬一次性算清那才是真虧。我給團(tuán)隊(duì)和老板定的規(guī)則不看LOC。盯三個(gè)真指標(biāo)每功能成本$/story 或 token/PR、cycle time、線上缺陷率。一張極簡(jiǎn)看板我每周看一次。一條鐵律用了AI一個(gè)月$/story 沒(méi)降、cycle time沒(méi)短就是失控信號(hào)。這情況下就要先停手復(fù)盤(pán)不盲目加量。為什么一支能打的團(tuán)隊(duì)照樣被能效失控放倒把這五個(gè)痛點(diǎn)放一起你會(huì)發(fā)現(xiàn)它們跟「團(tuán)隊(duì)強(qiáng)不強(qiáng)」幾乎無(wú)關(guān)而是被三件事放大在小團(tuán)隊(duì)里格外尖銳容錯(cuò)低一個(gè)大生產(chǎn)事故就能拖垮我們而AI引入的隱性缺陷最危險(xiǎn)——它不報(bào)錯(cuò)只是悄悄錯(cuò)。資深不代表不犯錯(cuò)只是犯得貴。治理缺沒(méi)有統(tǒng)一工具、規(guī)范、計(jì)量。諷刺的是人人資深意味著每人都有自己的習(xí)慣和prompt反而更難統(tǒng)一標(biāo)準(zhǔn)、沉淀最佳實(shí)踐。這件事只能我來(lái)推。人力薄沒(méi)有專職 QA / 架構(gòu) / SRE 兜底所有成本最終壓在「我 幾個(gè)骨干」身上。我們雖強(qiáng)但強(qiáng)在「各自能打」不擅長(zhǎng)「替AI兜底」——這件事誰(shuí)都不想接。大廠能用流程和人力把AI的副作用兜住我們兜不住所以作為技術(shù)負(fù)責(zé)人我更得在「用之前」就把邊界想清楚。能效 產(chǎn)出 ÷ 投入不是代碼量復(fù)盤(pán)完這五個(gè)痛點(diǎn)結(jié)論很樸素AI不是銀彈也不是騙局。它是放大器——團(tuán)隊(duì)交付鏈路健康它加速鏈路有洞它把洞放大成坑。我們這支清一色資深的團(tuán)隊(duì)用AI滿一年最深的體會(huì)是能效失控跟團(tuán)隊(duì)強(qiáng)不強(qiáng)無(wú)關(guān)只跟「有沒(méi)有看清鏈路」有關(guān)。我們小團(tuán)隊(duì)最該做的不是「多用AI」而是先把自己的交付鏈路看清錢(qián)花在哪、時(shí)間卡在哪、債積在哪再?zèng)Q定AI放在哪一環(huán)、怎么收費(fèi)、怎么兜底。具體規(guī)則上面每個(gè)痛點(diǎn)都給了。匯總成一句話也是我給團(tuán)隊(duì)立的規(guī)矩先把「能效」變成可盯的數(shù)字再給AI設(shè)預(yù)算和邊界人盯架構(gòu)與接口、AI盯實(shí)現(xiàn)約束它寫(xiě)瘦代碼把審查左移到自動(dòng)化。做到這五條AI才可能從「越寫(xiě)越虧」變回「真的提效」。相關(guān)閱讀用 AI 編程一年提效只發(fā)生在治理搭對(duì)之后——AI 提效的前提是治理不是工具本身本文「治理缺」痛點(diǎn)的延伸RAG 分塊策略實(shí)測(cè)01換分塊策略并不能提升 20 個(gè)點(diǎn)我用 100 道題說(shuō)話——瓶頸會(huì)自己移動(dòng)這個(gè)規(guī)律在 AI 編碼里一樣成立AI 員工時(shí)代真的來(lái)了paperclip / hindsight / dots 三家橫向掃一眼——多 Agent 協(xié)作工具現(xiàn)狀能不能把審查也自動(dòng)化