當 AI 大模型飛速進化，最先被卷入洪流的，不是寫作畫畫或運營，而是程序員。過去幾年，從 GitHub Copilot 開始，到 Cursor、Codeium、Claude Code，再到各類 Agent 框架如雨后春筍般涌現，AI 開始進入代碼世界，試圖不僅寫代碼、補代碼，更要理解工程、構建系統，乃至在沒有人的指令下完成一次次自動迭代。

這場看似技術層面的革新，其實正在悄然重塑整個軟件開發范式，也讓“AI 是否將程序員作為第一個被顛覆的職業”成為一個日益無法回避的問題。

然而，顛覆，從來不是一個單向度的詞。AI Coding 正在打開的是一條分叉的路徑：在存量程序員眼中，它是效率的躍遷工具，是寫代碼的新搭子；在非程序員眼中，它是一種“去編程化”的自由工具，是一種“用自然語言造軟件”的全新可能。而在真正理解軟件工程的人看來，AI Coding 更像是剛剛起步的“工程幼兒園”：離真實的復雜協作、架構設計、上下文演進與嚴肅生產環境仍有巨大距離。

7 月 19 日上午，AI 科技評論組織了一場圍繞“AI Coding”的線上圓桌，請到了三位長期深耕于 AI Coding 領域的代表人物：峰瑞資本的投資合伙人陳石、Auto Coder 創始人宿文與 ClackyAI 創始人李亞飛。他們的身份橫跨資本、模型與產品，也代表了對這個問題的三種路徑觀察。

以下是此次討論的精彩分享，雷峰網 AI 科技評論進行了不改原意的編輯整理：

從輔助工具到工程變革

AI 科技評論：歡迎大家來到今天的 GAIR ?Live 直播論壇。本場主題是 “AI 顛覆的第一個職業會是程序員嗎？”我們的第一次問題：什么才叫 AI Coding？它與傳統軟件工程（SWE）有什么區別？AI 是否可能成長為一種新的工程范式？ 下面先請陳石來分享他的看法。

陳石：我理解的 AI Coding，如果從狹義角度來看，目前更多指的是AI 自動生成或補全代碼，甚至是自動完成整個代碼編寫過程。但這個“完成”往往并不符合真正的軟件工程范式，也很難滿足我們在軟件開發中常提到的一些規范性要求。

當然，未來的 AI Coding 一定會朝著更工程化的方向演進。它不僅要遵循現有的軟件工程規范，甚至可能會發展出一種全新的工程范式。這種范式不僅要求 AI 能寫代碼，還要求它能參與整個開發流程：從需求拆解、架構規劃，到代碼生成、測試驗證、持續集成部署（CICD），甚至包括多智能體協作、自我修復、持續迭代等關鍵環節。

所以，我認為今天我們看到的 AI Coding，還處于非常早期的原型階段，只能在局部場景中解決一些簡單問題。但它的未來潛力不容低估——它會從生成“demo 級”的小程序，發展到真正具備構建大規模、復雜系統能力的工具。這才是我眼中 AI Coding 的真正方向。

AI 科技評論：所以目前來看，AI Coding 還處在一個比較早期的階段，確實還無法真正達到軟件工程的標準。那接下來想請宿文老師談談您的看法。

宿文：我們觀察到，今天 AI Coding 的產品形態，基本可以分為兩大類，它們分別對應兩類主要用戶。第一類是存量的程序員用戶。從最早的 GitHub Copilot，到后來的 Cursor、最近的Claude Code，這類工具主要圍繞開發者的 IDE 環境，提升代碼補全、協作效率等，甚至開始探索 SWE Agent 這樣的新范式。這個方向本質上是面向已有開發者市場的，屬于一個存量場景，所以吸引了大量程序員的關注和使用。

第二類則是增量用戶，主要面向非程序員群體。他們率先服務的還是posumer，這些人可能不會寫代碼，但有明確的軟件或應用需求，有點像產品經理，但是是“打著引號的產品經理”——他們可以用自然語言描述自己的需求，并期望 AI 幫助把這些想法變成一個原型產品。

目前，AI 模型在前端 UI 生成方面已經比較成熟，但真正的軟件工程深水區，比如后端邏輯、數據庫設計、高并發、高可靠性的處理能力等更難的技術棧，還遠遠沒有突破。這正是接下來整個技術體系要努力的方向。

所以我們認為，AI Coding 一方面是在提升存量程序員的效率，另一方面也在拓展增量市場、實現開發能力的“平權”。最終的目標，是讓更多人即使不具備編程能力，也能自由地實現自己的軟件想法，而不再受限于“程序員供給”的門檻。

AI 科技評論：聽起來這是兩個方向——一個面向程序員的效率提升，一個面向非程序員的能力擴展，確實可以看作是兩條路徑。那接下來也想請李亞飛老師來聊一聊，特別是 ClackyAI 最近剛發布了新產品，我們也很期待聽聽你的觀察和看法。

李亞飛：好的，剛才大家聊到了 AI Coding 的定義，我也想從兩個角度補充一下我的理解。第一，是從軟件工程的復雜度維度來劃分。我們可以把軟件項目按照工程復雜程度分成五個等級，從 C1 到 C5：

C1：最簡單的項目，比如通過 GPT 聊天生成一個前端頁面、小工具、小游戲，通常只有一個文件，純前端邏輯即可。

C2：稍微復雜一些的小工程，可能包含 10 個文件以內，具備基本樣式和簡單邏輯，比如帶 UI 的小網頁。

C3：像公司官網這樣的項目，結構更完整，文件量可能在 100 個以內，涵蓋完整的前端和部分簡單交互。

C4：真正意義上的軟件工程，具備前端、后端、數據庫，業務邏輯相對復雜，通常涉及多個模塊的協同。

C5：超級大工程，比如 Linux、Windows 這類操作系統級項目，涉及百萬文件、成千上萬名開發者協作。

目前我們看到的 AI Coding，大多還停留在 C1 到 C3 的階段。也就是說，它能勝任原型開發、小工具生成，但距離嚴肅軟件工程（C4以上）還有一段路要走。

第二個維度，是 AI Coding 對人類價值的進化階段。我們可以理解為 AI Coding 本身也在經歷從「工具」到「合作者」的過程：

