Video thumbnail for AI编程 VibeCoding的原理是什么?

AI程式設計「體感編碼」原理揭秘:程式設計師會被取代嗎?

Summary

Language:

Quick Abstract

程式設計師將被AI取代?深入解析「Vibe-Coding」的真相!這段影片探討了AI如何撰寫程式、何謂「Vibe-Coding」,以及程式設計師是否真的會被取代。我們將揭露AI背後的運作機制,以及它與人類程式設計師之間的關係。

Quick Takeaways:

  • AI藉由AI Agent作為中介層,透過預定義的檔案I/O操作函數(如read_file、write_file)來修改程式碼。

  • AI大多以diff格式提供修改建議,確保變更的準確性,並利用IDE收集的資訊(例如專案結構、錯誤訊息)來理解情境。

  • MCP(外掛系統)讓AI能操作雲端伺服器和資料庫,實現程式部署。

  • 雲端平台提供專案範本和提示,讓AI能產生與雲端服務相容的程式碼。

  • 「Vibe-Coding」是指AI能理解需求並一次性完成任務的體驗,簡化了從編碼到部署的流程。

雖然AI能協助完成程式撰寫和部署,但它仍然需要人類提供明確的指示和平台資訊。AI取代的或許是鍵盤上的雙手,而非程式設計師最初的創意與構想。程式設計師的角色將轉變為指導AI,將重心放回創意發想上。

引言

身為一名程式員,今天又看到聲稱程式員即將被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自行寫程式的程式員一樣。

被取代的只是形式

程式員真的被取代了嗎?也許吧。但它取代的是在鍵盤上打字的手,而不是寫下第一個想法的心。這是程式員王,下次見。

Was this summary helpful?