XR 空间计算（visionOS · Metal · 沉浸式界面）

何时使用

1. 为 Apple Vision Pro 做原生空间应用：窗口／体积／沉浸空间怎么选，玻璃材质、空间小组件、多窗口架构怎么搭
2. 自研渲染引擎直连合成器：用 Metal + Compositor Services 接管立体渲染、纹理布局、注视点渲染与帧率预算
3. 设计空间界面：凝视+捏合的间接手势体系、悬停效果、深度层级、可读性与可瞄准性
4. 用户反映不适：戴着头显头晕／眼疲劳／「感觉空间在动」——走 §五 舒适度防护逐条排除
5. 座舱／坐姿交互：操纵杆、油门、仪表盘、约束式控制与坐姿参考系；浏览器侧沉浸式（WebXR 跨设备兼容、输入差异、无能力时如何干净降级）

判定（分流相邻技能）：动的是空间平台约束（沉浸级别、注视点渲染、空间界面、舒适度）＝ 本技能；动的是内容与规则（机制、叙事、关卡、音频设计）＝ game-content-design；动的是引擎架构／工具链／世界分区＝ game-engine-engineering；动的是通用着色器与美术管线＝ game-tech-art（但「因立体渲染／注视点渲染而必须改的着色器约束」归本技能）；动的是网络同步＝ game-multiplayer-netcode。

触发语（语言信号）

• 中文：visionOS、Apple Vision Pro、空间计算、空间界面、沉浸式空间、体积窗口、玻璃材质、空间小组件、Metal、Compositor Services、注视点渲染、立体渲染、晕动症、舒适度、凝视捏合、悬停效果、座舱交互、坐姿体验、空间 UI、WebXR
• English: visionOS, Apple Vision Pro, spatial computing, spatial UI, volumetric, immersive space, Shared Space, Full Space, Liquid Glass, Metal, Compositor Services, LayerRenderer, foveated rendering, stereoscopic rendering, motion sickness, visual comfort, gaze and pinch, hover effect, cockpit interaction, seated experience, WebXR, graceful degradation

总纲：三条底座

1. 材料诚实优先于篇幅。本技能由 5 份外部专家资料融合而成，其中多数是「薄件」——只有身份／使命／能力清单三段，没有交付物模板、没有工作流、没有量化指标。薄就是薄：本技能如实标注每条要点的层级，绝不用通用 3D 常识冒充专家结论（见 §一）。
2. 空间计算的成本是「身体」。桌面 UI 出错是效率损失，空间 UI 出错是不适、眩晕、手臂酸胀。因此一切设计决策先过舒适度闸门，再谈视觉表现力。
3. 一切沉浸都可退出。用户在共享空间与全空间之间应始终保有控制权；把用户「锁」进沉浸，是空间体验的头号红线。

一、材料层级与标注约定〔先读〕

1.1 本技能的三类标注

1.2 5 份外部专家资料的实际厚度（如实记录）

结论：5 份中有 4 份是薄件（1.7–3.4 KB，仅三段式），1 份（macOS Spatial/Metal）达 12.1 KB 且含模板、工作流与指标。本技能的「渲染管线」一节因此比其余各节更有原文支撑；其余各节的骨架基本靠外部权威补齐。凡下述段落未标〔原文〕者，请默认其来自外部检索或常识层。

1.3 薄件的共性缺陷（原文层面）

• 无交付物模板：四份薄件列的是「能做什么（What You Can Do）」，不是「产出物长什么样」；无工作流：没有 step-by-step 过程，只有能力清单
• 无量化指标：原文（XR 界面架构） 与 原文（座舱交互） 在 Identity 段声称记忆了「输入延迟容忍度」「晕动阈值」「控制布局标准」，但正文一个数字都没给——属不可验证的自我声明，本技能不采信为指标（见 §6.2）
• 无失败模式：四份薄件均无 Critical Rules，故 §九 反例主要依据 原文（macOS Spatial/Metal） 的 Critical Rules〔原文〕与人因常识〔常识〕反写

二、visionOS 空间计算范式

2.1 三种场景类型〔外部〕

visionOS 的空间构成由三类 scene 组合而成，构成一条沉浸度光谱：

〔原文〕（visionOS 空间） 补充了 visionOS 26 的能力面：Liquid Glass 半透明材质（随明暗环境与周围内容自适应）、空间小组件（吸附墙面／桌面并保持放置）、唯一窗口实例、体积呈现、RealityKit-SwiftUI 集成（可观察实体、直接手势处理、ViewAttachmentComponent）、glassBackgroundEffect。这些均标注为 visionOS 26 特性且自陈不向前兼容，落地前须按目标系统版本核对（见 §十 存疑 4）。

2.2 共享空间 vs 全空间〔外部〕

