“AI，給我整點x86匯編！”從業25年，一名編程教師頓悟：既然都在Vibe Coding了，不如直接“開擺”

【CSDN 編者按】當 Vibe Coding 成為越來越多開發者的日常，我們或許都隱約感到：軟件開發正在進入一個全新范式。在此背景下，本文作者提出了一個更尖銳、幾乎有點“逆向思維”的問題——既然你已經在靠AI寫代碼了，為什么不用 C？甚至為什么不用 x86 匯編？如果未來的代碼是寫給機器看的，那我們今天習以為常的編程語言、可讀性、語法糖，還有意義嗎？是否需要一種專為 AI 生成而生的“面向 Vibe 的編程語言”？

原文鏈接：https://stephenramsay.net/posts/vibe-coding.html

作者 | Stephen Ramsay 翻譯 | 鄭麗媛

出品 | CSDN（ID：CSDNnews）

我有個想法：如果你都開始 Vibe Coding 了，那為啥不直接用 C？或者，更狠一點，干脆上 x86 匯編？

在展開這個看似無厘頭的想法之前，我先澄清幾個關鍵點——因為我是說真的，并不是在嘲諷或挖苦。

首先，我本人其實并不喜歡所謂的 Vibe Coding（靠感覺寫代碼/完全由 AI 生成代碼）。我很喜歡編程，從 90 年代中后期第一次接觸到它時就很喜歡。對我來說，寫代碼一直是“不太像工作”的工作——實在是太好玩了。它是我的職業，也是我的業余愛好。

有句話怎么說來著？“做你熱愛的事，你將一生無需工作”——這大概就是我寫代碼時的感受。

我教編程 25 年了，從來沒膩過，每學期的第一節課我還是興奮得不行。說句聽起來可能有點矯情的實話：把不會編程的人教成會編程的人，就是我的事業，也是我作為大學教授最值得驕傲的事情。

但 Vibe Coding 給我的感覺……很怪，甚至有點“臟”。我不是說它像作弊（雖然確實有那味兒），而是它剝奪了編程的樂趣。我經常跟學生說，編程就像世界上最棒的填字游戲，當你填對了，它真的會“跳起來唱歌”。可 Vibe Coding 搶走了這種成就感——因為程序不是我親手寫出來的，我并沒有“破解”那個謎題。

更可怕的是，身為一名程序員，你本該與各種“不確定性”長期共處：你以為你懂了編譯器的內部邏輯？也許吧；你以為你真正搞懂了虛擬內存系統？可能吧。雖然沒法給出肯定答案，但我還是想努力理解我寫下的每一行代碼，而不是被 Claude 生成的一段讀不明白的代碼折磨得痛不欲生。

但這就引出了第二個關鍵點：Vibe Coding 實際上是可行的，它真的能產出健壯、復雜、可運行的系統。你可能像我一樣，一開始堅信“AI 不可能做到這一點”——但這是錯的；你可能以為它頂多算個編程問題的“平替搜索引擎”——這也是錯的。

當你開始把那些你懶得自己寫的小程序交給它時，你會發現：這玩意兒太能干了。直到某天，你隨口對著 AI 模型念叨一句 “我有個程序構想……”，你會被它的輸出徹底驚艷。要是沒被驚艷到，要么是你壓根沒認真試過，要么就是還沒接受現實。

你說AI生成的代碼完美嗎？遠遠談不上。但話說回來，人類程序員寫的代碼也未必完美。而這會是未來嗎？我想答案不言而喻。

每一種編程語言，都是為“人類”準備的

言歸正傳，回到文章標題這個看似無厘頭的想法上。

我當年剛入坑編程時看過《計算機程序的構造和解釋》（SICP），并認為它是 20 世紀最偉大的編程教材之一。書里有段話我一直記得——書的序言第二段：

“我們希望建立這樣一個理念：編程語言不僅僅是讓計算機執行操作的工具，它更是一種表達方法學思想的形式化媒介。因此，程序首先是寫給人看的，只是順帶讓機器執行而已。”

從那以后，我就一直把這個理念的各種版本灌輸給學生。我會提醒他們，計算機根本不在乎代碼對人類是否“可讀”、“易用”，它只需要代碼能被自己解析和執行就行 —— 這個門檻比“可被人類理解”要低多了。

而每一種編程語言，哪怕是匯編語言，都是為“人類”準備的。所謂語言的創新，不是因為它擁有自動內存管理、并發、安全、錯誤檢查，而是它讓“人類”能更輕松表達和梳理這些技術邏輯。

