谷歌工程師用1984年小說打臉AI編程：3倍速寫代碼后，團隊崩了

2024年，某大廠內部數據顯示：接入AI輔助編程工具后，開發者日均代碼產出增長340%。三個月后，該團隊交付周期反而延長了22%。

這不是孤例。全球超過60%的科技公司正在重復同一套劇本——用AI給非瓶頸環節加速，然后看著系統整體窒息。

「三杯紅酒后的決策」

周二早晨，工程VP站在投影前，渾身散發著2017年幣圈早期玩家那種亢奮。剛參加完一場 vendor dinner，三杯黑皮諾加一個demo，他帶著「重大發現」回來了。

會議室里一半人點頭，另一半突然對筆記本電腦產生濃厚興趣。資深工程師面無表情，心里盤算著：現在反駁，還是稍后更新領英。

沒人問那個關鍵問題：速度，朝向哪里？

VP審視了整個軟件交付體系，找到那個本來就已經很快的環節，決定讓它更快。他在流水線上發現了一個不是瓶頸的工位，然后往里面砸錢。

懂系統的人都知道，這不僅沒用，會讓一切變得更糟。

一本制造業小說的詛咒

1984年，Eli Goldratt寫了《目標》——一部關于制造業的小說，莫名其妙地對軟件行業極具殺傷力。這也是你讀過的最有用的商業書籍，盡管它技術上算虛構。這幾乎與大多數KPI框架完全相反。

核心概念是約束理論（Theory of Constraints）：

每個系統有且僅有一個約束。一個瓶頸。整個系統的吞吐量由該瓶頸的吞吐量決定。在修復瓶頸之前，其他一切都不重要。

大部分人理解到這里。他們沒理解的部分，才真的可怕：

機械地思考這個問題。如果A工位生產小部件更快，但B工位（瓶頸）的處理速度不變，你只是在A和B之間制造了一堆未完成的小部件。庫存上升。交付周期上升。B工位的人現在被淹沒。堆積造成混亂，沒人知道下一步該做什么。質量暴跌，因為所有人都在救火，而不是思考。

我猜你們中有人正在經歷這個。我經歷過。糟透了。

PR隊列里的尸體

你的開發者產出PR的速度前所未有。太好了。太棒了。金星貼紙。誰去把彩帶炮拿來。

現在這些PR涌進審查隊列，而你的審查員沒有變成三倍。沒人給審查員變成三倍。甚至沒人想過審查員，因為vendor的slide deck里沒提審查員。

于是PR開始積壓。一天。兩天。一周。作者已經上下文切換到下一個AI輔助功能，等審查意見回來時，他們幾乎不記得第一個功能是干什么的。「你能解釋一下這個函數是做什么的嗎？」他們盯著自己八天前寫的代碼，像在看陌生人的日記。

上下文切換成本被低估了。微軟研究院2019年的一項研究發現，開發者每次中斷后需要平均23分鐘才能恢復深度工作狀態。AI讓編碼速度提升3倍，但審查瓶頸讓中斷頻率提升了5倍。

凈收益為負。但儀表盤上只顯示「代碼行數增長」，所以VP繼續舉杯。

被無視的約束清單

代碼審查只是冰山一角。在大多數組織中，真正的瓶頸藏在PPT不會展示的地方：

需求清晰度。產品經理用AI一天生成50份PRD，開發團隊花三天搞清楚「智能優化」到底指什么。

測試環境。代碼編譯從20分鐘降到2分鐘，但 staging 環境排隊從1小時變成4小時，因為基礎設施團隊沒收到AI預算。

決策延遲。技術方案評審會每周一次，AI輔助開發的特性三天就寫完，然后等四天等架構委員會的空檔。

認知負載。開發者同時維護的代碼庫數量從3個變成7個，因為「AI能幫你快速上手」。沒人統計過跨項目切換導致的bug增長率。

