為什麼你的AI設計流程慢如蝸牛？因為你還在用截圖

作者：竇竇的AI工具庫
日期：2026年1月26日 下午11:00
來源：WeChat 原文

✦整理版優先睇

速讀 5 個重點 高亮

用 Stitch MCP 同 Agent Browser 組合，4 分鐘搞掂全站測試，關鍵係用快照取代截圖、用規劃提升設計質量。

整理版摘要

作者一直以為 AI 設計瓶頸係「模型唔夠聰明」，但上星期用 Google Stitch MCP 加 Vercel Agent Browser，4 分鐘做完一個完整應用嘅 UI 測試，先發現原來係方法錯咗。佢嘅結論係：好的 AI 設計靠「對嘅工具做對嘅事」，而唔係盲目追模型升級。

具體嚟講，Agent Browser 用 accessibility tree 快照定位元素，取代傳統截圖，速度提升 5 倍以上；Stitch MCP 令 Claude 可以直接操控設計工具，自動生成同集成，唔使手動喂資料。佢仲強調規劃文檔嘅重要性，話「規劃質量 = 設計質量」，自己改咗 10 次先開始生成設計，確保視覺連貫。

最後佢總結咗完整工作流：Claude Code 規劃 → Stitch MCP 生成 → Claude Code 實現 → Agent Browser 測試，並提出三個趨勢：MCP 生態爆發、Accessibility-first 開發、規劃工程成為新技能。呢篇文章對想提升 AI 設計效率嘅開發者同設計師好有參考價值。

  • 結論：AI 設計慢嘅根源係流程方法，而唔係模型能力；用對工具組合可以大幅提速。
  • 方法：用 Google Stitch MCP 讓 AI 直接操作設計工具，配合 Vercel Agent Browser 嘅快照測試，取代傳統截圖。
  • 差異：Agent Browser 快照方案比 Chrome 擴展截圖模式快約 5 倍，因為直接讀結構元素，唔使像素分析。
  • 啟發：規劃文檔嘅質量直接決定 AI 設計嘅最終效果，必須反覆打磨先開始生成，避免「能用但平庸」。
  • 可行動點：安裝 Agent Browser 同 Stitch MCP（非官方包快速體驗），喺 claude.md 加入規則「所有 UI 測試使用 agent browser」。
值得記低
工具

Vercel Agent Browser 安裝

全局安裝：npm install -g @anthropic/agent-browser；帶界面運行：agent-browser --headed

留作參考
工具

Google Stitch MCP 簡化安裝

使用第三方 stitch-mcp 包一鍵配置，非官方路徑，生產環境建議用官方路徑。

留作參考
整理重點

反直覺發現：瓶頸唔喺模型，喺流程

我一直以為 AI 設計瓶頸係 模型唔夠聰明，直到上星期用咗兩個工具組合，4 分鐘跑完一個完整應用嘅 UI 測試，以前至少要 20 分鐘。呢個結果令我明白：唔係模型升級咗，而係我用錯咗方法。

核心洞察：好的 AI 設計從來唔靠單一神器，而係靠 對嘅工具做對嘅事。

呢篇文章會詳細介紹點樣用 Google Stitch MCP 同 Vercel Agent Browser 呢個組合，徹底改變 AI 輔助設計嘅效率。

整理重點

Stitch MCP：AI 自己『食』設計

以前喺 Stitch 入面要手動輸入 prompt → 生成設計 → 手動導出 → 手動集成到代碼。而家有咗 Stitch MCP，Claude Code 可以直接調用 Stitch，自動生成設計、自動拉取代碼、自動集成。你唔再需要「喂」AI，AI 自己會「食」。

非官方安裝指令（實驗性） bash 
npm install -g stitch-mcp
stitch-mcp init
整理重點

規劃質量 = 設計質量：先磨文檔再生成

呢個係作者踩過最大嘅坑：直接讓 AI 生成設計，出嚟嘅嘢「能用但平庸」。後來佢發現，AI 設計嘅天花板係 規劃文檔嘅質量。

  1. 1 Claude Code 規劃模式 → 輸出詳細 UI 指南
  2. 2 反覆打磨規劃（至少改 10 次）
  3. 3 規劃定稿後，先讓 Stitch 開始生成

