AI時代，別再提“人人都是程序員”了

原文標題：《Codex新用戶超兩成都不是專業開發者，但千萬別說“人人都是程序員”》，作者：Zetze，審校：凱文，題圖來自：視覺中國

6 月初，OpenAI 公布了一組頗具象征意味的數據：Codex 周活躍用戶已突破500萬，較 2 月桌面版發布時增長超過6倍；更值得注意的是，在過去一個月新增的 Codex 用戶中，分析師、營銷人員、運營人員、設計師、研究人員、投資者等非開發者占到了 20%，且增長速度超過開發者 3 倍。這個最初為軟件開發而生的工具，正在迅速進入泛化階段，參與更多人的日常工作，讓更多以前調用開發資源相對困難的人，低門檻的獲得了代碼能力。

OpenAI 同時推出了可以把工作成果直接轉化為托管網站和應用的 Sites 功能。用戶不只可以讓 Codex 處理文件和數據，還可以生成一個能夠通過 URL 分享的交互式工具。這也就意味著，一個原本從事數據分析崗位的人可以利用Codex 快速完成原本要申請開發團隊資源才能夠完成的可視化互動模型，直接打包成一個可發布的互動頁面，大大提高了工作效率。編程工具正在變成通用生產工具，軟件創造也第一次如此大規模地走出開發部門。

乍看之下，這似乎是“人人都是程序員”的又一個證據：當市場、運營和研究人員都開始調用編程智能體，當一個想法可以直接變成網站和應用，程序員與普通人的邊界似乎正在消失。

相比較 Codex 在持續弱化自己專業編程工具，力圖給自己貼上通用生產力標簽的同時，WWDC 2026 上蘋果對 Xcode 的更新提供了一個很關鍵的補充視角：在 AI 能力迅速進入寫代碼環節的同時，專業開發工具的理念并沒有被削弱，反而進一步把 Agent 深度嵌入到開發流程中——讓它可以參與構建、運行測試、分析錯誤，并通過與工具鏈的協作來完成修復與迭代。這種設計意味著 AI 不只是“生成代碼的助手”，而是被納入了一個真實的工程執行閉環之中，并在 IDE 的約束下與構建系統、測試系統和預覽系統共同工作。

這兩件事同時發生，或許才是 AI Coding 當下最真實的圖景：越來越多人可以借助 AI 創造軟件，但能夠生成軟件，并不等于自動擁有了工程能力。

有一種關于 AI Coding 的流行敘事正在變得越來越廉價：只要會說話，人人都能成為程序員。

這句話聽起來很有時代感，也足夠鼓舞人。它暗示軟件創造的門檻正在消失，過去需要多年訓練才能掌握的編程能力，如今可以被幾句自然語言提示詞替代。一個不會寫代碼的人，也許只要打開 Cursor、Claude Code 或者某個 AI Agent，就能做出自己想要的產品。

這當然不是全錯。

歷史上也許從來沒有一個時刻，普通人距離“把一個想法變成可運行的軟件”如此之近。一個略懂產品、略懂業務、略懂計算機概念的人，今天確實可以借助 AI 做出過去很難獨立完成的東西。一個原本只有 0.3 分能力的人，可能被 AI 放大到 0.8，甚至 0.9。

但問題也在這里：AI 可以放大 0.3，卻很難憑空生成那最初的 0.3。

如果一個人不知道自己到底想要什么，不知道如何描述問題，不知道什么叫邊界條件，不知道一個軟件從 Demo 變成服務需要經歷什么，也不知道錯誤應該在哪里被暴露、數據應該如何被組織、系統應該如何被維護，那么 AI 帶來的往往不是創造力的爆發，而是混亂的加速生成。

所以，AI 時代當然會出現更多“能做軟件的人”。但這并不等于人人都是程序員。

更準確地說，AI 正在放大一種能力：結構化理解世界、拆解問題、組織上下文、調用工具，并為結果負責的能力。程序員只是最早被迫系統訓練出這種能力的一群人。

在和一位長期深度使用 AI Coding 的資深工程師交流時，他反復提到一個判斷：AI Coding 最容易被誤解的地方，是人們總把它想象成“讓 AI 寫代碼”。出于職業身份和項目信息的考慮，本文稱他為 CC。在 CC 的實踐里，AI 真正改變的并不是敲代碼的速度，而是整個研發過程里“理解、表達、驗證和協作”的方式。

CC 的幾個經歷，恰好能說明這個變化。

一個人和 AI 都讀不懂的項目

