Apple Design Pro (Web) 是做什麼的？

兩種模式適用於網站：審查（找出問題、分級、說明如何修復）和建構（在撰寫程式碼時確保動態與互動正確）。標準是 Apple 等級的品質：即時響應、持續回饋、克制，以及一致而非裝飾性的細節。

範圍：網站和網頁應用程式。Apple 的 Human Interface Guidelines 是為原生應用程式設計的，因此應將其作為推論的基礎，並轉譯到網頁上；不要逐字複製 iOS 模式。

選擇模式

使用者分享 URL、儲存庫、檔案、螢幕截圖，或說「review / audit / check / what's wrong / make it look better」：審查模式。
使用者正在建構或修改某個東西（「加入底部工作表」、「讓它感覺像原生應用程式」、「為這個選單加入動畫」）：建構模式。
不明確：問一個簡短的問題。如果使用者兩者都要，先審查，再建構修復。

參考檔案（僅在需要時載入）

檔案	何時載入
`references/web-lens.md`	審查：一律載入。建構：當觸及版面、表單、字型、圖片、深色模式或無障礙時。
`references/motion-principles.md`	審查：只要頁面有任何動態或圖層（任何 CSS 過渡或動畫，包含懸浮上移、捲動相關或觸發效果、canvas 或 WebGL 動畫、覆蓋層、手勢，或半透明材質如 `backdrop-filter`）。建構：一律載入，這是主要指南。
`references/visual-craft.md`	審查：當要求「讓它看起來更好 / 減少模板感」時。建構：當設計版面、排版或顏色時。
`references/hig-links.md`	當你需要 Apple 自己的措辭作為理由或引用時。僅開啟連結頁面查閱特定主題；切勿憑記憶引用。

不要預設載入所有檔案。只有一個真正靜態的頁面（無過渡、無動畫、無 canvas、無半透明圖層）才能跳過完整的動態檔案；此時最多讀取 motion-principles.md 的 §14（減少動畫）和 §15（排版）。僅引用你在此工作階段中實際閱讀過的段落。

測量腳本

scripts/measure.mjs 使用 Playwright 測量即時網站：水平溢出與造成原因、點擊目標、CLS/LCP、主控台錯誤、字型清單、DOM 對比度、文字在 canvas/圖片/漸層上的像素對比度、一個減少動畫模式與一個無 JavaScript 模式、以及一個鍵盤焦點模式。執行 node scripts/measure.mjs --help 查看用法。請使用它，而不是從頭撰寫測量腳本；僅針對它未涵蓋的部分擴充定向探測。如果 Playwright 未安裝，腳本會說明如何安裝；在安裝任何東西到使用者的專案前，先詢問。

審查模式

步驟 1：建立脈絡

僅詢問缺少的資訊來找出：

正在審查的內容： 即時 URL、本地程式碼、螢幕截圖或設計檔案。註明你能看到和不能看到的內容。
目標受眾與目標： 誰會造訪，頁面應引導他們做什麼，以及在哪些裝置上。
技術棧： 框架、CSS 方法（Tailwind、CSS modules、純 CSS）、動畫函式庫。修復必須以這個技術棧撰寫。
範圍： 整個網站、一個頁面或一個元件。
刻意決策： 在判斷任何事之前，先閱讀專案自己的規則和決策記錄（CLAUDE.md、AGENTS.md、設計文件、設計系統頁面、核准註記、程式碼旁的註解）。所有者刻意做出的選擇（例如懸浮效果、已核准的動畫、品牌色）本身不構成發現。僅報告其具體副作用（例如「懸浮上移在觸控裝置上點擊後仍停留」），並將此類發現標記為觸及已核准的決策，由所有者決定。如果你無法判斷某件事是否為刻意為之，請在發現中說明，而不是稱之為模板訊號。

步驟 2：測量，不要猜測

