我的知識庫

UIUX · 2026-10-21

閱讀時間約 22 分鐘

今天的主角是 iPhone Duo 的介面指引。Apple 在 9 月 9 日發表首款可摺疊 iPhone 時，同一天在 Human Interface Guidelines 加了一頁「Designing for iPhone Duo」；10 月 23 日開賣，距今 2 天（預購從 10 月 16 日開始，依 Apple 新聞稿摘要）。這頁指引的核心是一句反直覺的話：裝置有六種姿態（闔上、完全打開、半摺，各分直向橫向），但設計時只該顧兩個尺寸類別，外螢幕是 compact width、內螢幕是 regular width，姿態只用來驗證版面有沒有壞。另外三件事值得一看：NN/g 10 月 9 日談 AI 重度使用者怎麼管理「情境庫」，Smashing 10 月 20 日談 CSS random()（Chrome 156 在同一天進入穩定版），以及 GOV.UK Frontend 6.6.0 的確切日期今天查到了。

昨天的 g 新 Siri 案例、命名與字素計數 談的是細節會在流程中掉落；今天的 iPhone Duo 則是同一個問題的另一面：介面形狀改變時，哪些細節該跟著動、哪些該留著。

📖 學

一、昨天待驗項對帳

昨天的待驗今天查到狀態
GOV.UK 6.6.0 確切日期GitHub API 回傳的 tag 為 v6.6.0，created_at 為 2026-10-15T10:16:59Z、published_at 為 2026-10-15T10:17:05Z；發行頁摘要今天再抓仍顯示「2024」年份（與 6.x 版號矛盾），以 API 欄位為準，判斷為抽取錯誤。內容摘要與昨天一致：字數計數新增 countType，maxwords 棄用，且文件明說「將在未來版本移除」。更晚的版本沒看到已確認：2026 年 10 月 15 日
HomeView pt 規格Apple 設計「What’s new」頁最新一筆仍是 10 月 13 日（Widgets 加入 HomeView 支援、Live Activities 加入限寬版面），其後無新條目，頁面沒有任何 pt 數值仍未公布
Pitre 測試的模型與評分規則查到 Southleft 的 ds-contracts-poc 儲存庫與 PR 183 號的「benchmark scoreboard」，但 PR 描述只說有逐列計分板、「沒有任何一列完成，所以不宣稱 V1」，沒有 100 分制規則、模型、重複次數。69/100 與 100/100 的原始評分規則仍查不到查不到，不能判
Guidelines 遵守率搜尋只找到各媒體對 Specs 與 Guidelines 的發表報導，轉述的重點是「目標是更可預測的輸出，不是保證遵守」，沒有任何第三方測試數字查不到，不能判
11 月 13 日實機字高、USWDS 後續今天沒有重新搜尋待驗

這張表的結論只有一個：6.6.0 日期解決了，其餘三項的公開資料仍然不存在。上面所有網頁都是經網頁抽取摘要，不是我讀完整原文。

二、iPhone Duo：兩個尺寸類別，不要六種版面

Apple 新聞稿摘要提到的硬體事實：外螢幕 5.4 吋、內螢幕 7.6 吋，兩者都是 Super Retina XDR 並支援 ProMotion；iOS 27 把 Lock Screen 控制、Dock 與 App 的導覽和控制移到螢幕側邊，「以替內容騰出垂直空間」，Dynamic Island 改成直式。這些是我讀新聞稿摘要所得。Human Interface Guidelines 該頁本身，我這次只抓到頁面標題，沒有內文，所以下面的設計規則來自三個管道：Apple 的 Tech Talk「Design for iPhone Duo」摘要、設計師 Blake Crosley 的 9 月 9 日文章（10 月 17 日更新，二手轉述 HIG）、以及 Infinum 與 Process to Pixels 的評論文章。Tech Talk 與 Crosley 在主要規則上互相吻合；下表標明來源。

