a16z最新播客，解釋AI Coding的一切

在AI公司們在卷生卷死的2025年，AI Coding依舊是必爭之地。

OpenAI首當其沖。

就在兩天前，它宣布在 ChatGPT 中引入 Codex 研究預覽版——目前他們最強大的AI編程助手。

它能夠并行完成編寫、解答代碼庫相關問題、修復 bug 以及提交拉

不僅如此——半個月前，OpenAI還曝出收購 Windsurf 的消息 ，交易金額達到30億美元。

圖源彭博社新聞

Anthropic同樣有進展。

彭博社報道，蘋果正與Anthropic 合作開發一款名為“Vibe-Coding”的軟件平臺。

Anthropic 的 Claude Sonnet 模型被集成到蘋果的 Xcode 新版本中，幫助程序員更高效地寫代碼。

圖源路透社新聞

國內，我們4月底在小紅書上獨家公布過，前月之暗面產品經理明超平的創業項目「Yourware」上線的消息。

Yourware 定位為“Vibe Coder’s Instagram”，提供一鍵部署網頁、展示 AI 編程用例以及社區互動等功能。

「四木相對論」小紅書相關內容

但即便進展神速，關于AI Coding依舊有許多未解之謎。

比如，Vibe Coder是不是AI Coding的"唯一"用戶群？強化學習能減少AI Coding工具的幻覺嗎？AI出現后，傳統計算機知識是否還值得學習？如何降低AI Coding的黑盒影響？未來，我們是否分別需要面向"Vibe Coder"的模型和面向企業級開發的模型？

在 a16z 最新一期AI播客中，a16z 的投資人 Matt Bornstein、Yoko Li 和 Guido Appenzeller 探討了這些話題。

他們提出了一些有趣的觀點：

• AI Coding已成為第二大AI市場，僅次于面向消費者的聊天機器。人工智能生成代碼預計將給市場帶來數萬億美元的生產力增長。
• AI會對開發流程產生影響，開發者從編寫代碼轉向編寫“規范”，AI負責實現。
• Vibe Coding的影響有限。Python和Java這樣的語言會一直存在，即使自然語言交互變得普遍。
• 現在多數IDE對使用工具的數量有限制（比如40-50個），這天然限制了AI能調用的上下文和工具的范圍。
• 現在的一些AI Coding工具與程序員操作之間存在斷層，需要中間產品賦予用戶修改底層的能力。
• AI Coding將鼓勵更多人參與“寫程序”這件事。新人群+新方法很可能催生全新的軟件形態和應用場景。

「四木相對論」對這期播客進行了編譯，全文如下，歡迎閱讀 ：

為什么Coding是AI的重要應用場景

Matt Bornstein：

從數字上看，我們很確定Coding目前是第二大AI市場，第一名是面向消費者的純Chatbot。

Guido Appenzeller：

如果將像 ChatGPT 這樣的工具歸類為“有用的伴侶”，那么編程市場可能比聊天機器人市場更大。

Matt Bornstein：

AI Coding實際上是現有行為發生的“轉變”。

以前，當人們遇到無法解決的問題時會去互聯網上查找信息，比如Stack Overflow（一個關于編程方面的問答網站）。

有一些玩笑說，“在過去數年里，Stack Overflow實際上編寫了大部分代碼”，現在這個動作被轉移到了AI模型上。

比如Github Copilot，它就做了這項非常基礎的工作。通過它，人們開始從使用Stack Overflow轉移到使用AI模型，像Cursor這樣的公司現在在這方面做得更好。

總之，AI Coding針對的是一個有需求的市場。這就像在存量市場中，銷售一個很有競爭力的新產品。

Yoko Li：

開發者是新技術的早期采用者，因為他們喜歡嘗試新工具，任何能夠提高生產力的技術都會被他們快速接受。

而且，編程問題具有明確的驗證標準（如輸入輸出），這使得 AI 編程工具的應用場景非常清晰。

Coding的美妙之處在于，你可以將許多現實世界的問題轉化為機器可處理的格式。

Guido Appenzeller：