第一階段是“輔助補全”階段，AI 能補全代碼、預測你接下來可能寫的內容，就像文章寫作里的自動續寫功能，這一階段已經發展了近兩年。

第二階段是“AI 原生編程”，像 Cursor 這樣的產品代表，基于聊天輔助的編程工具。AI 能圍繞用戶的需求實現具體模塊、功能，好的就留下來，不好的就可以丟掉。開發者還是主駕駛員，但 AI 已能提供有價值的思路和建議，

第三階段是我們現在正進入的 “Agentic” 階段，AI agent作為一個“AI工程師”真正參與到從 0 到 1 的項目建設中。我們一年前就開始做了，但真正能落地還是在最近一個月。這是以Claude Code為代表的新型的軟件開發模式，這種體驗非常獨特：你告訴它一個目標，它會在后臺持續“工作”，幾個小時后告訴你“已經搞定了”。你去檢查時會發現，大約七成已經搭好了，剩下三成搞差了。這個過程既矛盾又開心。

這一階段，我們認為才是真正的 AI 工程師時代的起點。

終局清晰，路徑仍模糊

AI 科技評論：有人跟我說，你在舊金山的一個 zip code下面，你能找出來 20 家 AI Coding 的公司，而且每一家切入點都不太一樣，有做 code review，有做 document 的，各種都有，那這個賽道它有沒有機會收斂？很多不同種類的公司的同時并存，是不是一個很長期的事情？

李亞飛：我簡單說一下我看到的一些現象。現在中國這邊其實還沒那么“熱”，大家應該也能感受到，雖然也有一些公司在做，但整體氛圍相對克制。反倒是美國那邊、尤其是硅谷，非常活躍，因為那邊是軟件的天堂嘛。

但也因為軟件工程的復雜度很高，它早就形成了非常明確的分工體系。在今天 AI 還處于相對早期階段的情況下，其實每個工種理論上都能被賦能。這也是為什么你會看到市面上有那么多 AI Coding 公司：做 code review 的、做測試的、做需求管理的……整個軟件開發流程每個環節都能開出一家公司來。

人類工程師掌握不了那么多的知識密度，所以需要分工，現在的AI可能在某個方向不是超級專家，但是它在大多數方面都是個中級工程師，這個時候分工就要發生變化了。

我覺得現在的趨勢就是從多 Agent 走向單 Agent 架構。因為分工帶來的成本太高，反而不如一個大模型“一人多能”來得劃算。有些場景可能不存在了，比如code review 這個環節，都是AI寫的，你還 review 啥？你是在為人類寫代碼做AI，還是在為“AI時代新的軟件工程”做AI？ 這里面有本質的變化和區別。現在大家看得也都不太清楚，所以這么多公司百花齊放，大家沖進去先干，活下來再說。這是我目前的觀察。

AI 科技評論：那你覺得，接下來這些基于分工誕生的 AI Coding 公司，會不會隨著分工變少、被逐漸取代？未來是不是就不再需要這么多細分方向了？

李亞飛：可能開始有很多山頭，然后會進入收斂階段，我不覺得會完全一家獨大——因為軟件工程太復雜了，不太可能被某一個玩家完全吃掉。更現實的情況是，會在幾個方向、幾個垂類場景里，各自形成一些穩定陣地。這個行業用戶的付費能力和意愿都很強，市場空間也足夠大，所以哪怕到終局，也不會是一個標準答案。

AI 科技評論：那陳石老師你從投資人的視角怎么看？

陳石：為什么美國有這么多切入點不一樣的公司？我覺得 AI Coding 是當前 AI 應用落地中最有機會的幾個方向之一。所謂“最有機會”，我覺得可以從三個維度來看：第一，用戶規模足夠大；第二，模型能力已經接近可用水平，至少達到了能滿足基本使用的程度；第三，市場上已經有一部分產品找到了初步的 PMF，比如 Cursor，好像現在已經能做到年化 5 億美金的營收了。這三點決定了為什么這個賽道這么熱、公司這么多。

但與此同時，我們也看到這個行業沒有明顯的收斂趨勢，原因在于很多關鍵問題還沒有達成共識，這一點作為一個天天見項目的投資人，我感受非常深。

首先是 Copilot 還是 Agent ？未來我傾向于認為 Agent 會更有潛力，但也一定會存在大量 Copilot 的場景，畢竟熟練的程序員很多時候還是更喜歡“手搓”。我們原本覺得 Copilot 不太適合創業公司，但 Cursor 的出現又讓這個觀點變得不那么確定了。

還有一個懸而未決的問題是：模型能力的邊界到底在哪？ 現在看，模型在處理一些垂直方向，比如單元測試、Code Review 這類任務上表現還不錯，端到端地做簡單或中等復雜度的程序時也能勝任，但面對真正復雜的軟件系統、長鏈條的邏輯結構時還是不行。

同時還有個現實問題是：模型廠商的業務邊界在哪里？ 有些創業公司會選擇做 Agent，但他們會有意避開模型公司可能會直接做的端到端方案，轉向更具壁壘的垂直場景。

Vibe Coding的市場有多大？很多人其實邏輯思考能力并不強，沒有能力把自己的需求有效地表達出來，所以這里頭有很多不太確定的東西。

我認為， code review 或者單元測試這些 AI Coding的機會不太大，因為需求和產品定義得很清楚了，產品規范上沒有門檻了。未來的Coding應該是每一個軟件都是定制化的軟件，有機會的應該是能圍繞垂直行業和 “深度上下文”展開的Agent，這是模型公司做不了的事情。圍繞著這些垂類行業的深度上下文，做大量的加工，總結成良好的提示詞和上下文工程，跟模型做交互，這才是我們創業公司比較好的發展機會。

AI 科技評論：宿文老師，您說您希望做一些“用完即焚”的軟件。我覺得這個思路和剛才陳石老師提到的“定制化軟件”某種程度上是相通的，所以也想請您展開聊聊這個想法，背后有哪些考慮？

宿文：其實這個是我們公司的一個 slogan，上半場是 Auto-coding is AGI，下半場是 Personal App is the End。意思是說，以后每個人都有屬于自己的 Personal App。這個APP可以是長期消費的，也可以是一次性的軟件。