• Shared Space：默认启动位置。多 app 并存，用户可开、关、移动窗口；系统能力（ARKit 空间理解）在此自动生效，但不给第三方 app 原始数据
• Full Space：该 app 独运行，其他 app 隐藏；可叠加窗口与体积、创建无界 3D 内容、开门户、或完全沉浸

判据：优先在 Shared Space 或 mixed 风格启动，让用户自己选择何时加深沉浸——一启动就推全沉浸会造成惊扰。

2.3 三级沉浸风格与硬边界〔外部〕

边界机制：头部接近边界时整个体验淡出、透传增强；超出边界后沉浸画面被替换为该 app 图标，回到原位或按数字旋钮重新居中后恢复。

2.4 透传、数字旋钮与环境〔外部〕

• 透传（passthrough）＝ 外部摄像头实时视频，是用户与物理世界保持连接的主通道；可调暗／着色以聚焦注意力（SurroundingsEffect），但应用微妙着色——强烈着色会削弱沉浸并干扰用户
• 数字旋钮（Digital Crown）：按住可重新居中内容；双击可临时隐藏所有内容看清环境。mixed 风格下不得大量遮挡透传——需要遮挡就改用 progressive／full
• 环境设计四条：最小化干扰内容（低对比、少运动）；用距离提示可交互性（近处物体用户才会尝试触碰）；动画保持微妙，绝不放大视野边缘的运动；环境要开阔（狭小空间引起幽闭感）

2.5 人因顺序（原文 + 外部）

〔外部〕内容默认放在用户视野内且相对于头部定位，系统自动处理不同身高与坐／站／躺姿态；但不要主动把内容锚定到头部——静态贴在眼前的物体会让人感到被困、受限，尤其当它遮挡大量透传、削弱周围环境的稳定性感知时。正确做法是锚定在用户的空间中，让人自由环顾。视场的尺寸因人、因遮光罩配置而异，且系统不提供用户视场信息——因此不存在「按度数精确定位」的编程手段，只能遵循「居中优先、不要求转头」的定性原则。

〔原文〕（macOS Spatial/Metal） 提出把焦点平面放在 2 米以获得舒适辐辏；并列出必须遵守的 HIG 项：舒适区与辐辏-调节（vergence-accommodation）极限、立体渲染的正确深度排序、手部追踪丢失的优雅处理、无障碍（VoiceOver / Switch Control）。

三、Metal 渲染管线与合成器接入

> 本节是本技能原文支撑最强的一节（骨架来自 12.1 KB 的 原文（macOS Spatial/Metal））；管线结构与资源模型的细节由 Apple 官方文档补足〔外部〕。

3.1 Compositor Services 接入路径〔外部〕

Metal 自研引擎只能走 ImmersiveSpace，且必须使用 CompositorLayer：

ImmersiveSpace(id:) { CompositorLayer { layerRenderer in Task { /* 你的渲染引擎 */ } } }

• CompositorLayer 提供 LayerRenderer，后者给出渲染循环所需的 Metal 类型与时序信息；时序信息用于按显示器刷新率交付帧——Apple 文档明确「以自定义渲染循环每秒最多渲染 90 帧」
• 渲染循环应跑在独立线程（Apple 示例用 TaskExecutor + .userInteractive 队列）；CompositorLayer 所在空间不要加任何 style 修饰符（系统会自动配置为全沉浸并忽略修饰符）
• 输出是每只眼一张图（两眼合成产生立体感），须含深度信息以正确遮挡〔原文+外部〕
• 〔原文〕同一份材料用 RemoteImmersiveSpace 把 macOS 侧立体帧串流到 Vision Pro；该 API 出现在 visionOS 26 的 SwiftUI 场景能力中（WWDC25 场次 290）〔外部佐证〕

3.2 纹理布局与注视点渲染〔外部〕

• 注视点渲染（foveated rendering）：目标是在不增大纹理尺寸的前提下提高每度像素密度——注视区高采样率、周边低采样率；合成器每帧提供 MTLRasterizationRateMap
• 能力探测：capabilities.supportsFoveation、capabilities.supportedLayouts(options:)；模拟器不支持注视点渲染，不做能力校验会在模拟器上失败。颜色：合成器期望扩展线性 Display P3，支持 2.0 EDR（SDR 两倍），默认像素格式不支持 HDR，须显式设 rgba16Float

3.3 资源存储模式〔外部〕

判据：每帧都更新的小数据用 shared；GPU 独占的用 private；帧内临时纹理用 memoryless。 〔原文〕与本条一致：「频繁更新的数据用 private Metal 资源」——注意这句在语义上更接近「GPU 侧私有的高频数据」，与外部文档的「CPU 高频写入用 shared」并不冲突但表述易误导，落地时按 CPU/GPU 谁写谁读来选（标注为表述风险）。

