【CSDN 編者按】這是一位擁有 30 年編程經(jīng)驗的老開發(fā)者的“自我清算”。本文作者 Paul Payn，目前是微軟 CTO 領(lǐng)導(dǎo)下的首席研究工程師，從 Commodore 64 到大型語言模型，從敲代碼到與 AI 共創(chuàng)，他親眼見證了整個軟件行業(yè)從“手寫邏輯”走向“機器自動生成”的驚人跨越。當他意識到自己賴以為生的技能，正被工具以指數(shù)級速度超越時，那種震撼與失落，相信每一位程序員都能感同身受。

原文鏈接：https://payne.io/posts/historical-artifact/

作者 | Paul Payne 翻譯 | 鄭麗媛

出品 | CSDN（ID ：CSDNnews）

好吧，我得承認——我整整 30 年的編程生涯，如今已經(jīng)成為了一件“歷史文物”。

AI 時代的浪潮，比我想象得更快。也許在不久的將來，人類回望當下時會覺得：當年居然真的是“人”在給機器寫代碼，簡直滑稽。

我曾堅信，編程離不開人類

我從 8 歲那年開始學編程，那時的我正抱著一臺 Commodore 64，翻著厚厚的用戶手冊，對著雜志上的示例代碼一行行地抄。此后 40 年，我從未停止過學習：編程并不是一門“學會了就完事”的技能，而是一場永不休止的自我進化。每一代開發(fā)者，都要學會在浪潮里自我重塑。我們招程序員時，最看重的幾項品質(zhì)，包括適應(yīng)性、獨立學習能力和批判性思維，正是這種生存能力的體現(xiàn)。

從本質(zhì)上說，編程需要一種“機械同理心”（mechanical sympathy）。你必須理解機器的底層邏輯：存儲、內(nèi)存、處理器、接口……在此之上，再去學習語言語法和工具鏈：什么樣的字符組合，才能讓系統(tǒng)真正執(zhí)行。再往上，是抽象的世界：先應(yīng)對大型程序，再到程序集群，最后是計算機網(wǎng)絡(luò)系統(tǒng)。

程序員的核心工作之一就是 “管理復(fù)雜性”，所以學習和掌握相關(guān)方法至關(guān)重要。經(jīng)驗豐富的開發(fā)者會熟練運用各種抽象工具：數(shù)據(jù)結(jié)構(gòu)與算法、配置與狀態(tài)管理、封裝思想、函數(shù)式與面向?qū)ο蠼M合、實體與數(shù)據(jù)區(qū)分、事件與快照模式、循環(huán)與遞歸選擇……這類知識無窮無盡。更別提每周都有新工具、新產(chǎn)品發(fā)布，都在不斷重構(gòu)你的技術(shù)棧。

然后就是權(quán)衡了，和所有工程領(lǐng)域一樣，編程的本質(zhì)也是做取舍。你要在處理性能與內(nèi)存間取舍、在開發(fā)時間與功能完整度間取舍、在可靠性與成本之間取舍。經(jīng)過一次次的權(quán)衡，最后才能誕生出“合格”的程序。

但程序不是孤立存在的，它們是為了解決人的問題——要變成真實的產(chǎn)品和服務(wù)。因此，程序員不僅要會寫代碼，還要懂用戶、懂需求、懂商業(yè)，確保系統(tǒng)可行、能跑、能賣。并且，由于程序員寫的程序要和用戶交互，我們還必須時刻關(guān)注心理學、社會學，以及這些領(lǐng)域與技術(shù)的交叉點。

幾十年后，我意識到，編程教給我最大的，并不是語法或算法，而是如何思考問題。如果你要拆解一個復(fù)雜問題、讓不同模塊協(xié)同、或者預(yù)判一個系統(tǒng)隨時間的演化——這類工作，過去必須有程序員在場。這也是過去半個世紀里，編程能滲透到幾乎所有科學領(lǐng)域的原因： 程序員，是加速一切問題求解的“設(shè)計師、建筑師和工匠”，他們在所有領(lǐng)域都能解決問題。

那么……編程真的離不開人類嗎？

三年前，我面試了幾個高級工程師候選人。而面試中常會遇到一種情況：有些人，不管什么原因，就是沒掌握編程工作必需的基礎(chǔ)技能。如果他們的批判性思維或問題解決能力很強，我們可能會根據(jù)崗位需求適當放寬要求，但這種“基礎(chǔ)不達標”的情況實在令人費解。

連續(xù)面試幾個候選人失敗后，我癱在辦公椅上抱怨：“這么基礎(chǔ)的問題，他們怎么連個解決方案都寫不出來？”

