AI 編碼工具席卷行業(yè)，“代碼產(chǎn)出提升40%”、“研發(fā)效率翻倍”之類的說法層出不窮。很多團(tuán)隊(duì)一擁而上上 AI 工具，卻發(fā)現(xiàn)代碼越寫越多，交付越來越慢，線上問題反而變多，工程師也更加疲憊。

原文鏈接：https://andrewmurphy.io/blog/if-you-thought-the-speed-of-writing-code-was-your-problem-you-have-bigger-problems

作者 | Andrew Murphy 翻譯 | 鄭麗媛

出品 | CSDN（ID：CSDNnews）

周二早上，工程副總裁（VP）正站在會議室前，展示一份PPT，，興奮得跟 2017 年剛發(fā)現(xiàn)加密貨幣的人一模一樣。他剛從某個(gè)會議或廠商晚宴回來，三杯烈酒下肚、一場AI演示看完，現(xiàn)在帶著“重磅消息”回來了：

“我們要在全團(tuán)隊(duì)推行 AI 編碼助手。初步數(shù)據(jù)顯示代碼產(chǎn)出會提升 40%，這將徹底改變我們的研發(fā)速度?！?/blockquote>

于是，會議室里出現(xiàn)了“經(jīng)典”一幕：一半人點(diǎn)頭附和，另一半人好像突然對自己的筆記本電腦產(chǎn)生了濃厚興趣。至于資深工程師，他們臉上露出了那個(gè)熟悉的表情——你懂的，就是那種在心里盤算：是現(xiàn)在站出來說點(diǎn)什么，還是晚點(diǎn)直接更新 LinkedIn 簡歷算了。

但從始至終，沒人問出那個(gè)最關(guān)鍵的問題：所謂的速度提升，到底是朝著什么目標(biāo)的速度？

事情的本質(zhì)其實(shí)很簡單：這位VP 看了一眼整個(gè)軟件交付流程，找到了一個(gè)本來就很快的環(huán)節(jié)——寫代碼，然后決定讓它更快。

這就像在流水線上，挑了一個(gè)不是瓶頸的工位瘋狂加速，還往里面砸錢。如果你稍微了解一點(diǎn)系統(tǒng)理論，就會知道——這不僅不會讓系統(tǒng)變快，反而會讓一切變得更糟。

1984 年的理論，今天依然適用

1984 年，Eli Goldratt 寫了一本小說——《目標(biāo)（The Goal）》。雖然講的是制造業(yè)，但對軟件工程也離譜地適用。

這本書最核心的思想是約束理論（Theory of Constraints）：

● 每個(gè)系統(tǒng)都有且只有一個(gè)瓶頸

● 整個(gè)系統(tǒng)的吞吐量，由這個(gè)瓶頸決定

● 在解決瓶頸之前，優(yōu)化其他地方毫無意義

很多人理解到這里就停了。但真正關(guān)鍵、也最危險(xiǎn)的一點(diǎn)是：

如果你優(yōu)化的不是瓶頸，你不僅不會得到更快的系統(tǒng)，反而會得到一個(gè)更加“崩潰”的系統(tǒng)。

以流水線舉例就很直觀：A 工位生產(chǎn)得飛快，但 B 工位（瓶頸 ）的處理能力沒變。而你在 A 和 B 之間塞了一堆未完成的任務(wù)，導(dǎo)致工作量暴漲、交付周期變長、B 工位的人被淹沒、優(yōu)先級混亂、質(zhì)量暴跌——因?yàn)樗腥硕荚诿χ熬然稹?，根本沒時(shí)間思考。

結(jié)論就是：你沒有提速，你只是制造了一場“交通堵塞”，然后管它叫“生產(chǎn)力提升”。

真實(shí)噩夢：當(dāng)你把代碼產(chǎn)出“提升 3 倍”之后

我相信，很多人已經(jīng)在經(jīng)歷這一切了。我也經(jīng)歷過，感受就是三個(gè)字：糟透了。

開發(fā)者提交 PR 的速度前所未有地快。嗯，很好，很棒，給你發(fā)個(gè)獎，但然后呢？這些 PR 進(jìn)入 Review 隊(duì)列，而負(fù)責(zé) Review 的人數(shù)并沒有變成 3 倍——VP 看到的那份廠商 PPT 里根本沒提到 Review 這個(gè)問題。

于是 PR 開始積壓：一天、兩天、一周。

然而，開發(fā)者早就被 AI 輔助推著搞下一個(gè)需求了，等 Review 意見回來時(shí)，他看著自己 8 天前寫的代碼，跟看侏羅紀(jì)化石沒區(qū)別：“你能解釋下這個(gè)函數(shù)是干嘛的嗎？”

在這種情況下，Review 開始變成走過場蓋章，因?yàn)閷?shí)在太多，根本沒法認(rèn)真看。有人審批了自己根本沒細(xì)看的 PR（大家都干過吧），然后合并、CI 跑 45 分鐘、不穩(wěn)定用例失敗、重跑、第二次通過。