3.4 上传、同步与内存纪律

• 〔原文〕用 shared buffer 做 CPU-GPU 数据传输；三缓冲（triple buffering）＋资源堆（resource heaps）；资源池化复用；注意 ARC、避免循环引用；定期用 Instruments 剖析；伴随应用（companion app）内存 < 1 GB —— 该 1 GB 是原文自定预算，不是 Apple 官方指标
• 〔外部〕写入 private 资源要走 blit 拷贝；macOS managed 资源 CPU 写完调 didModifyRange(_:)，GPU 写完在 blit pass 中调 synchronizeResource(_:)；CPU-GPU 同步的通用做法是信号量／fence + command buffer 的 addCompletedHandler，在三缓冲边界内保证一致性

3.5 绘制手段、剖析与指标

• 〔原文〕实例化绘制承载海量节点；视锥剔除 + LOD；激进批处理，目标 < 100 draw call／帧；private 资源承载高频更新数据
• 〔原文〕进阶：间接命令缓冲（GPU 驱动渲染）、网格着色器（mesh shader）、可变速着色（注视点渲染）、硬件光追；高级手部姿态估计、眼动追踪驱动的注视点渲染、空间锚点做持久布局、SharePlay 协同可视化
• 〔原文〕剖析：Metal System Trace + Instruments；优化着色器占用率与寄存器用量；按节点距离做动态 LOD；时域上采样提升感知分辨率
• 〔原文〕指标：90 fps 下 25k 节点为默认要求（目标区间 10k–100k）；GPU 利用率 < 80% 留热余量；凝视到选中延迟 < 50 ms；图更新期间不掉帧；示例数据「Metal System Trace 显示 25k 节点帧耗时 11.1 ms」
• 〔外部〕Apple 官方规格：刷新率 90 / 96 / 100 Hz（M2 版规格页），后续机型规格页另列 120 Hz —— 版本相关，须按机型核对；R1 协处理器 12 ms 光子到光子延迟、256 GB/s 内存带宽。光子到光子是系统级光学链路指标，不能当应用帧预算用——应用侧应按「刷新率 → 每帧预算」换算（90 Hz ⇒ 11.1 ms／帧），并另算跟踪与仿真开销

3.6 原文技术风险一例（存疑）

〔原文〕（macOS Spatial/Metal） 在优化手段中写「用 geometry shaders 做高效的边渲染」。存疑：几何着色器在 Apple 自研 GPU 上不受支持（该特性历史上仅部分 macOS 独立 GPU 可用，且已趋废弃路线）。此条不采信为可用方案，边渲染应以实例化线段／drawPrimitives(type: .line, ...)／计算着色器扩展几何等替代路径实现，并在目标机型实测后再定。

四、空间界面与交互设计

4.1 两套手势体系〔外部〕

判据：常规控件（按钮、列表）一律优先间接手势；直接手势与自定义手势只留给需要凑近端详或特定动作的对象。

• 标准手势集：轻点（选中／激活）、轻点并按住（上下文菜单）、轻拖（移动）、双击（预览）、轻扫（揭露操作／关闭／滚动）、双手捏合外扩／内收（缩放）、双手捏合画圈（旋转）
• 自定义手势的硬前提：必须运行在 Full Space 且已获手部数据权限
• 禁止要求特定身体动作或姿势作为唯一输入；禁止要求用指定某只手（提高认知负荷，且对手部优势／肢体差异人群不友好）
• 手／腕／前臂的滚动动作已被系统保留用于唤起系统叠加层（如看掌心出 Home indicator）；自定义手势若与之冲突须重点测试

4.2 凝视、悬停效果与隐私〔外部〕

• 用户看向可交互元素时，系统显示悬停效果，确认「就是这个」；看向标签栏等组件还会自动展开。悬停延迟三档：无延迟（效果微妙或引导交互，如滑杆上的旋钮浮现）／短延迟（看一眼即可交互，如标签展开）／长延迟（承载附加信息，如工具提示）
• 隐私硬约束：visionOS 不提供用户在点击前的注视位置——系统组件会自动告知「用户点了这个组件」，但 app 拿不到「用户正在看哪里」；且自定义悬停效果在 app 进程之外施加，你无法知道系统何时应用它、元素处于哪个状态，因此悬停效果不能执行需要「知道用户在看我」的代码
• 悬停效果设计：至少保留一个主视图在两个状态间不变（提供视觉稳定性）；避免滥用（会稀释效果并致视觉不适）；必须戴在头上实测

4.3 布局与可瞄准性〔外部〕

