從無人問津到巨頭混戰，AI為什麼最先點燃了編程？

AI編程，可能是當下最大的原生AI應用賽道。

這聽起來有點反直覺，因為在過去幾十年里，「開發工具」從來不是軟件行業里最賺錢的賽道。可如今，這一切都變了。

這個市場可比你想像得要大得多。

全球大約有 3000 萬名軟件開發者。如果每個人每年創造 10 萬美元的經濟價值，那這一群體的總產值就是 3 萬億美元，幾乎相當於一個法國的 GDP。

根據 a16z 團隊與數十家科技公司交流的結果，現在哪怕只是最基礎的 AI 編碼助手，也能讓開發效率提升 20%。而在理想部署下，效率翻倍完全可能。

開發效率提升背後，是整個軟件行業的重估。背後的邏輯其實很簡單：開發效率越高，總需求就越大；開發越快，軟件就越多。

換句話說，AI 編程有望為全球經濟帶來額外3萬億美元的產值，而這僅僅是開始。

如今，AI編程不僅撐起了一批估值數十億美元的初創公司，更有望孕育出下一個萬億美元級別的科技巨頭。這也是為什麼越來越多玩家開始湧入到AI編程賽道：

Cursor在短短15個月內做到了年收入5億美元，估值接近100億；Google砸下24億美元搶下Windsurf；Anthropic 推出了Claude Code；OpenAI的GPT-5也強化了編程能力。

可以看到，AI 編程的戰國時代，已經全面打響。接下來，AI 編碼會長成什麼樣？還沒有定論，但雛形已經顯現。

最近，A16Z就發佈一篇AI編程的文章，系統拆解了這個新興領域的結構：從工具鏈的創新到協作方式變化，展示了一個正在重塑的軟件開發未來。

軟件開發的範式變了

過去，用 AI 寫代碼，是這樣的流程：你先問它一句「幫我寫個登錄接口」，它回你一段代碼，你再複製黏貼進項目里。這種「點菜式」編碼方式，已經逐漸落伍了。

現在，一種全新的開發範式正在流行，被稱為「計劃→ 代碼→審查」。不再是人提問、AI 回答，而是從頭到尾，AI 全程參與：

先規劃：AI 負責幫你起草一個詳細的功能描述，並主動提出它需要哪些信息，比如 API 密鑰、訪問權限、系統依賴。

再編碼：AI 根據規劃自動生成代碼，甚至能完成單元測試，過程中形成一個小型的「代理循環」。

最後審查：人類開發者只是檢查 AI 的工作，必要時微調。

這張圖展示的是一個新項目啟動時，AI 介入的典型流程。它的第一步任務，是寫一份高級功能說明書。它會主動提出一連串問題，要求補全所有它認為關鍵的背景信息。

這些問題和請求往往涉及需求細節、架構決策、外部依賴、權限配置等，甚至會明確要你提供 API 密鑰、工具訪問權限等實際操作條件。最終形成的，是一份長達數頁、結構完整的附加信息清單。

這一套規範文檔有兩個價值。一方面，它能準確指導後續的代碼生成，確保模型寫出來的內容和開發意圖對齊；另一方面，它還能作為整個項目的「長期記憶」，幫助開發者或其他模型理解某個模塊或文件的功能。特別是在大型項目中，代碼庫往往非常複雜，一份清晰的規範就是維持秩序的錨點。

而這個過程不是一次性的。人類開發者在修改代碼之後，通常還會讓語言模型回過頭去更新規範文檔，保證這份說明始終跟隨代碼的最新狀態。最終形成的，是一套「文檔齊全」的工程產出，既方便人類查閱，也方便 AI 接續任務，真正實現了人機協作下的良性循環。

除了每個項目自身的需求，現在大多數 AI 編碼系統還會配備一整套通用的架構和編碼規範。這些規範有的覆蓋整個公司，有的專門針對某個項目或模塊，主要用來約束代碼風格、架構選擇、接口設計等技術細節，讓開發工作有章可循。

