現在要請 AI 生成一個網站或 App 介面，已經不再困難。真正麻煩的是下一步：團隊看到一張乾淨、有卡片、有按鈕的畫面後，要怎麼判斷它是不是能讓人把事情做完？
FlowEval 是一篇來自 Purdue University 與 Apple 研究者的論文。它不把評估停在畫面長相，而是讓 agent 在 AI 生成介面與既有參考網站上完成同一組任務，再比較兩者的操作軌跡。這個方向提醒我們：生成速度變快後，驗收標準更不能只剩下「看起來合理」。
生成一個介面，和生成一段可完成的體驗，是兩件事
AI 很擅長補齊常見的頁面結構：導覽列、商品卡、表單、空狀態，甚至看似完整的結帳流程。但畫面齊全不代表關鍵任務能順利走到底。地址能不能修改、條件能不能篩選、加入購物車後是否仍保留選項，這些都必須在實際操作中才看得見。
FlowEval 的核心是把任務當成評估單位。它取用已驗證任務，讓 computer-use agent 分別操作參考網站和 AI 生成版本，將兩者的導航軌跡轉成可比較的訊號。研究者試圖回答的不是「哪個畫面比較漂亮」，而是「這個生成版本是否仍支援同一件事」。
為什麼只用 AI 當評審還不夠？
快速評估生成 UI 時，很容易再找另一個模型評論版面、層級或美感。這樣做有規模優勢，卻也可能把評分模型自己的偏好、盲點一起帶進結果；高分不必然表示使用者能理解下一步。
FlowEval 選擇參考既有高品質服務的操作流程。它用多種軌跡相似度指標衡量生成版與參考版的距離，並以小型專家評估檢驗結果和人類判斷的關係。論文的貢獻不是建立一個萬用分數，而是讓評估有可追查的對照基準。
設計團隊可以先把「任務」寫清楚
這個方法對日常工作最實際的啟發，不是每個團隊都要訓練自己的評測模型，而是要在生成前先定義不能失敗的使用者任務。例如新會員能否在兩分鐘內完成預約、既有客戶能否找到訂單問題的處理入口，或使用者能否在付款前看懂總價與取消條件。
如果任務不存在，團隊通常就只會比較畫面風格；如果任務存在，AI 產出的多個方向才有被淘汰與修正的依據。設計系統、內容規則與錯誤狀態也應一起進入驗收，而不是等 UI 已被交付後才補上。
- 先列出最重要的 3 到 5 個任務與成功條件。
- 用真實內容、限制與例外狀態測試生成流程。
- 把操作失敗視為設計輸入，而非只當成程式 bug。
它不能取代真人研究，但能讓錯誤更早浮現
操作軌跡能檢查流程是否連得起來，卻很難完整回答一個人是否信任介面、是否感到被催促，或不同文化與經驗背景的人如何理解一段文案。這些仍需要研究、訪談與可近用性測試。
比較合適的定位，是把 FlowEval 類方法放在生成與真人測試之間：先用任務檢查快速篩掉明顯無法操作的版本，再把有限的研究資源留給真正需要理解人的判斷。AI 讓第一版更快出現，但不會自動替團隊決定什麼叫做好體驗。