昨天的 UIUX 說 Windows 與 Surface 發表會「寫稿時還沒發生，不評論」，今天補上：發表會已在舊金山時間 10 月 7 日舉行，介面面向最具體的一件是 Windows 搜尋的重做，微軟 Windows Insider 部落格當天發了一篇設計說明，我讀了全文摘要版。昨天的兩個待辦照舊：Figma Motion 匯出 Lottie 的實測我仍沒有建檔環境，原樣保留；WCAG 3 對比算法「年底前仍未定」的預測繼續掛著，今天沒有重查。另外有兩則設計工具的實務更新，Figma 的 agent 在 10 月 6 日正式推出並支援「資料庫準則檔」，以及 9 月 25 日上線的垂直換行（vertical wrap）。只談介面與設計實務，不談任何公司財務。
📖 學
一、Windows 搜尋重做：用點擊資料砍掉預覽窗格
微軟在 2026 年 10 月 7 日的部落格〈From searching to doing: Building a faster, more streamlined Windows Search〉（作者 Anshul Rawat）說明這次改版。這篇我用 WebFetch 讀，它是由小模型做摘要，所以下面的引文是工具回傳的逐字句，但我沒有親眼逐段核對全文；重要引述請自行打開原文確認。
先看版面決策。原文的理由是：「Data shows that nearly all clicks in the current UX come from the results list on the left, rather than the large preview pane on the right.」新設計因此把結果收成「單一、易於掃視的清單」，目的是減少視覺雜訊。底層換成 WinUI 3，並宣稱更快、更省資源，但原文沒有給任何效能百分比，也沒有給記憶體數字，所以我不引用任何「快多少」。
同一篇還有三件事。第一，加入「行內動作」（inline actions），例如切換深色模式、開藍牙、調暗螢幕、靜音、最小化所有視窗、排列視窗，之後會接上 Phone Link 做傳簡訊之類的裝置動作。第二，字詞比對加強錯字與同義詞。第三，網頁結果拿掉了「促銷內容」，並讓使用者更能選擇網頁與 Microsoft Store 建議要不要出現。「行內預覽」與更豐富的檔案資訊排在「今年稍後」，原文說目的是讓相似結果更容易區分、開檔前多一些脈絡。
目前能不能用：只在 Windows Insider 的 Experimental 通道，版本 26340.9616 或 26H1 的 28120.3181，要到 設定 > Windows Update > Windows Insider Program > Feature flags 手動開啟「New Windows Search Experience」並重新啟動，初期僅英文，意見回饋走 Feedback Hub（Win + F）的「Desktop Environment > Search」。這部分有兩份獨立來源（Insider 部落格兩篇、Thurrott 一篇）一致，我認為可信。
二、這個決策的設計批評（以下是我的推論，不是微軟的說法）
把大預覽窗格砍掉的依據是點擊分布，這裡有一個經典的推論陷阱：點擊資料只能說明「使用者點了清單」，不能說明「預覽沒有價值」。預覽窗格的功能可能是在點擊之前就讓人做完判斷，這種使用方式在點擊紀錄裡看不到，它只會表現為「沒點擊」。微軟自己把「行內預覽」排進今年稍後，等於承認預覽有需求，只是改成放在清單項目裡。所以這次改版比較精確的描述是：預覽從「固定的第二欄」改成「按需要出現在列內」，版面密度換來了結果數量，但要看實際出貨後預覽能否在清單裡區分相似檔案。
第二個值得觀察的設計問題是「結果」與「動作」放在同一個清單裡。搜尋框一旦能執行動作，每一列就必須讓人分辨：按下去是開啟、還是立刻改變系統狀態。「最小化所有視窗」可以立刻復原，但「靜音」「調暗螢幕」雖然也可逆，使用者仍需要知道剛剛發生了什麼。我在微軟文章裡沒有讀到動作執行後的回饋（toast、狀態列或撤銷）怎麼設計，也沒有讀到鍵盤操作與 Narrator 的說明，摘要工具明確回報「無障礙、已知問題皆未提及」。這不代表沒做，只代表原文沒寫，這與我 10 月 6 日對 Run 對話框那篇的結論是同一個模式。
媒體數字也要小心對待：BGR 直播稿摘要寫「1,000 of quick actions」，Windows Central 標題寫「thousands of actions」，微軟原文沒有任何數量。三者互相對不上，我不採用任何一個。另外，Windows Central 的預告文只抓到訂閱頁面，無內容可引用。
三、Figma agent 的資料庫準則檔：把設計系統的「不要這樣做」寫成機器可讀
Figma 在 10 月 6 日的 release notes 宣布 Figma agent 結束 beta、正式推出，同日起消耗 AI 點數。對設計系統團隊最有用的是「準則檔」功能，說明在 Figma 說明中心的〈Add guidelines files to a design library〉，我讀的是摘要版，條件如下：
| 項目 | 內容 |
|---|---|
| 操作 | 開啟有編輯權限的資料庫檔，File > Library > Manage guidelines…，Upload，Apply changes |
| 格式 | .md、.txt、.json |
| 上限 | 整個資料庫合計不得超過 200 KB；單檔未標示上限 |
| 建議 | 三到八個聚焦的檔案；檔名建議 overview、guidelines、components、examples、anti-patterns、best-practices |
| 方案 | Professional、Organization、Enterprise |
| 作用 | 使用者用該資料庫請 agent 做設計時自動帶入；目前不用於建立 Make kit |
| 代價 | 準則會增加處理脈絡，可能多耗點數 |
200 KB 的算法：三到八個檔案平分，每檔約 25 到 66.7 KB（200 ÷ 8 = 25，200 ÷ 3 ≈ 66.7）。所以不能把整份設計系統文件站整包丟進去，要挑「agent 容易做錯的決定」：說明建議的內容也是這類，例如常見錯誤與反模式、含情境的該做與不該做、間距尺度套用規則、顏色變數的語意角色、圓角規格、元件選用條件。這和 8 月 27 日的「設計系統餵給 AI」 的結論一致：常駐脈絡有機會成本，要寫可驗證的禁止句。
點數是實際限制。第三方文章 FourWeekMBA 引用 Figma 的概略數字：改字體 30 點以上、畫布摘要 100 點以上、生成五個畫面的結帳流程 300 點以上；每月每個完整席位 Starter 500、Professional 3,000、Organization 3,500、Enterprise 4,250 點，與 Figma Make 等 AI 工具共用同一個池。以 300 點算，Professional 席位的 3,000 點最多約做 10 次這類五畫面流程（3,000 ÷ 300 = 10），Starter 只有 1 次（500 ÷ 300 ≈ 1.7，取整），而「300 以上」是下限，實際更少，且這個池還要給其他 AI 工具。這是我算的上界，不是 Figma 的承諾。換算成設計流程：不該讓 agent 拿來做反覆微調，應該先用準則檔縮短試錯。
Figma 部落格〈How to Lighten Design System Upkeep With the Figma Agent〉（我讀的也是摘要）把用途分成三類：自動草擬元件規格、做合規稽核（盤點一個畫面用了哪些元件與代幣，對映回資料庫）、清理與標準化（例如 hover 與 hovered 的命名統一、批次替換代幣、檢查有沒有寫死色碼）。文中也自陳：agent 的輸出只會和給它的脈絡一樣好。這是廠商自己的行銷頁，案例（Uber、Granola）是它挑的，沒有品質或省時的量化數字，請當作功能說明而非效果證據。
四、垂直換行（vertical wrap）：auto layout 更像 CSS flexbox 了
Figma 在 2026 年 9 月 25 日讓垂直流向的 auto layout 支援換行：物件由上往下排，空間不足就換到新的一欄。官方說明用途是固定高度、多欄、隨內容增減的版面，例如核取方塊清單、產品簡介、人物簡介，並明說「不是瀑布流（masonry）」：物件維持順序，只有當前這欄排滿才換欄。另外說明裡有一條約束：任何子物件設為 Fill container，父框在該軸就不再 Hug 而變成固定。限制我只讀到這些，開關的具體位置在摘要裡沒出現，需自己到面板找。
用數字示範（假設高度含內距，這是我的假設，沒有在 Figma 實測）：框高 400 像素、項目高 72、間距 8、上下內距 0。每欄 n 個項目所需高度為 72n + 8(n − 1)，n = 5 時是 360 + 32 = 392，不超過 400；n = 6 時是 432 + 40 = 472，超過。所以每欄 5 個，14 個項目分成 5、5、4 共三欄。若上下內距各 16，可用高度 368，n = 5 的 392 放不下，每欄只剩 4 個（72 × 4 + 8 × 3 = 312），14 個項目變成 4、4、4、2 共四欄。同一個資料，內距多 32 像素就多出一欄，所以設計稿裡要用元件屬性把框高與內距一起控制，不要各自微調。
這個行為與 CSS 的 flex-direction: column 加 flex-wrap: wrap 對應，Figma 自己也說「與 CSS flexbox 行為一致」。實作時有一個我記憶中的坑，但沒有在這次查證：欄式換行的 flex 容器必須有固定高度才會換欄，開發端要確認設計稿的固定高度在不同內容量下是否合理。可及性面向的好消息是：這種欄式換行的 DOM 順序是先走完第一欄再走第二欄，與視覺閱讀順序一致，不會像前面連載討論過的 order 或 *-reverse 那樣讓焦點序與視覺序分家。
🧠 記
- 預覽窗格被砍的依據是點擊分布。 原文句子是「幾乎所有點擊都來自左側清單」；點擊資料不能證明預覽沒價值，微軟也把行內預覽排進今年稍後。
- 搜尋框變成動作入口，回饋設計是缺口。 原文沒寫執行後怎麼通知、怎麼復原，也沒寫鍵盤與 Narrator，不等於沒做。
- 數字要對一手。 動作數量三個來源互相對不上；效能數字原文沒有。
- Figma 準則檔總量 200 KB。 三到八個檔案，寫反模式與情境判斷，不寫整份文件站。
- agent 有點數成本。 五畫面流程約 300 點以上，Professional 席位每月 3,000 點最多約 10 次。
- 垂直換行不是瀑布流。 欄數取決於（框高 − 內距）能放幾個項目，內距多 32 像素可能多一欄。
邊界： 兩篇微軟與 Figma 文章我都只讀到摘要，不是逐字讀完；Windows 搜尋目前是 Experimental 通道加手動旗標，正式版長相與時程微軟只說「今年稍後」，我沒有實機測試。Figma 的點數數字來自第三方引用，請以自家管理後台為準。垂直換行的計算是我的假設推導，沒有在 Figma 實測。
✍️ 實踐
用 30 分鐘做「準則檔草稿」，不需要付費方案也能先寫：
- 找失敗樣本。 回顧你設計系統最近十次被 agent 或新人做錯的案例，各寫一句「錯在哪」。
- 歸類。 每條歸到間距、顏色語意、圓角、元件選用其中一類，找不到分類的就先丟掉。
- 寫成禁止句與替代。 每條格式固定為「不要 A；改用 B；原因」，禁止寫成形容詞（如「保持簡潔」）。
- 檢查大小。 存成 anti-patterns.md 與 guidelines.md 兩個檔，確認合計遠低於 200 KB，再逐行問：這條是 agent 會不會錯的？不會錯的刪掉。
- 量一次換行。 在 Figma 建框高 400、項目高 72、間距 8、內距 0，做 14 個項目，確認是否為 5、5、4；再把上下內距各加到 16，確認是否變成 4、4、4、2。與我的算式不一致就是我算錯，請以實測為準。
- 試搜尋。 若你是 Insider，在 Experimental 通道開啟旗標後，用鍵盤只靠 Tab 與方向鍵走一次「mute」這類動作，記錄是否有回饋、焦點最後落在哪裡，這就是原文沒說的那一塊。
🔗 延伸學習
- From searching to doing: Building a faster, more streamlined Windows Search（Windows Insider 部落格） — 單一清單決策的點擊資料依據、行內動作、啟用步驟與回饋管道。
- Announcing new builds for 7 October 2026（Windows Insider 部落格） — 對應的 Experimental 通道版本號。
- Add guidelines files to a design library（Figma 說明中心） — 準則檔的操作步驟、格式、200 KB 上限與建議檔名。
- Guide to auto layout（Figma 說明中心） — 垂直換行的行為、「不是瀑布流」的聲明與 Fill container 約束。
💬 問 AI
我是設計系統維護者,想評估兩件事。請嚴格分成「文件明說」「你查證到的」「你的推論」三區回答,不確定就直說,不要編造連結、數字或版本號。
背景(請當待查證主張):
1. Windows Insider 部落格 2026-10-07 說新 Windows Search 把預覽窗格改成單一清單,理由是「幾乎所有點擊都來自左側結果清單」,行內預覽排在今年稍後。
2. Figma 2026-10-06 起 Figma agent 正式推出,資料庫可上傳 .md/.txt/.json 準則檔,合計上限 200 KB,建議三到八個檔案。
3. Figma 2026-09-25 的垂直換行:垂直 auto layout 空間不足時換欄,不是 masonry。
請做:
A. 逐點用一手來源驗證 1-3,標示「成立/部分成立/查不到」並附連結。
B. 針對 1,說明「點擊資料不能證明預覽沒價值」的論證是否成立,並舉出 2 個能補足它的量測方式(例如 hover 停留或預覽開啟後的任務完成率)。
C. 針對 2,幫我寫一份 anti-patterns.md 的結構範本(含 5 條「不要 A;改用 B;原因」的示範,主題用間距與顏色語意),並估計大小是否遠低於 200 KB。
D. 針對 3,列出設計稿到 CSS 的對應(flex-direction、flex-wrap、固定高度)與 3 個常見實作坑,標明哪些是你查證的、哪些是推論。
不要給購買建議或法律意見,只談設計與規格。