更有意思的是，現在網上也出現了不少為 AI 模型量身打造 的「最佳實踐合集」，比如 Cursor 的規則集、GitHub 社區里分享的 prompt 模板，甚至 Claude Code 相關的開發說明。

這類內容不是寫給人看的，而是專門寫給 AI 模型讀的。

我們正在見證一種新型知識庫的出現——它不再是為了培訓新員工，而是為了讓 AI 成為真正的協作夥伴。

在這個新範式下，AI 已經不只是你說一句、它寫一段的工具，而是可以參與整個產品開發的「隊友」。它能理解公司的技術政策、掌握項目背景，甚至熟悉行業標準，具備越來越強的上下文理解力。它不再只是執行命令，而是可以參與架構設計、功能規劃，甚至提前發現潛在風險。

而在項目規劃環節，雖然 AI 的角色還處於早期探索階段，但已經有不少公司在嘗試把它引入更上遊的流程。

比如，Nexoro這一類工具，主打信息整理，可以自動從Slack、論壇、郵件、CRM 系統（比如 Salesforce、Hubspot）中提取客戶反饋，彙總成一份「用戶想要什麼」的清單。

另一類工具，比如 Delty 和 Traycer，則更聚焦在「任務拆解」這一步。它們能把一段功能說明，自動轉換成可執行的用戶故事，接著同步到 Linear 這樣的工單系統中，輔助團隊推進開發。

這些趨勢釋放了一個非常明確的信號：過去那種靠域奇文檔、手動維護任務追蹤器的方式，已經逐漸跟不上今天快節奏、複雜度高的項目需求。

傳統工具不是慢慢被淘汰，就是得被 AI 重構一遍，變得更智能、更高效、更自動化。軟件開發的協作方式，正在被重新定義。

從寫代碼，到編程「搭子」

一旦前期的計劃完善，接下來就是進入 AI 編碼的「循環流程」：AI 先寫代碼，開發者再審核和微調。這一過程會不斷迭代，而具體用什麼樣的交互方式，取決於任務的複雜程度和是否需要異步執行。

最常見的一種方式是「Tab 補全」和「智能編輯」功能，這類功能已經被無縫集成進了很多現代代碼編輯器，比如 Cursor、Windsurf、Sourcegraph Amp，甚至是各種 VSCode 插件里。

用戶只要在編輯器中正常寫代碼，AI 就會根據上下文自動補全當前行，或者對局部內容進行修改，幾乎不需要手動觸發提示。這類能力背後依賴的是專門調優過的小模型，既輕量又反應快，能夠在本地快速響應，提高開發效率。

另一種更靈活的方式，是「基於聊天」的文件編輯體驗。用戶可以直接對 AI 下指令，比如「幫我把這個函數改成異步的」，同時提供相關上下文。AI會調用具備大上下文窗口的大模型，對整個項目文件夾進行全局理解，甚至可以跨文件操作，比如創建新文件、添加依賴包等。

這類工具既可以嵌入IDE，也可以通過網頁使用，每一步都有可視化反饋，方便用戶快速確認修改結果。

簡單來說，AI 編碼正在從「寫幾行代碼」走向「協同完成整個開發任務」，交互方式也越來越多元，既有即時響應的輕量模型，也有具備全局理解的大模型配合，讓不同需求的開發者都能找到適合自己的工作方式。

後台運行的 AI 代理和普通AI助手有點不一樣。它們不需要人一直在旁邊交互，而是可以長時間獨立工作，自動推進任務。這類代理通常會自己運行測試，確保結果沒問題——畢竟用戶不在現場，系統必須有辦法自己判斷對錯。

這些AI最終的產出，往往是已經修改好的代碼樹，或者一份準備提交到Git 倉庫的Pull Request（代碼合併請求）。像 Devin、Anthropic Code、Cursor 的後台 Agent，就是這類「靜默工作型」AI的代表。

與此同時，還有一類工具也在快速興起，那就是AI 應用構建器和原型工具。比如 Lovable、Bolt（Stackblitz 旗下）、Vercel v0 和 Replit 等平台，正在嘗試用自然語言、線框圖，甚至簡單的 UI 示例，直接生成一整個能運行的應用，而不僅僅是前端頁面。

