這一系列從 10 月 16 日的 Specs、昨天的 Guidelines 一路談到「規則寫給代理讀」，一直缺一樣東西：有沒有人量過代理到底照不照做。今天找到最接近的一份：Figma 在 9 月 2 日公開的 Coinbase 設計系統團隊評測，三次重複測試，Code Connect 讓平均 token 用量降 11.5%、實作時間降 22.3%、成本降 22.5%，並同時比較元件選擇與 token 使用的正確性。它量的是 Code Connect，不是 Guidelines，但測法可以直接搬去量 Guidelines。
另一條線是昨天只讀過二手報導的 USWDS。今天讀到 GitHub 上兩篇原始貼文（9 月 18 日的進度更新、9 月 22 日的優先事項），有幾處與昨天寫的時間線要修正，也有幾個設計系統實務上值得抄的做法，例如「建置遇到稽核錯誤就失敗」「無障礙掃描要涵蓋開著的對話框」。第三塊是 Apple：10 月 13 日 HIG 同時改了 Widgets（加入 HomeView）與 Live Activities（加入限寬版面），後者的 iOS 27 橫向 Dynamic Island 規則，和 HomeView「2 公尺外只放得下兩個字」是同一類設計問題。先對帳，再依序講這三塊。
📖 學
一、昨天待驗的對帳
| 昨天的待驗 | 今天查到 | 狀態 |
|---|---|---|
| HomeView 的 pt 規格 | Blake Crosley 的開發者上手整理（10 月 13 日發表、14 日更新）寫：發表當天沒有 HomeView SDK、模擬器、Xcode 27.2 beta 1 平台目標，也沒有設計套件或機身模板；WidgetLocation 沒有 homeView 這個值；沒有 HomeView 專屬的 HIG 頁，只有 Widgets 頁新增段落 | 仍未公布，維持待驗 |
| Modular face 實際排列 | HIG 的文字是：小型系統家族、「放大並移除背景」，最多四個；Apple 要開發者把小工具背景標成「可移除」，才能出現在 StandBy 與這個面。排列與邊距仍無 | 部分有資料，排列待驗 |
| 11 月 13 日實機字高 | 尚未出貨 | 待驗 |
| 歌詞規則是否放寬 | 沒有新資料 | 查不到 |
| Guidelines / Specs 的代理遵守率 | Figma 沒有公布；但找到 Coinbase 對 Code Connect 的評測（第二節） | Guidelines 本身查不到 |
| Guidelines 的檔案格式與上限 | 說明中心只寫：專業、組織、企業方案、開放測試、需編輯權限；耗點數依「模型、任務複雜度，以及指南的數量、大小與複雜度」而定；沒有寫格式、命名或大小上限 | 確認文件沒寫 |
| Modular face 是否受認人把關 | 沒有新資料 | 待驗 |
| USWDS 10 月 9 日後動態與 GSA 回應 | 沒有找到 GSA 的回應；shipping news 頁最新條目是 9 月 17 日、沒有 10 月條目；9 月 18 日進度更新承諾「每兩週更新」，照此 10 月 2 日、10 月 16 日前後該有下一篇，我沒有在已讀頁面看到 | 查不到，維持待驗 |
| Matt Henry 的 30% 原始出處 | 搜尋結果仍只有 FedScoop 與其他媒體的轉述 | 查不到 |
這張表的整體結論是：真正會動的是「有沒有文件」，不是「有沒有新數字」。HomeView 的設計資料一天比一天多，但全部是文字規則，沒有尺寸；Figma 的代理規則一樣，只有功能說明，沒有量測。
二、Coinbase 的評測：量代理怎麼量
Figma 部落格《How Coinbase Used Code Connect to Guide Agents and Shrink Token Costs》（9 月 2 日）與同日網路研討會是目前最完整的公開評測。我讀到的是網頁抽取摘要，沒有看到逐次原始數據，以下數字都是文中的「平均」。
測法的重點是控制變因：同一份設計、同一個提示（刻意寫得含糊，大意是「把這個 Figma 設計做出來」）、同一個模型、每次都在空白程式碼庫開始、跑完就重置，三次重複；設計複雜度取中間值，避開過簡或過繁；提示快取（prompt caching）也刻意管理，避免干擾成本。比較的是有無 Code Connect。量測有兩類：一是花費（token、時間、成本），二是品質（是否選對元件而不是自己拼基本元件、是否用對 token 與語意色與尺寸規則、圖示與插圖名稱是否被代理亂編）。
| 指標 | 有 Code Connect 相對於沒有 |
|---|---|
| 平均 token 用量 | 降 11.5% |
| 平均實作時間 | 降 22.3% |
| 平均成本 | 降 22.5% |
| 三次重複 | 三次所有指標都改善 |
| 品質 | 元件選擇更正確、更貼近設計系統、圖示名稱不再亂編（摘要為定性描述，沒有給比例） |
我自己算了一個衍生數字。成本降 22.5%、token 降 11.5%，若把基準都設為 100，成本為 77.5、token 為 88.5，每單位 token 的成本比值是 77.5 除以 88.5，約 0.876，也就是每個 token 平均便宜約 12.4%。這個差距的可能原因我只能推論：有 Code Connect 時代理不必寫出大量基本元件，產出的 token 占比下降，而輸出 token 通常比輸入 token 貴；但文中沒有 token 的輸入輸出拆分，所以這只是假說。時間降幅（22.3%）也幾乎是 token 降幅的兩倍，可能是迭代與修正次數變少，同樣沒有逐次紀錄可以驗證。
這份評測有三個限制必須說在前面。第一，三次重複的平均，看不出每次之間的離散程度；三個值平均 22.5%，可以是 20、22、25，也可以是 10、22、35。第二，量的是 Code Connect（把設計元件對映到真實程式碼元件），不是 Guidelines（寫成 Markdown 的規則），兩者補的脈絡不同：前者回答「這個元件在程式碼裡叫什麼」，後者回答「這種情境該不該用它」。第三，我讀到的幾個摘要對所用的模型名稱不一致，所以我不寫模型名稱，要引用請回原文確認。Coinbase 設計系統技術負責人 Erich Kuerschner 的建議也值得記：就算未來代理強到不需要，也不要拿掉 Code Connect，否則「代理會亂來」。
Guidelines 還沒有這種公開評測，但這套測法可以直接複製。把「有沒有附 Guidelines」當自變數，把三項指標定義清楚：必用元件選對的比例、token 或語意色用對的比例、被編出來的元件或圖示名稱數量，再加上「每個選對的元件花多少點數」。最後一項最容易被忽略。Figma 已明說附 Guidelines 的提示「可能多耗點數」，所以「每次花得更多」是預期結果，真正要回答的是「每個答對的東西，成本有沒有下降」。下面用一組假設數字示意：
| 假設的三次結果（每次 10 個必用元件） | 沒有 Guidelines | 有 Guidelines |
|---|---|---|
| 每次選對的元件數 | 7、6、8 | 9、9、10 |
| 平均選對比例 | 70.0% | 93.3% |
| 每次點數 | 10、12、11（平均 11） | 14、13、15（平均 14） |
| 每個選對元件的點數 | 11 除以 7，約 1.57 | 14 除以 9.33，1.50 |
這組數字是我編的示範，不是實測，用意是顯示：有 Guidelines 的提示每次多花 3 點（上升 27%），但只要正確率提升夠多，每個選對元件的成本反而略降約 4.5%（1.50 除以 1.57 為 0.955）。反過來，正確率只從 70% 升到 75%，這個結論就會翻轉。這就是要同時量兩邊的原因。三次重複只能當篩檢，不能當統計顯著；樣本要更多、換設計、換提示、換模型才有說服力，Coinbase 自己也只是做了三次。
另一份整理是 DesignWhine 在 10 月 8 日的文章，主張 Figma 在把「治理」變成產品行為，提出五層結構：資產（元件、變數、樣式）、語意（命名、描述、關係）、政策（Guidelines、反例）、執行（代理做維護）、橋接（MCP、Code Connect 對映）。文中也附一份八項「代理就緒度」檢查：標準資產、已寫明的意圖、機器可讀的規則、設計與程式碼對映、可審查的批次修改、漂移偵測、輸出評估、治理是否被保留。最後一句話值得抄下來：「AI does not make design-system ambiguity disappear. It gives ambiguity a faster execution engine.」這是文章作者的評論，不是 Figma 的聲明；八項的評分方式也是作者的框架，不是業界標準，我把它放進下面的實踐。
三、USWDS：兩篇原始貼文讀到了什麼
昨天的時間線全部來自 Nextgov、FedScoop 與 Wikipedia 的二手整理。今天讀到 GitHub 上兩篇原始貼文（同樣是網頁抽取摘要，不是完整原文），有幾處要修正。
首先是日期。昨天我寫「9 月 25 日 Parker 在 GitHub 貼出 our priorities」，那是 FedScoop 報導的日期；GitHub 討論頁顯示這篇貼文是 9 月 22 日，作者是 Ryan Parker，標示為維護者。四項優先事項是：無障礙測試工具（原文「Automate as much accessibility testing as possible across current and future USWDS versions」）、USWDS 3 的改善（檢視未結議題，交付選定的無障礙與可用性改進並附清楚的版本說明）、語意化版本（版本一致、公開介面明確、提供升級指引）、下一版本探索（徵詢實作選項，包括 USWDS Elements 與 AI 工具相容性）。貼文提到穩定版是 3.14.0，待處理的貢獻包括對話框的鍵盤焦點與日期選擇器的朗讀提示，並承諾每兩週在討論區更新，且區分「已審查」「已合併」「已發佈」三種狀態。9 月 25 日有一位維護者（ajfarkas）留言，質疑利害關係人的意見怎麼收、哪些機構影響了優先事項。
接著是 9 月 18 日的進度更新（作者 Ryan Parker，共同維護者列 Sam Corcos），內容比報導多出一組可驗證的工程細節：
| 項目 | 原文要點 |
|---|---|
| 建置 | Sass 錯誤與稽核錯誤會讓建置失敗 |
| 無障礙掃描 | 範圍擴大到開啟中的對話框 |
| 測試 | 新增測試鎖定套件匯出與編譯後的 JavaScript 包 |
| 流程 | 拉取請求自動程式碼審查、標題格式規範、壓縮合併加最後審查 |
| 修正 | 表格排序樣式、組合框驗證樣式 |
| 積壓 | 未結議題從 219 降到 118；未結拉取請求 66 個（原 53 個） |
| 無障礙方針 | 維持 Section 508 與既有 WCAG 2.1 AA 目標；公開路線圖有詳細測試計畫；原文「No version ships without the full accessibility testing USWDS is known for」 |
| 版本 | 3.14.0 仍是目前穩定版，沒有新版 |
兩處我自己算。未結議題 219 降到 118，減少 101 個，101 除以 219 約 46.1%；未結拉取請求從 53 增到 66，增加 13 個，13 除以 53 約 24.5%。更新沒有寫這段是多長時間內發生的，也沒有拆「關閉」與「歸檔或合併」，所以不能據此說審查品質變好或變差，只能說工作隊列在短時間內大幅重組。另外注意這篇與昨天的報導有一個落差：兩篇貼文的抽取內容沒有出現 Codex 與 CodeRabbit 這兩個名字，只寫「自動程式碼審查」與「code review skill」；工具名稱來自 FedScoop。我沒有讀完整的原始貼文，所以不能斷定原文沒有。互動量也值得一記：9 月 18 日的更新在我讀到的時間點是 4 則留言、9 則回覆、5 位參與者，優先事項貼文是 1 則留言與 1 則回覆，與社群複本計畫的規模（約 200 人）差距很大；這只是讀取時點的數字，無法判斷原因。
從設計系統實務看，這兩篇貼文有三件事值得單獨拿出來講，與誰當負責人無關。第一，掃描要涵蓋狀態。多數設計系統的元件，出問題的往往不在初始畫面，而在「打開之後」：對話框、下拉選單、日期選擇器、提示框。更新說無障礙掃描擴大到開啟中的對話框，這正是把元件的狀態納入檢查範圍；元件庫自己的測試矩陣應該列出每個元件的狀態清單，再逐一對應掃描。第二，把稽核錯誤變成建置失敗。把「建議修」升級成「不修就不能出貨」，是把品質判準寫進流程，不依賴任何人記得去看；代價是誤報會直接擋住發版，所以要有可記錄的豁免機制。第三，把「已審查、已合併、已發佈」分開講。許多設計系統的使用者分不清「這個修正有沒有到我的版本」，三態分開報告，下游才知道什麼時候該升級、升級後該重測什麼。
目標標準也有一個值得注意的差異：USWDS 這篇更新寫的是 WCAG 2.1 AA，昨天讀到的 OGDS README 則要求自訂版通過 WCAG 2.2 或 Section 508。2.2 相對 2.1 新增 9 項成功準則、並讓 4.1.1（剖析）失效；算式是 78 加 9 減 1 等於 86（這是我依記憶的準則數推算，沒有回 W3C 原文核對）。其中新增的 A 與 AA 級共六項，我依「誰能檢查」做了一份分類，這是我自己的判斷，不是 W3C 或任何工具的官方分級：
| 新增準則（等級） | 要求 | 機器能做到 | 仍需人或真人 |
|---|---|---|---|
| 2.4.11 焦點不被遮住（AA） | 取得焦點的元件不被固定標頭等完全蓋住 | 部分：能量出重疊 | 要用鍵盤實際走過各種捲動位置 |
| 2.5.7 拖曳動作（AA） | 拖曳操作要有單指標替代 | 很有限 | 要判斷拖曳是否唯一路徑 |
| 2.5.8 目標尺寸（最小）（AA） | 目標至少 24 乘 24 CSS 像素，有例外 | 大部分：量幾何 | 例外（間距、行內）要人判斷 |
| 3.2.6 一致的說明（A） | 說明入口在各頁位置一致 | 很有限 | 跨頁比對 |
| 3.3.7 避免重複輸入（A） | 同一流程不要再要求輸入已填過的資訊 | 很有限 | 要走完流程才知道 |
| 3.3.8 無障礙驗證（最小）（AA） | 登入不能只靠記憶或轉錄的認知測驗 | 幾乎沒有 | 要真人流程測試 |
順手把 2.5.8 換算成實體尺寸。CSS 像素定義為 1/96 英寸，24 像素等於 24 除以 96 乘以 25.4，約 6.35 毫米；在 220 ppi 的 HomeView 螢幕上相當於 6.35 除以 25.4 乘以 220，等於 55 像素，1,088 像素的邊長最多排 19 個（1,088 除以 55 約 19.8）。6.35 毫米約是前面討論過的 9 毫米觸控目標的 70.6%。這裡有兩個提醒：2.5.8 規範的是網頁內容，HomeView 原生 App 不適用，這只是一個「最低標」的實體參照；而 9 毫米那個基準，是 10 月 14 日篇推算 Material 48 dp 時用的近似值，今天沒有重新查證。
四、Apple：限寬版面與 HomeView 是同一類問題
Apple 開發者網站「What’s new」頁在 10 月只有兩筆，都在 13 日：Widgets（加入 HomeView 指引、更新 watchOS 規格）與 Live Activities（加入限寬版面指引、更新支援平台與規格）。截至今天沒有第三筆，也就是 HomeView 專屬頁面還沒出現。
Live Activities 這筆對應 WWDC26 第 223 場「Live Activities essentials」。依該場摘要，iOS 27 的 Dynamic Island 精簡與最小化樣式在直向與橫向都可見；直向時精簡樣式寬度有彈性，橫向時沒有空間可變寬，所以環境值 isDynamicIslandLimitedInWidth 為真時，精簡樣式要換成更窄的替代版。場次的示範程式做的是：限寬時顯示步驟進度圖示，不限寬時顯示預計完成時間或階段文字。摘要裡還有一句設計哲學：較大的樣式放比較豐富的狀態與脈絡，精簡與最小化樣式只放最必要的訊號。另外兩個細節：StandBy 會把 Lock Screen 樣式放大到 200%，並用 showsWidgetContainerBackground 判斷要不要畫漸層背景，邊到邊的底色則用 activityBackgroundTint；小型活動家族（small）用來支援 Apple Watch 與 CarPlay。這些是摘要整理，我沒有逐段看完場次影片，程式碼細節請以官方為準。
把它和 HomeView 放在一起看，會發現規則一致。HIG 要求 HomeView 的小工具「放大並移除背景」，Live Activities 在 StandBy 也要判斷是否畫背景；也就是容器的背景由系統決定，內容不能靠自己的底色傳達意義。實務上這條可以寫進 Guidelines 當一條可檢查的規則：狀態（成功、警告、錯誤）不得只用背景色表達，一定要有圖示、文字或前景色，因為背景會被拿掉。再看寬度：昨天算過 3 × 3 的九路攝影機畫面，2 公尺處一格只放得下 2 個全形字（算式是 2.98 em 取整），結論是「改用圖示加位置」；Live Activities 的限寬規則是同一個解法，空間不夠時換成圖示，而不是縮小字級。兩者差在後者有一個環境值讓開發者判斷，前者要設計師自己在規格表裡寫清楚「小於幾 em 時換圖示」。
五、把這三塊合成一份規則清單
這幾件事合起來，可以寫成設計系統團隊現在就能放進 Guidelines 的四條規則，各自標示檢查等級（延續昨天的三級：機器可檢查、需人判斷、需真人測試）：
| 規則 | 前提 | 等級 | 通過範例 | 失敗範例 |
|---|---|---|---|---|
| 狀態不得只靠背景色 | 容器背景可能被系統移除（Modular face、StandBy） | 需人判斷 | 錯誤狀態有圖示與文字 | 整塊紅底、無圖示 |
| 空間不足時換圖示，不縮字 | 有明確的限寬條件（環境值或最小寬度） | 機器可檢查（有斷點時） | 小於斷點顯示圖示 | 字級縮到 11pt 以下 |
| 每個元件列出狀態矩陣並逐一掃描 | 對話框、選單、日期選擇器有開啟狀態 | 機器可檢查 | 開啟狀態都在掃描清單 | 只掃初始畫面 |
| 稽核錯誤擋建置，豁免要留紀錄 | 有可信的掃描規則 | 機器可檢查 | 紅燈不得合併、豁免附原因與期限 | 紅燈可直接忽略 |
這份表是我整理的建議，不是任何一家的官方標準。第二條「字級縮到 11pt 以下」的 11pt 取自 Crosley 整理的 HIG 慣例（小工具文字 11pt 以上），是他的整理，不是我查到的 HIG 原文，請回原文確認。
🧠 記
- Coinbase 評測（Figma 部落格，9 月 2 日）： 三次重複、同設計同提示、空白程式碼庫、重置；Code Connect 讓 token 降 11.5%、時間降 22.3%、成本降 22.5%；品質量元件選擇、token 使用、名稱亂編。自算：成本降幅 22.5% 與 token 降幅 11.5% 相比，每 token 約便宜 12.4%（0.775 除以 0.885 為 0.876，推論原因未驗證）。
- Guidelines 說明： 專業以上方案、開放測試；點數耗用依指南的數量、大小與複雜度而定；格式與上限沒寫。
- USWDS 原始貼文： 9 月 18 日更新（建置遇稽核錯誤即失敗、掃描涵蓋開啟中的對話框、議題 219 降到 118、拉取請求 53 增到 66）；9 月 22 日優先事項（四項，每兩週更新，區分已審查、已合併、已發佈）；穩定版仍是 3.14.0。昨天寫的「9 月 25 日」是報導日期，貼文為 9 月 22 日。
- WCAG 2.2： 78 加 9 減 1 等於 86 項；新增 A 與 AA 共六項；2.5.8 的 24 CSS 像素等於 6.35 毫米，220 ppi 下 55 像素。
- Apple HIG（10 月 13 日）： Widgets 加入 HomeView；Live Activities 加入限寬；iOS 27 橫向 Dynamic Island 精簡樣式不能變寬，用環境值判斷改成圖示；StandBy 放大 200%。
- 設計規則： 狀態不得只靠背景色；空間不足換圖示；元件狀態矩陣逐一掃描；稽核錯誤擋建置。
邊界： 本文所有網頁內容（Figma 部落格與說明中心、GitHub 兩篇貼文、Apple 開發者頁、WWDC 場次、Blake Crosley 與 DesignWhine 文章）都經網頁抽取摘要，沒有讀完整原文，也沒有在 Figma 或 Xcode 實際操作。Coinbase 評測只有平均數，沒有逐次數據、離散程度或模型版本（各摘要不一致，所以不寫）；成本與 token 差距的原因是我的推論；示範表的數字是編的，不是實測。USWDS 兩篇貼文的日期與數字取自抽取摘要，Codex 與 CodeRabbit 的名稱來自 FedScoop，我沒有在原文中確認。GSA 的回應、10 月 2 日與 16 日前後是否有新的進度更新，我沒有查到，不代表沒有。WCAG 2.2 的分類表是我的判斷，不是官方分級。Live Activities 的細節來自場次摘要與搜尋摘要，HIG 本頁我直接開啟時只取得標題，沒有取得內文；Crosley 的 11pt 數字是他的整理。
✍️ 實踐
用 30 分鐘，為你的設計系統建一個「有無 Guidelines」的對照測試，再用八項清單替系統打分。
- 選一個中等複雜的畫面（5 到 10 個必用元件），寫下必用元件清單。
- 固定提示（例如「把這個設計做出來」）、模型與起始檔案。沒有 Guidelines 的庫跑三次、有 Guidelines 的庫跑三次，每次都從空白開始，記錄點數。
- 每次記：選對的元件數、被編出來的元件或圖示名稱數、耗費點數。
- 貼進下面這段程式，看平均與「每個選對元件的點數」。
const mean = a => a.reduce((s, v) => s + v, 0) / a.length;
const needed = 10;
const runs = {
without: { correct: [7, 6, 8], credits: [10, 12, 11] },
withG: { correct: [9, 9, 10], credits: [14, 13, 15] },
};
for (const [k, r] of Object.entries(runs)) {
const c = mean(r.correct), cr = mean(r.credits);
console.log(k, {
accuracy: (c / needed * 100).toFixed(1) + '%',
range: Math.min(...r.correct) * 10 + '-' + Math.max(...r.correct) * 10 + '%',
creditsPerCorrect: (cr / c).toFixed(2),
});
}
// 預期:
// without { accuracy: '70.0%', range: '60-80%', creditsPerCorrect: '1.57' }
// withG { accuracy: '93.3%', range: '90-100%', creditsPerCorrect: '1.50' }- 把自己的數字換進去，並在記錄中標明：三次只能當篩檢，不是統計結論；兩組的範圍有沒有重疊比平均值更重要。
- 用 DesignWhine 的八項替系統打分，每項 0（沒有）、1（部分）、2（完整），滿分 16：標準資產、已寫明的意圖、機器可讀的規則、設計與程式碼對映、可審查的批次修改、漂移偵測、輸出評估、治理是否被保留。這是文章作者的框架，用來找弱項，不用來跨團隊比較分數。
- 把前面四條規則挑兩條寫進你的 Guidelines，標上等級，讓代理畫一個該通過的畫面與一個該失敗的畫面，記錄它對「需人判斷」那條是否會說「我無法判斷」。
🔗 延伸學習
- How Coinbase Used Code Connect to Guide Agents and Shrink Token Costs（Figma） — 三次重複評測的設計與 token、時間、成本數字。
- USWDS program update：3.14.0 remains the current stable release（GitHub 討論） — 9 月 18 日更新：建置、掃描、議題與拉取請求數字。
- USWDS: our priorities（GitHub 討論） — 四項優先事項與每兩週更新的承諾。
- Live Activities essentials（WWDC26 第 223 場） — 限寬 Dynamic Island、StandBy 背景處理與小型活動家族的示範。
- Apple HomeView for Developers: What Apple Said on Day One（Blake Crosley） — 發表當天已公開與未公開的開發者資料逐項盤點。
- Figma Agent For Design Systems: From Library To Software（DesignWhine） — 五層結構與八項代理就緒度檢查。
💬 問 AI
我想把「設計系統規則寫給 AI 代理讀」做成可量測的決策，而不是憑感覺。請嚴格分成「文件明說」「你查證到的」「你的推論」三區回答,不確定就直說,不要編造連結、數字、版本號或引文,也不要給任何投資或財務建議。
背景(請當待查證主張):
1. Figma 部落格(2026-09-02)Coinbase 設計系統團隊評測 Code Connect:同設計、同提示、空白程式碼庫、三次重複;平均 token 降 11.5%、實作時間降 22.3%、成本降 22.5%;品質看元件選擇、token 與語意色使用、圖示名稱亂編。我自算每 token 成本約低 12.4%(0.775 除以 0.885)。
2. Figma 說明中心:Guidelines 為開放測試、專業以上方案、需編輯權限;附 Guidelines 的提示可能多耗點數,依指南數量、大小與複雜度而定;沒有寫檔案格式與上限。
3. USWDS GitHub 貼文:2026-09-18 進度更新(建置遇 Sass 與稽核錯誤即失敗、無障礙掃描擴大到開啟中的對話框、未結議題 219 降到 118、拉取請求 53 增到 66、穩定版仍為 3.14.0);2026-09-22 優先事項四項、每兩週更新。
4. Apple HIG(2026-10-13):Widgets 加入 HomeView(小型家族、Modular face 放大並移除背景、最多四個);Live Activities 加入限寬版面,iOS 27 橫向 Dynamic Island 精簡樣式用 isDynamicIslandLimitedInWidth 改成較窄的替代。
請做:
A. 逐點驗證 1 到 4,標示「成立/部分成立/查不到」並附一手連結;特別確認 Coinbase 評測所用的模型名稱與是否有逐次數據、Apple 兩個 HIG 條目的原文。
B. 說明「三次重複的平均」能和不能支持哪些結論,並建議我測 Guidelines 時至少需要幾次、哪些變因要固定、怎麼避免提示快取干擾成本。
C. 檢查我對「每 token 便宜約 12.4%」的推論有哪些替代解釋(例如輸入與輸出 token 的價差、快取命中率、重試次數)。
D. 為「狀態不得只靠背景色」「空間不足換圖示不縮字」「元件狀態矩陣逐一掃描」三條規則,各寫前提、通過與失敗範例,並標出屬於機器可檢查、需人判斷或需真人測試。
不要評論人事或政治立場,只談設計系統實務、量測方法與證據強度。