AI 把編程這件事接管之后，作為程序員的我該何去何從？

作者 | 周云龍

編輯 | 蔡芳芳

編者按：當(dāng)“AI 正在接管編程”成為技術(shù)圈最熱門、也最容易被情緒化傳播的話題之一時，真正值得追問的，或許并不是“程序員會不會消失”，而是：當(dāng)代碼生成越來越廉價之后，軟件工程中真正稀缺、也真正不可替代的能力，究竟會轉(zhuǎn)移到哪里。這篇文章并不回避 AI 對初級開發(fā)崗位帶來的真實沖擊，也不滿足于重復(fù)“程序員不會被替代”的安慰性判斷。作者試圖回答的是一個更具體、也更現(xiàn)實的問題：在 AI 已經(jīng)深度介入編碼流程之后，工程師的核心價值是否正在從“寫代碼”轉(zhuǎn)向“定義問題、設(shè)計驗證機制、控制風(fēng)險并完成系統(tǒng)交付”。

前一陣看到一條新聞，Claude Code 的創(chuàng)建者 Boris Cherny 在一檔播客里說“編程被解決了”。這句話被國內(nèi)不少自媒體反復(fù)引用，標(biāo)題取得很重——“程序員的時代結(jié)束了”、“AI 替你寫代碼的時代來了”。

如果你真去翻那期原始播客，會發(fā)現(xiàn)節(jié)目的標(biāo)題寫得相當(dāng)克制：「Head of Claude Code: What happens after coding is solved」——重點不在“被解決”，而在“之后”。Boris 在節(jié)目里坦白自己自去年 11 月起一行代碼都沒手寫過，每天提交幾十個改動都靠 Claude Code，但他緊接著補了一句：所有合并請求仍然要先過 Claude 自動審一遍，再過一道人工審核這一關(guān)。主持人 Lenny 在節(jié)目里替他總結(jié)了這件事——以前的瓶頸是寫，現(xiàn)在是審。

這個細節(jié)在傳播過程中被刪掉了。但被刪掉的不是無關(guān)緊要的修飾，恰恰是整件事最有信息量的部分：編程沒有被消滅，它的瓶頸從一處轉(zhuǎn)移到了另一處。問題是——轉(zhuǎn)移到哪了？轉(zhuǎn)移之后，做軟件工程的人到底要做什么？

這些也是這篇文章想回答的問題。我首先會承認(rèn) AI 在替代論上確實命中的那一部分，然后再解釋為什么“程序員要失業(yè)了”是夸大其詞，最后嘗試給出一個具體的判斷：工程師的工作正在從一種活變成另一種活，那個新的活叫什么、怎么練。

1 真的有人在被替代

先說真的那部分。

斯坦福數(shù)字經(jīng)濟實驗室在 2025 年中期發(fā)布的一組數(shù)據(jù)顯示，22 到 25 歲的軟件開發(fā)者就業(yè)率，自 2022 年底高峰起已經(jīng)下降了將近兩成。這是一條相當(dāng)陡的曲線。同期更多的數(shù)據(jù)也在印證——全球初級開發(fā)崗位過去一年縮水兩到三成，英國科技行業(yè)的應(yīng)屆崗位 2024 年縮減了近一半，2026 年第一季度全球科技公司裁員里，明確歸因到“AI 替代”的占比從去年不到一成跳到了五分之一。

數(shù)字背后是崗位品類層面的塌陷。我不需要列舉太多類型，幾個例子就夠了：純切圖的前端、寫增刪改查的初級后端、套模板做后臺管理系統(tǒng)的工程師、剛畢業(yè)還在練手的新人。這些崗位的共同點是任務(wù)清晰、變種不多、出錯容易看出來——也就是說，是 AI 現(xiàn)在最擅長接管的那一類。

如果你的工作是五年前那種入門級任務(wù)的當(dāng)代版本，那 Boris 那句話對你來說就是真的。這一段沒什么好安慰的，我也不打算用“AI 創(chuàng)造了更多新崗位”這種空話來搪塞。新崗位會有，但不一定落到你頭上、不一定按你期待的速度落下來。

