QA 與 Browse：給 AI 一雙眼睛，讓它真的「看到」你的 app

寫程式有一個很長時間都被忽略的盲點：AI 能寫程式，但看不見程式跑起來的樣子。

你叫 Claude 寫一個登入流程，它寫了，看起來沒問題。你問它「登入頁有沒有正確顯示？」——它沒辦法回答，因為它從來沒打開過瀏覽器，它只看得到程式碼。

這個盲點在前端改動、UI regression、auth flow 這類問題上特別致命——問題不在邏輯，在視覺狀態；問題不在程式碼，在實際執行的結果。

Gstack 的 /browse 和 /qa 就是在修這個盲點。

`/browse`：給 AI 一雙真實的眼睛

/browse 背後是一個持久化的 Chromium daemon，透過 Playwright 控制：

第一次啟動：約 3 秒
後續每個指令：100-200ms 完成（點擊、導航、截圖、填表單）
持久化狀態：cookies、localStorage、開啟的 tabs 在指令之間保留
自動關閉：閒置 30 分鐘後自動 shutdown

跟 Claude for Chrome MCP 相比，Gstack 官方的說法是快 20 倍——原因是架構不同：Gstack 的 browse 是一個獨立的 compiled binary（58MB，用 Bun 編譯），和 Chromium 直接通訊，不走 MCP 的 round-trip。

它能做什麼

/browse https://your-app.com

AI 會打開你的 app，然後你可以叫它：

點進某個頁面、填表單、截圖
確認某個元素有沒有出現
讀 console errors
檢查 network requests

它用的是 accessibility-tree refs（@e1、@e2）來定位元素，不是 CSS selector——所以不會因為你改了 class name 就壞掉，比一般 Playwright script 更 robust。

測試登入後的頁面

很多重要功能在登入牆後面，一般自動化測試要設定帳號密碼、管理 session——很麻煩。Gstack 的解法是：

/setup-browser-cookies

這個指令會開一個互動式 picker，讓你選要從哪個真實瀏覽器（Chrome、Arc、Brave、Edge、Comet）匯入哪些 domain 的 cookies。匯入之後，/browse 和 /qa 就能直接測試你的已登入狀態，不需要重新設定帳密。

Cookie 值在整個過程中不會顯示在畫面上——Keychain 存取需要你明確同意，資料庫以 read-only 模式打開。

`/qa`：不只是看，是找問題、修問題、再驗證

/browse 是「給 AI 眼睛」，/qa 是「讓 AI 用眼睛做完整的 QA 流程」——差別在自動化程度和深度。

Diff-Aware 測試模式（預設）

/qa 預設是 diff-aware 模式：它會先分析你的 git diff，找出這次改動影響了哪些頁面和功能，然後只測那些受影響的部分。

這很重要——如果你的 app 有 50 個頁面，你不想每次改一個 button 就跑完整的 E2E suite。Diff-aware 讓測試範圍跟改動範圍成正比，快很多，也更有針對性。

四種測試模式

Diff-aware（預設）：分析 git diff，只測受影響的頁面
Full exploration：跑整個 app，適合 major release 前的全面檢查
Quick smoke test：快速確認核心流程還是通的
Regression baseline comparison：跟上一個 baseline 比較，找 regression

找到問題之後它自己修

/qa 的完整循環是：

分析 diff，決定要測哪些頁面
開瀏覽器，實際測試每個頁面
發現問題，自動修 bug（atomic commits）
修完，重新測試確認修好了
輸出健康分數（0-100）和測試報告

這個「找到問題自己修」的部分值得多說一下——它不是亂改，它做的是跟 /review 一樣的 diff-aware 分析，修改的是跟問題直接相關的程式碼，每個修改都是獨立的 atomic commit，方便你 review。

你可以在 /qa 跑完之後，看 git log 確認它做了什麼，每個 commit 都有清楚的說明。

`/qa-only`：只看報告，不動程式碼

如果你想要純粹的 bug report——讓 AI 測試完，告訴你有什麼問題，但不要自動修——用 /qa-only。

適合的場景：

你想把 bug report 整理好再分配給團隊成員處理
你對自動修 bug 還沒有足夠信心，想先看看它找到的是什麼

兩個 skill 用同樣的測試邏輯，差別只在最後要不要自動修。

健康分數怎麼解讀

/qa 輸出的 0-100 健康分數，是根據這次測試覆蓋的頁面和功能加權計算的。

大概的參考：

90+：主要流程都沒問題，頂多有幾個小的 UX issue
70-89：有幾個需要關注的問題，但核心功能還是通的
50-69：有 blocking issue，建議在上線前修掉
50 以下：有 critical 問題，不建議上線

分數不是絕對的——它反映的是「Gstack 測試到的範圍內的健康狀況」，不代表 Gstack 沒測到的部分都沒問題。把它當參考指標，不是最終判斷。

為什麼 `/browse` + `/qa` 值得你花時間設定

設定 browser cookies、熟悉指令語法——這些確實需要一點初始投入。但換來的是：

原本需要你手動打開瀏覽器、點十幾個頁面、確認有沒有 regression 的 QA 流程，現在一個指令跑完，你去倒杯咖啡回來看報告。

對獨立開發者來說這個收益特別明顯——你不可能每次都有時間做完整的手動測試，但 /qa 可以在你每次推程式碼之前幫你跑完基礎的 sanity check。

五個篇章的概念都講完了。最後一篇，把所有東西接起來，用一個真實的開發場景示範 Gstack 完整的工作流。

→ 真實開發場景：從新功能到 production 的 Gstack 完整工作流

回到系列總覽

這篇是 Gstack 系列的第五站，聚焦 /qa 與 /browse。完整閱讀路線與其他篇主題，請回到 Gstack 入門課。

/browse：給 AI 一雙真實的眼睛