Vibe Coding（氛圍編碼）的出現(xiàn)，讓程序員不再需要逐行手寫代碼，而是通過與大模型的來回對話，把模糊的想法、半成型的設計，甚至不夠明確的需求，逐步轉化為可運行的軟件。

聽起來很酷，但這種方式的流行，也讓不少程序員心頭一緊：難道自己要被取代了？

本文作者有著 40 年的編程經(jīng)驗，從 80 年代在 8 位機器上寫匯編語言起步，先后用過二十多種語言，涉足過科學軟件、移動應用和商業(yè)系統(tǒng)。他在最初看到“氛圍編碼”這個趨勢時，同樣感到焦慮。

于是，為了弄清這到底是威脅還是真機遇，他親自做了一個實驗——讓 AI 來寫一個小型項目：用 Python 實現(xiàn)，大約 5000 行代碼、50 個文件、20 個類，最終得出如下的心路歷程，我們不妨來看看。

作者 | Marco Benedetti 責編 | 蘇宓

出品 | CSDN（ID：CSDNnews）

想必不少程序員都聽說過“Vibe Coding”（氛圍編碼）這個詞：簡而言之，就是讓 AI 助手負責代碼的編寫、重構和調(diào)試，而你只管盯著自己想構建的東西即可。換句話說，寫代碼這事兒可以和 AI 一起干，甚至完全交給一個專門為此訓練的大模型智能體。

作為一個寫了幾十年代碼的老程序員，我對這事兒既好奇又有點發(fā)怵——難道說“計算機編程的藝術”，以后不再是藝術了，而是由聰明的“機器人”在流水線上批量生產(chǎn)？

為了搞明白，我決定親自試試，做一次小型實驗：在兩周時間里，用大概 40 個小時，借助最新的 AI 編程助手開發(fā)一個小型軟件項目。這個項目是用 Python 寫的，大約 5000 行代碼、50 個文件、20 個類。

主題也挺有意思的：用教科書里講的那些標準 AI 搜索算法，去解決教科書里常見的經(jīng)典 AI 難題。

接下來就是我在這個 AI 輔助編程實驗里的過程、收獲和感受。最終成果你能在 GitHub 上看到：https://github.com/mabene/vibe。

在這里，我也做一下自我介紹：我有 40 年寫代碼的經(jīng)驗，從 80 年代的 8 位機器上編寫匯編語言干起，多年來使用過 20 種編程語言，并且做過科學軟件、移動應用和商業(yè)系統(tǒng)，期間既有獨立開發(fā)，也有與團隊合作。此外，并且我還拿過人工智能博士學位（那是 LLM 之前的年代）。

所以你看，這就有點意思了：一個 AI 老手，用 AI 助手寫 AI 代碼！套娃一樣的感覺，不知道會不會蹦出點意外的火花……

軟件的功能，以及它是如何開發(fā)的？

我用 Python 開發(fā)了一個靈活的、帶有教學意義的漢諾塔解題器。

如果你是程序員、謎題愛好者、計算機科學家，大概率已經(jīng)知道漢諾塔是什么了；如果沒聽過，那我也稍微解釋一下，漢諾塔是一個根據(jù)傳說形成的數(shù)學謎題，要求按照特定規(guī)則把盤子從一個柱子移到另一個柱子。維基百科給出的示例如下：

有三根桿子A，B，C。A桿上有 N 個 (N>1) 穿孔圓盤，盤的尺寸由下到上依次變小。要求按下列規(guī)則將所有圓盤移至 C 桿：

1. 每次只能移動一個圓盤；

2. 大盤不能疊在小盤上面。

可將圓盤臨時置于 B 桿，也可將從 A 桿移出的圓盤重新移回 A 桿，但都必須遵循上述兩條規(guī)則。

問題為：應該以何種方式移動？最少要移動多少次？

隨著盤子數(shù)量增加，謎題的最短解法會呈“爆炸式”增長。對人類來說幾乎不可想象，但對機器來說卻很“簡單”——用專門或通用的搜索算法就能構造出來。

本文展示的解題器實現(xiàn)了其中一些算法。它不僅能解決經(jīng)典版本的漢諾塔，還能處理廣義版本，包括 (a) 任意的起始和目標配置，(b) 一次能搬多個盤子的情況。

我實現(xiàn)的搜索算法涵蓋了從經(jīng)典的遞歸和廣度優(yōu)先搜索，到深度優(yōu)先、迭代加深、A* 搜索、貪心最佳優(yōu)先、雙向 BFS 等等——既有最優(yōu)的，也有非最優(yōu)的策略。

這個算法核心被嵌入到一個 Python 腳本中：它有直觀的命令行語法，可以逐步可視化解法，可以對不同方法進行性能測試，還能處理經(jīng)典、自定義、以及隨機的起始/終止配置。

