我為什麼不再用 IDE，改在終端機裡開發

編譯摘要

我為什麼不再用 IDE，改在終端機裡開發 — 編譯摘要

濃縮

  1. 當 AI 成為主要程式碼產出者，IDE 的程式碼編輯視窗不再是核心需求：開發者的工作模式從「手寫程式碼」轉變為「對話 + 指令」，佔螢幕 80% 的程式碼編輯區反而多餘。一天中真正需要逐行閱讀程式碼的時間不到三成。
  2. 終端機作為 AI 時代的開發介面，以對話為主體而非程式碼為主體：Warp 的設計邏輯反映了這個轉變——分頁管理多專案、視窗分割讓對話和操作並行、每個分割視窗地位平等（不像 IDE 中終端機是「附屬品」）。
  3. 資源效率是實際的推力：Antigravity（VS Code 衍生）佔用 40 幾 GB 記憶體，促使作者重新評估 IDE 的成本效益比。

關鍵證據：作者的工具演進路徑——PhpStorm → Cursor → PhpStorm + Claude Code → Antigravity → Warp 終端機——每次切換都有具體觸發事件，最終收斂到純終端機方案。

質疑

  • 前提假設：假設開發者的主要工作是「與 AI 對話」。但在除錯、效能調校、複雜重構等場景中，IDE 的靜態分析、斷點除錯、型別檢查仍不可替代。純終端機方案在這些場景的效率可能下降。
  • 邊界條件：作者的工作以 WordPress 外掛開發為主，程式碼結構相對固定。對於大型前端專案（React/Vue）或需要頻繁 UI 預覽的場景，IDE 的即時預覽和熱更新可能仍是必要的。
  • 反例：文章中 Antigravity 佔 40GB 記憶體可能是異常情況（記憶體洩漏），不能代表所有 IDE 的資源消耗。VS Code 正常使用通常在 1-3GB 範圍內。以異常值作為放棄 IDE 的論據，說服力有限。
  • 反例：Cursor、Windsurf 等 AI-native IDE 正在重新設計介面佈局，以對話為中心而非程式碼為中心。「IDE vs 終端機」的二元選擇可能很快被「AI-native IDE」取代。

對標

  • [[認知負荷]]與介面設計：IDE 的複雜介面在 AI 時代可能成為認知噪音。終端機的簡約介面反映了「減少無關資訊」的認知負荷管理原則，與 [[AI 工具模組化]] 中「只在需要時觸發」的思維一致。
  • [[工具演化]]的 S 曲線：IDE 可能正處於 S 曲線的成熟期，功能累積帶來的複雜度開始超過邊際效用。終端機 + AI 是新 S 曲線的起點。
  • [[媒介即訊息]]（McLuhan）：工具塑造工作方式——以程式碼編輯器為中心的 IDE 鼓勵「閱讀和修改程式碼」的行為；以對話為中心的終端機鼓勵「描述需求和審查結果」的行為。工具的選擇本身就改變了開發者的認知模式。

關聯概念

  • [[終端機工作流]]
  • [[開發者體驗]]
  • [[認知負荷]]
  • [[AI 工具模組化]]
  • [[工具選擇策略]]
  • [[人機協作工作流]]