作者 | Alain

譯者 | 平川

策劃 | Tina

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

我不經(jīng)常發(fā)表博文。當(dāng)我這么做時(shí)，是因?yàn)槲矣X得還沒大有人把我注意到的事情說出來。

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

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

自動(dòng)化編程

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

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

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

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

頓 悟

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

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

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

框架解決（或聲稱解決）的三個(gè)問題

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

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

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

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

軟件工程回來了

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

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

我們?cè)俅潍@得了一個(gè)機(jī)會(huì)，讓我們可以擺脫無用的復(fù)雜性，繼續(xù)致力于我們的想法、特性和產(chǎn)品中那些真正受歡迎的復(fù)雜性。那些重要的復(fù)雜性，那些真正屬于你的復(fù)雜性。

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

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

想想吧

真的想想吧。

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

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

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

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

對(duì)于作者的觀點(diǎn)，Yuuki 表示：

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

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

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

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

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

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

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

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

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

會(huì)議推薦

OpenClaw 出圈，“養(yǎng)蝦”潮狂熱，開年 Agentic AI 這把火燒得不可謂不旺。在這一熱潮下，自托管 Agent 形態(tài)迅速普及：多入口對(duì)話、持久記憶、Skills 工具鏈帶來強(qiáng)大生產(chǎn)力。但這背后也暴露了工程化落地的真實(shí)難題——權(quán)限邊界與隔離運(yùn)行、Skills 供應(yīng)鏈安全、可觀測(cè)與可追溯、記憶分層與跨場(chǎng)景污染、以及如何把 Agent 納入團(tuán)隊(duì)研發(fā) / 運(yùn)維流程并形成穩(wěn)定收益。

針對(duì)這一系列挑戰(zhàn)，在 4 月 16-18 日即將舉辦的 QCon 北京站上，我們特別策劃了「OpenClaw 生態(tài)實(shí)踐」專題，將聚焦一線實(shí)踐與踩坑復(fù)盤，分享企業(yè)如何構(gòu)建私有 Skills、制定安全護(hù)欄、搭建審計(jì)與回放機(jī)制、建立質(zhì)量 / 效率指標(biāo)體系，最終把自托管 Agent 從可用的 Demo 升級(jí)為可靠的生產(chǎn)系統(tǒng)。

今日薦文

你也「在看」嗎？