AI 開發工具

前言:綠燈不等於對 我用一條 agentic 開發流水線,從零做完一個後台的「服務目錄」CRUD（Create/Read/Update/Delete,增刪查改）功能:一個內容管理系統（CMS）裡,管理員可以建立「服務」與「服務分類」,讓服務出現在使用者端 App 的列表裡。 結束時帳面很漂亮:單元測 772 全綠、build 通過、每個任務都過了兩段式 code review、最後還有一次整體 review。然後我把它部署到測試環境、用真實資料和真 App 一驗 —— 使用者 App 裡根本看不到剛建好的服務。 這篇要講的不是「怎麼修這個 bug」,而是一個更值得記下來的觀察:單元測、code review、端到端驗證,三者各自只抓得到「不同層級」的錯,缺一層就會放掉一整類問題。 開發流水線:每個任務都派新的 subagent 我用的是 subagent-driven development:先 brainstorm 出設計、寫成 spec、再拆成一份逐任務的 plan,然後每個任務派一個全新、無歷史包袱的 subagent 去實作。它做完後,再派兩個獨立 reviewer —— 先審「spec 合規」(有沒有照規格、有沒有多做少做),再審「程式品質」。 為什麼要派新的 subagent 關鍵在 context 乾淨。實作者只拿到「這個任務的完整描述 + 周邊脈絡」,不繼承我的對話歷史,所以不會被先前的決策慣性帶偏。reviewer 同理:它不知道實作者「想做什麼」,只能讀「實際寫出來的 code」對照規格 —— 這正是抓得到落差的前提。 主控者（orchestrator）唯一的工作是「精準地餵 context」與「把關 review loop」,不自己寫 code。這保住了主控者的 context,也讓每個 agent 都聚焦。 第一層:兩段式 review 擋下的真 bug 下面這些全部躲過了單元測(因為 mock 餵的是理想資料),是被 reviewer 讀 code 抓出來的。 雷 1:跟 API 要「只給名字」,結果連 ID 都不給了 存一筆「服務」時,要記錄它屬於哪個負責人,所以需要負責人的 ID。我為了省流量,跟後端說「負責人那欄,只給我名字就好」。後端很聽話 —— 只給了名字,把 ID 一起省掉了。 ...

缺口：戰略協調有了，戰術執行還在手動驅動 上一篇講了一份 CUTOVER.md 怎麼當跨 session、跨 repo 的控制平面 — 用 8 個 pattern 解決「AI agent 有遺忘症、任務卻沒結束」的協調問題。那套機制解的是戰略層：哪些高階決策被做過、哪個方案被否決、誰改完了等誰配合。 但它有個明顯缺口。Cutover doc 追蹤的是「高階任務」這個粒度 — 例如「後端 dual-write regression 要修」是一個 row。可是這個 row 底下，真正的執行還是我一個 session、一個 session 手動驅動：開 session、貼 pickup prompt、看它跑、它卡住我再 nudge、跑完我再回來 push doc。 換句話說，戰略層自動化了（doc 自己會被各 session pickup），但每個高階任務內部的戰術 loop — 寫測試、跑、看結果、修、再跑 — 還是人在當 orchestrator。 Anthropic 自家在 Building effective agents 這篇 engineering 文章裡定義過一個叫 orchestrator-workers（orchestrator–工人 pattern — 一個中央 LLM 動態拆解任務、派發給 worker LLM、再彙總結果）的工作流：原文寫「a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results」。配上 Claude Code 的 subagents（子代理 — 由主 agent spawn 的獨立 agent，每個都有自己 isolated context window）跟 headless mode（非互動模式 — 用 claude -p 把 prompt 餵進去、跑完吐結果，不開互動對話），就能補上 cutover doc 的戰術缺口 — 也就是「單一高階任務底下，怎麼讓 AI 自己跑數小時的 autonomous loop（自主迴圈 — 不需要人在中間 nudge，loop 自己 plan / execute / evaluate 直到條件達成）而不撞牆」。 ...

