在軟體開發與專案製作的過程中，市面上的 AI 輔助工具五花八門。從本地部署的 LLM 工具到雲端協作平台，每個工具都有其主打特色。

然而，在評估了開發效率、資源消耗以及上手門檻後，我們最終選擇以 Codex 與 Antigravity 作為開發的核心雙引擎。今天我們就來聊聊這套組合背後的選型邏輯！

1. 本地運算工具的痛點：以 LM Studio 為例

許多開發者為了資料隱私或免費使用，會選擇像 LM Studio 這類能把大語言模型下載到本地執行的工具。但 LM Studio 在實際開發輔助上存在極大的硬體瓶頸：

• 極度消耗電腦硬體資源：
  LM Studio 是完全依賴你自己的電腦硬體（CPU / GPU / RAM）進行本地運算。當你在跑模型的同時開著 Xcode、IntelliJ IDEA 或 Android Studio，電腦資源會被瞬間吃滿。
• 卡頓與開發體驗極差：
  除非擁有極頂級的工作站配備，否則在本地推論大型模型時，電腦會出現嚴重的卡頓、發熱與風扇狂轉現象。為了寫幾行 Code 讓整台電腦陷入癱瘓，極度影響開發流暢度。

2. 終端機介面的操作門檻：以 Ollama 為例

另一個非常熱門的本地 AI 工具是 Ollama，它專注於輕量化與命令列運作，但也帶來了使用者體驗上的挑戰：

• 依賴終端機（Terminal）指令：
  Ollama 的操作高度依賴 Command Line。對於不熟悉 CLI 指令、環境變數設定或文字介面調參的開發者來說，學習與使用門檻偏高。
• 缺乏直覺的 IDE 與 GUI 整合：
  在沒有安裝額外第三方 GUI 的情況下，要在終端機與 IDE 之間來回切換複製程式碼，效率極低，無法做到像 Codex 一樣在開發環境中「隨手呼叫、自動貼上」的無縫體驗。

💡 選型總結

• LM Studio：卡頓、耗資源、影響電腦效能。
• Ollama：純指令操作、缺乏視覺化介面、上手不夠便利。

正是因為這兩類工具在硬體負擔與操作便利性上的缺點，我們才轉向尋求更高效的解決方案。明天我們將接續 Day 21，說明 Codex 與 Antigravity 如何完美解決這些問題！