Figma 在 10 月 15 日的版本紀錄與說明文件，把設計系統拆成三個新東西：Guidelines（開放測試）讓團隊把規則與反例寫成 Markdown，附在已發佈的設計程式庫上，代理（agent）在後台自動讀取；Code Sources（封閉測試）把 GitHub 儲存庫或 npm 套件接到程式庫；集中式設計系統（預覽）把設計庫、程式碼庫與 Guidelines 綁成一份，附「系統地圖」追蹤變更與相依。昨天講的 Specs 是「一份文件」，今天這三項是「整個設計系統怎麼被機器讀」。
同一週在設計系統另一頭發生的事，方向相反：美國政府的 U.S. Web Design System（USWDS）在 9 月中換了主事者，新團隊公開說要「盡可能自動化無障礙測試」，並在儲存庫導入 OpenAI Codex 與 CodeRabbit 做程式碼審查；社群的回應是約 200 人另起一個時間點複本。兩件事擺在一起，剛好問同一個問題：規則寫給機器之後，檢查也交給機器，能放心到哪裡？今天先對帳 HomeView 的待驗，再講 Guidelines 怎麼用，接著把 USWDS 事件的事實攤開，最後用四份公開數字算出「自動檢查看不到的那一塊」有多大。USWDS 與 10 月 15 至 17 日當天的新動態我沒有查到，下面的時間線只到 10 月 8 日。
📖 學
一、昨天待驗的對帳
| 昨天的待驗 | 今天查到 | 狀態 |
|---|---|---|
| HomeView 的 pt 規格 | 新的上手報導沒有給任何尺寸 | 查不到，維持待驗 |
| Modular face 的實際排列 | 沒有新資料 | 待驗 |
| 11 月 13 日實機字高 | 尚未出貨 | 待驗 |
| 歌詞規則是否放寬 | 沒有新資料 | 查不到 |
| Specs 的代理遵守率 | 搜尋 Guidelines、Specs 的報導，只有「更可預測、不保證遵守」的說法，沒有公布測量結果 | 查不到 |
有一條間接資料。MacRumors 10 月 16 日的節目摘要寫：介面會在有人走近時調整；機器能辨識最多六人，並切換到對方的 App 與個人資料；個人內容「只在認出使用者、且配對的裝置在附近」時出現；沒有 App Store，第三方走「類 CarPlay 系統」透過 iPhone 或 iPad 連線；螢幕最暗可調到 0.3 尼特。這和昨天的推論一致：Modular face 是共用面，個人資料放 Home Screen，由「認出人」把關；但 Modular face 小工具是否也受這道把關，仍沒有文件。0.3 尼特則是 Night Mode 單色紅的另一個前提：極暗加單色紅，對比與狀態辨識都更吃緊。
另有搜尋結果摘要提到 Home Camera 面可同時顯示最多九路畫面。排列方式沒有公開，若假設 3 × 3 等分、無邊距，每格 362.7 px、41.9 mm；沿用本系列的視角基準 0.403 度，2 公尺處 em 為 121.8 px，一格寬 2.98 em，一行只放得下 2 個全形字；1 公尺處 5.95 em，可放 5 字。換成 0.3 度，2 公尺為 3.998 em，捨去後只剩 3 字，又是差千分之二掉一字的邊界。結論是攝影機標籤在 2 公尺外要控制在兩個字（「客廳」「車庫」可以，「後院大門」不行），或改用圖示加位置。這全是假設推算，排列與邊距沒有一手來源。
二、Guidelines、Code Sources 與集中式設計系統怎麼用
以下整理自 Figma 說明中心《What’s new from Config India 2026》與 10 月 15 日版本紀錄，我沒有在 Figma 裡實際操作：
| 功能 | 狀態與方案 | 做什麼 |
|---|---|---|
| Guidelines | 開放測試；專業、組織、企業方案；要有編輯權限 | 在已發佈的設計庫加入 Markdown 檔，寫模式、最佳實務與反例；有人請代理用該庫設計時，檔案在後台自動送給代理 |
| Code Sources | 封閉測試，少數使用者 | 把 GitHub 儲存庫或 npm 套件加到設計庫，發佈一次，下游團隊就能用；代理產生的程式碼圖層會取用真實元件 |
| 集中式設計系統 | 預覽，尚未正式提供 | 把設計庫、程式碼庫與 Guidelines 綁成一份；系統地圖追蹤變更與相依，另有診斷報告指出可改進處 |
Guidelines 補的是設計庫本身說不出來的東西。元件庫能告訴代理「有一個 Button」，但說不出「同一畫面只放一個主要按鈕」「危險操作不用品牌色」這類關係與禁忌。說明文件的原話是：Guidelines 要涵蓋「library assets alone cannot convey」的模式與反例。一份可用的 Guidelines 檔，建議每條規則有四個欄位：規則一句話、前提、通過範例、失敗範例；這是我延續昨天 Specs 的建議，Figma 沒有規定格式，說明文件也沒有寫單檔大小或檔數上限。
成本要留意：說明文件寫了，使用帶有 Guidelines 的設計庫「可能增加 AI 點數消耗」，因為代理多收到一份脈絡。TechCrunch 與多家報導的說法一致，目標是讓輸出「更可預測」，不是保證遵守；Figma 沒有公布遵守率或錯誤率。我的判斷是：在拿到實測以前，Guidelines 應該被當成降低偏離的手段，而不是驗收機制，驗收仍要有另一道檢查。這一點正好接到 USWDS。
三、USWDS 事件：事實時間線
USWDS 是美國聯邦網站共用的元件庫與規範，開源、維護在 GitHub。下面的事實都來自 Nextgov、FedScoop 與 Wikipedia 引用的報導；我只讀到文章，沒有讀 GitHub 上的原始貼文與歷史紀錄，所以「誰在何時刪了哪則留言」這類細節是報導方的說法。
- 9 月 16 日（Nextgov）： 長年領導 USWDS 的 Anne Petersen 被放行政假；Treasury（財政部）的 AI 工程師 Ryan Parker 接任負責人，任命者是兼任 GSA 三個職位的財政部資訊長 Sam Corcos。
- 9 月 25 日（FedScoop）： Parker 在 GitHub 貼出「our priorities」，目標寫成「automate as much accessibility testing as possible across current and future USWDS versions」；儲存庫導入 OpenAI Codex 與 CodeRabbit；前 USWDS 工程負責人 Matt Henry 說，無障礙測試只有約 30% 能可靠自動化，FedScoop 這句是轉述而非直接引言；Sheri Byrne-Haber 說 AI 工具「只偵測到約一半的違規」。
- 9 月 29 日（FedScoop）： 數十位開發者與前政府員工聯名，向 GSA 提出七項要求；報導列出的四項包括恢復社群維護者的 GitHub 權限、復職前領導與員工、公開溝通、維持嚴格的人工無障礙測試與有紀錄的品質保證。他們的理由是：一個無障礙缺陷、效能問題或資安漏洞，「可能讓數千個系統處於風險」。報導寫 FedScoop 已向 GSA 求證，文中沒有 GSA 的回應。
- 10 月 1 日（Nextgov）： 「People’s Design System」（今年 1 月在 USWDS 更新停滯時成立，Slack 社群近 200 人）提出治理委員會，要做 USWDS 的時間點複本（hard fork，不收也不推上游更新）；用哪個版本當基準尚未決定。
- 10 月 8 日（Civic Tech Daily 電子報）： 約 200 人建立 Open Government Design System（OGDS）；文章的主論點是這是治理問題，而不是 AI 好不好用。
OGDS 的 GitHub 儲存庫（open-government-design-system/ogds-elements）說明它是 USWDS 的補充與重構，而不是完整取代：元件用 CSS 自訂屬性，沿用與 USWDS 相同的設計 token（顏色、間距），不需要 Sass；有加強版的 accordion 與 banner，也有全新的 Task List；README 要求自訂版必須通過 WCAG 2.2 或 Section 508 測試，並寫「確保自訂符合無障礙要求是你的責任」。我抓到的頁面顯示 706 次提交、33 個開啟中的議題、9 個合併請求，這是取用當下的數字，會變。它沒有寫軟體授權條款（抓取摘要中看不到，不代表沒有）。
這件事對設計系統實務的意義不在政治，而在兩個結構性問題。第一，設計系統是共用基礎設施，一處缺陷會複製到所有下游站點，所以變更審核的品質是產品本身的一部分。第二，下游團隊需要一條「上游治理改變時的退路」：point-in-time 複本就是這條退路，代價是自己承擔之後的維護。這和 Figma 的集中式設計系統是同一個設計問題的兩個尺度：誰擁有規則、改動怎麼被追蹤、出了問題怎麼回頭。
四、自動檢查看得到多少：四份公開數字的分母
「約 30%」「一半」「57%」「71%」這幾個數字常被拿來互相反駁，其實是分母不同。我把能查到一手來源的整理成表：
| 來源 | 分母 | 數字 |
|---|---|---|
| UK GDS 2017（accessibility.blog.gov.uk） | 一頁刻意植入的 143 個失敗、19 類，10 個工具 | 單工具最佳 41%（Asqatasun，含「需人工檢查」的提示）、最差 17%（Google 開發者工具）；十個合併 71%；42 個（29%）全部工具都沒偵測到 |
| Deque 2021 年 3 月研究 | 2,000 多次稽核、1.3 萬多頁、約 30 萬筆真實問題 | 以 axe 規則自動偵測占問題筆數約 57%（第三方摘要寫 57.38%）；以 WCAG 成功準則計，過去業界基準是 20% 至 30% |
| Matt Henry（FedScoop 轉述） | 無障礙「測試工作」 | 約 30% 可靠地自動化 |
| Sheri Byrne-Haber（FedScoop 引言） | 違規 | AI 工具約一半 |
差異主要來自三件事：以「筆數」計還是以「準則」計（Deque 自己說，改用筆數後，因為缺替代文字、低對比、缺標籤這些機器擅長的問題剛好最常見，數字從 20% 至 30% 升到 57%）；測試頁是刻意植入的失敗還是真實網站（GDS 的 143 個是均勻設計出來的，並非真實分布）；工具是否把「需人工檢查」的提示算進去（GDS 最佳的 41% 就有算）。所以「30%」「57%」不互相矛盾，也都不是「AI 能做到的比例」，它們量的是規則式掃描工具，而 Parker 計畫導入的是 AI 程式碼審查。AI 審查對這些數字的影響，我沒有查到有公開的對照實驗。
再看 WebAIM 的 2026 年《WebAIM Million》（2 月，掃描 100 萬個首頁）：95.9% 的首頁有可偵測的 WCAG 2 失敗，前一年是 94.8%；平均每頁 56.1 個錯誤，較前一年的 51 個增加 10.1%；最常見六類依序是低對比文字 83.9%、缺圖片替代文字 53.1%、缺表單標籤 51%、空連結 46.3%、空按鈕 30.6%、缺文件語言 13.5%，合計占偵測到錯誤的 96%。有 ARIA 的頁面平均 59.1 個錯誤，無 ARIA 的 42 個，多 40.7%，這是相關，不是因果。
接下來是我自己的算法，只是示意。56.1 個是「掃描器看得到的」；若假設首頁的掃描涵蓋率等於上表各數字，真正的問題總數就是 56.1 除以涵蓋率：
| 假設涵蓋率 | 推算總數 | 其中掃描看不到的 |
|---|---|---|
| 71%（GDS 十工具合併） | 79 | 23 |
| 57.38%（Deque 筆數） | 98 | 42 |
| 41%（GDS 單工具最佳） | 137 | 81 |
| 30%（Henry） | 187 | 131 |
這個推算把三個不同母體混用（植入頁、稽核資料、首頁），而且 WebAIM 用的偵測器只算可自動偵測的類型，所以結果是範圍，不是估計值；用意是看量級：每頁看不見的問題，從幾十個到上百個都有可能。
還有一個反向的小發現。WebAIM 的平均元素數是 1,437 個，較前一年成長 14.3%，反推前一年約 1,257 個。每百個元素的錯誤數，從 51 除以 1,257 的 4.06，變成 56.1 除以 1,437 的 3.90，下降約 3.8%。也就是「錯誤變多」有很大一部分是頁面變複雜；單位元素的錯誤密度其實略降。前一年的元素數是我反推的，需要對照原報告表格。這不是說情況變好，是提醒引用「錯誤數上升 10%」時，要同時看頁面規模。
五、設計系統團隊現在可以做的三件事
第一，把規則依「誰能檢查」分三級再寫進 Guidelines。可機械檢查的（對比 4.5 比 1 與 3 比 1、替代文字存在、表單標籤、空連結、空按鈕、文件語言，正好是 WebAIM 前六類）；需要人判斷的（替代文字是否傳達意義、焦點順序、讀屏朗讀順序、連結文字是否獨立可懂）；需要真人使用者的（用 NVDA 或 VoiceOver 走一次主要流程）。每條規則標上等級，代理就不會把「需要人判斷」的項目回報成通過。這是我的建議，不是 Figma 的功能。
第二，審核流程把「自動」與「合併」拆開。無論審核是掃描器、AI 或人，合併條件要寫成「機器通過且人工清單對應項已勾」；USWDS 聯名要求的第四項「維持嚴格的人工測試與有紀錄的品質保證」就是這個意思。
第三，為上游治理改變準備退路。用開源設計系統的團隊，至少固定一份已驗證版本的複本（版本號與 token 快照），並知道自己升級時要重跑哪些無障礙測試；OGDS 與 People’s Design System 的做法證明這條路走得通，但維護成本要先算進去。
🧠 記
- Figma（10 月 15 日）： Guidelines 為開放測試，專業以上方案，Markdown 檔附在已發佈設計庫、自動送給代理、可能增加點數；Code Sources 封閉測試；集中式設計系統預覽，有系統地圖與診斷報告；遵守率沒有公布。
- USWDS： 9 月 16 日換主事者；9 月 25 日公布盡可能自動化無障礙測試、導入 Codex 與 CodeRabbit；9 月 29 日聯名要求恢復權限與人工測試；10 月 1 日起 People’s Design System 要做時間點複本；10 月 8 日報導 OGDS 成形。
- 涵蓋率的分母： GDS 2017：143 個失敗，單工具 17% 至 41%，合併 71%，29% 全漏；Deque 2021：約 30 萬筆，57%；Henry：約 30%；Byrne-Haber：約一半。
- WebAIM 2026： 95.9% 首頁有失敗；每頁 56.1 個；低對比 83.9%；前六類占 96%；元素 1,437 個。每頁真問題範圍（自算、示意）79 至 187 個。
- HomeView： 個人內容在認出使用者且配對裝置在附近時出現；最暗 0.3 尼特；3 × 3 假設下 2 公尺一行 2 字（0.403 度）。
邊界： Figma 的內容來自說明中心與版本紀錄經網頁抽取摘要，Guidelines 的檔案格式、大小上限、點數增量都沒有查到；USWDS 的事實全來自 Nextgov、FedScoop、Civic Tech Daily、Wikipedia 的二手整理，我沒有讀 GitHub 原始貼文，9 月 27 日那個日期在 Nextgov 的摘要中與曆法不符，所以時間線只寫「9 月底」；Deque 的 57.38% 與 32% 的準則比例來自第三方摘要與 Deque 的部落格，沒有讀完整報告；GDS 部落格有被抓取摘要，數字一致；GDS 是 2017 年的舊測試，工具已大幅更新；Henry 的 30% 是記者轉述，沒有原始出處；Parker 計畫用的 AI 審查與規則式掃描器涵蓋率不能直接比較；OGDS 數字是取用當下；MacRumors 與上手報導的內容是節目摘要與搜尋摘要，3 × 3 排列沒有一手來源；推算總數表是混用母體的示意。USWDS 與 GSA 在 10 月 9 日以後的動態、GSA 的回應，我沒有查到。
✍️ 實踐
用 20 分鐘，把你團隊現有掃描報告換算成「看不見的那一塊」，再寫一份分級規則檔。
- 對一個頁面跑 axe 或 WAVE，記下偵測到的錯誤筆數。
- 貼進下面這段程式，看四種涵蓋率假設下的總數範圍。
function hiddenIssues(detected, coverage) {
const total = detected / coverage;
return { total: Math.round(total), hidden: Math.round(total - detected) };
}
for (const c of [0.71, 0.5738, 0.41, 0.30]) {
console.log(c, hiddenIssues(56.1, c));
}
// 預期:
// 0.71 { total: 79, hidden: 23 }
// 0.5738 { total: 98, hidden: 42 }
// 0.41 { total: 137, hidden: 81 }
// 0.3 { total: 187, hidden: 131 }- 把你的 detected 換進去，並在文件裡記下前提：涵蓋率來源、母體不同、只是示意。
- 寫一份 Markdown 規則檔，至少三條：一條「機器可檢查」（例：正常字級文字對比不低於 4.5 比 1，通過範例與失敗範例各一）、一條「需人判斷」（例：替代文字要說明圖片用途，不是檔名）、一條「需真人測試」（例：主要流程用 VoiceOver 走完，記錄卡住的步驟）。每條標等級。
- 有 Figma 專業以上方案的話，把這個檔加到設計庫的 Guidelines，請代理畫兩個畫面，一個該通過、一個該失敗，記錄它對「需人判斷」那條是否說出「我無法判斷」。
🔗 延伸學習
- What’s new from Config India 2026（Figma 說明中心） — Guidelines、Code Sources、集中式設計系統、Specs 與程式碼圖層的方案範圍與點數說明。
- Figma announces new features to define how agents work on its platform（TechCrunch） — 目標是更可預測的輸出、而非保證遵守的說法來源之一（我只看到搜尋結果摘要，沒有開全文）。
- Technologists to create ‘trustworthy’ copy of GSA web design system（Nextgov） — People’s Design System、治理委員會與時間點複本。
- A Trump team wants to automate U.S. Web Design System accessibility testing（FedScoop） — 「our priorities」貼文、Codex 與 CodeRabbit、Henry 與 Byrne-Haber 的說法。
- What we found when we tested tools on the world’s least accessible webpage（GDS） — 143 個失敗、10 個工具、各工具涵蓋率。
- The WebAIM Million — 2026 年首頁無障礙失敗的類別、比例與逐年變化。
💬 問 AI
我想把「設計系統規則寫給 AI 代理讀」與「無障礙檢查交給自動化」做成可驗算、可檢查的決策。請嚴格分成「文件明說」「你查證到的」「你的推論」三區回答,不確定就直說,不要編造連結、數字、版本號或引文。
背景(請當待查證主張):
1. Figma 說明中心(2026-10-15):Guidelines(開放測試,專業以上方案)是附在已發佈設計庫的 Markdown 檔,代理自動讀取,可能增加 AI 點數消耗;Code Sources 封閉測試;集中式設計系統預覽,有系統地圖與診斷報告。Figma 沒有公布代理遵守率。
2. USWDS:2026-09-16 起換主事者,9-25 公布「automate as much accessibility testing as possible」並導入 Codex 與 CodeRabbit;Matt Henry 稱約 30% 的無障礙測試可靠地自動化(記者轉述);People's Design System 與 Open Government Design System 於 10 月初要做時間點複本。
3. 涵蓋率數字:UK GDS 2017(143 個植入失敗、10 工具,單工具 17% 至 41%、合併 71%、29% 全漏);Deque 2021(約 30 萬筆問題,自動偵測約 57%,以成功準則計約 20% 至 30%);WebAIM Million 2026(95.9% 首頁有失敗、平均 56.1 個、元素 1,437 個,前六類占 96%)。
4. 我的自算(示意):以 56.1 除以涵蓋率,每頁總問題約 79 至 187 個、看不見的 23 至 131 個;每百元素錯誤密度從約 4.06(前年元素數由 +14.3% 反推)降到 3.90。
請做:
A. 逐點驗證 1 到 4,標示「成立/部分成立/查不到」並附一手連結;特別確認 Guidelines 的檔案格式與上限、Henry 的 30% 是否有原始出處、GDS 與 Deque 的數字是否與原文一致。
B. 查是否有公開研究比較「規則式掃描」與「LLM 程式碼審查」在 WCAG 問題上的偵測率與誤報率;沒有就直說。
C. 說明我把 WebAIM 偵測數除以他處涵蓋率的推算有哪些方法論漏洞,並提出更合理的估計方式。
D. 為設計系統寫三條分級規則(機器可檢查、需人判斷、需真人測試),各含前提、通過與失敗範例,並建議合併條件怎麼寫。
不要評論人事或政治立場,只談設計系統治理、無障礙檢查方法與證據強度。