我們可以先預測一下終局，如果所有的Coding都是依賴于token去完成的，那可能就會發展為模型廠商贏者通吃的局面。走向未來的過程中，其實每一輪新的工具或技術出現，首先都是在現有的存量市場中扎根的。畢竟這么多專業的人才、聰明的大腦，一定會嘗試擁抱它，把它應用到已有的工作場景中。畢竟我們看到整個軟件世界體量非常龐大，從芯片往上一層一層搭建上來，最終都匯聚在“軟件”這個抽象層。

有些語料是大模型在后訓練（Post-train）或者預訓練（Pre-train）階段見不到的，都是這些垂直領域的玩家在用自己的知識去做的。這里面的卡點就是，今天的模型應該怎么去支持他們？模型架構在往前迭代，現在主流模型支持的上下文大概在 120K token 左右，往上做到幾百 K 的已經是極限了，Gemini做到Mb級別的長度了。

我們自己就是從模型層開始干的，我們就發現很多問題，只要模型迭代下個月就沒有了，開發者只要去擁抱新的技術生態就好了。

所以對我們來說，在這個不斷變化的過程中，最關鍵的是找到一個落點——我們會去尋找那些不容易被“堆人”、“堆資源”就能打下來的場景。很多產品和場景，可能按月、按季度就會被迭代掉。我們思考的也是，既要看清一個遠處的終局，也要找到當下能活下去的路徑，所以我們也考慮向 C4 這個環節去突破，面向嚴肅的生產環境制作軟件。

李亞飛：我想補充問一個問題，想請教一下宿文。其實剛才提到的 C4 工程——也就是涉及前端、后端、數據庫這些完整鏈路的軟件開發——它其實是可以有很多不同的解法的，對吧？比如說，有些人會選擇無代碼、低代碼的方式來處理，也有一些人堅持用標準的技術棧、按照傳統軟件工程方法來推進。那我挺好奇的是，你們在這方面是怎么思考和選擇的？你們更傾向于哪種路徑？

宿文：你肯定觀察到了最近的一些新聞，包括最近被Wix收購的Base44，這個產品是挺好用的，但是典型地用到了低代碼的手段，很親和于Wix的建站場景，整個軟件世界肯定不止這些。我們自己的判斷是，原有那套軟件開發架構還是局限于場景之中，是為“人”設計的，尤其是為架構師、程序員設計的，它的核心是：鏈條越長、分工越細，就越能發揮規模協作的優勢。比如一個大廠有幾千上萬程序員，每個人都是一個“螺絲釘”，整個鏈條組織得非常高效。但大模型來了之后，它的理解和處理方式完全不是這么玩的，我們在做全棧類生成的時候就非常明顯地感受到這點。

所以我們現在的重點方向是，探索一種面向語言模型親和、以生成為核心的軟件 agent 架構。我們認為這兩條路徑缺一不可。怎么去理解面向模型的生成式軟件架構，這是我們要去摸索的。舉例而言，在面向B端的應用中，每個頁面都會有一個搜索組件，但是在生成式的軟件中，整個架構中只有一套搜索的組件，我們再去選擇如何適配各種場景。

我們現在的看到的，比如 Devin 這套架構里面，它本質上是要替代程序員的，但是又按照程序員的分工協作去做的技術鏈條的設計，我覺得這樣很怪。我們在嘗試一條新的道路。

李亞飛：明白，這個問題其實我們作為創業者，真的會有很深的感受。它本質上是一種“內心的矛盾狀態”。這個矛盾來自兩個方向：一方面，我們知道市場、尤其是投資人這邊，確實會有壓力，大家都希望你能盡快跑出 PMF，最好能快速閉環，用戶開始付費，模型也能用起來。

那么從戰術上講，其實是有一些作弊的方法的。比如說我就只做個純前端界面，模型生成完一閉環，看起來像個產品，就能收錢了；又比如說我提前把整個技術棧鎖定，用低代碼的方式、圍繞某套提示詞和上下文優化打磨，也是可以很快搞出東西的。這些辦法都能跑得快、看起來也“成型”了。

但另一方面，作為搞了十多年全棧開發的工程師，我們心里也非常清楚——這些方式不是終局，甚至說是“偏離正確道路”的妥協。它們讓團隊進入了一個短暫的“舒適區”，但那個方向很可能不是 AI Coding 的未來。所以這時候你就會非常矛盾。

到底是堅持正確的選擇，還是馬上進入快車道去做閉環，有時候會讓團隊陷入一種無所適從的狀態。剛才聽宿文的回答，我覺得他其實在那套路徑里，也體現出了一種對這類矛盾的平衡。這個我挺有共鳴的。

陳石：我這邊想補充一句，其實亞飛老師剛才說的那種“矛盾”，確實在市場上是存在的，甚至可以說是目前不少創業者都會面對的現實困境。

就比如現在大家經常討論的一個路徑問題：是不是應該先從 Copilot 做起，有了局部的數據和經驗，再泛化到 Agent？但自動駕駛行業又有不同說法，例如有些專業人士認為，L2做得越好，就距離L4越遠（當然很多業界人士包括我自己并不完全認同這個觀點）。這也引申到 AI Coding 的問題上——你是先專注于一個垂直場景，做得足夠深，然后再圖泛化？還是說一開始就奔著通用方向去？這兩種路線還沒有形成什么共識，現在還處于一個多種探索并存的階段。

李亞飛：今天 Cursor 上個月改了收費方式之后，就被用戶打回原形了，就是這個矛盾的體現。就是作為 Copilot 產品，現在想按 agent 產品收費，用戶不 buy in。這就是一個矛盾。但如果你第一天就是做的 agent，那你就按這個方式，比如按任務規模復雜度來收費，那就可以了。

陳石：我覺得Cursor的經濟模型可能做不過來了。

李亞飛：我同意。我補充一個使用體驗上的角度。Cursor原來的收費方式是，一個月內500次調用收費20美金。這是基于上個階段的Chat-Base program的產品結構所定義的收費方式。但是 Agent 的工作方式是，給它一個目標，它能自己循環500次。結果 Agent 花了500次的錢，只收了用戶1次的錢，那Cursor肯定想改。這就是 Agent 模式和 Copilot 模式打架的問題。

