從8歲敲代碼到被AI接管，一名微軟工程師“破防”：“我整整30年的編程生涯，幾乎快成「歷史文物」了！”

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

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

作者 | Paul Payne 翻譯 | 鄭麗媛

出品 | CSDN（ID ：CSDNnews）

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

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

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

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

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

程序員的核心工作之一就是 “管理復雜性”，所以學習和掌握相關方法至關重要。經驗豐富的開發者會熟練運用各種抽象工具：數據結構與算法、配置與狀態管理、封裝思想、函數式與面向對象組合、實體與數據區分、事件與快照模式、循環與遞歸選擇……這類知識無窮無盡。更別提每周都有新工具、新產品發布，都在不斷重構你的技術棧。

然后就是權衡了，和所有工程領域一樣，編程的本質也是做取舍。你要在處理性能與內存間取舍、在開發時間與功能完整度間取舍、在可靠性與成本之間取舍。經過一次次的權衡，最后才能誕生出“合格”的程序。

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

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

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

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

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

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

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

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

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

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

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

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

● 動作鏈太短？我們教它如何規劃長序列任務。

● 不會拆解復雜問題？我們讓它學會任務分解與執行反饋。

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

● 缺乏自省？我們給它加上“自我反思”模塊，讓它能根據結果自我調整策略。

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

今年春天，Anthropic 發布了 Claude Code，它的兩個特性讓我們的系統效率飆升：

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

（2）優雅地整合了三種經典模式：任務分解、任務委派、工具調用（比如網頁請求、文件搜索），讓 AI 能可靠地協調一系列任務。

自那之后，我們全年都在用像 Claude Code 這類的工具，不斷提升 AI 系統的能力：能處理更大的任務、可靠性更高、持續運行時間更長。

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

原來，編程已經不需要人類了

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

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

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

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

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

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

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

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

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

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

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

但說真的，這是我第一次感覺到：“最難的部分，已經被攻克了。”——從現在開始，AI可以直接按照人的需求做事，不需要程序員在中間搭橋了。

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

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

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

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

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

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

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

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

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

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

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

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

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

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