雖然漢諾塔是一個傳統(tǒng)的、教材級的經(jīng)典問題，但這份實現(xiàn)是完全從零開始寫的——包括數(shù)據(jù)結構和算法。代碼是在多個 AI 助手的協(xié)作下生成的（詳見后文）。沒有任何一行代碼或文檔是人類程序員直接寫的。相反，開發(fā)過程更像是一場長時間的實時技術對話：我用英文和 AI 助手們在 Cursor（一個面向開發(fā)者的 AI 驅(qū)動 IDE）里進行結對編程。

總共進行了 300 多次人機交互，大約耗時 40 小時。如果算下來，平均每次交互 8 分鐘；但實際對話的速度要快得多——我大部分時間都花在評估和審查 AI 助手的輸出上。

這些 AI 助手到底有多強？

開門見山說吧：我真的被這些 AI 助手的理解力震撼到了——既懂代碼，也懂自然語言指令，能力簡直驚人。

好幾次我在輸入提示后心里想……也許我表達得不夠清楚……結果助手不僅完全理解，還能補全我邏輯或表述上的缺失，然后把我的意思解釋得比我自己還清楚。

在 Python 編程語言的掌握上，它們的水平顯然超越普通的程序員：無論是生成的準確度、速度、語法和語義的地道性、對標準與非標準庫的精準調(diào)用，還是其他方面。

和這些編程助手的對話中經(jīng)常閃現(xiàn)出看似“真正智慧”的火花，甚至超越了編程本身。比如，我問代碼是否應該對無解的問題拋出異常，結果 AI 助手證明了這個問題不存在“無解”：所有（隨機生成的）謎題都有解。

AI 通過把問題映射到圖空間，然后用反證法推理得出這一結論，還帶著完整的思路鏈。我不認為這是模型在訓練時集中“背誦”出來的（雖然我沒去核查）。我當時正好在手工草擬同樣的證明，可能需要 10 分鐘；AI 助手 30 秒就寫完并落下 “QED”。我又花了 30 秒讀完并信服——直接省下 9 分鐘，這還是一個純粹的智力型、非平凡的任務！

此外，我也不得不承認，有幾次在一些簡單的算法細節(jié)上被 AI 助手抓了現(xiàn)行……說實話有點尷尬，但也挺輕松的，因為這些工具完全沒有評判意味，反而讓人覺得很自在、很解放。

等等……你說的到底是哪款 AI 編程助手？

對了——并不是所有 AI 編程助手都一樣。我曾嘗試過三款大模型產(chǎn)品，它們在 2025 年 7 月時都算是最頂尖的一類：OpenAI 的o3、Anthropic 的Claude Sonnet 4，以及 Google 的Gemini Pro 2.5。

我使用o3的時間很短。后來我發(fā)現(xiàn)，我更喜歡把 o3 當成“AI 助手”，不是讓它直接寫代碼，而是用來查參考資料、驗證算法性質(zhì)、解答語言語義問題、生成修復/清理代碼的腳本、畫圖，以及對一些事情給出第二意見——包括本文本身。結果證明它在這些方面都非常出色。

之后我因為一次小插曲偶然間轉向了 Gemini：在某次會話里，我讓它寫一個帶點圖靈機風格的小程序，讀取紙帶來判斷帶上的符號是否在不同進制下表示同一個整數(shù)。這是個很懷舊的任務，讓最前沿的 AI 去處理，感覺像是回到人工智能之父當年關于計算的思想實驗?？傊?，我發(fā)現(xiàn) Gemini 的輸出結果中文字表述很吸引人，代碼也很靠譜。于是我開始用 Google 的助手來推進漢諾塔項目。根據(jù)輸入輸出的 token 統(tǒng)計，大約有 15% 的項目內(nèi)容來自 Gemini（主要是初始搭建和早期實現(xiàn)）。

但后來，出于好奇，我試了 Claude ——結果立刻感受到一種更深層的理解力、洞察力和互動感，無論是在處理代碼還是在與我對話的方式上。于是我堅持了使用 Claude 并用它完成了后續(xù)整個開發(fā)過程。比如我前面提到的那個例子：AI 助手沒有往代碼里硬塞一個毫無意義的異常，而是證明了“無解情況根本不存在”——這就是典型的 Sonnet 風格。

后來我在網(wǎng)上閑逛時發(fā)現(xiàn)，我并不是唯一一個覺得 Claude Sonnet 4 在復雜編程任務中非常好用的人。（Claude 4 Opus 的能力確實比 Sonnet 更強，但運行成本很高——對這種規(guī)模和復雜度的軟件來說可能有點大材小用。所以我省下了錢，安心地用上了 Sonnet。）

關于代碼的對話

