AI 編程正在終結框架時代

作者 | Alain

譯者 | 平川

策劃 | Tina

本文最初發布于 Alain 的個人博客。

我不經常發表博文。當我這么做時，是因為我覺得還沒大有人把我注意到的事情說出來。

我一直在從頭開始構建一個產品。不是那種“我啟動了一個 Next.js 模板”的從頭開始。我的意思是從網絡配置到產品設計再到定價決策。真正的端到端。我一直在使用比較前沿的模型和編碼代理，每天花費數小時，無論是在這個項目上還是在我的全職工作中。我一直在努力遠離混亂和炒作，努力篩選出真正有價值的東西。

自 2025 年 12 月以來，事情戲劇性地變好了。許多人都注意到了，但很少有人得出過正確的結論。

自動化編程

Antirez 喜歡稱之為“自動化編程”，我真的很喜歡這種表述。與“氛圍編碼”這個膚淺、幾乎帶有輕蔑意味的標簽相比，它更能抓住本質。在人類歷史上，自動化一直是大多數工作和文化革命的核心所在。印刷機、織布機、裝配線，這一次并沒有太大的不同。

我的大部分工作還是那樣。對于我想要構建的東西，我仍然需要深入地思考每一個重要的方面——架構、權衡、產品決策、凌晨 3 點反復思考的邊緣情況。消失不見的是那些需要逐行敲擊代碼的令人精疲力竭的繁重體力勞動。

這個時候，在一個干凈且經過良好設置的環境中，模型和工具確實可以帶來差異。我能成為建筑師，卻不必親手砌每塊磚、抹每道灰。我能設計禮服，卻不必裁剪縫制每片布料。但這一切都源于二十年來親手砌磚抹灰、裁剪縫紉的經驗積淀。但如果遇到不合心意的地方，我也可以深入其中，洞悉本質，隨心修正，并永久性地調整系統設置，讓它下次按我的意愿行事。

尤其是，自動化編程讓我可以快速構建我需要的工具，曾經存在于這個地球上的每一名鐵匠都會非常地羨慕我。終于能夠真正地專注于他們認為重要的事情了。終于能夠將更多的時間投入到他們構想的藝術創作中，而不是鍛造間的汗水中。

頓悟

這個念頭在我的腦海中已經醞釀數月之久。它如此清晰明了，以至于我真心不明白為何世人都不向全世界吶喊宣傳。

我們終于可以擺脫所有那些中間層工作了。這些年來，我們盲目接受的那層垃圾。大量的框架、庫和工具，徹底污染了軟件工程，特別是在 Web、移動和桌面開發中。抽象層層堆疊，用沒有意義的抽象解決了本不應該有的問題，每解決一個問題，卻創造了十個新問題。

想想發生的一切。作為一個行業，在看到了構建軟件的真實復雜性之后，我們沒有磨礪我們的思維，而是購買了別人的思維。我們用框架封裝一切，就像用絲綢包裹一條斷腿。看起來不錯，但腿還是斷的。

框架解決（或聲稱解決）的三個問題

在我看來，除了框架自稱的目標之外，它們還解決了三個問題：兩個明確的和一個明顯但從未聲明過的。

“簡化”。軟件工程師害怕自己設計東西。他們寧愿接受別人的結構，盡管不得不強行適配到他們的產品中，也不愿花時間從目標出發，倒推設計出完美契合自己理念的解決方案。就像一個建筑師盲目接受另一個建筑師的藍圖，不管環境、需求、地形、新的技術可能性如何，拿來就用。為了所謂的消除復雜性，我們決定購買一種適合所有人的設計并到處應用。這不是簡化。這是投機取巧。

自動化。實際上，這是我或多或少能夠理解并接受的唯一一點。編寫樣板代碼是件無聊的工作。我討厭那項工作。我尤其討厭使用那些需要我專門研究、持續更新、時刻警惕漏洞的庫，僅僅是為了避免重復編寫那些不可或缺的代碼。想想 ORM、CRUD 管理、代碼生成、API 文檔，等等。那些沒有人想做但每個人都需要完成的苦差事。說得有道理。不過先別急著下結論，因為正是從這一刻起，一切都將改變。

勞動力成本。這是從未聲明過的那一點。沒有人把它放在會議幻燈片上。對于企業來說，讓谷歌、Meta、Vercel 幫你決定如何構建產品和發布代碼要好得多。采用他們的框架，支付供應商鎖定的成本。為他們的云管理解決方案所吸引，用于托管、部署、存儲你的東西。你解鎖了一個與工程無關的功能：你不再需要雇傭軟件工程師。你雇傭一個 React 開發者，不需要培訓，即插即用，易于替換。一個由別人設計的機器中的齒輪，維護由別人架構的系統，解決由別人定義的問題。這不是工程。這是運營。

