剛剛看到一篇《A Year Of Vibes》，算是一篇很有代表性的過去一年對Vibe Coding 的總結了。 作者Armin Ronacher 很多人可能不熟悉，但如果你接觸過Python，大機率用過他寫的東西－Flask 框架，就是他十幾年前的作品。 文件開頭第一句就讓我很有共鳴：2025 年，我不再像以前那樣寫程式碼了。 跟他的經歷很類似，一個寫了快二十年代碼的人，現在打開電腦，主要的工作變成了──指揮AI 寫程式碼。他把這比喻為從「親自敲鍵盤的程式設計師」變成了「虛擬實習生的技術領導」。 我自己對Vibe Coding 的轉變來自於Claude Code，他也一樣，今年四五月份，開始沉迷使用Claude Code。幾個月下來，他在自己部落格上發了36 篇文章，佔了這個部落格2007 年至今全部文章的18%。不是因為他閒了，而是因為AI 把他從繁瑣的實現工作中解放了出來。 他現在同時用三個AI 程式工具：Amp、Claude Code 和Pi。他為這三個工具打了個比方——Amp 是保時捷，精緻講究；Claude Code 是大眾汽車，實惠能打；Pi 是駭客們的開源玩具。三個工具，三種調性，但他沒辦法告訴你哪個比較好。我自己倒是以Codex 為主，輔助GitHub Copilot 和Claude Code。 我估計如果做個調查，每個人使用AI 程式設計工具的選擇都不一樣，因為大家都在「vibes」。 Vibes 這個字貫穿了整篇文章，也是標題的由來。直譯是“氛圍”或“感覺”，但在這裡它指的是一種無法量化、只能憑直覺感受的評判標準。 這可能是2025 年AI 程式設計最詭異的地方：一個產業做了五十年累積下來的工程經驗，突然有點不太管用了。什麼程式碼規格、什麼最佳實踐，在面對AI 產生的程式碼時，你最後靠的居然是一種玄學——這個模型「感覺」更順手，那個工具「用起來」更舒服。 最理性的程式設計師群體，現在正在用最感性的方式選擇技術棧。 Armin 自己一整年都在跟MCP（模型上下文協定）較勁，覺得它不好使。但他拿不出數據，只能說「反正對我沒用」。而另一邊，有人用得熱火朝天。他的朋友Peter 年初拉他入坑Claude，現在Peter 自己跑去用Codex 了，覺得很香。 Armin 試了試，覺得沒那麼香。 誰對誰錯？沒有答案。大家都在摸黑走路。 更深層的不適感，來自人與機器的關係。 他開始對這些工具產生了一種「parasocial bond」——中文可以理解為單向的親密感。就是那種你對某個主播、某個偶像產生的情感投射，對方其實不認識你，但你總覺得跟對方很熟。 一個AI 工具，憑什麼讓人產生這種感覺？ 因為現在的AI 可以有記憶了。你跟它聊過的東西，下次它還記得。它開始有了「人格」的影子。 Armin 說他過去兩年一直訓練自己，把這些模型當成「token 攪拌機」——一個純粹的機率機器。但這種簡化論的視角已經對他失效了。 這些系統表現出人類的傾向，但把它們抬到人的高度又是錯的。它們到底是什麼？沒人能給一個好的定義。 Armin 甚至開始糾結「agent」（智能體/代理）這個詞——因為agency 意味著自主性和責任，而這兩樣東西應該留在人類手中。 這種「不知道該怎麼稱呼它」的困惑，本身就說明了問題。 文章最後，他列了幾個希望業界能去解決的痛點。 第一個是版本控制。 Git 和GitHub 是程式設計師吃飯的傢伙，但現在它們缺了一塊關鍵訊息：prompt。當程式碼是AI 生成的，你光看最終的改動，沒辦法判斷這個改動好不好。你需要看到是什麼指令催生了這段程式碼，中間走過哪些彎路。 更有趣的是他的一個發現：失敗的嘗試對AI 來說是寶貴的。如果你把AI 引回一個早期狀態，你會希望它記得之前哪條路走不通。但我們現有的工具壓根沒設計這個功能。你刪掉一段對話歷史，AI 就會重蹈覆轍。 第二個是程式碼審查。現在的GitHub 審查介面有個滑稽的設計：你沒辦法正式地review 自己的程式碼，只能留評論。但在AI 程式設計的場景下，程式設計師經常需要在自己的PR 裡給AI 留指示。現有的流程根本沒考慮這種人機協作。 第三個是可觀測性。這是個稍微技術一點的話題，但核心意思是：過去很多監控、調試工具因為太複雜而沒人用，但AI 剛好擅長處理複雜的東西。那些被束之高閣的方案可能要重新翻出來了。 最後他聊了一個稍微敏感的話題：有些人已經完全「放手」了，不再審查AI 產生的程式碼，直接讓它上。這種做法瘋狂嗎？瘋狂。但Armin 看過有人這麼幹還挺成功的。他自己還做不到，他還是會仔細檢查每一行。 存在的即是合理的，這種「放手派」的存在，說明一種全新的工作方式正在成型。這種方式和他熟悉的那套軟體工程完全是兩碼事。 這讓開源社群頭痛。越來越多的PR 是AI 一把梭生成的，沒經過人腦過濾就丟了上來。對於還在堅守傳統流程的維護者來說，這種PR 簡直是一種冒犯。 Armin 自己的辦法是寫詳細的貢獻指南和PR 模板，但他也知道這有點像唐吉訶德戰風車。 也許問題的解法不是讓別人改，而是讓那些認可AI 編程的大聲量玩家站出來，示範什麼叫「負責任地用AI 寫代碼」。 這篇文章對我來說是有共鳴的，你能感受到一個資深工程師的真誠困惑。他不是那種對AI 大唱讚歌的佈道者，也不是摀著耳朵拒絕變化的遺老。他夾在中間，一邊深度使用，一邊深度懷疑。 2025 年已經接近尾聲，但他提出的問題一個都沒解決：怎麼審查AI 的程式碼？怎麼保存AI 的失敗記憶？怎麼跟一個讓你產生情感的工具保持健康距離？ 這些問題的答案，可能就是下一批成功產品的方向。
