程序員每十年就“要被取代”一次：這件事從 1969 年開始

作者｜ Stephan Schwab

譯者｜冬梅

策劃｜Tina

編者按：

過去半個多世紀，軟件開發(fā)領(lǐng)域反復(fù)上演著一種熟悉的敘事：每當(dāng)一種新技術(shù)出現(xiàn)，總會伴隨著一個激動人心的承諾——編程將變得更簡單，軟件將不再是少數(shù)專業(yè)人士的專利，業(yè)務(wù)人員也可以親自“把需求變成系統(tǒng)”。從 COBOL 到 CASE 工具，從可視化開發(fā)環(huán)境到低代碼、無代碼平臺，再到今天被寄予厚望的 AI，這個夢想一次次被點燃，又一次次被現(xiàn)實修正。

這篇文章試圖回到歷史本身，梳理這條看似循環(huán)、卻不斷演進的技術(shù)軌跡。它從阿波羅登月這一人類工程史上的高光時刻講起，揭示軟件如何從幕后走到臺前，成為支撐復(fù)雜系統(tǒng)的關(guān)鍵力量；也回顧了企業(yè)世界中一次次“降低門檻”的努力，為什么總能解決部分問題，卻始終無法繞開真正的復(fù)雜性。

文章作者 Stephan Schwab 自 1981 年起就開始從事編程工作，曾使用過各種不同的平臺和大約 20 種不同的編程語言。目前，他主要專注于了解用戶和企業(yè)真正希望如何使用軟件，以及如何開發(fā)能夠激發(fā)客戶興趣的軟件。他成長于德國，并在多個國家生活和工作過。他能說一口流利的德語、英語和西班牙語。

Stephan 在文章并不否認技術(shù)進步帶來的價值。相反，他清晰地指出：每一代工具都確實讓開發(fā)更快、更高效，讓更多人得以參與軟件創(chuàng)造。但與此同時，一個始終未變的事實也逐漸浮現(xiàn)——軟件開發(fā)真正受限的，從來不是語法、界面或工具形態(tài)，而是對復(fù)雜現(xiàn)實的理解、判斷與取舍。

在 AI 編程工具引發(fā)新一輪想象的當(dāng)下，這種回望顯得尤為重要。AI 究竟是在“終結(jié)開發(fā)者”，還是在重塑開發(fā)者的工作方式？歷史或許已經(jīng)給出了線索。讀完這篇文章，你可能不會對未來抱有不切實際的幻想，但會更清楚地理解：為什么這個行業(yè)一次次期待“更簡單”，又為什么真正的價值，始終來自那些愿意思考復(fù)雜問題的人。

1 夢想，誕生于人類最偉大的成就時刻

1969 年，尼爾·阿姆斯特朗踏上月球表面的那一刻，全世界親眼見證了“有組織的人類智慧”究竟能夠走多遠。而支撐這次壯舉的背后，是瑪格麗特·漢密爾頓和她的團隊——他們一行一行地手寫阿波羅號的導(dǎo)航軟件，通過極其嚴謹?shù)娜斯彶椴蹲疥P(guān)鍵錯誤，第一次向世人證明：軟件并非可有可無的工具，而是關(guān)乎任務(wù)成敗、甚至生死存亡的核心系統(tǒng)。

阿波羅計劃讓人類意識到，正是軟件開發(fā)，才讓“不可能”成為現(xiàn)實。但與此同時，它也暴露出一個此后幾十年持續(xù)困擾企業(yè)管理者的現(xiàn)實問題：軟件的編寫需要高度專業(yè)的知識、長期的專注投入，以及難以壓縮的時間成本。如何讓軟件開發(fā)變得更簡單——如何減少對這些昂貴而稀缺的專業(yè)人員的依賴——幾乎在那一刻就成為了一種揮之不去的夢想。

2 COBOL：讓業(yè)務(wù)人員自己寫程序