我同事覺得好笑，問我：“什么問題？”我跟他描述了一遍，他說 “好”，然后我才發(fā)現(xiàn)，他不是在幫我分析面試問題——而是在把問題輸入給 OpenAI 的 GPT-3 Davinci playground（當時我們剛拿到早期訪問權(quán)限）。

敲了幾下鍵盤提交后，屏幕上立刻彈出了一段完美的 Python 代碼。我一看，答案不僅正確，效率還很高。我很驚訝，讓他換個編程語言再試，結(jié)果成功了；我又讓他換個編程范式，還是成功了。更夸張的是，AI 甚至沒等我們繼續(xù)要求，就自動輸出了其他多種語言的解決方案。

從那天起，我們微軟內(nèi)部的一支小團隊就開始深入研究這種由LLM（大語言模型）驅(qū)動的系統(tǒng)。

一開始，我和行業(yè)里大多數(shù)人想法一樣：這項技術(shù)頂多就是提高效率的工具，絕不可能替代程序員。要讓 AI 解決“非玩具級”的復(fù)雜問題，還需要很長時間——畢竟程序員日常用到的技能，對一個“文本補全的模型”來說太難了。

但后來，我們一個個地解決AI 的短板：

● 記憶窗口太短？我們發(fā)明了外部上下文管理技巧。

● 只能輸出文本？我們讓它調(diào)用工具、運行命令。

● 動作鏈太短？我們教它如何規(guī)劃長序列任務(wù)。

● 不會拆解復(fù)雜問題？我們讓它學會任務(wù)分解與執(zhí)行反饋。

● 輸出不可控？我們建立了可度量、可驗證的機制。

● 缺乏自?。课覀兘o它加上“自我反思”模塊，讓它能根據(jù)結(jié)果自我調(diào)整策略。

在這個過程中，模型能力不斷提升，生態(tài)也在擴大……一步一步地，AI 從我們程序員手里接走了越來越多工作。

今年春天，Anthropic 發(fā)布了 Claude Code，它的兩個特性讓我們的系統(tǒng)效率飆升：

（1）能直接通過命令行和電腦交互，而不是像 ChatGPT 那樣困在網(wǎng)頁或 API 里；

（2）優(yōu)雅地整合了三種經(jīng)典模式：任務(wù)分解、任務(wù)委派、工具調(diào)用（比如網(wǎng)頁請求、文件搜索），讓 AI 能可靠地協(xié)調(diào)一系列任務(wù)。

自那之后，我們?nèi)甓荚谟孟?Claude Code 這類的工具，不斷提升 AI 系統(tǒng)的能力：能處理更大的任務(wù)、可靠性更高、持續(xù)運行時間更長。

但即便如此，我當時仍沒覺得“編程會變成歷史文物”。

原來，編程已經(jīng)不需要人類了

上周，我們團隊把之前積累的各種技術(shù)和實驗，整合到了 Claude Code 上（把它當快速實驗平臺用），很快就集成了很多來之不易的成果。我們已經(jīng)在 GitHub 上發(fā)布了早期原型Amplifier（https://github.com/microsoft/amplifier），未來一兩周還會發(fā)布新版本。

當然，這個工具本身不會取代我，但它也讓我確信了一件事：距離AI 取代程序員的時間，只剩“幾個月”，而不是“幾年”——因為，它已經(jīng)搞定編程里“最難的部分”了。

用 Amplifier 時，你只需要描述自己想要什么，它就能按你的編程理念，從設(shè)計、后端、前端到測試，完整地把產(chǎn)品做出來。更離譜的是，它還會自我改進，也就是你用得越多，它越聰明：會積累可復(fù)用的工具；會記錄有用的技術(shù)方法；會從你的使用中學習，主動建議如何優(yōu)化自己。

這是一種“指數(shù)級效率提升”——你做出來的東西，會幫你更快地做出新東西。

過去一周，我用 Amplifier 做了兩件事：

（1）分析了兩個不同的代碼庫，從其中一個里提取我正在開發(fā)的功能模塊，然后讓它提出三種方案，把這個模塊整合到另一個代碼庫里；接著它并行實現(xiàn)了這三種方案，最后還給出了 “哪些可行、哪些不可行” 的總結(jié)。

（2）把我寫的一套（大型）Bash 腳本，轉(zhuǎn)換成了三個東西：Web 服務(wù) API、Golang 命令行工具、完整的 Web 應(yīng)用前端。

當然，寫提示詞需要時間，也需要程序員的知識，但每個任務(wù)只需要給 Amplifier 三條提示。每次它都會運行 30 到 120 分鐘，最后返回能直接用的軟件——還包括文檔。

