本文來(lái)自微信公眾號(hào)： 葉小釵 ，作者：葉小釵，原文標(biāo)題：《AI 把代碼寫(xiě)快了 10 倍，為什么交付只快了 18%？》
最近我為某公司研發(fā)團(tuán)隊(duì)做了一次相對(duì)深入的咨詢(xún)陪跑，過(guò)程中分享了過(guò)去兩年做AI原生組織的一些經(jīng)驗(yàn)。
為了準(zhǔn)備這次培訓(xùn)，我把近三個(gè)月看到的AI團(tuán)隊(duì)實(shí)踐又翻了一遍。
OpenAI、Shopify、Spotify、Dropbox、Figma、百度、騰訊、阿里，還有一些只有幾個(gè)人，卻同時(shí)跑著上百個(gè)Agent的小團(tuán)隊(duì)。
再加上我這三年做過(guò)的25個(gè)AI項(xiàng)目，材料堆在一起以后，我原本以為能整理出一份AI原生產(chǎn)研團(tuán)隊(duì)先進(jìn)工具清單。
翻完以后，那張清單反倒沒(méi)那么重要了。
因?yàn)檫@些團(tuán)隊(duì)早已越過(guò)誰(shuí)先用上Codex、Claude Code、誰(shuí)的項(xiàng)目里AI代碼占比更高的階段。
他們正在干一件麻煩得多，也徹底得多的事情：重新搭建整條產(chǎn)研交付生產(chǎn)線。
代碼寫(xiě)快了，所以呢？
Spotify披露，超過(guò)99%的工程師每周都在使用AI編程產(chǎn)品，94%的工程師認(rèn)為自己因此更高效，Pull Request的頻率上升了76%。
這組數(shù)據(jù)已經(jīng)很夸張了。
Shopify走得更遠(yuǎn)。他們自主研發(fā)了一個(gè)叫River的原生Slack Agent，并將它部署在公司內(nèi)部的公開(kāi)頻道。
員工只要在頻道里@它，就可以讓它讀代碼、跑測(cè)試、查詢(xún)數(shù)據(jù)倉(cāng)庫(kù)、查看線上Trace，甚至創(chuàng)建新的Pull Request。
30天內(nèi)，有3536個(gè)被合并的PR由River共同編寫(xiě)完成。
OpenAI內(nèi)部也發(fā)現(xiàn)，一個(gè)工程師同時(shí)盯著3—5個(gè)Agent會(huì)話，差不多就到了極限。
數(shù)量再多，人腦便開(kāi)始混亂：
這個(gè)任務(wù)在干什么？
那個(gè)任務(wù)卡在哪里？
哪個(gè)Agent還在等待補(bǔ)充上下文？
于是，他們通過(guò)開(kāi)源的Symphony，把項(xiàng)目管理工具Linear改造成了Agent控制臺(tái)。
人提交任務(wù)，后臺(tái)自動(dòng)領(lǐng)取、執(zhí)行、測(cè)試，再處理評(píng)審意見(jiàn)。部分團(tuán)隊(duì)上線后的前三周，合并PR的數(shù)量直接上升了500%。
單看這些數(shù)字，一個(gè)比一個(gè)猛?？蛇@里藏著一個(gè)很容易被忽略的問(wèn)題：
代碼寫(xiě)得更快、更多，并不等于產(chǎn)品迭代得更快
Dropbox的團(tuán)隊(duì)說(shuō)得很直接：AI提高代碼生成速度以后，交付壓力只是順著流水線向后轉(zhuǎn)移。評(píng)審隊(duì)列越來(lái)越長(zhǎng)，CI越來(lái)越擁擠，測(cè)試、發(fā)布、部署和線上運(yùn)維全都開(kāi)始堵。
百度內(nèi)部也遇到了幾乎一樣的情況。Coding Agent讓寫(xiě)代碼的速度提高了十倍以上，常規(guī)的雙周迭代周期卻沒(méi)有明顯縮短。
團(tuán)隊(duì)復(fù)盤(pán)后發(fā)現(xiàn)：Coding只占整條研發(fā)鏈路約20%的時(shí)間，其余時(shí)間都耗在需求澄清、方案評(píng)審、測(cè)試驗(yàn)證和等待上。
做個(gè)簡(jiǎn)單計(jì)算：如果占比20%的Coding環(huán)節(jié)提速十倍，其余環(huán)節(jié)維持原樣，整個(gè)交付周期也只能縮短18%左右。這一下就很尷尬了：
大家原以為AI會(huì)消滅瓶頸，把整體生產(chǎn)效率提高十倍、百倍。結(jié)果AI拿著一個(gè)大喇叭，把過(guò)去藏在研發(fā)流程里的問(wèn)題全喊了出來(lái)：
需求不清晰。
優(yōu)先級(jí)反復(fù)變化。
接口遲遲沒(méi)人提供。
組織知識(shí)散落在N個(gè)群聊和不同人的腦子里。
測(cè)試用例不完整，自動(dòng)化回歸測(cè)試也沒(méi)補(bǔ)齊。
驗(yàn)收標(biāo)準(zhǔn)含糊，沒(méi)人能說(shuō)清楚怎樣才算做完。
其實(shí)比較經(jīng)典的還是這張圖：
這和我在企業(yè)里觀察到的情況基本一致，關(guān)于AI編程帶給研發(fā)團(tuán)隊(duì)的效率提升，我有三個(gè)感受：
團(tuán)隊(duì)越小，提效越明顯。極端情況下甚至能達(dá)到1000%；團(tuán)隊(duì)規(guī)模越大，整體提升30%已經(jīng)很不錯(cuò)。
項(xiàng)目類(lèi)型會(huì)直接影響效果。老系統(tǒng)遷移、后臺(tái)項(xiàng)目和傳統(tǒng)增刪查改，提效非?？鋸?；需要多人共創(chuàng)、跨部門(mén)協(xié)作的項(xiàng)目，提升往往沒(méi)那么明顯。
工程師能力越強(qiáng)，AI帶來(lái)的增益越大。會(huì)拆問(wèn)題、懂業(yè)務(wù)、能判斷的人，一條指令就能撬動(dòng)大量Agent工作。
個(gè)人效率已經(jīng)發(fā)生了巨變，組織效率卻經(jīng)常原地踏步。
一個(gè)工程師一天完成過(guò)去三天的代碼量，測(cè)試團(tuán)隊(duì)仍然按照原來(lái)的速度工作；需求還沒(méi)講清楚，Agent已經(jīng)生成了三套方案；一個(gè)部門(mén)跑得再快，也得在接口、審批和評(píng)審環(huán)節(jié)繼續(xù)排隊(duì)：
個(gè)人AI提效，不等于組織AI提效
重做生產(chǎn)線
在做咨詢(xún)之前，我特別喜歡從企業(yè)員工AI使用情況/能力，去判斷這個(gè)團(tuán)隊(duì)是否AI原生了，比如用了多少AI、AI代碼占比、Token消耗情況...
真正看多了公司，發(fā)現(xiàn)所謂Token消耗沒(méi)得撒子意義，站在組織的角度，關(guān)注點(diǎn)會(huì)很不一樣：它有沒(méi)有把人的意圖、項(xiàng)目知識(shí)、機(jī)器執(zhí)行和最終責(zé)任，拼成一條能夠穩(wěn)定運(yùn)轉(zhuǎn)的研發(fā)生產(chǎn)線。
放到產(chǎn)研團(tuán)隊(duì)里，可以整理成一套更具體的公式：
AI原生產(chǎn)研團(tuán)隊(duì)=員工AI能力+研發(fā)機(jī)制流程+評(píng)價(jià)治理機(jī)制+AI研發(fā)操作系統(tǒng)
員工AI能力，決定工程師能不能用好Codex、Claude Code和各種Agent。
研發(fā)機(jī)制流程，決定需求、方案、任務(wù)和驗(yàn)收能不能被機(jī)器理解。
評(píng)價(jià)治理機(jī)制，決定誰(shuí)有權(quán)發(fā)布、誰(shuí)負(fù)責(zé)檢查、出了問(wèn)題由誰(shuí)承擔(dān)責(zé)任。
AI研發(fā)操作系統(tǒng)，負(fù)責(zé)連接代碼、知識(shí)、工具、環(huán)境、任務(wù)、測(cè)試和部署。
這四部分共同決定了AI能否進(jìn)入研發(fā)主線。
只給工程師安裝幾個(gè)工具，最多解決第一部分，而很多組織正在走第二部分，比較典型的方法論是SDD：
做個(gè)好上游
過(guò)去產(chǎn)品經(jīng)理寫(xiě)PRD，主要是給人看的，他們有個(gè)小心思：下游研發(fā)會(huì)兜底。
所以，文檔里留一點(diǎn)模糊空間，通常問(wèn)題不大。產(chǎn)品經(jīng)理可以在評(píng)審會(huì)上補(bǔ)充，研發(fā)可以當(dāng)面追問(wèn)，UX/UI也會(huì)憑經(jīng)驗(yàn)補(bǔ)齊缺失狀態(tài)。
這里倒不是吐槽產(chǎn)品經(jīng)理，因?yàn)檠邪l(fā)和測(cè)試的關(guān)系乃至前端和后端的關(guān)系是一樣的，比如后端就是要寫(xiě)垃圾接口文檔，前端是拿他一點(diǎn)辦法都沒(méi)有。
這些事，之前都是默認(rèn)下游吃虧，但在AI編程時(shí)代就不行了，PRD一旦需要直接喂給Agent，前端看不懂后端接口文檔，就會(huì)自由發(fā)揮，這些模糊空間就危險(xiǎn)了：
比如你告訴它：做一個(gè)會(huì)員系統(tǒng)。
它肯定能做出來(lái)，而且看上去還挺像那么回事。
可會(huì)員能不能退款？
并發(fā)登錄怎么算？
優(yōu)惠券能不能疊加？
舊用戶如何遷移？
這些內(nèi)容沒(méi)有提前說(shuō)明，Agent就會(huì)自己補(bǔ)。它既敢做，也敢猜。至于猜得對(duì)不對(duì)，那就看造化了...
總之，執(zhí)行能力越強(qiáng)，模糊需求越危險(xiǎn)
以前，一個(gè)含糊的需求最多浪費(fèi)一兩個(gè)工程師半天時(shí)間?，F(xiàn)在，同樣一句含糊的話，可以驅(qū)動(dòng)20個(gè)Agent并行產(chǎn)出20份完整的錯(cuò)誤答案。
AI會(huì)把效率放大，也會(huì)把偏差一起放大，而且偏得更快。最近Spec又被大家撿回來(lái)，原因就在這里。
阿里Qoder的Quest Mode會(huì)先生成完整Spec，把它作為人和Agent對(duì)齊的事實(shí)源。
Agent在后臺(tái)異步執(zhí)行，遇到歧義時(shí)彈出Action Required，任務(wù)結(jié)束后再交付一份包含驗(yàn)證結(jié)果與代碼變更的Task Report。
百度的做法也很接近：用Rules固化工程范圍，用Skills封裝Code Review、E2E測(cè)試和知識(shí)庫(kù)更新，再通過(guò)Spec約束技術(shù)方案。
以前散落在研發(fā)經(jīng)驗(yàn)里的內(nèi)容，正在被整理成Agent可以讀取、理解和執(zhí)行的組織資產(chǎn)，這類(lèi)方法現(xiàn)在經(jīng)常被統(tǒng)稱(chēng)為SDD。
SDD
在我們的實(shí)踐中，一份可以進(jìn)入執(zhí)行環(huán)節(jié)的Spec，至少應(yīng)該包含六個(gè)部分：
目標(biāo)；
范圍；
約束；
決策；
任務(wù)；
驗(yàn)收。
SDD做的事情并不神秘。它用統(tǒng)一模板承載需求，讓不同角色接收到的信息盡量保持一致；再把驗(yàn)收標(biāo)準(zhǔn)變成任務(wù)準(zhǔn)入和交付驗(yàn)收的憑證。
如果上游提交的Spec缺少邊界、異常處理和驗(yàn)收條件，下游，包括Agent，可以拒絕開(kāi)工。
問(wèn)題留在源頭解決，別再讓執(zhí)行環(huán)節(jié)不斷猜測(cè)和補(bǔ)位。這里碰到的是研發(fā)管理里的兩個(gè)老問(wèn)題：
第一個(gè)是信息失真。
信息經(jīng)過(guò)多人傳遞以后，總會(huì)被刪減、加工，甚至被不同角色悄悄“加料”。
第二個(gè)是評(píng)價(jià)失效。
上游提交了一份無(wú)法執(zhí)行的需求，最后卻沒(méi)有承擔(dān)任何質(zhì)量責(zé)任。研發(fā)為了推進(jìn)項(xiàng)目，只能自行補(bǔ)齊，出了問(wèn)題還得背鍋。
所以，SDD建立的是一條研發(fā)信息通道，也是Agent能夠工作的數(shù)字底座，反正核心就是把文檔寫(xiě)清楚。
一份有用的Spec，需要講明白什么結(jié)果才算做對(duì)，并且盡量讓這些標(biāo)準(zhǔn)可以被測(cè)試。比如：
用戶完成付款后會(huì)看到什么？
失敗后能否重試？
權(quán)限不足時(shí)，系統(tǒng)應(yīng)該怎樣告知用戶？
哪些業(yè)務(wù)指標(biāo)不能下降？
Spec既是需求說(shuō)明，也是一份驗(yàn)收契約。
當(dāng)然，SDD也會(huì)增加管理成本，比如一個(gè)很小的需求，有沒(méi)有必要走完六個(gè)部分？哪些任務(wù)需要完整Spec？哪些任務(wù)只要一張輕量任務(wù)卡？誰(shuí)來(lái)維護(hù)模板？誰(shuí)有權(quán)拒絕不合格需求？這些都需要團(tuán)隊(duì)自己劃分。
并且，大家要清楚：
SDD沒(méi)有消滅復(fù)雜度，它只是把復(fù)雜度提前到了定義階段，讓上游承擔(dān)自己應(yīng)該承擔(dān)的工作
即使沒(méi)有AI，一套執(zhí)行良好的SDD也能提高團(tuán)隊(duì)效率。AI只是把這件事逼得更急了：
依舊是上下文
我看完Shopify的案例后，對(duì)他們?cè)?024年做的兩個(gè)決定印象很深：
把分散的代碼合進(jìn)一個(gè)Monorepo；
用Nix把開(kāi)發(fā)、CI和生產(chǎn)環(huán)境做成可復(fù)現(xiàn)的統(tǒng)一底座。
這兩個(gè)工程都不性感，推進(jìn)時(shí)也不會(huì)討喜。
遷移過(guò)程會(huì)出各種問(wèn)題，CI需要重建，緩存和測(cè)試基礎(chǔ)設(shè)施欠下的債也得一起還。放在以前，這類(lèi)事項(xiàng)大概率會(huì)被歸為重要但不緊急，然后就沒(méi)有然后了...
只不過(guò)，Agent一接入，舊賬立刻全部暴露：
沒(méi)有健全的環(huán)境復(fù)現(xiàn)能力，Agent就無(wú)法驗(yàn)證結(jié)果。
代碼倉(cāng)庫(kù)割裂，Agent就拿不到完整上下文，也看不到一次修改對(duì)其他系統(tǒng)的影響。
業(yè)務(wù)流程沒(méi)人寫(xiě)下來(lái)，新同事學(xué)不會(huì)，Agent同樣猜不對(duì)。
Shopify后來(lái)總結(jié)了一句話：
代碼庫(kù)里那些為了讓Agent讀懂而需要償還的債，其實(shí)就是你一直欠人類(lèi)工程師的債
我覺(jué)得這句話可以貼在每個(gè)CTO的工位上。哦對(duì)了，現(xiàn)在很多公司已經(jīng)沒(méi)有CTO了...
在之前Context Engineering也很容易被理解成往提示詞里塞更多文檔，這其實(shí)也是一種AI Max的路徑，畢竟誰(shuí)還不想偷個(gè)懶。
只不過(guò)，文檔塞得太多，Agent會(huì)注意力渙散、Token爆炸，甚至把早已過(guò)期的規(guī)則當(dāng)成當(dāng)前事實(shí)。
這里不做好管理策略，一堆問(wèn)題就會(huì)冒出來(lái)：
AI操作系統(tǒng)的重要性
當(dāng)Agent數(shù)量增加，管理方式也要變化。
當(dāng)因?yàn)橐m應(yīng)AI而發(fā)展出來(lái)的管理機(jī)制多了后，管理也會(huì)應(yīng)接不暇，畢竟所有事情的背后都是成本??！
什么意思呢？最開(kāi)始，一個(gè)工程師開(kāi)一個(gè)Agent會(huì)話，靠自己的記憶就能盯住任務(wù)。三五個(gè)會(huì)話也能勉強(qiáng)應(yīng)付，等數(shù)量增加到十幾個(gè)，問(wèn)題馬上就來(lái)了：
哪個(gè)任務(wù)正在執(zhí)行？
哪個(gè)任務(wù)卡住了？
哪些代碼還沒(méi)有經(jīng)過(guò)測(cè)試？
哪些操作正在等待人工審批？
失敗以后，應(yīng)該重試還是轉(zhuǎn)交給人？
為了讓Agent穩(wěn)定工作，我們?cè)黾恿薙pec、Rules、Skills、上下文治理、自動(dòng)化測(cè)試、評(píng)測(cè)集、權(quán)限和審批。
這些機(jī)制有用的同時(shí)，卻也帶來(lái)了新的管理成本。
如果每份Spec都要管理者人工檢查，每次執(zhí)行都要工程師盯著，每個(gè)Agent都要手工補(bǔ)充上下文，每次失敗都要人肉整理經(jīng)驗(yàn)，那么團(tuán)隊(duì)很快又會(huì)陷入另一種忙亂。
所以，AI研發(fā)操作系統(tǒng)還要解決一個(gè)很現(xiàn)實(shí)的問(wèn)題：
把為了適應(yīng)AI而增加的管理動(dòng)作，盡量交給系統(tǒng)自動(dòng)執(zhí)行
比如：
Spec缺少驗(yàn)收標(biāo)準(zhǔn)，系統(tǒng)直接拒絕進(jìn)入開(kāi)發(fā)；
Agent根據(jù)項(xiàng)目自動(dòng)加載對(duì)應(yīng)的Rules和Skills；
代碼修改完成后，自動(dòng)運(yùn)行單測(cè)、E2E和安全掃描；
測(cè)試失敗，任務(wù)自動(dòng)退回并附上錯(cuò)誤信息；
高風(fēng)險(xiǎn)操作觸發(fā)人工審批；
任務(wù)結(jié)束后，自動(dòng)生成變更說(shuō)明和驗(yàn)證報(bào)告；
失敗案例進(jìn)入評(píng)測(cè)集，后續(xù)任務(wù)自動(dòng)回歸。
管理沒(méi)有消失，只是被固化進(jìn)了系統(tǒng)。
過(guò)去需要項(xiàng)目經(jīng)理反復(fù)催促、研發(fā)負(fù)責(zé)人人工檢查的事情，開(kāi)始由任務(wù)狀態(tài)、自動(dòng)化規(guī)則和質(zhì)量門(mén)禁完成。
回頭再看River和Symphony，它們的價(jià)值也就更容易理解了。
River把Slack變成統(tǒng)一任務(wù)入口，同時(shí)連接代碼倉(cāng)庫(kù)、測(cè)試系統(tǒng)、數(shù)據(jù)倉(cāng)庫(kù)和線上Trace。
Symphony把Linear變成Agent控制臺(tái)，讓任務(wù)可以自動(dòng)領(lǐng)取、執(zhí)行、測(cè)試，再根據(jù)評(píng)審意見(jiàn)繼續(xù)修改。
它們既在調(diào)度Agent，也在降低人類(lèi)管理Agent的成本。
所以，一套AI研發(fā)操作系統(tǒng)至少要承載三類(lèi)能力：
信息通道：組織需求、代碼、文檔、規(guī)則和歷史決策；
工作流容器：承載工具、Skills、測(cè)試、評(píng)審和部署流程；
控制系統(tǒng)：管理權(quán)限、審批、日志、成本、失敗重試和結(jié)果驗(yàn)收。
一家公司剛開(kāi)始沒(méi)有必要自研River。Linear、Jira、GitHub、GitLab、CI、Sandbox，再加上項(xiàng)目Rules和Skills，已經(jīng)可以拼出一個(gè)最小版本：
判斷的重要性
Anthropic對(duì)約40萬(wàn)次Claude Code Session的研究發(fā)現(xiàn)，典型協(xié)作中，人主要負(fù)責(zé)規(guī)劃，Claude主要負(fù)責(zé)執(zhí)行。
用戶的領(lǐng)域知識(shí)越強(qiáng)，一條指令能夠撬動(dòng)的Agent工作量越大，成功率也越高：
產(chǎn)物變便宜，判斷和決策變貴
這也符合當(dāng)前真實(shí)情況：誰(shuí)都可以生成，不代表誰(shuí)都可以發(fā)布。
架構(gòu)由誰(shuí)負(fù)責(zé)，誰(shuí)能訪問(wèn)生產(chǎn)數(shù)據(jù)，哪些操作需要審批，出了問(wèn)題由誰(shuí)解釋?zhuān)@些邊界必須寫(xiě)清楚。
OpenAI會(huì)把低風(fēng)險(xiǎn)操作放在Sandbox里自動(dòng)執(zhí)行，高風(fēng)險(xiǎn)動(dòng)作交給人審批，身份、憑據(jù)和關(guān)鍵行為全部留下記錄。
管理Agent，需要按照上線生產(chǎn)系統(tǒng)的標(biāo)準(zhǔn)來(lái)。
畢竟它不睡覺(jué)，手速極快，還可能同時(shí)擁有代碼、客戶數(shù)據(jù)和發(fā)布權(quán)限，這人萬(wàn)一不聽(tīng)話，那會(huì)很麻煩！
結(jié)語(yǔ)
上面說(shuō)了很多，但普通研發(fā)團(tuán)隊(duì)沒(méi)有必要開(kāi)局就重做整套體系。
先找一件經(jīng)常發(fā)生、結(jié)果容易判斷的任務(wù)，把輸入、權(quán)限、停止條件和驗(yàn)收標(biāo)準(zhǔn)寫(xiě)清楚，然后跑一遍。
第一輪大概率不會(huì)更快。
你會(huì)發(fā)現(xiàn)文檔過(guò)期、環(huán)境缺失、測(cè)試不足，很多團(tuán)隊(duì)規(guī)則也沒(méi)有寫(xiě)下來(lái)。這些問(wèn)題早就藏在研發(fā)流程里了，Agent只是讓它們提前暴露。
某個(gè)錯(cuò)誤反復(fù)出現(xiàn)，就放進(jìn)自動(dòng)化測(cè)試或評(píng)測(cè)集；某條規(guī)則只有老員工知道，就寫(xiě)進(jìn)項(xiàng)目規(guī)則；能夠自動(dòng)檢查的問(wèn)題，盡量別留到人工評(píng)審階段。
最終衡量的也不該是代碼量、Token消耗和Agent數(shù)量。
任務(wù)多久能夠交付、中間返工幾次、出現(xiàn)多少缺陷、多少任務(wù)需要人接管，這些指標(biāo)更有價(jià)值。
代碼確實(shí)正在變得越來(lái)越便宜，但判斷、邊界和責(zé)任沒(méi)有跟著變少，管理也不會(huì)憑空消失。
AI研發(fā)操作系統(tǒng)要做的，就是承接機(jī)器提速以后新增的復(fù)雜度，讓整條研發(fā)生產(chǎn)線真的快起來(lái)。