作者 | Craig Adam

編輯 | 云昭 

一、軟件開發史就像一個鐘擺

在軟件開發的歷史里，鐘擺一直在極端之間來回擺動。

早期，圈里推崇周密的規劃：規格文檔必須寫得一清二楚，架構圖要先畫好，才能寫第一行代碼。任何改動都像在操縱一艘貨輪——緩慢、官僚，附帶厚厚的文檔。

后來敏捷來了。鐘擺迅速擺向另一邊。

圈里又開始追求速度、迭代和“不完美”。“可運行的軟件高于詳盡的文檔”成了口號。上線快，比第一次就做對更重要。敏捷的確帶來了巨大的生產力紅利，徹底改變了軟件文化。

但今天，局面再一次變化。AI 工具可以憑一句話寫出成百上千行代碼。GitHub Copilot、Claude Code 讓“寫代碼”變成了機器的活兒。開發者的身份正在轉變：不再是碼農，而是環境的設計者，是系統的架構師。鐘擺再次擺回，帶著新的含義。

二、氛圍式編程的魔力與陷阱

“Just vibe it”（隨便干就行），這是 Andrej Karpathy 大神在安利氛圍編程時的一句話。一不留神就成了新一代開發方式的縮影。

要一個 React 組件？敲個 prompt！

要一個 API 集成？敲個 prompt！

要一個帶分頁、錯誤處理、加載狀態的 CRUD？一個好 prompt 能幫你完成 80%。

這就是氛圍編程：自然語言提示 + AI 輔助腳手架 + 快速迭代。

而對新人來說，這幾乎就是他們唯一的編程方式。

優勢看起來很明顯：它快、它爽、它省事。它消除了阻力，跳過了樣板代碼，加速了開發。一個下午就能做出原本需要幾天的原型。

然而，伴生的問題也很突出：寫得太快的代碼通常像牛奶而不是紅酒——容易變質。氛圍編程似乎在鼓勵淺層理解，追求眼下能跑通，而忽視半年后的維護。

“架構決策由模型暗中替你做了，模式在無審查中被固化，缺少審查，缺少理解。不久之后，你就陷入生成出來的復雜泥潭里，連上線的人都搞不懂。”

合理使用，氛圍式編程是超能力；魯莽使用，它就是技術債地獄的直達車。

所以，這時候，我們的解決方案不是減速，而是換人來為AI掌舵。

我們需要的不是更多的氛圍碼農，而是能思考 AI 運行環境的人。我們需要的是架構師。

三、架構的回歸：從寫函數轉回設計框架

單個函數的實現正在被自動化，這已經是一個事實。AI 可以在幾秒鐘生成類型良好的 TypeScript resolver、GraphQL schema 或 Flutter widget。

這意味著：開發的戰術層面正在商品化，但戰略層面依舊是人類的游戲。現代開發者不再只是“建造者”，而是“架構師”。不是頭銜上的虛名，而是真實意義上的設計者：負責搭建軟件生成和運行的結構。

這意味著要：

• 策劃庫和工具
• 設定邊界
• 定義模式，讓 AI 生成的代碼能干凈地集成并可持續擴展

未來的開發者價值不在于寫多少代碼，而在于為代碼創造怎樣的生存系統：框架、腳手架、模式和護欄，讓 AI 高效運轉而不制造混亂。

工作不再是比機器寫得更快，而是比機器想得更深。

四、下一代代碼是寫給機器看的

過去，我們寫干凈的代碼、完整的文檔，是為了后來接手的工程師。現在，下一個“讀者”是 AI。它不會提問，只會照著已有的模式繼續寫。于是，好的命名、穩定的抽象、明確的邊界，不僅僅是工程師的習慣，更是機器能否生成可靠代碼的前提。

換句話說，我們寫下的每一行代碼，都是 AI 的“訓練數據”。

五、敏捷之后的新宣言

