Combining Strategic Cutover Docs with Tactical Headless Orchestrators

缺口:戰略協調有了,戰術執行還在手動驅動 上一篇講了一份 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 直到條件達成)而不撞牆」。 ...

May 22, 2026 ·  · 9 分鐘 · Peter

Designing a Control-Plane Document for Async Multi-Session AI Agents

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 每個 AI session 開場先 pull doc → 讀完上下文 → 完成任務 → push update。Doc 自己是獨立 repo,與三個 code repo 解耦,扮演純控制平面角色。 ...

May 22, 2026 ·  · 6 分鐘 · Peter

LLM 驅動的 E2E 驗證:為什麼 bot 比人更容易揭發 backend regression

前言: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 一樣直接用。 ...

May 15, 2026 ·  · 4 分鐘 · Peter

Claude Code Token 不夠用?從 $20 升到 $100 還是燒光:我學到的教訓

前言:一個月燒掉 $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 時的除錯流程: 看到問題了嗎? 這就是「漫無目的的探索」——AI 不知道該往哪裡找,所以它嘗試讀取所有可能相關的檔案,每次讀取都在消耗 token。 Token 消耗的真相 操作類型 Token 消耗 實際價值 讀取不相關的檔案 高 零 廣泛搜尋 grep/glob 中 低(通常需要多次) 隨機嘗試修復 高 可能為負(引入新 bug) 來回確認「這樣對嗎?」 中 低 我的真實案例:為了修一個體脂率顯示的小數點問題,AI 讀取了: ...

December 20, 2025 ·  · 3 分鐘 · Peter

Cursor Browser Visual Editor 深度解析:AI 驅動的視覺化前端開發革命

前言 傳統的前端開發流程往往是這樣的:你在程式碼編輯器中修改 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 的付費用戶來說,這意味著: ...

December 19, 2025 ·  · 4 分鐘 · Peter

Subagent-Driven 與 Parallel Session:AI 協作開發的兩種典範

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

November 30, 2025 ·  · 22 分鐘 · Peter

Google Antigravity:AI 開發的典範轉移,從輔助編碼到自主開發

圖片來源: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(非同步任務中心) 這是你的「任務控制中心」,可以: ...

November 22, 2025 ·  · 5 分鐘 · Peter