某段時間，我在追一個只在 US region 才會出現的 login bug。 同樣的 code、同樣的 flow，在另一個區域跑就是會壞。文件沒寫、API 命名不一致、login path 在不同環境下走的根本不是同一條。最後我是在 console、network、git history、跟同事的記憶之間，把它一點一點拼回來的。 那次之後我才開始想—— 如果這個系統能自己記得它走過哪些路、call 過哪些 API、跨過哪些環境差異，我們是不是根本不需要花這麼多時間，去 reverse engineer 一個本來就是自己做的產品？ 這個問題，後來變成 Quantum QA Tool。
我最直覺的反應是：做一個 Agent。 讓 AI 看 UI、看 API、自己決定怎麼測。聽起來很性感。 但我很快撞牆——Agent 連自己在哪個環境都搞不清楚，根本不可能穩定執行。我每次跑都要花十分鐘解釋：現在是哪個 region、哪個帳號、哪個 API prefix、哪一版的 auth。 那時候我才意識到一件事： 問題不是 Agent 不夠聰明，是它沒有 context。 於是我把整個方向反過來。AI 先放下。先解決一個更基本、也更無聊的問題——這個系統如何穩定地知道「自己在哪」。
在 SaaS 與 Enterprise 專案裡，文件過時、API 命名混亂、流程靠口頭傳承，是 QA、PM、工程團隊最常遇到的痛點。Quantum QA Tool 的起點，就是降低理解複雜系統的成本。
Quantum QA Tool 不只是錄製操作，而是觀察 UI、API、事件、狀態變化，逐步還原 User Flow、API Dependency、Feature List 與可執行 Recipe。
真正困難的不是自動化測試，而是讓系統理解哪些操作是核心流程、哪些 API 是雜訊、哪些資料依賴需要被重建。這是未來 Agent 自動化的地基。
---
Agent 與自動化測試最大的問題之一，是缺乏穩定 context。
所以 Quantum QA Tool 最早建立的能力，不是 Agent，而是 Environment System。
• 管理多個 SaaS / Enterprise 環境 • 快速切換測試帳號與登入方式• 管理 API auth / credential / prefix • 建立可共享的測試基礎設施
Recorder 不只是錄製資料。我開始嘗試讓 Agent 根據錄製內容，自動推論並建立 Recipe。
「幫我根據這個 flow 建立一個 recipe」
這件事的本質其實是：把「人類理解產品流程」的能力，逐步轉譯成機器可執行知識。
真實產品裡的 API 往往沒有文件、沒有規格、沒有一致命名。
所以我開始建立 API Pool，把錄製過程中的 API 統整成可分析、可重播、可驗證的結構。
• OpenAPI / Postman 匯入匯出 • API dependency 分析 • Auth / DTO / Response 管理 • 作為 Recipe 與 Test Engine 基礎
錄製資料本身其實沒有太多語意。真正重要的是：
• 哪個 Page 對應哪個功能？• 哪個 Element 觸發了哪個 API？• 哪些事件形成了完整 User Flow？• 哪些資料才是真正的商業邏輯？
所以開始建立 Evidence Graph 與 Flow Context 系統，讓產品互動開始具備可分析性。
Recipe 並不是腳本。它更像是：
Executable Product Workflow
它可以描述：
• API Workflow automation • 自動化腳本 (ex: 多帳號建立) • 生成測試資料 ...etc
自己定義的工作流程
解除繁瑣手動網頁操作
Low code 體驗
一開始只是想解決自己的痛點。
但隨著 Recorder、API Pool、Recipe、Health Check、Flow Analysis 出現後，整個系統開始變成團隊共享的 QA 基礎設施。
• 環境管理• API 管理• Flow 分析• 自動化測試• Agent workflow
而這一切的核心，其實都是：
「降低人類理解複雜系統的成本。」
當產品互動可以被記錄、分析、轉譯、執行，QA 自動化才不只是測試腳本，而會變成組織理解產品的基礎設施。