• 间距：交互元素中心至少相距 60 pt，元素边界外留至少 16 pt；控件不得重叠；复合组件须定义整体包含区域供系统高亮
• 形状：交互元素倾向圆角——眼睛会被尖角吸引，越圆越容易稳定瞄准；重复图案／纹理不得铺满视野（眼睛会锁定图案中不同元素，产生虚假深度感）
• 观看距离：需长时间阅读或交互的内容至少放在 1 米外；不要开太多窗口——会遮挡环境、造成压迫与不适，且搬移困难

4.4 深度与缩放〔外部〕

• 深度用来传达层级（如 sheet 弹出时窗口沿 z 轴后退）；但不要给正文文字加深度（悬浮文字难读、拖慢阅读、可引起不适）；不要滥用深度——人眼每次感知深度差都要重新对焦，频繁或快速对焦变化会疲劳。深度线索缺失或与真实世界冲突会引起视觉不适
• 动态缩放（dynamic scale）：窗口远离时系统自动放大、靠近时缩小，使内容在各距离保持同样的可读尺寸；固定缩放（fixed scale）用于需「和实物一样大」的展示，但应仅用于非交互对象
• visionOS 的 point 是角度而非像素（其他平台的 point 是随分辨率变化的像素数）——跨平台移植 UI 时最易踩的换算陷阱

4.5 多模态输入与无障碍

• 〔原文〕（XR 界面架构）：支持直接触控、凝视+捏合、控制器、手部手势四类输入模型；多模态输入须备有降级路径。其他职责面：定义沉浸应用 UI 流程；与 XR 开发者协作保证 3D 语境可用性；为座舱／仪表盘／可穿戴出布局模板；做以舒适度与可学习性为指标的 UX 验证实验（未给实验方法与指标数值）
• 〔原文〕无障碍：原文（visionOS 空间） 的 VoiceOver 与沉浸界面空间导航；原文（macOS Spatial/Metal） 的 VoiceOver / Switch Control
• 〔外部〕系统级无障碍能力：VoiceOver、Switch Control、停留控制（Dwell Control）、引导式访问、头指针（Head Pointer）；「指针控制」允许选食指／手腕／头部作为替代指针

五、舒适度与晕动症防护（本节几乎全为外部权威，原文仅少量）

5.1 运动与视野〔外部〕

5.2 沉浸与移动〔外部〕

• 不要在 progressive／full 中鼓励用户移动：有人不愿动、有人因残障或环境无法动——应让内容走向用户，而不是让用户走向内容
• 若预判用户可能走出约 1.5 米边界，就不要用 progressive／full，应退回 mixed；用 mixed 时不要把透传遮得太狠
• 过渡必须平滑、可预期、可视化可追踪；避免突然、生硬的切换
• 由用户决定何时进出沉浸，并提供语义明确的退出控件（「返回上一层」还是「退出应用」须说清）；若退出即退应用，应提供暂停／保存入口
• 分阶段沉浸：对每个关键时刻选取满足该时刻的最小沉浸级别，不要假定每一刻都需要全沉浸

5.3 原文的舒适度条款〔原文〕

• 尊重舒适区与辐辏-调节极限；立体渲染必须做正确的深度排序；手部追踪丢失须优雅处理（不可让核心功能因追踪中断而不可用）
• 立体渲染中不得掉到 90 fps 以下；GPU 利用率压在 80% 以内以留热余量
• 焦点平面置于 2 米以获得舒适辐辏（原文（macOS Spatial/Metal），Communication Style 示例）

5.4 晕动症与延迟的量化关系〔外部〕

• motion-to-photon（MTP）延迟：VR 业界共识目标 ≤ 20 ms（Carmack／Abrash 路线广为引用值）；有研究提出敏感用户需 < 17 ms；AR（光学透视）因真实世界本身零延迟作参照，要求更严，目标常在 < 7 ms，理想 < 5–10 ms；MTP 超过 50–60 ms 后不适与晕动风险显著上升
• 90 Hz 对应每帧 11.1 ms；MTP 预算是端到端的（传感采样＋传输与跟踪解算＋应用／CPU 处理＋GPU 渲染＋显示扫描与稳定），不能把 11.1 ms 全部分给 GPU；重投影（reprojection／time warp）只补偿头部姿态变化，不改善交互延迟
• 来源：SID 期刊 Temporal Requirements for VR Displays（Wiley）、IETF draft Transport Support for AR/VR（引 Carmack 2013 与 NASA 研究）、ScienceDirect 渲染延迟条目。属外部研究共识，非 Apple 官方指标，非原文内容。

六、座舱与坐姿交互

〔原文〕（座舱交互） 的全部正文即以下七条，无模板、无流程、无阈值：