很多人第一次理解 AI Coding，是從“它能替我寫代碼”開始的。但在真實的軟件現場，AI Coding 最有價值的時刻，往往不是寫新代碼，而是讓舊系統重新變得可理解。

CC 曾接手過一個歷史項目。項目原先由一位算法背景很強、但工程經驗并不充分的開發者長期維護。項目核心是一組龐大的 Python 腳本，單個文件動輒幾千行。業務邏輯、數據處理、模型調用、文件讀寫、異常處理混在一起，模塊邊界模糊，命名風格不統一，重復邏輯到處散落。

更復雜的是，這個項目里還夾雜著早期 AI 補全時代留下的代碼。當時模型能力有限，AI 更像一個智能補全器，而不是今天意義上的編碼 Agent。它能生成一些局部片段，卻很難理解系統整體。于是項目逐漸變成了一個奇怪的混合體：算法專家的快速實驗代碼，加上早期 AI 補全生成的碎片，再加上長期缺乏工程治理積累下來的技術債。

對人來說，它幾乎不可讀。對 AI 來說，它同樣不友好。

這點經常被忽視。過去我們說代碼要“對人友好”，意味著結構清晰、命名明確、模塊邊界合理、文檔足夠完整。到了 AI Coding 時代，代碼還要“對 AI 友好”。一個幾千行的巨型腳本，不只是折磨接手項目的人，也會嚴重消耗模型的上下文窗口和推理能力。模型越難理解系統，就越容易在局部改動中制造新的混亂——注意：AI幾乎不可能告訴你“我看不懂這段代碼”，但這可能是更大災難的到來，說明它要準備瞎編了。

CC 后來復盤這段經歷時說，接手這種項目時，最自然的沖動可能是馬上重構。但真正有效的第一步不是動代碼，而是讓系統顯影。

CC 的做法是，讓 AI 扮演架構師，逐步閱讀代碼庫，梳理模塊關系、調用鏈路、數據流向和關鍵職責。讓它生成一份可以 onboarding 的文檔，畫出流程圖和設計圖。再由人根據自己的工程經驗去校準這些文檔：哪里是主鏈路，哪里是歷史包袱，哪里只是臨時繞路，哪里是業務上必須保留的復雜性。

這時，AI 的角色不是“替你寫代碼的實習生”，而更像一臺結構顯影儀。它把原本埋在幾千行腳本里的系統形狀重新照出來，讓人可以開始討論它、切分它、修改它。

在這個項目里，真正的轉折點就發生在這一步之后。等系統結構被重新看見，重構才變得可行：文件結構被重新劃分，模塊邊界逐漸出現，重復邏輯被抽取，可測試性增強，運行穩定性提升。更重要的是，用 CC 的說法，項目重新變得可維護了。

這里的“可維護”不僅是對人而言，也是對 AI 而言。

一個結構清晰的代碼庫，會讓后續 AI Agent 更容易理解上下文，更容易做小步安全修改，更容易根據測試反饋修正問題。反過來，一個混亂的代碼庫會同時拖垮人和 AI。AI Coding 并不會神奇地繞過工程復雜性。它只是讓工程質量的好壞，以更快的速度顯現出來。

這也是為什么“人人都是程序員”的說法會誤導人。AI 不是把工程能力取消了，而是把工程能力變成了更底層的基礎設施。

Demo 和服務之間，隔著一整套工程責任

Vibe Coding 最迷人的地方，是它讓軟件創造變得像說話一樣自然。

你描述一個想法，AI 給出頁面；你再補一句需求，AI 接著生成接口；你說這里不好看，它替你調樣式；你說想加登錄、支付、數據看板，它似乎也都能往前推進。一個晚上做出一個 Demo，這件事已經不再稀奇。

但 Demo 和服務之間，隔著一整套工程責任。

Demo 的目標是“看起來能用”，服務的目標是“長期可用”。Demo 可以容忍數據結構混亂、異常處理粗糙、權限模型簡化、部署流程手工化、日志缺失、測試缺位。服務不行。服務要面對真實用戶、真實數據、真實并發、真實成本、真實安全風險，以及真實的后續維護。

這也是很多 Vibe Coding 文章最容易講淺的地方。它們樂于展示“一個不會寫代碼的人做出了一個 App”，卻很少繼續追問：這個 App 能不能穩定運行？出了問題誰排查？數據壞了怎么辦？權限泄露怎么辦？業務規則變化后如何迭代？半年后還有人看得懂嗎？

能跑起來，是軟件生命的開始，不是結束。