AI Coding是一個比較容易占領的市場。

因為開發人員相對而言理解 AI 技術，這可能是人工智能的第一個真正的大市場。

試著算一下，全球大約有 3000 萬開發者。假設每個開發者每年創造10萬美元的市場價值，那么市場總價值能達到約3萬億美元，相當于蘋果公司這種科技巨頭的市值

而且，開發者們的效率還會提升。

有大型金融機構估算，普通Copilot的部署可以提高開發人員大概15%的生產力。我的直覺是，這個提升還將更大。完全可以想象，未來世界上所有開發人員的生產力會提高一倍。

去年，關于我們是否過度投資AI的討論非常熱烈。我記得當時的數字是每年投資2000億美元，但如果和3萬億美元的市場價值比較，這個投入就像是“花生米”的大小。

AI讓軟件開發產生了怎樣的改變？

Matt Bornstein：

程序員們的工作會發生很多變化。

當下已經能看到一些跡象。比如我現在寫代碼時，其實是在編寫“規范”，和一個模型討論如何實現某個功能。對于簡單的功能，可以直接讓模型去實現，人只需要審查一下。

那么之后，開發者會不會都變成只負責編寫規范的產品經理，然后讓 AI 去寫代碼，只是偶爾介入調試一下？這也有可能發生。

Yoko Li：

或者我們都成為QA工程師，測試它是否足夠好。

Guido Appenzeller：

就我自己來說，過去的六個月里，我使用這些模型的方式發生了很大變化。

以前，首先我會選擇最喜歡的工具，比如 ChatGPT 或類似的工具，然后給它提示詞（prompt），它會輸出一個程序，然后把這個程序復制到編輯器里，看它是否能運行。它這就像是 Stack Overflow 的替代品。當我遇到問題時，不會去 Stack Overflow，而是去 ChatGPT找它直接返回代碼。

到下一步，就是開始集成到IDE。比如 GitHub Copilot 和 Cursor 這樣的工具，它們有自動補全功能，這是一大進步。不再像以前那樣是單一的、塊狀的解決問題，而是融入了開發流程。在代碼行級別，我可以詢問關于代碼段的問題，或者我可以有一個單獨的聊天界面，用于進行更長的討論。

接著，IDE 開始能使用命令行工具。我們可以對它說：“嘿，你能幫我設置一個新的 Python 項目，使用 UVloop 或類似的東西嗎？”它可以運行命令來完成所有這些工作。

現在，當人們想要編寫一個新的軟件片段時，是在嘗試先編寫一個規范，而不是生產代碼。基本上，人們問的問題沒有經過深思熟慮。比如我會問模型（可能是 Sonnet 3.5 或 3.7 或 Gemini）。“我想要做xxx，這說得通嗎？請問我有沒有說不清楚的地方，給我寫一個更詳細的版本。”然后模型就開始工作了。

通常，它也會有很多問題問我，比如“嘿，我需要一個 API 密鑰才能做到這一點”，比如“你想要如何管理狀態？我們應該把它放在數據庫里嗎？還是只是用一個計算機文件之類的東西？”

它會通過來回討論，幫助我理清思路。雖然有些奇怪，它確實有效。隨著時間的推移，我會得到更詳細的規范。當有了這些規范后，我就會要求模型實現。

Yoko Li：

與六個月前相比，我現在使用 Coding Agent 的方式是，我更多地提供知識。以前，我主要依賴于基礎模型的知識。

現在，我覺得很自然地會去 Linear（一個項目管理工具）那里，找到對應的工單（ticket），然后把我的想法拉到 Cursor中，Agent 會先嘗試實現它，這是一種工作流程的變化。

另一種變化是更用戶驅動的，像主動查詢。以前，我可能需要把文檔復制粘貼到我的 Cursor 窗口中。現在，我只需要讓 Cursor Agent 去用 Firecrawl（一個爬蟲工具）查找最新的 Clerk 文檔（一個提供身份驗證服務的平臺的開發者文檔）。它會實際抓取一個頁面，然后我可以閱讀它。

Guido Appenzeller：

