老鳥談軟件開發(fā)歷史：氛圍編程時代，速度不再是第一位了！而是更聰明的框架設計！ 原創(chuàng)
作者 | Craig Adam
編輯 | 云昭
一、軟件開發(fā)史就像一個鐘擺
在軟件開發(fā)的歷史里，鐘擺一直在極端之間來回擺動。
早期，圈里推崇周密的規(guī)劃：規(guī)格文檔必須寫得一清二楚，架構(gòu)圖要先畫好，才能寫第一行代碼。任何改動都像在操縱一艘貨輪——緩慢、官僚，附帶厚厚的文檔。
后來敏捷來了。鐘擺迅速擺向另一邊。
圈里又開始追求速度、迭代和“不完美”。“可運行的軟件高于詳盡的文檔”成了口號。上線快，比第一次就做對更重要。敏捷的確帶來了巨大的生產(chǎn)力紅利，徹底改變了軟件文化。
但今天，局面再一次變化。AI 工具可以憑一句話寫出成百上千行代碼。GitHub Copilot、Claude Code 讓“寫代碼”變成了機器的活兒。開發(fā)者的身份正在轉(zhuǎn)變：不再是碼農(nóng)，而是環(huán)境的設計者，是系統(tǒng)的架構(gòu)師。鐘擺再次擺回，帶著新的含義。
二、氛圍式編程的魔力與陷阱
“Just vibe it”（隨便干就行），這是 Andrej Karpathy 大神在安利氛圍編程時的一句話。一不留神就成了新一代開發(fā)方式的縮影。
要一個 React 組件？敲個 prompt！
要一個 API 集成？敲個 prompt！
要一個帶分頁、錯誤處理、加載狀態(tài)的 CRUD？一個好 prompt 能幫你完成 80%。
這就是氛圍編程：自然語言提示 + AI 輔助腳手架 + 快速迭代。
而對新人來說，這幾乎就是他們唯一的編程方式。
優(yōu)勢看起來很明顯：它快、它爽、它省事。它消除了阻力，跳過了樣板代碼，加速了開發(fā)。一個下午就能做出原本需要幾天的原型。
然而，伴生的問題也很突出：寫得太快的代碼通常像牛奶而不是紅酒——容易變質(zhì)。氛圍編程似乎在鼓勵淺層理解，追求眼下能跑通，而忽視半年后的維護。
“架構(gòu)決策由模型暗中替你做了，模式在無審查中被固化，缺少審查，缺少理解。不久之后，你就陷入生成出來的復雜泥潭里，連上線的人都搞不懂?！?/p>
合理使用，氛圍式編程是超能力；魯莽使用，它就是技術債地獄的直達車。
所以，這時候，我們的解決方案不是減速，而是換人來為AI掌舵。
我們需要的不是更多的氛圍碼農(nóng)，而是能思考 AI 運行環(huán)境的人。我們需要的是架構(gòu)師。
三、架構(gòu)的回歸：從寫函數(shù)轉(zhuǎn)回設計框架
單個函數(shù)的實現(xiàn)正在被自動化，這已經(jīng)是一個事實。AI 可以在幾秒鐘生成類型良好的 TypeScript resolver、GraphQL schema 或 Flutter widget。
這意味著：開發(fā)的戰(zhàn)術層面正在商品化，但戰(zhàn)略層面依舊是人類的游戲。現(xiàn)代開發(fā)者不再只是“建造者”，而是“架構(gòu)師”。不是頭銜上的虛名，而是真實意義上的設計者：負責搭建軟件生成和運行的結(jié)構(gòu)。
這意味著要：
- 策劃庫和工具
- 設定邊界
- 定義模式，讓 AI 生成的代碼能干凈地集成并可持續(xù)擴展
未來的開發(fā)者價值不在于寫多少代碼，而在于為代碼創(chuàng)造怎樣的生存系統(tǒng)：框架、腳手架、模式和護欄，讓 AI 高效運轉(zhuǎn)而不制造混亂。
工作不再是比機器寫得更快，而是比機器想得更深。
四、下一代代碼是寫給機器看的
過去，我們寫干凈的代碼、完整的文檔，是為了后來接手的工程師?，F(xiàn)在，下一個“讀者”是 AI。它不會提問，只會照著已有的模式繼續(xù)寫。于是，好的命名、穩(wěn)定的抽象、明確的邊界，不僅僅是工程師的習慣，更是機器能否生成可靠代碼的前提。
換句話說，我們寫下的每一行代碼，都是 AI 的“訓練數(shù)據(jù)”。
五、敏捷之后的新宣言
過去二十年，《敏捷宣言》塑造了團隊構(gòu)建軟件的方式。它的我們從臃腫的需求文檔和長達 18 個月的瀑布式開發(fā)中解放出來。我們不再寫一堆 Word 文檔，而是開始發(fā)布最小可行產(chǎn)品（MVP）。那是一次巨大的進步，但我們走得有些過頭了。
敏捷教會我們“重視可工作的軟件，而不是全面的文檔”。這沒錯——直到“可工作的軟件”逐漸被曲解為“只要做完就好”。在氛圍式編程和 AI 輔助提示的時代，這條原則開始瓦解。
因為軟件也許能跑，但它并不總是被真正理解。
現(xiàn)在，隨著 AI 生成的代碼占比越來越高，鐘擺再次擺動。我們正在重新發(fā)現(xiàn)那些“舊東西”的價值：文檔、規(guī)范、護欄。但原因不同了，并不是因為人類需要它們，而是因為我們的 AI 同事需要。
敏捷的核心價值并沒有失效，但其中一些需要重新解讀。在這個新世界里：
- 我們可能會更重視全面的結(jié)構(gòu)而不是“能跑的軟件”——因為今天能跑、明天就垮的軟件是負債。
- 我們可能會更重視精心策劃的系統(tǒng)而不是“個體與互動”——因為這些“個體”越來越多是機器。
- 我們可能會更重視對上下文的響應而不是“對變化的響應”——因為穩(wěn)定性和可重復性才是真正支撐快速迭代的基礎，而不是混亂。
當然，這場回歸自然不是要重返繁瑣的流程教條。新的奧義在于：在約束中獲得速度，在架構(gòu)中獲得自由。
六、開發(fā)者新角色：定義新環(huán)境
如果你今天是資深開發(fā)者或技術負責人，你的角色已經(jīng)在悄然轉(zhuǎn)變，即使你的頭銜還沒跟上。
你不再只是寫函數(shù)，而是要定義一個環(huán)境，讓函數(shù)在其中被高效創(chuàng)造。這意味著你要主導架構(gòu)，制定模式，設計系統(tǒng)，不僅引導人類同事，還要引導越來越多的 AI 協(xié)作者。
要在這個新環(huán)境中實現(xiàn)有效領導，則需要關注以下幾個方面：
1. 用系統(tǒng)思維，而非代碼片段思維
僅僅會寫代碼已經(jīng)不夠。你需要學會塑造系統(tǒng)：
- 邊界應該劃在哪里？
- 哪些決策需要一次性定下并固化？
- 哪些抽象能減少未來的重復勞動？
代碼庫的增長速度前所未有。薄弱的結(jié)構(gòu)會導致快速崩塌。
2. 建立護欄，而不僅是功能
制定模式，讓人類和機器都能安全遵循。使用類型、linter、測試套件和 schema，不只是為了保證正確性，更是為了傳遞意圖。
凡是無法自動化強制的，就通過清晰、可重復的結(jié)構(gòu)來約束。要做的是框架，而不僅是庫。
3. 像庫管理員一樣整理示例
AI 工具依賴模式識別。好的示例帶來好的輸出，壞的示例只會放大混亂。
代碼庫就是新的學習環(huán)境。保持整潔！去除互相矛盾的風格。在重要的地方記錄意圖。把它當成訓練數(shù)據(jù)來打理——某種程度上，它的確就是。
4. 掌控評審層
AI 可以生成可用的代碼。但它不能（至少現(xiàn)在還不能）做出深思熟慮的架構(gòu)取舍。
這是你的責任。評審時不僅要看正確性，還要看整體一致性。關注那些可能導致長期復雜度的模式。做質(zhì)量的策展人，而不僅是 Bug 的把關人。
5. 不要做“天才型開發(fā)者”
最聰明的人不是解決最多問題的人，而是能防止問題發(fā)生的人。
在這個語境下，領導力意味著打造能超越個人能力規(guī)模的系統(tǒng)。意味著把判斷力編碼進系統(tǒng)里，而不是鎖在自己的腦子里。
七、記?。合乱淮鷆oder是機器，而不是人
沒錯，敏捷時代，的確讓編程界學會了快跑。但進入 AI 時代，挑戰(zhàn)已經(jīng)變成了，找對方向。
未來的軟件注定不再是由人類“寫出來”，而是由人“設計出來”的。
這時候，速度依然重要，但更重要的是方向、結(jié)構(gòu)和原則。
所以，編程宣言的奧義可能要變成這樣：快，但要聰明。
而且，有一點一定要清楚：之后的代碼不再是寫給人看的，是給努力理解你意圖的機器用的。
本文轉(zhuǎn)載自??51CTO技術棧??，作者：云昭