20 世紀 60 年代末到 70 年代，COBOL 語言登上歷史舞臺，它的雄心甚至直接寫進了名字里——“通用業(yè)務(wù)導(dǎo)向語言”。設(shè)計者的愿景異常清晰而大膽：讓編程語言看起來就像英文句子一樣自然，這樣一來，業(yè)務(wù)分析師就可以親自編寫程序，而不再需要依賴受過高度專業(yè)訓(xùn)練的程序員。軟件開發(fā)，似乎第一次被描繪成一件“人人可參與”的事情。

這一愿景確實極具吸引力。

隨著軟件逐漸成為企業(yè)運轉(zhuǎn)的命脈，程序員卻始終是稀缺而昂貴的資源。COBOL 承諾要“讓軟件開發(fā)民主化”，讓更多人參與進來，這聽上去幾乎是企業(yè)管理者的福音。

但現(xiàn)實給出了另一種答案。COBOL 最終只是變成了另一門需要系統(tǒng)訓(xùn)練的編程語言。那些嘗試親自編寫 COBOL 程序的業(yè)務(wù)分析師很快發(fā)現(xiàn)：語法是否“像英語”，并不能消除邏輯本身的復(fù)雜性，也無法繞開數(shù)據(jù)結(jié)構(gòu)、系統(tǒng)設(shè)計這些硬核問題。結(jié)果是，一群新的“COBOL 程序員”誕生了，而“不再需要專業(yè)開發(fā)者”的夢想，再一次落空。

不過，這個夢想并沒有消失。

它只是耐心地，等待著下一次技術(shù)浪潮的到來。

3 20 世紀 80 年代：CASE 工具將自動生成一切

進入 80 年代，計算機輔助軟件工程（CASE）工具橫空出世，帶著近乎顛覆性的承諾而來：只要畫流程圖、畫實體關(guān)系圖，工具就能自動生成可運行的代碼。市場宣傳精準(zhǔn)擊中了人們的直覺——視覺化設(shè)計，顯然比敲打晦澀難懂的命令要“更符合人性”。業(yè)務(wù)專家只需把流程“畫出來”，軟件就會自然生成。

企業(yè)為此投入了大量資金。廠商信誓旦旦地宣稱，生產(chǎn)力可以提升 10 倍，甚至更多。

但現(xiàn)實再次潑了冷水。

生成的代碼往往需要大量人工修改；性能問題接連出現(xiàn)；當(dāng)生成代碼與可視化模型逐漸“走散”后，維護幾乎變成了一場噩夢。更致命的是，要畫出真正準(zhǔn)確的圖，本身就需要對業(yè)務(wù)邏輯和系統(tǒng)復(fù)雜性有深入理解——這與寫代碼所要求的認知能力并無本質(zhì)差異。工具改變了操作界面，卻沒有觸及問題的核心。

再一次，人們發(fā)現(xiàn)：問題遠比解決方案頑固得多。

4 Visual Basic 與 Delphi：拖一拖，放一放，就完成了

90 年代帶來了另一條路徑。微軟的 Visual Basic 和 Borland 的 Delphi，讓構(gòu)建用戶界面變得前所未有地簡單：把組件拖到窗口上，設(shè)置屬性，編寫事件處理代碼。突然之間，開發(fā)一個 Windows 應(yīng)用，看起來不再是少數(shù)高手的專利。

這一次，它們的成功方式，與 COBOL 和 CASE 工具有所不同。

這些工具并沒有否認“編程知識仍然必要”，而是顯著降低了入門門檻。更多具備中等經(jīng)驗的人，也能做出真正有用的軟件。

然而，“消滅開發(fā)者”的夢想依然頑強存在。“高級用戶”“公民開發(fā)者”將自行構(gòu)建部門級應(yīng)用；IT 部門只需專注基礎(chǔ)設(shè)施，業(yè)務(wù)部門自己解決軟件需求——這一藍圖再次令人心動。

但現(xiàn)實依舊更加復(fù)雜。

簡單應(yīng)用確實更容易上手了，可一旦需求開始變復(fù)雜——系統(tǒng)集成、安全合規(guī)、高并發(fā)性能、長期維護——經(jīng)驗豐富的開發(fā)者就不可避免地走回舞臺中央。這些工具擴展了“誰可以寫軟件”的邊界，卻從未消除構(gòu)建大型系統(tǒng)所需的專業(yè)能力。