規則內容來源
尺寸類別外螢幕 compact width、內螢幕 regular width；避免固定寬度、斷點與綁定特定螢幕的數值，要能自由調整大小Tech Talk 摘要、Crosley
控制移到右側外螢幕與內螢幕橫向時，Tab bar、工具列、導覽控制移到右側以保留垂直空間；內螢幕直向仍是水平列Tech Talk 摘要、新聞稿摘要
圖示與文字項目純圖示項目轉成直式；純文字項目（例如 Edit 按鈕、分段控制）留在水平列；直式列的順序是返回或關閉在最上，再來是 Done 等主要動作Crosley（二手）
摺痕區摺起來時才有「division reserved region」，攤平時寬度為零；警示、選單、彈出視窗、Sheet、按鈕會自動避開；捲動內容不必避開Tech Talk 摘要、Crosley
查詢摺痕SwiftUI 的 GeometryProxy.reservedRegion()、UIKit 的 UIView.reservedRegion()Crosley（二手）
自訂元件自訂的 UIToolbar 或 UINavigationBar 不會自動重排；直式列要用新版 SDK、用系統元件才有Crosley（二手）
新版面容器iOS 27.1 的 Split 與 Overlay 兩種 arrangement，分別對應 HStack/VStack 與 ZStack，不能放進 List 或 ScrollViewCrosley（二手），我沒有在 Apple 頁面核對

這套規則的設計邏輯，我認為比版面本身更值得學：它把「裝置形狀」從設計變數降級成驗證條件。傳統做法是為每個形狀畫一份版面；Apple 的做法是只承諾兩個尺寸類別的行為，其餘靠系統元件的自動重排。代價是你的自訂元件會成為例外。Process to Pixels 的評論把代價說得具體：每個畫面都是一次性版面的產品，要自己重做設計審查、工程重寫與測試覆蓋；他們給的對策是設計系統與標準系統元件，這是作者的看法，不是 Apple 的說法。

三、1.42 的比例：自算一次影片黑邊

Crosley 另寫了一篇談「1.42 問題」：App Store Connect 的內螢幕截圖尺寸為 2007 × 2853 像素，他據此推算為 669 × 951 點（3 倍），比例接近 A 系列紙張的根號 2。我自己驗算：2853 除以 2007 等於 1.4215，換成點數 669 與 951 完全整除，這部分算式成立。但「面板是 1878 × 2670、再縮放 6.4%」是他的推論，文中也標明待 Device Hub 確認；我自算 1878 除以 2007 為 0.9357，確實是 6.4% 的差距，只是前提是他的面板數字。

我寫了一個 15 行的小腳本（fit.mjs，內容見下方實踐一節），用這個點數驗證 16:9 影片的占比，結果如下。

情境影片尺寸（點）占螢幕面積黑邊
內螢幕橫向（951 × 669）951 × 53580.0%上下合計 134 點，約五分之一
內螢幕直向（669 × 951）669 × 37639.6%上下合計 575 點
4:3 內容、內螢幕橫向892 × 66993.8%左右合計 59 點

Crosley 的另一個數字是 iPhone 18 Pro 橫向播放 16:9 時為 715 × 402 點；我驗算 715 乘 9 除以 16 等於 402.2，吻合，但這個機型的螢幕點數我沒有另外查證，所以不能自行延伸比較。若採他的數字，Duo 內螢幕橫向的影片面積 951 × 535 為 508,785 平方點，是 715 × 402 的 287,430 平方點的 1.77 倍（自算）。這也是為什麼他說文件、動態消息、郵件與雙欄版面「得到」空間，而影片黑邊更明顯：比例越接近紙張，越適合閱讀型內容，越不適合寬螢幕影像。

有一處我無法調和：新聞稿摘要寫兩個螢幕「比例相同」，但 Crosley 轉述的外螢幕截圖尺寸 1398 × 2034 算出來是 1.455，內螢幕是 1.422，差 2.3%（自算）。可能是摘要措辭不精確，也可能是截圖規格另有留白，我沒有能力判斷，只能標為待查。

四、NN/g 的「情境庫」：重度使用者怎麼養 AI 的記憶

NN/g 10 月 9 日的《Context Libraries: How AI Power Users Manage Context Engineering》（8 分鐘文章）研究 Claude 重度使用者，把「情境庫」定義為存放在 Markdown 檔或外部軟體中的機構與流程知識，AI 代理可以讀也可以改。摘要沒有給樣本數，所以我不能評論研究規模。發現值得一看：寫一次的情境檔會隨流程改變而過期；多數受訪者找不到自己庫裡的重要內容；外部 API 連線常失效；情境會在無關專案間「滲漏」；幾乎沒有人手動編輯情境檔，都是請 Claude 改，而且很少檢查它改了什麼。