那是如何工作的，要使用MCP嗎？

Yoko Li：

要使用MCP，但更多可能是與現實世界有更多的集成。

Matt Bornstein：

你們聽起來比我經驗豐富得多。對我來說，場景通常是這樣的：周六晚上，我終于有一個小時的空閑時間，突然有了一個奇怪的應用程序想法，我就會直接開始動手讓 Cursor 去完成所有的事情。

我發現它在處理復雜度高、繁瑣的任務時特別有效，比如前端開發。如果現在地球上有人能記住現在用來設置邊距和內邊距的所有 CSS 內容，那真是難以想象。

我們有相應的標準記錄。這本不該是一個很難的問題。總共有五種不同的方法可以用來居中文本和元素，但我從來記不住它們。但AI 模型在這方面真的很擅長，而且它們現在可以做到。當我開始涉及到更小眾的庫和函數調用時，我喜歡用 Firecrawl 。

Yoko Li：

是的，有時我也會像復制 Mintlify Docs 那樣，直接拷貝整段 LLM 文本。我只需要提供文檔的 URL或者文件，然后讓 Cursor 去實現它。

Matt Bornstein：

Yoko你在 MCP 方面上做了很多工作，你覺得MCP扮演了什么角色？

Yoko Li：

我認為 MCP 的本質就是提供相關性最強的上下文給語言模型。我可以使用 Linear MCP，也可以使用 GitHub MCP 來拉取相關的上下文和技術細節。但 MCP 的核心其實還是上下文，它要搞清楚自己能給模型提供最相關的東西是什么，以便模型能更好地幫助用戶。

Matt Bornstein：

你覺得在IDE中集成這類AI工具，是否意味著AI編程對資深開發者更高效或更實用？

因為長期以來有個質疑是，AI Coding更多是"vibe coders"在使用，因為AI能快速做出很炫的demo，初級開發者也能快速上手。而那些資深派，比如負責集群架構、防止系統崩盤的程序員，往往對AI持懷疑態度。你認為IDE中集成AI工具是吸引他們參與的一種方式嗎？

Yoko Li：

我覺得這取決于資深工程師的核心目標。比如有些資深應用工程師擅長快速實現想法，這類工具能均衡他們的技能分布，他們只需要把技術棧搭起來就行。

但如果是專精分布式系統或性能調優的資深工程師，目前AI可能還不太行。

因為編程助手無法獲取分布式系統的全部狀態，很多問題仍需人工干預。不過隨著上下文窗口擴大和工具調用能力增強，我們正在朝這個方向進步。現在多數IDE對工具數量有限制（比如40-50個），這天然限制了AI能調用的上下文和工具的范圍。

Guido Appenzeller：

這里有一個規律：問題越是深奧，你試圖解決的問題越新穎，需要提供的背景信息就越多。比如“幫我寫篇博客"或者"做個簡化版網店"——這種標準本科軟件開發課的題目，網絡上的樣例幾乎無窮無盡，模型已經見過無數次，完成起來就會非常拿手。

但若遇到訓練數據極少的領域，情況就完全不同。你必須事無巨細地說明需求：提供上下文、API規范等，難度陡增。

Matt Bornstein：

而且模型還會“信心十足”地給出錯誤答案。更糟的是它死不認錯，還會繼續編造。

Guido Appenzeller：

當前模型最致命的缺陷，就是"無法承認自己不知道"。

Yoko Li：

你認為強化學習能改變這點嗎？理論上，它能夠模擬相關的分布式系統并調試AI。

極端情況下，如果你是地球上第一個解決某個問題的人，訓練數據就是零。我認為現在模型目前還缺乏真正的創造力，它們只能做有限的知識遷移。比如為全新架構芯片編寫首版驅動，這基本還得靠人工。

但好消息是，這類情況只占軟件開發的0.01%。像無數ERP系統，我們有海量訓練數據，這些工具就能大顯身手。

"Vibe Coding"與計算機教育的未來

Matt Bornstein：

雖然我們沒多談"Vibe Coding"，但非開發者現在也能寫代碼，很酷對吧？