“幻覺”仍是模型最大短板

AI 科技評論 ：去年一整年，隨著Claude 3.5、3.7的發布，AI 編程已經變得越來越“實用”了，甚至開始推動整個交互范式往 Agent 模式轉變。那問題來了——作為投資人，以及親自參與模型開發和基于模型做產品的人，你們怎么看當前模型能力的瓶頸？

宿文：其實從我們自己的觀察來看，整個大模型的能力還遠遠沒有達到理想狀態，離我們想象中那個“終點”還差得挺遠的。但是我們也不能等下一個版本出現，因為說實話，你等再久，它也不會主動把你的用戶數據納入到 Pre-train 里，所以我們不應該做技術等待型的公司。

Claude 3.5出來，伴隨著一個很有意思的產品，Artifacts，我們今天就看到了 lovable 這種首先找到一個變現場景的產品，不管爭議多大，用戶量都有了，前端也能寫的很好。其實前端語言的邏輯性是很弱的，很多前端代碼都暴露在公網，所以這些都能做出來。但是我們不能拿到數據庫，拿到后端代碼。

大模型的問題在于，今天的Transformer架構很難把業務的長鏈條解決得很好，這是Transformer本身的天花板所決定的，那我們就會想去解決其中的一部分問題，其中一個就是“幻覺”。模型為什么產生幻覺？我們后來反復研究，發現它的根源其實還在最早的 Pre-train 階段，特別是反向傳播的機制本身就有偏差，那我們就看有什么更好的網絡結構去改造。

所以我們自己的結論是：如果真的要解決問題，必須從網絡結構層面去動刀，真正讓模型在 Pre-train 階段就變得更靠譜。這才是能帶來陡峭提升的地方。說實話，從 DeepSeek-V2 發布到現在，我們看到整個行業在這方面的創新還很有限。那我們就自己想辦法解決了。

陳石：剛才宿文老師提到了“幻覺”這個問題，我也非常認同，這是當前大模型能力的一個關鍵短板。而除了幻覺，另一個普遍存在的技術瓶頸，就是上下文窗口的限制。我們現在看到很多代碼庫其實體量都非常大，很容易就超越了上下文窗口的上限。

此外，受限于當前AI模型訓練的機制，模型訓練完成后就被凍住了，在運行時一般不再做參數更新。而每個用戶在使用模型的時候，都需要某種程度的定制化，或者說都需要有自己的上下文記憶，現在解決定制化的方法是靠應用去存儲和捕捉上下文，以反復Prompt的方式傳遞給模型。這個成本很高，且運行時間越長，Prompt長度越大，每一個交互都需要費大量token。現在雖然像 ChatGPT 引入了一些“記憶功能”，但我覺得還遠遠不夠。我認為未來模型應該可以直接“記住”你的上下文，讓它能像人一樣保有長期記憶，而不是每次都靠 prompt 臨時加載。

我猜未來會有一些變化，要么是模型結構上的，允許在運行階段動態調整參數；要么是解決記憶存儲的安全與隱私問題，比如如何以安全、可控的方式把用戶或企業的長期上下文交給模型來處理。

AI 科技評論：亞飛總怎么看待這個問題呢？

李亞飛：首先我挺佩服真正敢下場做大模型、做 Pre-train 的團隊，今天的大模型確實還有不少問題和短板需要解決，而我認為，在工程領域看待這些問題，可以從兩個不同的視角入手。

第一個視角，是智能性，也就是大家經常說的“推理能力”。這一塊現在很多模型都在突破，比如陳石總剛才提到的上下文處理問題的兩種思路：一種是直接把盡可能多的上下文“塞”進模型中，另一種思路則是像人類那樣通過外部記憶進行知識調用。實際上這波 Claude Code 展現了外腦獲取知識的能力，它會自己反思看代碼，現在我的測試結果是，它能把10 萬級別的文件處理得也很好。

第二個視角，就是幻覺問題。我覺得這和人類的想象力類似，某種程度上是生成能力的一部分，它可能永遠無法被完全“消除”。但在 Coding 領域，我們能做的最好的方式是，給模型提供充分的tools，讓模型具備反思能力——也就是要能“犯錯-覺察-修正”。

第三個，我覺得大家經常忽略掉的，就是我們要給它一個更強大的反饋系統。我們從工程領域看到的，比如debug類的信息，沒有給它。原來的debug是單步單點，這是給人類設計的。其實AI不需要單步單點，如果AI研究一會兒看不出錯誤，它就跟你說，請你把調試器打開把那個錯誤粘給我，然后我才能繼續。為什么我們不能把這個信息直接丟給AI呢？這些能力加上之后，AI的能力會明顯地變強變好。

目前來看，Claude 4.0 的智能性已經相當強，從今年 6 月開始，真正屬于 Coding 領域的 Agentic 時刻已經到來了。剩下的問題無非就是，Cli是不是最好的形態了。

原型做得快，生產還得慢慢來

AI 科技評論：要想提升AI的編程能力，哪些東西是模型能做的？哪些是產品設計中能做的？

宿文：在我看來，這兩方面還比較難拆開。模型迭代得很快，我們核心還是構建數據飛輪。產品層面來看，工程也是很重要的一件事情。我們的模型和產品缺乏一個超級動態規劃，其實大家今天都靜態得不能再靜態了。

那模型層要做什么呢？我覺得最核心的還是數據飛輪的構建。之前美國紅杉開會的時候，幾乎沒有一家公司的CEO能說清楚怎么構建的。我們認為，真正有效的數據飛輪一定從 Pre-train 階段開始。但 Pre-train 成本極高，不可能頻繁跑。所以關鍵在于怎么通過網絡結構創新來支持“增量預訓練”，而不是傳統意義上的增量微調（Post-train），從而讓token的權重可以快速地進行動態調整。這肯定是網絡結構決定的，我們今天基本上能夠做到了。

