引言
身為一名程式員，今天又看到聲稱程式員即將被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自行寫程式的程式員一樣。
被取代的只是形式
程式員真的被取代了嗎？也許吧。但它取代的是在鍵盤上打字的手，而不是寫下第一個想法的心。這是程式員王，下次見。
{# 
{#