當 AI 開始讀產品，UX 就不只服務人了

這幾個月在整理 AI 工作流時，我一直有一個很不舒服的感覺：我們過去習慣的產品設計思維，可能有一部分正在失效。

以前談 UX，我們很自然會想像使用者是一個人。他會看畫面，理解文字，點按按鈕，感受動線是否順，判斷提示是否清楚。設計師在意留白、層級、互動回饋、情緒與品牌感，這些都合理，因為產品是給人使用的。

但現在產品不只被人看，也會被 AI 讀。

AI 不一定像人一樣理解畫面。它更依賴結構、欄位、狀態、語意和流程邏輯。如果產品只有漂亮的介面，卻沒有清楚的語意結構和狀態設計，AI 很容易讀錯重點，也很難被穩定地納入工作流。

這時候我才意識到，問題不只是「如何讓人用得更順」。問題也變成：你的產品，有沒有被設計成能讓 AI 正確理解？

這對 PM × Designer 來說不是抽象趨勢，而是很實際的交付問題。因為我平常要處理的不是單一畫面，而是需求、流程、介面、開發限制和使用者情境如何被串起來。當 AI 也開始讀產品，設計就不能只停在視覺和動線，還要進一步處理語意、狀態和可驗證的流程邊界。

UX 不是消失，而是多了一個新的讀者

我不覺得 UX 真的死了。人還是要使用產品，人還是會被介面影響。但 UX 的對象正在變複雜，因為產品不再只被人理解，也會被 AI 理解。

這就是我開始關注 AX，也就是 Agentic Experience 的原因。

傳統 UX 很多時候是設計給人看的。視覺層級要清楚，按鈕要容易辨識，錯誤提示要讓人理解，流程要有心理預期。Donald Norman 在《The Design of Everyday Things》裡把這件事講得很精準：好的介面設計靠的是「預設用途」（affordance）與「訊號物」（signifier）——一個東西看起來能不能被按、被拉、被滑，以及有沒有夠明顯的線索告訴你該怎麼操作它。人能夠光靠形狀、陰影、位置的暗示，猜出一個沒看過的按鈕該怎麼用，這種辨識能力大部分時候不需要說明書。

但 AI 面對介面時，真正需要的是另一種清楚。它需要語意結構，需要可解析的狀態，需要明確的錯誤原因，需要清楚的流程邊界。人看得懂的訊號物，對 AI 來說常常什麼都不是——一個看起來像按鈕的 <div>，人一眼認得出來能按，AI 若沒有對應的語意標籤，就只是一塊沒有意義的色塊。

這個落差背後其實有一個更根本的原因。Michael Polanyi 在《The Tacit Dimension》裡提出一句常被引用的話：「我們知道的，比我們能說出來的更多」。人對介面的理解，有很大一部分是默會知識（tacit knowledge）——我們說不清楚自己是怎麼判斷「這個看起來可以點」的，那個判斷是長年累積的直覺，不是一條可以寫下來的規則。這正是傳統 UX 可以一直依賴視覺直覺、卻很少需要把判斷邏輯講清楚的原因。AI 沒有這種默會知識可以繼承，它只能靠明確寫下來的、可解析的規則去理解一個介面。換句話說，AX 要求的不是「多做一點無障礙標籤」，是把過去允許留在默會層次、只靠人類直覺補完的部分，重新變成顯性、可讀取的結構。

如果一個頁面只有漂亮的卡片和動效，卻沒有清楚的 semantic HTML、ARIA 標籤、表單狀態和錯誤邏輯，AI 就很容易像讀不懂路標的人一樣迷路。它可能無法判斷欄位關係，也可能誤解流程狀態，最後產生看似合理但其實偏掉的輸出。

這件事讓我重新看待介面設計。以前我會問，使用者看不看得懂。現在我會多問一句：AI 讀不讀得懂。

GenUI 是 AI 即時組裝介面給人用，AX 則是人設計可理解的產品結構給 AI 讀。兩者方向相反，但很可能會同時存在於未來產品裡。

這裡有個值得正面回應的質疑：AX 會不會只是把語意化 HTML、無障礙標準這些本來就該做的老實踐，重新包裝成新名詞？這個質疑有一半對——語意化標記、明確的狀態管理不是新概念。但過去這些實踐通常被歸類成「加分項」，做不做取決於團隊有沒有餘裕。當 AI 變成常態讀者，它們的性質變了：不再只是可及性加分項，而是 AI 能不能正確納入工作流的先決條件。名詞是舊的，但它從「應該做」變成「不做就會壞掉」，是新的。

設計稿不再只是圖，而是系統規則的一部分

另一個讓我感受很深的變化，是設計與工程的邊界正在變薄。