像我們夸 Rust 的安全、夸 C++ 的零開銷抽象、夸 Go 的并發模型……說到底，這些能力都是“人類程序員”獲得的便利，而不是計算機獲得的。對計算機來說，我們這種“面向對象情結”，無非是對堆內存有著莫名的執念罷了：“你們愛咋折騰咋折騰吧。”（計算機大概會這么想）

其實不管是函數式編程、代數數據類型、依賴類型、不可變數據結構，還是代碼大括號風格……這些都是“人類工程學問題”。與“機器工程問題”相比，人類的問題要復雜得多。

為什么讓AI輸出為“人類”設計的語言？

所以，我的問題來了：

既然你都已經 Vibe Coding 了，為啥還要用那些為人類便利而設計的語言？

換句話說：用 AI 生成出來的，難道不應該是對機器最友好的語言嗎？為什么不讓它直接寫 C？或者，直接生成 x86 匯編代碼不是更直接嗎？

你可能會反駁說：“但我們還需要理解代碼啊。”——好的，但請注意：如果你真的在搞 Vibe Coding，那你本來就搞不懂AI生成的大部分代碼了。而且，你要是仔細觀察會發現，AI 其實并不怕 C 語言里的未定義行為，也能妥善處理內存釋放，更不容易犯“錯誤”。它比你更能正確執行邏輯，就像編譯器比你更會優化一樣。完美嗎？當然不。但正如我之前所說，誰都做不到完美。

那么 C 語言是 Vibe Coding 的最佳語言嗎？也許不是。但我知道 Rust 肯定更不適合，Haskell、OCaml 就更別提了，畢竟這些語言都是寫給“人類”看的，而不是給“AI”看的。甚至，它們在 AI 模型面前都會顯得有些“可愛”——考慮了太多 AI 壓根不存在的問題。

也許，我們應該發明一種面向Vibe的新語言

我想表達的核心是：如果 Vibe Coding 真是軟件開發的未來，那我們何苦還要死守那些為“人類”設計的語言？難道不該誕生一種“面向Vibe 的編程語言”（Vibe-Oriented Programming Language，簡稱 VOPL）嗎？

我猜，你可能是第一次聽到這個概念。

這個 VOPL 可能是什么樣的呢？

可能一：超強“偽代碼”語言，即表面上給你展示通俗易懂的偽代碼，背地里卻在默默生成匯編指令。

可能二：真正實現“文學編程”，即你寫一份闡述“方法論思想”的文字文檔，AI 就能直接產出機器碼，程序員的核心工作也變成了驗證 AI 生成的機器碼（連測試用例也是 AI 寫的）。

可能三：接近自然語言，但帶有特定的編程行話，即比現有的任何語言都更貼近自然語言，同時又自帶一套易于掌握的慣用表達，能引導 AI 更精準、更高效地給出解決方案

不過現實是：AI 代碼大模型之所以擅長 JavaScript 和 C++，核心原因是它已經學習了這兩種語言的數十億行代碼，以及無數論壇帖子、StackOverflow 上的爭論等相關數據。因此，想要搭建并推廣一個 VOPL 很難。

但也有人猜測，LLM 其實已經在學習某種未來版本的 VOPL 了——畢竟現在太多程序員都在用 Vibe Coding 來構建生產級系統，相當于在摸著石頭過河。

我對這種未來的感受？

用一個詞來形容的話，就是：復雜。

一想到“手寫代碼”會變成未來 Vibe Coder 的啟蒙課程、一種類似于幼兒園里的趣味啟蒙，我確實有點悲傷；但另一方面，一個新的計算范式正在誕生，又令我感到興奮。

從宏觀時間來看，不久前（1945 年左右的 ENIAC 時期），人們才意識到每次計算都要重新布線有多低效；而當存儲程序計算機（1951 年左右的 EDVAC）出現時，同樣有人怨聲載道，說它“不可靠、慢、剝奪操作者參與、威脅專業性、不夠純粹”。

如今，我們的激烈爭論與當年相比，看起來真是“如出一轍”啊。

【報名倒計時，限免】C++之父中國行 · 40周年慶典｜北京·上海開發者見面會正式開啟！

• 北京站：12月12日 · 北京金隅喜來登酒店

• 上海站：12月14日 · 上海淳大萬麗酒店