AI 能寫百萬行代碼以后，軟件工程的瓶頸變成了什么？

Cursor團隊的GPT-5.2多智能體實驗暴露了比代碼生成更致命的瓶頸：任務拆解、責任歸屬與協同機制正成為新戰場。這場持續數周的工程馬拉松不僅揭示了Agent協作的7個反直覺陷阱，更預示著未來工程師的核心價值將從編碼轉向系統設計。

———— / BEGIN / ————

前幾天，Cursor 的CEO Michael Truell 在社交媒體上提到：他們讓一套由 GPT-5.2 驅動的系統連續跑了一周，產出數百萬行代碼、數千個文件的瀏覽器相關代碼庫。

這聽起來像產品發布，但更準確地說，它是一場工程實驗：Cursor 團隊想驗證的不是 AI 會不會寫代碼，而是當 AI 可以同時并發、持續運行數周以后，大型軟件項目的瓶頸到底在哪里。

Cursor 在自己的播客里也發布了相關內容，詳述了他們如何在一個項目上同時運行數百個并發 Agent，觀察它們如何寫出超過百萬行代碼、如何在長時間運行里保持推進。

具體怎么做到的？

關鍵不在模型，而在組織。

如果你把這件事理解成模型變強了，所以能寫更多代碼，那會錯過最關鍵的部分。

Cursor 博客里講得非常工程化：他們真正遇到的麻煩不是寫不出來，而是多 Agent 協作時的協調成本，這也恰恰是現實軟件團隊最熟悉、也最難優化的那部分。

一開始他們走的是“扁平自治”的直覺方案：所有 agent 地位平等，共享一個文件來認領任務、更新狀態。為了防止搶同一個任務，他們加了鎖。

結果很快翻車：agent 會持鎖太久甚至忘了釋放；系統吞吐量會從 20個agent退化成 2-3個agent 的有效速度；更糟的是系統脆弱，agent 失敗時可能帶著鎖一起掛，甚至出現不拿鎖就寫入協調文件的混亂情況。

之后，他們改用“樂觀并發控制”，讓讀取自由、寫入沖突就失敗。

這確實更健壯，但更深層的問題仍然存在：沒有層級結構時，agent 會變得非常規避風險，它們會回避困難任務，去做“小而安全”的修改；沒人承擔端到端責任，于是看起來很忙，實際在空轉。

真正讓系統開始像團隊一樣工作的，是他們把扁平結構拆成了一條職責清晰的流水線：

• 規劃者：持續探索代碼庫、拆任務，還可以派生子規劃者，讓規劃本身也能并行、遞歸展開；

• 執行者：只負責把領到的任務做完、提交變更，不需要關心全局，也不與其他執行者協調；

• 評審：每個周期結束判斷是否繼續，然后下一輪從干凈的初始狀態重新開始，用這種方式對抗長期運行的漂移和視野變窄。

這一段是原文的核心方法論：它基本解決了協同問題，能把系統擴展到非常大的項目，同時避免單個 agent 越跑越鉆牛角尖。

更有意思的是他們的經驗總結：很多改進來自減法而不是加法。

例如他們曾設計過集成者專門做質量控制和沖突解決，后來發現它制造的瓶頸多于解決的問題：執行者本身就能處理不少沖突。

以及一個非常務實、但經常被忽視的結論：在長時間任務里，系統行為很大程度取決于提示詞怎么寫，框架和模型重要，但提示詞更重要。

同時，多智能體協同仍然很難，系統還需要定期從頭重啟來對抗漂移。

這說明了什么？軟件工程的瓶頸正在“遷移”

如果把這次實驗拆開看，它其實在把一個舊問題換個問法：未來軟件工程的瓶頸，可能從寫代碼的“人力”轉移到“如何組織大量自動化執行體”。

過去的瓶頸是：工程師數量、團隊協作成本、代碼評審節奏。

這次 Cursor 的實驗，把新瓶頸至少推到了四個位置：

第一，任務拆分與責任歸屬，比寫代碼更稀缺。

扁平結構下 agent 傾向做安全小改動，本質上就是沒人對最終結果負責。

你會發現，這和現實團隊里沒人愿意背鍋的大需求一模一樣。Cursor 最終用 規劃者/執行者/評審的結構，把責任重新壓實。

第二，協調機制與吞吐量，決定了并發到底是乘法還是內耗。

鎖把系統拖慢、讓并發退化；樂觀并發更健壯但仍然會空轉。

換句話說，當你有上百個 agent 時，工程效率不再取決于一個人寫得多快，而取決于組織系統有沒有把沖突和等待壓到最低。

第三，長期運行的漂移是常態，復位機制是必需品。

在長任務里，agent 會偏航、會視野變窄，所以他們明確寫到仍需要定期從頭重啟，并用評審把迭代切成周期來對抗漂移。

第四，驗收與可驗證性，會成為比產出代碼更關鍵的成本中心。

百萬行代碼的價值，不在于寫出來，而在于能不能穩定跑、能不能被復現、能不能被維護。

這也是外界討論最集中的點：這到底算不算做出了瀏覽器？

你可能關心：這個瀏覽器真的能跑起來嗎？

先說結論：它能跑，但更多是“能動起來”，離“能用起來”還差一大截。

原因很簡單，大家討論的“能不能跑”其實不是一件事。

第一層是“有沒有實物”，有。Cursor 把代碼放出來了，說明這不是口嗨。

第二層是“能不能當產品用”，暫時不行。這類原型離穩定性、兼容性、性能、安全性都很遠，還談不上日常可用。

第三層才是你真正關心的：能不能打開網頁。更接近“能渲染一些簡單頁面”，但覆蓋范圍有限、問題也不少，所以它更像一次工程實驗，而不是一個可替代 Chrome 的瀏覽器發布。

其實 Cursor 這件事最值得看的，不是瀏覽器做沒做出來，而是它把一個趨勢擺到了臺面上：

當 AI 可以很便宜地寫出海量代碼后，軟件工程的關鍵不再是“寫”，而是怎么組織、怎么驗收、怎么讓系統持續朝著正確方向推進。

最后我想說的是，今天的 AI 還做不到把復雜系統做成產品，但它已經能把復雜系統推到一個可運行的原型。

接下來真正決定分水嶺的，不是代碼量，而是誰能把長期協作、質量控制、可復現交付這套工程體系也一起自動化，那才是 AI 把軟件生產方式改寫的開始。

本文來自公眾號：Fun AI Everyday 作者：張艾拉

想要第一時間了解行業動態、面試技巧、商業知識等等等？加入產品經理進化營，跟優秀的產品人一起交流成長！