CC 后來做過一個更復雜的業務系統項目。出于商業保密，這里不展開具體行業和客戶，只保留問題形態：它并不是一個單純的技術項目，而是一場從線下紙質流程到線上數字化系統的遷移。它需要理解不同崗位的工作方式，觀察真實流程，而不是只聽一句“我們想做個系統”。它需要把業務語言翻譯成數據表、權限規則、審批流、統計口徑、接口邊界和異常場景。

這種項目復雜的地方，并不在于某個單點技術有多炫。真正復雜的是業務細節和數據關系：幾十張表之間如何關聯，數百個 API 如何組織，不同角色如何使用同一套數據，不同流程之間如何互相影響。過去，這類項目往往需要產品、后端、前端、測試、運維等多種角色協同。

AI 的確改變了這里的效率結構。一個有經驗的人，可以借助 AI 把很多過去需要多人分擔的工作串起來。但前提是，他必須知道該把什么上下文交給 AI。

這就是 AI Coding 和普通代碼生成的分水嶺。

AI Coding 的本質不是寫代碼，而是寫上下文

今天更成熟的 AI Coding，已經越來越不像“打開聊天框讓 AI 寫函數”，而像一條端到端的研發鏈路。CC 把自己的做法概括為：盡可能替 AI 構建足夠豐富的上下文，然后讓 AI 在這個上下文里工作。

在 CC 的工作流里，一個需求通常不是從“請幫我寫代碼”開始，而是先把產品 PRD、需求文檔、需求評審會議的逐字稿、上下游系統的技術文檔、已有代碼庫和項目規范都提供給 AI。然后讓 AI 基于這些材料生成技術方案。方案不是直接進入開發，而是先沉淀成一篇文檔，交給工程師、產品和相關業務同事 review。

這一步很關鍵。

因為 AI 的輸出不是用來跳過溝通的，而是用來提升溝通質量的。過去，很多需求評審的問題在于不同角色腦中的系統模型并不一致。產品說的是用戶流程，工程師想的是數據結構，業務同事關心的是線下例外情況，上下游關心的是接口契約。AI 可以把這些散落的材料先組織成一個可討論的版本，讓團隊更早發現理解偏差。

確認技術方案后，再進入編碼、單元測試、回歸測試和人工驗收。開發完成后，CC 還會讓 AI 繼續生成對接文檔。這個文檔表面上是給上下游同事看的，但在 AI Agent 普及之后，它還有一個新的用途：成為別人 Agent 的上下文。

這是一種很有意思的變化。過去，文檔主要寫給人讀；今天，文檔也開始寫給 AI 讀。接口說明、業務規則、驗收標準、錯誤碼、數據樣例，都會成為另一個 AI Agent 開發對接功能時的輸入。

于是，所謂 AI Coding 的核心對象發生了變化。

過去我們寫代碼，今天我們也在寫上下文。這里的上下文不是一段 prompt，而是一個工作場：需求文檔、會議記錄、代碼庫、測試用例、日志、項目規范、技術決策、驗收標準、接口文檔、歷史討論，都在其中。

誰能組織更好的上下文，誰就能更好地使用 AI。

這也是為什么“會 prompt 就夠了”是另一個誤解。真正重要的不是某句神奇提示詞，而是你能否把一個模糊問題整理成 AI 可以理解、可以執行、可以驗證的結構。提示詞只是入口，上下文才是主體。

如果上下文是錯的，AI 會高效地產生錯誤。如果上下文是亂的，AI 會高效地放大混亂。如果上下文缺少驗收標準，AI 就會傾向于給出“看起來完成了”的結果。

AI Coding 的上限，不只由模型決定，也由人類組織上下文的能力決定。

程序員并沒有被 AI 取代，他們正在用 AI 進入各行各業

“程序員要失業了”是 AI 浪潮里最常見的句式之一。

程序員自己說這句話，很多時候是自嘲。這個行業長期站在技術變化前沿，習慣了每隔幾年就被新的語言、框架、平臺、范式重新教育一遍。自嘲背后，往往有真實焦慮，也有對變化的敏感。

但當這句話被簡化成“AI 會寫代碼，所以程序員不重要了”，它就變成了一種外行式誤判。

編程當然包含寫代碼，但程序員的核心能力從來不只是記住語法。一個合格程序員長期訓練的是另一組能力：把模糊需求拆成明確任務，把復雜系統拆成模塊，把異常情況前置考慮，把重復勞動抽象成工具，把現實世界的不確定性壓進可以運行、可以調試、可以維護的結構里。

這些能力恰恰是 AI 時代更容易被放大的能力。