1. 手交互 yoke／lever／throttle：用 3D mesh 加输入约束实现；约束驱动的控制机制（no free-float motion）——不提供自由漂浮位移
2. 仪表盘 UI：toggle、switch、gauge 加动画反馈；多输入 UX：手部手势 + 语音 + 凝视 + 实体道具
3. 把用户视角锚定到坐姿界面以最小化迷失感；人机工效对齐「眼—手—头」自然流动
4. 原型实现走 A-Frame 或 Three.js

6.1 与通用空间 UI 的原则冲突（须显式处理）

〔外部〕通用 visionOS 原则是「不要把内容锚定到用户头部」（会让人感到被困、削弱环境稳定性），而座舱恰恰要求把视角锚定到坐姿参考系。解法：锚定到坐姿的固定参考系（座舱本体的空间坐标）而非头部——头仍可自由转动，只是载具／座椅的位姿驱动整个参考系运动。座舱把移动自由度交给载具模型而非用户位移，这本身就是晕动防护的结构性手段〔常识〕。但座舱不豁免 §5.1 的周边视觉、旋转世界、振荡频率三条禁令——座舱内的快速滚动、仪表指针抖动、舷窗外高速掠过的景物都属高风险项〔常识〕。

6.2 存疑项（原文声称但未给出）

〔原文〕（座舱交互） 的 Identity 段声称掌握「控制布局标准」「坐姿导航的 UX 模式」「晕动阈值」；原文（XR 界面架构） 同样声称记忆「人机工效阈值」与「输入延迟容忍度」，但两份原文正文均未出现任何数值或标准编号。

结论：这些是不可验证的自我声明，不作为指标使用。本次外部检索亦未找到针对「XR 座舱」的可引用一手控制布局标准或晕动阈值（Apple HIG 未覆盖座舱形状因子），故 §八 不列座舱专用阈值——该缺口如实保留。

七、WebXR 与跨平台降级

〔原文〕（XR 沉浸式开发） 全部正文（1.8 KB、三段式）只给出以下要点，无代码模板、无性能预算、无流程：

• 技术栈与输入：WebXR Device APIs ＋ A-Frame / Three.js / Babylon.js；覆盖手部追踪、捏合、凝视、控制器
• 交互与性能：射线检测（raycasting）、命中测试（hit testing）、实时物理；遮挡剔除（occlusion culling）、着色器调优、LOD 系统
• 设备矩阵与工程方式：Meta Quest / Vision Pro / HoloLens / 移动 AR 的多运行时兼容层；模块化、组件驱动的 XR 应用；干净的降级路径（clean fallback）
• 能力清单：脚手架化搭建 WebXR 项目；构建带交互面的 3D UI；跨浏览器与运行时的空间输入问题调试；提供降级行为与优雅退化策略

7.1 外部补充与降级判据

• 〔外部〕visionOS 26 的 Safari 侧能力已扩展：网页内嵌 3D 模型（可内联查看、可拉出到空间看 1:1 实物）、网页内播放空间与沉浸式视频（含 Apple Immersive Video）、「空间浏览」在滚动中显示空间场景、面向开发者的自定义沉浸式「Web environments」预览。版本敏感，落地须按目标系统版本核对
• 〔常识〕能力探测优先于特性假设：手部追踪、平面估计、命中测试、沉浸模式逐项探测后启用；每种输入都要有非 XR 等价路径（鼠标／触控／键盘／游戏手柄），否则 WebXR 页面会退化成不可用页面；跨设备意味着按「意图」而非「手势」建模，再在设备层映射

八、量化验收指标

表内每一项都标注了来源层级。原文未给完整指标集，故本表以外部权威为主。

指标缺口（如实保留）：〔原文〕四份薄件未给任何指标，唯一提供 Success Metrics 的是 原文（macOS Spatial/Metal）；座舱专用指标缺失——原文声称有晕动阈值与布局标准但未给数，外部检索亦未找到可引用的座舱一手标准 → 本技能不编造。
- 〔原文〕（XR 界面架构） / 原文（座舱交互） 声称的「输入延迟容忍度」「人机工效阈值」在原文与本次外部检索中均无出处 → 不计入验收

九、反例（八条）

十、来源与边界

10.1 材料层级声明（必读）

本技能的骨架来自 5 份外部专家资料，其实际层级为：

• 4 份是薄件（原文（XR 界面架构） 1.7 KB、原文（座舱交互） 1.8 KB、原文（XR 沉浸式开发） 1.8 KB、原文（visionOS 空间） 3.4 KB），均只有 Identity / Core Mission / What You Can Do 三段（原文（visionOS 空间） 略多一段 Limitations）——无交付物模板、无工作流、无量化指标。
• 1 份相对厚（原文（macOS Spatial/Metal） 12.1 KB / 336 行），含 Critical Rules、4 段代码模板、4 步 Workflow、Communication Style、Success Metrics。§三 的原文支撑主要来自这一份，§五 与 §九 的部分红线和 §八 的部分指标亦来自它。
• 因此：本技能约六成的方法论内容不是「外部专家资料」，而是本次检索的 Apple 官方文档与人因研究。凡未标〔原文〕者，请勿当作专家结论引用。

