從技術研究到產品：A2UI 的產品化旅程
技術研究很容易停在「這個技術好酷」。但在銀行，技術研究要回答的問題只有一個：這項技術能不能變成產品功能？這篇用 A2UI 為例，整理我怎麼把一項新技術推向產品。
一、A2UI 是什麼
A2UI 是 Google 在 2025 年 12 月開源的協定，讓 AI Agent 不只回覆文字，還能回覆一個「介面」：Agent 送出描述元件與資料的 JSON，前端再用自己預先核准的元件畫出來。因為 Agent 送的是資料、不是程式碼，它不能執行任意程式，只能從前端的元件清單裡挑選。
對銀行來說，這解決一個實際的問題：理財資訊用一大段文字回答，客戶很難讀；但讓 AI 直接產生網頁程式碼，又不可能通過資安審查。A2UI 剛好在中間：畫面怎麼排由 AI 決定，能用哪些元件由銀行決定。
二、產品化的五個站點
我把技術研究排成一條旅程，每一站都要先過關，才進下一站：
- 商用場景：它能用在哪裡？
- 所需資源：要做 PoC，需要什麼？
- 價值驗證：業務單位覺得值得做嗎？
- PoC：在測試環境裡真的做得出來嗎？
- 產品化：排進產品的開發時程。
三、第一站：先找場景，再劃邊界
以智富管家為主要場景，我整理出三個候選：
- 資產總覽：用卡片與圖表呈現客戶的資產配置，取代一長串文字。
- 商品比較：把客戶問到的幾檔基金，整理成一張比較表。
- 資料填寫：用表單協助客戶完成風險屬性問卷這類資料。
找場景的同時，也要先劃出邊界：依上線前檢核機制，智富管家不能執行交易，所以 A2UI 只用在「資訊呈現與資料填寫」，不放下單按鈕。
四、第二站：資源決定技術能做到哪裡
PoC 需要的資源包括：環境需求與技術規格、Azure AI Foundry 與 Token 的申請、IT 測試環境的對接，以及前端可用的元件清單。最後一項最關鍵：A2UI 能畫出什麼，取決於銀行准許哪些元件。
五、第三站：技術可行只是門檻
在進入 PoC 之前，要先和業務單位確認兩件事：哪一個場景最值得先做？成功要用什麼指標衡量？少了這一站，PoC 做得再好，也可能做的是沒人要的功能。
六、第四、五站：PoC 與產品化
選定場景後，在測試環境實作，並套用 Guardrails 與上線前檢核：Agent 產生的介面，同樣要通過產出層的驗證。PoC 通過後，再和產品團隊對接，把 A2UI 排進開發時程。
學到的事
技術研究的順序，決定了它會不會變成產品。先問「能用在哪裡」，再問「需要什麼」，最後才問「做不做得出來」。順序反過來，常常會得到一個做得出來、卻沒有人要用的 Demo。