如果一個程序員缺少設計能力，AI 可以補一部分產品原型；缺少前端審美，AI 可以補一部分界面實現；缺少運維經驗，AI 可以解釋云服務、生成部署腳本、定位日志問題；缺少寫作能力，AI 可以協助生成文檔、郵件和方案。換句話說，AI 不只是讓程序員寫代碼更快，也讓程序員更容易補齊跨界短板。

所以，更值得注意的現象也許不是“程序員正在被各行各業取代”，而是“程序員正在借助 AI 進入各行各業”。

當一個擁有工程思維的人獲得產品、設計、運營、數據分析和寫作能力的外骨骼，他能做的事情會比過去寬得多。反過來，一個完全沒有結構化表達能力、沒有系統概念、沒有邊界意識的人，即使拿到最強的 AI 工具，也很容易卡在第一步：不知道該如何描述自己想要什么。

這并不是說非程序員不能使用 AI 做軟件。恰恰相反，AI 的確讓很多非技術背景的人第一次擁有了軟件創造能力。但他們真正需要補的，不是“語法”，而是問題定義、需求表達、流程拆解和結果驗收。

AI 降低的是編碼門檻，不是思考門檻。

甚至可以說，AI 越強，思考門檻越顯眼。因為工具越能快速執行，錯誤的方向就越容易被快速放大。過去一個模糊需求可能在漫長開發過程中慢慢暴露問題；現在，它可能在一天之內變成一個結構混亂但頁面完整的系統。

這不是民主化的反面，而是民主化之后的新門檻。

AI 最危險的地方不是寫錯

對 AI Coding 的批評，常常集中在“AI 會寫 bug”。但在真實工程里，更麻煩的情況不是它寫錯，而是它把錯誤隱藏起來。

CC 在一個數據科學相關項目中，曾經遇到過一種很典型的問題：無論輸入數據多離譜，程序最終似乎總能輸出結果。表面看，這是系統“魯棒性”很強；但按業務邏輯判斷，某些輸入本應在中間環節觸發錯誤，提醒開發者數據不合法、流程不完整或假設不成立。

后來的人工排查發現，問題出在一系列 AI 生成或補全的兜底邏輯上。它在很多環節加了默認值、try-catch、空值兼容和靜默降級。每個局部看起來都像是在“增強穩定性”，但串起來之后，系統變成了一個幾乎不會失敗的黑箱。

這恰恰很危險。

工程系統里，失敗不是壞事。該失敗的時候失敗，錯誤才能被及時暴露；該拋異常的時候拋異常，系統邊界才是清晰的。尤其在數據科學、金融、醫療、教育等領域，一個“永遠給出結果”的系統未必可靠，反而可能意味著它正在掩蓋異常。

AI 為什么喜歡這樣寫？一個可能的原因是，它在訓練和交互中更容易被獎勵“完成任務”。用戶說修復錯誤，它就傾向于讓報錯消失；用戶說程序不要崩，它就傾向于加兜底；用戶說保證輸出，它就傾向于制造默認路徑。但在工程里，報錯消失不等于問題解決，程序不崩不等于邏輯正確，有輸出不等于有價值。

這就是人類工程師仍然重要的地方。

人要告訴 AI：哪些錯誤必須暴露，哪些異常不能吞掉，哪些輸入必須拒絕，哪些鏈路必須 fail fast，哪些關鍵環節需要顯式校驗。更進一步，這些規則不應該只停留在口頭，而應該沉淀進項目規范里，放在代碼庫根目錄，隨 git 一起提交。

這會帶來一個新的協作模式：人制定規則，AI 執行規則。

過去，團隊代碼規范依賴培訓、文檔、code review 和個人習慣。讓所有人持續遵守一套規范很難，因為人會遺忘、偷懶，也會在趕進度時妥協。今天，很多規范可以寫成 AI Agent 能讀取的項目約束：異常處理原則、命名規范、測試要求、禁止行為、提交標準、驗收清單。不同成員的 Agent 進入代碼庫后，都能讀取這些規則，并在開發中自動遵守。

這不是說 code review 不重要了，而是規范執行的起點前移了。AI 讓團隊有機會把“工程共識”變成更可執行的上下文。

從這個角度看，未來優秀工程師的一項重要工作，不只是寫業務代碼，而是維護一套能讓 AI 正確工作的規則系統。

那最初的 0.3 是什么？

如果 AI 可以把 0.3 放大到 0.9，那么問題就變成：那最初的 0.3 到底是什么？

對專業開發者來說，它越來越不是某個具體框架的熟練度。框架會變，工具會變，模型能力也會快速提升。今天困擾開發者很久的隱藏 bug，也許明天換一個新模型就能被直接定位。很多現在看起來需要技巧的問題，都會逐漸被更強的模型能力吞掉。