這些工具正在吸引兩類人：一類是希望快速做出MVP的創業者或設計師，另一類則是想用 AI 快速試錯、搭建原型的專業開發者。雖然現在還很少有人直接把這些 AI 生成的界面代碼用到正式上線的項目里，但這更多是因為工具還在成長階段，而不是方向不對。

未來，等它們穩定性提升，AI 寫 UI 寫後端、連數據庫、接 API，可能就真成了全棧「搭子」。我們距離「說一句話生成一款 App」的那一天，或許沒那麼遠了。

隨著 AI 代理在項目中的角色越來越重，開發者關注的重點也發生了轉變。過去，我們更在意「代碼是怎麼改的」；而現在，重點變成了「為什麼要這麼改」和「改完有沒有效果」。尤其是當 AI 一次性生成整個文件時，傳統的「diff（差異）比較」方式就顯得沒那麼有用了。

於是，一些新工具開始重新定義「版本控制」這件事。比如Gitbutler，它的思路不再是盯著文件內容一行行怎麼變，而是圍繞「意圖」來記錄開發過程：

AI 是怎麼理解需求的？用了什麼提示詞？測出來效果怎麼樣？這些信息比單純的代碼差異更有價值。Git變成了後台的「賬本系統」，而真正有意義的操作，發生在「語義層」——也就是目標、決策和結果的軌跡。

與此同時，AI 也越來越多地參與到源代碼管理系統（如 GitHub）本身。現在，不少團隊已經在讓 AI 參與 Issue 和 Pull Request 的討論。這些討論內容本身就是一種「上下文輸入」，能讓 AI 更好地理解開發意圖，從而給出更貼切的實現方案。

而在代碼審查環節，AI 也開始擔任「審查官」的角色。它會聚焦於代碼的正確性、安全性、合規性，輔助開發者提升代碼質量。像 Graphite、CodeRabbit 就是做這一方向的代表，正在探索「AI審查AI」的全新開發協作模式。

現在，大多數 AI 編碼助手的工作流程已經高度自動化了。也就是說，它們會自主決定下一步該做什麼，還會調用各種工具完成任務（在 Hugging Face 等框架中被稱為「3 星」能力）。比如，像文本小改、更新一個庫、加一個簡單功能這類任務，現在很多時候都可以完全由 AI 獨立完成，無需人類介入。

這個趨勢也帶來了一些「高光時刻」。比如，GitHub 上一個討論功能的 issue，最後只留下一句「@aihelper 請實現」，幾分鐘後，AI 就自動生成了一個幾乎完美的 Pull Request，直接合併上線。雖然目前這種「神來之筆」還不常見，但在簡單場景中已經開始成為可能。

相比之下，更複雜的開發任務仍然需要人類參與決策，但有一個領域已經被證明特別適合 AI，那就是遺留代碼遷移。這是目前 AI 編碼最成熟、效果最好的落地場景之一。

常見的例子包括：把 Fortran 或 COBOL 這樣的老語言遷移到 Java，把 Perl 轉成 Python，或者替換掉已經過時的 Java 類庫。一種典型做法是，先讓 AI 從舊代碼中提取出功能規範，再根據這個規範用新語言重新實現。舊代碼不再直接複製黏貼，而是變成瞭解決歧義的「對照組」。

這一方向的市場潛力非常大，已經有不少初創公司專注於這個賽道。尤其是在金融、製造等大量依賴老系統的行業，AI 正在成為「翻新工程」的超級工具，效率遠高於傳統人力方案。

如今，AI 寫代碼已經不是「寫幾行新功能」這麼簡單了，它正在成為大型系統現代化升級的關鍵角色。

別只盯著 AI 寫代碼了，它連測試和文檔都包了

很多人以為，AI 寫完代碼就結束了。但其實，真正的「神助攻」還在後面。

當代碼寫完，緊接著就是兩個關鍵環節：測試和文檔生成。而現在，這兩個部分也都在被AI重新改寫。

