昨天留下的「HIG 有沒有 HomeView 條目」，今天有了一手答案：有，但只有兩頁，而且最實用的那一頁講的是小工具（widget）。Apple 在 10 月 13 日更新《人機介面指南》（HIG）的 Widgets 頁，變更紀錄寫「Added guidance for Apple HomeView, and updated watchOS specifications」。我直接下載 Apple 的 HIG 資料檔（developer.apple.com 的 tutorials/data/design/human-interface-guidelines/widgets.json）讀全文，另抽查 carplay、live-activities、typography、layout、color 等十餘頁，只有 widgets 與 carplay 兩頁出現 HomeView；carplay 那頁只有一則註記，內容和昨天讀的 CarPlay 指南一致。換句話說，HomeView 沒有自己的 HIG 頁，它的設計規則是分散寫進既有頁面。
同一週還有另一條值得讀的線：Figma 在印度的 Config 活動（10 月 14 日，官方部落格文章標 10 月 15 日）推出 Specs，把設計規範、產品文件寫成能放上畫布、也能讓 AI 代理（agent）讀取的 Markdown。兩件事的共通點是「規範被機器消費」：HIG 的表格決定小工具在哪裡、用什麼渲染模式出現；Specs 讓團隊把自己的規範寫成代理讀得懂的文件。今天先把昨天的待驗對帳，再算 HomeView 小工具的格子，最後講 Specs 怎麼用。承 昨天的 UIUX，11 月 13 日出貨前沒有實機，所以實測類的待驗維持不變。
📖 學
一、昨天待驗的對帳
| 昨天的待驗 | 今天查到 | 狀態 |
|---|---|---|
| HIG 是否有 HomeView 條目 | Widgets 頁有完整一節（變更紀錄 2026-10-13）；CarPlay 頁有一則註記；沒有獨立頁 | 部分解決 |
| HomeView 的點（pt）規格 | Widgets 頁所有尺寸表（iPhone、iPad、Apple Watch、visionOS）都沒有 HomeView 欄，只有「哪個家族出現在哪」與「渲染模式」兩張表有 | 查不到，維持待驗 |
| 第三方 App 的歌詞規則是否在 HomeView 放寬 | CarPlay 指南第 6 頁原文仍是「Never show song lyrics on the CarPlay screen」，沒有任何 HomeView 例外 | 查不到，維持待驗 |
| 11 月 13 日實機字高、距離切換臨界與遲滯 | 尚未出貨 | 待驗 |
| Center Stage 輸出比例與群組通話版型 | 沒有新資料 | 待驗 |
「沒有 pt 規格」值得多講一句：Apple 對每種裝置的小工具都給了 pt 尺寸表（例如 iPhone 393 × 852 的畫面上，小型是 158 × 158 pt），HomeView 沒給。設計師手上只有家族名稱（小型），不知道這個小型在 1088 × 1088 螢幕上最後有多大。這個缺口下面用算的方式補一個上限。
二、HIG 對 HomeView 小工具說了什麼
我把 Widgets 頁與 HomeView 有關的原文整理成表（原文是英文，下面是我的轉述，引號內是原文）：
| 項目 | 原文要點 | 我的讀法 |
|---|---|---|
| 位置 | 人可以把小工具放在 Modular face（模組式面板）與 Home Screen | 兩個容器，性質不同（見下） |
| 尺寸 | HomeView 上的小工具來自小型系統家族（small system family），外觀與 iPhone 小工具相同 | 不需要為 HomeView 另做尺寸，但也沒有更大的尺寸可用 |
| 來源 | 選自已安裝在 HomeView 的（例如 Weather、World Clock），或選自個人連接的 iPad 或 iPhone | 小工具不是裝進 HomeView，而是從手機借來顯示 |
| Modular face | 最多四個小工具，可來自不同家庭成員的 iPhone；例：某人把 Calendar 小工具放上去，「那個人的行事曆會對所有人顯示」；每戶一個 | 這是共用面，等於公開看板 |
| Home Screen | 每位已登錄的家庭成員有自己個人化的一組 | 個人面，才適合放私人內容 |
| 渲染 | Home Screen 可選淺色、深色、clear、tinted 四種外觀；Modular face 的小工具「scaled up in size with the background removed」；環境光低於門檻時套「monochromatic red tint」 | 背景會被拿掉、低光時變單色紅 |
| 渲染模式表 | HomeView：Home Screen 與 Modular face（背景移除）為 full-color 與 accented；Night Mode 的 Modular face 為 vibrant | 三種模式都要驗 |
Apple 自己舉的行事曆例子，是這一節對設計最重要的一句。Modular face 是一個全家人共用的畫面，放上去的內容就是對全家公開；所以如果你的 App 小工具會顯示個人資料（行程標題、訊息預覽、健康數字），在這個面上就是隱私設計問題，不只是版面問題。這是我的推論，HIG 只給了例子，沒有寫「請避免」；但 CarPlay 指南第 6 頁對 CarPlay App 寫過「Never show the content of messages, texts, or emails on the CarPlay screen」，兩者精神一致，HomeView 小工具也沿用 CarPlay 的小工具機制（見下一點）。
另一個值得注意的連結：HIG 在 StandBy 那一段寫「CarPlay 與 StandBy 的小工具都用小型家族、移除背景、放大以符合格狀」，並寫「支援 StandBy 也等於確保你的小工具在 CarPlay 上好用」。HomeView 的 Modular face 渲染描述與 StandBy 幾乎同一句，所以合理的推測是：已經為 StandBy 設計過的小工具，在 HomeView 的 Modular face 上不會太離譜。這是推測，沒有任何文件說三者共用同一條渲染路徑。
三、四個小工具，一格能放幾個字
HIG 沒給 HomeView 的 pt 尺寸，但給了兩個可以算的前提：螢幕是 1088 × 1088 px、220 ppi（昨天的一手規格），Modular face 最多四個小工具。假設排成 2 × 2、沒有邊距與間隔（排列方式 Apple 沒公布，這是上限假設），每格是 544 × 544 px，邊長 62.8 mm。沿用本系列的視角基準 0.403 度（我的假設），一格能放的全形字寬（em）數如下：
| 觀看距離 | 0.403 度：em（px） | 一格寬度（em） | 一行全形字數上限 | 0.3 度：em（px） | 一格寬度（em） | 一行全形字數上限 |
|---|---|---|---|---|---|---|
| 1 公尺 | 60.9 | 8.93 | 8 | 45.4 | 12.0（實際 11.996） | 11 |
| 2 公尺 | 121.8 | 4.46 | 4 | 90.7 | 6.0（實際 5.997） | 5 |
| 3 公尺 | 182.8 | 2.98 | 2 | 136.1 | 4.0（實際 3.998） | 3 |
算式是格寬 544 ÷ em，em 取 距離 × tan（視角）÷ 0.1155 mm，無條件捨去取整字；0.3 度那三格的寬度恰好落在整數邊緣之下（11.996、5.997、3.998），所以捨去後各少一字，不是四捨五入。2 公尺、0.403 度下，一格一行只放得下四個全形字，若扣掉每側約 10% 的內距就剩三個。「23°」「72%」「3 則」這種數字加單位是可以的；「下一場會議 14:30」九個字就必須拆兩行，每行字高不變，那格的垂直容量（2 公尺時約 2.97 行，以行距 1.5 計）就被一個行程吃掉了。
拿 iPhone 比較：158 pt 的小型小工具，在 460 ppi、3 倍的 iPhone（我憑印象取這個規格，沒有逐項查證）上約 26.2 mm，近看 35 公分時視角約 4.3 度。HomeView 一格在 62.8 mm 的情況下是 2.4 倍大，但 2 公尺看只有 1.8 度，約是手機近看視角的 42%。以 12 pt 正文計（我的假設字級），158 pt 寬約 13 個全形字寬；到了 HomeView 2 公尺只有 4.46 em，內容量縮為約三分之一。像素面上則是 544 px 對 iPhone 小型的 474 px（158 pt × 3），只放大 1.15 倍，所以「放大後糊掉」的風險小，真正的限制在字量而不是解析度。
這些數字有三個前提都沒被 Apple 證實：2 × 2 排列、無邊距、視角基準。我把它當作設計時的「預算」，不是 HomeView 的實際規格；11 月 13 日出貨後量一次就能校正。
四、實作上要注意的四件事
- 背景要能被移除。 HIG 要求「Mark your widget’s background as removable」；在 WidgetKit 裡，預設的做法是用
containerBackground(for: .widget)把背景放進容器，系統就能在 StandBy、Modular face 這類情境拿掉它。WWDC23 的《Bring widgets to new places》（session 10027）說明了這個機制，也說明像 Photos、Maps 這種沒有獨立前景內容的小工具，可以用containerBackgroundRemovable(false)退出。背景被拿掉後，文字直接坐在 HomeView 的面板上，對比由面板決定，不是你的背景色決定，所以前景要自己有足夠的對比。 - 狀態不要只靠顏色。 Night Mode 下 Modular face 用 vibrant 模式，低光時整個小工具變單色紅；紅色的「警告」和綠色的「正常」在單色紅下無法區分。這是色彩使用的可用性老問題，在這個面上變成硬限制：狀態要靠文字、圖形形狀或位置表達。HIG 在 StandBy 段落也建議「少用豐富圖片或顏色傳達意義，改用放大與重排文字」。
- 把小工具當公開看板設計。 如前述，Modular face 的內容對全家可見。個人化的內容放在 Home Screen；若同一個小工具兩處都會出現，考慮顯示「摘要」而不是原文。
- CarPlay 的退出機制是否涵蓋 HomeView，我查不到。 CarPlay 指南第 11 頁寫：小工具若在車上不適用，用
.disfavoredLocations([.carPlay], for: [.systemSmall])，仍可被使用者選用但互動會被關閉；第 6 頁列了不適合的情況，包含會被連續點擊刷新超過六次的、依賴資料保護等級 A 或 B 的（因為 CarPlay 使用時 iPhone 大多鎖著）。HomeView 的條件沒寫，開發者協議只說開發者要自行判斷小工具是否「functional and suitable」。HomeView 是否有自己的退出位置，我沒有查到，列為待驗。
五、Figma Specs：把設計規範寫成代理讀得懂的文件
另一條線是設計工具。Figma 官方部落格《Introducing Specs: Markdown as a Medium》說明 Specs 是放在畫布上的 Markdown 容器，要解決的問題是：Markdown 已成為把脈絡交給 AI 代理的通用格式，但它沒有多人協作、沒有和實際設計稿的連結。下面是我讀官方文章（透過網頁抽取摘要）整理出的用法，鍵盤快捷鍵等細節我沒有在 Figma 裡實際操作過：
- 建立： 三種方式，把
.md檔拖進畫布、按鍵盤 D 鍵（待驗）、或點工具列的 Specs 圖示（Figma 與 FigJam 都有）。 - 引用： 可以在文件裡嵌入畫布上的框架、節點、FigJam 圖、程式碼圖層（code layers）與 Code Connect 程式片段；也可以把設計元素拖進文件做註解，或再拖出來並保留屬性。
- 外部脈絡： 連接器有 GitHub（從程式碼庫起草技術規格）與 Hex（跑資料分析並把結果嵌在提問的位置）。
- 代理怎麼讀： Figma 自己的代理可以在 Specs 裡讀寫留言、平行回覆多則留言、依文件內容產生圖片或程式碼圖層；外部的程式碼代理（官方舉 Codex）透過 Figma 的 MCP 伺服器，可以把 Specs 當 Markdown 檔讀取，連同所有嵌入的參照，一個連結就拿到完整脈絡。MCP 這次也新增了超過 20 個整合工具。
- 可用性： 官方寫 10 月 15 日起公開測試（open beta），分批開放給付費方案，網頁、桌面、行動版都有。
設計系統團隊最直接的用法，是官方例子裡 Intuit 的做法：一份格式固定的 Specs 文件記錄圖示的檔名、分類、搜尋標籤與描述，Intuit 的 Mark Harvey 說這讓設計檔「對非設計師更容易讀」。把這個思路延伸到規範本身，一份好的設計規則文件有四個欄位：規則（一句可檢查的話）、理由、正確範例、錯誤範例，加上嵌入的元件連結。例如「Modular face 小工具主資訊不超過 4 個全形字」可以附一張通過的框架與一張失敗的框架。這是我的建議，Figma 沒有規定格式。
要保持冷靜的是效果。TechCrunch 報導指出 Figma 的說法是讓代理「更能遵守」品牌規則，目標是輸出更可預期，而不是保證遵守。官方文章沒有給「代理遵守率」之類的數字；程式碼圖層文章引用客戶 Merkle 的說法（迭代與功能開發快 30%、互動規格文件少 50%），那是廠商引用的客戶自述，我不當作已驗證的效益。程式碼圖層同日進入公開測試，付費方案在 11 月 4 日前建立與編輯免費，之後會消耗 AI 點數，這影響團隊是否在規劃期把它當日常工具，之後再看實際耗點。
六、兩條線的共通啟示
HIG 用「哪個家族出現在哪、用什麼渲染模式」兩張表，把 HomeView 的規則交給設計師去推算；Specs 讓團隊把自己的規則寫成機器能讀的文件。共通的設計實務有三點。第一，規則要寫成可檢查的句子，「字要夠大」不能被驗證，「2 公尺處一格一行不超過 4 字」可以。第二，規則要標示它的前提，像上面的 2 × 2 與 0.403 度，前提一變，結論跟著變，寫進文件的是前提加數字，不只是結論。第三，規範的讀者現在包含代理，所以規範要有範例與反例，代理和新進設計師一樣，看一個失敗案例比看十句形容詞有用。
🧠 記
- HIG： Widgets 頁變更紀錄 2026-10-13 加入 HomeView；HomeView 小工具為小型系統家族；位置為 Modular face（最多四個、每戶一個、可來自不同成員的 iPhone）與 Home Screen（每位成員自己一組）；Modular face 背景移除並放大；Night Mode 為 vibrant，低光為單色紅。
- 沒有的： 沒有獨立 HomeView 頁；所有 pt 尺寸表都沒有 HomeView；歌詞規則沒有 HomeView 例外。
- 一格能放幾字（2 × 2、無邊距、假設）： 544 px 邊長、62.8 mm；0.403 度時 1 公尺 8 字、2 公尺 4 字、3 公尺 2 字；0.3 度時 11、5、3 字（寬度 12.0、6.0、4.0 em 但略低於整數）。
- 實作：
containerBackground(for: .widget)讓背景可被移除；containerBackgroundRemovable(false)可退出；狀態不要只靠顏色；Modular face 當公開看板。 - Figma Specs： 畫布上的 Markdown 容器；可嵌框架、FigJam、程式碼圖層、Code Connect；GitHub 與 Hex 連接器；Figma 代理與外部代理（MCP）都能讀；10 月 15 日公開測試、付費方案；程式碼圖層同日公開測試，付費方案 11 月 4 日前免費、之後耗 AI 點數。
邊界： HIG 的引用來自我下載的 Apple HIG 資料檔（JSON）的文字抽取，沒有看渲染後的頁面圖；我只抽查了十餘頁，所以「只有兩頁有 HomeView」是抽查結果，不是全站掃描；2 × 2 排列、無邊距、視角基準 0.403 度與 0.3 度、iPhone 小型小工具 460 ppi 與 12 pt 字級都是假設或憑印象；Specs 的內容來自 Figma 官方部落格頁面經網頁抽取摘要，D 鍵快捷鍵、付費方案範圍我沒有在 Figma 裡驗證；Merkle 的數字是廠商引用的客戶自述；TechCrunch 與官方文章日期差一天（活動 10 月 14 日、文章 10 月 15 日），我沒有逐項釐清。HomeView 是否有專屬的 disfavored 位置、Modular face 實際排列與邊距、歌詞規則是否放寬，都查不到。
✍️ 實踐
用 20 分鐘，為你的小工具或任何「小格子內容」算一次字量預算，並寫成一則可檢查的規則。
- 決定三個數字：格子像素邊長、螢幕 ppi、設計觀看距離（公尺）。HomeView 的假設值是 544 px、220 ppi、2 公尺。
- 貼進下面這段程式，輸出一行能放幾個全形字。
function cellCapacity(cellPx, ppi, distM, angleDeg) {
const pitchMm = 25.4 / ppi;
const emMm = distM * 1000 * Math.tan(angleDeg * Math.PI / 180);
const emPx = emMm / pitchMm;
const emPerCell = cellPx / emPx;
return {
emPx: +emPx.toFixed(1),
cellMm: +(cellPx * pitchMm).toFixed(1),
emPerCell: +emPerCell.toFixed(2),
charsPerLine: Math.floor(emPerCell),
};
}
console.log(cellCapacity(544, 220, 2, 0.403)); // 預期 emPx=121.8 cellMm=62.8 emPerCell=4.46 charsPerLine=4
console.log(cellCapacity(544, 220, 1, 0.3)); // 預期 emPx=45.4 emPerCell=12 charsPerLine=11- 注意第二行：emPerCell 印出來是 12，但實際值是 11.996，無條件捨去得 11，不是 12。邊界值差千分之幾就少一字，所以規則要把「取整方式」與「內距」一起寫；實務上再扣內距，取更保守的字數。
- 把結果寫成一份 Specs 或任何 Markdown 規則：規則一句（例：2 公尺處一格一行不超過 4 個全形字）、前提（544 px、220 ppi、0.403 度）、通過範例（「23°」）、失敗範例（「下一場會議 14:30」）。
- 在 Figma 裡把這份 Markdown 拖上畫布，把通過與失敗兩個框架嵌進去；若有 MCP 可用的代理，請它依規則檢查三個現有小工具稿，並記錄它是否正確指出失敗案例。
🔗 延伸學習
- Widgets（Apple HIG） — 2026-10-13 加入 HomeView 的一節；渲染模式表與家族出現位置表都在這頁。頁面是前端渲染，我是讀它背後的資料檔。
- Bring widgets to new places（WWDC23 session 10027） — 背景可移除、
containerBackground與退出機制的原始講解。 - Introducing Specs: Markdown as a Medium（Figma） — Specs 的建立方式、連接器、MCP 與官方例子。
- Design together with code layers on the canvas（Figma） — 程式碼圖層的建立方式、公開測試與 AI 點數計費說明。
💬 問 AI
我想把「小格子內容的字量預算」與「給 AI 代理讀的設計規範」做成可驗算、可檢查的設計決策。請嚴格分成「文件明說」「你查證到的」「你的推論」三區回答,不確定就直說,不要編造連結、數字、版本號或引文。
背景(請當待查證主張):
1. Apple HIG Widgets 頁(變更紀錄 2026-10-13)加入 Apple HomeView:小工具來自小型系統家族;位置為 Modular face(最多四個、每戶一個、可來自不同成員的 iPhone)與 Home Screen(每位成員自己一組);Modular face 背景移除並放大,Night Mode 為 vibrant、低光為單色紅。
2. HomeView 規格:1088 x 1088 px、220 ppi、可視邊長 125.6 mm。假設 Modular face 為 2 x 2 無邊距,則一格 544 px、62.8 mm。
3. 視角基準(我的假設)0.403 度與 0.3 度:2 公尺處 em 為 121.8 px 或 90.7 px,一格寬約 4.46 或 6.0 em(一行全形字數取整後為 4 或 5)。
4. Figma Specs(2026-10-15 公開測試、付費方案):畫布上的 Markdown 容器,可嵌框架、FigJam、程式碼圖層與 Code Connect,Figma 代理與外部代理透過 MCP 讀取。
請做:
A. 逐點驗證 1 到 4,標示「成立/部分成立/查不到」並附一手連結;特別確認 HomeView 是否公布 pt 尺寸、Modular face 的實際排列、HomeView 是否有專屬的 disfavored 位置。
B. 查至少兩份關於遠距離閱讀的視角與字高的標準或實證研究,比較 0.403 度與 0.3 度,並說明我的「一行字數上限」算法有哪些漏洞(內距、字寬、行距)。
C. 針對 Modular face 小工具,建議三條可檢查的設計規則(含前提、通過與失敗範例),其中一條要處理「單色紅下的狀態辨識」。
D. 評估「把設計系統規範寫成 Markdown 給代理讀」的證據:Figma 或其他來源是否公布過代理遵守率或錯誤率?沒有就直說。
不要評論公司財務或產品好壞,只談尺寸、人因證據與實作。