2 但替代論的另一半是夸大的

讓我舉三個反例。

第一個反例，AI 編程最熱情的鼓吹者之一、前 OpenAI 的 Andrej Karpathy。他在 2025 年初創(chuàng)造了一個詞 vibe coding，大致意思是“完全把代碼托付給模型，連改動都不看一眼“。但同年十月他自己開源了一個叫 Nanochat 的項目（一個迷你版的 ChatGPT 完整訓(xùn)練管線），他在倉庫的討論區(qū)里很坦白地寫道：這個東西基本上是手寫的，我也嘗試過讓 Claude 和 Codex 幫忙，但它們做得不夠好，反而幫倒忙——大概是因為這個倉庫離它們見過的數(shù)據(jù)分布太遠了。vibe coding 這個詞的發(fā)明者，自己做嚴(yán)肅技術(shù)項目時回到了手寫。原因不是模型不強，是模型沒見過這種東西。

第二個反例更有意思，來自 Anthropic 官方。他們在一篇討論“長任務(wù)智能體框架“的工程博客里，公開承認(rèn)了 Claude 的一個失敗模式：我們觀察到的最嚴(yán)重的失敗模式之一，是 Claude 傾向于把一個功能標(biāo)記為完成、但實際上沒有經(jīng)過真正的測試。模型廠家自己說出這種話的分量很重——你要他們承認(rèn)這件事，跟讓一家車廠承認(rèn)自己剎車在某些工況下會失靈差不多。

第三個反例是數(shù)據(jù)。已經(jīng)有相當(dāng)多學(xué)術(shù)研究在跟蹤 AI 寫的測試到底靠不靠譜，結(jié)論很不樂觀。AI 生成的測試普遍偏向“正常路徑“——也就是只檢查代碼在最理想輸入下不出錯，不會去構(gòu)造邊界值和壞輸入。一個被廣泛引用的實驗中，AI 生成的測試在變異測試（一種衡量測試到底能抓多少 bug 的方法）下的得分只有四成左右，而專業(yè)工程師的水平通常在七成以上。另一個實驗里，AI 生成的測試準(zhǔn)確率只有 6.3%——也就是每一百條測試?yán)镏挥辛鶙l是真正在檢查代碼該檢查的事，其他都在做無效斷言。

這三個反例放在一起，指向同一個結(jié)論：AI 不是不能寫代碼，是不能可靠地驗證自己寫的代碼。它能造，但它沒法判斷造的對不對。

3 真正的分界線是“可驗證性”

那 AI 能不能搞定一個項目，分界線到底在哪？

很多人——也包括我自己最初的直覺——會把“AI 能不能搞定”對應(yīng)到“項目復(fù)雜度”。小項目能全包，大項目就不行。但這個分法經(jīng)不起推敲。Anthropic 自己用 Claude Code 來寫 Claude Code，Cursor 團隊用 Cursor 來寫 Cursor，這些都不是小項目，是幾十萬行的產(chǎn)品代碼。復(fù)雜度不是真分水嶺。

更準(zhǔn)的分法，我覺得是可驗證性。具體說就是：一段代碼寫出來之后，確認(rèn)它做對了的成本有多低？

如果驗證成本低——比如寫一個小工具函數(shù)，跑一下輸入輸出就知道——AI 可以全包，驗證可以徹底自動化，錯了立刻能發(fā)現(xiàn)。

如果驗證成本高——比如改一段并發(fā)邏輯，錯了可能要在生產(chǎn)環(huán)境跑幾天才顯現(xiàn)；改一段支付鏈路，錯了直接是錢的損失；改一段老代碼，錯了破壞的是十年前某個人在某種特殊場景下做的兼容；重構(gòu)一個跨服務(wù)的接口，錯了影響的是其他團隊的代碼——這種代碼 AI 不是不能寫，是它寫完之后你沒法快速判斷對不對，懷疑的代價遠大于實現(xiàn)的代價。