Goldratt在《目標》里寫過一個場景：工廠老板拼命優化每臺機器的利用率，結果庫存爆炸、現金流斷裂。四十年后，軟件行業的「機器利用率」叫「開發者代碼產出」，庫存叫「待合并PR」，現金流叫「交付周期」。

劇本沒變，只是演員換了。

那些提前醒來的團隊

并非所有人都在撞南墻。GitLab 2023年公開了內部轉型數據：在引入AI編碼助手前，他們先花了八個月重構審查流程——并行審查機制、自動分配算法、審查時間SLA。AI工具上線后，端到端交付周期縮短31%。

順序很重要。約束理論的第一步是識別瓶頸，不是加速非瓶頸。

Shopify的做法更極端。他們的「開發者體驗」團隊被賦予否決權：任何新工具上線前，必須證明它不會加劇現有瓶頸。2024年初，他們否決了三個AI代碼生成工具的采購申請，理由是「審查和測試基礎設施未就緒」。六個月后，競爭對手在社交媒體上炫耀「AI代碼占比90%」時，Shopify默默完成了瓶頸擴容，然后一次性接入。

這種克制在財報電話會上很難解釋。「我們為什么比對手晚半年用AI？」但CEO Harley Finkelstein在內部備忘錄里寫：「我寧愿解釋為什么慢，也不愿解釋為什么崩。」

儀表盤上的幻覺

問題是，瓶頸很難在儀表盤上顯形。

代碼行數、提交頻率、AI生成占比——這些數字漂亮、即時、可橫向比較。審查等待時間、上下文切換成本、決策隊列長度——這些需要人工埋點、跨系統關聯、長期追蹤。

于是組織自然選擇優化前者。這不是惡意，是結構性懶惰。

一位前Google工程總監在離職博客中寫道：「我們花了兩年讓AI寫代碼更快，最后發現交付延遲的80%來自『等待某人做決定』。那個『某人』通常是我。而我當時正在看AI寫代碼的進度報告。」

他用了個類比：給汽車引擎加裝渦輪增壓，但輪胎還是自行車胎。速度表指針會動，車不會快，只會更危險。

速度崇拜的代價

軟件行業對速度的執念有其歷史根源。2001年敏捷宣言、2010年代持續交付運動、2020年代DevOps文化——每一波都在強化同一敘事：更快就是更好。

這個敘事在約束存在且被解決時成立。當它被無視時，「更快」變成局部優化，系統整體受損。

制造業在1980年代學過這一課。日本豐田生產方式的精髓不是「快」，而是「流動」——識別瓶頸、保護瓶頸、逐步擴容。Goldratt把這套邏輯抽象成通用理論，四十年后，軟件行業正在重新發明輪子，只是這次輪子是AI生成的，還沒經過測試。

一個諷刺的細節：許多推廣AI編程工具的公司，內部并不用這些工具開發自己的核心系統。不是因為他們知道約束理論，而是因為他們的核心系統已經夠脆了，經不起再堆一層未完成 inventory。

如果你正在評估AI工具

幾個具體的問題，比「能提升多少代碼產出」更重要：

你的審查隊列當前平均等待多久？接入AI后，這個數字會如何變化？

開發者同時維護的項目數量是多少？AI降低的「上手成本」會誘導這個數字上升嗎？

從「代碼寫完」到「生產環境運行」，哪個環節耗時最長？AI工具作用于這個環節之前還是之后？

如果AI讓編碼速度提升X倍，你的瓶頸環節能在多長時間內擴容到匹配？擴容成本是多少？

這些問題的答案不會出現在vendor的slide deck里。它們需要你走出會議室，去工位旁邊看PR隊列的長度，去統計staging環境的排隊時間，去追蹤一個需求從提出到上線的全路徑。

Goldratt在《目標》結尾讓主角意識到：「 throughput 不是機器運轉的速度，是賣出去的產品數量。」對軟件而言，不是代碼產出的速度，是價值交付的速度。而價值交付的速度，由最慢的環節決定。

那個環節，此刻正在你組織的某個角落堆積 inventory，等待被看見。

你的儀表盤上，有它的實時數據嗎？