但有些東西不那么容易被吞掉。

比如業務理解。你要知道一個需求為什么存在，哪些流程是真需求，哪些只是歷史習慣，哪些例外情況必須保留，哪些復雜性可以被砍掉。AI 可以根據材料生成方案，但它很難替你判斷一個組織真正需要什么。

比如 spec 能力。也就是把需求寫清楚的能力。一個好的 spec 不只是描述“我要什么功能”，還要描述邊界、狀態、數據結構、角色權限、異常場景、驗收標準和非目標。AI 越強，spec 越重要，因為 spec 決定了 AI 執行的方向。

比如驗收能力。AI 可以寫測試，也可以跑回歸，但人要知道什么叫真正通過。頁面能打開不代表業務正確，接口返回 200 不代表數據可信，模型給出結果不代表結論可用。

比如系統判斷。什么時候繼續讓 AI 修，什么時候人該接管；什么時候補測試，什么時候重構；什么時候接受局部不完美，什么時候必須推倒重來。這些都不是一句 prompt 能解決的。

對非專業開發者來說，最初的 0.3 也許更基礎：能不能描述清楚自己想要什么，能不能把一個大想法拆成幾個小問題，能不能意識到軟件不僅有頁面，還有數據、權限、部署、成本和維護。

很多人以為自己缺的是編程語言，其實第一步缺的是需求表達。

這也是 AI 時代一個很有意思的變化：表達能力變得前所未有地重要。過去，表達不清楚最多影響人與人溝通；今天，表達不清楚會直接影響 AI 的執行結果。一個模糊的想法，會被 AI 快速變成一個模糊的系統。

當然，AI 也能幫助人補齊短板。云服務、計算機網絡、數據庫、部署流程，這些過去讓非技術人望而卻步的知識，如今都可以通過 AI 快速解釋和輔助執行。只要問題描述得足夠清楚，AI 確實能帶人跨過很多過去很高的門檻。

但這仍然不是“零門檻”。

AI 時代的門檻從“會不會寫代碼”，轉移到了“會不會定義問題、組織上下文、判斷結果”。

別再說人人都是程序員了

“人人都是程序員”之所以流行，是因為它抓住了一個真實趨勢：軟件創造正在從少數專業人士手里擴散出去。

這個趨勢當然值得歡迎。更多人可以把自己的想法做成工具，更多小團隊可以用更低成本完成數字化，更多行業知識可以直接轉化成軟件原型。AI 讓創造軟件這件事，第一次真正接近大眾。

但如果因此認為專業性不再重要，就走向了另一個誤區。

AI Coding 不會消滅工程能力，它會重估工程能力。它不會讓所有人自動成為程序員，它會讓那些具備結構化能力、學習能力、業務理解和責任意識的人獲得更強的生產力。它不會讓代碼質量問題消失，它會讓質量問題以更快速度出現，也讓治理質量問題的能力更重要。

從這個意義上說，AI Coding 最重要的改變不是“代碼由誰敲出來”，而是“誰來定義問題、組織上下文、建立規則、驗證結果，并為系統負責”。

未來的軟件工程師可能會少寫一些機械代碼，但會更多地寫 spec、寫上下文、寫測試、寫規則、寫文檔、寫給其他 AI Agent 讀取的協作材料。軟件開發的中心，正在從“代碼輸入”轉向“上下文組織”。

這不是程序員消失的開始，而是程序員角色重組的開始。

AI 的確可以把 0.3 放大到 0.8，甚至 0.9。這是這個時代真正令人興奮的地方。一個人只要具備一點點計算機基礎、業務理解、表達能力和結構化思維，就可能做出過去需要一個小團隊才能完成的東西。

但如果沒有那最初的 0.3，一切都是空話。

AI 不會替你知道你想要什么，不會替你承擔后果，也不會自動理解一個組織、一個行業、一套業務流程背后的真實復雜性。它可以生成代碼，也可以生成文檔、測試和方案，但它無法替代人對問題本身的理解。

所以，AI 時代，別再說人人都是程序員了。

更準確的說法是：人人都更接近軟件創造，但不是人人都自動擁有工程能力。

AI 放大的不是職業標簽，而是人的基本功。

本內容由作者授權發布，觀點僅代表作者本人，不代表虎嗅立場。如對本稿件有異議或投訴，請聯系 tougao@huxiu.com。

本文來自虎嗅，原文鏈接：https://www.huxiu.com/article/4867009.html?f=wyxwapp