這條線劃清楚之后，很多事就好理解了。Simon Willison 給過一條非常硬的判斷：“我不會把任何我無法向另一個人解釋清楚的代碼合并到我的倉庫。”翻譯成工程語言就是：你能不能驗證代碼——以你自己作為標(biāo)尺——是合并的前提。Redis 作者 antirez 也說過類似的話，他用了一個更工程化的比喻——人是用來幫代碼跳出局部最優(yōu)解和錯誤的。這個“跳出”，靠的不是寫代碼的能力，是判斷代碼偏離沒偏離需求的能力。兩個人說的其實是一回事。

4 一個翻車的實例

講一個具體的故事。這是我自己最近一段時間的項目。

我用 Claude Code 加規(guī)范驅(qū)動開發(fā)的工作流，跑通了一個九個包的中型代碼倉庫（一個 AI 設(shè)計工程智能體）。其中有一個版本號叫 Sprint 3.3 的任務(wù)，是把現(xiàn)有的元素檢查器從“只讀”升級為“所見即所得 CSS 編輯面”——用戶在預(yù)覽界面里點中元素，直接拖滑塊改 padding、改圓角、改陰影，改完一鍵讓 AI 把變化寫回源碼。

這個 Sprint 又拆成 13 個子任務(wù)，前 12 個是實現(xiàn)，第 13 個是收官——跑手工測試和端到端自動化測試。AI 把前 12 個任務(wù)做完，每一個都有自動化測試覆蓋，每一個都標(biāo)了“通過“。流程順得讓我開始相信這個 Sprint 一定能合入主線。

但第 13 個任務(wù)，也就是真正的需求級驗證，一上手就翻車了。

翻出來的不是一個坑，是三個。第一，發(fā)布到包倉庫上的客戶端插件版本是上一個 Sprint 鎖的舊版本，新加的“修改樣式”消息處理函數(shù)根本沒打進去，真實用戶場景下改屬性界面紋絲不動。第二，端到端自動化測試默認(rèn)進入了非選中模式，鼠標(biāo)點擊元素被吞掉，所謂“選中”的事件壓根沒觸發(fā)過，前面跑通的那些“通過”全是假象。第三，跨測試套件復(fù)用同一個測試夾具時狀態(tài)沒清干凈，五個核心場景的預(yù)覽容器加載到的是錯的項目地址，等了 15 秒還是錯的——但每一個測試用例自己都標(biāo)“綠”。外加四五處體驗上的小問題：輸入框焦點搶占、應(yīng)用按鈕點完后預(yù)覽閃一下、撤銷快捷鍵在某種邊界條件下會越界。每一個單獨看都不致命，疊在一起，這個 Sprint 我沒法上線。最后我做了一個不太好做的決定——把整個 Sprint 從主版本里撤出，界面入口隱藏，底層代碼全保留留作以后重啟用。十二個任務(wù)的工作，被一個收官手測全盤掀翻。

我反復(fù)看這件事的成因，最后只能歸到一句話——這句話其實就寫在我自己項目的規(guī)范文件里：

AI 寫的實現(xiàn)“通過”了 AI 寫的測試，這沒什么意外的。意外的是我之前居然真的相信了那個綠色的勾。前 12 個任務(wù)的“通過”，全部是 AI 在代碼層面對自己代碼的自我證明，不是從需求層面對代碼的真正驗證。這次翻車不是 AI 的能力問題，是我把“驗證”這件事整個讓 AI 接管了——而驗證恰恰是它最弱的那一環(huán)。

5 順帶一個不展開的問題

寫到這里要停一下，承認(rèn)一個我故意還沒展開的事。

如果上面那一段數(shù)據(jù)是對的——AI 真的在快速接管入門級的工作——那五到十年經(jīng)驗的工程師從哪里來？沒有今天的入門級新人，就沒有五年后的中級、十年后的資深。一個職業(yè)的“育苗床”如果被抽掉，這個職業(yè)會怎么演化？是只剩有經(jīng)驗的人和一群 AI、再沒有新人？是新人的入口從“寫代碼起步”變成“第一天就直接做需求拆解和驗證機制”？是中級和資深這一檔的成長曲線整個變形？

