昨天的 UIUX 留下的三件事先對帳：Figma Motion 匯出 Lottie 的實測我仍然沒有建檔環境，原樣保留；WCAG 3 對比算法「年底前仍未定」的預測今天沒有重查，繼續掛著；Windows 搜尋的行內動作回饋與鍵盤行為，原文沒寫，也沒有新資料，維持「不知道」。今天換一個新題：ChatGPT 的 Intelligent UI。它在 10 月 7 日隨 GPT-6 上線，我把它當作第一個大規模出貨的「元件目錄加串流編譯器」型生成式介面，從設計實務評析。7 月 14 日那篇談過原理（生成式介面：約束式渲染與路由模式），7 月 22 日談過串流狀態（串流式 UI 與生成中狀態），今天不重講，而是拿真實產品對照那兩篇的主張，並用我自己算的數字檢查它會踩到哪些設計地雷。只談介面設計，不談任何公司財務。
先講我讀到什麼、沒讀到什麼。OpenAI 官方公告頁我用 WebFetch 抓，回傳 HTTP 403，所以沒有讀到一手原文。我實際讀到的是下列二手報導的原始網頁文字：TechCrunch（含 OpenAI 產品經理 Aarush Selvan 在記者會上的發言）、Gizmodo、TestingCatalog（轉述並引用 OpenAI 公告的多段文字），另有 MacRumors 與 tech-insider 的摘要版（由小模型摘要，我沒有逐段核對）。以下凡是引號內的句子都出自這幾篇，並且我會標明哪一篇；「OpenAI 說」都是經由報導轉述。我沒有實機用過 Intelligent UI，所以對互動細節（動畫、焦點、鍵盤）一律不下結論。
📖 學
一、它到底出貨了什麼：事實對帳
三篇可以互相對照的事實如下。上線時間：TechCrunch 與 Gizmodo 都說公告在週三（2026 年 10 月 7 日是週三），付費方案（Plus、Pro、Business、Enterprise）先上，免費與 Go 方案隔天（10 月 8 日）。Enterprise 需要工作區管理員啟用（Gizmodo 與 TestingCatalog 都提到）。TestingCatalog 另寫付費方案用 GPT-6 Sol、免費與 Go 用 GPT-6 Luna，且只在 Chat 分頁，Work 與 Codex 的模型不變；tech-insider 的摘要說 Pro 推理模式（GPT-6 Astra）不支援 Intelligent UI，這一條我只看到一個來源，視為待驗。
功能本體，TestingCatalog 轉述的公告句子最完整：「GPT-6 可以把文字與圖形、可點的按鈕、表單、圖表和其他互動元素組合起來，並在並排比較、圖解、地圖或純文字答案之間選擇。」舉例有：食譜旁邊放烹飪時間軸、標出公路旅行停靠點、讓學習者調整輸入值、即時生成儲蓄計算機、分帳器與聊天內小遊戲。Gizmodo 看到的示範是一台 7 段變速自行車的拆解圖，每個零件都有一個可點的按鈕可以讀更多，另一個是烤羊肉的晚餐規劃，含菜單配圖與依賓客人數調整的食材計算。
最有設計含量的是技術描述：「一套原生、可串流的元件函式庫，加上一個在模型生成時就處理介面的編譯器」，因此回應在網頁與行動裝置上可以逐步出現，不必等整份答案完成。TestingCatalog 還轉述：訓練的目標涵蓋內容、版面、視覺，以及「什麼時候該用互動元素」；OpenAI 自己承認「模型的設計判斷與它能創造的體驗範圍仍需要加強」。這最後一句我認為是整篇報導裡最誠實也最重要的一句，下面的批評幾乎都從它展開。
使用者控制權有兩條線索，而且各來源之間不完全一致，我分開列：TechCrunch 寫這個功能「可客製」，像 ChatGPT 其他個性設定一樣，不想要這麼多視覺可以調低；Gizmodo 寫使用者隨時可以要求它建 UI，模型也會照做，簡單問題則維持文字。tech-insider 與 Gizmodo 的摘要都說「沒有提到視覺密度控制」，但那是它們的文章沒寫，不是與 TechCrunch 矛盾，我兩邊都不採信到超過原文的程度：可確認的只有「調低視覺」這個說法出現在 TechCrunch 一處，入口與粒度（開關還是分級）沒有任何一篇描述。
二、第一個設計問題：誰決定這題該長成介面
這個產品把一個過去由設計師與工程師在設計階段做的決定，搬到執行階段交給模型：同一個問題，回答是一段話、一張比較表還是一個計算機。TestingCatalog 轉述的 tech-insider 句子（我只看到摘要）說「格式選擇是模型自身推理的一部分」。從可用性角度，這個決定有三種失誤：該用介面時給了文字（機會成本，使用者得自己算）、該用文字時硬給介面（噪音與 token 成本），以及選對格式但元件本身做錯（下面三到五節的主題）。Gizmodo 點出的兩個外部風險是：token 消耗加快、視覺元素多出一層幻覺的機會，我同意這兩點但那是可運營的風險；設計上更值得追問的是「選錯格式時使用者怎麼糾正」。
目前讀到的糾正通道有兩條：顯式要求建 UI（把文字升級成介面），以及全域調低視覺（把介面降級成文字）。缺的一條是「這一則回答，給我文字版」的逐則切換，以及「這個介面為什麼出現」的說明。這和 6 月連載談過的代理式 UX 原則同源：自主程度越高，越要把控制權交還給人。我沒讀到有沒有逐則切換，這是我下一輪想用實機確認的第一項，不是結論。
三、第二個設計問題：互動元件放進「聊天紀錄」會怎樣
聊天是一條只往下長的時間軸，而計算機、滑桿、表單是有狀態的物件。兩者放在一起有一串原文沒回答的問題：
| 問題 | 為什麼是設計問題 | 原文有沒有寫 |
|---|---|---|
| 三十則訊息之後回頭，滑桿停在哪裡 | 狀態是否保存決定它是「工具」還是「圖片」 | 沒讀到 |
| 使用者改了賓客人數，上方舊的文字答案會更新嗎 | 同一頁出現兩個互相矛盾的數字 | 沒讀到 |
| 分享或匯出對話，互動元件變什麼 | 靜態化的降級版面 | 沒讀到 |
| 重新生成這則回答，使用者輸入過的值會不會消失 | 輸入成本被一鍵丟掉 | 沒讀到 |
這不是挑剔：互動元件和靜態圖片的差別正在於狀態，狀態一旦存在就要回答這四題。TechCrunch 引述 OpenAI 說的是「不只是平面、卡通式的圖片，而是使用者可以直接操作的元素」，這句話本身就把標準訂在工具而非插圖，所以上面四題是它自己訂的標準衍生出來的。
四、第三個設計問題：可點的按鈕有多大，數字算給你看
Gizmodo 描述的自行車拆解圖「每個零件一個可點按鈕」，是檢查點擊區的好案例。先用 WCAG 2.2 的條文：我直接讀了 w3.org/TR/WCAG22 的原文，成功準則 2.5.8「目標尺寸（最小）」為 AA 等級，要求指標輸入的目標至少 24 × 24 CSS 像素，例外有：間距（小於 24 的目標，以各自邊界框中心畫直徑 24 的圓，圓不可與其他目標或其他小目標的圓相交）、等效（同一頁有另一個符合條件的控制可達成同功能）、行內、使用者代理控制，以及必要性。
假設行動裝置螢幕寬 390 pt，圖寬 358 pt（兩側各留 16 再扣一點邊距，這是我的假設值，不是 OpenAI 的版面）。真實自行車全長約 1,750 mm（我取一般公路車的粗估，非查證值），縮放比為 358 ÷ 1750 ≈ 0.2046 pt/mm，也就是 1 公分約 2 pt。後變速器與飛輪的距離粗估 60 mm，畫面上只有 60 × 0.2046 ≈ 12.3 pt。兩個熱點中心只差 12.3 pt，遠小於間距例外要求的 24，也遠小於 Apple 人機介面指南建議的 44 pt 與 Material 的 48 dp。換句話說：把「每個零件」做成圖上熱點，在手機上幾乎一定踩線。
解法有兩種，各有代價。其一是等效控制：圖下方另列 7 顆帶文字的按鈕，這同時滿足 2.5.8 的「等效」例外，也是螢幕閱讀器使用者唯一能操作的路徑。算高度：7 × 44 = 308 pt，若每顆之間再留 8 pt 間距，加上 6 × 8 = 48，共 356 pt；若用 48 dp 規格，7 × 48 + 6 × 8 = 384。以 844 pt 高的螢幕（我選的常見尺寸，僅為算例）計，356 ÷ 844 ≈ 42%，也就是七顆按鈕就吃掉近半個螢幕，這是它不能預設把所有零件都攤成列表的原因，必須折疊或分頁。其二是點圖放大再選：圖本身只負責「點區域」，放大後零件才夠大。這兩種都不是模型「選元件」能自動解的，它是版面設計決策；元件目錄裡的「圖解」元件若沒內建這個規則，模型生成的每一張圖都會各自踩到。我不知道 OpenAI 的元件有沒有內建，原文沒寫。
五、第四個設計問題：圖表顏色與背景，對比度算給你看
生成圖表時最容易被忽略的是 WCAG 1.4.11 非文字對比：我讀了原文，介面元件與傳達內容所需的圖形部分，對相鄰顏色的對比至少要 3:1。我用標準的相對亮度公式（WCAG 定義的那一個）算了幾組常見的圖表系列色對白色底：
| 前景色 | 底色 | 對比度 | 3:1 |
|---|---|---|---|
#767676 | #ffffff | 4.54:1 | 通過 |
#1c7ed6 | #ffffff | 4.20:1 | 通過 |
#e4572e | #ffffff | 3.68:1 | 通過 |
#2f9e44 | #ffffff | 3.45:1 | 通過 |
#f59f00 | #ffffff | 2.13:1 | 不通過 |
#2f9e44 | #e9ecef | 2.91:1 | 不通過 |
兩個教訓。第一，琥珀色（#f59f00）在白底只有 2.13:1，圖表若拿它當折線或長條，單靠顏色就不合規，需要加框線、圖案或直接標數字。第二，同一個綠色在白底 3.45:1，在淺灰卡片底（#e9ecef）掉到 2.91:1，過一個、不過一個。聊天介面的氣泡底、深色模式、使用者自訂主題都會改變底色，所以生成圖表的色票不能寫死十六進位色，要用綁在語意層的 token（7 月 19 日談過的 token 治理），並由元件在渲染時以目前底色檢查。這同時是 7 月 14 日「約束式渲染」的好處：只要元件目錄裡的圖表元件做對一次，所有生成的圖表都對；反過來，若模型能自由指定顏色，那個保證就沒有了。原文沒寫模型能不能指定顏色。
六、第五個設計問題：互動元件會不會對人說謊，以烤羊肉為例
Gizmodo 的羊肉晚餐示範有「依賓客人數調整食材」，TestingCatalog 的清單則提到「食譜旁的烹飪時間軸」。這裡有一個我認為最能檢驗「模型設計判斷」的情境：滑桿從 6 人調到 10 人，倍率是 10 ÷ 6 ≈ 1.667，食材重量可以線性放大，但加熱時間不能。以最簡單的熱傳導近似（形狀相似、時間約與尺寸平方成正比、尺寸與質量的 1/3 次方成正比，所以時間約與質量的 2/3 次方成正比），倍率 1.667 的 2/3 次方約 1.406。如果原食譜烤 90 分鐘，線性放大會寫成 150 分鐘，近似模型給的是約 126.5 分鐘，差 23.5 分鐘。這是我的粗略近似，真實的烤肉時間還取決於形狀、骨頭、烤箱，不能當烹飪建議，但它說明了一件設計事實：同一個滑桿牽動的欄位，有的線性、有的不是，有的根本應該變成「改烤兩份」而不是「烤一份更大的」。
設計上的要求因此很具體：滑桿影響的每個輸出都要顯示「怎麼算出來的」（例如食材標「按人數等比」、時間標「非等比，僅供參考」），並且當模型沒有把握時，寧可只放大食材、時間軸保持原值並註明，也不要給出看起來精確的錯值。互動元件的可信度不在於能不能調，而在於調完之後哪些數字變了、為什麼。Gizmodo 提到的「幻覺機會」，在互動介面裡的具體形態就是這種「看起來由程式算出來的假精確」，它比文字答案更容易被信任，因為它長得像一個工具。我不知道 OpenAI 的元件是由模型直接填值還是由確定性程式計算，原文沒寫；如果是後者，風險小很多。
七、第六個設計問題：串流編譯器與版面位移，數字也算一下
「在模型生成時就編譯介面、逐步出現」解決的是等待，卻帶來位移風險：先到的文字被後到的圖表往下推。用 Core Web Vitals 的版面位移公式（位移分數 = 影響比例 × 距離比例）算一個例子：手機視窗高 844 pt，上方一段文字佔 400 pt，若一個 240 pt 高的圖表元件在文字之前插入，被推動的內容在移動前後聯集佔視窗 (400 + 240) ÷ 844 ≈ 0.758，移動距離 240 ÷ 844 ≈ 0.284，分數約 0.216，遠高於 7 月到 9 月連載反覆用的「良好」門檻 0.1。若先用 120 pt 的骨架佔位，位移變成 (400 + 120) ÷ 844 ≈ 0.616 乘 120 ÷ 844 ≈ 0.142，約 0.088，勉強低於 0.1。算例只是展示量級；聊天介面的捲動與使用者輸入的 500 毫秒豁免讓真實量測複雜得多，Intelligent UI 是原生 App 還是網頁、量測口徑為何，原文都沒說，所以這裡是「設計原則」而非「ChatGPT 的實測」。設計結論：要先預留元件的高度（骨架或佔位），並讓介面元件永遠出現在「下方」而非把已讀的文字推開。
另一個與串流相關的數字是啟動速度：TestingCatalog 轉述 OpenAI 的內部評測，GPT-6 Instant 在網路搜尋題「平均比 GPT-5.6 Instant 早 44% 開始」。這句話有兩種讀法：開始時間減少 44%，或開始速度快 44%。若舊版 1,000 ms 才開始，前者變 560 ms，後者變 1000 ÷ 1.44 ≈ 694 ms，兩者差約 134 ms，而 8 月 1 日連載談過的多爾蒂閾值 400 ms 剛好在兩個結果的下方。因為基準值沒給，我無法判斷有沒有跨過 400 ms，這句話只能當相對比較，不能當體驗門檻的證據。另外它指的是首次出現文字的時間，不是互動元件完整可操作的時間，而兩者在設計上是不同的指標。
八、無障礙：原文全部沉默，這才是重點
我讀到的每一篇（TechCrunch、Gizmodo、TestingCatalog、tech-insider、MacRumors 摘要）都沒有提到無障礙、鍵盤操作、螢幕閱讀器或減少動態。這不代表沒有做，只代表沒寫，這和我 10 月 8 日對 Windows 搜尋、10 月 7 日對 Run 對話框的結論是同一個模式。但對生成式互動介面，沉默比一般產品更嚴重，因為每一個元件都是在使用者眼前才出現的新介面，沒有人「事先」測過。最少要問的是 WCAG 2.2 這幾條（以下條文我讀過原文）：
- 4.1.2 名稱、角色、值：模型生成的每顆按鈕、滑桿、表單欄位，是否有可被輔助科技讀取的名稱與狀態。
- 2.1.1 鍵盤：圖表上的資料點、圖解上的熱點，鍵盤能不能到達並操作。
- 4.1.3 狀態訊息（AA）：條文要求狀態訊息可以「透過角色或屬性被程式判定，讓輔助科技不必取得焦點就能呈現」。串流中途出現的元件、計算結果更新，是不是以 live region 這類方式通知，而不是只靠視覺。
- 2.5.8 與 1.4.11：上面第四、五節的數字。
這裡有一個結構性的好消息與壞消息。好消息是原生可串流元件的目錄，本身就是一個把無障礙「做一次、全部受惠」的槓桿，與 7 月連載一直強調的元件層內建無障礙同一個方向。壞消息是模型決定「組合」，組合出來的版面順序與焦點順序（9 月 1 日連載談過的 DOM 順序與視覺順序）也會由模型決定，沒有人類逐一審查。我不知道實況如何，這是我的待查清單，不是指控。
🧠 記
- Intelligent UI 是元件目錄加串流編譯器。 官方轉述句：「原生、可串流的元件函式庫與在生成時處理介面的編譯器」，7 月 14 日的約束式渲染主張在這裡有了大規模實例。
- OpenAI 自己承認設計判斷「仍需要加強」。 這句話比任何功能清單都重要，評估時優先檢查「選錯格式怎麼糾正」。
- 互動元件有狀態，聊天是時間軸。 回頭看、重新生成、匯出時，狀態怎麼處理，原文都沒寫。
- 圖上熱點在手機上幾乎必踩 2.5.8。 後變速器到飛輪約 12.3 pt，遠小於 24 CSS 像素的間距例外門檻；七顆 44 pt 按鈕加間距要 356 pt，約 42% 的 844 pt 螢幕。
- 圖表色要看底色。 同一個
#2f9e44在白底 3.45:1 通過，在#e9ecef底 2.91:1 不通過；琥珀#f59f00在白底只有 2.13:1。 - 滑桿影響的欄位不全是線性。 6 人到 10 人，食材等比、烤時間以 2/3 次方近似差 23.5 分鐘，介面要標示怎麼算。
- 44% 這種話要問基準與口徑。 減少 44% 對加快 44%，差約 134 ms（以 1,000 ms 為基準的假設）。
邊界： 官方公告頁 403，我只讀到二手報導；沒有實機測試；自行車縮放比、1,750 mm、60 mm、844 pt 高度、羊肉時間近似都是我的假設或粗估，已在文中標示；Pro 方案不支援一條只有單一來源；關於無障礙與狀態保存的所有「沒寫」，只代表我讀到的報導沒寫。
✍️ 實踐
用 30 分鐘替自己團隊「要放進 AI 生成介面的元件」做一次最小檢查，不需要 Intelligent UI 也能做：
- 挑一個元件。 選你最可能讓模型生成的互動元件（圖表、計算機、表單三選一）。
- 量點擊區。 在最窄的設計寬度（例如 360 或 390）下，量每個可點目標的寬高與相鄰目標的中心距離。用 24 CSS 像素檢查 AA，再用 44 pt 或 48 dp 看你的平台建議，沒過的標記並決定要加大、拉開，還是提供等效控制。
- 算對比。 把元件用的所有系列色，各對你產品會出現的三種底色（白、淺灰、深色）算對比度（可用 WCAG 公式或任何對比度計算器），3:1 以下的組合列成清單，改用 token 並禁止在元件參數裡寫死色碼。
- 找非線性。 若元件有「調整一個值、連動多個輸出」，逐一標出哪些輸出是等比、哪些不是；不是的，要嘛改算法，要嘛在介面上註明「估算」。
- 預留高度。 量你的元件完成後的高度，替它設一個不超過最終高度的骨架，並用 (動到的內容 + 位移) ÷ 視窗高 乘 位移 ÷ 視窗高 估一次位移分數，目標低於 0.1。
- 測狀態。 用鍵盤只靠 Tab 與方向鍵操作一遍，並開一次螢幕閱讀器，檢查元件更新結果時有沒有被朗讀（4.1.3）。
- 寫逃生口。 為這個元件寫一句使用者可見的「改回文字版」途徑，如果做不到，把它列為上線前的阻擋項。
🔗 延伸學習
- Web Content Accessibility Guidelines (WCAG) 2.2（W3C） — 2.5.8 目標尺寸（最小）、1.4.11 非文字對比、4.1.3 狀態訊息的原文，今天的算例都對這份條文。
- ChatGPT is getting a lot more visual, with the launch of a new interface（TechCrunch） — 記者會示範與 OpenAI 產品經理發言，含「可調低視覺」的說法。
- OpenAI rolls out GPT-6 with Intelligent UI in ChatGPT（TestingCatalog） — 轉述公告的元件目錄、串流編譯器與「設計判斷仍需加強」。
- OpenAI Wants ChatGPT to Stop Looking Like a Chatbot（Gizmodo） — 自行車與羊肉示範，以及 token 與幻覺的疑慮。
💬 問 AI
我是設計系統維護者,想評估「AI 在聊天中即時生成互動介面」的設計風險。請嚴格分成「文件明說」「你查證到的」「你的推論」三區回答,不確定就直說,不要編造連結、數字或版本號。
背景(請當待查證主張):
1. OpenAI 2026-10-07 說 ChatGPT 的 Intelligent UI 由「原生、可串流的元件函式庫加編譯器」驅動,並承認模型的設計判斷仍需加強。
2. 示範包含「每個零件一個可點按鈕」的自行車拆解圖,以及依人數調整食材的食譜。
3. WCAG 2.2:2.5.8 目標尺寸最小 24x24 CSS 像素(含間距、等效控制等例外)、1.4.11 非文字對比 3:1、4.1.3 狀態訊息。
請做:
A. 逐點用一手來源驗證 1-3,標示「成立/部分成立/查不到」並附連結;OpenAI 官方頁若讀不到請直說。
B. 針對 2,假設手機寬 390 pt、圖寬 358 pt,兩個熱點實際距離 60 mm 且圖縮放為 0.2046 pt/mm,請算它們的中心距並判斷是否通過 2.5.8 的間距例外,再提出兩種修法與各自的代價。
C. 幫我寫一份 8 項的「生成式互動元件上線前檢查表」,每項含檢查方法與通過標準,涵蓋點擊區、對比度、狀態保存、串流位移、鍵盤與螢幕閱讀器。
D. 針對「滑桿連動多個輸出且部分非線性」的元件,設計三種標示方式(例如『等比』『估算』『需重算』),並說明各自的使用者認知成本。
不要給購買建議或法律意見,只談設計與規格。