接著，部署流程需要手動審批，而審批的人正在開“關(guān)于開會的會”。所以功能在測試環(huán)境躺了三天，沒人對“上線”這件事有緊迫感。與此同時(shí)，開發(fā)者又提交了兩個(gè) PR。隊(duì)列越來越長，待辦事項(xiàng)逐漸爆炸，每個(gè)人手里同時(shí)掛著 6 件事，卻沒一件能真正做完，周期時(shí)間（真正衡量你給用戶交付價(jià)值速度的指標(biāo)）反而變得更差。

你產(chǎn)出了更多代碼，卻上線了更少的軟件。明明現(xiàn)狀變得更糟了，儀表盤上卻寫著：生產(chǎn)力提升了40%——而搞出這一切的人，很可能要升職了。

這樣的劇本，我在三家不同公司親眼見過：儀表盤數(shù)據(jù)好看了，上線速度卻變慢了。沒人把兩者關(guān)聯(lián)起來，因?yàn)閮x表盤是給董事會看的，而董事會不懂什么是周期時(shí)間，也沒人愿意做那個(gè)出來解釋真相的人。

而更讓我睡不著的是：很多 AI 生成的代碼，根本沒人能完全懂。

因?yàn)閷懘a的人沒有真正去“寫”，只是提示、 skim、跑一遍。凌晨 2 點(diǎn)線上出Bug時(shí)，值班的人沒寫過，寫提示的人又解釋不了。結(jié)果呢？你只是擴(kuò)大了故障面，同時(shí)減少了能理解系統(tǒng)的人。

顯然，這不是生產(chǎn)力提升，這只是一顆包裝得更好看的“定時(shí)炸彈”。

那么，真正的瓶頸到底在哪？

問題來了：如果寫代碼從來都不是瓶頸，那真正的瓶頸到底在哪？

答案很簡單：順著價(jià)值流走一遍。跟著一個(gè)功能，從“一個(gè)想法”到“用戶真正用到”，我保證你會發(fā)現(xiàn)瓶頸在瘋狂向你招手。

（1）你根本不知道該造什么

這是所有人都羞于談?wù)摰恼嫦啵寒a(chǎn)品經(jīng)理兩個(gè)月沒跟真實(shí)用戶聊過天；需求是 Jira 里三行字加一個(gè) Figma 鏈接，設(shè)計(jì)是從沒用過產(chǎn)品的人拍板的；工程師每天要做 50 個(gè)關(guān)于行為、邊界、異常處理的微決策——因?yàn)楦緵]人定義過，所有人都在猜。

我見過一個(gè)團(tuán)隊(duì)，花了 6 周，根據(jù)銷售在 Slack 里轉(zhuǎn)述的“客戶可能在電話里大概說過”的需求，做了一個(gè)功能，而最后客戶根本沒買。這個(gè)功能只有 11 個(gè)人用過，其中9 個(gè)是內(nèi)部測試。

這不是交付問題，這是“我們到底在干嘛”的問題。

在這種環(huán)境下提升代碼速度，寫得再快，也只是更快地做錯(cuò)事而已。

（2）代碼“寫完”之后的所有事情

我給“寫完”打引號，是因?yàn)樵诖蠖鄶?shù)公司，代碼寫出來可能只占整個(gè)流程的20%。另外 80%，是你的代碼在各種隊(duì)列里等待的時(shí)間。

我見過這樣一種情況：代碼一下午就寫完了，而上線花了兩個(gè)月。代碼本身沒變慢，是代碼周圍的一切在擋路——PR 評審、CI、測試環(huán)境、QA、安全評審、產(chǎn)品驗(yàn)收、發(fā)布窗口、灰度……從開發(fā)者分支到用戶屏幕，是一長串交接、等待、排隊(duì)。

大多數(shù)時(shí)候，你的代碼都一動不動：等人看、等流程跑、等某人點(diǎn)頭放行。

你以為慢的是開發(fā)，其實(shí)真正慢的是“等待”。

（3）發(fā)布恐懼癥

我數(shù)不清有多少團(tuán)隊(duì)都害怕發(fā)布。用例不穩(wěn)定、可觀測性一團(tuán)糟、沒人信灰度流程、上次周四發(fā)布?xì)Я怂腥说闹苣谑撬麄冊趺醋?？把變更攢成更大的包，但更大就更危險(xiǎn)，更危險(xiǎn)就更不敢發(fā)，更不敢發(fā)就攢得更多。

恭喜，你形成了一個(gè)完美的“發(fā)布恐懼循環(huán)”。

現(xiàn)在，還要再加上“更快的代碼產(chǎn)出”：更多代碼，但同樣恐懼發(fā)布的文化，導(dǎo)致包更大、風(fēng)險(xiǎn)更高、發(fā)布更慢——你給一個(gè)本來就不敢上線的團(tuán)隊(duì)，增加了更多不敢上線的理由。

（4）發(fā)布了，但沒人知道有沒有用

這和“不知道造什么”是同一種病，只是在流程另一端。你做了、你上線了，然后…… 沒了。沒有像樣的數(shù)據(jù)分析、沒有上線后的用戶訪談、沒人回頭看這個(gè)功能到底有沒有解決問題。于是，你的下一個(gè)功能繼續(xù)猜。