Guido Appenzeller：

這個話題中的問題是，這件事能否在所有情況下成立。就像人人能搭棚屋，但造不了摩天樓？

Matt Bornstein：

這正是關鍵——多數人第一次用網站生成器或Cursor做的demo可能沒啥實際價值。但如果其中一部分人逐漸進階，用完全不同于傳統編程的方式做出復雜項目，會發生什么呢？我對這件事非常樂觀：新人群+新方法很可能催生全新的軟件形態和應用場景。

Yoko Li：

這讓我想起2000年左右，“博客”還是個新鮮詞，所有人都覺得“我得開個博客”。然后大家一窩蜂去建博客，接著 WordPress （使用PHP語言開發的開源發布平臺，用戶可以在支持PHP和MySQL數據庫的服務器上架設屬于自己的博客、網站）出現了。直到現在還有人用 WordPress，我還挺意外的。

而這次vibe coding的浪潮，感覺就像所有人——我、我媽、甚至我媽的鄰居——都在嘗試用這些模型來打造個人化的東西。我們算是從“個人靜態內容”過渡到了“個人 CRM客戶關系管理”，用來管理人際關系之類的事情。

軟件的落地深度能做到什么程度？說實話，我覺得不會很深，但這不重要。只要對人們來說實用就行。

另外，我一直在想，對于“Vibe coder”來說，低一層的抽象（level lower abstraction）是什么？是代碼？是 IDE？還是別的什么？想聽聽你們的看法。

Guido Appenzeller：

我覺得這是個非常好的問題。我稍微重新表述一下：未來想從事軟件開發的人，到底需要掌握什么？是更深一層的東西，還是說其實是橫向的某種能力？有些人會說：“現在學計算機科學沒意義了，重點是社會情感學習(Social and Emotional Learning,簡稱SEL)”。我其實不太認同。

說實話，我完全不知道五年后的計算機教育會變成什么樣。

但如果回顧歷史，類似的事情發生過——比如計算方式的演變：我們從手動加減數字到用 Excel，但“記賬員”這個職業并沒有消失，而是變成了“會計師”。數據錄入和手動計算變得不那么重要，更高層次的抽象能力（比如分析模式）反而更關鍵。

如果按這個規律推測，未來“描述問題、解釋算法基礎、設計架構、梳理數據流”會越來越重要，而“如何用最巧妙的方式展開循環”這種很細節具體的編程，很可能會變成更小眾的專業技能。”

Matt Bornstein：

在經典的計算機科學本科教育中，學生不僅僅是學習最新的東西。在多數情況下，甚至要會花一學期學匯編語言。

都是從“最古老”的東西開始學習。即便是“世界上最糟糕的計算機工程師”，同樣要學習怎么接門電路，學處理器是如何工作的。接著是文件系統和操作系統基礎。當然也學Java——當時它還是尖端技術，不過現在嘛……所以人們容易認為，新一代技術只是堆疊在這些基礎之上的工具，而學編程可能只剩歷史或教育意義。我不確定是否真是如此。

幾十年，有很多新的編程接口（programming interface）出現。但AI 實際上并不是一個編程接口，它也不是一個框架。它更像是一個工具，它幫助你使用你已經擁有的東西。

所以這讓我懷疑，我們是否是在等待下一個迭代，即 AI 真正可以改變計算機編程方式的東西。比如，或許會出現一種能直接將自然語言提示詞轉化為代碼的機制，而現在的AI代理只是起點。這就是我好奇的方向。

傳統的編程語言會怎樣？

Guido Appenzeller：

今天我認為 AI 不僅僅是一個高級語言抽象之類的東西。但未來會不會演化成那樣？

用大語言模型（LLM）來設計編譯器或編程語言，和用經典的編譯器設計，思路會完全不同。雖然我們還不知道最終會是怎么樣，但如果能用精煉的人類語言直接定義某些邏輯，并將其作為編譯器輸入，變革會非常巨大。

Yoko Li：

類比來看，現在很多公司在開發agent。當觀察它們的運作方式時，會發現它們本質上就像操作系統課程里學的“進程”——一個進程處理任務后交給下一個，再配合資源管理。

