AI 編碼工具席卷行業(yè)，“代碼產(chǎn)出提升40%”、“研發(fā)效率翻倍”之類的說法層出不窮。很多團隊一擁而上上 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)加密貨幣的人一模一樣。他剛從某個會議或廠商晚宴回來，三杯烈酒下肚、一場AI演示看完，現(xiàn)在帶著“重磅消息”回來了：

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

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

但從始至終，沒人問出那個最關鍵的問題：所謂的速度提升，到底是朝著什么目標的速度？

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

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

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

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

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

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

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

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

很多人理解到這里就停了。但真正關鍵、也最危險的一點是：

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

以流水線舉例就很直觀：A 工位生產(chǎn)得飛快，但 B 工位（瓶頸 ）的處理能力沒變。而你在 A 和 B 之間塞了一堆未完成的任務，導致工作量暴漲、交付周期變長、B 工位的人被淹沒、優(yōu)先級混亂、質(zhì)量暴跌——因為所有人都在忙著“救火”，根本沒時間思考。

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

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

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

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

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

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

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

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

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

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

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

因為寫代碼的人沒有真正去“寫”，只是提示、 skim、跑一遍。凌晨 2 點線上出Bug時，值班的人沒寫過，寫提示的人又解釋不了。結果呢？你只是擴大了故障面，同時減少了能理解系統(tǒng)的人。

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

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

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

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

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

這是所有人都羞于談論的真相：產(chǎn)品經(jīng)理兩個月沒跟真實用戶聊過天；需求是 Jira 里三行字加一個 Figma 鏈接，設計是從沒用過產(chǎn)品的人拍板的；工程師每天要做 50 個關于行為、邊界、異常處理的微決策——因為根本沒人定義過，所有人都在猜。

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

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

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

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

我給“寫完”打引號，是因為在大多數(shù)公司，代碼寫出來可能只占整個流程的20%。另外 80%，是你的代碼在各種隊列里等待的時間。

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

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

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

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

我數(shù)不清有多少團隊都害怕發(fā)布。用例不穩(wěn)定、可觀測性一團糟、沒人信灰度流程、上次周四發(fā)布毀了所有人的周末……于是他們怎么做？把變更攢成更大的包，但更大就更危險，更危險就更不敢發(fā)，更不敢發(fā)就攢得更多。

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

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

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

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

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

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

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

所以，有時候瓶頸根本不是技術，而是：

● 要等一個會才能做決策

● 三個團隊要定接口契約，但一個月沒互相聊過

● 架構師是所有重大設計的唯一審批人，流程至少要積壓兩周

● 季度規(guī)劃要做 6 周，緊急需求要再等 5 周，因為“不在計劃里”

我參加過一個討論會，當時全場都在問 “為什么這個功能沒上線”，最終答案簡直離譜：“我們在等一個正在休假的人開會。”

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

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

正確但“無聊”的解法

這些方法沒人愿意講，因為它們不酷、不 AI、不好賣，但確實有效。

（1）盤一下你的價值流

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

（2）關注周期時間，而不是代碼量

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

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

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

（4）少開工，多完工

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

（5）聽一線工程師的

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

最后想說的

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

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

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

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

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

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