10.2 各节要点与原文出处对照

10.3 外部来源清单〔外部〕

用于补齐原文缺失技术面的权威来源（developer.apple.com/design/human-interface-guidelines/… 简称 HIG）：

• Apple HIG：designing-for-visionos（空间／沉浸／透传／空间音频／眼与手／工效／无障碍总则）；spatial-layout（视野、禁止头部锚定、深度、动态／固定缩放、point 为角度、窗口数量、间接手势优先、60 pt／16 pt、地面平面）；immersive-experiences（共享空间 vs 全空间、mixed/progressive/full、约 1.5 m 边界、120°–360°、透传着色、环境设计、过渡与退出）；motion visionOS 段（周边视觉运动、大物体透明度／对比、禁止旋转世界、静止参照系、约 0.2 Hz、游戏 30–60 fps 参考）；eyes（悬停效果、凝视隐私、悬停效果进程外执行、≥1 m 观看距离、圆角、避免满视野图案、悬停延迟三档）；gestures visionOS 段（间接／直接手势、标准手势表、自定义手势前提、禁止指定手别、滚动手势被系统保留）
• WWDC23「Discover Metal for immersive apps」、Apple Developer — Compositor Services / Drawing fully immersive content using Metal：三种纹理布局（layered/dedicated/shared）、注视点渲染与 MTLRasterizationRateMap、扩展线性 Display P3 与 2.0 EDR、rgba16Float；CompositorLayer / LayerRenderer / Frame / Drawable；渲染循环「最高 90 帧/秒」；渲染线程与 UIApplicationPreferredDefaultSceneSessionRole；CompositorLayerConfiguration、supportsFoveation、supportedLayouts；「Rendering hover effects in Metal immersive apps」
• Apple Developer — Choosing a resource storage mode for Apple GPUs / Resource fundamentals、归档 Metal Best Practices Guide — Resource Options、Apple Vision Pro 官方规格页（Tech Specs）：四种存储模式语义与适用场景、memoryless 仅限纹理、didModifyRange / synchronizeResource；刷新率 90/96/100 Hz（M2 版）与后续机型页的 120 Hz、R1 光子到光子 12 ms、256 GB/s、IPD 51–75 mm、重量 600–650 g
• WWDC25「Set the scene with SwiftUI in visionOS」（290）与 visionOS 26 官方 What's New：RemoteImmersiveSpace 从 macOS 串流沉浸内容、窗口／体积锁定到房间并持久化、场景恢复、网页内 3D 模型与沉浸视频
• 人因／延迟研究：SID 期刊 Temporal Requirements for VR Displays…；IETF draft Transport Support for AR/VR（引 Carmack 2013、NASA 研究）；ScienceDirect 渲染延迟条目 —— §5.4 的 20 / 17 / 7 / 50–60 ms 阈值出处

10.4 未核与存疑清单

• 未核（材料层级结果）：5 份外部专家资料不含模板，故本技能不提供任何交付物模板（对比 game-content-design 有五套）——不以通用常识补造。
• 存疑 1：原文「geometry shaders 做边渲染」在 Apple 自研 GPU 上不可用（§3.6）。
• 存疑 2：原文「频繁更新的数据用 private 资源」表述易误导——private 意味着 CPU 不可访问，CPU 每帧写入应选 shared（§3.3）。
• 存疑 3／4：原文声称的「控制布局标准」「晕动阈值」「输入延迟容忍度」「人机工效阈值」均无出处，不采信（§6.2、§8 缺口）；原文将能力标注为「visionOS 26」并自陈不向前兼容，Apple API 与刷新率随机型／系统版本变动，落地前须按目标机型逐一核对
• 未核：原文引用的 Apple 文档 URL 本次未逐条打开验证内容一致，仅作来源线索；未做任何渲染实测，§八 全部数值均为引用阈值

10.5 本技能不做与相关技能

• 不做：通用游戏内容设计 → game-content-design；通用引擎架构／系统实现／工具链／世界分区 → game-engine-engineering；通用着色器编写、材质与美术资产管线、VFX → game-tech-art（XR 特有渲染约束与合成器接入归本技能）；网络同步与权威模型 → game-multiplayer-netcode；Roblox 平台 → roblox-platform-dev；工作室级流程编排 → game-studio-orchestration
• 相关：art-foundation（构图／光影／色彩底座）、nano-banana-pro 与 designkit-usage（视觉资产生成）、ai-video-director-preanalysis（沉浸式内容的前置镜头决策）

