我為什麼不再用 Antigravity，而改在終端機裡開發
|
大家端午快樂，這週分享一下我目前的主力開發工具～ 開發工具的使用歷程在 AI 時代前，我都是使用 PhpStorm。PHPStorm 確實順手——跳到函式定義、儲存時自動格式化和檢查，這些功能讓開發效率提升不少。 進入 AI 時代後，我用了 Cursor 好幾個月。自動補全和聊天介面加速了不少開發流程。但用了一段時間，我發現自己還是需要理解程式碼的能力，最後回到 PHPStorm 搭配 Claude Code 的組合。 後來也試過 Google 的 Antigravity。除了免費額度以外，用起來跟 VS Code 差不多。直到某天我打開系統監控，發現 Antigravity 的記憶體佔用竟然到了 40 幾 GB。 40 幾 GB，只為了一個程式碼編輯器。 程式碼視窗還重要嗎？這讓我開始重新思考一個問題：傳統 IDE 的設計核心是「程式碼」。整個介面以程式碼編輯器為主體，側邊欄、終端機、除錯面板都是輔助角色。 但我現在的開發流程已經變了。大部分時間我在跟 Claude Code 對話，描述需求、確認方向、審查它產出的結果。真正需要自己打開檔案逐行閱讀的時候，一天可能不到三成。 既然主要的工作模式是「對話 + 指令」，那為什麼不直接在終端機裡做？ 改用 Warp 之後的工作流程
我選了 Warp 作為主力終端機。用了幾週下來，整理出三個讓我回不去 IDE 的原因。 多專案管理靠分頁就搞定我同時在跑好幾個專案。在 Warp 裡，每個專案就是一個 Tab。早上開工時，Warp 會把我開過的專案分頁都暫存起來，只要一啟動時，就是所有我目前手邊正在進行中的專案，每個 Tab 直接切到對應的專案目錄。要切換專案，Command + 數字鍵就到了。 不用像以前那樣開好幾個 IDE 視窗，每個視窗吃掉一大塊記憶體。 視窗分割讓對話和操作並行Command + D 就能分割畫面。我常用的配置是左邊跑 Claude Code，右邊開一個終端機執行指令。如果需要同時監看 log 或跑測試，再切一個小視窗出來。 這跟 IDE 裡開 Terminal 的體驗完全不同。在 IDE 裡，終端機是被塞在底部的附屬品；在 Warp 裡，終端機就是主角，每個分割視窗都是平等的。我可以根據當下的需求，自由調整每個視窗的比例和用途。 檔案操作也不缺真的需要瀏覽檔案結構的時候，Warp 左側也有目錄面板，點選就能開啟檔案。雖然不像 IDE 那樣有語法高亮和智慧提示，但對於偶爾需要確認檔案內容的場景來說夠用了。 這套做法適合誰我不會說每個開發者都該丟掉 IDE。如果你的工作需要大量手寫程式碼、頻繁使用重構工具、依賴型別檢查和自動補全，IDE 依然是最好的選擇。 但如果你跟我一樣，日常開發有一大半時間在跟 AI 協作——描述需求、審查產出、下指令執行——那 IDE 裡那個大大的程式碼視窗，可能真的不是你最需要的東西。 Warp 的介面設計剛好反映了這個轉變：它以 AI 對話為主體，終端機操作為輔助。當你的工作流程本來就是「對話 + 指令」，這樣的配置比 IDE 順手得多。 - 如果你希望可以看到更多關於 AI 開發的實用工具跟做法，可以回信傳一個 🛶 給我讓我知道！ |
WordPress 開發日常
之前朋友約出來喝咖啡時他分享下一個階段的 AI 可能會發展成監督式的 AI，也就是當 AI 自己在跑的時候，會有另外一個 AI 來檢查它現在做的每一件事情是否都真的有往正確的方向推進。 當下聽到覺得這個 idea 很棒，但具體要怎麼實作完全沒有概念，更不用說這樣子 token 消耗的成本會不會變成兩倍？而且監督 AI 的 AI 需要有什麼能力？該以哪一種方式來進行監督？然後又該如何把找出的問題回報給原本的 AI 呢？ 這一切問題在我最近研究 Claude Code 以外的工具時意外發現了解決方案，那就是之前我拿來做為 Discord Bot 的 AI 引擎 OMP。 OMP 是 PI 的分支，想理解什麼是 OMP 可以先從 PI 開始理解，PI 是一套開源且輕量化的 Coding CLI，也是跟 Claude Code 一樣跑在終端機的寫程式 Agent。 相較於 Claude Code 的封閉，PI 完全開源，並且支援多家不同的模型，PI 強調有需要什麼工具再自己額外安裝，就不會像 Claude Code 一樣原廠給你什麼就只能用什麼。 而 OMP 是 PI 的分支，它的概念跟...
之前分享我請 AI 設計的一套專門用來管理手邊待辦清單的專案管理軟體，邊用的時候我就在邊思考著：當我新增這些任務之後，我還是要回到終端機去把這些任務的描述、相關的文件以及完成的目標告訴 AI，然後等它跑完之後我再驗收，再回到我的計時軟體裡面來記錄是已完成還是該暫停。 如果可以在開立任務的時候，就能直接指派 AI 來做這件事情，是不是就可以少一個重複描述、開發需求的流程？剛好有了這個想法之後，就在 YouTube 上面看到一個叫做 Auto Claude 的專案。 它把 Claude 直接跟看板軟體整合，並且可以在裡面詢問 AI 關於專案的細節以及產生開發藍圖，也能設定專案的亮點與相關資訊。 我看到後驚為天人，覺得這似乎是另外一種理想的 AI 開發軟體，本想直接下載裝起來用，但請 Claude 研究後發現它有一些問題，於是就想說自己來開發，順便理解關於整個 Loop Engineering 的概念。 Claude Orchestrator 這次一樣是使用 Glaze 來開發，請它建立好專案的環境之後，然後再回到終端機去接手後續的多工並行。我的做法是先請 AI 去參考 Auto...
常常在社群媒體上看到各種自動化工具的廣告，從早期的 n8n 開始到現在 AI Agent 自動完成任務，這些工具跟流程都很棒。但是回到使用者本身，我們真的知道自己有哪些工作是可以被自動化或是應該「自動化」的嗎？ 這就讓我回想起以前給自己的工作要求，那就是要把手上所做的每一件事情都記錄下來，並且可以明確看到每項任務的執行時間以及頻率，這樣事後才有辦法做回顧，我把這樣的理念也應用到承接專案的層面上。 這也是為什麼我有一些專案都是採取時薪計價的開發模式，因為我需要讓客戶知道他的預算都花在哪些項目，來藉此把資源用在合適的任務上。 我最早使用的即時軟體叫做 Ora，這是一套結合看板管理、敏捷開發流程、時數統計，甚至還有內建聊天討論串的一套強大工具。 它長期都是免費的，付費方案是團隊成員超過計算，所以我都是使用它來進行與客戶的專案管理，它的介面十分清楚且一目瞭然，可以縱觀地知道是哪一類型的任務花最多時間，也可以細看到具體是在處理哪一個問題所消耗的時數。 但當某天我打開準備使用它的時候，發現它被另外一套專案管理軟體 ClickUp...