另外，Stitch 默認會將 landing page 拆成小組件分別生成，導致後期集成風格唔統一。解決方法：明確要求 生成一個完整嘅長頁面設計，保持視覺連貫性。

整理重點

截圖係慢嘅根源：Agent Browser 快照方案

傳統 Chrome 擴展測試 UI 嘅步驟：啟動完整瀏覽器 → 截屏 → 像素級分析 → 導航到下一個位置 → 再截屏……每一步都慢。而 Vercel 嘅 Agent Browser 換咗個思路：佢唔睇「像素」，佢睇「結構」——生成 accessibility tree 嘅快照，所有可交互元素都標記好，AI 通過 選擇器直接定位元素，唔使「睇圖揾按鈕」。

  • Chrome 擴展：原理係截圖 + 像素分析，速度慢，每次都要渲染 + 截圖
  • Agent Browser：原理係快照 + 選擇器定位，速度快，直接讀結構

作者嗰個 4 分鐘測完全站 嘅案例，換成截圖模式至少 15 分鐘起步。

Agent Browser 安裝與運行 bash 
npm install -g @anthropic/agent-browser
agent-browser --headed

小技巧：喺 claude.md 入面加一條規則——「所有 UI 測試使用 agent browser」，咁 Claude 就會自動揀更快捷嘅方案。

整理重點

完整工作流覆盤：從規劃到測試，再加三個趨勢

作者用呢套組合做咗個技術面試模擬 App，完整流程如下：

  • Claude Code（規劃模式）→ 輸出 UI 設計指南
  • 反覆打磨規劃至滿意
  • Stitch MCP → 根據指南生成完整設計 → 預覽 + 微調 → 導出 HTML/CSS
  • Claude Code（實現模式）→ 集成到 Next.js → 重構為組件化結構
  • Agent Browser → 快照測試全站 → 發現問題 → 自動修復 → 再測試

一句話總結：唔好再截圖慢測、手動喂設計、直接生成唔規劃。記住：截圖太慢，用快照；手動太繁，用 MCP；生成太糙，先規劃。

4分鐘搞掂全站測試。唔係吹水，係換咗個諗法。

一個反直覺嘅發現

我一直以為，AI設計嘅瓶頸在於「模型唔夠聰明」。

直到上星期，我用兩個工具嘅組合，4分鐘跑完咗一個完整應用嘅UI測試——以前至少要20分鐘。

唔係模型升級咗。係我用錯咗方法。

核心洞察：好嘅AI設計從來唔靠單一神器，而係靠「啱嘅工具做啱嘅事」。

今日講嘅呢套組合，改變咗我對AI輔助設計嘅認知：

  • Google Stitch MCP：畀AI agent直接叫用設計工具
  • Vercel Agent Browser：用「快照」代替「截圖」嘅測試神器

令AI成為真正嘅設計助手

Google Stitch最近開放咗MCP接口。

呢個代表咩？

以前：你喺Stitch手動輸入prompt → 生成設計 → 手動匯出 → 手動整合到代碼。

而家：Claude Code直接叫用Stitch → 自動生成設計 → 自動拉取代碼 → 自動整合。

你唔再需要「餵」AI，AI自己會「食」。

實際體驗中，我畀Claude根據規劃文件，自動創建Stitch項目、生成landing page、拉取HTML代碼、整合到Next.js——全程我只打咗幾行指令。

即時行動指南

安裝有兩條路：

  1. 官方路徑（穩但麻煩）：裝Google Cloud SDK → 登入兩次（用戶+應用）→ 啟用Stitch API → 設定MCP
  2. 非官方簡化版（快但實驗性）：一個第三方stitch-mcp套件，一鍵搞掂曬成個流程

⚠️ 非官方版目前用得，但隨時可能失效。生產環境建議用官方。

規劃質量 = 設計質量

呢個係我踩過最大嘅坑：

直接叫AI生成設計，出嚟嘅嘢「用得但平庸」。

後來我發現，AI設計嘅天花板，係你規劃文件嘅質量。

我而家嘅流程係咁：

1. Claude Code 規劃模式 → 輸出詳細UI指南
2. 反覆打磨規劃（我改了不下10次）
3. 規劃定稿後，才讓Stitch開始生成