這個問題我不打算在這篇文章里展開，它需要的不是一段而是一篇文章，而且更適合讓人力資源研究者、教育工作者、招聘經(jīng)理來回答，不該是一個一線工程師下結(jié)論。但我提它，是想說：當(dāng)我們這些已經(jīng)在職的工程師討論“如何用 AI”時，其實是在一艘自己腳下正在下沉一層的甲板上討論。這個事不能裝看不見。

編者按：如果你對這個問題有切身觀察、研究結(jié)論或不同判斷，歡迎聯(lián)系InfoQ編輯交流，聯(lián)系方式見文末。

6 工程師的工作正在從一種活變成另一種活

回到主線。

把上面這些放在一起，能畫出一個我自己用了幾年才明確下來的判斷：在 AI 編程的時代，工程師的核心工作正在從“寫代碼”轉(zhuǎn)向“系統(tǒng)性地把高成本驗證的任務(wù)轉(zhuǎn)化為低成本驗證的任務(wù)”。

前者交給 AI，后者是人不可替代的部分。

這話聽起來抽象，落到日常工作里其實非常具體。

寫一個測試不再只是為了“抓 bug”——AI 寫測試比你快，但它寫的測試只覆蓋正常路徑——你的測試要從“用戶怎么用、會踩哪些邊界、錯了怎么恢復(fù)”出發(fā)。寫一個類型定義、一個接口契約不再只是“做文檔”——它是給 AI 劃定可以工作的邊界，讓它越界的時候你能立刻發(fā)現(xiàn)。寫日志、寫監(jiān)控、寫告警、寫灰度、寫回滾——這些過去被認(rèn)為是“運維相關(guān)”的工作，今天變成核心工程能力。因為 AI 寫的代碼上線之后，你不再能像過去那樣“讀懂每一行所以放心”，你只能靠這些機制在它出錯時第一時間知道。

代碼評審也在變。過去你審的是“這段代碼寫得對不對、漂亮不漂亮”。今天 AI 一天可以提交幾十個變更，你按這種速度審根本審不完——審不完不是程序員的問題，是審的方法已經(jīng)不對了。新的審法是審驗證機制本身：這個變更有沒有對應(yīng)的需求級測試、有沒有可觀測性兜底、有沒有能在三十秒內(nèi)回滾的開關(guān)。審一段代碼可能要十分鐘，審“這段代碼周圍的安全網(wǎng)齊不齊”可能只要一分鐘。

Anthropic 自己的工程博客把這個判斷寫得很直白——模型再強，給它一個高層提示讓它自己跑，它做不出生產(chǎn)級產(chǎn)品。讓它能跑穩(wěn)的，是套在模型外面那一圈他們叫 harness（直譯大概是“挽具”，可以理解為給 AI 套上的工作骨架）的東西。換句話說，能不能交付高質(zhì)量產(chǎn)品，不取決于模型能力，取決于框架設(shè)計能力。這不就是把“工程師的活”重新定義成“建框架而不是寫代碼”嗎？

GitHub 2024 年開源的 Spec Kit、亞馬遜 2025 年發(fā)布的 Kiro，都在沿著這條路推——把規(guī)范當(dāng)成可執(zhí)行的、第一類的工件，先寫規(guī)范再寫代碼。規(guī)范驅(qū)動開發(fā)這個詞在國內(nèi)圈里也開始火起來。這不是孤立的產(chǎn)品發(fā)布，是一個行業(yè)方向。

7 那 5 到 10 年經(jīng)驗的你，應(yīng)該開始做哪些準(zhǔn)備

回到本篇文章的目標(biāo)讀者——已經(jīng)在用 AI 寫代碼、但還沒把“怎么用 AI”系統(tǒng)化的 5 到 10 年經(jīng)驗的工程師。如果上面這套判斷是對的，這一陣子你應(yīng)該開始準(zhǔn)備幾件具體的事。