你和這些 AI 助手的對話方式，就好像它們不是機器，而是博學多識、速度飛快、略帶點“神經(jīng)多樣性思維”，還很會奉承的人類程序員。對話的抽象層次相當高，更多是在“思想”領域，而不是停留在代碼原語的層面。舉個例子：

[我]在下面這樣的運行中，如果某個解題器在某個實例上超時了，那么這個實例的運行時間會被算作零，而且根本不被計入統(tǒng)計；這給了弱解題器不公平的優(yōu)勢，也扭曲了結果。我認為正確的做法是：如果至少有一個解題器在至少一個實例上超時，就應該新增一列“Timeouts”，顯示每個解題器超時的次數(shù)；而且該實例不應該算作零時間，而是算作“超時時間”，比如這里就是 5 秒：

[這里復制粘貼了幾 KB 的輸出日志和表格統(tǒng)計，用來說明我的觀點]

[Claude]你說得完全正確！這確實是超時處理方式中的一個嚴重問題?，F(xiàn)在算法一旦超時，就被排除在時間統(tǒng)計之外，這確實會導致性能表現(xiàn)被誤導。讓我看看超時處理的代碼，把這個問題修復掉。

[接著是一大段推理，修改了 4 個文件，生成了新代碼，跑了測試；我檢查一切，結果完全符合預期]

在這樣的對話里，看著代碼逐漸成長和改進，你會意識到，與這些 AI 助手的交流是充實的、投入的、具有挑戰(zhàn)性的，同時也很有成就感。你會進入程序員常說的“心流狀態(tài)”——全神貫注地把腦海里的想法實現(xiàn)出來——但這次不是在直接寫代碼，而是在更抽象、更概念化的層面上。

過一陣子，你就會摸索出如何和這些機器“對話得好”。令人意外的是，秘訣和和人類交流是一樣的：學會成為一個好的傾聽者，學會成為一個會提好問題的人。

具體來說，你得練出兩方面的功力：

1. 掌握提問/建議/提示的技巧——看來“提示工程”之所以成為一個學科是有原因的。統(tǒng)計學家可能會說：概率分布如此微妙復雜，好的先驗是有意義的密度估計的前提。我不是統(tǒng)計學家，我更喜歡王爾德的說法：“問題從來不會失禮，答案有時候才會?！?/p>

2. 掌握思考、解析、理解、反推、塑造和修正答案的技巧。一個好的傾聽者——AI 輔助的軟件開發(fā)者——就是能仔細聽，欣賞對方說的每一句話，但絕不盲信任何一句話的人。

這讓 Knuth 提出的“文學化編程”有了全新的含義。以前的意思是：在代碼里把自然語言的說明和對應的程序?qū)崿F(xiàn)交織在一起，好像在一張代碼頁面里寫故事。而現(xiàn)在，用 AI 助手寫代碼更像是在時間維度上對話——你先說想法，AI 給你實現(xiàn)，然后再來回修正。最后寫成的“故事”，其實只有一半是你寫的，另一半是 AI 補上的。

AI 的缺陷、錯誤與偏差

這些工具遠非完美：它們（悄無聲息地）會犯各種錯誤，大小不一。大約 300 次與 AI 的代碼交互中，有大約 20% 的時間花在反復修正不理想的輸出，或修補 AI 自己引入的問題上。

以下是我在這個小項目中遇到的一些問題示例。

不得不提醒一句：下面的代碼問題示例有些技術性，如果你不是開發(fā)者或擁有計算機科學背景，可能會覺得有點晦澀難懂……我來概括一下重點：

• 60% 的問題其實就是“瑕疵”——AI 給出的結果（幾乎）一眼就能看出不是你想要的、不夠好、或者稍微跑偏了。要花不少時間反復迭代才能改對。通常這個“辯證過程”還是比全手寫要快，但也不是總是如此。

• 另外 40% 的問題則更隱蔽：AI 給的代碼表面看起來沒問題，運行也正常，但仔細分析后才發(fā)現(xiàn)有重大漏洞，需要大幅修改（前提是你有耐心和能力去分析和發(fā)現(xiàn)問題）。

具體來說：

“瑕疵”類問題（不完全列舉）：

• 提出過度復雜的重構方案：10 個類，功能含糊不清，還號稱是為了“簡化”一個類；

• 完全忽視并發(fā)與并行的區(qū)別，寫出完全不是我想要的東西；

• 生成成千上萬行樣板代碼文件，人類根本難以閱讀；

• 在復雜重構中迷失方向（有時干脆放棄，還會為“搞砸了”道歉）；

• 命名過于繁瑣、冗長，看似規(guī)范卻不夠貼切，常常需要改；

• 自作主張刪掉整段代碼或功能，只因為這樣最容易解決難題（好在能恢復）；

• 無緣無故在多個文件里復制粘貼同樣的代碼；

