VS Code 團隊在 10 月 15 日發表〈Modernizing the VS Code UI〉，把整個工作台換成新的 Dark 2026 與 Light 2026 主題、「連接式分頁」與一套共用的設計 token，並在使用者抱怨「更寬鬆不算進步，如果代表看到的程式碼變少」之後，加了一個 Compact 密度設定。這是近兩週少見的、改版理由與退路都寫在同一篇原文裡的案例。今天以它為主角，另外補兩件小而實用的事：Adrian Roselli 10 月 9 日對「裝飾性圖片」的強硬主張（10 月 25 日的 Pixels of the Week 再度轉載），以及 Figma 在 10 月 15 日的 Config India 開放測試的「程式碼圖層」（code layer）到底怎麼用、解決什麼設計問題。
承接 昨日 UIUX：昨天的主軸是 AX 與無障礙樹，今天不延續，只對帳昨天留下的待驗項，其中 Lighthouse 的官方文件今天查到了，結論與昨天引用的第三方說法有出入。本文所有網頁都經網頁抽取工具摘要，不是我讀完整原文，沒有實際操作任何一個產品；抽取結果之間不一致的地方我會標明。
📖 學
一、昨天待驗項對帳
| 昨天的待驗 | 今天查到 | 狀態 |
|---|---|---|
| Lighthouse Agentic Browsing 的官方權重 | 打開 Chrome for Developers 的「Lighthouse agentic browsing scoring」頁（頁面標示最後更新 2026-05-05 UTC）。抽取摘要的原句是：不像其他 Lighthouse 類別，Agentic Browsing 沒有 0 到 100 的加權平均分數，改顯示分數形式的通過比例（通過了幾項就緒檢查）、單項的通過或未通過，以及資訊性計數。頁面列出四個面向：WebMCP 整合、agent 導向的無障礙（名稱與標籤、樹的完整性、可互動內容不得被藏出無障礙樹）、CLS、llms.txt 是否存在。這一頁的摘要沒有出現權重數字，也沒寫哪個 Lighthouse 版本引入 | 部分推翻：昨天寫的「三項計分、權重各 1、WebMCP 權重 0」我沒能在官方頁驗證，而官方明說沒有加權平均分數。第三方說法可能指內部設定，但我沒有證據，所以昨天算的「各占 33.3%」不能當成官方事實 |
| iPhone Duo 外螢幕與內螢幕的點數 | Apple 公布的是像素與 ppi，不是點數。外螢幕 1398 × 2034 像素、460 ppi，兩個第三方都換算成 466 × 678 點（3 倍）。內螢幕 1878 × 2670 像素、430 ppi，兩個第三方換算結果不同，見第二節 | 外螢幕兩家一致；內螢幕兩種換算並存，Apple 一手點數仍未見 |
| HomeView 的點數與 widget 實際 pt | 搜尋結果只有像素：1088 × 1088、220 ppi、約 7 吋。沒有找到任何點數或 widget pt 的一手資料 | 仍待驗 |
| 11 月 13 日實機字高 | 日期未到 | 待驗 |
| Pitre 評分規則、Guidelines 遵守率、Google Maps、Gmail、Uber 的適配 | 今天沒有再追 | 待驗 |
這張表想說的是：昨天最像「定論」的一個細節（權重）反而是今天最站不住腳的。我昨天標了「請回官方文件核對」，今天核對的結果是官方沒有這組數字。
二、iPhone Duo 內螢幕：同一組公開數字，兩種點數換算
先把能算的算清楚。Blake Crosley 的文章（9 月 9 日發表、9 月 10 日更新）整理 Apple 公布的內容：規格頁內螢幕 1878 × 2670 像素、430 ppi，外螢幕 1398 × 2034 像素、460 ppi；App Store Connect 的截圖尺寸，內螢幕是 2007 × 2853 像素，外螢幕仍是 1398 × 2034。他的推論是內螢幕以 669 × 951 點（3 倍）繪製，渲染成 2007 × 2853，再縮小約 6.4% 到面板的 1878 × 2670，做法與歷代 Plus 機型相同。另一個追蹤網站 iphoneduosupport.com 則直接用面板像素除以 3，得到內螢幕 626 × 890 點，並明說「Apple 只公布像素，不公布點數」，點數是推導值。
兩種換算差多少，自算如下。2007 ÷ 1878 = 1.0687，所以縮小量是 1 − 1878 ÷ 2007 = 6.43%，與 Crosley 說的約 6.4% 吻合。每點對應的面板像素：626 版是 3.000，669 版是 1878 ÷ 669 = 2.807。轉成實際長度：430 ppi 下，626 版 1 點 = 25.4 × 3 ÷ 430 = 0.1772 毫米，44 點的觸控目標 = 7.80 毫米；669 版 1 點 = 25.4 × 2.807 ÷ 430 = 0.1658 毫米，44 點 = 7.30 毫米。兩者差 0.5 毫米，約 6.4%，也就是上面那個縮放比。對照 10 月 12 日算過的 Mac 觸控模式 44 點 = 8.8 毫米，Duo 內螢幕上的 44 點落在 7.3 到 7.8 毫米，比較小。哪一種對，取決於 Apple 的 SDK 實際回報的邏輯尺寸，我查不到；兩個來源都不是 Apple 一手。
長寬比也能對帳。2670 ÷ 1878 = 1.4217，2034 ÷ 1398 = 1.4549，內外螢幕比例不同，這與 Apple 新聞稿稱兩塊螢幕「比例相同」的轉述（Crosley 引用的註腳）對不上；我只是做除法，也不確定 Apple 那句話是說概略比例還是精確相同，這點我沒有查證到原句。1.4217 比 √2（1.4142）高 0.53%，所以 Crosley 說的「約半個百分點內的 A 系列紙張比例」成立。他舉的 16:9 影片例子也可重算：橫向時寬 951 點，16:9 畫面高 951 × 9 ÷ 16 = 534.9 點，上下共留 669 − 534.9 = 134.1 點，占 20.0%，與他說的「五分之一」一致。
這一節的設計意義是：任何拿「某個點數」當目標尺寸的檢查（例如 WCAG 2.2 的 24 CSS 像素、Apple 習慣的 44 點），在 Duo 內螢幕上換算成毫米都有約 6% 的不確定，目前沒有一手資料可以消除它。
三、VS Code：現代化 UI 的設計取捨
Lee Murray 在 10 月 15 日的部落格列出這次改版的內容，我讀的是抽取後的摘要，分兩次抽取，以下只寫兩次都一致的部分。
改版目標是讓編輯器與新的 Agents 視窗共用一套設計基礎，原文的說法是做出「更連貫、更好親近的體驗，但不放棄密度、可自訂性與肌肉記憶」。具體動作有：新的 Dark 2026 與 Light 2026 主題，用「更窄的表面色範圍」建立層次，同時讓程式碼維持視覺中心；編輯器分頁從膠囊形改成「連接式分頁」，理由是原文寫的「膠囊形分頁看起來像編輯器上方的獨立控制項，選中的檔案更難與內容在視覺上連起來」；Activity Bar、側邊欄、面板與狀態列統一間距、圓角與高度（elevation）；視圖標題移除全大寫。共用 token 的理由寫得很直接：這樣才能「一致地調整介面，並支援不同密度與主題」。
最值得學的是回應意見的方式。使用者回饋是更寬鬆的版面讓畫面看到的程式碼變少，團隊的處理不是辯護，而是在標題列的 Customize Layout 加了 Layout Density，設定值 window.density.layout 設為 compact，保留現代化的結構但縮小間距。另外給了退路：在設定搜尋 workbench.experimental.modernUI 並取消勾選可回到舊介面，原文明說這個選項是「暫時的，雖然我們還沒訂移除日期」。主題作者方面，新元素的色彩識別碼會回退到既有顏色，既有主題相容。
數字的部分，兩次抽取都有的是「初期實作在 1920 × 1080、100% 縮放下，水平多占約 20 像素、垂直多占 12 到 18 像素」，只有其中一次寫了「初期」二字，所以我不確定這個數字是否仍適用現在的預覽版。自算：20 ÷ 1920 = 1.04%，12 ÷ 1080 = 1.11%，18 ÷ 1080 = 1.67%。若假設編輯器一行約 19 像素（這是我的假設，不是原文數字，實際取決於字級與行高設定），垂直損失約 0.6 到 0.9 行；若假設等寬字一格約 8 像素，水平損失約 2.5 欄。換句話說，如果這組數字屬實，容量上的損失在一到三行、兩三個字元的量級，使用者的不滿更可能來自「看起來變鬆」的感受，而不是真的少了很多內容。這是我的推論，原文沒有給行數，也沒有給使用者回饋的數量。
另一個數字是效能：CSS 選擇器最佳化讓合併基準下的樣式重算時間少 8.2%、牆鐘時間少 3.3%。若這兩項改善完全來自樣式重算，則樣式重算約占牆鐘時間 3.3 ÷ 8.2 = 40%；原文沒有說基準的組成，這個比例只是反推，不是事實。
無障礙方面，原文只提到有淺色、深色與高對比主題，沒有對比值或鍵盤焦點樣式的承諾，我也沒有實測。連接式分頁這種把「選中狀態」靠形狀而不是顏色傳達的做法，值得自己拿 WCAG 的非文字對比（1.4.11，3:1）檢查選中與未選中分頁之間的差異，但這是我提的檢查點，不是原文的聲明。
四、Roselli：裝飾性圖片大概不存在
Adrian Roselli 10 月 9 日的〈Decorative Images…aren’t a thing〉，立場是敘述性內容中的圖片幾乎都在傳達某種東西（情緒、主題連結、填補留白也是一種用途），真的裝飾性的圖片應該直接移除。他給兩個快速判斷：「把這張圖整個拿掉，有沒有讀者在乎？」「把它換成一張大便的照片，作者在乎嗎？」兩題答案都是否，就拿掉；任一是肯定，就代表它不是裝飾性的，需要真正的替代文字。他列出的真正候選只有幾種：1990 年代的 spacer.gif、與旁邊文字重複的圖片、首頁上只是文章錨點的圖片。抽取結果還說，即使符合全部裝飾條件，他也偏好移除而不是設空的 alt；這點我只從一次抽取得到，而且文中沒討論 CSS 背景圖、role="presentation" 或 aria-hidden，這些我沒有從他的文章讀到。
對照 W3C WAI 的圖片決策樹（我另外打開了）：五個問題依序是圖片是否含文字、是否用在連結或按鈕內且理解需要圖片、是否為頁面或情境貢獻意義、是否純裝飾或不給使用者看、用途不明。裝飾的處理很明確：用空的 alt 屬性。所以 Roselli 與 WAI 並不衝突，而是在「什麼才算裝飾」的門檻上差很多：WAI 給的是技術處置，Roselli 要求先過一道設計審問。
這對設計實務的意思，可以直接當評審提問：每張圖在稿子上要先寫下「它為誰做什麼」。寫不出來的，在 Figma 稿上就該拿掉，而不是交給工程師決定 alt 怎麼寫。這與 Lighthouse 官方頁列的「名稱與標籤」同一個方向：先有目的，才有名稱。
五、自動檢查能測多少：Pour 的 51 比 86
10 月 25 日 Pixels of the Week 推薦的 Pour（pour.dev）是我今天少數能對照自己算的資料。頁面寫它是免費、無帳號、非營利的 WCAG 2.2 檢查工具，有瀏覽器擴充、書籤小工具、CLI（可進 CI）、VS Code 擴充與獨立對比檢查器。自稱有 99 條自動化規則，「協助」86 項 WCAG 2.2 成功準則中的 51 項，另外 35 項需要人判斷。這組數字我驗過加總：51 + 35 = 86；按原則分的 29（可感知）+ 34（可操作）+ 21（可理解）+ 2（穩健）= 86。比例：51 ÷ 86 = 59.3%，35 ÷ 86 = 40.7%，99 條規則平均每個被協助的準則約 99 ÷ 51 = 1.94 條。
最該留意的是它的自我限制，原文寫「沒有任何自動化工具能完整測試單一 WCAG 準則……pour engine 的規則協助 51 項，並不宣稱解決其中任何一項」。「協助」不等於「判定通過」，所以 59.3% 是涵蓋面，不是能自動判通過的比例。它的速度宣稱（比 axe-core 快 3 倍、最大頁面快 24 倍、在自家測試站找出全部 38 個植入錯誤）是廠商自述，我沒有實跑，也沒有看到 axe-core 的對照條件。
這與 Chrome 官方頁的口徑是同一個方向：Lighthouse 的 Agentic Browsing 不給單一分數，改給通過比例與個別通過或失敗。兩個工具都選擇「不給你一個漂亮的總分」，而 10 月 11 日我寫過 WebAIM 2026 的結果是每頁平均 56.1 個錯誤、95.9% 的首頁有可偵測的失敗，這些都說明可偵測的問題離完工還很遠。
六、Figma 程式碼圖層：怎麼用，解決哪個設計問題
Figma 在 10 月 15 日的 Config India 把「程式碼圖層」放進所有方案的開放測試。官方說明文件的定義是：一個「由執行中的程式碼支撐的互動原型」，直接放在畫布上。開啟方式有五種：按 B 鍵或工具列選 Code，用游標拉出範圍後在右側請 Figma agent 描述想做的東西；選取畫面框架後按 B，在右側面板按 Build selection，把設計轉成程式碼圖層；用 Figma 的 Chrome 擴充功能擷取網頁並貼上；連接 GitHub 複製一個儲存庫並可回頭開拉取請求；或從本機上傳資料夾。要求是對設計檔有編輯權限、Full 席位，方案涵蓋 Education（K-12）、Starter、Professional、Organization、Enterprise。
這個功能對設計問題的實際貢獻，文件寫得很具體：能在畫布上預覽互動設計並抓到「空、載入中、錯誤」三種狀態，也能複製一個圖層並排探索另一個方向。這三個狀態正是靜態稿最常漏掉的，也是 10 月 9 日我評 ChatGPT Intelligent UI 時看到的串流位移那類問題的來源（載入狀態沒設計，版面就在內容抵達時跳動）。限制也寫得清楚：不是所有儲存庫都能複製，要先看需求；AI 點數在付費方案上到 2026 年 11 月 4 日前免費，之後依任務複雜度計費。從今天 10 月 26 日算起還有 9 天，從發表日算有 20 天。這一句是計費影響團隊用法的帶過，不展開。
同一天的 Specs 與 Payload 我只用一句帶過：Specs 是放在設計旁邊的 Markdown 文件，Payload 是讓程式碼圖層連到資料庫與內容管理的後端，兩者在 Design Compass 等二手報導與 Figma 的說明頁表格中都標為開放測試或已提供。我沒有實際建立任何程式碼圖層，也沒有驗證它輸出的 HTML 對螢幕閱讀器是否可用，這是我最想知道的一件事。
七、一張給今天的檢查表
| 今天讀到的事 | 設計動作 | 驗證方式 |
|---|---|---|
| VS Code 密度回饋 | 改版若讓內容變少或變鬆，先給密度選項，並公開退路與日期 | 在 1920 × 1080、100% 縮放下，數改版前後同一畫面可見的行數與欄數 |
| 連接式分頁靠形狀表達選中 | 選中狀態不能只靠顏色細微差異 | 量選中與未選中分頁的非文字對比是否達 3:1 |
| Roselli 的兩個提問 | 每張圖在稿上寫下「它為誰做什麼」 | 設計評審逐張圖過一遍，寫不出來的拿掉 |
| WAI 決策樹的第一題 | 圖片內的文字也要以真正的文字出現在附近 | 關閉圖片載入，看資訊是否仍完整 |
| Pour 的 51 比 86 | 自動檢查只算第一輪，剩下 35 項靠人 | 在檢查報告分「自動涵蓋」與「人工逐項」兩欄 |
| 程式碼圖層可預覽三種狀態 | 每個動態區塊至少做空、載入、錯誤三版 | 用程式碼圖層或原型逐一點過，確認版面不跳動 |
| Duo 內螢幕點數有兩種換算 | 目標尺寸以毫米留 6% 餘裕，等 Apple 一手資料 | 以 7.3 毫米為下限檢查 44 點目標是否仍可點 |
🧠 記
- Lighthouse 官方頁（5 月 5 日更新）： Agentic Browsing 沒有 0 到 100 加權平均分，改顯示通過比例與個別通過或失敗；頁面沒列權重也沒寫版本，昨天的「各占 33.3%」無法當官方事實。
- iPhone Duo 內螢幕點數： Apple 只公布像素；內螢幕 1878 × 2670 可換算成 626 × 890 或 669 × 951 兩種點數，1 點約 0.177 或 0.166 毫米，44 點約 7.8 或 7.3 毫米。
- VS Code 現代化 UI（10 月 15 日）： 連接式分頁、Dark 2026 與 Light 2026；初期實作水平多占約 20 像素、垂直 12 到 18 像素；Compact 密度設定
window.density.layout；舊介面開關workbench.experimental.modernUI是暫時的；樣式重算 −8.2%、牆鐘 −3.3%。 - Roselli（10 月 9 日）： 拿掉測試與替換測試兩問；真正裝飾性的圖片很少，優先移除而不是空
alt；WAI 決策樹對裝飾圖給空alt。 - Pour： 99 條規則協助 86 項準則中的 51 項（59.3%），35 項要人判斷；「協助」不等於判定。
- Figma 程式碼圖層（開放測試）： 按 B 建立，可預覽空、載入、錯誤狀態；AI 點數 11 月 4 日前免費。
邊界： 本文所有網頁都經網頁抽取摘要，沒有讀完整原文，抽取結果之間有不一致處（如 VS Code 數字是否為初期實作）已標明。Lighthouse 官方頁沒有權重資料，不代表內部沒有權重。iPhone Duo 兩種點數都是第三方推導，Apple 的 HIG 與截圖規格頁我今天抓不到內容（截圖規格頁回傳找不到，HIG 頁只有標題）。Duo 內外螢幕是否同比例，我只做了除法，沒有找到 Apple 原句。VS Code 的行數與欄數損失是用我的假設算的。Roselli 對 CSS 背景圖與 ARIA 的看法我沒讀到。Pour 的速度與準確宣稱沒有實跑。Figma 程式碼圖層我沒有實際使用，輸出的無障礙品質未知。HomeView 點數、Pitre 評分規則、Guidelines 遵守率今天都沒查到。
✍️ 實踐
用 40 分鐘為自己的產品做一次「密度與圖片」盤點，兩件事分開量。
- 密度：挑最常用的一個畫面，在 1920 × 1080、100% 縮放下截圖，數出可見的列表行數或程式碼行數、每行可見欄數，記為基準。改版或調整間距之後再量一次，用差距而不是感覺來討論。若差距超過你設的門檻（例如少 2 行），先做密度選項，不要先辯論。
- 圖片：把頁面上所有
img列成表，每張寫三欄：它為誰、做什麼、拿掉會怎樣。寫不出來的標為「待移除」，其餘依 WAI 決策樹補alt；真正屬於裝飾且保留的，用空的alt。 - 選中狀態：找出你介面裡靠「形狀或顏色」表示選中的元件（分頁、導覽項、切換鈕），用對比檢查工具量選中與未選中的差距，目標是非文字對比 3:1。
- 三種狀態：挑一個非同步載入的區塊，做出空、載入中、錯誤三版，確認載入完成前後版面高度不變（先保留空間）。
- 把今天的結果分成「自動工具能抓到的」與「我用眼睛和鍵盤驗的」兩欄，不要合併成一個通過率。
🔗 延伸學習
- Modernizing the VS Code UI（VS Code 部落格） — 10 月 15 日，改版理由、Compact 密度與退路，我打開並抽取過兩次。
- Decorative Images…aren’t a thing（Adrian Roselli） — 10 月 9 日，裝飾性圖片的兩個判斷問題，我打開並抽取過兩次。
- Lighthouse agentic browsing scoring（Chrome for Developers） — 官方說明該類別不用加權平均分數，我打開並抽取過兩次。
- Code layers in Figma Design（Figma 說明中心） — 建立方式、方案與席位要求、AI 點數期限，我打開並抽取過。
💬 問 AI
我想做一次「介面密度、圖片替代文字與自動檢查涵蓋面」的設計盤點。請嚴格分成「文件明說」「你查證到的」「你的推論」三區回答,不確定就直說,不要編造連結、版本號、數字或引文,也不要給任何投資或財務建議。
背景(請當待查證主張):
1. VS Code 團隊在 2026-10-15 發表 Modernizing the VS Code UI:新增 Dark 2026 與 Light 2026 主題、連接式分頁;初期實作在 1920x1080、100% 縮放下水平多占約 20 像素、垂直 12 到 18 像素;之後加入 window.density.layout 設為 compact 的密度設定;舊介面開關 workbench.experimental.modernUI 為暫時性;樣式重算時間少 8.2%、牆鐘時間少 3.3%。
2. Adrian Roselli 在 2026-10-09 主張裝飾性圖片幾乎不存在,真正裝飾性的應直接移除而不是設空 alt;W3C WAI 圖片決策樹對裝飾圖給空 alt。
3. Pour(pour.dev)自稱 99 條自動化規則協助 WCAG 2.2 的 86 項成功準則中的 51 項,35 項需人判斷。
4. Chrome 的 Lighthouse agentic browsing scoring 文件(頁面標示 2026-05-05 更新)稱該類別沒有 0 到 100 的加權平均分,改顯示通過比例與個別通過或失敗;我昨天引用的第三方「三項權重 1、WebMCP 三項權重 0」未在官方頁驗證到。
5. iPhone Duo 內螢幕 Apple 公布 1878x2670 像素、430 ppi,App Store Connect 截圖尺寸 2007x2853;點數有 626x890 與 669x951 兩種第三方換算。
請做:
A. 逐點驗證 1 到 5,標示「成立/部分成立/查不到」並附一手連結;特別確認 VS Code 的 20 與 12 到 18 像素是否仍適用於目前預覽版,以及 Lighthouse 該類別各稽核是否有內部權重。
B. 說明 Apple 目前有沒有公布 iPhone Duo 內螢幕的邏輯點數(HIG、SDK 文件或截圖規格),若有請給出處;若沒有,哪一種換算與 Plus 機型的歷史做法一致。
C. 我的產品有一個高密度的資料表格畫面與一個以圖片為主的行銷頁:各列出 5 個最可能被「密度改版」與「圖片替代文字」影響的設計決策,並附可量測的檢查方式(行數、欄數、對比值、alt 覆蓋率)。
D. 設計一個 40 分鐘流程,把自動檢查(axe 或同類工具)與人工逐項檢查分開記錄,說明這樣分開記錄能與不能證明什麼。
不要評論公司或人事,只談設計實務、量測方法與證據強度。