Humanity has prevailed (for now!)
人類暫時取得了勝利！

昨天，在東京舉行的 AtCoder 2025 世界巡回賽中，一位人類選手 Psyho 以較大差距暫時擊敗了 OpenAI 提交的自動化程序 OpenAIAHC，拿下榜首。

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 都能支持中文的輸入。

動作還是非常快的，可能因為任務比較簡單，代碼生成的過程并不需要等待很久。它首先自動生成了需要安裝哪些庫，可以用來爬取網頁，接著生成了 main.py，核心的代碼文件。

中間遇到的問題是知乎需要登錄，它還自動使用 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……而這一切竟然就是發生在最近兩三年的時間里。

所以，我想對于這樣一個飛速發展的技術，我們更多的應該關注它的趨勢，而不應該是瑕疵。而 趨勢的意義從來不在于它今天多成熟，而在于我們是否愿意 早點動手試一試，摸清它的邊界，找到自己的使用方式。

甚至，推動它變得更好。

歡迎加入 APPSO AI 社群，一起暢聊 AI 產品，獲取，解鎖更多 AI 新知

我們正在招募伙伴

簡歷投遞郵箱hr@ifanr.com

?? 郵件標題「姓名+崗位名稱」（請隨簡歷附上項目/作品或相關鏈接）