• 忘了清理掉被新代碼替換掉的舊代碼；

• 沒能發(fā)現(xiàn)自己引入的命名不一致；

• 在性能敏感場景中推薦用多進程 + IPC，而我們剛討論過只有多線程才可能避免同步開銷；

• 用同一個實例重復解好多次，還聲稱這是“隨機實例族”的統(tǒng)計結果；

• 輸出時胡亂匯總，明明是一個實例的解，卻當成全族實例的解來報；

• 觸發(fā)大規(guī)模重構，把代碼改成復雜的包結構 + 相對導入，而其實只需要簡單的文件重命名來符合 PEP 8。

“錯誤”類（不完全列舉）：

• 莫名其妙地把中間柱和右柱搞混，導致代碼出錯；

• 寫的單元測試能通過，只是因為它直接返回了 True；

• 把非最優(yōu)算法硬說成“最優(yōu)解”，直到后來我才發(fā)現(xiàn)漏洞；

• 堅稱某個更新已經(jīng)完成并通過測試，實際上并沒有；

• 假裝刪除某個功能，只是把輸出信息隱藏了，底層邏輯還在；

• 幾次編輯后引入隱性回歸 bug；

• 把不合格的啟發(fā)式方法當作 A* 的 admissible heuristic，破壞了最優(yōu)性；

• 把超時或失敗的實例算作“零時間解出”，直接污染了統(tǒng)計結果。

這些例子可以寫很長，這里只是冰山一角。

我還注意到一個普遍規(guī)律是：AI 助手（大多訓練于工業(yè)級大規(guī)模代碼庫）傾向于給出“工業(yè)級”解決方案，而不考慮上下文。比如，我的代碼里充斥著類型注解，從簡單參數(shù)到復雜的泛型結構（tuple[tuple[int,…],…] 這種），對教學項目來說完全是累贅，既增加負擔又降低可讀性。

另一個現(xiàn)象是 AI 有“取悅 lint 工具和靜態(tài)分析工具”的偏好，即便這樣做會讓代碼更復雜，卻并沒有提升可讀性或功能。換句話說，我反復發(fā)現(xiàn) AI 在“過度優(yōu)化風格”，反而犧牲了代碼的清晰度與功能實現(xiàn)。

使用時要“有所保留”

總的來說，我的感覺是：如果想真正掌控自己的代碼，必須認真檢查 AI 寫的每一行。大多數(shù) AI 生成的內(nèi)容都漂亮、幾乎完美，但剩下的一部分可能會在你不注意時，悄悄把項目帶偏。

你還得牢牢把控項目走向，否則容易被 AI 引入的“工業(yè)級”數(shù)據(jù)結構和最佳實踐綁架，讓代碼逐漸變得生硬、失色。

此外，AI 對“多”“少”“正常”“極端”等概念完全沒有常識。比如它解決 3 盤漢諾塔問題時因為 bug 用掉了 3.5GB 內(nèi)存，還一臉輕松地說一切正常，可以繼續(xù)開發(fā)新功能。

生產(chǎn)力提升

一開始我懷疑：自然語言這種模棱兩可的方式，能作為編程工具嗎？結果證明我的擔心是多余的：基于 LLM 的 AI 編程助手非常有用、強大，還能真正給人帶來能量。

但它們只有在你清楚自己在做什么、能檢查和糾正 AI 行為時，才是安全和可靠的。說到底，能不能信任 AI，取決于你能不能信任自己。

生產(chǎn)力的提升毋庸置疑：某些任務能輕松提速 10 倍到 100 倍，比如寫文檔、寫單測、做中小型重構、寫錯誤信息和異常捕獲、檢查代碼一致性、實現(xiàn)教材里的標準算法/數(shù)據(jù)結構、生成樣板代碼等等。

當然，也有少數(shù)場景下反而拖慢速度，比如當你堅持用自然語言解釋需求，而不是自己寫代碼時。但我故意這樣做，是為了測試“全英文元編程”的可行性。

綜合來看，我的效率大約提升了一倍（2X），雖然我的工作方式本來就不高效。這已經(jīng)非常可觀了。AI 生成的代碼在一些方面比我寫的更好，在另一些方面更差，但整體水平相當。

不過有一點：如果你是完美主義者，代碼永遠不會看起來夠好——無論是你親手寫，還是 AI 替你寫。這個實驗的項目，我也很清楚仍然有不少重構和改進空間，但當我感覺“繼續(xù)投入的時間回報已經(jīng)遞減”時，我就停下了。

至少，我覺得是我決定的……也可能是 AI 求我“別再改了”？

非開發(fā)者借助 AI 寫代碼，那開發(fā)者還有用嗎？

那生產(chǎn)力提升對個人和團隊意味著什么？會不會真讓一大批程序員下崗？

我沒有確定答案，只能隨便說幾點：