這正是計算機教育不會消失的原因：它提供了一套理解本質的參照系。否則你甚至不會知道‘進程’這個概念的存在。但另一方面，在基礎模型之上，我們還沒發明出類似操作系統那樣的成熟范式。

Matt Bornstein：

形式化語言（formal languages）的存在有必然性——無論是編程語言還是規范語言。

人類總需要一種高帶寬、高表達力的方式來設計軟件（或其他事物）。所以我很難想象Python或編程語言會完全消亡。就像剛才Yoko說的：你必須理解至少低一層的抽象。

有個有趣的問題：某些語言是否會因為更“AI原生”而變得更流行？比如現在的 Python和JavaScript。

工具鏈的發展也很有意思——Python生態最近涌現了大量新工具，活躍度前所未有。這自然會影響到它與AI擴展的兼容性。所以，我覺得我們不可能完全拋棄這些傳統語言。

Yoko Li：

需要理解底層抽象的原因在于：當你要優化系統時，有些知識就派上用場了。如果不需要優化，確實可以不懂。就像早年用Java寫計算器的人根本不用了解 GBM（Gradient Boosting Machine ），但如果要用它做多線程優化就必須懂。

vibe coding也是同理——做個營銷網站可能不需要深究優化，但如果要支撐大規模訪問，就得懂CDN、頁面緩存這些。

Yoko Li：

不了解本質幾乎不可能成功。計算機可以做某些事情，是由形式語言定義的。這些語言層層堆疊，要想真正操控系統，就必須理解它們。

Guido Appenzeller：

我同意。我認為這些語言不會消失，因為它們雖然看起來很復雜，但往往是用最簡潔的方式表達精確意圖的最佳載體。

自然語言通常不夠精確，需要更多詞匯才能達到同樣效果。

現在有趣的問題是：AI能否在某些場景下，通過理解人類語境、結合智能符號系統，將自然語言描述準確轉化為代碼？目前在某些領域已經可行，但能否進一步雜交出新型語言？我還說不準。

Matt Bornstein：

你提到的復雜性區分很精妙，這可以理解是一種繁雜的系統，也可以理解成難以使用。

人們常覺得編程語言復雜是因為難學，但實際上它們可以很簡單，可以用一套有表達范式的東西畫一棵樹。

當我們轉向的“AI編程”雖然看似更易用，但底層卻復雜得多。

所以關鍵是如何平衡？是否需要混合方案？Cursor團隊提倡的'形式化規范'寫作或許是個方向——就像Guido說的，未來人們可能更多需要撰寫精確的規格說明。

Yoko Li：

我最近采訪過一位典型Vibe Coder。

我的問題是：“你真的需要編程界面嗎？”畢竟現在輸入提示詞就能生成大段代碼。他的回答很有意思：“AI生成代碼并展示給我看的過程讓我充滿成就感，但當我想手動修改時，卻完全無從下手。”

Matt Bornstein：

這不限于新手程序員。就算是我們這些人，用AI生成四五輪代碼后想手動編輯也會非常困難——整個代碼變得極其晦澀。

Yoko Li：

我在用Blender MCP時遇到了這個問題。我以前從未使用過Blender，我通過Cursor IDE的MCP服務，輕松生成了微縮模型。但要修改這個3D模型時，系統就崩潰了，我連該從哪開始改都不知道。

所以，AI 與 Vibe Coder之間的空白地帶也有很多機會。

Matt Bornstein：

最酷的地方在于，AI實際上為軟件開發創造了一個前所未有的新語境層和意圖層。比如，AI能幫助遷移舊代碼嗎？比如銀行業試圖淘汰COBOL語言都喊了快一百年了。

但說實話，答案可能是否定的。 AI當然能提供幫助，但解決不了核心難題。具體來說：AI或許能把COBOL轉譯成Java，可當年編寫這些COBOL代碼時的大量上下文早已在幾十年間消失殆盡。