我們先說文檔。現在的大模型，比如 GPT-4、Claude Opus 等，已經可以寫出非常專業、結構清晰的技術文檔，而且不僅能寫，還能「用文檔」。

什麼意思？比如你問 AI：「這個函數是幹嘛的？」它不光能回答，還能調出註釋、示例、上下文代碼，給你講得明明白白，比老員工還可靠。

像 Context7 就專門做這個，它會在你需要的時候，自動把相關內容調出來，確保AI寫出來的文檔是「貼著代碼長出來的」，而不是那種看起來高大上，實際上跟實現毫無關係的套話。

更強的是Mintlify，不僅能幫你生成靜態文檔頁面，還能搭建一個「文檔小助手」。你可以在裡面問問題、搜用法，甚至一句話讓 AI 重新生成某一部分文檔。特別適合給客戶用的產品文檔，比PDF不知道高到哪裡去了。

而在企業里，還有一種更「嚴肅」的文檔，叫安全合規文檔。以前這種東西都是專人寫、慢且容易錯。現在有了像 Delve 這樣的 AI 工具，直接幫你生成和更新，合規不再是煩人的流程，而是自動化的一部分。

再來看測試。

以前寫測試用例是真麻煩，尤其那種跨 UI、API、數據庫的流程測試，動不動幾百行。現在，AI QA 工具可以全自動搞掂。它不僅能寫測試腳本，還能自己跑流程、檢查結果、輸出錯誤報告，甚至給出「建議修復方式」。

這意味著什麼？過去開發流程是：「寫完代碼 → 人工審查 → 人工寫測試 → 提交上線」；現在有些任務，AI 一口氣全包了，從寫到測再到提交，只需要你最後點個頭。

特別是在現在很多 AI 生成的代碼越來越「黑盒」的情況下，我們更關心的是它「有沒有錯」而不是「看不看得懂」。這時候，AI 在測試、文檔、合規方面的全面介入，就變得尤為關鍵。

代理系統背後的全自動工具棧

除了為人類開發者服務的工具之外，現在還出現了一類專門為 AI 自己用的「工具鏈」。

這些工具不是用來給人操作的，而是專門提供給 LLM（大語言模型）調用，讓它們能獨立完成搜索、分析、測試等任務。可以理解為，是 AI 自己用的「開發者工具箱」。

首先是代碼搜索與索引工具。當 AI 要操作的是百萬行、甚至上億行級別的代碼庫時，顯然不可能把所有代碼一次性塞進模型里。這樣不僅慢，而且成本高、效果差。

更高效的方式，是給 AI 裝一個「代碼搜索引擎」，在需要時再去查關鍵片段。對於小項目，普通的 RAG 技術或者 grep 搜索就夠用了；但在大型項目中，就得用更專業的方案，比如自動構建調用圖、識別函數引用的分析工具。

像 Sourcegraph 就提供了企業級代碼分析平台，Relace 推出的專用模型也在這個方向發力，幫助 AI 快速定位最相關的部分，大幅提升理解效率。

第二類是文檔與網絡搜索工具。比如 Context7、Mintlify 這樣的平台，可以自動從代碼中提取註釋、示例和上下文，確保 AI 生成的文檔和真實實現對得上。

而 Exa、Brave、Tavily 則更偏向網絡搜索，能幫助 AI 快速獲取外部知識、臨時參考資料，尤其適合客服、運營、支持場景的長尾檢索。

還有一個核心組件是代碼沙盒。AI 寫出來的代碼需要測試和運行，但直接跑在本地有風險——模型可能「幻覺」出錯誤命令，甚至觸發安全問題；而現實的開發環境本身又很複雜，依賴多、配置重。

為此，一批專門的「AI 執行環境」應運而生，比如 E2B、Daytona、Morph、Runloop 和 Together 的 Code Sandbox。它們提供可重覆、可隔離、可追蹤的沙盒平台，讓AI可以安全地執行命令行操作、運行腳本、調試程序，成為整個 AI 開發體系的關鍵基礎設施。