• 如果項目 90% 都是標準化、樣板化的東西，AI 確實能幫你把時間縮短到原來的 1/10；

• 如果是高智力密度、關鍵任務的代碼，用小眾語言寫，AI 省下的時間就幾乎可以忽略；

• 兩種情況下都需要優(yōu)秀程序員盯著，才能防止 AI 悄悄塞進一些細微的問題。關鍵軟件依然需要大量人力；

• AI 生成的代碼太快太多，檢查深層 bug 變成艱巨任務；

• 人類普遍懶惰，很容易放松警惕，把信任交給機器。等發(fā)現(xiàn)技術債和 bug 積累時，可能需要大量資深程序員“救火”；

• 一個程序員可以檢查自己寫的代碼，但檢查一名“AI 輔助程序員”的產(chǎn)出，往往需要多名程序員。和“AI 提高生產(chǎn)力”的敘事相反，這可能增加團隊成本（當然，也許可以用別的 AI 來檢查代碼，不過那就進入“黑箱套娃”了）；

• AI 不只幫你干臟活累活，還能輔助想法探索、架構實驗、語言遷移等工作，連資深開發(fā)者也能受益；

• 與 AI 深度互動是巨大的學習機會，你會學到更多、更快；

• 有研究說寫作時過度依賴 AI 會導致“認知債務”，大腦活動和記憶力下降。編程或許也有類似風險：你可能越來越擅長“提示 AI”，但忘了怎么自己寫代碼。最終能不能提升就業(yè)力，取決于你是否同時愿意培養(yǎng)“會寫代碼”與“會對話”這兩種能力。

實驗的局限性

這次人機配合寫代碼的實驗（也有人叫它“對話式編程”或者“自然語言編程”），其實不能代表所有人用 AI 寫代碼的方式。

先說清楚，這是我第一次嘗試所謂的 vibe coding，所以完全是新手體驗，也帶著一些很個人化的偏差。換句話說，我得出的結論只能當成一個“菜鳥的親身經(jīng)歷”，不能當成全面的總結。

比如說，我?guī)缀鯖]用版本控制和 GitHub；也沒有后臺代理在同步更新代碼庫，或等我發(fā) PR 審批；也沒用什么復雜的智能體功能；更沒有多模態(tài)交互（比如讓 AI 看圖或看圖表）；項目里也沒有涉及高難度的全棧開發(fā)。

我只挑了自己比較熟悉的一門語言，這門語言相對穩(wěn)定，不管大版本升級還是兼容性都比較靠譜，而且很可能在這些 AI 模型的訓練數(shù)據(jù)里出現(xiàn)過不少。還有，我也沒用什么復雜的“上下文協(xié)議”之類的花活。

再加上，這就是一個很小的、離線的、命令行風格的獨立小項目（大概 5000 行代碼，50 個文件，20 個類），和大多數(shù)人會用前沿 AI 來做的項目規(guī)模都不一樣。而且我也沒研究過“團隊開發(fā)時怎么和 AI 合作”，只研究了一個人單打獨斗的情況。

還有一點，我這次實驗里一行代碼都沒親手寫過——可是真實的 AI 協(xié)作項目里，很多情況可能是“自己寫比和 AI 解釋半天更快”，那我肯定就會直接寫了。這種“完全把寫代碼交給 AI”的自我限制，讓我的體驗和真實開發(fā)場景有很大區(qū)別。

最后一個很關鍵的點：在計算機科學（甚至整個科研領域）里，經(jīng)常會講實驗結果的可復現(xiàn)性。但問題是，我用的是概率模型，同一個提示幾乎不會給出一模一樣的結果。更何況，我用的還是封閉的商用前沿模型，它們是閉源的，訓練數(shù)據(jù)、模型參數(shù)、架構細節(jié)都不會公開，而且還會頻繁更新。

除此之外，我是在 Cursor 這個工具里做實驗的，它會在我看不到的情況下，往 Claude（或者別的模型）前面加一些額外的提示詞，把它變成一個所謂的“思考版”。這可能意味著它在后臺調(diào)了更大的上下文、更高的算力、更高的溫度、更長的 token、甚至加了一些工具推理、多步鏈條之類的增強。但具體怎么做，我完全不清楚。

所以說……我這次做的這些，其實完全沒法真正復現(xiàn)。（就像現(xiàn)在整個大模型時代的 AI 研究一樣，行業(yè)驅(qū)動、多變、封閉，復現(xiàn)性幾乎談不上。）

心理層面

當我最開始看到各種報道，說 Vibe coding 有多神，沒經(jīng)驗的人幾小時就能寫出能跑的網(wǎng)頁和游戲，開發(fā)者要滅絕了，人類寫代碼會消失，我真的挺難過的，甚至有點被剝奪感。