這些系統往往經歷了魔改，最初只是個機票預訂系統，后來逐漸塞進了人力資源模塊、甚至訂咖啡功能（笑）。而許多參與開發的程序員（順便說一句，他們基本不寫文檔或注釋）可能早就不在這家公司——或者不在人世了。

AI現在能協助但無法徹底解決這個問題。

不過話說回來，真正讓我更感興趣的是另一件事，當我們討論測試用例和規格文檔時，我就在想：如果當年構建這些系統時就有AI參與，那么開發者的原始意圖就會自動留下完整的記錄。

這相當于白送的白送的福利對吧？根本不需要事后補做。

Guido Appenzeller：

這個觀點很有趣。我最近和一些大型企業交流時發現，他們正在用AI處理遺留代碼庫——特別是大型主機上的COBOL和PL/I這類語言。

這個過程特別有意思，他們遇到的正是你描述的問題：如果只看舊代碼，根本搞不清原始開發意圖；如果直接翻譯代碼，又會繼承舊編程語言的各種古怪特性（畢竟Java有更現代的語法結構，而COBOL根本沒有這些特性）。

目前我從多個機構聽到的最佳實踐是：先讓AI根據舊代碼生成技術規范說明書，然后基于這份規范重新實現代碼。這樣做得到的結果遠比直接轉譯要好——代碼更精簡、更符合現代標準。就像處理古董家具，與其強行改造榫卯結構，不如先測繪圖紙再重新打造現代版本。

Yoko Li：

是的，很有趣。我剛剛就在想：重寫現代軟件（比如近10年的）其實容易得多——比如從Angular遷移到React，尤其是Agent對這兩個框架都很熟悉的情況。但如果是PHP轉，那可能就不一樣了。像Laravel這類框架，遷移起來還算順利，畢竟生態比較完善。但具體難易程度還得看框架類型。

真正的硬骨頭是那些橫跨多個軟件系統的遺留系統——你得先做全面的系統勘探，或者訓練一個能自主探索的智能體，這個方案我覺得理論上可行。

但還有硬件層特有的坑，比如某些遺留系統跑在特制硬件上，比如要給Docker容器分配精確的內存參數，或者需要特定運行時配置。

就像你剛才說的，這些細節往往早已湮滅，除非能對運行時環境做完整快照。否則連系統到底需要什么資源都搞不清楚，這種遷移根本是無米之炊。

如何應對AI的非確定性輸出

Matt Bornstein：

我現在已經開始做噩夢了，想象某個生產環境突然崩潰，而你不得不翻查GPT的對話日志，試圖還原某人可能誤操作了什么...

這里可以引出另一個有意思的問題：如果我們把AI視為應用程序的原生組件，而非僅是寫代碼的工具。它似乎正在突破軟件系統中確定性與非確定性行為的邊界。

想想很早之前——開發者只為本地機器寫代碼時，對程序行為了如指掌。后來網絡的出現帶來了不可預測性，但至少還能用相同范式去描述。而當AI被集成進系統，或讓它生成代碼時，你根本不知道會發生什么。你覺得這種類比成立嗎？從網絡時代積累的經驗，能否幫我們應對AI帶來的混沌與未知？

Guido Appenzeller：

確實可以這么類比——雖然我們還沒完全消化這些經驗教訓。 回想網絡系統剛普及時，冒出了全新的故障模式。比如超時問題以及隨之產生的重試機制等解決方案。但到了分布式數據庫階段，問題就復雜多了：必須處理原子性和數據回滾這些數字語境下的新挑戰。

而直到今天，這些設計模式仍不完善，雖然有強大的潛力，又帶著各種不穩定的特性。

Matt Bornstein：

有些問題可能是無法解決的？

Guido Appenzeller：

根本性問題確實無法解決，但至少可以讓開發者用起來盡可能簡單。說到底，所有工具都是為了幫開發者緩沖這些沖擊。

Matt Bornstein：

是的，現在的輸入框簡直成了混沌系統，早年間只要防住單引號就能安全執行SQL語句，現在呢？用戶可能輸入任何東西，任何事情都可能發生。