這些專為代理設計的工具，就像給 AI 裝上了一把多功能瑞士軍刀，真正讓它具備了參與複雜項目的能力。

未來，我們將看到越來越多的 AI，不只是「在 IDE 里打輔助」，而是像一名獨立工程師一樣，接任務、調資源、跑測試、提 PR，全流程參與軟件開發。真正的「AI 工程協作系統」，正在浮出水面。

應用會自己進化，程序員的價值也變了

AI 編碼時代真的來了，現在很多公司已經不再是「試試看」，而是開始把它用在實際工作中了。但問題也隨之而來，這玩意兒，貴得驚人。

最近 Reddit 上就有個熱帖問：「Claude Code 太貴了，有什麼慳錢技巧嗎？」

我們來算一筆賬：如果你用的是 Claude Opus 4.1，調用一次模型要塞進去10萬個 token，再加上1萬個輸出 token。按每百萬 token 輸入15美元、輸出75美元來算，一次調用大約要花2.5美元。

如果你每天跑 7 小時，每小時跑3次，一年下來就是一萬多美元，甚至比一些地區的初級程序員還貴。

那還值嗎？

其實，很多平台已經開始用「聰明的方式」來優化成本了。比如Cursor，就可以在同一個界面里調多個模型，根據任務複雜度自動選便宜又夠用的那一個。哪怕是低價模型，也能帶來明顯提效。

所以，現在大家不再糾結「誰家模型最強」，而是更關注「誰能用合理的價格創造出實際價值」。過去幾十年，軟件開發的成本幾乎全靠人力支撐；而現在，大模型的推理成本，正在成為新的人力之外的「運營開銷」。這會不會幹掉傳統的 IT 外包？可能不會，但確實會讓商業決策的方式發生變化。

那對全球三千萬開發者來說，AI 是機會還是威脅？

有人說，AI 會取代程序員。這種說法其實是媒體的誇張，還有一些廠商為了賣產品在搞的營銷——他們把 LLM 的定價宣傳成「人力替代成本」，聽起來嚇人，其實並不真實。

現實反而是：越早用上 AI 的公司，反而越想多招開發者。他們發現，用得好，不僅短期 ROI 正向，而且還發現了很多原來做不到的新機會。

只不過，程序員的工作內容變了。你不僅要會寫代碼，還要懂怎麼「跟模型合作」，怎麼查錯、補全、優化提示詞……傳統的開發流程正在被重新洗牌。

這也意味著，大學里教的東西，也得大改。

算法、架構、人機交互這些還是重要的，但那種「從頭敲代碼寫完一個項目」的教學方式，正在變成歷史。我們還是需要懂編程的人，但更多時候，是為了「從 AI 寫的爛代碼里把坑填上」，而不是自己從零寫起。

從長遠來看，AI 還可能推動一種全新的軟件形態：會自我進化的應用。比如，Gumloop 這類工具，用戶只需要描述一個新功能，AI 就能自己生成代碼實現。未來的 App，可能不是靜態發佈，而是可以隨時升級、定製、自動擴展的「活軟件」。

或許，未來每個 App 上都會有個「AI 增強」按鈕，點一下就能用一句話讓它幫你加功能。

當然，這不代表代碼就會消失。

在簡單場景下，確實可以用語言控制 LLM 來完成任務。ChatGPT 已經可以直接跑一些基礎算法。但一旦任務複雜、性能要求高，代碼依然不可替代。

別忘了：GPU 上執行一個加法只需要 10^-14 秒，而 LLM 輸出一個 token 至少要 10^-3 秒，中間差了 1000 億倍的速度鴻溝。這種差距，構成了代碼世界天然的護城河。

所以可以這麼說，AI 不會替代程序員，但會重塑他們的角色。

未來的程序員，不再只是「寫代碼的人」，而更像是和AI一起工作的「系統編排師」、「提示工程師」、「模型質檢員」。

本文來自微信公眾號「烏鴉智能說」，作者：智能烏鴉，36氪經授權發佈。