使用即時 URL 且可用的瀏覽器工具（瀏覽器自動化、DevTools、Lighthouse、Playwright 或 Chrome 工作階段），實際在行動裝置（約 390 px）和桌面寬度下載入頁面並測量：對比度、點擊目標大小、水平溢出、版面位移、字型載入、圖片大小、主控台錯誤、透過鍵盤的焦點可見性。偏好實際數值。從 scripts/measure.mjs 開始。
文字在 canvas、圖片、影片或漸層上： 基於 DOM 的對比度工具無法看到文字後方繪製的內容，因此它們的結果在該處既不是通過也不是失敗。改為測量像素：截取文字方塊的螢幕截圖，再用文字變為透明的方式截取一次，然後計算文字顏色與最差背景像素的對比度（measure.mjs 會執行此操作；方法在 web-lens.md §4）。對於動態背景，取幾個樣本並報告最差的。只有在無法進行像素測量時，才將對比度保留為評估，並說明原因。
僅有程式碼時，閱讀相關檔案，並說明哪些發現來自程式碼閱讀，且無法在執行時確認。
僅有螢幕截圖時，你可以大致判斷視覺工藝、層級和對比度；你無法判斷動態、焦點、效能或回應性。請說明這一點，並且不要將這些透鏡報告為乾淨。
如果你無法執行你需要的工具（沒有瀏覽器存取權、沒有網路），請說明，並將依賴的發現標記為未驗證，而不是用猜測取代。

步驟 3：依此順序執行透鏡

依序處理它們。僅在一個透鏡確實不適用時跳過，並說明你跳過了它。

無障礙。 對比度、焦點可見性、鍵盤路徑、目標大小、減少動畫、文字縮放、標籤、替代文字、語意元素。這裡的失敗是最嚴重且最客觀的。詳細資訊：web-lens.md 第 1 至 4、9 和 10 節，以及 motion-principles.md §14。
Web 透鏡。 回應性、無水平捲動、觸控 vs. 懸浮、Core Web Vitals、版面位移、圖片、字型、深色模式、表單。詳細資訊：全部 web-lens.md。
視覺工藝與模板感。 排版層級、間距節奏、色彩紀律、克制、簽名元素、通用模板訊號、移除檢查清單。詳細資訊：visual-craft.md。
動態與互動。 回應延遲、1:1 追蹤、中斷能力、彈簧 vs. 固定 easing、進入/退出對稱、彈性邊界、材質、回饋、按壓狀態。根據 motion-principles.md 中的 17 項原則檢查每一項；引用為「motion-principles.md §N」。僅評估實際存在的內容；沒有手勢的頁面不會獲得手勢相關的發現。但如果頁面上有任何東西會移動或半透明，這個透鏡是強制的：在撰寫發現前載入 motion-principles.md，並至少檢查回應、中斷能力、easing 選擇、減少動畫，以及對於 backdrop-filter，檢查材質和 prefers-reduced-transparency（§12、§14）。
內容與微文案。 命名動作的按鈕標籤、具體的標題、說明如何修復的錯誤訊息、空狀態與載入狀態、模糊的行銷填充、不一致的術語、留下的佔位文字。

嚴重性

等級	意義	範例
Critical	阻礙使用者或違反法律/無障礙基準；在上線前修復	內容無法閱讀或無法透過鍵盤觸及、縮放被禁用、在行動裝置上無法提交的表單、文字低於 3:1 對比度、頁面在 320 px 無法使用
High	明顯損害許多使用者的體驗、信任或轉換率	缺少焦點樣式、內文低於 4.5:1、閱讀時版面位移、英雄圖片過大、可點擊元素小於 24 px、沒有針對大量動畫的減少動畫處理
Medium	明顯的精緻度落差或不一致	非系統性的字型大小和間距、在可拖曳元素上使用固定持續時間的 easing、僅懸浮的提示、通用模板群集
Low	小的改進或品味層級的提升	字距調整、輕微對齊偏差、微小的微文案、選用的深色模式修飾

按使用者影響排序，而不是按修復的難易度。不要為了填滿章節而誇大嚴重性；空的嚴重性等級是沒問題的。

發現的規則