或許我們真正需要做的，是重新定義系統的基礎能力和接口規范，讓開發者能夠合理使用這些能力，而不是要試圖消除所有可能的故障模式，比如完全規避網絡超時問題。

Guido Appenzeller：

我認為這只是問題的一部分。我們還需要改變預期標準。我曾與一家大型銀行交流，他們部署了一個文本生成系統。要知道，金融機構從不提供投資建議，所以他們要確保這個語言模型既保持高實用性，又絕對不能（哪怕是隱晦地）給出投資建議。

這本質上是個無解難題。你可以不斷優化模型，但永遠無法徹底杜絕這種情況。即便設置第二道過濾機制，這個安全層偶爾也會因為"誤判為有效幫助"而出錯。最終他們不得不做出決定：我們無法開發出絕對不犯錯的系統，必須調整評估標準。

我記得最終設定的標準大概是：出錯概率不得超過訓練有素的銀行職員在相同情境下犯錯概率的一半。

提示詞（prompts）是AI編程的核心節點

Yoko Li：

互聯網的演進過程中曾存在關鍵的"窄腰結構"（narrow waist，如TCP/IP協議棧中的IP層，擁有非常精簡的核心功能，卻承擔著數據鏈路中承上啟下的聯通作用）。你認為AI發展會呈現類似的架構規律嗎？這種類比是否成立？或許AI系統根本不會形成這樣的核心約束層？

Guido Appenzeller：

我認為可能是提示詞（prompts）。

重大技術變革往往建立在抽象層之上，就像SQL數據庫用簡潔的API封裝了底層復雜性，以及早期事務型數據庫的B*樹索引機制。那是研究生課程內容，現在誰還需要關心？我們只需編寫查詢語句。

現代機器學習的發展軌跡如出一轍：不再需要高薪聘請PhD專家訓練模型，現在通過提示詞（prompt）就能駕馭模型。這使得一個普通的Python程序員，也能通過提示詞調用強大的LLM能力。

Yoko Li：

如果深入研究這些提示詞，你覺得它們像是你想要做的事情的自然語言表達嗎？因為沒有標準，提示詞可以是任何東西，無所不包，它幾乎沒有一個明確的規范，可以說它并不是一種正式語言。

Matt Bornstein：

當然，它顯然也不像英語，這讓我覺得，我們其實都在學習一種新的語言，用來引導這些工具。

Guido Appenzeller：

我們會有正式的提示語言嗎？

Matt Bornstein：

有斯坦福的博士們正在研究這個問題，希望他們能有所突破。

Yoko Li：

我們亞洲的團隊也在研究正式的提示語言。

Guido Appenzeller：

我們已經開始看到一些有結構的提示語了，比如在問答結束時說一句“好的”。但這也算不上很正式。但我覺得這是一個起點，未來模型可能會在更結構化的表達上進行訓練和微調。

Yoko Li：

這種情況已經發生了。現在的模型都有JSON模式，用戶可以定義自己想要的東西。

Guido Appenzeller：

從長遠來看，我一直在思考對于一個推理模型而言，如果大部分思考過程發生在內部，那么面向用戶和機器的輸出模型，是否會與推理階段的模型完全不同？這聽起來可能有些抽象。

比如，我們可能需要一個健談的聊天模型，或者一個更簡潔的模型，又或者專門生成JSON格式輸出的模型。這就引出一個可能性：未來的模型輸出層可能會與推理層完全分離。

那么問題來了，我們是否最終會發展出面向"Vibe Coder"的模型和面向企業級開發的模型這兩個完全不同的分支？

Yoko Li：

我不這么認為。

我覺得Vibe Coding就是你讓模型根據需求去生成需要的東西。你不在乎實現的細節，關心的是最終實現的結果是否是自己想要的。傳統編程中，開發者需要做出大量技術選型決策，比如選擇使用這個SDK而非另一個。

在Vibe Coding中，只要最終能達成目標，開發者根本不需要關心底層技術細節，但仍需聚焦需求（否則寫這段代碼的意義何在？）。現在我完全可以預見，企業用戶也會采用Vibe Coding模式。