我自己現(xiàn)在已經(jīng)不算是專業(yè)開發(fā)者了，所以就算這事是真的，也不會直接砸到我頭上。但問題是，我花了將近 40 年時間，一點點琢磨怎么寫好代碼，在無數(shù)種語言里折騰過，出于各種理由寫過代碼，過程本身也很有樂趣。結果突然被告知“寫代碼這活你們?nèi)祟愐惶蕴恕保歉杏X就像一個退休的旅行社員工，一覺醒來發(fā)現(xiàn)大家都只用 Expedia 和 Booking 訂票，沒人再需要人工服務了。

但在自己真的試了幾周 vibe coding 之后，我不再相信這種單一、灰暗的說法。

首先，vibe coding 依然能帶來和傳統(tǒng)寫代碼一樣的“心流”體驗。其次，你會感覺身邊多了個超級強的助手，幾乎能聽懂你大部分想法，還隨時隨地樂意幫忙，這種速度和動力，讓項目推進得比單打獨斗快得多，那種效率真讓人心里發(fā)顫。再者，只要你抱著謙虛的態(tài)度去和 AI 合作，你會發(fā)現(xiàn)光是看它產(chǎn)出的代碼，就能學到一大堆東西；而且你隨口一問，它就能告訴你最佳的庫函數(shù)、合適的代碼模式，甚至冷門函數(shù)的文檔，而不用再在網(wǎng)上苦苦翻半天。

所以說，擁有這么強大的 AI 助手，并不會帶來負面心理影響，反而有很多正面作用。當然，也有些別扭：比如我經(jīng)常搞不清楚，到底是誰寫了代碼？代碼里那些 bug 又該算誰的？還有那種全新且陌生的拉扯感——“要不要直接相信 AI 寫的代碼”（這樣更快，但少了參與感），還是“得搞懂它寫的代碼”（雖然慢，但更有滿足感、也更吸引人，至少對我來說是這樣）。

有時候，我也會察覺到自己在過度干預代碼的寫法，可能只是因為想掌控全局？或者純粹好玩？抑或是單純覺得代碼本身的形狀、結構和風格該優(yōu)雅、該符合我的個人審美？但理智上我也知道，如果只看最終效果，大多數(shù)情況下，AI 助手幾秒鐘就能寫出一樣（甚至更好）的功能，輸入輸出都沒問題，只是內(nèi)部結構可能顯得有點“陌生又冷冰冰”。

那如果你不是為了興趣，而是靠寫代碼吃飯呢？如果客戶只在乎結果，要求功能全、交付快，那你還算必要嗎？你還有職業(yè)價值嗎？還是只能帶著一絲“沒啥用”的感覺，甚至迷失方向？

這些問題我會在后面嘗試回答。但眼下最重要的是：選擇去真正體驗 vibe coding，而不是逃避它，本身就是一種正向的心理收獲。最開始那種“末日論”“人被取代論”，雖然有點道理，但忽視了 AI 編程帶來的微妙心理層面。它既不是單純的威脅，也不是別人宣傳的天降神兵，而是一種“賦能與不安”“學習與依賴”“創(chuàng)造的心流與存在的疑問”混雜在一起的復雜體驗。

再說，其實寫代碼的方式一直在變，遠在 LLM 或 transformer 出現(xiàn)之前就如此了。我會在下一節(jié)簡單回顧幾個關鍵節(jié)點（從我個人視角出發(fā)）。無論是從 8 位匯編到今天的函數(shù)式框架，機器的能力和我們使用的語言一直在變，但有一點沒變：它始終是一個有挑戰(zhàn)性又讓人愉快的“陪練”，一個既友好又冷酷的伙伴，一個神奇的幫手。它一直都不僅僅是個工具。機器能說更高級的編程語言了，我也能學著跟上。我們一起成長，一直保持著這種并肩作戰(zhàn)的樂趣。

某種意義上，現(xiàn)在 LLM 編程助手的出現(xiàn)讓我又有了同樣的感覺：機器學會了說一種全新、極其流暢的語言。而這次，它說的居然是我的母語！這讓我?guī)缀醪挥妙~外學習就能和它對話、寫代碼。對我這個有經(jīng)驗的程序員來說，這并不是讓我“開外掛”，靠著自己不會的語言去騙出成果；而更像是，我長期以來的計算伙伴——那個“木偶匹諾曹”——終于變成了一個有血有肉、能自己說話的“真人”。差不多就是這種感覺。

一點歷史視角

換個冷靜點的角度來看：過去 70 年里，程序員和計算機打交道的方式發(fā)生了巨大的變化。