同一時間，我們團隊的其他人也用它做了許多事：開發(fā)了 Amplifier 的新版本、搭建了一套完整的評估框架、做了兩個不同的圖形化實驗桌面。最讓我驚訝的是一個設(shè)計師：他沒什么編程經(jīng)驗，卻靠 Amplifier 實現(xiàn)了一個“從設(shè)計風格到完整框架”的新流程 —— 融合了 Figma、Storybook 等工具的思路和工作流，做出了一個全新的 “AI 輔助設(shè)計應(yīng)用”。我估計，這個工具能讓他的效率提升 10 倍。

除此之外，我們還讓 Amplifier 對接了一個“管理大型關(guān)聯(lián)任務(wù)列表”的項目，它直接把這個項目整合進了自己的系統(tǒng)。我同事讓它通宵運行，它自主完成了幾十個任務(wù)，還準備了一份“早間報告”——里面包含了多個組件的實現(xiàn)方案，讓我同事判斷下一步該做什么。

這并不是最終產(chǎn)品，我們還有很多工作要做，比如：硬件和軟件廠商需要發(fā)布 AI 可用的產(chǎn)品背景信息，我們還得迭代和發(fā)布新的系統(tǒng)集成標準。

但說真的，這是我第一次感覺到：“最難的部分，已經(jīng)被攻克了?！薄獜默F(xiàn)在開始，AI可以直接按照人的需求做事，不需要程序員在中間搭橋了。

所以，編程的未來是怎樣的？

像我剛才提到的，“把 Bash 腳本轉(zhuǎn)成 Web 應(yīng)用”的項目，其實全程都在一臺樹莓派（Raspberry Pi）微型電腦上運行。我只是在上面裝了 Amplifier，掛載了舊代碼庫，然后告訴它要做什么——全程沒碰過一行代碼。而它做出的成果，比我花幾周時間親自做的還要好。

你可以想象一下未來：我們無需再下載、安裝軟件，只需告訴AI“我想要什么”，它就會幫你做出來。想改功能？加新特性？做個全新應(yīng)用？沒問題，直接跟它說就行。

而我過去幾十年積累的那些編程技能，包括算法、抽象、架構(gòu)設(shè)計，現(xiàn)在只要給 Amplifier 寫對提示詞，它就都能做到?，F(xiàn)在只差最后一步：把這些“專業(yè)知識”全部封裝好交給 AI。屆時，哪怕沒有編程經(jīng)驗的人，也能讓 AI 按自己的需求，隨時搭建軟件。

當“編程”不再需要人類，我們該怎么辦？

我得承認，至少這對我個人而言是一場“生存危機”。

外界對我的身份認知中，很大一部分是 “程序員”。過去，我一直覺得編程就像“魔法”：只要寫對“咒語”（代碼），就能召喚機器完成奇跡——這也是我的“職業(yè)超能力”?？涩F(xiàn)在，每個人都能用“魔法”了，我的“超能力”突然變成了“日常技能”，那我還能在行業(yè)里立足嗎？

同時，我的職業(yè)技能也產(chǎn)生了一種快變成“遺產(chǎn)”的感覺。我們都希望自己做的事能超越生命周期，但現(xiàn)在很明顯：我職業(yè)生涯的遺產(chǎn)，會變成一種“奇觀”—— 就像鐵匠、抄寫員、宮廷小丑那樣。

但這次技術(shù)帶來的“淘汰”，可能比以往更特殊。過去，被技術(shù)取代的人，還能把自己的領(lǐng)域知識和問題解決能力，遷移到新領(lǐng)域里升級：鐵匠去建鋼鐵廠，抄寫員變成印刷工，小丑變成喜劇演員。他們?nèi)栽诮鉀Q問題，只是換了工具。

可這一次，當“解決問題”本身都能被自動化，我們還能去哪？

我的同事 Brian Krabach 半年前也有過類似的思考，但我當時沒信。我以為 AI 最多取代部分編程工作，未來很長一段時間里，我們還是需要程序員來引導(dǎo) AI。但 Amplifier 每天都在證明：我的時間判斷錯了。

Brian Krabach比較樂觀，他說“取代程序員” 反而讓他能做自己一直喜歡的事——更快地解決更大的問題。但我沒他那么樂觀。對我來說，“識別問題、提出方案”從來都不是難事。而我在多個創(chuàng)新實驗室的經(jīng)歷告訴我：這些能力，同樣是 “可自動化的流程”。

有人或許會辯解：“機器不知道人類在面臨什么問題啊！”是的，但也許我們很快會讓機器寫出“知道該解決什么問題”的軟件。

想到這里，我其實感到一絲慰藉——也許，真正的大問題終于有望被解決：能源、醫(yī)療、教育、社會治理……只是從此以后，我的貢獻，不再來自我那雙敲鍵盤的手；那些我靠幾十年磨礪得來的技能，也將不再屬于某個專業(yè)群體，它們會屬于每一個能調(diào)用算力的人。