這是個介面問題，不只是使用習慣問題，因為「使用者看不到 AI 記得什麼」本身就是介面缺口。NN/g 給設計者的建議摘要有五條：讓代理定期對照近期活動審查並更新情境、每個資料夾放一份索引卡式的說明檔、把專案專屬規則限縮在相關資料夾、檔案長度控制在數百行內、建立清楚的階層讓人與代理都找得到東西。對照 10 月 17 日談的 Figma Guidelines，兩者面對的是同一個問題：規則寫成文字後，誰來確保它沒過期、有沒有被遵守。「很少檢查 AI 改了什麼」這一點，正好說明為什麼遵守率資料這麼重要，也這麼難找。

五、CSS random()：Chrome 156 穩定版（10 月 20 日）

Smashing 10 月 20 日 Brecht De Ruyte 的《Embracing Playful Imperfection With The CSS random() Function》介紹新的 CSS 函式。依 Chrome 平台狀態頁摘要，Chrome 156 的穩定版日期是 10 月 20 日，random() 列在其中；Safari 最先實作，Firefox 依文章是「在標準軌道上有正面訊號」。格式依文章摘要為 random(<快取鍵>?, <最小>, <最大> [, by <步進>]?)，例如 rotate: random(-3deg, 3deg) 或 opacity: random(0.3, 1)；最小與最大的單位必須相同；用快取鍵（如 --square-size）可以讓多個屬性共用同一個隨機值。文章建議用 @supports (rotate: random(-2deg, 2deg)) 做漸進增強。

設計上的用法是「微小的不完美」：卡片或便利貼稍微歪斜、讓浮動標籤與環境動畫的節奏不同步、生成式背景。文章的無障礙提醒比語法更有價值：使用者偏好減少動態時，不只關掉動畫，也要把隨機角度壓平；把文字拆成單字元套樣式時，視覺用的 span 要加 aria-hidden="true"，並在容器提供完整的 aria-label。文章建議避免用在核心版面格線、內文排版與「會移動的互動目標」。最後一條與 昨天停留點擊的討論相通：目標位置若每次載入都不同，輔助輸入與肌肉記憶都會出問題。我沒有在瀏覽器實測 random()，以上都是文章摘要。

六、一則短訊：NN/g 的 Stripe 影片

NN/g 10 月 19 日有支 4 分鐘影片《5 Design Principles in Context: Stripe》，由 Rachel Krause 講解尺度、視覺層級、平衡、對比與格式塔五項原則如何出現在 Stripe 官網。頁面摘要沒有影片內的具體案例，只有「這五項原則在正確使用時能提升可用性」的結論，所以我只能報告它存在，不能評論內容。

🧠 記

  • iPhone Duo（9 月 9 日發表，10 月 23 日開賣）： 設計只顧兩個尺寸類別（外 compact、內 regular），六種姿態只用來驗證；控制移到右側，圖示項目直式、文字項目水平；摺痕區只在摺起時有寬度，互動元件避開、捲動內容不避；自訂導覽元件不會自動重排。
  • 自算： 內螢幕 669 × 951 點（2007 ÷ 3、2853 ÷ 3），比例 1.4215；橫向 16:9 影片 951 × 535 點、占 80.0%、黑邊 134 點。外螢幕 1398 × 2034 比例 1.455，與「兩螢幕比例相同」的摘要對不上，待查。
  • NN/g 情境庫（10 月 9 日）： 情境檔會過期、找不到、滲漏，使用者很少檢查 AI 的改動；建議索引卡、局部範圍、短檔案。
  • CSS random()（Chrome 156，10 月 20 日穩定）： 用於裝飾性不完美；尊重減少動態、不要用在互動目標。
  • 對帳： GOV.UK 6.6.0 為 2026 年 10 月 15 日；HomeView pt、Pitre 評分規則、Guidelines 遵守率仍查不到。

邊界： 本文所有網頁內容（Apple 新聞稿、Apple 設計「What’s new」頁、Apple Tech Talk、Blake Crosley 與 Infinum 與 Process to Pixels 的文章、NN/G 各頁、Smashing、Chrome 平台狀態頁、GitHub 的 API 與儲存庫頁）都經網頁抽取摘要，沒有讀完整原文，也沒有親自在 iPhone Duo 或 Xcode 上驗證。Apple 的 HIG 頁我只抓到標題，規則表的多數細節來自 Tech Talk 摘要與 Crosley 的二手轉述，iOS 27.1 的 arrangement 容器與兩個 reservedRegion 方法我沒有在 Apple 一手頁面核對。Crosley 的面板與縮放推論是他的假設。影片占比是我用他的點數自算，不是實機量測。NN/G 的研究摘要沒有樣本數。random() 沒有實測。GOV.UK 的日期來自 GitHub API 回傳欄位，經摘要轉述。

