Developer Tools

前言：一個月燒掉 $100 的真實故事 如果你正在考慮升級 Claude Code 的訂閱方案，或者已經升級了卻發現 token 還是不夠用，那你來對地方了。 這不是一篇推銷文，而是一個真實的使用心得。 我從 Pro Plan（$20/月） 開始使用 Claude Code，很快就發現 token 不夠用。心想：「升級到 Max Plan（$100/月）應該就沒問題了吧？」 結果呢？ Max Plan 的 token 也不夠用。 更尷尬的是，我花了大把的 token 去處理一些看似簡單的 bug，像是： 體脂率的小數點精度問題 排便次數顯示 null 和 0 的差異 這些問題聽起來簡單，實際上卻各花了大量 token 去「探索」程式碼。 直到我發現問題的根源不是 token 不夠 (Pro plan是真的不夠！)，而是我沒有找到對的 Skill 來處理這類問題。 問題分析：Token 都燒去哪了？ 讓我用一張圖來說明沒有使用正確 Skill 時的除錯流程： graph TD A[發現 Bug] --> B[讓 AI 搜尋程式碼] B --> C[讀取 file_a.dart] C --> D[沒找到，讀取 file_b.dart] D --> E[還是沒找到，讀取 file_c.dart] E --> F[發現可能相關，展開搜尋] F --> G[讀取更多檔案...] G --> H[終於找到問題] H --> I[提出修復方案] I --> J{修復成功？} J -->|否| B J -->|是| K[完成] style B fill:#ff6b6b,color:#000 style C fill:#ff6b6b,color:#000 style D fill:#ff6b6b,color:#000 style E fill:#ff6b6b,color:#000 style F fill:#ff6b6b,color:#000 style G fill:#ff6b6b,color:#000 style K fill:#51cf66,color:#000 看到問題了嗎？ ...

前言 傳統的前端開發流程往往是這樣的：你在程式碼編輯器中修改 CSS，儲存檔案，切換到瀏覽器查看效果，發現不滿意，再切回編輯器調整⋯⋯這個來回切換的過程不僅耗時，更打斷了創意的流動。 Cursor 的 Browser Visual Editor 正是為了解決這個問題而生。 這個全新功能將網頁應用程式、程式碼庫和視覺化編輯能力整合在單一介面中，讓開發者可以直觀地操作介面元素，同時保持與程式碼的同步。本文將深入解析這項創新功能的核心概念、運作原理和實際應用場景。 什麼是 Cursor Browser Visual Editor？ 核心概念 Cursor Browser Visual Editor 是一個整合在 Cursor IDE 中的視覺化編輯工具，它讓開發者能夠： 直接拖拉介面元素來調整佈局 透過側邊欄即時修改樣式屬性 使用自然語言描述想要的變更 讓 AI 自動更新對應的程式碼 這不只是一個簡單的 CSS 預覽工具，而是一個完整的**設計到程式碼（Design-to-Code）**工作流程。 省 Token 的關鍵利器 這裡要特別強調一個重要的實用價值：Visual Editor 可以大幅減少你對 AI 下 prompt 的次數，進而節省 Token 用量！ 想像一下傳統的 AI 輔助開發流程： ❌ 傳統 AI 輔助方式（消耗大量 Token）： 1. "請把這個按鈕的 padding 加大一點" → 消耗 Token 2. 看效果，不滿意 3. "再大一點，然後加個圓角" → 消耗 Token 4. 看效果，顏色不對 5. "背景色換成藍色" → 消耗 Token 6. 還是不滿意... 7. 反覆對話 10 次 → 消耗大量 Token 💸 ✅ Visual Editor 方式（幾乎零 Token）： 1. 直接在面板上拖動 padding 滑桿 → 0 Token 2. 調整 border-radius 數值 → 0 Token 3. 點選色盤換顏色 → 0 Token 4. 即時預覽，滿意為止 → 0 Token 5. 只有複雜變更才需要 AI → 少量 Token ✅ 對於 Cursor 的付費用戶來說，這意味著： ...

前言：AI 協作開發的範式演進 在 AI 輔助開發工具快速演進的今天，我們已經從「程式碼自動補全」進化到「AI 主動協作」的階段。Claude Code 作為 Anthropic 推出的革命性開發工具，引入了兩種截然不同但互補的協作模式：Subagent-Driven Development 和 Parallel Session。 ...

圖片來源：Google Antigravity 官方部落格 前言：當 AI 從助手變成隊友 2025 年 11 月，Google 悄悄推出了一款顛覆性的開發工具 —— Antigravity。這不是又一個「AI 程式碼補全工具」，而是一個徹底改變我們思考軟體開發方式的平台。如果說 GitHub Copilot 和 Cursor 是你的智慧助手，那麼 Antigravity 就是一支能夠自主規劃、執行和驗證的 AI 團隊。 在深入研究了官方文件、實際案例和社群回饋後，我想分享這個「代理優先」（Agent-First）開發平台的核心理念、創新功能，以及它目前仍面臨的挑戰。 核心概念：什麼是「代理優先」開發？ 傳統 AI 輔助 vs. 代理優先開發 在傳統的 AI 輔助編碼中，開發者仍然是主角：你逐行寫程式碼，AI 只是在旁邊提供自動完成建議。但 Antigravity 提出了一個全新的工作模式： 你不再是程式碼的執行者，而是任務的指揮官。 這個轉變體現在： 傳統模式：「我要在第 42 行加一個函數…」（微觀管理） Antigravity 模式：「建立一個包含搜尋功能的活動網站」（任務導向） AI 代理會： 分析需求並制定計劃 自主執行所有編碼工作 測試應用程式並驗證功能 產生可審查的成果文件（Artifacts） 三個核心介面：Mission Control 架構 Antigravity 設計了三個相互配合的工作介面： Editor 與 Agent Manager 的雙介面架構 1. Agent Manager（非同步任務中心） 這是你的「任務控制中心」，可以： ...

前言：差點對錯誤的 cluster 下指令 某天下午，我在兩個 EKS（Amazon Elastic Kubernetes Service）cluster 之間切換除錯，staging 和 production 的 kubeconfig context 都掛在同一台筆電上。當我打完 kubectl delete deployment 按下 Enter 前的那半秒，我其實不確定自己在哪個 context。那次運氣好，是 staging。 事後檢討，問題不是粗心，是預設的終端機提示字元什麼都不告訴你。user@host ~ % 這行字 20 年來沒變過，但我們的工作環境早就變了：一個人同時面對多個 cluster、多組 AWS 帳號、十幾個專案目錄。工具沒跟上環境，靠的就只剩自律——而自律總有失靈的一天。 這篇文章整理我把終端機全面現代化的過程：六個主力工具，加上一批不用安裝任何東西的原生 shell 技巧。每個工具都回答三個問題：為什麼要換、不換的代價是什麼、以及會踩到哪些坑。 六個升級，按痛點排序 1. starship — 操作 EKS 前，先看一眼提示字元 starship 是用 Rust 寫的跨 shell 提示字元引擎。裝完之後，每行指令前會自動顯示：目前路徑、git 分支與狀態、語言版本，以及對 DevOps 最關鍵的兩個欄位——kubernetes context 和 AWS profile： ~/work/api-server on main via 🐍 v3.11.4 ☸ arn:aws:eks:ap-northeast-1:123456789012:cluster/prod-cluster (default) ❯ 為什麼這樣做？ 防呆的本質是把「需要主動確認的事」變成「被動就會看到的事」。kubectl config current-context 誰都會打，但沒有人會在每一條指令前打一次；提示字元每次都在，你想忽略都難。 ...