以前的流程很直觀。設計師畫好圖，整理標註，工程師再切版、接資料、補邏輯。這是典型的序列式等待。設計完成後丟給工程，工程遇到問題再回來問設計，中間有很多來回，也有很多語意在交接時流失。

但現在，設計稿越來越不像一張圖，而像一份結構化資料。設計系統、design tokens、component API、Code Connect、MCP 這些東西，正在把設計稿和程式碼之間的距離拉近。

這其實是把 Herbert Simon 在《The Sciences of the Artificial》裡談的「近乎可分解性」（near-decomposability）搬到設計流程上。Simon 觀察到，複雜系統之所以能被人理解、被有效維護，往往是因為它被拆成一個個模組，模組內部緊密互動，模組之間只透過少數幾個清楚定義的介面溝通——你不需要理解整台系統，只要理解你負責的模組，以及它跟外部的接口長什麼樣。design token、component API、狀態與 variant 的定義，就是在幫設計系統畫出這些模組邊界與接口。當 token、component、variant、狀態和規則都被定義清楚，AI 就不只是看著圖片猜怎麼切，而是可以直接讀取結構，產生初步實作，甚至沿著既有 codebase 做調整——因為它讀到的不是一張圖，是一份已經照近乎可分解的方式拆好的規格。

這意味著設計和開發會從序列式交接，逐漸變成並行作業。

這對設計師是壓力，也是機會。如果設計師只把自己定位成畫畫面的人，很容易變成 AI 工作流裡的輸入者。但如果設計師能定義系統規則、元件語意、狀態邊界與互動判準，他就會變成 AI 工作流裡很重要的規則設計者。

工程師的價值也會變。不是單純把圖刻出來，而是審查 AI 生成的架構，處理極端情境，建立可維護的系統邊界。

最後還是回到人的判斷

這些變化看起來都很技術，但最後仍然會回到人的判斷。

AI 可以讓產出變快，可以讓設計與工程更早並行，也可以幫我們快速生成很多方案。可是越是這樣，人越不能只當產出的搬運工。

我在實作裡越來越相信一件事：AI 負責發散，人負責收斂；AI 負責產出，人負責扛責。

這個分工其實對應到 Karl Weick 在組織研究裡談的「意義建構」（sensemaking）。Weick 的觀察是：人在模糊、資訊不完整的情境裡，並不是先想清楚答案再行動，而是邊行動、邊回頭替發生的事建構一套說得通的解釋，然後據此決定下一步——判斷從來不是在真空裡發生的邏輯推導，是在具體情境裡持續修正的意義建構過程。AI 現在能做的，是把大量發散的可能性攤開來給你看；但把這些可能性放進「這個組織現在的處境、這次交付要對誰負責、犧牲哪一種穩定性換取哪一種速度合不合理」這個脈絡裡去判斷，這件事本質上就是意義建構，而意義建構需要對脈絡的持續投入，不是一次性的指令能取代的。

不要再把 AI 只當成一個幫你補文字或寫程式的工具。更有價值的做法，是把整個 codebase、設計系統、流程限制與使用情境都當成 context，讓 AI 對著活生生的系統找盲點、寫 spec、提出風險。

但最終，決定選哪一條路徑、要承擔多少技術債、要不要犧牲一點流暢度換取穩定性，這些決策 AI 幫不了你。

當工具拉平了很多人的產出能力，真正決定產品高度的，會是你對領域的理解，以及你能不能在無數次取捨裡做出更準的判斷。

所以我會多問一個問題

我不會說 UX 已經過時。更準確地說，是 UX 不能只停留在人類視角。

未來的產品，很可能同時要服務人，也要讓 AI 能讀懂。人需要理解、信任與情緒上的流暢；AI 需要語意、狀態、可解析的流程與清楚邊界。

所以我現在看產品時，會多問一個問題：這個系統除了讓人看得懂，能不能也讓工具讀得懂、讓團隊驗得出、讓後續維護接得上？如果要落地成一個具體檢查點，我會在每個介面設計評審裡都問一次：這個狀態變化，AI 有沒有辦法只靠讀結構就判斷出來，而不用靠猜？答不出來，就代表這個地方還停留在只服務人的階段。

對我來說，這其實回到複雜服務落地的同一件事：產品不是一張畫面，而是一套可被人、團隊、開發流程與未來 AI 工具共同理解的工作系統。AX 不是把 AI 概念塞進設計，而是提醒我，交付出去的服務必須有清楚的語意、狀態、邊界與責任。

這也是為什麼我覺得 AX 不只是新的名詞，而是一個提醒。它提醒我們，AI 時代的產品設計，不只是把 AI 放進產品裡，而是重新理解產品到底被誰理解、由誰判斷、又由誰承擔後果。

我們不是只是在學怎麼用 AI。

我們是在學如何在 AI 參與工作的世界裡，重新設計人、工具與系統之間的邊界。