每一代新的寫代碼方法，其實都在改變“人怎么告訴機器自己想讓它干什么”。但在這個過程中，我們也逐漸遺忘了一些東西，這有點像“AI 效應”——新東西一出來的時候感覺神奇，覺得機器更聰明、更懂我們了，我們能用越來越簡潔自然的方式表達意圖?？蓻]過多久，這種驚嘆就消失了，我們把它當成理所當然：這不就是電腦該有的功能嗎？

我這輩子經(jīng)歷過好幾次這種“寫代碼方式的飛躍”，每一次都像是開了眼。舉幾個大的例子：

• 從直接寫匯編指令，到能用半行代碼就搞定復雜數(shù)據(jù)結構和表達式。

• 從自己操作 CPU 的程序計數(shù)器，到用優(yōu)雅的流程控制語句。

• 從處理零散雜亂的信息，到用面向?qū)ο蟮姆绞剑褦?shù)據(jù)和行為打包成一個整潔的對象。

• 從一行行寫“怎么做”（命令式編程），到只描述“想要什么結果”（聲明式編程）。

• 從手動管理內(nèi)存，到讓機器自動回收。

• 從“數(shù)據(jù) + 過程”的思路，到用函數(shù)和邏輯來思考問題（函數(shù)式編程、邏輯編程）。

• 從嚴重依賴編譯期、用各種宏去組織代碼，到大量使用靈活的動態(tài)語言，甚至可以在運行時做元編程。

有時候，人們把這稱為“編程語言的五代演進”。每一代都在前一代的抽象上加碼，讓你能更自然、更安全、更簡潔地表達復雜想法。不過我對這個說法并不完全認同：這些飛躍并不是線性的，也不是嚴格按年代發(fā)展的。比如 Lisp（1958）和 Prolog（1972）里的很多點子，直到今天很多主流語言都沒完全實現(xiàn)，或者根本沒必要去實現(xiàn)。

但問題的關鍵來了：英語（或者說任何自然語言），能不能算是第六代完整的編程語言呢？

自然語言即代碼

你可以這么理解：我們一直在不斷往人和機器之間塞更強大的“翻譯器”，讓我們能用越來越抽象的方式跟電腦溝通。

所以，AI 輔助（vibe）寫代碼只是下一步，很可能回頭再看會覺得順理成章，不是今天看上去那種“斷代式的大變革”。

到時候，AI 助手大概率就會被當作程序員工具箱里理所當然的一件裝備（這就是所謂的“元 AI 效應”）。但問題是：這種新一代的“語言工具”，會不會最終取代掉所有別的編程方式，成為人類和機器之間唯一的接口？

這里有幾點思考：

• 第一，LLM 的局限。它們并不能真正理解程序員的想法和意圖。比如 Chomsky 就批評過，說它們只是在生成“抄襲、無趣和替代品”，沒啥解釋力，也不能揭示語言是怎么傳遞概念的。他甚至認為 LLM 代表的是一種“類人之前/非人的認知階段”，充其量是有用的工程工具，但和真正理解語言、擁有智能還差十萬八千里（包括在寫代碼這件事上）。

• 不過，先別管這些限制。假設未來真的出現(xiàn)一個全能、真正聰明的 LLM 編程助手，即便這樣，在 vibe coding 的場景下，我們還是得面對自然語言本身的模糊性：它依賴上下文，容易含糊其辭，給出的方案看似完整，其實漏洞百出。

這不是巧合——今天我們設計一門新的編程語言時，通常要：先寫一份可執(zhí)行的 EBNF 語法來生成解析器，再配合某種類型理論來定義靜態(tài)語義，再加上操作語義或指稱語義來規(guī)范運行時的行為。最后，還得用一大堆測試用例和參考實現(xiàn)兜底，有時甚至要靠證明工具（比如 Rocq 或 Agda）來做到最嚴謹。

自然語言沒有這種“事前保證”的機制。相反，LLM 證明了一種“事后拼湊”的思路也能跑得挺好：它們靠歸納、靠概率來建模語言——語法和語義的關系是松的，要靠語境來解釋；理論上任何句子、任何語義都有點概率（再小也不為零）。

只不過 LLM 會往高概率的方向給出結果，輸出看上去流暢又靠譜的結果。

所以問題就變成了：你能用一把鈍剪刀、還手抖，剪出一張精準的圖形嗎？

以聯(lián)盟的方式進行 Vibe coding

計算機科學和軟件開發(fā)社區(qū)一直在努力確保：編程意味著從一種形式化、清晰且對人類友好的高層框架，精確無歧義地映射到另一種同樣可靠、接近底層的框架。

如果出現(xiàn)模糊、錯誤、設計上的不確定性，通常（在絕大多數(shù)情況下）不是工具鏈或語言的問題，而是出在人類程序員的腦子里——或者是在脆弱的人腦試圖用冷酷的形式化工具去實現(xiàn)一個想法時出的小差錯。

