AtCoder World Tour Finals 是 AtCoder 主辦的一年一度的賽事，旨在決出競技程式設計的世界冠軍。第一是來自波蘭的 Psyho，OpenAIAHC 排在第二。訊息一齣，連 OpenAI CEO 奧特曼都親自轉發了，配文「幹得好，Psyho！」這場勝利確實值得歡呼，但它始終是暫時的。OpenAIAHC 排在第二名緊追不捨，AI 參與程式設計競賽的實力越來越強，從零除錯的程式已經逼近人類頂尖選手。正如當年 AlphaGo 「大戰」李世石那樣，AI 程式設計的優勢也正在一點點顯現，逐步佔據主導地位。今天的開發者，正在被 Claude Code、Gemini CLI、Cursor 等工具團團圍住，不再是「用不用」的問題，而是「怎麼用」。最近 Kimi K2 釋出，讓 Claude Code 又火了一把。很多人第一時間注意到的，除了 K2 跑得多快、模型多大，還有它的 API 接入了 Claude Code。啟動 Claude Code，寫上一段 prompt，回車，一大段結構清晰的函式就寫好了。Gemini CLI，Cursor，同樣如此。程式設計從一個人對抗 bug 的痛苦過程，變成了一個跟 AI 一起搭積木的創意遊戲。甚至有個很好聽的名字叫 Vibe Coding（氛圍程式設計，透過提示詞與 AI 協作程式設計）。非常多的人在社交媒體上分享自己 Vibe Coding 的經歷，有人表示 Claude 是「目前用過最強的程式碼助手」，不過也有經驗豐富的開發者分享使用 Claude 的痛苦經歷。
AI 寫的程式碼也被一些經驗豐富的開發者感覺到「噁心」Vibe Coding 到底行不行？是程式設計大賽勇奪第二的智慧，還是在日常程式設計裡一次次的「被噁心」。就在不久前，一項新的研究給 AI 程式設計潑了一盆冷水。一項反直覺的研究：AI 程式設計，可能更低效最近，美國 AI 安全機構 METR 公佈了一項針對 Claude 3.5/3.7 的實測研究。他們找來了 16 名經驗豐富的開源開發者，讓他們在熟悉的專案中使用 Claude Code 輔助程式設計。
16 名經驗豐富的開發者參與實驗的結果（紅色），以及從左到右經濟學家、機器學習專家、和開發者在參與研究過程中和之後的預測結果（綠色）。結果讓很多人驚訝：開發者使用 AI 後，完成任務的時間平均增加了 19%。更有趣的是，雖然結果是變慢了，但參與者自我報告的感覺是變快了！他們覺得 AI 幫了很大的忙，寫得更順了，效率提升了 20%。「AI 幻覺」好像轉移到了人類身上，變成一種「效率幻覺」，你以為你變快了，但其實你只是感覺變快了。為什麼會這樣？研究總結了下面幾個原因，寫 prompt 很花時間，而且經常要改來改去；Claude 給出的程式碼大多不能直接用，需要手動改邏輯、查 bug；你在「提示 – 等待 – 修改」的迴圈中，陷入了一種「被打斷的狀態」。看到這兒，我們也開始好奇，那我們自己用這些工具寫點東西，會不會也遇到同樣的問題？於是我們做了一個小實驗。Vibe Coding 真的能讓你飛起來嗎？我們設計了一個看起來不難、但邏輯不算太簡單的小任務：寫一個命令列工具，輸入關鍵詞，返回知乎熱榜中含該關鍵詞的帖子標題，限制輸出條數。這個任務包含了網路請求、HTML 解析、字串匹配、命令列引數解析，剛好可以試試 Claude Code 和 Gemini CLI 的能力。這裡我們使用 Gemini CLI 來完成這個任務，雖然在命令列裡面使用中文真的很違和，但是 Gemini CLI 和 Claude Code 都能支援中文的輸入。
中間遇到的問題是知乎需要登入，它還自動使用 Google 幫我搜索了一個公開的 API，以及嘗試使用其他的工具，但是仍然沒有用。最後它告訴我需要我自己輸入 Cookie。
雖然短時間內它沒有幫我完成這個任務，但整個體驗的過程確實很舒適。像是指揮實習生去完成工作，實習生做得不好不可以罵，但是 Vibe Coding 裡面能直接罵 Gemini CLI。在使用 Kimi K2 的 Claude Code 時，同樣的，我們嘗試讓他從零開始完成一個科研任務。在一個空資料夾中，我告訴 Claude Code 說，我要發一篇 CVPR（計算機視覺頂級會議） 的文章，我有一個具體的方向，你需要幫我寫程式碼完成這個實驗。
結果是，等到我把 Kimi K2 的免費 API Token 都用完了，整個專案還是約等於一個零。他先是自信的給我生成了全部的訓練程式碼、網路結構程式碼、資料集程式碼、測試程式碼等等，然後告訴我說可以運行了。我說你這個方法根本不 Novelty（創新），他說確實是。然後我要他去找最近兩年的論文，接下來他就把我的 Token 全部消耗完了。由於整個過程還是比較短的時間，我沒有做太多的人為干預，完全交給 AI 去處理。即便是中間遇到了問題，我也是讓 AI 自己去解決。我覺得，他有一個最大的好處，它幾乎可以完全控制這臺電腦，不需要我去給他提供額外的上下文資訊。爽感 vs 效率，AI 程式設計可以魚熊掌兼得嗎？這次小測試，讓我印象最深的是，AI 給我的更多是「爽感」，而不是「效率」。你會感到自己像個程式設計高手，程式碼像魔法一樣自動冒出來，但一旦報錯或邏輯不通，會發現你其實沒有真正理解這段程式碼，也不太知道怎麼改。但我仍然覺得工具本身沒有問題，如何使用工具才是決定能否發揮它潛力的重要因素。
來自 OpenAI 的 Sean Grove 在 AIEWF2025 上發表「新的程式碼」演講在 OpenAI 從事對齊推理工作的 Sean Grove 在最近的一個演講裡面則提到，在使用 AI 程式設計工具時重要的不是提示工程，而是「規範」。當前的「Vibe Coding」存在一個問題，我們保留了 AI 生成的程式碼，卻丟棄了包含我們原始意圖的提示詞。這就像「把原始碼撕掉，只對編譯後的二進位制檔案進行版本控制」一樣，是不可持續的。程式設計的未來不再僅僅是編寫程式碼，而是透過規範（Specification）來定義和傳達意圖。真正的瓶頸和價值在於結構化的溝通，而「規範」正是這種溝通的最終體現。有一位參與了文章開頭提到的那項研究的開發者，在 X 上分享了自己參與的經歷，他說自己就是那個用了 Vibe Coding，效率降低了 38% 的人。
他認為 LLM 只是工具，不要期待它是一顆「萬能靈丹」。除了只有特定型別的程式設計任務，才擁有大量乾淨的訓練資料這一缺點之外，還有像是上下文退化、在等待生成的過程中分心、以及 LLM 程式碼工具沒有準確的成功衡量標準等「長尾問題」。不過最後他也提到「如果我們想用好這個新工具，就必須理解它（以及我們自己）的短板，並主動去適應。」那麼，真的可以有一種方法，讓所有人在使用這些 AI 程式設計工具的時候，同時收穫效率和爽感嗎？除了這些「糟心」的體驗分享，X 上也有非常多的使用者分享自己使用這些 AI 程式設計工具提高生產力效率。
有人說 Claude Code 可以像你一樣去使用你的電腦，他建立了一個 Claude.md 文件，在這個文件裡，告訴 Claude 如何訪問他資料夾中的重要目錄。像是用於回憶、日記、想法、程式碼、待辦事項、便籤和指令碼等不同的資料夾。此外，他還建立一些自定義命令，用於建立日誌的 /journal 命令，還有用於建立待辦事項的 /todos 命令。Claude Code 能夠在這些檔案裡面新增內容時，自動檢索它的電腦檔案，做到真正的智慧助手。他還分享了使用 MCP 連線到除了電腦本地資源以外的更多網路資訊，能連線 Notion、地圖軟體、線上辦公應用等等來進一步提升效率。他說 Claude Code 幾乎能高效的幫助他，完成所有的工作。對我來說，很明顯我們遇到的瓶頸不是模型能力，而是創造力和理解力。還是忍不住感慨，AI 程式設計的發展實在太快了……
2025 年最佳程式設計 AI：6款必備頂級 AI 工具，圖片來自：pragmaticcoders.com，2025-06-24從一開始還是隻能在側邊欄裡呼叫 GitHub Copilot，到後來豐富的 Agentic AI 程式設計工具，像是「Tab」一下的 Cursor、WindSurf、Trae，還有亞馬遜也在最近推出了 Kiro，等等。今年，再來到了從 GUI（圖形使用者介面）到 CLI（命令列介面）的轉變，有了 Claude Code 和 Gemini CLI……而這一切竟然就是發生在最近兩三年的時間裡。所以，我想對於這樣一個飛速發展的技術，我們更多的應該關注它的趨勢，而不應該是瑕疵。而趨勢的意義從來不在於它今天多成熟，而在於我們是否願意早點動手試一試，摸清它的邊界，找到自己的使用方式。甚至，推動它變得更好。