于是，這個循環(huán)，被帶入了新的千年。

5 2000 年代及以后：Web 框架、低代碼、無代碼

每一個新的十年，都會帶來新的變體。

Ruby on Rails 提出“約定優(yōu)于配置”；低代碼平臺用可視化開發(fā)減少手寫代碼；無代碼平臺甚至宣稱，常見業(yè)務(wù)應(yīng)用可以完全不寫程序。

每一波浪潮，都帶來了真實的價值。在特定場景下，開發(fā)速度確實大幅提升；更多人開始參與軟件創(chuàng)造。但與此同時，專業(yè)軟件工程師不僅沒有被取代，對他們的需求反而持續(xù)增長。

這就引出了一個關(guān)鍵問題：為什么這個模式會一再重演？

為什么這個夢想始終存在？

這種反復(fù)出現(xiàn)的模式，揭示了我們對“復(fù)雜性”的一種根本誤判。軟件開發(fā)之所以看起來應(yīng)該很簡單，是因為我們能用自然語言描述目標(biāo)：“當(dāng)客戶下單時，檢查庫存、計算運費、處理支付、發(fā)送確認郵件。”這段話聽起來毫不費力。

真正的復(fù)雜性，藏在細節(jié)里。

• 庫存被另一個訂單臨時占用怎么辦？

• 部分支付如何處理？

• 郵件服務(wù)暫時不可用，是重試還是放棄？重試幾次？

• 結(jié)賬過程中用戶會話過期怎么辦？

• 如何防止重復(fù)下單？

每一個答案，都會引出新的問題。無數(shù)邊界情況、決策分支和相互作用層層疊加，形成了任何工具都無法抹平的真實復(fù)雜性。無論使用 COBOL、CASE 圖、Visual Basic，還是 AI 提示詞，這種“思考本身”，就是軟件開發(fā)。

這，也正是今天這股熱潮的背景。

6 AI：一段漫長歷史中的最新章節(jié)

今天的 AI 編程助手，是迄今為止最強大的嘗試。它們可以根據(jù)自然語言生成大量可運行代碼，解釋現(xiàn)有代碼，提出優(yōu)化建議，甚至協(xié)助調(diào)試問題。

這是實實在在的進步。經(jīng)驗豐富的開發(fā)者，正在用 AI 明顯提升效率；初學(xué)者，也能從互動式指導(dǎo)中受益。

但熟悉的模式已經(jīng)開始浮現(xiàn)。最初關(guān)于“AI 將取代開發(fā)者”的狂熱，正在逐漸讓位于更冷靜的認知：AI 改變了開發(fā)者的工作方式，卻并沒有替代他們的判斷力。復(fù)雜性依然存在。必須有人理解業(yè)務(wù)問題，評估生成代碼是否真正解決了問題，審視安全風(fēng)險，確保系統(tǒng)集成順暢，并在需求變化中持續(xù)維護。

AI 放大了開發(fā)者的能力，但并沒有取代“理解問題與技術(shù)全局”的人。

這里存在一個格外耐人尋味的悖論。

我們的軟件能力取得了驚人的進步。阿波羅制導(dǎo)計算機只有 4KB 內(nèi)存，而你的手機擁有數(shù)百萬倍的算力。開發(fā)工具和框架，確實讓許多事情變得更容易。

但軟件需求，依然遠遠超過我們的交付能力。幾乎每一家組織，都想要比自己能構(gòu)建的更多軟件。需求清單增長的速度，始終快于開發(fā)團隊的消化能力。

正是這種張力——工具愈發(fā)強大，產(chǎn)能卻依然不足——讓夢想持續(xù)存在。管理者面對積壓的需求，自然會想：“一定有辦法更快，讓更多人參與進來。”這并非不理性，而是極其現(xiàn)實的期待。

