引言
身為一名程式員,今天又看到聲稱程式員即將被AI取代的影片,這次的理由是「Vibe-Coding」的出現,實在令人氣憤。筆者是有8年經驗的資深程式員,曾幫三位老闆實現財務自由,現在有人以為創造一個新名詞就能超越我,不,是比我更會寫程式?今天就來看看AI到底如何寫程式,以及「Vibe-Coding」究竟是什麼。
AI寫程式的原理
大型語言模型的限制
無論大型語言模型多強大,本質上它只是個聊天機器人,除了回應我們發送的訊息,別無他能。最初,程式員為了讓AI協助編程,會將程式碼複製貼到聊天框,等待AI回應,再把回覆貼回去調試,這種反覆複製貼上的方式顯然很麻煩。根本原因在於大型語言模型只能回應訊息,無法直接讀取本地文件。
AI Agent的出現
於是,程式員在AI模型和程式碼之間添加了一個中介層:AI Agent。AI Agent是在本地運行的小程序。為了讓Agent能寫程式,程式員會預先定義一些函數,如read_file、write_file、list_file等文件I/O操作函數。然後,AI Agent將這些函數的名稱和用法與用戶的提示捆綁在一起,發送給大型語言模型。模型審核後,會回覆訊息告訴Agent「你,用這些參數調用這個函數」,從而間接執行修改文件的操作。
在VSCode中,AI編程插件就扮演著AI Agent的角色。它們利用VSCode提供的API獲得讀寫程式碼的能力。有些AI編程插件默認不僅能讀寫本地文件,還能瀏覽網頁、執行終端命令等。有了這些文件操作能力,AI終於能實際修改程式碼。
AI修改程式碼的方式
最直接的方法是讓AI生成完整的修改後程式碼,但問題很明顯。即使只改一個字,AI也得從頭到尾重新生成整個文件,這不僅效率低、浪費令牌,更關鍵的是,一旦文件太長,就很難100%準確地重現,尤其是未被修改的部分,一個小錯誤就可能引入bug。
因此,絕大多數AI編程工具讓大型模型以diff格式回覆修改內容。簡單來說,diff格式描述了哪個文件的哪一行需要用什麼新內容替換。這種格式其實很古老,像Git和SVN這樣的版本控制工具已經使用了很長時間,相應的算法也非常成熟。而且在大型語言模型的訓練過程中,它被輸入了整個網際網路的文本,其中包括大量diff格式的內容,這使得生成的回覆更加可靠。
提高AI回覆的準確性
當然,大型語言模型再聰明,回覆也不可能總是100%準確。所以,AI Agent收到diff後,會先檢查diff中引用的原始程式碼是否與當前文件匹配。如果不匹配,說明模型誤解了上下文,就會再試一次。這樣就能盡可能確保模型修改的對象確實是我們正在編輯的文件,從而得到一個相對穩定可靠的AI編程工具。
AI的不足與改進
AI的「笨拙」之處
然而,人們很快發現AI其實挺笨的,經常犯很明顯的錯誤。比如,即使VSCode已經標出語法錯誤,AI仍需要嘗試幾次才能修正。或者,它想修改的文件根本不存在。
提供更多上下文信息
聰明的程式員再次意識到,為何不把IDE的信息也發送給大型模型呢?所以現在,大多數AI編程工具除了能讀寫文件,還會主動收集大量上下文信息。例如,當前項目的文件結構、用戶正在查看的文件名、哪些文件是打開的、命令行的輸出,甚至當前時間。總之,只要信息不太長或不太敏感,它們就會盡可能多地塞進大型語言模型,讓AI模型更好地了解情況,使其所見與用戶所見幾乎相同,整個編程過程自然就順暢多了。
從編程到部署
AI編程的局限性
此時,程式員終於成功創造出能自行寫程式的AI工具,即使是不會編程的普通人,只要輸入提示,AI就會勤奮地構建程式。但事情並沒那麼簡單。程式寫好了,在本地運行正常,但如何部署呢?部署前端、配置後端服務、設置資料庫等等,這些都是麻煩事,而且是AI編程機器人實際上做不到的。
MCP的引入
為了實現被完全取代的夢想,聰明的程式員又開始思考解決方案。讓AI編程機器人支持MCP吧。可以把MCP看作是編程機器人的插件系統,就像瀏覽器擴展一樣,MCP允許AI編程機器人安裝新的技能包,操作它原本不懂的事情。例如,操作雲端伺服器、部署網站、配置資料庫等。
越來越多的雲端平台現在都推出了自己的MCP伺服器,與編程機器人連接,幫助它們完成最後的部署步驟。比如,管理資料庫、上傳靜態網頁、創建雲端函數、配置域名等,這一切都可以通過MCP完成。我們只需要像寫程式一樣,用提示告訴編程機器人「幫我部署這個網站」,它就能自動使用MCP中提供的功能完成部署。
雲端平台API的問題
但有一個關鍵點很多人忽略了。我們剛讓AI幫助部署了一個網站,比如創建了一個資料庫,這相當於以管理員權限執行的操作。但網站上線後呢?網站本身也需要訪問這些資源,比如讀寫自己的資料庫,而此時AI助手已經不在了,所有操作都必須由網站自己的程式碼實現。問題來了,每個雲端平台的API都不同,AI不可能寫出與所有雲端平台都兼容的程式碼。所以,當我們第一次提示AI寫程式時,必須明確告訴它程式將部署在哪個平台,並使用相應的API。
更麻煩的是,有些雲端服務是在AI模型訓練後才發布的,AI實際上對這些服務的存在一無所知。在這種情況下,我們必須手動告訴它這個平台有哪些服務、如何調用、使用什麼庫以及依賴關係是什麼,非常麻煩。
雲端平台的解決方案
為了省事,除了MCP伺服器,雲端平台通常還提供一整套項目模板。這個模板通常會導入訪問雲端服務所需的所有庫,並配置必要的配置文件。最重要的是,它為AI編程機器人提供了預先寫好的提示。這些提示會清楚地說明程式碼應該是什麼樣子、如何訪問數據、如何部署,甚至如何閱讀在線文檔。這些提示在你寫程式的過程中,會自動與用戶的提示一起發送給AI模型,這樣AI就自動知道如何生成與雲端服務兼容的程式碼。
完整的服務鏈
整個流程
最後,來看看這個連接在一起的完整服務鏈。你打開一個雲端服務的項目模板,對編程機器人說「幫我寫一個個人網站」。於是,編程機器人開始工作。它自動從IDE收集各種信息,如文件I/O接口、當前錯誤、已打開的文件、命令行的內容等。同時,它也讀取項目模板帶來的提示。用戶需求、模板提示和環境信息都被打包在一起,發送給AI模型。
基於這些提示,模型知道這個程式最終將部署在某個雲端服務上,所以它選擇相應的API來寫程式碼。寫好的程式碼以diff格式返回給編程機器人。編程機器人會先驗證這些diff修改是否與本地文件匹配。如果不匹配,就重試;如果匹配,就通過內置的文件I/O函數應用這些修改。這個過程可能會來回幾輪,直到整個網站能在本地運行。
接下來,用戶告訴編程機器人讓這個已經寫好的網站上線。因為我們一開始就配置了雲端服務的MCP,此時,編程機器人會將MCP提供的功能也發送給AI模型。AI模型通過以特定格式返回訊息,引導編程機器人調用MCP服務。MCP服務然後操作雲端服務,完成最後的部署任務,如部署、設置資料庫和配置域名。這樣,一個從編程到部署的完整開發過程就自動完成了。至少對於一些簡單的項目,它真正實現了零基礎編程、零基礎部署和維護。
Vibe-Coding的由來
這種讓AI隱性地理解你並一氣呵成完成事情的體驗,也許就是大家所說的「Vibe-Coding」。所以,程式員不僅成功地取代了自己,還學會了一個新名詞「Vibe-Coding」,真是令人愉快。
程式員真的被取代了嗎?
程式員的角色
程式員真的被取代了嗎?我不這麼認為。我們花了這麼多時間終於打造出一個足夠聰明的工具。我們解構了自己的技能,將其打包成提示,甚至教會了AI部署過程,這樣我們就不必糾結於每一個if-else語句。如果程式是人意願的延伸,那麼今天的AI編程並沒有將人從過程中移除,而是將他們帶回到真正的起點,回到有想法、願意創造的自我。就像那一天,靈光一閃,第一個想到讓AI通過Agent自行寫程式的程式員一樣。
被取代的只是形式
程式員真的被取代了嗎?也許吧。但它取代的是在鍵盤上打字的手,而不是寫下第一個想法的心。這是程式員王,下次見。