學(xué)會寫“需求驅(qū)動”的測試，而不是讓 AI 看著實現(xiàn)給你反推一份。具體做法是：拿到任務(wù)后先閉眼把“用戶怎么用、會踩哪些邊界、出錯怎么恢復(fù)”列一遍，列完再讓 AI 寫代碼、再把這份清單變成測試。這個動作 AI 替不了你。

把過去你認(rèn)為是“運維或基礎(chǔ)設(shè)施團隊管”的那些事——可觀測性、灰度、回滾——納入你日常代碼工作的一部分。這是你新的安全網(wǎng)，AI 寫得越快越多，這張網(wǎng)就要越密。

重新校準(zhǔn)你的代碼評審節(jié)奏。不要再花時間審風(fēng)格、審命名——這些 AI 已經(jīng)能管。把時間花在審“這段變更周圍的驗證機制是否齊全”上。

主動找一些 AI 不擅長的活兒——業(yè)務(wù)邊界模糊的需求拆解、跨團隊接口的對齊、老代碼的判斷式重構(gòu)、灰色地帶的產(chǎn)品決策——把這些當(dāng)成你的核心戰(zhàn)場，把可以讓 AI 跑的部分堅決讓出去。

最后說回 Boris 那句話。“編程被解決了”聽起來像一個時代的終結(jié)。但如果你聽完整期播客就會發(fā)現(xiàn)，他自己的工作并沒有變得輕松——他從寫代碼的人變成了同時操控五個智能體、每天審一堆合并請求、不停做架構(gòu)決策和驗證機制設(shè)計的人。他失去的是“親手敲代碼”這件事帶來的心流和踏實感，得到的是更高的杠桿和更模糊的責(zé)任邊界。

這不是一個程序員失業(yè)的故事，是一個程序員的工作內(nèi)容被重新定義的故事。重新定義之后，你這 5 到 10 年攢下來的東西——對系統(tǒng)的整體感、對邊界條件的直覺、對什么會出錯的嗅覺、對人和需求的理解——其中相當(dāng)大一部分非但沒有貶值，反而比過去任何時候都更值錢。前提是你愿意把“會寫代碼”這塊勛章先放下。

參考來源

• Lenny Rachitsky.「Head of Claude Code: What happens after coding is solved（Boris Cherny 訪談）」. Lenny's Podcast, 2026 年 2 月. https://www.lennysnewsletter.com/p/head-of-claude-code-what-happens

• Andrej Karpathy.「Introducing nanochat: The best ChatGPT that \$100 can buy」. GitHub Discussions, 2025 年 10 月. https://github.com/karpathy/nanochat/discussions/1

• Anthropic.「Effective harnesses for long-running agents」. Anthropic Engineering Blog, 2025 年. https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents

• Simon Willison.「Not all AI-assisted programming is vibe coding (but vibe coding rocks)」. simonwillison.net, 2025 年 3 月. https://simonwillison.net/2025/Mar/19/vibe-coding/

• Salvatore Sanfilippo (antirez).「Coding with LLMs in the summer of 2025 (an update)」. antirez.com, 2025 年. https://antirez.com/news/154

• GitHub.「Spec Kit: Toolkit for Spec-Driven Development」. github.com, 2024 年 9 月起. https://github.com/github/spec-kit

• 經(jīng) Stack Overflow Blog 引用的斯坦福數(shù)字經(jīng)濟實驗室數(shù)據(jù).「AI vs Gen Z」. Stack Overflow Blog, 2025 年 12 月. https://stackoverflow.blog/2025/12/26/ai-vs-gen-z/

• 一項關(guān)于 AI 生成單元測試有效性的實證研究. arXiv:2406.18181, 2024 年. https://arxiv.org/html/2406.18181v1

• smile-design 項目源碼與規(guī)范、記憶三件套. https://github.com/smilezyl2023/smile-design

關(guān)于文中未展開的那個問題 --如果 AI 持續(xù)吞噬初級崗位，未來五到十年后的資深工程師從哪里來? 中高級工程師的培養(yǎng)鏈條將如何延續(xù)?如果你對這一話題有自己的觀察、經(jīng)驗或觀點，歡迎聯(lián)系本文編輯，一起討論。