然后你再看上下文的處理問題。去年的上下文窗口競爭，一度“卷”到兆級上下文。但那其實更多是post-train層面的改造，不是真正從 Pre-train 層解決上下文編碼能力的問題。比如去年 Magic.dev 的探索就很有代表性，他們認為編程的卡點在大上下文，于是基于mamba的架構去做了，雖然過程不順，但思路非常有價值。混合架構加上位置編碼的方式，能不能把上下文擴展到Mb級別？我覺得是可以的，那我們就這樣做了。

而從產品層面，我們關注的重點是用戶的真實表達能力。你的用戶可以是程序員，也可以是非程序員，甚至是完全不懂技術的“普通用戶”。關鍵在于你能否讓他們把自己的需求講清楚。而這恰恰是今天對話式交互里最大的挑戰。我們肯定去做社區，做內容沉淀讓更多的知識可復用；還有就是擺脫對話式，做圖形的交互方式等等。產品考慮的是用戶入口的事，模型考慮的是智能迭代的事。

AI 科技評論：明白。陳石總，從您作為投資人看過這么多產品的這個角度來看，您覺得呢？

陳石：我之前也做過技術和 CTO，雖然現在離技術有些遠了，但對這個話題還是有一些感受。AI Coding 想要在未來真正發展起來，我認為核心在于“兩端能力”的協同推進：

一端是模型側能力的持續進化，包括更強的邏輯推理、對上下文的理解與處理能力、以及上下文窗口的進一步擴展等等。這是模型層面的事。另一端則是應用層的“上下文工程”。也就是說，產品要通過巧妙的設計和人機交互方式，幫助用戶清晰、完整地表達出他們的上下文和需求。

模型和應用端面臨的挑戰就是，如何幫助那些邏輯表達不夠清晰的用戶，把他們真實的心理需求，以清晰的方式用自然語言的方式表達出來。

AI 科技評論：大多數基于 LLM 的編碼助手 AI Coding 的產品并不公開其內部邏輯，所以我們很難去驗證它生成代碼的準確性，也不能夠去理解它為什么會做出來這樣的輸出，就沒有辦法去嵌入到真實的這個項目環境，但是Vibe Coding這個詞又很熱，所以我們應該怎么去看待它的價值？

陳石：對于早期的嘗試性用戶，如果有一些編程基礎，他們可能覺得比較好。我們要認識到Vibe Coding還是一個原型驗證的階段，偏向于把創意激發出來。

有些人可以告訴AI，你給我寫個貪吃蛇游戲，它就寫出來了。因為這是一個很容易的代碼。如果是一個復雜的東西，受限于人類的自然語言表達能力，和當前的語言模型的編程能力，還是比較難的。所以不要把快速做出貪吃蛇當回事，這只是個很簡單的功能，甚至不需要大語言模型。

我們的訴求是，產品側幫助用戶把真實需求以規范的產品文檔方式表達出來，以及在模型側怎么形成好的軟件工程范式，這兩段的努力能夠讓Vibe Coding產生更大的價值。

AI 科技評論：宿文總好像對貪吃蛇這種游戲類可以說幾句。

宿文：游戲是個非常復雜的事情。今天大家看到 AI 做馬里奧、貪吃蛇這些案例，確實能跑通，更多是因為這些場景早已有很多類似樣本，模型能“見多識廣”，所以比較容易實現。

我不太喜歡Vibe Coding 這個詞，但是今天到底能做到哪一步？目前典型產品，比如lovable、bolt.new 甚至更早一些的工具，確實已經能做到做出原型，而原型這件事在很多場景下本身就已經很有價值了。它能夠幫助開發者省去大量方案設計、產品需求撰寫和原型構建的工作，所以才會有那么大的用戶量。

我們更關注的是下一步：如何進入真正的生產環境，并贏得用戶信任。過去由人來寫代碼，哪怕出錯也能溯源、有人背鍋。但今天基于大語言模型的代碼生成，本質上是概率模型，天然帶有不確定性。如何讓用戶信任這種“不確定性里的生產力”？這需要分階段、分角度來推進。以前只有少數程序員能夠做的高階工程，以后也會以token的形式交付出來，這樣一步一步驗證它的安全性，慢慢影響用戶心智，從而進入生產環境。

到底要不要放開源代碼，我們持相對開放的態度，有一個問題是，一旦放開，用戶再一改代碼，整個deploy環境就亂套了，也就破壞完整的數據閉環了。

AI 科技評論：為什么不喜歡Vibe Coding這個詞？

宿文：國內最主流的翻譯是氛圍編程，這感覺不是一個能進生產環境的詞。

李亞飛：有一個詞更合適，叫松弛編程，就是我心情比較輕松，氛圍編程就好像是在玩，瞎搞。

今天我們對此有兩個矛盾。第一個矛盾是：來自業務側的“小白用戶”，他們很多都是非常專業的商業人士，只是完全不懂編程。但他們有明確的需求，想自己動手做一個應用。然而現實是，哪怕今天的工具已經進步了很多，這種需求和能力之間還是沒有完全拉齊。所以 Vibe coding 才會在某些圈子里被嫌棄——因為它給了用戶“好像能搞定一切”的錯覺。

第二類矛盾是：專業工程師的認知正在迅速分化。我最近觀察到一個有趣的現象：本來就是“十倍效率”的高階工程師，在接入“松弛編程”之后，效率能再提升十倍，甚至達到百倍。普通的工程師，只要用對方法，也能獲得顯著提升。還有一些工程師是堅決反對甚至排斥的。但這并不代表他們錯了——可能只是因為還沒真正看到這些工具的威力。我自己就反復橫跳了兩次，但是它一次次改變了我的想法。

我們現在早就不是貪吃蛇可以一鍵生成的時代，Vibe Coding已經可以做到 one-shot 生成一個完整的官網頁面，甚至借助它做點外包項目。今天的一些工程師已經可以通過松弛變成搞定 C3、C4 復雜度的項目，包括后臺、數據庫等全套系統。

這類能力距離“完全小白用戶”使用還有一段距離，當然，也可能未來永遠不會出現“完全小白用戶”能獨立做工程的那一天。畢竟軟件開發本質上是軟硬工程結合的復雜工作——懂行的人都知道它有多難。但有一點是可以肯定的：未來的開發過程一定是“松弛的”，以后的工程師都是業務邏輯式的，技術水平只需要以前的三分之一，但是他們能捋清商業邏輯，捋清產品邏輯。