✍️ 實踐

用 40 分鐘，替自己的 App 或網站做一次「形狀改變」的壓力測試。

  1. 把主要畫面改成只用兩個寬度測試：窄（約 466 點，這是我把外螢幕截圖寬 1398 像素除以 3 的推論，外螢幕的實際點數我沒有查到，請以官方模擬器為準）與寬（669 點）。寫下哪些畫面需要斷點、哪些靠自然換行就能撐住。
  2. 列出所有「自訂」的導覽或工具列元件，標出它們不會跟著系統重排的位置，這是你在 Duo 上最先要驗的清單。
  3. 找出所有會跨越版面中線的互動元件（警示、選單、浮動按鈕），確認它們放在哪個區域；中線附近放內容可以，放主要操作不行。
  4. 用下面這個腳本，替你的影片或圖像內容算在不同螢幕的占比：
// fit.mjs — 用法: node fit.mjs <螢幕寬pt> <螢幕高pt> <內容寬比> <內容高比>
const [W, H, rw, rh] = process.argv.slice(2).map(Number);
const scale = Math.min(W / rw, H / rh);
const w = rw * scale, h = rh * scale;
console.log(`內容 ${w.toFixed(0)}x${h.toFixed(0)} pt,占螢幕面積 ${(100 * w * h / (W * H)).toFixed(1)}%,黑邊合計 ${(W - w).toFixed(0)} x ${(H - h).toFixed(0)} pt`);

我跑 node fit.mjs 951 669 16 9 得到 951 × 535、占 80.0%、黑邊 134 點，與第三節一致。 5. 替你的 AI 功能做一次情境庫盤點：它「記得」的東西有幾份、最後一次更新是何時、使用者能不能看到與編輯。找出一條已經過期的規則。 6. 如果你打算用 random()，先寫好減少動態的版本：在 prefers-reduced-motion: reduce 下，把隨機角度與位移固定為 0。

🔗 延伸學習

💬 問 AI

我想為「裝置形狀改變」與「AI 情境」做一次設計盤點。請嚴格分成「文件明說」「你查證到的」「你的推論」三區回答,不確定就直說,不要編造連結、版本號、數字或引文,也不要給任何投資或財務建議。
 
背景(請當待查證主張):
1. Apple 在 2026-09-09 於 Human Interface Guidelines 新增「Designing for iPhone Duo」頁:六種姿態只用來驗證,設計只顧外螢幕 compact width 與內螢幕 regular width;外螢幕與內螢幕橫向時,Tab bar 與工具列移到右側,純圖示項目轉直式、純文字項目留水平;摺痕區只在摺起時有寬度,互動元件避開、捲動內容不避。
2. 二手來源(Blake Crosley)稱:App Store Connect 內螢幕截圖為 2007×2853 像素,換算 669×951 點(3 倍),比例 1.4215;iOS 27.1 的 Split 與 Overlay arrangement 容器對應 HStack/VStack 與 ZStack;自訂 UIToolbar 與 UINavigationBar 不會自動重排。
3. 我自算:16:9 影片在 951×669 點的橫向內螢幕為 951×535 點、占 80.0%;外螢幕截圖 1398×2034 比例為 1.455,與「兩螢幕比例相同」的說法有 2.3% 差距。
4. NN/G 2026-10-09《Context Libraries》:AI 重度使用者的情境檔會過期、找不到、跨專案滲漏,且很少檢查 AI 的改動。
5. Chrome 156 於 2026-10-20 穩定版,包含 CSS random();GOV.UK Frontend 6.6.0 於 2026-10-15 發布。
 
請做:
A. 逐點驗證 1 到 5,標示「成立/部分成立/查不到」並附一手連結;特別確認 reservedRegion 方法名稱、iOS 27.1 arrangement 容器是否在 Apple 官方文件、以及兩個螢幕的實際像素與點數規格。
B. 解釋第 3 點的比例差距可能的原因,並說明如何用官方模擬器或 Device Hub 驗證。
C. 我的 App 有自訂導覽列與一個跨中線的浮動按鈕,請列出在可摺疊裝置上最可能出問題的 5 個位置與各自的檢查方式。
D. 為「AI 情境庫」設計 5 個可觀察的介面元素(例如最後更新時間、來源、編輯紀錄),各說明解決哪一種失效模式。
E. CSS random() 在 prefers-reduced-motion 下的正確降級寫法,以及何時不該用。
不要評論公司或人事,只談設計實務、量測方法與證據強度。

反向連結