Thariq Skills #2 — Product Verification：讓 Agent 自己跑驗證，而不是等你手動測

你讓 agent 改了一段程式，它說「完成了」。但你怎麼知道 signup 流程還是通的？

Product Verification skills 解決的就是這個問題：讓 agent 自己去驗證，不要等你手動打開瀏覽器測。

---

類別定義

Product Verification 是 Thariq 特別強調投入工程資源的類別。他的說法是「值得讓一個工程師花一週把它做好」——這個投資會讓之後的所有 agent 工作都更可靠。

這個類別的核心不是「寫 test case」，而是「給 agent 一個可以驅動、觀察、並斷言的驗證環境」。

---

Thariq 的範例

signup-flow-driver — 自動驅動使用者註冊流程。啟動 Playwright，填表單、點按鈕、驗證狀態——agent 執行，而不是人工執行。

checkout-verifier — 結帳流程的端對端驗證。關鍵是「programmatic assertions at each step」：每一步都有可程式化的斷言，不是靠視覺判斷。

tmux-cli-driver — 用 tmux 驅動 CLI 工具的交互。agent 在一個 pane 執行指令，在另一個 pane 觀察輸出，確認行為符合預期。

---

兩個關鍵技術

錄影輸出

# 典型的 Playwright 錄影設定
playwright test --video=on --output=./test-results

程式化斷言

不要讓 agent 做「看起來對」的判斷。每個驗證步驟都應該有明確的可程式化條件：

// 好：明確的程式化斷言
await expect(page.locator('[data-testid="success-message"]')).toBeVisible();
await expect(page.url()).toContain('/dashboard');

// 差：依賴 agent 視覺判斷
// "Check if the page looks correct"

---

SuperPortia 實戰觀點

這是 SP skills 覆蓋中最大的缺口。

目前狀況：SuperPortia Bridge（前端）和 Command Center（儀表板）完全沒有自動化驗證 skill。每次部署後，驗證流程是手動的——人工打開瀏覽器、點頁面、確認功能。

這在單一 agent 部署時還可接受，但隨著 agent 頻率增加，問題會放大：

風險	現狀	影響
部署後迴歸	無自動驗證	需人工發現問題
API 端點變更	無端對端測試	前後端可能不同步
CF Workers 部署	靠 wrangler 輸出判斷	沒有功能層面的確認

最可行的起步：為 Command Center（localhost:3900）建立一個 cc-verifier skill，用 Chrome DevTools MCP 驗證關鍵頁面是否正常渲染，並確認 API endpoints 回應正確的 status code。

---

建議做法

從最簡單的「冒煙測試 skill」開始，不必一步到位：

cc-verifier/
├── SKILL.md         ← 觸發條件：「部署後驗證 CC 功能」
├── smoke-test.sh    ← curl 檢查關鍵 API endpoints
└── gotchas.md       ← 已知的不穩定行為記錄

三個必驗的點：

1. Command Center 首頁是否正常載入（HTTP 200）
2. /api/projects 是否回傳正確格式
3. 最近一次修改的功能是否仍然運作

---

回到總文

本文是九大類別系列的第二篇。完整框架與 SuperPortia 對照請見：

Anthropic 工程師的 Agent Skills 完全指南 — 九大類別 × 九個技巧