如果你本身就掌握了編程技能，在 Vibe Coding 這個浪潮里，你依然能夠做到比別人高出十倍的效率。

AI 科技評論：以后Vibe Coding會公開代碼嗎？

李亞飛：我的答案是應該公開。它的本質還是代碼，還是資產，誰都能來接管。自動駕駛的汽車司機也能接管， 只是沒必要。

“倒車式”創新

AI 科技評論：正好也銜接我們接下來的話題。現在大家都在討論：為什么Claude Code能在這么短的時間里積累起這么大的聲量，獲得這么多用戶的轉化？是、因為它是Anthropic的產品？還是說它在產品形態或能力上真做出了重大突破？

李亞飛：我的體感可能會更強一些。我覺得它在形態上是“開了倒車”的——它回到了 30 年前命令行程序那一套，甚至可以說是 GUI 出現之前、60 年代那種技術形態。產品定義上是倒車的，但是程序員是相對能接受的。

它之所以爆火，關鍵在于它非常充分地激發了 Claude 4.0 的智能能力。它幾乎不需要很長的上下文，也不依賴太多的人類提示或“補丁”，就能產生足夠好的智能性。所以我覺得這是一個真正的 Agentic 工具。

基模在ChatGPT3.5那個時代，它只能做補全，而且還只是一些小文件，所以只能做Copilot，后來到了Claude 3.5，大家發現我們能跟AI有一些基本的對話了，可以做出一些功能性的能力了，現在到了Agent的階段，但是AI也沒強到那種程度，只能算是初中級工程師。

我認為 CLI 最終不是未來，未來一定是云端、多工協作的模式。Agent就像是一個工程師，以后雇一個工程師不滿意的話，就雇三個、五個，多開多干。

AI 科技評論：我覺得“倒退”也未必是壞事。宿文老師，您怎么看？

宿文：這個問題可能亞飛總更專業一些，因為我自己離開寫代碼已經挺久了，嚴格來說我既不是Claude Code也不是 Cursor 的典型用戶。

從我們內部的觀察來看，真正的源頭，還是看誰掌握模型。lovable也好、Cursor也好，一定程度上都是Claude的token的二道販子。特別是在這樣一個早期且劇烈變化的階段，握有底層模型能力的一方必然占據更多主動權。我認為歸根結底，今天還是誰握著模型、誰的主動性就更強。

AI 科技評論：陳石總以前做過CTO， 您怎么看Claude Code？

陳石：我覺得Claude Code 之所有受到好評，主要原因首先是它的上下文工程做得好，畢竟沒有人比模型廠商更知道如何全面、有效率地向模型提供它完成任務需要的Prompt。其次是Claude Code剛好有些取巧，它當前只提供命令行界面（CLI），愿意且有能力使用CLI來編程的人大部分是有經驗的程序員，而這批人更有能力取得好的體驗。

據Anthropic公司的統計，Claude Code上80%的左右使用的是Agent功能，而Cursor上只有50%，這也是CLI界面上編程序的特點，它相對于圖形界面（GUI）是不友好的，做深度復雜的編程是很難的，程序員要在這么多文件上來來回回切來切去也很麻煩，所以大家更愿意去用Claude Code的Agent功能，這也讓它有了更大的聲量。

李亞飛：對一些老程序員來說，Cli做開發比較快。

陳石：還有我覺得前端還是有很多價值的，否則Google也不會發那么多錢去收購windsurf，這可能也是我們應用創業的一個機會吧。

AI 科技評論：我下一個問題就想請陳石總先談談——Agent 未來有沒有可能成為研發流程里的核心 Controller 或 Planner？從您目前的觀察來看，這個路徑是否已經成為業界的共識？

陳石：從趨勢上來看，確實有越來越多創業公司涌向 Agent 路線。Copilot 這個方向現在難度太高了，海外大廠都在做，比如微軟的GitHub Copilot ，此外Cursor這些領先的創業公司也做得不錯。你再去從頭做一個 Copilot，幾乎沒有多少空間了。所以很多人選擇了 Agent 這條路線。

Agent 作為 Controller 和 Planner，雖然當前取得一些進步，但是現在還談不上成熟。你讓它去做一個深度的任務規劃，或者真的做一個“項目經理”角色，其實還是非常困難的。何況讓它寫對邏輯性和一致性要求非常高的代碼，稍微復雜一點可能連編譯都通不過。

雖然 Agent 的方向是對的，但要走通它還面臨很多挑戰。未來模型能力會提升，這是肯定的；但在這個過程中，我們必須有一套流程設計，讓人類能夠參與其中，承擔監督和反饋的角色。哪怕是做標注、做獎勵反饋，只要能把人類嵌進 Agent 的工作流中，Agent 的表現就會更好。

現在最大的問題是，Agent 做完一整套操作之后，大部分情況要么完全跑不通，要不跑通但不符合用戶需求，且普遍存在用戶反饋滯后稀疏的情況。這種反饋結果非常不利于模型做強化學習。所以關鍵還是流程設計：要讓人類愿意提供高質量的反饋，讓模型在過程中就能獲得獎勵信號，這樣才能真正訓練出一個好用的 Agent。

AI 科技評論：亞飛總您怎么看？現在做 Agent 是不是已經成為行業共識？

李亞飛：我覺得“成為共識”可能還言之尚早。我今天最大的任務，就是想告訴大家——Agent 應用，尤其是在 Coding 領域，已經可以用了。

現在很多人還是將信將疑的。其實那么多大廠、那么多團隊，就像微軟早早地做了 Copilot，結果看著Cursor做了起來，我覺得其實是大廠內部沒有那么篤信。

你看中國的大廠，還在搞IDE呢，Cursor都被彎道超車一個月了。有些大廠還希望你把模型私有化進去，做Copilot。

宿文：我們從第一天就認為，Agent肯定是未來，但是就怕它不是這一波泡沫中應該出現的事兒呢。

我覺得Coding Agent在這一波技術周期還是能落地很多場景的，但是現在仍然是完全不成熟的狀態。我們自己內部討論的時候，有人說超級動態planning，要讓產品很靈活，效果又都有保障，結果我們發現，底層的給Agent做的infra是完全不完善的。我們期待會有一些更好的Agent框架，如果出現了，我們就快速地擁抱，同時我們自己也在做一些突破。目前來看還是有瓶頸的。