過去二十年，《敏捷宣言》塑造了團隊構建軟件的方式。它的我們從臃腫的需求文檔和長達 18 個月的瀑布式開發中解放出來。我們不再寫一堆 Word 文檔，而是開始發布最小可行產品（MVP）。那是一次巨大的進步，但我們走得有些過頭了。

敏捷教會我們“重視可工作的軟件，而不是全面的文檔”。這沒錯——直到“可工作的軟件”逐漸被曲解為“只要做完就好”。在氛圍式編程和 AI 輔助提示的時代，這條原則開始瓦解。

因為軟件也許能跑，但它并不總是被真正理解。

現在，隨著 AI 生成的代碼占比越來越高，鐘擺再次擺動。我們正在重新發現那些“舊東西”的價值：文檔、規范、護欄。但原因不同了，并不是因為人類需要它們，而是因為我們的 AI 同事需要。

敏捷的核心價值并沒有失效，但其中一些需要重新解讀。在這個新世界里：

• 我們可能會更重視全面的結構而不是“能跑的軟件”——因為今天能跑、明天就垮的軟件是負債。
• 我們可能會更重視精心策劃的系統而不是“個體與互動”——因為這些“個體”越來越多是機器。
• 我們可能會更重視對上下文的響應而不是“對變化的響應”——因為穩定性和可重復性才是真正支撐快速迭代的基礎，而不是混亂。

當然，這場回歸自然不是要重返繁瑣的流程教條。新的奧義在于：在約束中獲得速度，在架構中獲得自由。

六、開發者新角色：定義新環境

如果你今天是資深開發者或技術負責人，你的角色已經在悄然轉變，即使你的頭銜還沒跟上。

你不再只是寫函數，而是要定義一個環境，讓函數在其中被高效創造。這意味著你要主導架構，制定模式，設計系統，不僅引導人類同事，還要引導越來越多的 AI 協作者。

要在這個新環境中實現有效領導，則需要關注以下幾個方面：

1. 用系統思維，而非代碼片段思維

僅僅會寫代碼已經不夠。你需要學會塑造系統：

• 邊界應該劃在哪里？
• 哪些決策需要一次性定下并固化？
• 哪些抽象能減少未來的重復勞動？

代碼庫的增長速度前所未有。薄弱的結構會導致快速崩塌。

2. 建立護欄，而不僅是功能

制定模式，讓人類和機器都能安全遵循。使用類型、linter、測試套件和 schema，不只是為了保證正確性，更是為了傳遞意圖。

凡是無法自動化強制的，就通過清晰、可重復的結構來約束。要做的是框架，而不僅是庫。

3. 像庫管理員一樣整理示例

AI 工具依賴模式識別。好的示例帶來好的輸出，壞的示例只會放大混亂。

代碼庫就是新的學習環境。保持整潔！去除互相矛盾的風格。在重要的地方記錄意圖。把它當成訓練數據來打理——某種程度上，它的確就是。

4. 掌控評審層

AI 可以生成可用的代碼。但它不能（至少現在還不能）做出深思熟慮的架構取舍。

這是你的責任。評審時不僅要看正確性，還要看整體一致性。關注那些可能導致長期復雜度的模式。做質量的策展人，而不僅是 Bug 的把關人。

5. 不要做“天才型開發者”

最聰明的人不是解決最多問題的人，而是能防止問題發生的人。

在這個語境下，領導力意味著打造能超越個人能力規模的系統。意味著把判斷力編碼進系統里，而不是鎖在自己的腦子里。

七、記住：下一代coder是機器，而不是人

沒錯，敏捷時代，的確讓編程界學會了快跑。但進入 AI 時代，挑戰已經變成了，找對方向。

未來的軟件注定不再是由人類“寫出來”，而是由人“設計出來”的。

這時候，速度依然重要，但更重要的是方向、結構和原則。

所以，編程宣言的奧義可能要變成這樣：快，但要聰明。

而且，有一點一定要清楚：之后的代碼不再是寫給人看的，是給努力理解你意圖的機器用的。

本文轉載自??51CTO技術棧??，作者：云昭