昨天留下的問題是「代理到底有沒有照規則做」，今天找到第二份帶數字的資料：TJ Pitre（Southleft）7 月 26 日的文章，在自家的設計系統契約（DS Contracts）專案上做了 A/B 測試，沒有治理的代理畫出的畫面得 69 分、有 90 項違規（編造屬性、寫死顏色、改樣式），改用契約目錄的代理得 100 分。這份資料和 Coinbase 的評測放在一起看，剛好是同一個問題的兩種量法；但它是廠商自家專案的測試，模型、次數與評分規則都沒有寫，證據強度要打折。
另外三條線是這週新出的：10 月 7 日起 ChatGPT 的 Intelligent UI 讓答案直接長成計算機、表單與比較表，使用的是 OpenAI 預先做好的元件庫，設計上的問題從「畫面好不好看」變成「誰決定這個答案長什麼樣、使用者能不能檢查」；10 月 16 日 NN/G 發表合成受訪者與真人受訪者的對照（120 個合成對 604 位真人，答案種類 12 種對 50 種以上）；10 月 15 日 Microsoft 把 Windows 11 的相片 App 重做，編輯器分成四類任務。最後補一份 Dave Davies 掃描 59,400 個電商商品頁的無障礙報告，有幾個數字能直接核對。先對帳，再依序講這幾塊。
📖 學
一、昨天待驗的對帳
| 昨天的待驗 | 今天查到 | 狀態 |
|---|---|---|
| Guidelines 本身的遵守率與格式上限 | 沒有 Figma 的新資料；但找到 Pitre 的契約 A/B 測試（第二節），它量的是「契約目錄」，不是 Figma Guidelines | Guidelines 本身仍查不到 |
| USWDS 10 月進度更新與 GSA 回應 | GitHub 討論區清單上，維護者 ryparker 最新的貼文仍是 9 月 22 日；清單中最新的是 10 月 5 日一位社群成員提出「為 React Native 開發元件庫」的點子，0 則回覆。9 月 18 日更新承諾每兩週一次，自算 9 月 18 日至今 31 天，照承諾 10 月 2 日與 10 月 16 日前後應各有一篇，我在清單上沒有看到。GSA 的回應沒有找到 | 兩個週期未見更新，GSA 回應查不到 |
| HIG 是否出現 HomeView 專頁或 pt 規格 | Apple 設計「What’s new」頁最新仍是 10 月 13 日兩筆（Widgets、Live Activities），沒有第三筆；Blake Crosley 的整理（更新到 10 月 14 日）寫 Xcode 27.2 beta 3 於 10 月 14 日釋出，發行說明沒有 HomeView 專屬的 SDK 項目，Apple 也沒有公布 1088 × 1088 螢幕的 pt 規格；Live Activities 頁至今沒有明確寫出 HomeView | 仍未公布 |
| 11 月 13 日實機字高 | 自算距出貨還有 25 天 | 待驗 |
| Modular face 是否受認人把關 | 沒有新資料 | 待驗 |
| Henry 30% 原始出處 | 沒有新資料，不再重複搜尋 | 查不到 |
| Figma Specs 與 Code layers | 昨天沒列為待驗，今天補到 TechCrunch 對 10 月 14 日 Config India 的報導：Code layers 由 6 月宣布的私人測試進入開放測試；Specs 是 Markdown 編輯器，可獨立成檔或放進畫布，能引用 Figma 元素、嵌入 FigJam 圖與程式碼圖層 | 新增，細節見第二節 |
這張表的結論和昨天相同：變動最快的是文件與報導，不是規格與數據。HomeView 的設計資料這幾天沒有任何新增，Apple 的版面資訊停在文字規則；USWDS 的進度承諾與實際貼文之間有落差，但這只能說「我在公開清單上沒看到」，不能推論專案停擺。
二、第二份代理遵守率資料：契約目錄 69 對 100
昨天寫「Guidelines 還沒有公開評測」。今天找到的 Pitre 文章《How To Use AI To Need Less AI》（7 月 26 日，作者署名 TJ，Southleft）嚴格說也不是 Guidelines 的評測，但它是目前我能查到唯一一份把「沒有約束」對「有機器可讀契約」直接比分數的公開資料。Vitaly Friedman 7 月 29 日的《How To Reduce AI Drifting In Design》引用了它，這是我在 Friedman 的文章裡讀到的出處。
| 條件 | 分數 | 違規 |
|---|---|---|
| 沒有治理的代理畫畫面 | 69 / 100 | 90 項：編造屬性、寫死顏色、改寫元件樣式 |
| 使用契約目錄的代理 | 100 / 100 | 沒有；文中說它「回報缺口，而不是硬湊」 |
這組數字有四個要先講清楚的限制。第一，測試對象是作者自己的 DS Contracts 概念驗證（GitHub 上的 southleft/ds-contracts-poc），作者自己也寫「請帶著懷疑讀」。第二，模型名稱、跑幾次、評分規則、違規怎麼算，文章都沒有寫；我另外開了 GitHub 專案的說明頁，也沒有找到 69 分與 90 項這組數字，專案自己的衡量哲學寫的是「量完成的使用者旅程、涵蓋率與剩餘的拒絕次數」。第三，100 分的條件下，代理被允許「拒絕」，也就是做不到就回報缺口；這和「交出一個可用畫面」不是同一個目標，滿分可能是因為它畫得少。第四，一個我自己的算式：100 減 69 等於 31 分，卻有 90 項違規，若是線性扣分，每項最多只扣約 0.34 分，所以評分顯然不是單純的「違規數乘固定權重」，規則不明，就不能拿 69 分去和別的團隊比。
把它和 Coinbase 的評測並排，會看出它們量的是不同層：
| Coinbase 對 Code Connect（9 月 2 日） | Pitre 的 DS Contracts（7 月 26 日） | |
|---|---|---|
| 做的事 | 把設計元件對映到真實程式碼元件 | 以機器可讀契約描述元件的屬性、token、狀態，並用確定性檢查比對 |
| 量什麼 | token、時間、成本，加元件與 token 使用的正確性 | 單一綜合分數與違規數 |
| 公開的細節 | 三次重複、同設計同提示、空白程式碼庫，只給平均 | 沒有模型、次數、評分規則 |
| 利益關係 | 設計系統團隊自己的使用評測，刊在 Figma 部落格 | 廠商自家專案 |
| 對 Guidelines 的啟示 | 要同時量成本與正確率 | 要讓代理有「拒絕」的選項，並量拒絕次數 |
Friedman 文章裡有一句值得抄的話：「權限屬於能確定性地拒絕的那一層，而不是指示得最大聲的那一層。模型可以被說服繞過，但結構描述不行。」他的結論是用 AI 撰寫規格，用確定性工具執行檢查。這和 Figma 的 Guidelines 是一條對照：Guidelines 是指示，要靠代理自覺遵守；Code Connect 與契約是結構，不遵守就會被擋或會報錯。昨天寫的「需人判斷」那一類規則，Guidelines 只能請代理盡量遵守，真正的把關還是要放在機器能拒絕的層。
Config India 的新資訊，我只放能對上報導的。TechCrunch 引述 Figma 首席設計長 Loredana Crisan：現在產出的程式碼行數是過去的 17 倍，但釋出次數只有 1.3 倍，所以程式碼更多是用來探索。我自算 17 除以 1.3 約 13.1，也就是「寫得多」與「放出去」之間差了十幾倍；這是高階主管的說法，文中沒有給資料來源或衡量範圍，只能當觀點。MCP 新增超過 20 個工具，報導沒有逐項列名。Specs 與 Guidelines 的關係，我讀到的報導沒有說清楚兩者分工，我自己的解讀是：Specs 偏人與代理共讀的設計意圖文件，Guidelines 偏代理執行時的規則，但這是推測，請以 Figma 說明中心為準。
三、Intelligent UI：答案直接長成介面
OpenAI 在 10 月 7 日開始把 GPT-6 推進 ChatGPT，同時推出 Intelligent UI。依 Digital Applied 整理，Plus、Pro、Business、Enterprise 在 10 月 7 日先用 GPT-6 Sol，Free 與 Go 在 10 月 8 日用 GPT-6 Luna，只限 Chat 分頁；功能涵蓋從 Instant 到 Extra High 的推理強度，Pro 的 Astra 推理選項沒有這個功能，目前沒有讓使用者關掉視覺元件的開關（依該文撰寫時的文件）。實作上有三塊：一個原生元件庫（圖形、可點按鈕、表單、圖表與互動體驗，例如比較表、互動圖解、食譜計時器、帶註記的地圖、計算機與分帳工具）、一個在模型生成時邊產生邊渲染的編譯器，以及訓練模型決定內容、版面、視覺與互動的方法。OpenAI 自己也承認「模型的設計判斷還有進步空間」，另外比較表要選哪些來源、商品怎麼進入互動式答案，目前沒有公開說明。「12 億以上每週使用者」是產品整體數字，不是這個功能的使用量，不要混用。
設計上最值得注意的是第一點：它不是任意畫像素，而是從固定元件庫挑選。這和前幾天寫的 Code Connect、Guidelines 是同一個架構的另一個端點。設計系統團隊用元件庫約束代理，OpenAI 用元件庫約束自家模型，差別是前者的使用者是團隊內的設計師與工程師，後者的使用者是十幾億人。元件庫一旦是封閉的，這個產品能表達什麼，就等於元件庫能表達什麼；比較表有沒有「不確定」的狀態、圖表有沒有資料來源欄位，都是元件庫的設計決策，不是模型的決策。
Process to Pixels 電子報（作者 Demchenko）把這件事寫成信任問題：「一個整齊的互動式比較表，可以讓答案顯得比它實際上更值得信任。」她的整理還有兩個相關的觀察。一是 10 月 8 日 Anthropic 的 Claude Dashboards：描述想看的資訊就產生有時間戳的圖表，點任何一個數字會顯示底層查詢，並能向非技術的檢視者解釋 SQL，資料權限依檢視者逐一套用；二是 Claude Motion：用程式碼產生動畫，匯出 MP4 前仍可編輯，解決「改一個標籤就得整支重生」的問題，僅限 Team 與 Enterprise 方案。這兩項我只讀到電子報的轉述，沒有查原始發表頁，但「點數字看來源」與「產出前可編輯」是兩個很具體的互動模式。她的結論是「預覽再執行」：例如 The Drive AI 在動手前先列出預計的檔案變更並可還原，設計決策要放在使用者能看到、檢查與復原什麼。
把這幾個觀察合起來，可以對任何「生成式介面」問五個問題，我整理成一張檢查表，這是我的歸納，不是任何一家的標準：
| 問題 | 為什麼要問 | 好的答案長什麼樣 |
|---|---|---|
| 數字從哪裡來？ | 整齊的圖表會被當成可信的 | 點數字能看到來源或查詢（Claude Dashboards 的做法） |
| 它有沒有「不確定」的外觀？ | 元件庫若只有確定的樣式，所有答案都長得一樣有把握 | 有低信心與缺資料的元件狀態 |
| 動手前能預覽嗎？ | 代理行動不可逆時，事後解釋來不及 | 先列變更、可還原 |
| 不想要互動元件時能關嗎？ | 目前 ChatGPT 沒有開關，螢幕閱讀器與純文字偏好者沒有退路 | 提供純文字等價 |
| 語意與焦點順序是否正確？ | 畫面正確不代表輔助科技讀得到 | 元件本身帶標籤與鍵盤操作 |
第五點不是我替 OpenAI 下結論：我沒有查到 Intelligent UI 元件的無障礙說明，所以只能寫「沒查到」。Smashing 10 月 6 日那期電子報有一則相關提醒，說 AI 產生的介面常常看起來正確，但輔助科技依賴的語意資訊不存在，並分享了一個五層的語意正確性把關做法；我只讀到電子報的摘要，沒有讀內文。
另一份資料可以當對照：Romina Kavcic 在 6 月 1 日分析了 156 套公開設計系統，其中 26 套記載 AI 元件與用法，自算 26 除以 156 約 16.7%（文中沒有寫挑選標準，也沒有取得「一年前」的對照數字）。她歸納四條規則：每次都標示 AI 產出、分層解釋（是什麼、為什麼、怎麼做）、讓人保持控制、為「它出錯的那一刻」設計。拿這四條對 Intelligent UI，第一條與第四條是目前最看不到的：答案長成互動元件之後，哪些部分是模型的判斷、哪些是固定的計算邏輯，從畫面上看不出來。這是我讀了公開資料後的觀察，不是 OpenAI 的說法。
四、合成受訪者：答案很像，種類少很多
NN/G 在 10 月 16 日發表 Rachel Banawa 的《Synthetic Users vs. Human Respondents: Same Conclusion, Less Variation》。研究設計很單純：沿用一份舊問卷的題目，「你認為下列工作最適合歸在哪個專業領域」，原本有 604 位科技與設計從業者回答；這次用 Synthetic Users 平台產生 120 個合成受訪者回答同一題。
| 真人 | 合成 | |
|---|---|---|
| 人數 | 604 | 120 |
| 不同的標籤數 | 50 種以上 | 12 種 |
| 歸為 UX 相關名稱的比例 | 約 70% | 84% |
兩組得到的主結論相同，但合成組的答案種類少很多，這就是 NN/G 說的模式崩塌（mode collapse）：只產出最常見的答案，掉了長尾。真人組有「數位體驗策略」「人因工程」這類專門說法，合成組沒有。自算兩件事：12 除以 50 是 24%，因為真人是「50 種以上」，所以合成組的答案種類至多只有真人的四分之一；兩組「UX 相關」的比例差 14 個百分點。若硬把兩組當簡單隨機樣本算 95% 信賴區間（這個前提對合成組並不成立，所以只是示意），真人約 70% 加減 3.7 個百分點，合成約 84% 加減 6.6 個百分點，兩個區間不重疊，但合成不是抽樣，區間本身沒有意義，真正該看的是長尾。
長尾為什麼對可用性測試重要，可以用 Nielsen 的找問題算式示意：某個問題影響 5% 的使用者，測 n 位時至少撞見一次的機率是 1 減 0.95 的 n 次方，n 為 5、15、20、60 時分別約 22.6%、53.7%、64.2%、95.4%。這是我的假設情境，不是 NN/G 的數據：如果合成受訪者的行為本來就偏向多數答案，那麼它發現「罕見但嚴重」的問題的機率，會比這條曲線更低。NN/G 的建議也是這個方向：用合成受訪者「產生假設或檢查大方向」，「當長尾重要時，需要真人參與者」，把合成的發現當作「起點，而不是使用者怎麼想、怎麼說、怎麼做的證據」。
這和第二節是同一個道理：只量平均、不量離散，就看不到代理或合成使用者「集中在最常見答案」這件事。昨天提醒過三次重複的平均看不出離散，今天這份資料是一個反面例子：連主結論都一致的資料，也可能少了四分之三的種類。
五、59,400 個電商商品頁：數字可以自己核對
Dave Davies 的《State of Ecommerce Accessibility 2026》掃描 59,400 個商品頁，來源是 HTTP Archive 的全球前百萬網站資料，其中 Shopify 39,976 頁、WooCommerce 19,424 頁（加起來剛好 59,400，自算 Shopify 占 67.3%）；工具是 Lighthouse 13.4.1 與 axe-core 4.12.1，手機版，稽核期間 7 月 29 日至 8 月 4 日。
| 問題 | 報告的比例與頁數 | 自算占比 |
|---|---|---|
| 文字對比不足 | 80%（47,479 頁） | 79.9% |
| 連結沒有名稱 | 53%（31,636 頁） | 53.3% |
| 標題層級問題 | 49%（28,948 頁） | 48.7% |
| 點擊目標不足 | 32%（18,790 頁） | 31.6% |
| 標籤與名稱不一致 | 28%（16,598 頁） | 27.9% |
| 圖片缺替代文字 | 27%（16,107 頁） | 27.1% |
整體有 64% 的頁面至少有一個嚴重問題（約 37,874 頁，自算 63.8%），96% 至少沒通過一項自動檢查，兩者差 32 個百分點，也就是「沒通過但不算嚴重」的頁面很多。有兩個發現值得記。第一，流量越高越糟：前十萬名網站的頁面 69% 有嚴重問題，其餘 63%，差 6 個百分點，報告稱這違反直覺，但原因文中沒有解釋，我不推測。第二，偵測到無障礙覆蓋工具（overlay）的 1,691 頁中，仍有 62% 至少一個嚴重問題。我自算一個對照：1,691 頁約占全部的 2.8%，這些頁面約 1,048 頁有嚴重問題；剩下 57,709 頁約 36,826 頁有，占比約 63.8%。也就是有裝覆蓋工具的頁面（62%）和其他頁面（63.8%）幾乎沒有差距。這是觀察性資料，裝覆蓋工具的商店本身可能不同，不能說覆蓋工具「沒有用」，只能說在這份樣本中，沒有看到它讓嚴重問題變少。
這份報告的限制要寫在前面：只用自動化工具，沒有人工檢查；10 月 17 日引過 Deque 的數字，自動化大約只能抓到約 57% 的問題（那一篇有出處），所以這裡的比例是「自動工具看得到的下限」，不是真實的全貌。另一個連結是昨天算的 WCAG 2.5.8：24 CSS 像素最小目標，等於約 6.35 毫米；這份報告的「點擊目標不足」有 32% 的頁面，但它用的是哪一條門檻（Lighthouse 與 axe 各有自己的規則與版本），我沒有讀到，所以不能和 2.5.8 直接畫等號。這份清單對設計系統的啟示很實際：對比、連結名稱、標題層級、替代文字，都是元件層級就能解決的問題，一個元件庫如果把「連結必須有可讀名稱」做成元件的必填屬性，就能一次擋掉 53% 那一類。
六、Windows 11 相片 App：以任務分類的編輯器
Microsoft 在 10 月 15 日發表重做的相片 App，先給 Windows 測試人員，年內擴大給所有 Windows 11 使用者。三個部分的設計決定都有明確的說法：
Gallery 把電腦、OneDrive 與 Apple iCloud 的相片放進同一個介面，加入以人物為主的瀏覽與篩選（依相片存放位置與人物縮小範圍）、相簿、我的最愛、OneDrive 的「回憶」功能，以及自然語言搜尋（例如「湖邊的家庭野餐」）。Editor 的工具改成「四類、依你想完成的事組織」：裁切、增強、修復、風格化；去除物件可用圈選或塗抹，Relight 可放置最多三個光源、設定顏色並選擇對焦點，並保留 HDR 與 HEIC、WebP 格式。Viewer 把重點放在相片本身：「一個選單收納導覽與 App 選擇，不擠壓相片」，細節（檔名、日期、相機資訊、地圖、直方圖、視覺搜尋）收在資訊按鈕，用方向鍵快速切換。
效能數字是 Editor 啟動快 25%、Viewer 平均啟動快 15%、HEIC 最多快 30%，條件是 Microsoft 在受控環境下，跨 x64 與 ARM64 裝置，與相片 App 版本 2026.11060 比較，「實際效能依裝置而異」。我自算一個提醒：「快 25%」有兩種讀法，若是啟動時間減少 25%，以 2.0 秒為例是 1.5 秒；若是速度提高 25%（時間除以 1.25），則是 1.6 秒，差 0.1 秒，原文沒有定義，我也沒有看到絕對秒數，2.0 秒只是示意的假設。
從設計角度，我覺得最可拿來用的是 Editor 的分類方式。很多編輯器的工具列是依技術分（濾鏡、調整、標記），這次依使用者的意圖分（裁切、增強、修復、風格化），一個新手要「去掉背景裡的路人」，不需要知道那叫哪種工具，直接進「修復」。它的代價是跨類的操作（例如先增強再修復再裁切）要來回切換，這是我的推論；我只讀了 Microsoft 的發表文，沒有實際操作，所以不知道切換是否順暢。另一個值得學的是 Viewer 的單一選單：把「導覽」與「換 App 開啟」收在同一個地方，把相片留白。對照昨天談的 Live Activities 限寬版面，這兩個案例有同一個邏輯：空間有限時，把次要的功能收進一個入口，不是縮小全部。
七、把這幾塊合成一份增補規則
延續昨天的四條規則與三級檢查（機器可檢查、需人判斷、需真人測試），今天可以補四條：
| 規則 | 前提 | 等級 | 通過範例 | 失敗範例 |
|---|---|---|---|---|
| 代理必須有「拒絕」出口，並統計拒絕次數 | 用契約或 Code Connect 約束代理 | 機器可檢查 | 缺元件時回報缺口 | 找不到就自己拼一個 |
| 圖表與數字可點開看來源 | 生成式或代理產出的畫面 | 需人判斷 | 點數字顯示查詢或資料表 | 只有一張整齊的圖 |
| 元件庫有「不確定」與「缺資料」狀態 | 元件由模型挑選並填入 | 需人判斷 | 低信心時外觀不同 | 所有答案長得一樣有把握 |
| 連結與按鈕的可讀名稱做成必填屬性 | 元件庫自己控制 API | 機器可檢查 | 缺名稱時編譯錯誤 | 靠頁面作者自己記得填 |
這份表是我整理的建議，不是任何一家的官方標準。最後一條的依據是前面那份 59,400 頁掃描：連結沒有名稱是第二常見的問題，而它是元件 API 能直接杜絕的那種。
🧠 記
- Pitre 的 DS Contracts 測試（7 月 26 日）： 沒治理代理 69 分、90 項違規；契約目錄 100 分；模型、次數、評分規則皆未公開，廠商自家專案。自算：100 減 69 為 31 分，90 項違規若線性扣分每項最多約 0.34 分，所以評分不是單純線性。
- Friedman 的結論（7 月 29 日）： 用 AI 撰寫規格，用確定性工具執行；權限屬於「能確定性拒絕的那一層」。
- Figma Config India（10 月 14 日，TechCrunch）： Code layers 進入開放測試；Specs 為 Markdown 編輯器；MCP 新增逾 20 個工具；主管說程式碼行數 17 倍、釋出 1.3 倍（自算比值約 13.1）。
- ChatGPT Intelligent UI（10 月 7 日起）： 固定元件庫加邊生成邊渲染的編譯器；付費方案 10 月 7 日、Free 與 Go 10 月 8 日；目前沒有關閉開關；元件的無障礙說明沒查到。
- NN/G 合成受訪者（10 月 16 日）： 120 個合成對 604 位真人；答案種類 12 種對 50 種以上；UX 相關 84% 對約 70%；結論一致但長尾消失。自算：5% 的問題測 5、15、20、60 人至少撞見一次的機率約 22.6%、53.7%、64.2%、95.4%（假設情境）。
- 電商無障礙報告： 59,400 頁；64% 有嚴重問題、96% 至少一項自動檢查沒過；對比 80%、連結名稱 53%；有覆蓋工具的頁面 62% 對其他頁面自算約 63.8%。
- Windows 11 相片： Editor 分裁切、增強、修復、風格化；Viewer 單一選單；啟動快 25%、15%、HEIC 最多 30%，原文沒定義「快」。
- USWDS： 10 月 5 日是清單中最新的貼文（社群點子），維護者最新貼文仍是 9 月 22 日；9 月 18 日至今 31 天。
邊界： 本文所有網頁內容（TechCrunch、Digital Applied、Process to Pixels、NN/G、Windows 部落格、Pitre 與 Friedman 與 Kavcic 的文章、Dave Davies 報告、MacRumors、Blake Crosley、Apple 開發者頁、GitHub 討論區清單、Smashing 電子報）都經網頁抽取摘要，沒有讀完整原文，也沒有實際操作 Figma、ChatGPT 或 Windows 相片 App。Pitre 的測試是廠商自家專案，評分規則未公開；Intelligent UI 的元件細節來自第三方整理，不是 OpenAI 原始發表頁；Claude Dashboards 與 Motion 只來自電子報轉述；Demchenko 的引文是我對抽取摘要的中譯，請回原文確認。NN/G 的信賴區間只是示意，因合成受訪者不是抽樣；1 減 0.95 的 n 次方是假設情境。電商報告只用自動化工具，且我沒有查 Lighthouse 與 axe 點擊目標規則的門檻，不能與 WCAG 2.5.8 對等。Microsoft 的效能數字出自發表文，「快」的定義未寫，2.0 秒是示意假設。USWDS 的「沒有更新」只是我在公開清單上沒看到，不代表沒有；GSA 回應沒查到。
✍️ 實踐
用 30 分鐘，替你團隊正在用或打算用的「生成式介面或代理產出的畫面」做一次可信度盤點，並算一次自己的長尾。
- 選一個代理或模型會產生畫面的流程（可以是 Figma 的代理、ChatGPT 的互動答案，或自己的內部工具）。
- 用第三節的五題檢查表，每題打 0（沒有）、1（部分）、2（完整），滿分 10。把「沒有」的項目寫成一句待辦，例如「圖表缺來源欄位」。這是我的歸納，用來找弱項，不拿來跨產品比分。
- 對你的元件庫，列出「連結、按鈕、圖示按鈕」三種元件，檢查可讀名稱是不是必填屬性；不是的，寫下改成必填需要動幾個元件。
- 算一次你自己的長尾：把最近一輪使用者測試的問題清單，標出每個問題被幾位受測者撞見，找出只被撞見一次的，再用下面這段程式算「若只測 n 位會漏掉它的機率」。
// 影響比例 p 的問題，測 n 位時至少撞見一次的機率
const hit = (p, n) => 1 - Math.pow(1 - p, n);
for (const n of [5, 15, 20, 60]) {
console.log(n, (hit(0.05, n) * 100).toFixed(1) + '%');
}
// 預期:
// 5 22.6%
// 15 53.7%
// 20 64.2%
// 60 95.4%- 把 p 換成你自己的估計（例如 0.1 或 0.02），並記下：這個算式假設每位受測者獨立、問題影響比例固定，真實情況不會這麼乾淨。
- 如果你有用合成受訪者或模擬使用者的工具，拿同一批題目讓它與真人各回答一次，只比一件事：不同答案的種類數。若合成組的種類少到只剩四分之一左右，就當它是產生假設的工具，不當證據。
- 對照昨天的「有無 Guidelines」測試，在記錄表多加一欄「拒絕次數」：代理有幾次明說「我做不到、缺元件」。拒絕次數為零不一定是好事，可能是它在硬湊。
🔗 延伸學習
- ChatGPT’s Intelligent UI: What Interactive Answers Change（Digital Applied） — 元件庫、編譯器、推出時程與已知限制的整理。
- Answers are turning into interfaces, and agents are learning where to stop（Process to Pixels） — 「整齊的比較表比它值得的更可信」與預覽再執行的設計論點。
- Synthetic Users vs. Human Respondents: Same Conclusion, Less Variation（NN/G） — 120 個合成對 604 位真人的研究設計與建議。
- State of Ecommerce Accessibility 2026（Dave Davies） — 59,400 頁掃描的方法與逐項數字。
- Meet the new Photos app on Windows 11（Windows Experience Blog） — Gallery、Editor、Viewer 的設計說明與效能測試條件。
- How To Use AI To Need Less AI（TJ，Southleft） — 契約目錄 69 對 100 的 A/B 測試，作者自己要求「帶著懷疑讀」。
💬 問 AI
我想判斷「生成式介面」與「代理產出的畫面」的可信度與可量測性。請嚴格分成「文件明說」「你查證到的」「你的推論」三區回答,不確定就直說,不要編造連結、數字、版本號或引文,也不要給任何投資或財務建議。
背景(請當待查證主張):
1. TJ(Southleft)2026-07-26 文章:A/B 測試中,沒有治理的代理畫畫面得 69/100、90 項違規(編造屬性、寫死顏色、改寫元件樣式),使用契約目錄的代理得 100/100;Vitaly Friedman 2026-07-29 引用。我不確定模型、次數與評分規則。
2. OpenAI 自 2026-10-07 起在 ChatGPT 推出 Intelligent UI:固定的原生元件庫加邊生成邊渲染的編譯器;付費方案 10 月 7 日、Free 與 Go 10 月 8 日;沒有使用者關閉開關。
3. NN/G 2026-10-16:120 個合成受訪者對 604 位真人,不同答案 12 種對 50 種以上,UX 相關名稱 84% 對約 70%,結論一致但長尾消失。
4. Dave Davies 掃描 59,400 個電商商品頁(Lighthouse 13.4.1、axe-core 4.12.1,2026-07-29 至 08-04):64% 有嚴重問題、96% 至少一項自動檢查沒過、對比不足 80%、連結沒有名稱 53%;偵測到覆蓋工具的 1,691 頁中 62% 仍有嚴重問題(我自算其他頁約 63.8%)。
請做:
A. 逐點驗證 1 到 4,標示「成立/部分成立/查不到」並附一手連結;特別確認第 1 點的測試細節與第 2 點元件的無障礙說明(焦點順序、螢幕閱讀器標籤、純文字替代)。
B. 針對第 1 點:「允許代理拒絕」的條件下得到 100 分,為什麼不能直接視為「更好」?請設計一個同時量「交出可用畫面的比例」與「拒絕次數」的評分方式。
C. 針對第 3 點:模式崩塌對可用性測試的哪些階段影響最大(探索、驗證、回歸)?哪些階段仍可用合成受訪者?
D. 針對第 4 點:檢查我「覆蓋工具頁面與其他頁面差距很小」的算法與解讀有哪些偏誤,以及自動化掃描的涵蓋上限如何影響結論。
E. 為「連結與按鈕的可讀名稱做成元件必填屬性」「圖表數字可點開看來源」「元件庫有不確定狀態」三條規則,各寫前提、通過與失敗範例,並標出屬於機器可檢查、需人判斷或需真人測試。
不要評論公司或人事,只談設計實務、量測方法與證據強度。