閉環(huán))
gstack /qa 工作流全解Test → Fix → Verify 的自動化瀏覽器 QA 與缺陷修復(fù)閉環(huán)【免費下載鏈接】gstackUse Garry Tans exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA項目地址: https://gitcode.com/GitHub_Trending/gs/gstack本文以 gstack 倉庫的 qa/SKILL.md 為主體完整拆解 gstack 的 QA 技能從觸發(fā)詞、三檔測試層級Quick / Standard / Exhaustive、四種運行模式diff-aware / Full / Quick / Regression到 11 個階段的 Test → Fix → Verify 工作流、健康分加權(quán)評分標(biāo)準(zhǔn)、缺陷分級分類法、原子提交修復(fù)循環(huán)、回歸測試生成與 WTF-likelihood 自我調(diào)節(jié)機制。讀完你可以理解一個AI QA 工程師如何在真實瀏覽器中像用戶一樣測試 Web 應(yīng)用、為每個修復(fù)做原子提交與前后截圖證據(jù)、并輸出可放入 PR 描述的 ship-readiness 報告。一、技能定位QA 工程師 缺陷修復(fù)工程師的雙重角色gstack 是 Garry Tan 的 Claude Code 工作流配置集其中 23 個技能分別扮演 CEO、設(shè)計師、工程經(jīng)理、發(fā)布經(jīng)理、文檔工程師和 QA 等角色。/qa是其中的 QA 技能其 SKILL.md 頭部qa/SKILL.md聲明了元信息name: qaversion: 2.0.0preamble-tier: 4description: Systematically QA test a web application and fix bugs found. (gstack)允許的工具Bash、Read、Write、Edit、Glob、Grep、AskUserQuestion、WebSearch觸發(fā)詞qa test this、find bugs on site、test the site語音別名包括 quality check、test the app、run QA。技能正文開宗明義qa/SKILL.mdYou are a QA engineer AND a bug-fix engineer. Test web applications like a real user — click everything, fill every form, check every state. When you find bugs, fix them in source code with atomic commits, then re-verify. Produce a structured report with before/after evidence.也就是說/qa不是只測不改的報告工具而是一個完整閉環(huán)測試 → 發(fā)現(xiàn)缺陷 → 源碼級最小修復(fù) → 原子提交 → 瀏覽器復(fù)測驗證 → 結(jié)構(gòu)化報告。如果只需要報告而不修改代碼應(yīng)使用配套的 qa-only 技能just report bugs、test but dont fix 觸發(fā)。二、調(diào)用入口與參數(shù)解析/qa啟動時先解析用戶請求中的 6 個參數(shù)qa/SKILL.md參數(shù)默認(rèn)值覆蓋示例Target URL自動探測或必填https://myapp.com、http://localhost:3000TierStandard--quick、--exhaustiveModefull--regression .gstack/qa-reports/baseline.jsonOutput dir.gstack/qa-reports/Output to /tmp/qaScope全應(yīng)用或 diff 范圍Focus on the billing pageAuthNoneSign in to userexample.com、Import cookies from cookies.json三檔 Tier 直接決定哪些嚴(yán)重級別的缺陷會被修復(fù)Quick只修 critical highStandard再加 medium默認(rèn)檔Exhaustive連 low / 裝飾性問題也一并修。另外有一個自動行為如果用戶沒給 URL 且當(dāng)前在 feature 分支上自動進(jìn)入diff-aware 模式——這是最常見的場景即開發(fā)者剛在分支上寫完代碼想驗證它是否真的能工作。啟動前還有兩項環(huán)境檢查1. CDP 模式檢測——檢查 browse 服務(wù)是否連接到用戶真實瀏覽器$B status 2/dev/null | grep -q Mode: cdp echo CDP_MODEtrue || echo CDP_MODEfalse若CDP_MODEtrue則跳過 cookie 導(dǎo)入提示、跳過 user-agent 覆蓋、跳過無頭檢測補丁——因為真實瀏覽器里已有真實的登錄會話和 user-agent。2. 干凈工作樹檢查——/qa的每個修復(fù)都要獨立原子提交所以要求git status --porcelain輸出非空工作樹臟時立即 STOP 并用 AskUserQuestion 提供三個選項A) 先提交當(dāng)前改動再開始 QA推薦未提交的工作應(yīng)保留為提交B) stash 后 QA 完成再 popC) 中止用戶自行清理。三、browse 二進(jìn)制與測試框架引導(dǎo)3.1 定位 browse 瀏覽器引擎/qa依賴 gstack 的 browse 工具持久化 headless Chromium首次調(diào)用自動啟動約 3 秒之后每條命令約 100mscookie / 標(biāo)簽頁 / 登錄態(tài)在調(diào)用間持久詳見 browse/SKILL.md。定位方式_ROOT$(git rev-parse --show-toplevel 2/dev/null) B [ -n $_ROOT ] [ -x $_ROOT/.claude/skills/gstack/browse/dist/browse ] B$_ROOT/.claude/skills/gstack/browse/dist/browse [ -z $B ] B$HOME/.claude/skills/gstack/browse/dist/browse if [ -x $B ]; then echo READY: $B else echo NEEDS_SETUP fi若為NEEDS_SETUP先征得用戶同意one-time build (~10 seconds)然后cd SKILL_DIR ./setup若機器上沒有bun會下載固定版本 1.3.10 的安裝腳本并校驗 SHA-256bab8acfb046aac8c72407bdcce903957665d655d7acaa3e11c7c4616beae68dd不匹配則報錯退出。這段邏輯與 browse/SKILL.md 的 SETUP 小節(jié)完全一致說明/qa直接復(fù)用了 browse 技能的構(gòu)建路徑。3.2 測試框架引導(dǎo)Test Framework Bootstrap修復(fù)循環(huán)要寫回歸測試所以/qa在 Setup 階段先確認(rèn)項目有沒有可用的測試命令。規(guī)則的核心是證據(jù)不盲跑先讀項目的 CLAUDE.md以及 TESTING.md。如果其中已寫明測試命令直接采用跳過全部檢測與引導(dǎo)。否則運行一組 marker 探測腳本qa/SKILL.md識別運行時生態(tài)與既有測試證據(jù)# Definitive ecosystem markers (presence ecosystem, NOT a command to run) [ -f manage.py ] echo RUNTIME:python FRAMEWORK:django MARKER:manage.py { [ -f pyproject.toml ] || [ -f pytest.ini ] || [ -f tox.ini ] || [ -f setup.cfg ] || [ -f requirements.txt ]; } echo RUNTIME:python [ -f Gemfile ] || [ -f Rakefile ] || [ -f .rspec ] echo RUNTIME:ruby [ -f package.json ] echo RUNTIME:node [ -f go.mod ] echo RUNTIME:go [ -f Cargo.toml ] echo RUNTIME:rust [ -f composer.json ] echo RUNTIME:php [ -f mix.exs ] echo RUNTIME:elixir [ -f pom.xml ] echo RUNTIME:jvm BUILD:maven { [ -f build.gradle ] || [ -f build.gradle.kts ]; } echo RUNTIME:jvm BUILD:gradle # 已有測試路徑配置文件、聲明的腳本、測試文件 ls jest.config.* vitest.config.* playwright.config.* .rspec pytest.ini tox.ini phpunit.xml* 2/dev/null [ -f package.json ] grep -q test[[:space:]]*: package.json echo SCRIPT:package.json test [ -f Makefile ] grep -qE ^(test|check): Makefile echo TARGET:make test git ls-files | grep -cE (^|/)(tests?|spec|__tests__)/|(^|/)tests?\.py$|...|\.(test|spec)\.[jt]sx?$|_spec\.rb$|Test\.(java|kt)$ | sed s/^/TESTFILES:/ # Rust 單元測試在 src/ 內(nèi)部僅靠文件名會漏掉 [ -f Cargo.toml ] git grep -lF #[test] -- src /dev/null 21 echo TESTS:rust in-source # 用戶此前拒絕過引導(dǎo) [ -f .gstack/no-test-bootstrap ] echo BOOTSTRAP_DECLINED文檔特別強調(diào)兩個易錯點marker 只是證據(jù)不是可以盲跑的命令在一個從未用過該 runner 的項目上探測性執(zhí)行會大聲失敗且毫無信息量沒有配置文件不等于沒有測試——Django 的測試在app/tests.py、Go 在*_test.go、Rust 在src/內(nèi)的#[test]塊python manage.py test全綠就是已測試項目絕不引導(dǎo)安裝第二套框架。發(fā)現(xiàn)任何既有測試證據(jù)配置文件、聲明的 test 腳本、TESTFILES:計數(shù)非零、TESTS:rust in-source不引導(dǎo)改為通過 AskUserQuestion 把候選命令給用戶確認(rèn)并持久化到 CLAUDE.md 的## Testing段之后不再詢問再讀 2-3 個既有測試文件學(xué)習(xí)命名、導(dǎo)入、斷言風(fēng)格。完全沒有生態(tài) marker問用戶語言棧Node / Ruby / Python / Go / Rust / PHP / Elixir / 不需要測試。選不需要則寫.gstack/no-test-bootstrap標(biāo)記文件。有生態(tài)但零測試證據(jù) → 執(zhí)行引導(dǎo)步驟 B2–B8B2 研究最佳實踐用 WebSearch 查[runtime] best test framework 2025 2026不可用時回落到內(nèi)置推薦表Ruby/Rails → minitest fixtures capybaraNode.js → vitest testing-libraryNext.js → vitest testing-library/react playwrightPython → pytest pytest-covGo → stdlib testing testifyRust → cargo test mockallPHP → phpunit mockeryElixir → ExUnit ex_machina 等。B3 框架選擇AskUserQuestion 給出 A) 首選方案含理由與包清單、B) 替代方案、C) 跳過。B4 安裝配置裝包、建最小配置、建目錄、寫一個示例測試驗證 setup安裝失敗則調(diào)試一次仍失敗就git checkout --回滾并繼續(xù)無測試流程。B4.5 首批真實測試git log --since30.days --name-only --format | sort | uniq -c | sort -rn | head -10找近期改動文件按風(fēng)險排序錯誤處理器 帶條件分支的業(yè)務(wù)邏輯 API 端點 純函數(shù)每個文件寫一個有真實斷言的測試禁止expect(x).toBeDefined()這類空斷言通過則保留失敗修一次仍失敗就靜默刪除。測試文件里永遠(yuǎn)不引入密鑰與憑證。B5 驗證跑完整測試套件失敗則調(diào)試一次仍失敗回滾全部引導(dǎo)改動。B5.5 CI 流水線檢測.github/等 CI providerGitHub Actions 則生成.github/workflows/test.ymlruns-on: ubuntu-latest、對應(yīng) runtimes 的 setup action、B5 驗證過的測試命令、push pull_request 觸發(fā)非 GitHub CI 則跳過并提示手動添加。B6 寫 TESTING.md哲學(xué)100% test coverage is the key to great vibe coding、框架與版本、已驗證的運行命令、Unit/Integration/Smoke/E2E 分層、命名與 setup/teardown 約定。已存在則更新而非覆蓋。B7 更新 CLAUDE.md追加## Testing段已有則跳過寫明運行命令、目錄以及測試預(yù)期新函數(shù)配測試、修 bug 配回歸測試、加錯誤處理配觸發(fā)該錯誤的測試、加 if/else 時兩條路徑都測、絕不提交讓既有測試變紅的代碼。B8 提交git commit -m chore: bootstrap test framework ({framework name})。最后創(chuàng)建輸出目錄mkdir -p .gstack/qa-reports/screenshots。四、四種運行模式/qa支持四種模式qa/SKILL.mdTier 控制修什么Mode 控制測什么4.1 Diff-aware 模式feature 分支 無 URL 時自動啟用主模式分析分支 diffgit diff main...HEAD --name-only git log main..HEAD --oneline從改動文件反推受影響的頁面/路由controller/route 文件 → 它們服務(wù)的 URL 路徑view/template/component → 渲染它們的頁面model/service → 使用這些 model 的頁面查引用它的 controllerCSS → 引入該樣式表的頁面API 端點 → 直接用$B js await fetch(/api/...)測試靜態(tài)頁面 → 直接導(dǎo)航。若 diff 推不出任何明確頁面不跳過瀏覽器測試——回落到 Quick 模式首頁 頂部 5 個導(dǎo)航目標(biāo) 控制臺錯誤 發(fā)現(xiàn)的交互元素因為后端、配置與基礎(chǔ)設(shè)施改動同樣影響應(yīng)用行為。探測本地運行中的應(yīng)用依次嘗試常見開發(fā)端口$B goto http://localhost:3000 2/dev/null echo Found app on :3000 || \ $B goto http://localhost:4000 2/dev/null echo Found app on :4000 || \ $B goto http://localhost:8080 2/dev/null echo Found app on :8080找不到則查 PR 或環(huán)境里的 staging/preview URL再不行就向用戶要 URL。逐個測試受影響的頁面導(dǎo)航 → 截圖 → 查控制臺 → 交互類改動做端到端驗證 → 操作前后用snapshot -D對比確認(rèn)改動產(chǎn)生了預(yù)期效果。與提交信息、PR 描述交叉驗證意圖——這個改動應(yīng)該做什么驗證它確實做到了。查 TODOS.md若存在與改動文件相關(guān)的已知 bug 納入測試計劃QA 中發(fā)現(xiàn)的 TODOS.md 之外的新 bug 記入報告。報告限定在分支改動范圍內(nèi)Changes tested: N pages/routes affected by this branch每頁給出是否可用 截圖證據(jù) 相鄰頁面回歸檢查。4.2 其余三種模式Full提供 URL 時的默認(rèn)系統(tǒng)性探索訪問所有可達(dá)頁面記錄 5-10 個證據(jù)充分的缺陷產(chǎn)出健康分。耗時 5-15 分鐘視應(yīng)用規(guī)模而定。Quick--quick30 秒冒煙測試。首頁 頂部 5 個導(dǎo)航目標(biāo)檢查能加載有控制臺錯誤有死鏈產(chǎn)出健康分不做詳細(xì)缺陷記錄。Regression--regression baseline跑完整 Full 模式后加載baseline.jsondiff 出哪些修好了、哪些是新增的、分?jǐn)?shù)變化多少把回歸小節(jié)追加進(jìn)報告。五、Phase 1-6QA 基線工作流Phase 1初始化找到 browse 二進(jìn)制、建輸出目錄、把報告模板qa/templates/qa-report-template.md復(fù)制到輸出目錄、啟動計時器。Phase 2認(rèn)證如需用戶給了憑據(jù)時模擬真實登錄$B goto login-url $B snapshot -i # find the login form $B fill e3 userexample.com $B fill e4 [REDACTED] # NEVER include real passwords in report $B click e5 # submit $B snapshot -D # verify login succeeded提供了 cookie 文件則$B cookie-import cookies.json后直達(dá)目標(biāo) URL遇到 2FA/OTP 向用戶要驗證碼并等待遇到 CAPTCHA 則請用戶在瀏覽器里手動完成后通知繼續(xù)。Phase 3定向Orient先拿應(yīng)用地圖$B goto target-url $B snapshot -i -a -o $REPORT_DIR/screenshots/initial.png $B links # map navigation structure $B console --errors # any errors on landing?同時探測前端框架并記入報告元數(shù)據(jù)HTML 里有__next或_next/data請求 → Next.js有csrf-tokenmeta 標(biāo)簽 → RailsURL 含wp-content→ WordPress客戶端路由無整頁刷新 → SPA。SPA 的links命令可能返回很少導(dǎo)航在客戶端完成要改用snapshot -i找導(dǎo)航元素。Phase 4探索Explore逐頁訪問每頁三件套$B goto page-url $B snapshot -i -a -o $REPORT_DIR/screenshots/page-name.png $B console --errors然后執(zhí)行 qa/references/issue-taxonomy.md 定義的逐頁探索清單1) 視覺掃描——看標(biāo)注截圖找布局問題2) 交互元素——點每個按鈕/鏈接/控件是否做了它聲稱的事3) 表單——空提交、非法數(shù)據(jù)、邊界值長文本、特殊字符4) 導(dǎo)航——進(jìn)出路徑、面包屑、后退鍵、深鏈、移動端菜單5) 狀態(tài)——空態(tài)、加載中、錯誤態(tài)、溢出態(tài)6) 控制臺——交互后再跑console --errors7) 響應(yīng)式——移動端視口按需檢查8) 認(rèn)證邊界——登出狀態(tài)、不同角色下行為如何。$B viewport 375x812 $B screenshot $REPORT_DIR/screenshots/page-mobile.png $B viewport 1280x720深度分配原則核心功能首頁、dashboard、checkout、搜索多花時間次要頁面about、terms、privacy少花。Phase 5即時記錄Document發(fā)現(xiàn)即記錄絕不攢批。證據(jù)分兩檔交互類 bug壞流程、死按鈕、表單失敗操作前截圖 → 執(zhí)行操作 → 結(jié)果截圖 →snapshot -D展示變化 → 寫引用截圖的復(fù)現(xiàn)步驟$B screenshot $REPORT_DIR/screenshots/issue-001-step-1.png $B click e5 $B screenshot $REPORT_DIR/screenshots/issue-001-result.png $B snapshot -D靜態(tài) bug錯字、布局問題、缺圖一張標(biāo)注截圖 問題描述$B snapshot -i -a -o $REPORT_DIR/screenshots/issue-002.png每個問題立即按模板格式寫入報告。Phase 6收尾Wrap Up按評分標(biāo)準(zhǔn)下一節(jié)計算健康分2. 寫 Top 3 Things to Fix3. 匯總所有頁面看到的控制臺錯誤4. 更新嚴(yán)重級別計數(shù)表5. 填充報告元數(shù)據(jù)日期、耗時、訪問頁數(shù)、截圖數(shù)、框架6.保存基線baseline.json{ date: YYYY-MM-DD, url: target, healthScore: N, issues: [{ id: ISSUE-001, title: ..., severity: ..., category: ... }], categoryScores: { console: N, links: N } }Regression 模式下再加載基線文件比較分?jǐn)?shù) delta、已修復(fù)項、新增項并追加回歸小節(jié)。六、健康分評分標(biāo)準(zhǔn)Health Score Rubric每個類別先算 0-100 分再加權(quán)平均qa/SKILL.mdConsole權(quán)重 15%0 錯誤 → 1001-3 個錯誤 → 704-10 個 → 4010 個以上 → 10。Links權(quán)重 10%0 死鏈 → 100每個死鏈 -15下限 0。其余六類Visual、Functional、UX、Content、Performance、Accessibility每類從 100 起按發(fā)現(xiàn)扣減——Critical 缺陷 -25、High -15、Medium -8、Low -3每類下限 0。權(quán)重表類別權(quán)重Console15%Links10%Visual10%Functional20%UX15%Performance10%Content5%Accessibility15%最終分score Σ (category_score × weight)。功能正確性Functional 20%權(quán)重最高內(nèi)容權(quán)重最低這個分布體現(xiàn)了用戶能不能用優(yōu)先于文字是否通順的 QA 價值觀。七、缺陷分級與分類法Issue Taxonomyqa/references/issue-taxonomy.md 定義了四級嚴(yán)重度級別定義示例critical阻塞核心工作流、造成數(shù)據(jù)丟失或應(yīng)用崩潰表單提交導(dǎo)致錯誤頁、checkout 流程斷裂、無確認(rèn)即刪除數(shù)據(jù)high主要功能損壞或不可用且無繞行方案搜索返回錯誤結(jié)果、文件上傳靜默失敗、認(rèn)證重定向死循環(huán)medium功能可用但存在明顯問題有繞行方案頁面加載慢5s、缺表單校驗但提交仍可用、僅移動端布局破損low輕微外觀或打磨問題頁腳錯字、1px 對齊問題、hover 狀態(tài)不一致七個類別Visual/UI布局破損、圖片缺失、z-index 錯誤、暗色模式問題等、Functional死鏈、死按鈕、表單校驗缺失、狀態(tài)不持久、競態(tài)條件、UX導(dǎo)航困惑、缺加載指示、500ms 無反饋、破壞性操作無確認(rèn)、死胡同、Content錯字、lorem ipsum 殘留、截斷文本、空態(tài)缺失、Performance3s 加載、布局偏移、單頁 50 請求、阻塞 JS、Console/ErrorsJS 異常、4xx/5xx、CORS、混合內(nèi)容、CSP 違規(guī)、Accessibility缺 alt 文本、表單無標(biāo)簽、鍵盤導(dǎo)航斷裂、焦點陷阱、對比度不足。八、框架特化測試指引SKILL.md 為四類技術(shù)棧給出專項檢查點qa/SKILL.mdNext.js查 hydration 錯誤Hydration failed、Text content did not match監(jiān)控_next/data請求的 404點鏈接做客戶端導(dǎo)航而不是goto才能抓到路由問題動態(tài)內(nèi)容頁查 CLS。Rails查 N1 查詢警告development 模式驗證表單里的 CSRF token測 Turbo/Stimulus 集成——頁面過渡是否順滑flash 消息是否正確出現(xiàn)并消失。WordPress查插件沖突來自不同插件的 JS 錯誤登錄用戶的管理欄可見性測/wp-json/REST 端點查混合內(nèi)容警告WP 上很常見。通用 SPAReact/Vue/Angular用snapshot -i找導(dǎo)航links會漏客戶端路由查陳舊狀態(tài)離開再回來數(shù)據(jù)刷新了嗎測瀏覽器前進(jìn)/后退history 處理對嗎長時間使用后的內(nèi)存泄漏跡象。九、Phase 7-8分診與修復(fù)循環(huán)Phase 7Triage按嚴(yán)重度排序后按 Tier 決定修哪些Quick 只修 critical highStandard 加 mediumExhaustive 全修。凡無法從源碼修復(fù)的問題第三方 widget 的 bug、基礎(chǔ)設(shè)施問題無論 Tier 一律標(biāo)記 deferred。分診后還要針對缺陷所在組件刷新 learnings選一個純字母/連字符的關(guān)鍵詞如checkout-button、signup-form、payment不能帶引號、斜杠、點、冒號、空格~/.claude/skills/gstack/bin/gstack-learnings-search --query your-keyword --limit 5 2/dev/null || true若命中歷史學(xué)習(xí)用一句話說明哪條適用于即將做的修復(fù)沒有命中也照常繼續(xù)——無命中本身就是有用信息。Phase 8Fix Loop每個可修復(fù)問題按嚴(yán)重度順序8a 定位grep 錯誤信息、組件名、路由定義glob 匹配受影響頁面的文件模式只改與該問題直接相關(guān)的文件。8b 最小修復(fù)讀懂上下文后做解決該問題的最小改動不重構(gòu)周邊代碼、不加功能、不順手改進(jìn)無關(guān)的東西。8c 原子提交一個修復(fù)一個提交絕不捆綁git add only-changed-files git commit -m fix(qa): ISSUE-NNN — short description8d 復(fù)測導(dǎo)航回受影響頁面拍 before/after 截圖對查控制臺用snapshot -D確認(rèn)變化符合預(yù)期$B goto affected-url $B screenshot $REPORT_DIR/screenshots/issue-NNN-after.png $B console --errors $B snapshot -D8e 分類verified復(fù)測確認(rèn)修復(fù)且無新錯誤/best-effort已修但無法完全驗證如需特定認(rèn)證態(tài)或外部服務(wù)/reverted檢測到回歸 →git revert HEAD→ 標(biāo)記 deferred。8e.5 回歸測試分類非 verified、或純視覺/CSS 修復(fù)、或無測試框架且用戶拒絕引導(dǎo)時跳過。五步流程研究項目既有測試模式讀 2-3 個離修復(fù)最近的測試文件精確匹配文件命名、導(dǎo)入、斷言風(fēng)格、describe/it 嵌套、setup/teardown——回歸測試要看起來是同一個開發(fā)者寫的。追蹤 bug 代碼路徑后寫測試什么輸入/狀態(tài)觸發(fā)了 bug精確前置條件走了哪條代碼路徑斷在哪一行/哪個條件還有哪些輸入會撞同一條路徑修復(fù)周圍的邊界null、空數(shù)組、邊界值測試必須構(gòu)造觸發(fā) bug 的前置條件、執(zhí)行暴露 bug 的動作、斷言正確行為而不是它渲染了或沒拋異常。并附完整歸因注釋// Regression: ISSUE-NNN — {what broke} // Found by /qa on {YYYY-MM-DD} // Report: .gstack/qa-reports/qa-report-{domain}-{date}.md測試類型決策控制臺錯誤/JS 異常/邏輯 bug → 單元或集成測試表單斷裂/API 失敗/數(shù)據(jù)流 bug → 帶請求/響應(yīng)的集成測試帶 JS 行為的視覺 bug壞下拉、動畫→ 組件測試純 CSS → 跳過靠 QA 重跑兜底。mock 掉全部外部依賴DB、API、Redis、文件系統(tǒng)用自增命名{name}.regression-*.test.{ext}避免沖突。 3.只跑新測試文件{detected test command} {new-test-file}。 4.評估通過 → 提交test(qa): regression test for ISSUE-NNN — {desc}失敗 → 修一次仍失敗刪測試并 defer探索超 2 分鐘 → 跳過并 defer。 5.WTF-likelihood 排除測試提交不計入下面的啟發(fā)式計分。8f 自我調(diào)節(jié)STOP AND EVALUATE每 5 次修復(fù)或任何一次 revert 后計算WTF-LIKELIHOOD: Start at 0% Each revert: 15% Each fix touching 3 files: 5% After fix 15: 1% per additional fix All remaining Low severity: 10% Touching unrelated files: 20%WTF 20% 立即停止向用戶展示已做的工作并詢問是否繼續(xù)。硬上限50 次修復(fù)之后無論還有多少遺留問題都停止。這套機制防止 AI 在長會話里越修越離譜——修復(fù)率失控本身就是回歸風(fēng)險信號。十、Phase 9-11最終驗證、報告與學(xué)習(xí)沉淀Phase 9 Final QA所有修復(fù)完成后對受影響頁面重跑 QA計算最終健康分。若最終分比基線更差顯著 WARN——說明引入了回歸。Phase 10 Report報告雙寫——本地.gstack/qa-reports/qa-report-{domain}-{YYYY-MM-DD}.md文件名用域名 日期如qa-report-myapp-com-2026-03-12.md以及項目作用域的~/.gstack/projects/{slug}/{user}-{branch}-test-outcome-{datetime}.md跨會話上下文。每個問題額外記錄 Fix Statusverified / best-effort / reverted / deferred、Commit SHA、改動文件、before/after 截圖。匯總段給出總?cè)毕輸?shù)、修復(fù)數(shù)verified: X, best-effort: Y, reverted: Z、deferred 數(shù)、健康分 deltabaseline → final以及一行可粘貼進(jìn) PR 的總結(jié)QA found N issues, fixed M, health score X → Y.Phase 11 TODOS.md 更新若倉庫有 TODOS.md新的 deferred bug 按嚴(yán)重度/類別/復(fù)現(xiàn)步驟寫成 TODOTODOS.md 里被本次修掉的條目標(biāo)注 Fixed by /qa on {branch}, {date}。輸出目錄結(jié)構(gòu).gstack/qa-reports/ ├── qa-report-{domain}-{YYYY-MM-DD}.md # 結(jié)構(gòu)化報告 ├── screenshots/ │ ├── initial.png # 落地頁標(biāo)注截圖 │ ├── issue-001-step-1.png # 逐問題證據(jù) │ ├── issue-001-result.png │ ├── issue-001-before.png # 修復(fù)前若已修 │ ├── issue-001-after.png # 修復(fù)后若已修 │ └── ... └── baseline.json # 回歸模式用報告本體由 qa/templates/qa-report-template.md 定義元數(shù)據(jù)表Date/URL/Branch/Commit/PR/Tier/Scope/Duration/訪問頁數(shù)/截圖數(shù)/Framework、Health Score 分類表、Top 3 Things to Fix、Console Health 聚合表錯誤信息/次數(shù)/首次出現(xiàn) URL、按嚴(yán)重度匯總的 Summary 表、每個 ISSUE 的 Severity/Category/URL/描述/帶截圖的復(fù)現(xiàn)步驟、Fixes Applied 表Issue/Fix Status/Commit/Files Changed、Before/After Evidence、Regression Tests 表含 Deferred Tests 的 Precondition/Action/Expected/Why deferred、Ship Readiness 表health score before → after、issues found、fixes applied、deferred與 PR Summary、Regression 對比表。流程結(jié)束前還有學(xué)習(xí)沉淀把本次發(fā)現(xiàn)的非顯而易見的模式、陷阱或架構(gòu)洞見寫入 learningsgstack-learnings-log類型分pattern/pitfall/preference/architecture/tool/operational來源分observed/user-stated/inferred/cross-model置信度 1-10代碼里驗證過的模式 8-9不確定的推斷 4-5用戶明確說出的偏好 10并附上 learning 引用的文件路徑以便后續(xù)陳舊檢測。十一、十二條 QA 鐵律SKILL.md 用 Important Rules 固化了執(zhí)行紀(jì)律qa/SKILL.md這些是理解該技能設(shè)計哲學(xué)的關(guān)鍵復(fù)現(xiàn)就是一切——每個問題至少一張截圖無例外記錄前先驗證——重試一次確認(rèn)可復(fù)現(xiàn)排除偶發(fā)絕不包含憑據(jù)——復(fù)現(xiàn)步驟里密碼一律寫[REDACTED]增量寫入——發(fā)現(xiàn)即追加進(jìn)報告不攢批絕不讀源碼測試階段——像用戶一樣測不是像開發(fā)者一樣測每次交互后查控制臺——不表現(xiàn)為視覺問題的 JS 錯誤也是 bug像用戶一樣測——真實數(shù)據(jù)、完整工作流端到端走一遍深度優(yōu)于廣度——5-10 個有證據(jù)的缺陷好過 20 條含糊描述絕不刪除輸出文件——截圖與報告只增不減這是有意的棘手 UI 用snapshot -C——能發(fā)現(xiàn)可訪問性樹漏掉的 cursor:pointer / onclick / tabindex div對應(yīng) browse 技能的 Core QA Patterns 第 5 條每次截圖后必須用 Read 工具把圖片讀給會話看——否則截圖對用戶不可見responsive產(chǎn)生 3 張就全讀絕不拒絕使用瀏覽器——用戶調(diào) /qa 就是要求基于瀏覽器的測試哪怕 diff 看起來沒有 UI 改動也不得建議用 evals、單測等替代方案。qa 專屬補充規(guī)則11-15干凈工作樹是前置條件臟則 AskUserQuestion 三選一一修復(fù)一提交只在 8e.5 生成回歸測試時改測試——絕不改 CI 配置、絕不改既有測試只新建測試文件回歸就立刻git revert HEAD遵循 WTF-likelihood 啟發(fā)式拿不準(zhǔn)就停下問。十二、測試佐證與延伸閱讀gstack 倉庫用 E2E 測試驗證該技能的行為邊界test/skill-e2e-qa-workflow.test.ts 中qa-quick用例把 qa 目錄拷入臨時工作區(qū)、啟動本地測試服務(wù)器后讓會話讀取qa/SKILL.md并跑 Quick 檔測試跳過 preamble / telemetry 等運維段落直接走 QA 工作流qa-only-no-fix用例則驗證 report-only 路徑——值得注意的是它會專門把 qa/templates/qa-report-template.md 復(fù)制進(jìn)沙箱因為 qa-only 技能引用的正是 qa 目錄下的模板印證了兩個技能共享同一份報告模板資產(chǎn)。另有 test/skill-e2e-qa-bugs.test.ts 專門驗證缺陷發(fā)現(xiàn)行為。延伸資料缺陷分級與逐頁清單qa/references/issue-taxonomy.md報告模板qa/templates/qa-report-template.md瀏覽器引擎全部命令goto/snapshot/fill/click/console/viewport/upload/dialog等browse/SKILL.mdreport-only 變體qa-only/SKILL.md技能模板源文件SKILL.md 由它自動生成勿直接編輯qa/SKILL.md.tmpl小結(jié)gstack 的/qa把測試 → 修復(fù) → 驗證壓進(jìn)一條可執(zhí)行的流程Setup 階段解決瀏覽器引擎、工作樹清潔度與測試命令三個前置問題四種模式覆蓋驗分支diff-aware、全量體檢Full、冒煙Quick和趨勢對比RegressionPhase 1-6 用標(biāo)注截圖 控制臺證據(jù) 加權(quán)健康分建立基線Phase 7-8 在 Tier 約束下做最小修復(fù)、原子提交fix(qa): ISSUE-NNN、before/after 復(fù)測與回歸測試生成并用 WTF-likelihood 計分和 50 次硬上限給 AI 修復(fù)行為上保險Phase 9-11 重跑驗證、雙寫報告、回寫 TODOS.md最終產(chǎn)出一行可直接進(jìn) PR 的 QA found N issues, fixed M, health score X → Y。整條鏈路的設(shè)計重心非常清晰每個結(jié)論都要有截圖與控制臺證據(jù)每個修復(fù)都要有獨立提交與復(fù)測每個循環(huán)都要有自我剎車?！久赓M下載鏈接】gstackUse Garry Tans exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA項目地址: https://gitcode.com/GitHub_Trending/gs/gstack創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 gstack /qa 工作流全解：Test → Fix → Verify 的自動化瀏覽器 QA 與缺陷修復(fù)閉環(huán)
gstack /qa 工作流全解Test → Fix → Verify 的自動化瀏覽器 QA 與缺陷修復(fù)閉環(huán)【免費下載鏈接】gstackUse Garry Tans exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA項目地址: https://gitcode.com/GitHub_Trending/gs/gstack本文以 gstack 倉庫的 qa/SKILL.md 為主體完整拆解 gstack 的 QA 技能從觸發(fā)詞、三檔測試層級Quick / Standard / Exhaustive、四種運行模式diff-aware / Full / Quick / Regression到 11 個階段的 Test → Fix → Verify 工作流、健康分加權(quán)評分標(biāo)準(zhǔn)、缺陷分級分類法、原子提交修復(fù)循環(huán)、回歸測試生成與 WTF-likelihood 自我調(diào)節(jié)機制。讀完你可以理解一個AI QA 工程師如何在真實瀏覽器中像用戶一樣測試 Web 應(yīng)用、為每個修復(fù)做原子提交與前后截圖證據(jù)、并輸出可放入 PR 描述的 ship-readiness 報告。一、技能定位QA 工程師 缺陷修復(fù)工程師的雙重角色gstack 是 Garry Tan 的 Claude Code 工作流配置集其中 23 個技能分別扮演 CEO、設(shè)計師、工程經(jīng)理、發(fā)布經(jīng)理、文檔工程師和 QA 等角色。/qa是其中的 QA 技能其 SKILL.md 頭部qa/SKILL.md聲明了元信息name: qaversion: 2.0.0preamble-tier: 4description: Systematically QA test a web application and fix bugs found. (gstack)允許的工具Bash、Read、Write、Edit、Glob、Grep、AskUserQuestion、WebSearch觸發(fā)詞qa test this、find bugs on site、test the site語音別名包括 quality check、test the app、run QA。技能正文開宗明義qa/SKILL.mdYou are a QA engineer AND a bug-fix engineer. Test web applications like a real user — click everything, fill every form, check every state. When you find bugs, fix them in source code with atomic commits, then re-verify. Produce a structured report with before/after evidence.也就是說/qa不是只測不改的報告工具而是一個完整閉環(huán)測試 → 發(fā)現(xiàn)缺陷 → 源碼級最小修復(fù) → 原子提交 → 瀏覽器復(fù)測驗證 → 結(jié)構(gòu)化報告。如果只需要報告而不修改代碼應(yīng)使用配套的 qa-only 技能just report bugs、test but dont fix 觸發(fā)。二、調(diào)用入口與參數(shù)解析/qa啟動時先解析用戶請求中的 6 個參數(shù)qa/SKILL.md參數(shù)默認(rèn)值覆蓋示例Target URL自動探測或必填https://myapp.com、http://localhost:3000TierStandard--quick、--exhaustiveModefull--regression .gstack/qa-reports/baseline.jsonOutput dir.gstack/qa-reports/Output to /tmp/qaScope全應(yīng)用或 diff 范圍Focus on the billing pageAuthNoneSign in to userexample.com、Import cookies from cookies.json三檔 Tier 直接決定哪些嚴(yán)重級別的缺陷會被修復(fù)Quick只修 critical highStandard再加 medium默認(rèn)檔Exhaustive連 low / 裝飾性問題也一并修。另外有一個自動行為如果用戶沒給 URL 且當(dāng)前在 feature 分支上自動進(jìn)入diff-aware 模式——這是最常見的場景即開發(fā)者剛在分支上寫完代碼想驗證它是否真的能工作。啟動前還有兩項環(huán)境檢查1. CDP 模式檢測——檢查 browse 服務(wù)是否連接到用戶真實瀏覽器$B status 2/dev/null | grep -q Mode: cdp echo CDP_MODEtrue || echo CDP_MODEfalse若CDP_MODEtrue則跳過 cookie 導(dǎo)入提示、跳過 user-agent 覆蓋、跳過無頭檢測補丁——因為真實瀏覽器里已有真實的登錄會話和 user-agent。2. 干凈工作樹檢查——/qa的每個修復(fù)都要獨立原子提交所以要求git status --porcelain輸出非空工作樹臟時立即 STOP 并用 AskUserQuestion 提供三個選項A) 先提交當(dāng)前改動再開始 QA推薦未提交的工作應(yīng)保留為提交B) stash 后 QA 完成再 popC) 中止用戶自行清理。三、browse 二進(jìn)制與測試框架引導(dǎo)3.1 定位 browse 瀏覽器引擎/qa依賴 gstack 的 browse 工具持久化 headless Chromium首次調(diào)用自動啟動約 3 秒之后每條命令約 100mscookie / 標(biāo)簽頁 / 登錄態(tài)在調(diào)用間持久詳見 browse/SKILL.md。定位方式_ROOT$(git rev-parse --show-toplevel 2/dev/null) B [ -n $_ROOT ] [ -x $_ROOT/.claude/skills/gstack/browse/dist/browse ] B$_ROOT/.claude/skills/gstack/browse/dist/browse [ -z $B ] B$HOME/.claude/skills/gstack/browse/dist/browse if [ -x $B ]; then echo READY: $B else echo NEEDS_SETUP fi若為NEEDS_SETUP先征得用戶同意one-time build (~10 seconds)然后cd SKILL_DIR ./setup若機器上沒有bun會下載固定版本 1.3.10 的安裝腳本并校驗 SHA-256bab8acfb046aac8c72407bdcce903957665d655d7acaa3e11c7c4616beae68dd不匹配則報錯退出。這段邏輯與 browse/SKILL.md 的 SETUP 小節(jié)完全一致說明/qa直接復(fù)用了 browse 技能的構(gòu)建路徑。3.2 測試框架引導(dǎo)Test Framework Bootstrap修復(fù)循環(huán)要寫回歸測試所以/qa在 Setup 階段先確認(rèn)項目有沒有可用的測試命令。規(guī)則的核心是證據(jù)不盲跑先讀項目的 CLAUDE.md以及 TESTING.md。如果其中已寫明測試命令直接采用跳過全部檢測與引導(dǎo)。否則運行一組 marker 探測腳本qa/SKILL.md識別運行時生態(tài)與既有測試證據(jù)# Definitive ecosystem markers (presence ecosystem, NOT a command to run) [ -f manage.py ] echo RUNTIME:python FRAMEWORK:django MARKER:manage.py { [ -f pyproject.toml ] || [ -f pytest.ini ] || [ -f tox.ini ] || [ -f setup.cfg ] || [ -f requirements.txt ]; } echo RUNTIME:python [ -f Gemfile ] || [ -f Rakefile ] || [ -f .rspec ] echo RUNTIME:ruby [ -f package.json ] echo RUNTIME:node [ -f go.mod ] echo RUNTIME:go [ -f Cargo.toml ] echo RUNTIME:rust [ -f composer.json ] echo RUNTIME:php [ -f mix.exs ] echo RUNTIME:elixir [ -f pom.xml ] echo RUNTIME:jvm BUILD:maven { [ -f build.gradle ] || [ -f build.gradle.kts ]; } echo RUNTIME:jvm BUILD:gradle # 已有測試路徑配置文件、聲明的腳本、測試文件 ls jest.config.* vitest.config.* playwright.config.* .rspec pytest.ini tox.ini phpunit.xml* 2/dev/null [ -f package.json ] grep -q test[[:space:]]*: package.json echo SCRIPT:package.json test [ -f Makefile ] grep -qE ^(test|check): Makefile echo TARGET:make test git ls-files | grep -cE (^|/)(tests?|spec|__tests__)/|(^|/)tests?\.py$|...|\.(test|spec)\.[jt]sx?$|_spec\.rb$|Test\.(java|kt)$ | sed s/^/TESTFILES:/ # Rust 單元測試在 src/ 內(nèi)部僅靠文件名會漏掉 [ -f Cargo.toml ] git grep -lF #[test] -- src /dev/null 21 echo TESTS:rust in-source # 用戶此前拒絕過引導(dǎo) [ -f .gstack/no-test-bootstrap ] echo BOOTSTRAP_DECLINED文檔特別強調(diào)兩個易錯點marker 只是證據(jù)不是可以盲跑的命令在一個從未用過該 runner 的項目上探測性執(zhí)行會大聲失敗且毫無信息量沒有配置文件不等于沒有測試——Django 的測試在app/tests.py、Go 在*_test.go、Rust 在src/內(nèi)的#[test]塊python manage.py test全綠就是已測試項目絕不引導(dǎo)安裝第二套框架。發(fā)現(xiàn)任何既有測試證據(jù)配置文件、聲明的 test 腳本、TESTFILES:計數(shù)非零、TESTS:rust in-source不引導(dǎo)改為通過 AskUserQuestion 把候選命令給用戶確認(rèn)并持久化到 CLAUDE.md 的## Testing段之后不再詢問再讀 2-3 個既有測試文件學(xué)習(xí)命名、導(dǎo)入、斷言風(fēng)格。完全沒有生態(tài) marker問用戶語言棧Node / Ruby / Python / Go / Rust / PHP / Elixir / 不需要測試。選不需要則寫.gstack/no-test-bootstrap標(biāo)記文件。有生態(tài)但零測試證據(jù) → 執(zhí)行引導(dǎo)步驟 B2–B8B2 研究最佳實踐用 WebSearch 查[runtime] best test framework 2025 2026不可用時回落到內(nèi)置推薦表Ruby/Rails → minitest fixtures capybaraNode.js → vitest testing-libraryNext.js → vitest testing-library/react playwrightPython → pytest pytest-covGo → stdlib testing testifyRust → cargo test mockallPHP → phpunit mockeryElixir → ExUnit ex_machina 等。B3 框架選擇AskUserQuestion 給出 A) 首選方案含理由與包清單、B) 替代方案、C) 跳過。B4 安裝配置裝包、建最小配置、建目錄、寫一個示例測試驗證 setup安裝失敗則調(diào)試一次仍失敗就git checkout --回滾并繼續(xù)無測試流程。B4.5 首批真實測試git log --since30.days --name-only --format | sort | uniq -c | sort -rn | head -10找近期改動文件按風(fēng)險排序錯誤處理器 帶條件分支的業(yè)務(wù)邏輯 API 端點 純函數(shù)每個文件寫一個有真實斷言的測試禁止expect(x).toBeDefined()這類空斷言通過則保留失敗修一次仍失敗就靜默刪除。測試文件里永遠(yuǎn)不引入密鑰與憑證。B5 驗證跑完整測試套件失敗則調(diào)試一次仍失敗回滾全部引導(dǎo)改動。B5.5 CI 流水線檢測.github/等 CI providerGitHub Actions 則生成.github/workflows/test.ymlruns-on: ubuntu-latest、對應(yīng) runtimes 的 setup action、B5 驗證過的測試命令、push pull_request 觸發(fā)非 GitHub CI 則跳過并提示手動添加。B6 寫 TESTING.md哲學(xué)100% test coverage is the key to great vibe coding、框架與版本、已驗證的運行命令、Unit/Integration/Smoke/E2E 分層、命名與 setup/teardown 約定。已存在則更新而非覆蓋。B7 更新 CLAUDE.md追加## Testing段已有則跳過寫明運行命令、目錄以及測試預(yù)期新函數(shù)配測試、修 bug 配回歸測試、加錯誤處理配觸發(fā)該錯誤的測試、加 if/else 時兩條路徑都測、絕不提交讓既有測試變紅的代碼。B8 提交git commit -m chore: bootstrap test framework ({framework name})。最后創(chuàng)建輸出目錄mkdir -p .gstack/qa-reports/screenshots。四、四種運行模式/qa支持四種模式qa/SKILL.mdTier 控制修什么Mode 控制測什么4.1 Diff-aware 模式feature 分支 無 URL 時自動啟用主模式分析分支 diffgit diff main...HEAD --name-only git log main..HEAD --oneline從改動文件反推受影響的頁面/路由controller/route 文件 → 它們服務(wù)的 URL 路徑view/template/component → 渲染它們的頁面model/service → 使用這些 model 的頁面查引用它的 controllerCSS → 引入該樣式表的頁面API 端點 → 直接用$B js await fetch(/api/...)測試靜態(tài)頁面 → 直接導(dǎo)航。若 diff 推不出任何明確頁面不跳過瀏覽器測試——回落到 Quick 模式首頁 頂部 5 個導(dǎo)航目標(biāo) 控制臺錯誤 發(fā)現(xiàn)的交互元素因為后端、配置與基礎(chǔ)設(shè)施改動同樣影響應(yīng)用行為。探測本地運行中的應(yīng)用依次嘗試常見開發(fā)端口$B goto http://localhost:3000 2/dev/null echo Found app on :3000 || \ $B goto http://localhost:4000 2/dev/null echo Found app on :4000 || \ $B goto http://localhost:8080 2/dev/null echo Found app on :8080找不到則查 PR 或環(huán)境里的 staging/preview URL再不行就向用戶要 URL。逐個測試受影響的頁面導(dǎo)航 → 截圖 → 查控制臺 → 交互類改動做端到端驗證 → 操作前后用snapshot -D對比確認(rèn)改動產(chǎn)生了預(yù)期效果。與提交信息、PR 描述交叉驗證意圖——這個改動應(yīng)該做什么驗證它確實做到了。查 TODOS.md若存在與改動文件相關(guān)的已知 bug 納入測試計劃QA 中發(fā)現(xiàn)的 TODOS.md 之外的新 bug 記入報告。報告限定在分支改動范圍內(nèi)Changes tested: N pages/routes affected by this branch每頁給出是否可用 截圖證據(jù) 相鄰頁面回歸檢查。4.2 其余三種模式Full提供 URL 時的默認(rèn)系統(tǒng)性探索訪問所有可達(dá)頁面記錄 5-10 個證據(jù)充分的缺陷產(chǎn)出健康分。耗時 5-15 分鐘視應(yīng)用規(guī)模而定。Quick--quick30 秒冒煙測試。首頁 頂部 5 個導(dǎo)航目標(biāo)檢查能加載有控制臺錯誤有死鏈產(chǎn)出健康分不做詳細(xì)缺陷記錄。Regression--regression baseline跑完整 Full 模式后加載baseline.jsondiff 出哪些修好了、哪些是新增的、分?jǐn)?shù)變化多少把回歸小節(jié)追加進(jìn)報告。五、Phase 1-6QA 基線工作流Phase 1初始化找到 browse 二進(jìn)制、建輸出目錄、把報告模板qa/templates/qa-report-template.md復(fù)制到輸出目錄、啟動計時器。Phase 2認(rèn)證如需用戶給了憑據(jù)時模擬真實登錄$B goto login-url $B snapshot -i # find the login form $B fill e3 userexample.com $B fill e4 [REDACTED] # NEVER include real passwords in report $B click e5 # submit $B snapshot -D # verify login succeeded提供了 cookie 文件則$B cookie-import cookies.json后直達(dá)目標(biāo) URL遇到 2FA/OTP 向用戶要驗證碼并等待遇到 CAPTCHA 則請用戶在瀏覽器里手動完成后通知繼續(xù)。Phase 3定向Orient先拿應(yīng)用地圖$B goto target-url $B snapshot -i -a -o $REPORT_DIR/screenshots/initial.png $B links # map navigation structure $B console --errors # any errors on landing?同時探測前端框架并記入報告元數(shù)據(jù)HTML 里有__next或_next/data請求 → Next.js有csrf-tokenmeta 標(biāo)簽 → RailsURL 含wp-content→ WordPress客戶端路由無整頁刷新 → SPA。SPA 的links命令可能返回很少導(dǎo)航在客戶端完成要改用snapshot -i找導(dǎo)航元素。Phase 4探索Explore逐頁訪問每頁三件套$B goto page-url $B snapshot -i -a -o $REPORT_DIR/screenshots/page-name.png $B console --errors然后執(zhí)行 qa/references/issue-taxonomy.md 定義的逐頁探索清單1) 視覺掃描——看標(biāo)注截圖找布局問題2) 交互元素——點每個按鈕/鏈接/控件是否做了它聲稱的事3) 表單——空提交、非法數(shù)據(jù)、邊界值長文本、特殊字符4) 導(dǎo)航——進(jìn)出路徑、面包屑、后退鍵、深鏈、移動端菜單5) 狀態(tài)——空態(tài)、加載中、錯誤態(tài)、溢出態(tài)6) 控制臺——交互后再跑console --errors7) 響應(yīng)式——移動端視口按需檢查8) 認(rèn)證邊界——登出狀態(tài)、不同角色下行為如何。$B viewport 375x812 $B screenshot $REPORT_DIR/screenshots/page-mobile.png $B viewport 1280x720深度分配原則核心功能首頁、dashboard、checkout、搜索多花時間次要頁面about、terms、privacy少花。Phase 5即時記錄Document發(fā)現(xiàn)即記錄絕不攢批。證據(jù)分兩檔交互類 bug壞流程、死按鈕、表單失敗操作前截圖 → 執(zhí)行操作 → 結(jié)果截圖 →snapshot -D展示變化 → 寫引用截圖的復(fù)現(xiàn)步驟$B screenshot $REPORT_DIR/screenshots/issue-001-step-1.png $B click e5 $B screenshot $REPORT_DIR/screenshots/issue-001-result.png $B snapshot -D靜態(tài) bug錯字、布局問題、缺圖一張標(biāo)注截圖 問題描述$B snapshot -i -a -o $REPORT_DIR/screenshots/issue-002.png每個問題立即按模板格式寫入報告。Phase 6收尾Wrap Up按評分標(biāo)準(zhǔn)下一節(jié)計算健康分2. 寫 Top 3 Things to Fix3. 匯總所有頁面看到的控制臺錯誤4. 更新嚴(yán)重級別計數(shù)表5. 填充報告元數(shù)據(jù)日期、耗時、訪問頁數(shù)、截圖數(shù)、框架6.保存基線baseline.json{ date: YYYY-MM-DD, url: target, healthScore: N, issues: [{ id: ISSUE-001, title: ..., severity: ..., category: ... }], categoryScores: { console: N, links: N } }Regression 模式下再加載基線文件比較分?jǐn)?shù) delta、已修復(fù)項、新增項并追加回歸小節(jié)。六、健康分評分標(biāo)準(zhǔn)Health Score Rubric每個類別先算 0-100 分再加權(quán)平均qa/SKILL.mdConsole權(quán)重 15%0 錯誤 → 1001-3 個錯誤 → 704-10 個 → 4010 個以上 → 10。Links權(quán)重 10%0 死鏈 → 100每個死鏈 -15下限 0。其余六類Visual、Functional、UX、Content、Performance、Accessibility每類從 100 起按發(fā)現(xiàn)扣減——Critical 缺陷 -25、High -15、Medium -8、Low -3每類下限 0。權(quán)重表類別權(quán)重Console15%Links10%Visual10%Functional20%UX15%Performance10%Content5%Accessibility15%最終分score Σ (category_score × weight)。功能正確性Functional 20%權(quán)重最高內(nèi)容權(quán)重最低這個分布體現(xiàn)了用戶能不能用優(yōu)先于文字是否通順的 QA 價值觀。七、缺陷分級與分類法Issue Taxonomyqa/references/issue-taxonomy.md 定義了四級嚴(yán)重度級別定義示例critical阻塞核心工作流、造成數(shù)據(jù)丟失或應(yīng)用崩潰表單提交導(dǎo)致錯誤頁、checkout 流程斷裂、無確認(rèn)即刪除數(shù)據(jù)high主要功能損壞或不可用且無繞行方案搜索返回錯誤結(jié)果、文件上傳靜默失敗、認(rèn)證重定向死循環(huán)medium功能可用但存在明顯問題有繞行方案頁面加載慢5s、缺表單校驗但提交仍可用、僅移動端布局破損low輕微外觀或打磨問題頁腳錯字、1px 對齊問題、hover 狀態(tài)不一致七個類別Visual/UI布局破損、圖片缺失、z-index 錯誤、暗色模式問題等、Functional死鏈、死按鈕、表單校驗缺失、狀態(tài)不持久、競態(tài)條件、UX導(dǎo)航困惑、缺加載指示、500ms 無反饋、破壞性操作無確認(rèn)、死胡同、Content錯字、lorem ipsum 殘留、截斷文本、空態(tài)缺失、Performance3s 加載、布局偏移、單頁 50 請求、阻塞 JS、Console/ErrorsJS 異常、4xx/5xx、CORS、混合內(nèi)容、CSP 違規(guī)、Accessibility缺 alt 文本、表單無標(biāo)簽、鍵盤導(dǎo)航斷裂、焦點陷阱、對比度不足。八、框架特化測試指引SKILL.md 為四類技術(shù)棧給出專項檢查點qa/SKILL.mdNext.js查 hydration 錯誤Hydration failed、Text content did not match監(jiān)控_next/data請求的 404點鏈接做客戶端導(dǎo)航而不是goto才能抓到路由問題動態(tài)內(nèi)容頁查 CLS。Rails查 N1 查詢警告development 模式驗證表單里的 CSRF token測 Turbo/Stimulus 集成——頁面過渡是否順滑flash 消息是否正確出現(xiàn)并消失。WordPress查插件沖突來自不同插件的 JS 錯誤登錄用戶的管理欄可見性測/wp-json/REST 端點查混合內(nèi)容警告WP 上很常見。通用 SPAReact/Vue/Angular用snapshot -i找導(dǎo)航links會漏客戶端路由查陳舊狀態(tài)離開再回來數(shù)據(jù)刷新了嗎測瀏覽器前進(jìn)/后退history 處理對嗎長時間使用后的內(nèi)存泄漏跡象。九、Phase 7-8分診與修復(fù)循環(huán)Phase 7Triage按嚴(yán)重度排序后按 Tier 決定修哪些Quick 只修 critical highStandard 加 mediumExhaustive 全修。凡無法從源碼修復(fù)的問題第三方 widget 的 bug、基礎(chǔ)設(shè)施問題無論 Tier 一律標(biāo)記 deferred。分診后還要針對缺陷所在組件刷新 learnings選一個純字母/連字符的關(guān)鍵詞如checkout-button、signup-form、payment不能帶引號、斜杠、點、冒號、空格~/.claude/skills/gstack/bin/gstack-learnings-search --query your-keyword --limit 5 2/dev/null || true若命中歷史學(xué)習(xí)用一句話說明哪條適用于即將做的修復(fù)沒有命中也照常繼續(xù)——無命中本身就是有用信息。Phase 8Fix Loop每個可修復(fù)問題按嚴(yán)重度順序8a 定位grep 錯誤信息、組件名、路由定義glob 匹配受影響頁面的文件模式只改與該問題直接相關(guān)的文件。8b 最小修復(fù)讀懂上下文后做解決該問題的最小改動不重構(gòu)周邊代碼、不加功能、不順手改進(jìn)無關(guān)的東西。8c 原子提交一個修復(fù)一個提交絕不捆綁git add only-changed-files git commit -m fix(qa): ISSUE-NNN — short description8d 復(fù)測導(dǎo)航回受影響頁面拍 before/after 截圖對查控制臺用snapshot -D確認(rèn)變化符合預(yù)期$B goto affected-url $B screenshot $REPORT_DIR/screenshots/issue-NNN-after.png $B console --errors $B snapshot -D8e 分類verified復(fù)測確認(rèn)修復(fù)且無新錯誤/best-effort已修但無法完全驗證如需特定認(rèn)證態(tài)或外部服務(wù)/reverted檢測到回歸 →git revert HEAD→ 標(biāo)記 deferred。8e.5 回歸測試分類非 verified、或純視覺/CSS 修復(fù)、或無測試框架且用戶拒絕引導(dǎo)時跳過。五步流程研究項目既有測試模式讀 2-3 個離修復(fù)最近的測試文件精確匹配文件命名、導(dǎo)入、斷言風(fēng)格、describe/it 嵌套、setup/teardown——回歸測試要看起來是同一個開發(fā)者寫的。追蹤 bug 代碼路徑后寫測試什么輸入/狀態(tài)觸發(fā)了 bug精確前置條件走了哪條代碼路徑斷在哪一行/哪個條件還有哪些輸入會撞同一條路徑修復(fù)周圍的邊界null、空數(shù)組、邊界值測試必須構(gòu)造觸發(fā) bug 的前置條件、執(zhí)行暴露 bug 的動作、斷言正確行為而不是它渲染了或沒拋異常。并附完整歸因注釋// Regression: ISSUE-NNN — {what broke} // Found by /qa on {YYYY-MM-DD} // Report: .gstack/qa-reports/qa-report-{domain}-{date}.md測試類型決策控制臺錯誤/JS 異常/邏輯 bug → 單元或集成測試表單斷裂/API 失敗/數(shù)據(jù)流 bug → 帶請求/響應(yīng)的集成測試帶 JS 行為的視覺 bug壞下拉、動畫→ 組件測試純 CSS → 跳過靠 QA 重跑兜底。mock 掉全部外部依賴DB、API、Redis、文件系統(tǒng)用自增命名{name}.regression-*.test.{ext}避免沖突。 3.只跑新測試文件{detected test command} {new-test-file}。 4.評估通過 → 提交test(qa): regression test for ISSUE-NNN — {desc}失敗 → 修一次仍失敗刪測試并 defer探索超 2 分鐘 → 跳過并 defer。 5.WTF-likelihood 排除測試提交不計入下面的啟發(fā)式計分。8f 自我調(diào)節(jié)STOP AND EVALUATE每 5 次修復(fù)或任何一次 revert 后計算WTF-LIKELIHOOD: Start at 0% Each revert: 15% Each fix touching 3 files: 5% After fix 15: 1% per additional fix All remaining Low severity: 10% Touching unrelated files: 20%WTF 20% 立即停止向用戶展示已做的工作并詢問是否繼續(xù)。硬上限50 次修復(fù)之后無論還有多少遺留問題都停止。這套機制防止 AI 在長會話里越修越離譜——修復(fù)率失控本身就是回歸風(fēng)險信號。十、Phase 9-11最終驗證、報告與學(xué)習(xí)沉淀Phase 9 Final QA所有修復(fù)完成后對受影響頁面重跑 QA計算最終健康分。若最終分比基線更差顯著 WARN——說明引入了回歸。Phase 10 Report報告雙寫——本地.gstack/qa-reports/qa-report-{domain}-{YYYY-MM-DD}.md文件名用域名 日期如qa-report-myapp-com-2026-03-12.md以及項目作用域的~/.gstack/projects/{slug}/{user}-{branch}-test-outcome-{datetime}.md跨會話上下文。每個問題額外記錄 Fix Statusverified / best-effort / reverted / deferred、Commit SHA、改動文件、before/after 截圖。匯總段給出總?cè)毕輸?shù)、修復(fù)數(shù)verified: X, best-effort: Y, reverted: Z、deferred 數(shù)、健康分 deltabaseline → final以及一行可粘貼進(jìn) PR 的總結(jié)QA found N issues, fixed M, health score X → Y.Phase 11 TODOS.md 更新若倉庫有 TODOS.md新的 deferred bug 按嚴(yán)重度/類別/復(fù)現(xiàn)步驟寫成 TODOTODOS.md 里被本次修掉的條目標(biāo)注 Fixed by /qa on {branch}, {date}。輸出目錄結(jié)構(gòu).gstack/qa-reports/ ├── qa-report-{domain}-{YYYY-MM-DD}.md # 結(jié)構(gòu)化報告 ├── screenshots/ │ ├── initial.png # 落地頁標(biāo)注截圖 │ ├── issue-001-step-1.png # 逐問題證據(jù) │ ├── issue-001-result.png │ ├── issue-001-before.png # 修復(fù)前若已修 │ ├── issue-001-after.png # 修復(fù)后若已修 │ └── ... └── baseline.json # 回歸模式用報告本體由 qa/templates/qa-report-template.md 定義元數(shù)據(jù)表Date/URL/Branch/Commit/PR/Tier/Scope/Duration/訪問頁數(shù)/截圖數(shù)/Framework、Health Score 分類表、Top 3 Things to Fix、Console Health 聚合表錯誤信息/次數(shù)/首次出現(xiàn) URL、按嚴(yán)重度匯總的 Summary 表、每個 ISSUE 的 Severity/Category/URL/描述/帶截圖的復(fù)現(xiàn)步驟、Fixes Applied 表Issue/Fix Status/Commit/Files Changed、Before/After Evidence、Regression Tests 表含 Deferred Tests 的 Precondition/Action/Expected/Why deferred、Ship Readiness 表health score before → after、issues found、fixes applied、deferred與 PR Summary、Regression 對比表。流程結(jié)束前還有學(xué)習(xí)沉淀把本次發(fā)現(xiàn)的非顯而易見的模式、陷阱或架構(gòu)洞見寫入 learningsgstack-learnings-log類型分pattern/pitfall/preference/architecture/tool/operational來源分observed/user-stated/inferred/cross-model置信度 1-10代碼里驗證過的模式 8-9不確定的推斷 4-5用戶明確說出的偏好 10并附上 learning 引用的文件路徑以便后續(xù)陳舊檢測。十一、十二條 QA 鐵律SKILL.md 用 Important Rules 固化了執(zhí)行紀(jì)律qa/SKILL.md這些是理解該技能設(shè)計哲學(xué)的關(guān)鍵復(fù)現(xiàn)就是一切——每個問題至少一張截圖無例外記錄前先驗證——重試一次確認(rèn)可復(fù)現(xiàn)排除偶發(fā)絕不包含憑據(jù)——復(fù)現(xiàn)步驟里密碼一律寫[REDACTED]增量寫入——發(fā)現(xiàn)即追加進(jìn)報告不攢批絕不讀源碼測試階段——像用戶一樣測不是像開發(fā)者一樣測每次交互后查控制臺——不表現(xiàn)為視覺問題的 JS 錯誤也是 bug像用戶一樣測——真實數(shù)據(jù)、完整工作流端到端走一遍深度優(yōu)于廣度——5-10 個有證據(jù)的缺陷好過 20 條含糊描述絕不刪除輸出文件——截圖與報告只增不減這是有意的棘手 UI 用snapshot -C——能發(fā)現(xiàn)可訪問性樹漏掉的 cursor:pointer / onclick / tabindex div對應(yīng) browse 技能的 Core QA Patterns 第 5 條每次截圖后必須用 Read 工具把圖片讀給會話看——否則截圖對用戶不可見responsive產(chǎn)生 3 張就全讀絕不拒絕使用瀏覽器——用戶調(diào) /qa 就是要求基于瀏覽器的測試哪怕 diff 看起來沒有 UI 改動也不得建議用 evals、單測等替代方案。qa 專屬補充規(guī)則11-15干凈工作樹是前置條件臟則 AskUserQuestion 三選一一修復(fù)一提交只在 8e.5 生成回歸測試時改測試——絕不改 CI 配置、絕不改既有測試只新建測試文件回歸就立刻git revert HEAD遵循 WTF-likelihood 啟發(fā)式拿不準(zhǔn)就停下問。十二、測試佐證與延伸閱讀gstack 倉庫用 E2E 測試驗證該技能的行為邊界test/skill-e2e-qa-workflow.test.ts 中qa-quick用例把 qa 目錄拷入臨時工作區(qū)、啟動本地測試服務(wù)器后讓會話讀取qa/SKILL.md并跑 Quick 檔測試跳過 preamble / telemetry 等運維段落直接走 QA 工作流qa-only-no-fix用例則驗證 report-only 路徑——值得注意的是它會專門把 qa/templates/qa-report-template.md 復(fù)制進(jìn)沙箱因為 qa-only 技能引用的正是 qa 目錄下的模板印證了兩個技能共享同一份報告模板資產(chǎn)。另有 test/skill-e2e-qa-bugs.test.ts 專門驗證缺陷發(fā)現(xiàn)行為。延伸資料缺陷分級與逐頁清單qa/references/issue-taxonomy.md報告模板qa/templates/qa-report-template.md瀏覽器引擎全部命令goto/snapshot/fill/click/console/viewport/upload/dialog等browse/SKILL.mdreport-only 變體qa-only/SKILL.md技能模板源文件SKILL.md 由它自動生成勿直接編輯qa/SKILL.md.tmpl小結(jié)gstack 的/qa把測試 → 修復(fù) → 驗證壓進(jìn)一條可執(zhí)行的流程Setup 階段解決瀏覽器引擎、工作樹清潔度與測試命令三個前置問題四種模式覆蓋驗分支diff-aware、全量體檢Full、冒煙Quick和趨勢對比RegressionPhase 1-6 用標(biāo)注截圖 控制臺證據(jù) 加權(quán)健康分建立基線Phase 7-8 在 Tier 約束下做最小修復(fù)、原子提交fix(qa): ISSUE-NNN、before/after 復(fù)測與回歸測試生成并用 WTF-likelihood 計分和 50 次硬上限給 AI 修復(fù)行為上保險Phase 9-11 重跑驗證、雙寫報告、回寫 TODOS.md最終產(chǎn)出一行可直接進(jìn) PR 的 QA found N issues, fixed M, health score X → Y。整條鏈路的設(shè)計重心非常清晰每個結(jié)論都要有截圖與控制臺證據(jù)每個修復(fù)都要有獨立提交與復(fù)測每個循環(huán)都要有自我剎車?！久赓M下載鏈接】gstackUse Garry Tans exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA項目地址: https://gitcode.com/GitHub_Trending/gs/gstack創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考