Debug 能力才是 AI 編輯器的真正護城河

一個反常識嘅開場

過去兩年，AI 編輯器嘅競爭焦點一路擺喺「寫 code」——誰生成得快、誰理解 prompt 準、誰支援嘅 model 多。但如果你問我用咗一年 Cursor、半年 Codex、再試過 Claude Code 嘅實際體感，我會話你知：寫 code 能力已經 commodity 化，真正分出高下嘅係 debug 能力。 一個 AI 編輯器幫你寫完 code 只係第一步，當佢寫嘅 code 行唔通、報錯、或者邏輯硬係唔啱嘅時候，佢能唔能夠自己發現問題、追蹤根源、修正再驗證——呢個先係決定開發者會唔會留低嘅真正門檻。

點解 debug 比寫 code 更難做好

寫 code 本質上係生成任務：俾一個 context window + instruction，模型 predict 下一段 token。呢個問題嘅結構相對清晰，模型喺大規模 code data 上 pre-train 得愈好，output 就愈可靠。但 debug 係完全唔同嘅問題類別——佢需要反向追蹤因果鏈、需要理解「預期行為 vs 實際行為」之間嘅差距、需要喺多個可能嘅 root cause 之間做假設檢定。

現實中嘅 debug 場景係咁嘅：你寫咗一個 React component，佢渲染出來嘅 UI 同你預期嘅唔同。錯誤訊息可能喺 console 出現，但 root cause 可能喺三個層次以上嘅 parent component 嘅 useEffect dependency array 入面。AI 編輯器如果淨係識得根據錯誤訊息改最近嗰行 code，同叫人「試下熄機再開」冇分別。

Cursor Debug Agent 呢度做咗一個關鍵嘅設計決定：佢唔只係俾 error trace 你睇，而係 run 一個完整嘅 debug loop——睇 error、追 code path、改 code、再 run 嚟驗證，直至問題解決或者資源耗盡。呢個 loop 睇落簡單，但背後需要編輯器層級嘅深度整合：讀 terminal output、理解 stack trace 嘅指向、喺正確嘅檔案位置做修改、然後重新觸發 build 或 test。呢啲嘢唔係單純嘅 LLM prompt engineering 做到嘅。

Cursor Debug Agent 嘅具體差距

實際對比 Cursor Debug Agent 同 Codex/Claude Code 嘅 debug 流程，會見到幾個關鍵差異。

第一，context 嘅掌握深度。Codex Agent 或者 Claude Code 喺 debug 時，佢哋嘅 context 主要來自 user 俾嘅 instruction 同 terminal output。如果你冇 copy 晒成個 error 同相關 code 俾佢，佢嘅 debug 能力會大打折扣。Cursor Debug Agent 唔同，佢可以直接讀取 editor 入面嘅 diagnostics、terminal 嘅即時 output、甚至 LSP 嘅 type error——呢啲 context 係自動收集嘅，唔需要 developer 手動餵。

第二，iteration 速度。一個典型嘅 debug session 係咁：睇 error → 改 code → rebuild → 睇新 error → 再改。如果每個 iteration 都要 developer copy-paste output 俾 AI，再等 AI 回覆，然後手動 apply change，個 loop 慢到唔值得用。Cursor Debug Agent 嘅價值在於呢個 loop 喺編輯器內部自動化咗——error 出咗，佢自己睇、自己改、自己觸發 rebuild。你喺旁邊睇住佢試，得就得，唔得佢會轉 strategy。

第三，工具使用嘅廣度。真正嘅 debug 唔只係改 code，而係要睇 log、check network request、inspect DOM、甚至用 debugger breakpoint 逐行睇變量值。Cursor 嘅 Agent 透過同 terminal、browser devtools、同 LSP 嘅整合，做到更完整嘅工具鏈覆蓋。Codex 同 Claude Code 喺呢方面主要靠 command execution，但佢哋同編輯器本身嘅 integration 冇咁深。

點解呢個係護城河

AI 編輯器市場嘅競爭已經進入第二階段。第一階段係「邊個寫得快」——呢度大家都追到差唔多，因為底層 model 嘅進步係共享嘅。你用 GPT-4o，我用 Claude 4，佢用 Gemini 2.5，generate 出來嘅 code quality 差距愈來愈細。

第二階段嘅競爭係「邊個寫完之後你唔使執咁多」。呢個「執」嘅過程絕大部分係 debug。一個 AI 編輯器寫 code 嘅準確率就算得 90%，嗰 10% 要你自己逐個修，體驗一樣係爛。但如果佢嘅 debug loop 夠快、夠準、夠自動化，嗰 10% 嘅修復成本可以從 10 分鐘降到 30 秒。

更重要嘅係，debug 能力嘅提升依賴編輯器層級嘅基礎設施——唔係單純 call 一個 API 就做到嘅。你要做 terminal integration、建立 file watcher、設計 agent 嘅 failure recovery 策略、決定幾時放棄一個 approach 轉第二個、平衡 token budget 同 iteration 深度。呢啲累積性嘅工程投入，唔係 competitor 短期內可以 copy 嘅。呢個就係真正嘅 moat。

對開發者嘅實際建議

如果你今日要揀 AI 編輯器作為每日主力工具，唔好再淨係比較「邊個 prompt 寫得靚」或者「邊個支援嘅 model 多」。請你親身試一個場景：故意寫一段有 bug 嘅 code，然後睇下每個工具點樣幫你 debug。

具體啲講：

• 寫一段有 off-by-one error 嘅 logic，睇編輯器識唔識得自己 trace 出問題
• 寫一個 React useEffect 嘅 infinite loop，睇佢識唔識分析 dependency array
• 寫一個 TypeScript generic constraint 錯嘅情況，睇佢識唔識得唔淨係改 type annotation 而係真正理解 generic 嘅設計意圖

做咗呢個測試之後，答案好明顯。Cursor 喺 debug 呢個維度嘅領先唔係啱啱開始——係由 Agent 功能推出嗰日就已經 build into 核心設計。Codex 同 Claude Code 當然會追，但要追嘅唔係一個 feature，而係一整層 editor-level infrastructure。呢個 gap 唔係幾個月追得到嘅。

對於香港同繁體中文圈嘅開發者，我呢個建議特別重要：我哋好多時候係用 AI 編輯器嚟補語言 barrier——英文唔係母語，睇 documentation 慢，所以更依賴 AI 幫手理解同除錯。一個 debug 能力強嘅編輯器，對我哋嘅生產力加成遠比一個單純寫得快嘅編輯器大。揀啱工具，係對自己時間最大嘅尊重。