The Problem: AI Agents Forget, but the Task Doesn’t End 技術社群已經習慣「給人類看的 RFC」— Architecture Decision Records、incident postmortem、設計文件，模板都很成熟。但給 AI agent 之間用的非同步協作文件呢？少有公開討論。 最近處理一個跨三個 repo 的 schema migration：後端表結構改、前端 GraphQL 切換、行動端讀寫遷移，估計要 30+ 天，會跨越十多個獨立的 Claude session（不同時段、不同任務切片、不同筆電）。每次 session 結束、下一輪起來，前次的 context window 就消失了。問題不只是「上下文遺忘」，還包括： 上次 session 進度到哪？沒人記得。 之前否決過的方案？新 session 很容易「自信地重新提案」。 跨 repo 的「我改完了、等你那邊配合」訊息，怎麼跨越 session 邊界？ 某次踩的坑，下次會不會重蹈？ 我們最後長出一份 CUTOVER.md 放在獨立的 metadata repo，作為跨 session、跨 repo 的 out-of-band control plane。實戰一個月後，這份文件結晶出 8 個對 AI agent 特別有效的設計模式 — 它們幾乎都對應到分散式系統的經典概念。 The Architecture flowchart LR subgraph code[Code repositories] R1[backend repo] R2[frontend repo] R3[mobile repo] end subgraph plane[Control plane] DOC[CUTOVER.md<br/>append-only<br/>own repo] end subgraph time[AI sessions over time] S1[t1: backend session] S2[t2: frontend session] S3[t3: mobile session] S4[t4: backend session] end S1 -.modifies.-> R1 S2 -.modifies.-> R2 S3 -.modifies.-> R3 S4 -.modifies.-> R1 S1 -->|pull / push| DOC S2 -->|pull / push| DOC S3 -->|pull / push| DOC S4 -->|pull / push| DOC classDef p fill:#cce5ff,stroke:#007bff,color:#004085 classDef s fill:#d4edda,stroke:#28a745,color:#155724 classDef c fill:#f5f5f5,stroke:#333,color:#333 class DOC p class S1,S2,S3,S4 s class R1,R2,R3 c 每個 AI session 開場先 pull doc → 讀完上下文 → 完成任務 → push update。Doc 自己是獨立 repo，與三個 code repo 解耦，扮演純控制平面角色。 ...

前言：frontend 修補的驗證最常被推給人手點 修了一個 frontend modal 的提交守門 bug，把改動推上 STG（staging 環境），下一步「驗證」往往就是寄訊息給 QA 或產品經理：「請開瀏覽器點點看，看 UI 守門有沒有生效。」 這個步驟在 CI 跑完單元測試後通常還是被當成人類的責任，原因是 E2E（end-to-end，端到端）環境難搭、寫一次 Playwright 腳本要花的時間比人手點還久、而且 UI 本來就會變動。 但隨著 LLM agent 配上瀏覽器自動化能力，這個 trade-off 已經悄悄反轉了。Bot 不只能省掉人手點擊的時間，更會做一件人類常常忘了做的事：在 UI 看似成功之後，去資料庫驗證資料真的寫對了。 這篇文章記錄一次真實的 STG 驗收，原本要驗 frontend 修補，卻意外揭發 backend 的 dual-write regression（雙寫機制失效）。 Playwright MCP 是什麼，為什麼是它打破僵局 先把兩個關鍵字釐清： Playwright 是微軟釋出的瀏覽器自動化框架，原本是寫 JavaScript 或 Python 腳本控制 chromium。 MCP（Model Context Protocol） 是 Anthropic 推的開放協議，把外部工具用宣告式 schema 包成 LLM 可呼叫的 server，類似 LSP（Language Server Protocol）之於編輯器——讓不同 IDE 共用同一個語言分析後端。LLM 客戶端啟動時會跟 MCP server 握手取得可用 tool 清單，之後對話中就能像呼叫 function 一樣直接用。 ...

前言：一個月燒掉 $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（非同步任務中心） 這是你的「任務控制中心」，可以： ...