問題在于，軟件開發(fā)的瓶頸，從來不在打字速度，也不在語法復(fù)雜度，而在于處理復(fù)雜性的思考能力。打字再快，也無法替代對并發(fā)數(shù)據(jù)庫更新的推演；語法再簡單，也無法繞開對安全影響的深度判斷。

7 這對管理者意味著什么

理解這一歷史循環(huán)，會徹底改變你評估新工具的方式。

當(dāng)有人承諾“業(yè)務(wù)人員無需開發(fā)者也能構(gòu)建應(yīng)用”時，你可以理解這種愿景，但也能保持清醒的預(yù)期。

真正該問的，不是“這能否消滅開發(fā)者”，而是：

• 它是否能幫助開發(fā)者更高效地解決復(fù)雜問題？

• 是否能讓某些類型的解決方案更快落地？

• 是否能減少重復(fù)性勞動，讓人專注于真正獨特的挑戰(zhàn)？

• 團隊是否需要為此學(xué)習(xí)新的能力？

這些問題，既承認復(fù)雜性的不可消除，也為真正有價值的工具留出了空間。

8 五十年的重復(fù)，揭示了問題的本質(zhì)

這五十年的歷史告訴我們一個根本事實：如果軟件開發(fā)的難點主要是機械性的——打字太多、語法太復(fù)雜、步驟太繁瑣——我們早就解決了。COBOL 讓語法可讀，CASE 工具消除了輸入，視覺化工具繞開了語法，AI 甚至能直接生成完整函數(shù)。

每一次進步，都解決了真實存在的摩擦點。

但核心挑戰(zhàn)始終存在，因為它不是機械問題，而是認知問題。軟件開發(fā)，是把思考變成可運行的現(xiàn)實。無論是 COBOL 程序、Delphi 窗口，還是 Python 腳本，它們都只是復(fù)雜思考的外在表現(xiàn)。

這種思考，無法被“跳過”，就像建筑設(shè)計或醫(yī)學(xué)診斷一樣。工具能幫助，經(jīng)驗?zāi)芗铀伲K究需要有人把問題想清楚。

9 帶著清醒前行，因為夢想本身就有意義

新的開發(fā)浪潮還會到來。有的會真正創(chuàng)造價值，有的會用新技術(shù)重復(fù)舊承諾。理解這條歷史曲線，能幫助你更理性地使用新工具。

使用 AI 助手，評估低代碼平臺，嘗試新框架——但最重要的投入，依然應(yīng)該放在提升人們理解和駕馭復(fù)雜性的能力上。這一點，自阿波羅時代至今，從未改變。

登月成功，不是因為工具多么先進，而是因為一群杰出的人，把極端復(fù)雜的問題逐一想透。他們手寫軟件，只是因為當(dāng)時別無選擇。如果有更好的工具，他們一定會用。但工具，從來不是替他們思考的東西。

我們今天處在同樣的基本處境中：工具更強了，強得多，但思考依然不可或缺。

也許，一次次想要“替代開發(fā)者”的夢想，并不是錯誤。也許，正是這種帶著理想主義色彩的樂觀，推動了工具的進步。每一次嘗試，都沒有按最初設(shè)想實現(xiàn)，卻都創(chuàng)造了真實的價值。

COBOL 沒讓業(yè)務(wù)人員寫程序，卻支撐了一代商業(yè)系統(tǒng)；CASE 工具沒自動生成應(yīng)用，卻推動了建模思想；Visual Basic 沒消滅開發(fā)者，卻讓更多人走進開發(fā)世界；AI 不會取代工程師，但必然深刻改變我們的工作方式。

這個模式之所以不斷重演，是因為它源于一個真實而迫切的需求：我們需要更快、更高效地創(chuàng)造軟件。只是一次又一次，我們發(fā)現(xiàn)，真正的限制從來不在工具，而在問題本身的復(fù)雜性。

理解這一點，并不意味著拒絕新工具，而是帶著清醒的期待去使用它們——知道什么可以交給技術(shù)，什么永遠需要人類的判斷。

https://www.caimito.net/en/blog/2025/12/07/the-recurring-dream-of-replacing-developers.html