AI 編程正在終結(jié)框架時代

作者 | Alain

譯者 | 平川

策劃 | Tina

本文最初發(fā)布于 Alain 的個人博客。

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

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

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

自動化編程

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

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

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

尤其是，自動化編程讓我可以快速構(gòu)建我需要的工具，曾經(jīng)存在于這個地球上的每一名鐵匠都會非常地羨慕我。終于能夠真正地專注于他們認為重要的事情了。終于能夠?qū)⒏嗟臅r間投入到他們構(gòu)想的藝術(shù)創(chuàng)作中，而不是鍛造間的汗水中。

頓悟

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

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

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

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

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

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

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

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

軟件工程回來了

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

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

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

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

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

想想吧

真的想想吧。

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

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

工具已經(jīng)有了。模型已經(jīng)有了。革命已經(jīng)發(fā)生，大多數(shù)人卻仍然在裝飾老房子。

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

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

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

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

感謝分享，這真是發(fā)人深省。我的第一反應(yīng)有以下兩點。

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

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

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

雖然你說工程學關(guān)乎解決你現(xiàn)在面臨的問題，而不是我們明天可能遇到的問題，但我們?nèi)匀恍枰獮槊魈斓膯栴}做準備。這將如何實現(xiàn)呢？

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

聲明：本文為 InfoQ 翻譯，未經(jīng)許可禁止轉(zhuǎn)載。