從 PRD、API、後台、iOS、Android 到 QA 回報修正，把「跨平台團隊」壓縮成一套可驗證的 agent workflow。
方案、首購方案、課程、期課、匯入、日曆、課程選項
購物車、金流結帳、付款 callback、訂單、電子發票、優惠、退款狀態
用戶、老師、場館、後台使用者、角色、稽核紀錄
預約、簽到、租借教室、設備、活動報名與票券
App 端送出購物車、付款方式與發票資料，後端建立訂單與 payment。
串接第三方金流，支援信用卡、ATM、超商代碼/條碼等付款資訊。
接收付款結果、驗證來源、記錄原始 callback、更新付款與訂單狀態。
付款成功後發放方案、更新使用權益，並讓後台可查詢與追蹤。
個人、公司戶、會員載具、手機條碼、自然人憑證，開立失敗要可追蹤。
訂單列表、付款狀態、金流編號、發票狀態、作廢與例外處理。
金流 callback、發票加解密、非同步狀態、0 元訂單、取消與退款情境。
主分支觸發部署流程，避免人工 SSH 上機操作成為瓶頸。
伺服器拉最新 main，確保環境與 repo 狀態一致。
用部署腳本切換服務，降低發佈風險。
部署完成後用服務狀態與 logs 追蹤問題。
把模糊需求轉成 agent 能執行、能驗收、能回報的工程單位。
決定優先序、判斷 tradeoff、處理模糊需求，不負責逐行操作。
在明確邊界內讀 code、改 code、跑測試、回報結果。
理解需求、留言、附件、驗收條件。
model、migration、handler、service、unit test。
頁面、表單、狀態、API 串接、權限。
curl + local API + agent-browser E2E。
Layout、色彩、字級、間距、元件階層，多數能被 agent 從設計稿推導出來；真正卡的是細節與狀態。
但越接近設計稿，越需要精準描述差異。
把「感覺不像」變成「這些像素、狀態、元件不一致」。
iOS 已完成的畫面結構、API flow、狀態機、文案與 edge cases。
Kotlin native implementation，完成度約 90%，再靠 emulator 截圖修細節。
確認 Kotlin code 可以實際跑，不只停在靜態編譯。
對照 Figma 與 iOS 行為，找出間距、scroll、dialog、表單狀態差異。
用 Maestro 或人工 QA 流程覆蓋核心路徑。
選固定 Xcode 與 simulator，build debug app，安裝後用 Maestro 走畫面並截圖。
CI 選 Xcode、安裝 certificate、provisioning profile、App Store Connect API key。
更新 build number、設定 manual signing、build app，最後 upload TestFlight。
用 Gradle build debug/release variant，安裝到 emulator，再用 Maestro 跑 E2E 與截圖。
CI 設 JDK 17、Gradle cache、解 google-services 與 release keystore，執行 bundleRelease。
把 AAB artifact 上傳到 Google Play internal track，QA 從測試通道安裝。
Xcode 版本、iOS runtime、Android SDK、JDK、Gradle cache 不一致，都可能讓 agent 追錯問題。
release build 需要 certificate、profile、keystore、API key；本地 agent 通常不能直接碰完整機密。
clean build、啟動模擬器、安裝 app、跑 E2E 都慢，容易拖長 feedback loop。
把 build 指令、裝置、API 環境、測試帳號、Maestro flow 都固定化，讓 agent 少做猜測。
小 UI 改動可用局部 build + 截圖；高風險交易流程才跑完整 E2E 與發佈驗收。
debug login、首頁載入、通知權限、tab navigation，先確認 app 可操作。
課程詳情、期課顯示、點數 popup、取消紀錄，測 API 資料與 UI 狀態一致。
購買點數、條款 popup、個人/公司戶發票、載具欄位、ECPay WebView。
流程可深入到金流信用卡表單，填卡號、效期、CVV、姓名、手機與 email。
流程進到 ECPay WebView 即截圖停止，避免在 production-like 環境真的扣款。
用截圖當 proof，讓 agent 能看實際畫面，而不是只看文字 log。
首頁載入、API 回應、動畫、WebView 轉場都需要 extended wait；等太短 flaky，等太長拖慢 feedback。
金流頁 DOM 不受 app 控制，文字可能變、popup 可能擋住、測試環境提示會中斷流程。
測試帳號、方案資料、付款狀態、發票欄位、build 指向的 API 都會影響結果。
看到錄影或失敗截圖，但不知道當時帳號狀態、API payload、前一步是否真的成功。
每段 flow 都留 screenshot、使用穩定文字/id、把測試停在安全邊界，並把環境條件寫進 ticket。
agent 先 comment 追問，避免修錯方向。
要測試、push、等自動部署，再交回 QA。
任務狀態、測試結果、回覆紀錄形成下一輪輸入。
留下清楚變更與測試紀錄。
觸發 API、後台或 app 發佈流程。
確認 GitHub Action 與部署結果。
移動狀態，comment 說明修正與驗證方式。
任務資訊不足時，agent 會用推測補洞；看似有做事，但方向可能一開始就錯。
只有一句「這裡怪怪的」或缺少 expected / actual，agent 很難判斷要改產品邏輯還是 UI。
影片能看到現象，但不一定能抽出可重現步驟、資料狀態、裝置條件與觸發點。
沒有頁面、帳號狀態、API payload、截圖時間點，agent 只能靠搜尋與猜測補 context。
沒有自動部署與可重跑測試，agent 寫得再快也很難可靠交付。
PRD 要拆成具體 Asana task，並帶有完成定義與測試路徑。
截圖、E2E、curl、CI 狀態，比主觀 prompt 更能讓 agent 收斂。
把需求、測試、部署、QA、回報全部做成 agent 能操作的介面，才是讓一個人交付完整產品的關鍵。