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

两种模式用于网站：审查（找出问题、排序、说明修复方法）和构建（在编写代码时确保动效和交互的正确性）。标准是苹果级别的质量：即时响应、持续反馈、克制，以及一致而非装饰性的细节。

范围：网站和 Web 应用。Apple 的人机界面指南是为原生应用编写的，因此要利用其推理逻辑并将其翻译到 Web；不要逐字照搬 iOS 模式。

选择模式

用户分享了 URL、仓库、文件、截图，或说“审查/审计/检查/有什么问题/让它看起来更好”：审查模式。
用户正在构建或修改某些内容（“添加一个底部面板”、“让它感觉像原生应用”、“给这个菜单添加动画”）：构建模式。
不明确：问一个简短的问题。如果用户两者都要，先审查，然后构建修复。

参考文件（仅加载你需要的）

文件	何时加载
`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 会话），实际在移动端（约 390px）和桌面端宽度加载页面并测量：对比度、点击目标尺寸、水平溢出、布局偏移、字体加载、图片尺寸、控制台错误、通过键盘的焦点可见性。优先使用真实数值。从 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. 悬停、核心 Web 指标、布局偏移、图片、字体、深色模式、表单。详情：web-lens.md 全部内容。
视觉工艺和模板感。 字体层次、间距节奏、颜色纪律、克制、标志性元素、通用模板信号、移除清单。详情：visual-craft.md。
动效和交互。 响应延迟、1:1 跟踪、可中断性、弹簧 vs. 固定缓动、进入/退出对称性、橡皮筋效果、材质、反馈、按压状态。对照 motion-principles.md 中的 17 条原则逐条检查；引用为“motion-principles.md §N”。仅评估存在的内容；没有手势的页面不会得到手势相关的问题。但如果页面有任何移动或半透明效果，此检查是强制性的：在编写问题之前加载 motion-principles.md，并至少检查响应性、可中断性、缓动选择、减少动效以及对于 backdrop-filter（第 12、14 节），还需检查材质和 prefers-reduced-transparency。
内容和微文案。 描述动作的按钮标签、明确的标题、说明修复方法的错误消息、空状态和加载状态、模糊的营销填充语、不一致的术语、遗留的占位文本。

严重性

级别	含义	示例
严重	阻止用户操作，或未通过法律/可访问性基线；发布前必须修复	内容无法通过键盘读取或访问、缩放被禁用、移动端无法提交表单、文本对比度低于 3:1、页面在 320px 宽度下无法使用
高	明显损害许多用户的体验、信任或转化	缺少焦点样式、正文文本对比度低于 4.5:1、阅读时布局偏移、首屏图片过大、可点击元素小于 24px、未对大动效做减少动效处理
中	明显的精致度缺口或不一致性	临时调整的字体大小和间距、对可拖拽元素使用固定持续时间的缓动、仅靠悬停进行交互、通用模板集群
低	小的改进或品味层面的提升	字距调整微调、轻微对齐问题、微文案优化、可选的深色模式润色

按对用户的影响排序，而不是按修复的难易程度。不要为了填充某个部分而提高严重性；某个严重级别没有问题是完全可以的。

问题规则

仅审查实际存在的内容。 没有基于观察到的页面或代码内容之外的问题。没有通用建议列表。
证据或标注。 每个问题要么是已验证（测量或直接看到，并包含数值），要么是评估（判断或推断，并说明如何验证）。
始终引用文件名： “web-lens.md §4”、“motion-principles.md §11”、“项目的 CLAUDE.md §7”。永远不要单独写“§N”，因为技能和项目都有各自编号的章节。
引用具体数值： “正文文本 #8a8a8a on #ffffff 是 3.4:1，需要 4.5:1”、“CTA 是 32x32 px”。
肯定做得好的部分。 最多提到三个真正优秀的地方，让用户知道保留什么。
一个根本原因，一个问题。 对重复项进行分组（“12 个按钮缺少焦点样式”），附上计数和示例。
不要未经请求就修复。 在审查模式下，只报告；仅在用户要求时修改代码。在报告末尾简要提及其他范围内的偶然发现。
不要盲目照搬 Apple。 如果 Web 惯例在这个上下文中优于 Apple 模式，说明这一点。

报告格式

以 3 到 5 行的摘要开头：总体印象、一两个最重要的事情、哪些内容已验证和未验证。然后按严重性分组的问题（严重优先）。每个问题格式如下：

### [严重性] 简短标题
**问题：** 哪里有问题，位置（选择器、组件、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 节）。
用户触摸的内容使用弹簧，仅被动过渡使用固定缓动。 默认临界阻尼；仅当手势带有动量时才添加回弹（第 4 节）。
将手释放速度传递给动画并投射动量，用于轻扫、面板和轮播（第 5、6 节）。
进入和退出沿相同路径，从触发器原点开始（第 7 节）。使用软边界而非硬停止（第 9 节）。
仅动画 transform 和 opacity，并将首次绘制工作排除在关键路径之外（第 11 节和 web-lens.md 第 5、6 节）。
始终提供降级方案： prefers-reduced-motion、prefers-reduced-transparency、prefers-contrast（第 14 节）、可见的 :focus-visible、键盘操作、44px 触摸目标（web-lens.md）。
优先使用项目已有的库（Motion/Framer Motion、GSAP、Vaul、Embla、原生 CSS View Transitions），而不是手动实现物理效果，除非项目没有且交互需要。

构建工作流：

阅读项目当前的动效方式（库、CSS 约定、令牌）并保持一致。
用一句话命名交互：用户触摸什么、什么移动、什么可以中断它。
使用匹配的原则部分实现它；将弹簧参数保存在一个共享配置中，而不是散落字面量。
测试：在半路上中断它、反向操作、拖动过界、仅使用键盘、启用减少动效、在 DevTools 中限制 CPU。
报告你更改了什么以及你无法测试什么。

适用于两种模式的原则

说明什么是已验证的，什么是判断；命名任何未经验证内容的检查方法。
报告阻塞项（无法访问 URL、缺少工具、文件读取失败），而不是默默绕过它们。
停留在请求范围内：报告偶然发现而不是未经请求就修复它们。
优先选择数量更少、证据充分的问题，而不是一长串通用问题。

Apple Design Pro (Web)