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

OpenAI首當其沖。

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

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

Anthropic同樣有進展。

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

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

國內(nèi)，我們4月底在小紅書上獨家公布過，前月之暗面產(chǎn)品經(jīng)理明超平的創(chuàng)業(yè)項目「Yourware」上線的消息。

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

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

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

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

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

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

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

為什么Coding是AI的重要應(yīng)用場景

Matt Bornstein：

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

Guido Appenzeller：

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

Matt Bornstein：

AI Coding實際上是現(xiàn)有行為發(fā)生的“轉(zhuǎn)變”。

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

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

比如Github Copilot，它就做了這項非�；A(chǔ)的工作。通過它，人們開始從使用Stack Overflow轉(zhuǎn)移到使用AI模型，像Cursor這樣的公司現(xiàn)在在這方面做得更好。

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

Yoko Li：

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

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

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

Guido Appenzeller：

AI Coding是一個比較容易占領(lǐng)的市場。

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

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

而且，開發(fā)者們的效率還會提升。

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

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

AI讓軟件開發(fā)產(chǎn)生了怎樣的改變？

Matt Bornstein：

程序員們的工作會發(fā)生很多變化。

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

那么之后，開發(fā)者會不會都變成只負責(zé)編寫規(guī)范的產(chǎn)品經(jīng)理，然后讓 AI 去寫代碼，只是偶爾介入調(diào)試一下？這也有可能發(fā)生。

Yoko Li：

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

Guido Appenzeller：

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

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

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

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

現(xiàn)在，當人們想要編寫一個新的軟件片段時，是在嘗試先編寫一個規(guī)范，而不是生產(chǎn)代碼�；旧希藗儐柕膯栴}沒有經(jīng)過深思熟慮。比如我會問模型（可能是 Sonnet 3.5 或 3.7 或 Gemini）。“我想要做xxx，這說得通嗎？請問我有沒有說不清楚的地方，給我寫一個更詳細的版本。”然后模型就開始工作了。

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

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

Yoko Li：

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

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

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

Guido Appenzeller：

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

Yoko Li：

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

Matt Bornstein：

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

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

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

Yoko Li：

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

Matt Bornstein：

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

Yoko Li：

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

Matt Bornstein：

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

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

Yoko Li：

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

但如果是專精分布式系統(tǒng)或性能調(diào)優(yōu)的資深工程師，目前AI可能還不太行。

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

Guido Appenzeller：

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

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

Matt Bornstein：

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

Guido Appenzeller：

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

Yoko Li：

你認為強化學(xué)習(xí)能改變這點嗎？理論上，它能夠模擬相關(guān)的分布式系統(tǒng)并調(diào)試AI。

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

但好消息是，這類情況只占軟件開發(fā)的0.01%。像無數(shù)ERP系統(tǒng)，我們有海量訓(xùn)練數(shù)據(jù)，這些工具就能大顯身手。

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

Matt Bornstein：

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

Guido Appenzeller：

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

Matt Bornstein：

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

Yoko Li：

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

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

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

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

Guido Appenzeller：

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

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

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

如果按這個規(guī)律推測，未來“描述問題、解釋算法基礎(chǔ)、設(shè)計架構(gòu)、梳理數(shù)據(jù)流”會越來越重要，而“如何用最巧妙的方式展開循環(huán)”這種很細節(jié)具體的編程，很可能會變成更小眾的專業(yè)技能�！�

Matt Bornstein：

在經(jīng)典的計算機科學(xué)本科教育中，學(xué)生不僅僅是學(xué)習(xí)最新的東西。在多數(shù)情況下，甚至要會花一學(xué)期學(xué)匯編語言。

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

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

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

傳統(tǒng)的編程語言會怎樣？

Guido Appenzeller：

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

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

Yoko Li：

類比來看，現(xiàn)在很多公司在開發(fā)agent。當觀察它們的運作方式時，會發(fā)現(xiàn)它們本質(zhì)上就像操作系統(tǒng)課程里學(xué)的“進程”——一個進程處理任務(wù)后交給下一個，再配合資源管理。

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

Matt Bornstein：

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

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

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

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

Yoko Li：

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

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

Yoko Li：

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

Guido Appenzeller：

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

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

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

Matt Bornstein：

你提到的復(fù)雜性區(qū)分很精妙，這可以理解是一種繁雜的系統(tǒng)，也可以理解成難以使用。

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

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

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

Yoko Li：

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

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

Matt Bornstein：

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

Yoko Li：

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

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

Matt Bornstein：

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

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

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

AI現(xiàn)在能協(xié)助但無法徹底解決這個問題。

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

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

Guido Appenzeller：

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

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

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

Yoko Li：

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

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

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

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

如何應(yīng)對AI的非確定性輸出

Matt Bornstein：

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

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

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

Guido Appenzeller：

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

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

Matt Bornstein：

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

Guido Appenzeller：

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

Matt Bornstein：

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

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

Guido Appenzeller：

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

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

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

提示詞（prompts）是AI編程的核心節(jié)點

Yoko Li：

互聯(lián)網(wǎng)的演進過程中曾存在關(guān)鍵的"窄腰結(jié)構(gòu)"（narrow waist，如TCP/IP協(xié)議棧中的IP層，擁有非常精簡的核心功能，卻承擔著數(shù)據(jù)鏈路中承上啟下的聯(lián)通作用）。你認為AI發(fā)展會呈現(xiàn)類似的架構(gòu)規(guī)律嗎？這種類比是否成立？或許AI系統(tǒng)根本不會形成這樣的核心約束層？

Guido Appenzeller：

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

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

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

Yoko Li：

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

Matt Bornstein：

當然，它顯然也不像英語，這讓我覺得，我們其實都在學(xué)習(xí)一種新的語言，用來引導(dǎo)這些工具。

Guido Appenzeller：

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

Matt Bornstein：

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

Yoko Li：

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

Guido Appenzeller：

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

Yoko Li：

這種情況已經(jīng)發(fā)生了。現(xiàn)在的模型都有JSON模式，用戶可以定義自己想要的東西。

Guido Appenzeller：

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

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

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

Yoko Li：

我不這么認為。

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

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