有個細節好關鍵：Stitch默認會將landing page拆成一個個小組件分別生成。咁會搞到後期整合時風格唔統一。

解決方法：明確要求「生成一個完整嘅長頁面設計」，保持視覺連貫性。

截圖係慢嘅根源

呢個係今日最重要嘅洞察。

Claude嘅Chrome擴展點樣測試UI？

  1. 啟動完整瀏覽器
  2. 截屏
  3. 像素級分析
  4. 導航到下一個位置
  5. 再截屏...

每一步都慢，疊加起嚟就係災難。

Vercel嘅Agent Browser換咗個諗法：

佢唔睇「像素」，佢睇「結構」。

具體嚟講，佢生成嘅係accessibility tree嘅快照——一棵標記曬所有可交互元素嘅結構樹。AI透過選擇器直接定位元素，而唔係「睇圖揾掣」。

維度
Chrome擴展
Agent Browser
原理
截圖 + 像素分析
快照 + 選擇器定位
速度
慢（每次都要渲染+截圖）
快（直接讀結構）
精度
依賴視覺識別
精確到元素
會話
用你嘅瀏覽器
獨立Chromium實例

我嗰個4分鐘測曬全站嘅案例，換成截圖模式至少15分鐘起跳。

即時行動指南

# 安裝（全局）
npm install -g @anthropic/agent-browser

# 帶界面運行（方便觀察）
agent-browser --headed

一個小技巧：喺claude.md度加一條規則——「所有UI測試用agent browser」。咁Claude就會自動揀更快嘅方案。

完整工作流程覆盤

用呢套組合做咗個技術面試模擬App，流程如下：

Claude Code（規劃模式）
    ↓ 輸出UI設計指南
    ↓ 反覆打磨至滿意
Stitch MCP
    ↓ 根據指南生成完整設計
    ↓ 預覽 + 微調
    ↓ 導出HTML/CSS
Claude Code（實現模式）
    ↓ 集成到Next.js
    ↓ 重構為組件化結構
Agent Browser
    ↓ 快照測試全站
    ↓ 發現問題 → 自動修復 → 再測試

成個過程中，我發現一個畀人忽略嘅點：Claude默認會將所有代碼塞入一個檔案。記得要明確要求「按React最佳實踐拆分組件」。

三個相鄰可能

  1. MCP生態正在爆發：Stitch只係開始。當更多設計工具開放MCP，AI agent將會真正成為「全棧設計師」。值得留意Figma、Framer嘅動向。

  2. Accessibility-first嘅開發範式：Agent Browser嘅快照方案暗示咗一個趨勢——未來嘅AI工具會越來越依賴結構化數據而唔係視覺識別。呢個對無障礙設計係好事。

  3. 規劃工程（Planning Engineering）：就好似我哋有Prompt Engineering，將來可能需要專門研究「點樣寫出令AI產出高質量設計嘅規劃文件」。呢個係一個被低估嘅技能。

一句話總結

好嘅AI設計唔係揾到最強嘅工具，而係令啱嘅工具做啱嘅事。

截圖太慢，用快照。 手動太煩，用MCP。 生成太粗，先規劃。

工具組合 × 正確用法 = 效率躍升。

你嘅AI設計流程入面，邊個環節最慢？ 歡迎留言，我哋一齊揾解法。


4分鐘完成全站測試。不是吹牛，是換了個思路。

一個反直覺的發現

我一直以為，AI設計的瓶頸在於"模型不夠聰明"。

直到上週，我用兩個工具的組合，4分鐘跑完了一個完整應用的UI測試——以前至少要20分鐘。

不是模型升級了。是我用錯了方法。

核心洞察：好的AI設計從來不靠單一神器，而是靠"對的工具做對的事"。

今天聊的這套組合，改變了我對AI輔助設計的認知：

  • Google Stitch MCP：讓AI agent直接調用設計工具
  • Vercel Agent Browser：用"快照"替代"截圖"的測試神器

讓AI成為真正的設計助手

Google Stitch最近開放了MCP接口。

這意味着什麼？

以前：你在Stitch裏手動輸入prompt → 生成設計 → 手動導出 → 手動集成到代碼。