整個(gè)路線圖就是一連串“有根據(jù)的推測（educated guess）”，中間沒有任何反饋閉環(huán)。

在這種環(huán)境下加快代碼速度，只是讓你“做→上線→無所謂” 的循環(huán)轉(zhuǎn)得更快。你更頻繁地得到 “我們不知道這東西有沒有用”，每次都學(xué)不到任何東西，還莫名其妙把這叫做“速度”。

（5）真正的瓶頸：組織本身

所以，有時(shí)候瓶頸根本不是技術(shù)，而是：

● 要等一個(gè)會才能做決策

● 三個(gè)團(tuán)隊(duì)要定接口契約，但一個(gè)月沒互相聊過

● 架構(gòu)師是所有重大設(shè)計(jì)的唯一審批人，流程至少要積壓兩周

● 季度規(guī)劃要做 6 周，緊急需求要再等 5 周，因?yàn)椤安辉谟?jì)劃里”

我參加過一個(gè)討論會，當(dāng)時(shí)全場都在問 “為什么這個(gè)功能沒上線”，最終答案簡直離譜：“我們在等一個(gè)正在休假的人開會?！?/p>

所以，不是技術(shù)問題，不是代碼問題，是組織結(jié)構(gòu)的問題。我們討論功能的時(shí)間，比寫功能還長，甚至還有人提議：開個(gè)會，討論一下那個(gè)會怎么開——我真希望這只是個(gè)玩笑。

這些是協(xié)作問題、人的問題、政治問題、沒人愿意背鍋的問題。AI 寫代碼更快又怎樣？這對這些問題毫無作用。你的瓶頸在組織架構(gòu)里，再強(qiáng)的 Copilot 也重構(gòu)不了它。

正確但“無聊”的解法

這些方法沒人愿意講，因?yàn)樗鼈儾豢帷⒉?AI、不好賣，但確實(shí)有效。

（1）盤一下你的價(jià)值流

從想法到上線，一步步記下來，每一步耗時(shí)、每兩步之間等待多久。等待的 gap，就是你周期時(shí)間的殺手。過程可能會很抑郁，但還是要做。

（2）關(guān)注周期時(shí)間，而不是代碼量

如果你在統(tǒng)計(jì)代碼行、合并 PR 數(shù)，卻不看從提交到用戶用上要多久，你就是在優(yōu)化錯(cuò)誤指標(biāo)。

（3）消滅等待狀態(tài)

PR 等兩天？做結(jié)對編程、更小 PR、固定評審時(shí)間。發(fā)布要等手動審批？自動化，或至少做成 Slack 按鈕，別總靠會議。決策靠開會？拆成小決策，讓很多決策不需要開會。

（4）少開工，多完工

WIP 限制是有原因的。做完 3 件事，比 10 件事都做到一半要強(qiáng)得多。并行任務(wù)就是切換成本，而優(yōu)秀工程師就是這么慢慢精神內(nèi)耗掉的。

（5）聽一線工程師的

一線工程師早就知道瓶頸在哪，他們每天 standup 在吐槽、還在 Slack 發(fā)梗圖——只是沒人聽。

最后想說的

回到開頭說的那個(gè)周二早上。副總裁站在臺上說“代碼產(chǎn)出提升 40%”，但他真正該說、且真正有用的話應(yīng)該是：

“我們分析了整個(gè)交付流程，發(fā)現(xiàn)功能平均有 9 天在等待。接下來，我們要把它砍半。”

這句話并不酷炫、放不進(jìn)廠商 PPT、做不成產(chǎn)品，也很難成為大會演講題目，但它卻能讓你真正地快速交付。

所以，寫代碼的速度從來都不是你的問題。如果你以為它是，那么這個(gè)“認(rèn)知與現(xiàn)實(shí)的差距”，才是你真正的問題所在。

真正的競爭優(yōu)勢，從不屬于寫代碼最快的團(tuán)隊(duì)，他們反而容易被淹沒在 AI 生成的 PR 隊(duì)列里，而那些能想清楚要造什么、造得出來、并快速交到用戶手里的，才是真正成功的團(tuán)隊(duì)。

【活動分享】“48 小時(shí)，與 50+ 位大廠技術(shù)決策者，共探 AI 落地真路徑。”由 CSDN 與奇點(diǎn)智能研究院聯(lián)合舉辦的「全球機(jī)器學(xué)習(xí)技術(shù)大會」正式升級為「奇點(diǎn)智能技術(shù)大會」。2026 奇點(diǎn)智能技術(shù)大會將于 4 月 17-18 日在上海環(huán)球港凱悅酒店正式召開，大會聚焦大模型技術(shù)演進(jìn)、智能體系統(tǒng)工程、OpenClaw 生態(tài)實(shí)踐及 AI 行業(yè)落地等十二大專題板塊，特邀來自BAT、京東、微軟、小紅書、美團(tuán)等頭部企業(yè)的 50+ 位技術(shù)決策者分享實(shí)戰(zhàn)案例。這不僅是一場技術(shù)的盛宴，更是決策者把握 2026 AI 拐點(diǎn)的戰(zhàn)略機(jī)會。