AI 編程現在到底是什麼水平了？

JustSayAI

September 30, 2025

AI 編程的終極問題：誰來背鍋？（利益相關，非程序員）

我必須在開頭就捅破那層窗戶紙：程序員就是用來背鍋的。我開發一個新功能或許不難，但修復一個盤根錯節的 Bug 卻異常艱難。事情搞砸了，有人能修，就留下；修不了，就滾蛋。這，就是商業世界冷冰冰的運作真相。

然而，所有關於 AI 編程的狂熱討論，似乎都在兩條截然不同的賽道上狂奔，卻又心照不宣地迴避了這個核心問題。一條賽道由 Cursor、Windsurf 這樣的“交互式”集成開發環境（IDE）領跑，它們像一個副駕駛，深度嵌入程序員的日常，實時輔助；另一條賽道則由 Jules、Codex 這類“異步”編程代理（Agent）構成，它們更像一個可以領走任務、隔夜交付結果的獨立承包商。但無論哪條賽道，都陷入了一個“高不成，低不就”的尷尬境地：真正的頂尖高手覺得它礙手礙腳，而編程小白麵對真正的工程難題時，它又愛莫能助。

賽道一：IDE 的“人機共駕”，交互體驗定生死

在 IDE 這條賽道上，上演的是一場關於“交互哲學”的對決，主角是更懂專業開發者的 Cursor 和更懂企業用戶的 Windsurf 。

Cursor 之所以能成為明星，並非自身有什麼智能突破，而是因為它機緣巧合地站在了 Claude Sonnet 這個大模型巨人的肩膀上。它真正的護城河，是選擇從零開始做一個獨立的編輯器，而不是一個簡單的插件。因為編程是一種極度注重沉浸式體驗的工作，任何卡頓和不順都會讓用戶放棄。只有完全掌控平臺，才能打磨出極致的細節，比如那個讓我願意為它掏錢的“git merge”功能——它能以程序員的思維去比對、合併 AI 生成的代碼，而不是粗暴地全盤替換。

而 Windsurf則走向了另一條更務實的道路：ToB 優先，兼容屎山代碼。它更早、也更堅決地把自己切換到了“AI 當主駕，人當副駕”的智能體模式。這種模式對小白用戶和企業流程更友好，因為企業服務最怕的就是高昂的客服成本和無休止的扯皮。這也解釋了為什麼 OpenAI 最終願意豪擲 30 億美金收購它——OpenAI 需要的不僅是一個 ToB 的銷售渠道，更是海量的、寶貴的“過程數據”：那些在反覆修改、調試、反饋中產生的，遠比 GitHub 上靜態的最終代碼更有價值的數據，這些數據是訓練更強大模型的終極養料。

賽道二：異步 Agent 的“全包之夢”，空中樓閣待落地

另一條賽道則顯得更加野心勃勃。Google 的 Jules、OpenAI 的 Codex 和 Anthropic 的 Claude Code，上演了一齣“三國殺” 。它們的目標是實現“異步編程”——你晚上睡覺前交代一個任務，7 小時後一早醒來，代碼已經交付到你面前。

這其中，Google 的 Jules 最具代表性，它希望憑藉強大的雲計算能力，提供“全託管”服務，你提需求，它全包。這聽起來是所有老闆的終極夢想，畢竟，正如一位創始人所言：“代碼是最確定的，程序員是最貴的，我肯定會逼著所有人都用，誰不用誰就滾” 。

但這個夢想目前更像是一場華麗的“概念車”發佈會。這些工具展現了技術的未來方向，但離真正上路還有遙遠的距離。因為軟件開發最難的從來不是寫代碼，而是清晰地定義問題。我們現實中的老闆，有多少能像唐僧一樣目標堅定？他們往往是“說要去西天取經，結果半路拐進了 KTV” 。當一個需求本身都充滿不確定性，AI 又如何能獨立完成？

共同的瓶頸：翻不過的“人之常情”三座大山

無論是深度集成程序員工作流的 IDE，還是試圖獨立完成任務的異步 Agent，它們最終都撞上了同一堵牆——使用者本身。AI 的使用門檻看似降低了，實則被無限抬高。因為高質量的輸出，必然依賴於更高質量的輸入。

要讓 AI 真正替代程序員，必須翻越三座大山：可被描述、可被拆解、可被評估。

可被描述：你能像哲學家維特根斯坦要求的那樣，用語言毫無歧義地描述你的世界（需求）嗎？當你能做到時，你會發現你的語言已經驚人地接近代碼本身了。