現在：Claude Code直接調用Stitch → 自動生成設計 → 自動拉取代碼 → 自動集成。

你不再需要"喂"AI，AI自己會"吃"。

實際體驗中，我讓Claude根據規劃文檔，自動創建Stitch項目、生成landing page、拉取HTML代碼、集成到Next.js——全程我只敲了幾行指令。

立即行動指南

安裝有兩條路：

  1. 官方路徑（穩但繁瑣）：裝Google Cloud SDK → 登錄兩次（用戶+應用）→ 啓用Stitch API → 配置MCP
  2. 非官方簡化版（快但實驗性）：一個第三方stitch-mcp包，一鍵搞定全流程

⚠️ 非官方版目前能用，但隨時可能失效。生產環境建議走官方。

規劃質量 = 設計質量

這是我踩過最大的坑：

直接讓AI生成設計，出來的東西"能用但平庸"。

後來我發現，AI設計的天花板，是你規劃文檔的質量。

我的流程現在是這樣的：

1. Claude Code 規劃模式 → 輸出詳細UI指南
2. 反覆打磨規劃（我改了不下10次）
3. 規劃定稿後，才讓Stitch開始生成

有個細節很關鍵：Stitch默認會把landing page拆成一個個小組件分別生成。這會導致後期集成時風格不統一。

解決方案：明確要求"生成一個完整的長頁面設計"，保持視覺連貫性。

截圖是慢的根源

這是今天最重要的洞察。

Claude的Chrome擴展怎麼測試UI？

  1. 啓動完整瀏覽器
  2. 截屏
  3. 像素級分析
  4. 導航到下一個位置
  5. 再截屏...

每一步都慢，疊加起來就是災難。

Vercel的Agent Browser換了個思路：

它不看"像素"，它看"結構"。

具體來說，它生成的是accessibility tree的快照——一棵標記了所有可交互元素的結構樹。AI通過選擇器直接定位元素，而不是"看圖找按鈕"。

維度
Chrome擴展
Agent Browser
原理
截圖 + 像素分析
快照 + 選擇器定位
速度
慢（每次都要渲染+截圖）
快（直接讀結構）
精度
依賴視覺識別
精確到元素
會話
用你的瀏覽器
獨立Chromium實例

我那個4分鐘測完全站的案例，換成截圖模式至少15分鐘起步。

立即行動指南

# 安裝（全局）
npm install -g @anthropic/agent-browser

# 帶界面運行（方便觀察）
agent-browser --headed

一個小技巧：在claude.md里加一條規則——"所有UI測試使用agent browser"。這樣Claude會自動選擇更快的方案。

完整工作流覆盤

用這套組合做了個技術面試模擬App，流程如下：

Claude Code（規劃模式）
    ↓ 輸出UI設計指南
    ↓ 反覆打磨至滿意
Stitch MCP
    ↓ 根據指南生成完整設計
    ↓ 預覽 + 微調
    ↓ 導出HTML/CSS
Claude Code（實現模式）
    ↓ 集成到Next.js
    ↓ 重構為組件化結構
Agent Browser
    ↓ 快照測試全站
    ↓ 發現問題 → 自動修復 → 再測試

整個過程中，我發現一個被忽視的點：Claude默認會把所有代碼塞進一個文件。記得明確要求"按React最佳實踐拆分組件"。

三個相鄰可能

  1. MCP生態正在爆發：Stitch只是開始。當更多設計工具開放MCP，AI agent將真正成為"全棧設計師"。值得關注Figma、Framer的動向。

  2. Accessibility-first的開發範式：Agent Browser的快照方案暗示了一個趨勢——未來的AI工具會越來越依賴結構化數據而非視覺識別。這對無障礙設計是利好。

  3. 規劃工程（Planning Engineering）：就像我們有Prompt Engineering，未來可能需要專門研究"如何寫出讓AI產出高質量設計的規劃文檔"。這是個被低估的技能。

一句話總結

好的AI設計不是找到最強的工具，而是讓對的工具做對的事。

截圖太慢，用快照。 手動太繁，用MCP。 生成太糙，先規劃。

工具組合 × 正確用法 = 效率躍遷。

你的AI設計流程裏，哪個環節最慢？ 歡迎留言，我們一起找解法。