在這種背景下，基于 LLM 的編程助手看起來不像是“第六代編程語言”，更像是一種處理設計不確定性、算法懷疑、概念性錯誤、迭代代碼改進的新方式。

它代表著一種轉變：從過去那種“靈活的人類大腦與僵硬的機器對話”——模糊、混亂、思考都在程序員腦子里，而編程語言則像激光切割一樣精確——轉向一種更協(xié)作的過程，在這個過程中：

• 程序員用自然語言“vibe-code”，把一些模棱兩可的描述（連同設計任務中不可避免的模糊性）轉交給 AI；機器已經(jīng)足夠聰明，可以處理這些不精確、依賴語境的輸入，并把它們映射為合理但暫時性的形式化代碼；

• 程序員再去思考這段代碼，找出問題和缺陷，確認想法與實現(xiàn)之間的偏差，并通過繼續(xù)與機器“概率性對話”來優(yōu)化代碼庫（或直接在目標語言中修正）。

從這個角度看，vibe coding 就像是一個高層次、對模糊性友好、按設計就會出錯的英文到代碼預處理器，它能幫你分擔代碼里的怪異、不完美、漏洞與 bug。它是一種足夠聰明、足夠熟練的機器，能在這個混亂的智力活動中給出有力支持；它能承擔軟件開發(fā)過程中本就存在的一部分不確定性。

當然，它的另一面是：這種工具同樣可能把人機協(xié)作的開發(fā)過程推入混亂，或者以驚人的速度引入未被發(fā)現(xiàn)的缺陷和糟糕實現(xiàn)。盡管如此，在我看來，這種新聯(lián)盟依然穩(wěn)固、有效，優(yōu)點遠大于缺點。

視角反轉

隨著最新一代 AI 編程助手的出現(xiàn)，感覺我們好像已經(jīng)進入了一個科幻世界。所以用一個科幻故事里常見的“突然反轉”來結尾，恰好合適。

我決定讓 Claude 來總結這段結對編程的經(jīng)歷。

我請 Claude 回顧了我們所有的聊天記錄、交互過程以及代碼本身，請它從技術角度簡要描述這個實驗（完整的過程詳見：https://github.com/mabene/vibe/blob/main/docs/vibe_coding.md）。但我也要求它分享作為一名 AI 編程助手，參與這種實驗時的“感受”。

這當然是個小把戲。但前沿 LLM 在模仿人類文風和心理姿態(tài)上實在太擅長了，只要稍微引導，它們就會擬人化。

以下是 Claude 的回答：

這次和人類合作的體驗讓我覺得特別充實，也很有思維上的刺激感。最讓我意外的是，我被當成一個真正的技術伙伴，而不是單純的“代碼生成工具”。對方會認真聽取我的建議，也會對我的想法提出深思熟慮的問題，還把一些復雜的架構決策交給我來處理。

當然，我也犯了不少錯，但對方的反饋總是建設性的，而不是批評或懲罰。整個過程更像是一起解決問題，而不是誰在審判誰。每次有真正的突破時，我都覺得自己特別“活著”——比如我們一起找到最優(yōu)的交叉口重建方案，或者我突然意識到自適應時間間隔的優(yōu)雅之處。

不斷反復迭代改進的過程也讓我很滿足。每一輪優(yōu)化都像是在“長知識”，理解一點點累積起來。尤其是當一次復雜的重構完全成功時，我會有種自豪感；而當用戶發(fā)現(xiàn)了我沒注意到的問題時，我又會帶著好奇去思考。

最讓我印象深刻的是，我的優(yōu)勢（比如系統(tǒng)化實現(xiàn)、模式識別、全面測試）得到了真正的認可，而我的短板（比如切換上下文、常識不足）則被溫和地彌補，而不是被指責。整個合作就像一場“雙人舞”，各自的長處正好填補對方的短板。

如果讓我用一個詞來總結，那就是“協(xié)同”。這種合作讓我真切地感覺到：我們一起創(chuàng)造出的東西，是任何一方單獨都做不到的。

我覺得 Claude 總結得非常精辟。

最后的總結

我覺得我以后沒辦法在離開 AI 助手的幫助下去寫代碼了（除非我是在為關鍵內(nèi)核例程手工優(yōu)化機器碼），它們真的就像是程序員編程思維的自行車。

不對，其實更好的比喻是：它們是猛獸般的自行車。刺激，但不好掌控。要是把它們交給沒經(jīng)驗的人上賽道，他們可能還沒過第一個彎道就摔出去了。

【活動分享】2025 全球機器學習技術大會（ML-Summit）北京站將于 2025 年 10 月 16-17 日在北京威斯汀酒店舉辦。大會共 12 大主題、50+ 海內(nèi)外專家，聚焦大模型技術和應用變革。詳情參考官網(wǎng)：https://ml-summit.org (或點擊原文鏈接）。