軟件工程回來了

在我看來，真正的軟件工程又回來了。

我這么說并不是空穴來風。我已經用這種方式開發了兩年多，幾乎無懈可擊。但真正的革命顯然是去年發生的，自 2025 年 12 月以來，對于任何關注過的人來說，這一點都顯而易見。從現在起，這一點將更加明顯。

我們再次獲得了一個機會，讓我們可以擺脫無用的復雜性，繼續致力于我們的想法、特性和產品中那些真正受歡迎的復雜性。那些重要的復雜性，那些真正屬于你的復雜性。

自動化和樣板代碼的挑戰從未如此廉價地被克服。基本上，同樣的代碼行我從未寫過兩次。我立即就可以構建我需要的小工具，有目的地構建，完全圍繞手頭正在處理的問題。我不需要任何花哨的單庫管理器。對于我 99% 的用例，一個簡單的 Makefile 就可以滿足全部需求。當事情變得非常復雜時，如果真的變得非常復雜，我會考慮的。但也只有在那時，不會提前一秒。這就是工程。你解決你手頭的問題，而不是某個人在會議上告訴你你最終會有的問題。

在基本工具方面，編碼代理做了非常好的準備。這些工具已經存在了幾十年，而不僅僅是幾個月。Bash 誕生于 1989 年，比我出生早兩個月。現在運行的最平庸的模型也比世界上任何人都更了解 Bash。Bash 是通用適配器。編碼代理從復雜昂貴的 MCP 配置轉向采用以 Bash 為交互方式的簡單代理循環，這絕非偶然。最古老的工具反而展現出最強的未來適應性。其中蘊含的啟示值得你認真領會。

想想吧

真的想想吧。

對于你能想到的大多數用例，為什么你需要一個無用、昂貴、有缺陷而且往往容易受到攻擊的框架，而對于那些相伴而來的庫，你可能只用了其中 10% 的功能？還有與之相關的所有成本。從“最不”昂貴的運營成本（比如保持所有庫及時更新，因為他們再次在你使用的 Next.js 版本中發現了一個關鍵漏洞）到最昂貴的設計選擇成本——無形的成本，你每天都在支付卻沒有意識到，因為你已經支付了這么久，忘記了自由的感覺。

如果你繼續接受這種權衡，則不僅將錯失軟件工程領域數十年來最大的機遇，還可能無法察覺自己的惰性而再次選擇盲從超大規模云服務商為你做的決策。你正讓谷歌、Meta 和 Vercel 成為你的架構師、設計師和思想者，而你換來的，不過是成為他們的操作員。

工具已經有了。模型已經有了。革命已經發生，大多數人卻仍然在裝飾老房子。

不用再用絲綢包裹斷腿了。開始構建屬于你的東西。

對于作者的觀點，Yuuki 表示：

我完全同意你的觀點。 我目前正在構建我自己的庫，完全不需要使用那些背負著陳舊包袱的高度復雜的庫。更重要的是，我相信這是一個創造的時代——我們可以參考像 Spec Kit 和 OpenClaw 這樣的項目，但更重要的是要自主探索和實驗。 相信自己的品味。最好的品味往往來自個人，而不是組織。

評論區還有一位用戶 AH 留下了自己不同的看法：

感謝分享，這真是發人深省。我的第一反應有以下兩點。

一、我不認為我們今天擁有的模型真的像框架那樣解決了“簡化”問題。我認為，對于頂級工程師來說，LLM 是真正的倍增器，但中低級工程師需要在這個新工程時代中用盡全力去提升自己的水平。

真正的危險在于，似乎沒有人愿意解決這個問題。我們該如何開發提示技巧并培訓新晉開發人員？例如，我來自第三世界國家，現在才剛開始將模型融入開發流程。使用框架時，我能立即獲取操作指南和海量的應用示例。但 LLM 供應商提供的卻只有玩具示例，整個生態系統的文檔支持也嚴重不足。我最擔憂的是，技術鴻溝只會越拉越大。

第二個不贊同的點是，我不相信模型可以自我改進，至少目前是這樣。框架會隨著時間的推移而演變，無論是功能、架構還是易用性的改進。LLM 會怎么做？我們會被困在用于訓練模型的架構中嗎？簡而言之，我們確定 LLM 可以“思考”它們生成的結果里存在的問題，研究并改進它們的輸出嗎？

雖然你說工程學關乎解決你現在面臨的問題，而不是我們明天可能遇到的問題，但我們仍然需要為明天的問題做準備。這將如何實現呢？

https://blog.alaindichiappari.dev/p/software-engineering-is-back

聲明：本文為 InfoQ 翻譯，未經許可禁止轉載。