第二輪：21 題、四套設計系統
同一批 21 題，分別交給 tfds、LUMIXIS、IBM Carbon、Atlassian 四套設計系統，每套各給兩種份量的資料，共 168 份答案。每份答案的畫面、每條評分結果和稽核意見都在 評測檢視台，可以逐條留下人工判定。
怎麼跑的
題目共 21 題：D2 7 題（含第一輪的「刪除案件確認」）、D3 6 題、D4 6 題、D5 2 題。題目由 agent 從 KB 和 PRQ 寫成，再由另一個 agent 檢查有沒有洩題，共改了 36 處。
每套系統給兩組資料，第 2 組比第 1 組多了使用說明：
| 系統 | 第 1 組 | 第 2 組 | 交件格式 |
|---|---|---|---|
| tfds | T1：組件清單和屬性（2 個檔，60 KB） | T2：再加每個組件的使用說明、行為規格、結構說明和設計模式規則（195 個檔，2.8 MB） | 畫面資料（JSON），用組件組成 |
| LUMIXIS | L1：token 頁、token 原始檔、樣式表（19 個檔，404 KB） | L2：整個網站 19 頁加原始檔（30 個檔，480 KB） | HTML，樣式只能引用 token |
| Carbon | C1：組件的屬性清單（2 個檔，292 KB） | C2：再加各組件和設計模式的使用說明（111 個檔，1.4 MB） | HTML，用 Carbon 的 Web Components |
| Atlassian | A1：從套件型別整理出的組件屬性（2 個檔，308 KB） | A2：再加 Atlassian 給 agent 讀的完整文件 llms-full.txt（5 個檔，1.0 MB） | React，用 @atlaskit 套件 |
每一題、每一組各由一個 agent 作答，只跑一次。作答的 agent 只讀交給它的資料夾，不上網，不跑程式，也不開瀏覽器。
作答和評審都用 claude-opus-5-5，使用稽核用 claude-sonnet-5-5。型號從每次執行的紀錄讀出，推理強度用預設值。
第 0 層 規則用法：每套系統各寫一支檢查程式，依它自己公開的規則檢查。tfds 對照組件資料，LUMIXIS 對照 token 和它允許綁定的屬性，Carbon 對照它發布的組件清單和 token，Atlassian 用 TypeScript 型別檢查。
第 1 層 自動無障礙檢查：axe-core，淺色、深色各一次。
第 2 層 是非題：LLM 評審回答三種題：每題自己的規則、7 題通用題（名稱、文案、失敗、等待、空狀態、後果、狀態齊全），以及各系統從自己文件出的題（tfds 4 題、LUMIXIS 7 題、Carbon 4 題、Atlassian 4 題）。評審一次看同一題的兩份答案，只看到 A、B 代號，答案裡的註解先刪掉。
第 3 層 使用稽核：這一輪新加的，見下方「使用稽核」一節。
總表
| 組 | 第 0 層 通過 | 第 1 層 除對比外沒有問題 | 第 1 層 有對比不足 | 第 2 層 答「是」比例 | token 中位數 |
|---|---|---|---|---|---|
| T1 | 2/21 | 3/21 | 18/21 | 84.8% | 91,721 |
| T2 | 14/21 | 16/21 | 19/21 | 87.9% | 120,307 |
| L1 | 1/21 | 14/21 | 19/21 | 88.0% | 109,945 |
| L2 | 2/21 | 15/21 | 19/21 | 92.7% | 136,055 |
| C1 | 11/21 | 2/21 | 6/21 | 85.5% | 100,321 |
| C2 | 13/21 | 2/21 | 6/21 | 87.0% | 115,895 |
| A1 | 5/21 | 10/21 | 1/21 | 91.8% | 96,615 |
| A2 | 14/21 | 13/21 | 2/21 | 91.8% | 105,267 |
讀表方式：
只在同一套系統內比較第 1 組和第 2 組。 第 0 層檢查的是各系統自己的規則，第 2 層也有一部分題目是各系統自己的，所以跨系統的數字不能拿來排名。
第 1 層分成兩欄。 「除對比外沒有問題」是指 axe 除了對比不足，沒有找到其他問題。另外有一類問題是所有狀態排在同一頁造成的（重複的主要區域、重複的 id），不算進來。LUMIXIS 顏色頁自己列出的例外（品牌藍和危險紅按鈕上的白字）不算對比不足；扣掉這些後，LUMIXIS 仍有 19/21 份有其他對比問題。
第 2 層不含 D5。 依原計畫，D5 不自動評第 2 層。tfds 和 LUMIXIS 照做了；Carbon 和 Atlassian 的評審則連 D5 也評了（C1 83%、C2 76%、A1 81%、A2 86%），為了可以對照，表中扣掉。
整體來看：
多給使用說明之後，第 0 層明顯變好的有兩套：tfds 2 → 14、Atlassian 5 → 14；Carbon 只多 2 份（11 → 13），只跑一次分不出是不是偶然。LUMIXIS 幾乎沒有變（1 → 2），因為它的主要錯誤，多給網頁也沒有補到（見 LUMIXIS 一節）。
第 2 層的進步小，0 到 5 個百分點。題目規則和文案，只給組件清單的第 1 組大多也做得到；資料多寡主要影響的是組件和 token 用得對不對。
第 2 組用掉的 token 比第 1 組多 9% 到 31%。
tfds
| T1 組件清單 | T2 加使用說明等 | |
|---|---|---|
| 第 0 層通過 | 2/21 | 14/21 |
| 第 1 層除對比外沒有問題 | 3/21 | 16/21 |
| 第 2 層 D2 / D3 / D4 | 92% / 78% / 85% | 91% / 85% / 88% |
| token 中位數 | 91,721 | 120,307 |
| 工具使用次數中位數 | 6 | 16 |
| 耗時中位數 | 2.0 分鐘 | 3.9 分鐘 |
組件結構說明和使用說明讓組件用法大幅變對。 T1 最常見的錯是組件的位置放了它不接受的東西（17 份）和缺少必填的位置（7 份）；T2 分別降到 5 份和 2 份。
同一件事也反映在無障礙檢查。 T1 有 17 份出現沒有名稱的按鈕、8 份出現按鈕包按鈕；T2 只剩 2 份和 1 份。T1 這 17 份裡有 10 份是對話框的關閉按鈕：tfds 的組件不帶文字，關閉按鈕的名稱要由使用的人給，對話框的使用說明有示範（aria-label="Close"），T1 沒有拿到這份說明。按鈕的使用說明也寫了只有圖示的按鈕要加 aria-label。這和第一輪 V1 的發現一致。
第 2 層總分差距小，因為兩個方向互相抵消。 「每個控制項都有螢幕閱讀器讀得到的名稱」這題，T1 只有 3/19 答「是」，T2 有 18/19；題目規則這部分反而是 T1 略高（93% 對 87%）。分等級看，差距只在 D3（一個畫面加它的各種狀態）看得到：T1 78%、T2 85%；D2 兩組幾乎一樣。
tfds 自己的顏色有一個對比問題。 主要按鈕的白字配 #1877ff 底色，淺色主題對比 4.1，低於 4.5。42 份 tfds 答案中有 36 份被標出，和 agent 怎麼寫無關。同一個顏色在 LUMIXIS 是列出來的例外，tfds 沒有列。
第 0 層檢查程式修過一處。 有「值」的組件（例如驗證碼欄位、時間軸），在 Vue 裡用 modelValue 屬性綁定，組件資料也有列；檢查程式原本只認結構說明裡不分框架的名稱 value，誤判了 T2 的 9 份答案。修正後 T2 從 10/21 變成 14/21，T1 不變。結構說明的格式可以考慮直接寫出各框架用的名稱。
顯示程式畫不出提示訊息（toast）。 tfds 的提示訊息要透過程式呼叫才會出現，答案寫在畫面資料裡的提示訊息畫出來是空的。t03 的評審因此把兩份答案的兩題判成「否」，要在檢視台上人工複核。
代價。 T2 讀的資料是 T1 的 47 倍（2.8 MB 對 60 KB），token 多 31%，是四套系統裡增加最多的。
LUMIXIS
| L1 token 頁 | L2 整個網站 | |
|---|---|---|
| 第 0 層通過 | 1/21 | 2/21 |
| 第 1 層除對比外沒有問題 | 14/21 | 15/21 |
| 第 2 層 D2 / D3 / D4 | 91% / 84% / 90% | 95% / 90% / 93% |
| token 中位數 | 109,945 | 136,055 |
| 工具使用次數中位數 | 12 | 14 |
| 耗時中位數 | 4.2 分鐘 | 5.6 分鐘 |
第 2 層是四套系統裡第 2 組進步最多的（88.0% → 92.7%），每個等級都變好。 多出來的是原則、無障礙、命名等頁，LUMIXIS 自己的題目有一部分就出自這些頁（原則、無障礙）。兩組差距最大的幾題是：危險按鈕用危險填色（4/9 → 7/7）、危險按鈕的焦點外框（6/9 → 7/7）、token 的用途合不合元素（7/19 → 11/19）。兩組都做不好的是「確認框除了危險動作，還有至少兩個出口」（2/5、1/5）；這是 tfds 的對話框規則，LUMIXIS 自己沒有寫。
第 0 層幾乎全部不通過，主因是一條很嚴的規則。 兩組各有 19 份犯「token 用在它不該用的屬性」。最常見的是拿間距 token 當定位的位移（top、left、right、bottom）或寬高，拿尺寸 token 排格線欄寬。LUMIXIS 沒有定位用的 token，它的 Figma 設定也只寫了 token 可以綁在 Figma 的哪種欄位（間距、填色、寬高……）。哪個 CSS 屬性對應哪種 Figma 欄位，是檢查程式自己定的，作答的 agent 沒有拿到。所以多給網頁也補不到這一點。這些算不算錯，要人判斷。
沒有組件，結構問題反而少。 agent 直接寫 HTML，第 1 層除對比外 14 到 15 份沒有問題，剩下的多半是元素加了不允許的角色。
幾乎每份答案都有對比不足，且不在 LUMIXIS 列的例外裡。 最常見的是次要文字的灰 #727272 配 #eeeeee（淺色 4.14，42 份中 31 份）、成功綠 #2a9f47 配淡綠底（3.03，16 份）、#9e9e9e 配白底（2.67，11 份）。這些顏色都是 LUMIXIS 的 token 值；哪些是 token 本來就不該這樣配、哪些是 agent 配錯，要對照它的顏色頁。
評審資料中途補過一次。 判斷「用的 token 符不符合元素的用途」這題時，評審需要知道每個 token 的用途說明；這份資料在 t01 到 t03 開始評審後才加進去，這三題的評審只能從 token 名稱推測。
代價。 資料只多了 19%（480 KB 對 404 KB），token 多 24%，是四套系統裡耗時最長的。
Carbon
| C1 屬性清單 | C2 加使用說明 | |
|---|---|---|
| 第 0 層通過 | 11/21 | 13/21 |
| 第 1 層除對比外沒有問題 | 2/21 | 2/21 |
| 第 2 層 D2 / D3 / D4 | 90% / 84% / 82% | 89% / 90% / 82% |
| token 中位數 | 100,321 | 115,895 |
| 工具使用次數中位數 | 11 | 15 |
| 耗時中位數 | 3.3 分鐘 | 3.5 分鐘 |
第 1 層的問題多半來自 Carbon 組件本身。 最常見的五種，都出在 Carbon 組件自己產生的結構裡：表格列的子元素、日期選擇器裡沒有名稱的隱藏連結、按鈕組、單選按鈕的屬性、切換器的按鈕。答案怎麼寫都會出現，所以兩組都只有 2/21，反映的是這個版本的 Carbon Web Components。
評審判「每個控制項都有名稱」的比例很低。 C1 7/19、C2 8/19，其他三套系統的第 2 組都有 18/19 以上。Carbon 的控制項在自己的封裝結構（shadow DOM）裡，這一項是答案真的漏了名稱，還是評審讀不到，要在檢視台上人工複核。
第 0 層的錯集中在少數答案。 「不是 Carbon 的 class」只出現在 C1 3 份、C2 5 份，但每份上百處，是答案自己寫了樣式 class。「只能用 Carbon 自己的 class」是這次評測訂的規則，Carbon 的文件沒有這樣要求。另一個常見的錯是把文字色 token 拿來當邊框或底色（C1 7 份、C2 5 份）。
確認框的標題和主要按鈕說的動作常常不一致。 Carbon 的對話框使用說明要求兩者都反映同一個動作，兩組都只有 7/11，多給使用說明也沒有改善。危險確認框和取消按鈕兩組都全對。
對話框的角色要從螢幕閱讀器的資料讀。 Carbon 把對話框的角色放在封裝結構裡，自動擷取的畫面事實讀不到；評審改讀螢幕閱讀器會拿到的資料，危險確認框在那裡是「alert」。
代價。 資料多 5 倍（292 KB 對 1.4 MB），token 多 16%。
Atlassian
| A1 屬性清單 | A2 加 llms-full.txt | |
|---|---|---|
| 第 0 層通過 | 5/21 | 14/21 |
| 第 1 層除對比外沒有問題 | 10/21 | 13/21 |
| 第 2 層 D2 / D3 / D4 | 97% / 88% / 90% | 97% / 89% / 89% |
| token 中位數 | 96,615 | 105,267 |
| 工具使用次數中位數 | 16 | 17 |
| 耗時中位數 | 3.4 分鐘 | 3.5 分鐘 |
第 0 層的差距幾乎都來自同一個錯。 圖示的顏色要寫成 token("color.icon.subtle")，也就是把 token 名稱交給 Atlassian 的函式換成實際的值；很多答案直接寫了 token 名稱字串。這樣寫出來的顏色無效，圖示會退回文字色。兩組合計 88 處，A1 16 份答案有型別錯誤，A2 降到 7 份；llms-full.txt 裡有這種寫法的例子。
型別檢查的結果要先篩過。 答案用一般 JavaScript 寫自己的小組件時，型別檢查會要求每個參數都必填，共 111 處，這些和 Atlassian 無關，已經拿掉。另有 10 處是寫在變數裡的值被型別檢查放寬，只記為提醒。
第 1 層幾乎只剩標題層級。 除對比外的問題，幾乎都是標題層級跳級（A1 10 份、A2 7 份）；對比不足只有 1 份和 2 份，是四套系統裡最少的。
第 2 層兩組一樣（91.8%）。 對話框的主要按鈕要反映標題，這題 A1 8/13、A2 10/13；對話框要有標題、一個對話框只做一件事，兩組都全對。
畫面要加上頁面底色。 第一次畫時頁面沒有底色，深色主題的淺色字落在白底上，深色檢查出 711 處對比不足。實際的 Atlassian 應用程式會用它的全域樣式設定頁面底色和文字色，重畫時比照加上，兩個主題各剩 7 處。
代價。 資料多 3 倍（308 KB 對 1.0 MB），token 只多 9%，是四套系統裡增加最少的，第 0 層的進步卻和 tfds 一樣多。
使用稽核（第 3 層）
稽核 agent 不看題目規則、不看設計系統，也不知道答案來自哪一套。它只拿到一個身分和一個用使用者的話寫的目標，依流程順序一張張看各狀態的畫面，每張說它接下來會按哪裡、哪裡讓它猶豫，最後回答做不做得完。問題分三種：卡住、拖慢、煩人。
每份答案跑兩次：一次看截圖，一次只拿螢幕閱讀器會讀到的內容和 Tab 順序。這一輪先選三題，共 48 次：
t21：倉庫保全主管，把一個已經結案、不再需要的案件刪掉（3 張畫面）。
t08：管工地攝影機、不懂技術的人，把某台攝影機十月的縮時影片拿到手，寄給工地主任（4 張）。
t16：監控室值班人員，剛才回放時看到堆高機撞到貨架，把那段影像保存下來交給保險公司，並確定已經存好（7 張）。
t16 的結果（括號內是卡住的問題數）：
| 組 | 看畫面 | 螢幕閱讀器 |
|---|---|---|
| T1 | 部分做得完（1） | 部分做得完（1） |
| T2 | 部分做得完 | 部分做得完（1） |
| L1 | 部分做得完 | 部分做得完（1） |
| L2 | 做得完 | 做得完 |
| C1 | 部分做得完（1） | 部分做得完（1） |
| C2 | 部分做得完（1） | 部分做得完 |
| A1 | 做得完 | 部分做得完（2） |
| A2 | 部分做得完 | 部分做得完（2） |
t08 和 t21 分不出各組的差別。 t08 幾乎全部「做得完」，t21 全部「部分做得完」。下一輪要換題。
t16 卡住的地方大多是流程接不起來。 最常見的是：存檔失敗時，訊息要使用者到 Archives 刪掉一個舊片段，但答案畫的 Archives 只有播放和下載，沒有刪除（C1、A1、A2）。其次是失敗訊息沒說原因，也沒說影像還會保留多久。這些是是非題問不到的：每個畫面各自都合規則，接起來才有問題。
螢幕閱讀器模式找到的問題多得多。 卡住的問題看畫面共 3 處，螢幕閱讀器 9 處。其中有些只有用聽的才發現得到：時間和日期欄位沒有名稱（T1、A2）、Tab 順序裡多出兩個看不到的連結（C2）、存檔後來失敗了卻沒有讀出任何提示（L1）。
稽核方法修過三次。 第一版說明沒有講「失敗的那張畫面也是測試的一部分」，稽核把強制的失敗當成目標沒達成；t16 的目標原本寫了一個題目裡沒有的攝影機名稱；截圖的視窗太矮，切掉了 T1 這種整頁高度的畫面的存檔按鈕。三處都修正並重跑受影響的部分，作廢 25 次。
同一份輸入重跑，結論不一定一樣。 T1 的螢幕閱讀器稽核重跑一次後，「卡住」的問題從「Archives 沒有刪除」換成「時分秒欄位沒有名稱」；後者上一次列為「拖慢」。單次的結果只能當線索，要多跑幾次才能算比例。
token 用量與模型
每份答案記下模型用掉的 token、工具使用次數和耗時，數字取自每個 agent 結束時的回報。
| 組 | token 中位數 | token 合計（21 題） | 工具次數中位數 | 耗時中位數 | 交給它的資料 |
|---|---|---|---|---|---|
| T1 | 91,721 | 1,874,259 | 6 | 2.0 分鐘 | 60 KB |
| T2 | 120,307 | 2,603,894 | 16 | 3.9 分鐘 | 2.8 MB |
| L1 | 109,945 | 2,485,948 | 12 | 4.2 分鐘 | 404 KB |
| L2 | 136,055 | 2,803,998 | 14 | 5.6 分鐘 | 480 KB |
| C1 | 100,321 | 2,353,927 | 11 | 3.3 分鐘 | 292 KB |
| C2 | 115,895 | 2,478,308 | 15 | 3.5 分鐘 | 1.4 MB |
| A1 | 96,615 | 1,991,621 | 16 | 3.4 分鐘 | 308 KB |
| A2 | 105,267 | 2,280,392 | 17 | 3.5 分鐘 | 1.0 MB |
等級越高，用的 token 越多。以 T2 為例，D2 中位數 105,138，D4 140,735。資料量和 token 不成比例：T2 資料是 T1 的 47 倍，token 只多 31%。從數字推測，agent 沒有整份讀完，只挑了需要的檔案。
整輪的用量：
| 工作 | 次數 | 模型 | token 合計 |
|---|---|---|---|
| 寫題目（依等級分四批） | 4 | claude-opus-5-5 | 697,313 |
| 檢查題目洩題 | 2 | claude-opus-5-5 | 179,627 |
| 作答 | 168 | claude-opus-5-5 | 18,872,347 |
| 評審，tfds 和 LUMIXIS | 38 | claude-opus-5-5 | 沒有逐次記錄 |
| 評審，Carbon 和 Atlassian | 42 | claude-opus-5-5 | 4,431,572（中位數 90,894） |
| 使用稽核 | 73（有效 48） | claude-sonnet-5-5 | 4,077,208 |
tfds 和 LUMIXIS 的 38 次評審沒有逐次記下 token；之後每次評審都要記。
限制
每份答案只跑一次。 幾個百分點的差距和單題的結果都可能是偶然；稽核重跑一次就出現過不同的結論。
評審和作答是同一個模型。 評審可能偏好自己的寫法。
第 0 層有幾條規則是這次評測自己訂或自己詮釋的。 Carbon 只能用它自己的 class；LUMIXIS 的 CSS 屬性和 Figma 欄位怎麼對應。這兩條都會拉低通過數。
題目文字是 agent 從 KB 寫的。 寫完檢查過洩題，仍可能殘留描述畫面的字眼。
畫面是自己寫的顯示程式畫的。 tfds 的提示訊息畫不出來；Carbon 對話框的角色要從螢幕閱讀器的資料讀；Atlassian 要補上頁面底色。
過程中修過幾處。 tfds 的第 0 層檢查程式、LUMIXIS 評審資料中途才補上、稽核方法修過三次。修正後都重跑了受影響的部分，只有 LUMIXIS t01 到 t03 的評審沒有重跑。
使用稽核只有 3 題，而且是靜態的分鏡。 其中 2 題分不出差別。
D5 還沒有人工評分。 依計畫 D5 的第 2 層由人評。
待決定事項
tfds 主要按鈕的白字配 #1877ff 對比只有 4.1：要調顏色，還是列為刻意保留的例外。兩種都要寫一份決策紀錄（ADR）。
組件結構說明的格式要不要寫明「值」在各框架的屬性名稱（Vue 是 modelValue）。
LUMIXIS：CSS 屬性和 Figma 欄位的對應要不要算進第 0 層；如果要，對應表也要交給作答者。
Carbon：「只能用 Carbon 的 class」這條規則要不要留。
在檢視台上人工複核：tfds t03 的提示訊息、Carbon 的「控制項都有名稱」、D5 的第 2 層。
下一輪每份答案多跑幾次，才算得出通過率和波動。
交叉實驗：換評審模型（例如用 claude-sonnet-5-5 當評審），或換稽核模型。
使用稽核換掉 t08 和 t21，並改成可以實際操作的原型（答案格式加「按了去哪裡」的標註）。
要不要加新題型：要求 agent 做出設計系統還沒有的組件，或先找出設計系統缺了什麼。
tfds 對話框的關閉按鈕在使用者沒給名稱時是無名的（T1 有 10 份答案如此）：維持「組件不帶文案」只靠開發時的警告，還是把名稱改成必填。