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