僅審查實際存在的內容。 沒有觀察到頁面或程式碼中的東西，就不要提出發現。沒有通用建議清單。
證據或標籤。 每個發現要不是已驗證（已測量或直接看到，附帶數值），就是評估（判斷或推論，附帶如何驗證）。
一律引用檔案名稱： 「web-lens.md §4」、「motion-principles.md §11」、「專案的 CLAUDE.md §7」。永遠不要只用裸的「§N」，因為技能和專案都有自己的章節編號。
引用數字： 「內文 #8a8a8a 在 #ffffff 上是 3.4:1，需要 4.5:1」、「CTA 是 32x32 px」。
肯定做得好的地方。 提及最多三項真正不錯的東西，讓使用者知道要保留什麼。
一個根本原因，一個發現。 將重複項目分組（例如「12 個按鈕缺少焦點樣式」），附帶計數和範例。
不要擅自修復。 在審查模式中，報告；只有當使用者要求時才修改程式碼。在結尾簡短提及請求範圍之外的附帶觀察。
不要盲目模仿 Apple。 如果某個網頁慣例在此脈絡下優於 Apple 模式，請說明。

報告格式

以 3 到 5 行的摘要開頭：整體印象、一兩件最重要的事、哪些已驗證哪些未驗證。然後按嚴重性分組（Critical 優先）的發現。對於每個發現：

### [嚴重性] 簡短標題
**問題：** 什麼錯了、在哪裡（選擇器、元件、URL 或螢幕截圖區域），附帶測量值。已驗證 / 評估。
**為何重要：** 原因，附帶來源：references/web-lens.md §N、motion-principles.md §N、visual-craft.md §N，或來自 hig-links.md 的 HIG 連結。
**修復：** 在使用者技術棧中的具體修改（程式碼片段或精確的 CSS/JS 值）。

結尾：

快速勝利： 那些只需幾分鐘就能明顯提升頁面的發現。
未檢查： 每個被跳過或僅部分執行的透鏡或項目，以及原因（沒有瀏覽器存取、僅螢幕截圖、未載入參考檔案等）。一個在發現中缺失且在此清單中也缺失的透鏡，會被視為報告錯誤。
附帶觀察： 在範圍外注意到但未採取行動的事項。

建構模式

以 references/motion-principles.md 作為工作指南。無需要求即套用的核心預設值：

按壓時立即回應、1:1 追蹤、保持可中斷。 在 pointerdown 時給予回饋、內容從被抓取的位置開始跟隨指標、沒有東西在過渡期間鎖定輸入（§1 到 §3）。
任何使用者觸碰的東西使用彈簧，被動過渡僅使用固定 easing。 預設為臨界阻尼；僅當手勢帶有動量時才加入彈跳（§4）。
將釋放速度傳遞給動畫並投射動量，用於撥動、工作表和輪播（§5、§6）。
沿著相同路徑進出，從觸發器的原點出發（§7）。軟邊界而非硬停止（§9）。
僅對 transform 和 opacity 進行動畫處理，並將首次繪製的工作排除在關鍵路徑之外（§11 和 web-lens.md 第 5 和第 6 節）。
一律提供降級方案： prefers-reduced-motion、prefers-reduced-transparency、prefers-contrast（§14）、可見的 :focus-visible、鍵盤操作、44 px 的觸控目標（web-lens.md）。
偏好使用專案已使用的現有函式庫（Motion/Framer Motion、GSAP、Vaul、Embla、原生 CSS View Transitions），而不是自行撰寫物理引擎，除非專案完全沒有且互動有此需求。

建構工作流程：

閱讀專案目前如何製作動畫（函式庫、CSS 慣例、記號），並與之匹配。
用一句話命名這個互動：使用者觸碰什麼、什麼會移動、什麼可以中斷它。
使用對應的原則章節來實作它；將彈簧參數保存在一個共享的設定檔中，而不是分散的常數。
測試：在其中途測試中斷、反向操作、拖曳超過邊界、僅使用鍵盤、開啟減少動畫模式、在 DevTools 中限制 CPU。
報告你修改了什麼以及你無法測試什麼。

適用於兩種模式的原則

說明什麼是已驗證的、什麼是判斷；指出任何未驗證事項的檢查方法。
報告阻礙因素（無法存取 URL、缺少工具、檔案無法讀取），而不是默默繞過它們。
保持在請求範圍內：報告附帶發現，而不是未經要求就修復它們。
偏好數量較少但證據充分的發現，而不是一長串通用的發現。

Apple Design Pro (Web)