异常处理与降级（Error Handling）

输入校验：什么算「不合格输入」

错误分类与处置

明确不做与去向

> 本技能不做通用游戏内容设计（机制／叙事／关卡／音频）、不做通用引擎架构与工具链、不做通用着色器编写与美术资产管线、不做网络同步。
> 若你要的是内容与规则 → game-content-design；引擎架构／世界分区 → game-engine-engineering；通用着色器与材质 → game-tech-art（但「因立体渲染／注视点渲染而必须改的着色器约束」归本技能）；网络同步 → game-multiplayer-netcode。
> 本技能不编造座舱专用阈值——原文声称有「晕动阈值」「控制布局标准」但正文一个数字都没给，外部检索亦未找到可引用标准（§6.2、§8 指标缺口）：该缺口如实保留。

输出一致性保障（Stability）

• 固定输出骨架：每次输出必含四段且顺序固定——场景与沉浸风格 / 渲染与性能判定 / 舒适度红线 / 未核与存疑。某段为空也要写出并标「无」，不得省略整段。
• 每条断言携带证据：须带「层级标记（〔原文〕/〔外部〕/〔常识〕）＋ 具体 API 或条文名 ＋ 数值」。三项缺一即为不合格输出；不得把〔常识〕包装成〔原文〕结论（§1.1）。
• 幂等：同一目标机型与同一段场景描述，重复执行应给出同一组判定。若两次不同，说明存在未标出的不确定性（未确认刷新率、未确认布局等）⇒ 须补标注，不得静默择一。
• 时效敏感项：凡引用会随系统版本变化的内容（visionOS 26 特性、刷新率 90/96/100/120 Hz、R1 光子到光子 12 ms、Liquid Glass），须标「未核」＋目标版本，不得当成永久事实。
• 数值只引用不臆造：§8 表内阈值均带来源层级；原文四份薄件未给指标——凡需新数一律标「缺口」，不以通用 3D 常识补造（§8 指标缺口）。
• 风险不软化为建议：视场边缘运动、旋转虚拟世界、头部锚定三条（§5.1／§9）在任何输出中都以「禁止」措辞出现，不得降级为「尽量」。

常见问题 FAQ（含正反对比）

Q1 在模拟器上启用注视点渲染，为什么直接失败？
- ❌ 判定「设备不支持注视点渲染」，放弃该特性。
- ✅ 保留能力探测 capabilities.supportsFoveation → capabilities.supportedLayouts(options:)，并给模拟器路径显式关闭注视点渲染。
- 为什么：模拟器不实现注视点渲染（§3.2）；失败是模拟器特性而非设备能力，不做能力校验就会把「模拟器不跑」误读成「真机不支持」。

Q2 想让注视点渲染省算力，选 shared 纹理布局行不行？
- ❌ 行，反正只渲染两只眼。
- ✅ 不行——shared 是单纹理双视口、不适配注视点渲染；要保留注视点渲染须选 layered。
- 为什么：注视点渲染依赖合成器逐帧提供的 MTLRasterizationRateMap，而 shared 的视口模型与它不相容（§3.2 布局表）。

Q3 想省事，把内容锚定到用户头部可以吗？
- ❌ 可以，用户抬眼就能看见，最稳。
- ✅ 锚定在用户的空间里；静态贴眼前的物体会让人被困、受限，还削弱环境稳定性感知。
- 为什么：系统虽允许内容随头部定位，但持续占据视野会破坏空间参照；看内容应靠用户自由环顾（§2.5、§9 反例 2）。

Q4 每帧更新的小数据，放 private 资源更快？
- ❌ 是，private 对 GPU 最快，所以高频数据都放 private。
- ✅ 按「谁写谁读」选——CPU 每帧写入的数据放 shared；private 意味着 CPU 不可访问，CPU 侧写入要先走 blit 拷贝。
- 为什么：原文那句「频繁更新的数据用 private Metal 资源」语义上指 GPU 侧高频数据；直接照搬会把 CPU 每帧写入放进不可访问的资源（§3.3、§10.4 存疑 2）。

Q5 用 geometry shader 做边渲染，原文这么写的，能落地吗？
- ❌ 能，原文写了就用。
- ✅ 不采信——Apple 自研 GPU 不支持几何着色器；边渲染改用实例化线段／drawPrimitives(type: .line, ...)／计算着色器扩展几何。
- 为什么：该特性历史上仅部分 macOS 独立 GPU 可用且已趋废弃路线，落在 Apple 自研 GPU 上不可用（§3.6 存疑 1）。