AI 科技評論：那你們有哪些嘗試呢？

宿文：我們目前最核心的探索，其實還是聚焦在“如何更靈活地滿足用戶的個性化需求”上。因為如果你要提供一個端到端的方案，首先是你整個技術棧得非常完整，其次是要面對用戶非常長尾分散的需求。

現在不管是Manus還是Devin提出的一些東西，我們都不太能夠借鑒得上，我們先一步步地做自己的生成式軟件agent架構，未來留待擁抱更多的靈活性。

AI 科技評論：確實，agent 的能力和未來的落地還存在很多挑戰。請陳石總從更宏觀的角度聊聊，您怎么看待 AI Coding Agent 生態的發展？

陳石：我覺得可以抽象為兩個關鍵方向：第一，是基礎設施層面的統一，尤其是要為 agent 或 AI 特別設計的一整套基礎設施；第二，是協作與監督工具的完善，讓人類和 AI 能更高效地協作，同時對 AI 有一定可控性。

比如 OpenAI 的 CodeX、Claude Code 模塊等，都會配套一些沙盒環境。這類“安全可控”的運行環境非常關鍵，因為最好的驗證方式，其實就是讓 Agent 在虛擬環境先跑一遍，這類基礎設施非常重要。我覺得這一類產品會慢慢成為一個既安全又能形成標準的一個運行環境。還有就是用戶端的長期記憶和上下文共享的機制，包括MCP、一些向量數據庫等等。

再說協作監督工具。如何讓一個邏輯能力弱一點的用戶，也能把需求準確表達出來？這個過程需要一整套引導機制。

還有一個特別重要但現在缺失的東西是可視化調試工具。現在的大模型像個黑盒，用戶不知道它為啥出錯、哪里錯了，就跟自動駕駛的 corner case 一樣，你沒有辦法預警，也很難修復。如果能有像儀表盤那樣的可視化系統，讓人可以在高層級上看清 AI 的“決策路徑”，那人就能更有效地“標注” agent 的行為，形成一個更健康的閉環反饋系統。

所以總結來說，基礎設施統一和協作監督機制，是 agent 生態目前最需要補足的兩大塊。

AI 科技評論：那這些工作應該主要由誰來做？是 Agent 開發者、平臺方，還是說這其實是很適合創業團隊切入的機會？

陳石：關鍵是判斷哪些模塊是適合做在應用層的，哪些模塊適合在模型層做。像我們投資的做一體化 Agent 工作環境的產品，就是一個創業團隊在做。你可以從 Infra 層切入，也可以從應用層往下扎。比如 Cursor 本身做了很多前端上的交互設計，它也在做一些記憶機制、上下文優化，還有數據收集與回溯能力，這些也都在增強 Agent 的協作能力。所以說這些事，應用開發者和平臺方其實都可以做。

AI 科技評論：宿文總，您在市場上有看有接觸過這樣的公司，或者是有這些需求嗎？

宿文：我們從 2023 年底決定切入這個領域開始，就特別關注，在未來的研發與商業化過程中，會存在哪些“生態型卡點”會讓這種不確定性非常高，所以前期規劃的時候我們盡可能把能規避的都規避了。

我們看到的比較大的，我們嘗試解決，也希望產業鏈的小伙伴能共同解決的一個難點就是，生成式數據庫。因為我們今天做的大多數場景，仍然集中在 CRUD 類型的系統開發上，而這個場景上最重要的就是數據庫。

我們今天做的還是相對簡單的獨立系統，但是人類至少積累了三四十年的數據資產，大量企業從 90 年代就開始使用 ERP 系統，里頭積累了三四十年的合規數據、進銷存數據，后面一代代的系統都是在這個系統上去做增量開發，或者疊加的。那么大模型時代生成的內容跟歷史內容之間的交互關系在哪兒？這是我們認為在端到端這件事情上比較大的卡點。

李亞飛：大家今天聊到了很深的場景話題。我們相信“端到端生成”就是未來，在AI能力不斷變強的情況下，端對端的核心邏輯就兩個：第一，是一個真正的Agent在工作。 未來一定不是 prompt based 的一次性交互，而是一個智能體，真正作為開發者參與到項目全流程中。第二，今天人類在架構設計、系統認知上的優勢仍然遠超 AI，所以我們就應該把這些難點提前替 AI 處理好，給它創造一個“可控的工作空間”。

哪些難點呢？宿文剛才說的數據庫是一個，還有就是框架選型，根據需求匹配最合適的語言架構。我們幫助Agent把這個運行環境給準備好，對于非專業工程師來說，這就是Agent的工作區。萬事俱備，我們最終才能塑造一個真正意義上的端對端APP的交付。

先提效，再提質

AI 科技評論：那下一個問題是一個現實但可能略顯“悲觀”的議題：我們現在看到 AI 在生成代碼的過程中，會大量制造“垃圾代碼”，因為成本太低，導致很多大廠的代碼庫越來越龐雜、難以維護。這是一個真的需要擔心的問題，還是只是個“杞人憂天”？

李亞飛：這個問題絕對是現實存在的，而且已經非常廣泛。因為今天code寫起來實在太容易了， 大模型傾向于寫點code去幫你解決問題，我就親眼見過，它寫了一個不work，它順手在下面又寫了一個，最后一塊交給我了。

解決這個問題的思路并不復雜，人類是有版本管理的，代碼推送之后是要確認的，如果你是一個比AI更好的工程師，你就在確認環節把它這些不太好的方案干掉。

其他的解決思路還有，在 prompt 設計和上下文設計里面要充分地讓 AI 知道不要瞎寫東西，盡可能多約束AI，隨時打斷。

宿文：我們其實完全沒擔心過“生成垃圾代碼”這件事。這種現象在歷史上都出現過。比如在知識傳播這件事上，從古代口耳相傳到現代信息爆炸的時代，我們也沒擔心過這個事兒。

當然，這個類比未必完全貼切。但如果我們要精準地回答這個問題，其實很簡單：你不進生產環境，代碼再臟也是工程師的事情。至于工程師在這個過程中如何轉變角色、如何管理質量，那是另一個話題。