Q6 玩家就想在 progressive／full 里走动，鼓励一下不行吗？
- ❌ 行，沉浸就该动起来才真实。
- ✅ 不在沉浸态鼓励用户移动；让内容走向用户，若预判会走出约 1.5 m 边界就退回 mixed。
- 为什么：有人不愿动、有人因残障或环境无法动——逼人位移既是可达性问题，也把人推向边界触发淡出（§5.2）。

Q7 高频主操作安排成直接手势（举臂触碰）更直观？
- ❌ 直观，直接手势更有沉浸感，主操作就用它。
- ✅ 常规控件一律优先间接手势（看住目标＋任意位置轻点／捏合）；直接手势只留给可及范围内、短时凑近端详的对象。
- 为什么：直接手势须在可及范围内，且长时间举臂会疲劳——做成高频主操作必然被手臂酸胀反噬（§4.1、§9 反例 3）。

Q8 「凝视到选中 < 50 ms」能直接当成应用帧预算用吗？
- ❌ 能，50 ms 就是全部时间，直接塞进渲染循环即可。
- ✅ 不能——50 ms 是交互延迟指标；应用侧要按刷新率换算每帧预算（90 Hz ⇒ 11.1 ms/帧），端到端 MTP 还要另算传感与跟踪开销。
- 为什么：「光子到光子 12 ms」是系统级光学链路指标、「凝视到选中 50 ms」是交互延迟、11.1 ms 是应用帧预算，三者口径不同；混用会算错预算（§3.5、§8）。

完整示例（输入 → 判定 → 输出）

输入：「给 Vision Pro 做一个 3000 面的机械装配体展示，要单眼高密度、周边省算力，跑在 90 Hz 上，用户站着看就行，不要那种一眼就被锁住的感觉。」

判定：走 §2.1 选场景类型（要 3D 可环视 → Volume 或 ImmersiveSpace）→ §3.2 定纹理布局（要注视点渲染 → layered）→ §3.3 选存储模式 → §5.1／§5.2 过舒适度闸门 → §8 逐项对每帧预算。

输出（成品，无任何占位符）：

【场景与沉浸风格】
- 场景类型：ImmersiveSpace(id: "AssemblyViewer")，走 RealityKit-SwiftUI 集成，3D 内容可任意角度观察
- 沉浸风格：起步 mixed（不设边界，透传为主）；用户主动升档才给 progressive
- 不锚定头部：装配体锚定在用户空间前方 2 m 焦点平面处，头可自由环顾
- 退出控件：语义明确写「返回共享空间」，不是「退出应用」

【渲染与性能判定】
- 纹理布局：layered —— 单通道立体渲染，保留注视点渲染（判定依据 §3.2 布局表）
- 注视点渲染：启用；前提是先读 capabilities.supportsFoveation；
  模拟器路径显式关闭（模拟器不支持），真机启用 MTLRasterizationRateMap
- 像素格式：显式 rgba16Float，色彩空间扩展线性 Display P3（默认格式不支持 HDR）
- 存储模式：装配体网格与贴图 → private（GPU 独占）；
  每帧旋转矩阵 → shared（CPU 每帧写入）；
  单 pass 内深度／模板 → memoryless（仅纹理，不能用于 buffer）
- 每帧预算：90 Hz ⇒ 11.1 ms／帧
- 负载实测：Metal System Trace 显示 3000 节点帧耗时 5.8 ms，GPU 利用率 42%，
  draw call 38 次／帧（< 100）—— 均在 §8 阈值内
- 手部追踪丢失时：保留凝视+捏合与控制器两条等价路径，核心功能不依赖手部

【舒适度红线】
- 静止参照系：装配体固定于空间，四周不放随动粒子或流动背景（避免「环境在动」误判）
- 视场边缘：不放运动元素；高亮轮廓亮度与其余可见内容接近
- 不旋转虚拟世界：切换装配体角度用快速淡出后的瞬时方向切换，不做平滑旋转
- 阅读距离：标注文字始终 ≥ 1 m；交互热区中心间距 ≥ 60 pt、边界外留白 ≥ 16 pt
- 视觉噪声：零件描边用圆角、不铺满视野；透明件透明度随零件体积增大而提高

【未核与存疑】
- 目标系统版本未给：Liquid Glass／glassBackgroundEffect 等 visionOS 26 特性一律标「未核」，
  落地前按目标机型系统版本逐一核对（§2.1、§10.4 存疑 4）
- 刷新率随机型变动：本判定按 90 Hz 算；若目标机型规格页为 96／100／120 Hz，每帧预算须重算（§3.5）
- 座舱方向不涉及：本场景非座舱，本技能不编造座舱专用阈值（§6.2）

注意：上例的「未核与存疑」段必须写满——即便结论是「不涉及」，也要写明为什么不涉及，不得留空。