所以，我們完全不會擔心這會影響到軟件的實際使用者。這個問題是可以解決的，而且應該在提升效率之后再回頭解決質量問題。就像生成式數據庫的問題，我們會基于存量的各種各樣的 ?數據庫構建今天的系統，但是我們知道未來新的IT架構會倒逼新的 Infra 產生。

同樣的一個字段，在不同的軟件開發廠商的數據中可能明明完全不一樣，那就需要后端程序員通過API等業務理解去做的。大模型去跨系統去理解這個事情是很難的，一定要做語義貼合，不然成本太高，所以我們只能停留在上一代的數據庫形態上。但是人類有個特點，只要倒逼到那一步，大概率也有聰明腦袋能解決。

陳石：我也同意大家的看法。這個問題是存在的，但不需要過度焦慮。放眼整個互聯網，我們已經充滿了“垃圾數據”了，但并沒有因此停滯。更重要的是，代碼和文本不同，它具有結構性、邏輯性和可驗證性——你寫得好不好，其實能跑一遍測試就知道了。

在編程世界里，有很多方法論可以幫助我們做代碼質量篩選，比如 lint 工具、單元測試、代碼審查等等。更重要的是，AI 現在也能調用這些工具自動檢測代碼。我相信有朝一日，AI 寫出的代碼質量會超過大部分普通程序員。

李亞飛：大家為什么會關心這個問題呢？我覺得本質上，軟件是一種負債，生產出來的軟件，你就得維護它，你不維護它就像一個生命一樣就要死掉了。如果你寫出來剛剛好能work的代碼，沒有及時消除你的債務的話，它就指向了一種持續維護的成本，這就有個隱形的雷。

軟件工程里面這個問題還是比較嚴重的，必須要消除掉。我們不能說這一代程序員寫出來就不管了，等下一代程序員來了接手這個“屎坑”。

陳石：這個問題最終的解決不在于代碼上，有可能就在于你的prompt提煉出來的產品規范上。如果產品規范定義得足夠優質，下一次你換個架構或換種編程語言去重寫一遍代碼問題也不大了。

李亞飛：站在產品角度，我們把它叫做產品架構，站在技術角度，我們把它叫做技術架構，這是兩位一體的東西，也是一個好產品的核心骨架。只要骨架還在，外圍的代碼爛一點關系不大。

好的技術，是需求的釋放

AI 科技評論：最后一個問題，我們今天討論了很多 AI Coding 的進展。那放眼未來，它可能會徹底改變人類與代碼的交互方式。你們認為程序員的工作會發生什么樣的變化？映射一下我們今天的主題，AI 顛覆的第一個職業，會是程序員嗎？

宿文：好的技術一定是通過創造供給的方式，激發出更多需求。當然，第一階段一定是服務于“已有程序員”的——讓他們用得更爽、更高效，尤其在一些高度垂直、封閉的場景，比如半導體領域的 firmware 這套軟件的開發，這不可能是大模型能做的事情，反而是這些程序員可以利用好 AI，工作質量可能更上一層樓。所以會有很多垂類場景長期存在。

但在另一些場景中，程序員的角色可能真的會被“再定義”。比如很多行業其實需要的只是把業務需求“翻譯”為軟件，但因為供給的效率、供給的成本、供給的質量等等限制，這個需求長期被壓抑。現在有了 AI，門檻降低了，大量非技術用戶就能用 token 去完成代碼生成，觸發出新的增量市場。這些也是我們的商業模式的范圍。

既然以后所有的代碼是依賴于token實現的，那就把它變成infra，變成infra的時候，Coding的收費邏輯也會發生改變的。這些是5年之內可以預期到的事情。

AI 科技評論：那亞飛總，您是程序員出身，肯定感受更深。

李亞飛：是，我本身就是工程師出身，所以體會確實很直接。我覺得可以用一句話總結：打孔的人不需要了，但懂打孔機原理的人仍然有價值。早期的程序員其實就是在打孔、輸入程序，那種工種確實消失了。

沒有AI干得好的人，確實不需要了。但好消息是——懂底層原理的人，在新的體系中會更加值錢。他們會成為“維護打孔機的人”，會更快地適應新范式。同時，這也意味著新工種的誕生。這是一個新的工作機會，因為生產軟件變得更便宜了，個性化軟件需求時代會到來。新時代生產軟件的人，我姑且稱之為“業務邏輯師”。

陳石：未來發展的瓶頸就變成了人和AI結構化的溝通。今天程序員真正寫代碼的時間，其實只占工作量的 20%-30%，大多數時間花在溝通、邏輯整理和系統設計上。如果模型越來越強，它不僅能寫出高質量代碼，甚至可以自動挑選最合適的語言、架構和實現方式。那時候，真正的“源代碼”可能是你在AI幫助下寫出來的產品規范文檔。

這份“文檔”可以是自然語言、流程圖、界面草圖的組合，它的結構清晰度越高，AI 實現的準確性就越好。而未來的 IDE，也許不再是代碼編輯器，而是一個“集成思維澄清器”——幫你厘清思路、表達邏輯、形成規范，剩下的都交給 AI。

到那時，程序員的核心能力，可能不是寫代碼，而是能不能清晰表達需求、構建邏輯架構。這也印證了剛才亞飛總說的“業務邏輯師”這個概念——甚至我覺得一些邏輯性強的職業，比如律師，都可能在這個新工種中如魚得水。

AI 科技評論：三位的回答其實都不約而同地指向一個趨勢：未來的程序員，也許不是“代碼工匠”，而是“業務翻譯者”和“需求架構師”。寫代碼這件事，逐漸被抽象掉，真正有價值的，是結構化表達與邏輯構建的能力。

至于“AI 顛覆的第一個職業是不是程序員”——可能不是簡單的“被替代”，而是徹底的“角色轉變”。

非常感謝宿文老師、陳石老師、李亞飛老師，今天的分享非常深入且富有啟發。這次圓桌分享到這里就正式結束了，謝謝大家！雷峰網 (公眾號：雷峰網)

雷峰網原創文章，未經授權禁止轉載。詳情見 轉載須知 。