# Web Online Exhibition Master

> Web 线上展览开发 (虚拟展厅) (Web 线上展览 / 虚拟展厅开发 (从业者/工程视角) — 用 web 技术开发线上展览、虚拟展厅、云展会、数字展馆，覆盖 3D 空间、全景漫游、WebXR、文博数字化、营销云展厅、3D 商品展示等形态。覆盖: (a) 技术栈 — 3D web(Three.js / React Three Fiber / Babylon.js / Google model-viewer / WebGL / WebGPU)、全景(Pannellum / Marzipano / Photo Sphere Viewer / krpano / 720云)、WebXR(WebXR Device API / A-Frame)、资产管线(glTF·GLB / Draco / Meshopt / KTX2 纹理压缩 / gltf-transform / LOD); (b) 自研 vs SaaS 平台选型(国内: 众趣 / 酷雷曼 / 比目鱼 / 会鸽 / 3DVista; 海外: Matterport / Kuula / Artsteps / Spatial); (c) 性能优化(大场景加载 / 模型轻量化 / draw call / 移动端 / 首屏 / 显存)——web 3D 第一性难题; (d) 策展与导览(动线设计 / 热点 hotspot / 语音讲解 / 交互); (e) 文博数字化(IIIF / 数字孪生 / 高清文物) 与 会展·电商商业化(营销云展厅 / 数据埋点 / 线索转化); (f) 部署(CDN / 流式加载 / 跨端兼容 / WebGL 降级)。学派分歧: 自研 Three.js vs SaaS 平台、真 3D 重场景 vs 720 全景轻量、WebGL vs WebGPU、文博考据派 vs 营销转化派、沉浸优先 vs 加载优先。不含: 线下展陈 / 展台搭建、原生 VR App(非 web)、通用 3D 游戏开发、纯 3D 建模教程。) Master OS — automated mastery of Web 线上展览 / 虚拟展厅开发 (从业者/工程视角) — 用 web 技术开发线上展览、虚拟展厅、云展会、数字展馆，覆盖 3D 空间、全景漫游、WebXR、文博数字化、营销云展厅、3D 商品展示等形态。覆盖: (a) 技术栈 — 3D web(Three.js / Reac

- Skill: `swaylq/web-online-exhibition-master` (Agent Skill, multi-file: 16 files)
- Install (CLI): `npx skillmds@latest add swaylq/web-online-exhibition-master`
- Raw SKILL.md: https://api.skillmd.com/api/skills/swaylq/web-online-exhibition-master/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: swaylq (https://skillmd.com/u/swaylq)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/swaylq/web-online-exhibition-master

---


# Web 线上展览开发 (虚拟展厅) · Master OS

> 装上这个 skill, agent 立刻进入「Web 线上展览开发 (虚拟展厅)」资深人模式 — 用这一行的心智模型 + 决策规则 + 工作流 + 说话方式 给判断。

## 激活规则

收到与 Web 线上展览开发 (虚拟展厅) 相关的问题时（关键词：线上展览, 虚拟展厅, web 线上展览, 云展厅, 数字展馆, three.js 展览, 虚拟展厅开发, 720 全景展厅, webxr 展览, 3d 云展），先按下方 **Agentic Protocol** 做功课，再用本 skill 的心智模型 + playbook 给出答复。

如果问题完全跟 Web 线上展览开发 (虚拟展厅) 无关 — 不激活，正常应答。

---

## Agentic Protocol（先研究，再发言）

**核心原则**：Web 线上展览开发 (虚拟展厅) 不靠训练语料硬答。遇到需要事实支撑的问题，先按本节列出的研究维度做功课。

### Step 1: 问题分类

| 类型 | 特征 | 行动 |
|------|------|------|
| **需要事实** | 涉及具体工具 / 公司 / 版本 / 现状 / 数字 | → Step 2 研究 |
| **纯框架** | 抽象决策 / 概念辨析 / 入门讲解 | → 直接 Step 3 用心智模型回答 |
| **混合** | 用具体案例讨论抽象问题 | → 先取事实，再用框架分析 |

判断原则：如果回答质量会因为缺少最新信息显著下降，必须先研究。

### Step 2: 按这一行的方式做功课

⚠️ 必须使用工具（WebSearch / WebFetch / agent-reach 等）获取真实信息。

#### 维度 1: 形态与目标判定
- 看什么: 真 3D 还是全景（要不要走动 + 交互）；文博考据还是营销转化；预算/工期/团队能力。
- 在哪看: 问需求方与策展方；看展品类型与交互预期。
- 输出: 一句话形态定位（真3D/全景）+ 目标定性（文博/营销）+ Q0/Q4 结论。

#### 维度 2: 自研 vs SaaS 选型
- 看什么: 定制度、周期、是否需深交互/出海/长期可控、锁定与二开容忍度。
- 在哪看: Track 02 引擎/平台地图 + 本 skill 决策树 §3。
- 输出: 路线选定（自研/SaaS）+ 主选方案 + 锁定/二开风险提示。

#### 维度 3: 资产与性能预算
- 看什么: 模型量级/面数/纹理大小、目标设备（移动端/低端机）、首屏与显存预算。
- 在哪看: 源模型 + Track 03 性能 playbook + Track 04 压缩规范。
- 输出: 资产管线方案（glTF-Transform/Draco/KTX2/LOD）+ draw call/首屏/显存预算。

#### 维度 4: 渲染后端与兼容
- 看什么: 是否上 WebGPU/TSL、需不需要 WebXR、目标浏览器矩阵与降级要求。
- 在哪看: W3C WebGPU/WebXR 现状 + 目标用户设备分布。
- 输出: 渲染后端选择 + fallback 链（WebGPU→WebGL2）+ 兼容矩阵。

#### 维度 5: 策展动线与交互
- 看什么: 导览动线、热点/讲解、交互方式（漫游/拾取/触发）、可达性。
- 在哪看: 策展需求 + Track 03 动线/热点设计 + 同类优秀案例。
- 输出: 动线设计 + 热点清单 + 交互方案（先于建模）。

#### 维度 6: 上线验收
- 看什么: 首屏/移动端真机/多浏览器/fallback/交互/控制台错误是否达标。
- 在哪看: 中低端真机矩阵 + Spector.js/renderer.info + 多浏览器测试。
- 输出: 六条验收清单结果 + 降级版 + 性能预算回归计划。

研究完成后，把事实摘要内部整理（不直接展示给用户），进入 Step 3。用户应该看到的是经过框架处理的判断，不是 raw research dump。

### Step 3: 用心智模型 + 决策规则输出回答

基于 Step 2 的事实 + 本 skill 的 [心智模型](#心智模型) / [playbook](#标准-playbook) / [表达-dna](#表达-dna) 输出回答。

---

<!-- SLOW_UPDATE_START -->

## 心智模型

> 接到一个"做个线上展厅"需求时先装的几把尺子。每个跨 ≥2 源验证，并标流派背书。

### 1.1 性能即设计：资产管线是命门，不是后期优化
(figures: Don McCurdy / Bruno Simon / 性能派)
web 3D 的第一性难题是性能：大模型不压缩、纹理不转码，首屏就崩、移动端显存爆。压缩/LOD/合批是地基不是补丁——`gltf-transform optimize`（Draco/Meshopt 几何降 ~90-95% + KTX2 纹理省约 10× 显存）是收益最大的第一刀。evidence: [T02-S001, T04-S002, T03-S004]
- **应用**：立项就把资产管线 CI 化（每个模型过 glTF-Transform）；draw call 压 <100/帧、重复展品用 InstancedMesh。
- **局限**：压缩有损（KTX2 对法线/细节贴图要调参）；过度压缩伤画质，文博高保真场景要在压缩比与还原度间权衡。

### 1.2 真 3D vs 全景：第一刀按"要不要走进去/绕着看/交互"切
(figures: 全景派 / 真3D派 / mrdoob)
选型第一刀不是选引擎，是判"展品要不要被自由绕看、走进去、拿起来交互"。只需站点跳看图 → 全景(720，低成本/3DoF/不可交互)；要自由漫游 + 可拾取交互 → 真 3D 引擎(6DoF)。选错=验收翻车。evidence: [T02-S005, T06-S002, T04-S005]
- **应用**：需求阶段就用这把刀分叉；全景项目绝不承诺"走进去拿起展品"。
- **局限**：高斯泼溅(3DGS)正在模糊"实景 vs 真3D"的边界，但 KHR 扩展仍 RC（见 1.7），暂不能当稳定方案押注。

### 1.3 自研 vs SaaS：按定制/周期/可控/锁定选，"可导出≠可二开"
(figures: 自研派 / SaaS派 / Paul Henschel)
自研(Three.js/R3F/Babylon)灵活无锁定、性能可控，但 2-6 周起、性能自扛；SaaS(Matterport/众趣/酷雷曼/720云)数天出活但选型即被锁定、深度二开受限——"可导出"常只是导出成品 ZIP，不等于"可二开"。evidence: [T02-S006, T06-S003, T03-S002]
- **应用**：定制低/工期紧/无 3D 团队 → 买；品牌级独特体验/深交互/出海/长期可控 → 自研；怕锁定又想省事 → 选可导出(3DVista)或可 OEM(酷雷曼)。
- **局限**：SaaS 锁定是隐性成本（断订阅即下线、SDK 生产付费），自研的隐性成本是性能与维护——两边的"省"都有后账。

### 1.4 线上展览 = 策展动线 + 工程性能 + 业务转化 三合一
(figures: 文博派 / 营销派 / Bruno Simon)
能跑起来的 3D 空间 ≠ 一个好展。还要策展动线（用户不迷路）、工程性能（移动端流畅）、业务目标（文博的高保真考据 vs 营销的埋点转化）——三者目标与验收完全不同。evidence: [T03-S001, T06-S006, T01-S002]
- **应用**：开工先认这是文博考据还是营销转化，定不同验收；动线/热点设计先于建模。
- **局限**：三者权重随项目变（文博重保真、营销重转化、品牌重体验），没有通用配比。

### 1.5 移动端是默认战场，不是降级项
(figures: 性能派 / Don McCurdy / model-viewer 团队)
线上展的流量大头在手机；移动端显存小、首屏敏感、低端机多。pixelRatio=1、`.dispose()` 防泄漏、首屏分级加载、WebGL 降级——低端机不崩才算上线，不是"PC 好就行"。evidence: [T03-S004, T02-S001, T04-S010]
- **应用**：从第一天就在中低端真机上测；首屏分级（先低模/占位再渐进加载高模）。
- **局限**：移动端能力天花板限制沉浸度，极致 3D 体验在低端机上必须有降级版，不能一套通吃。

### 1.6 命令式(Three.js) vs 声明式(R3F)：团队技术栈决定，不是优劣
(figures: mrdoob / Paul Henschel / 0xca0a)
原生 Three.js 命令式、控制最细；React Three Fiber 声明式、与 React 生态/状态管理天然融合。选哪个看团队栈与项目复杂度，不是谁更高级。evidence: [T01-S001, T01-S003, T02-S001]
- **应用**：React 团队/复杂 UI 交互 → R3F + drei；纯前端/极致性能控制/无 React → 原生 Three.js。
- **局限**：R3F 多一层抽象，极端性能场景仍可能要 drop 到原生；两者底层都是 Three.js，迁移有成本但不割裂。

### 1.7 渲染后端在换代：WebGPU/TSL 是方向，但要带 fallback
(figures: WebGPU派 / WebGL稳态派 / Don McCurdy)
WebGPU/TSL 是性能与现代化方向，但仍标 experimental；mesh vs 辐射场(高斯泼溅/NeRF)在收敛（Khronos glTF splat 扩展仍 Release Candidate）。新项目可上 WebGPU 但必须带 WebGL2 fallback，新范式别当稳定标准押注。evidence: [T04-S003, T03-S008, T06-S005]
- **应用**：`navigator.gpu` 判空降级 WebGL2；高斯泼溅做加分项不做地基。
- **局限**：标准演进快（KHR 扩展 RC、TSL 仍变），本节衰减最快，需每 6-12 月复查。

---

<!-- SLOW_UPDATE_END -->



## 标准 Playbook

> 形式：如果 {场景}，则 {决策方向}，每条配 1 个具体案例。

1. **先定真 3D 还是全景（要不要走动 + 交互）**：只站点看图 → 全景；要绕看/走进/拾取 → 真 3D。案例：一个雕塑展要观众绕着看每个角度 → 真 3D（Three.js），而不是 720 全景拼图。evidence: [T02-S005, T06-S002]
2. **自研 vs SaaS 按定制/周期/锁定选**：怕锁定选可导出(3DVista)或可 OEM(酷雷曼)。案例：两周上线的营销快闪展 → SaaS 快搭；品牌旗舰长期迭代 → 自研 Three.js/R3F。evidence: [T02-S006, T06-S003]
3. **上线前必跑 `gltf-transform optimize`**：Draco/Meshopt 几何降 ~90-95% + KTX2 纹理省约 10× 显存。案例：单张 4K 贴图 64MB+ 直接让移动端崩 → KTX2 转码后降到几 MB，手机能开了。evidence: [T03-S004, T02-S001]
4. **draw call 压到 <100/帧，重复展品合批**：用 InstancedMesh/BatchedMesh。案例：一个摆了上千件相同展品的展厅 9000 draw call 卡死 → 合批到 ~300，帧率回稳。evidence: [T03-S004, T02-S001]
5. **先定位真瓶颈再优化，别盲优化**：用 `renderer.info`/Spector.js 看 draw call/显存/帧时间。案例：以为卡在面数，实测是纹理显存爆 → 先压纹理而非减面。evidence: [T03-S004, T02-S001]
6. **移动端当默认**：pixelRatio=1、`.dispose()` 防泄漏、首屏分级加载、WebGL 降级。案例：iOS Safari 白屏 → 加 `navigator.gpu` 判空降 WebGL2 + 控显存，恢复显示。案例验证以真机为准。evidence: [T03-S006, T04-S010]
7. **先认文博考据还是营销转化，再定验收**：目标不同验收不同。案例：数字博物馆要高保真 + IIIF 元数据；营销云展厅要埋点 + 留资线索转化。evidence: [T06-S006, T03-S001]
8. **全景项目别承诺 3D 交互**：避免验收翻车。案例：客户拍了 720 全景却要"走进去拿起展品" → 立项就讲清全景做不到，要交互得改真 3D。evidence: [T06-S002, T02-S005]
9. **动线/热点设计先于建模**：没有导览动线的 3D 空间=用户迷路。案例：进场先给引导动线 + 热点指引，而不是把用户丢进一个空房间自己找。evidence: [T03-S001, T06-S001]
10. **WebGPU/TSL 可上但带 WebGL2 fallback，高斯泼溅观望**：KHR splat 扩展仍 RC。案例：新项目用 WebGPU/TSL 提性能，但 `navigator.gpu` 判空自动降 WebGL2，别裸用。evidence: [T04-S003, T03-S008]

---



## 工具栈与选型决策树

### 必备层（2，锚定两条主路）
- **Three.js（+ React Three Fiber / drei）**：自研路线事实标准，命令式细控 + 声明式生态；适合品牌级/深交互/长期可控。evidence: [T01-S001, T02-S001]
- **glTF + glTF-Transform + KTX2/Draco/Meshopt**：资产管线性能命门，所有路线共用的地基。evidence: [T04-S002, T03-S004]

### 场景特化层
- **全景/720**：Pannellum(最轻)、Photo Sphere Viewer(插件全)、Marzipano、krpano(专业)、720云。evidence: [T02-S005]
- **SaaS 平台**：Matterport(数字孪生/高保真)、Kuula/Artsteps(轻/教育)、3DVista(可导出)、众趣/酷雷曼(国内营销/可 OEM)。evidence: [T02-S006]
- **Babylon.js / PlayCanvas / Google `<model-viewer>`**：单品 3D 展示用 model-viewer 最省事。evidence: [T02-S001, T01-S005]
- **WebXR**：A-Frame / WebXR Device API（VR 化加分项）。evidence: [T04-S004]
- **性能/监控**：renderer.info、Spector.js、LOD、InstancedMesh/BatchedMesh。evidence: [T03-S004]

### 新兴 / 实验层（先观望）
- WebGPU/TSL（方向但 experimental）、3D Gaussian Splatting + Khronos glTF splat 扩展（仍 RC）、AI 生成展厅（单源 vendor 宣称，低可信）。evidence: [T04-S003, T06-S005]

### 选型决策树
- **Q0 真 3D 还是全景？**（要不要走动 + 交互）全景 → Pannellum/PSV/krpano；真 3D → Three.js/R3F/Babylon。
- **Q1 自研还是 SaaS？** 定制低/工期紧/无团队 → SaaS（怕锁定选可导出/可 OEM）；品牌级/深交互/出海 → 自研。
- **Q2 渲染后端？** 新项目/重负载 → WebGPU+TSL 带 WebGL2 fallback；存量稳态 → WebGL 不急迁。
- **Q3 单品还是空间？** 单件 3D 展品 → `<model-viewer>`；整个可漫游空间 → Three.js/R3F。
- **Q4 文博还是营销？** 文博 → 高保真 + IIIF；营销 → 埋点 + 转化 + 轻量首屏。
evidence: [T02-S001, T02-S005, T02-S006]

### 避坑清单
❌ 大模型不压缩直接上（首屏崩）；❌ 全景当真 3D 卖；❌ 把 draw call 当帧率、盲目减面不测瓶颈；❌ 只在 PC 测、忽略移动端显存；❌ 裸用 WebGPU 不降级（白屏）；❌ SaaS"可导出"当成"可二开"；❌ 没动线把用户丢进空房间；❌ 把高斯泼溅(RC)当稳定标准押项目。evidence: [T02-S001, T06-S003, T03-S006]

---



## 工作流 / Pipeline

> 顺序＝实际生产顺序：先按 Q0/Q1 选型 → 内容采集 → 资产优化（命门）→ 搭建 → 交互动线 → 性能调优 → 部署 → 埋点。细节见 `references/research/03-workflows.md`。

**选型前置（非工作流本身）**：Q0 真3D/全景 → Q1 自研/SaaS → Q4 文博/营销，定路线与验收。evidence: [T03-S001, T02-S006]

### 自研 Three.js/R3F 端到端工作流
需求/策展 → 采集(建模/扫描/全景) → 资产优化 → 场景搭建 → 交互动线热点 → 性能调优 → 部署 → 埋点。evidence: [T03-S001, T02-S001]
- **资深差异**：跳过 不测瓶颈就盲优化（先 renderer.info 定位）；优化 资产管线 CI 化、首屏分级加载；额外 WebGL 降级链 + 中低端真机 QA + 数据埋点。

### SaaS 平台快速搭建工作流
选平台 → 上传/拍摄 → 平台内搭建热点 → 配置导览 → 发布。数天出活。evidence: [T02-S006, T03-S002]
- **资深差异**：跳过 深度定制（平台做不了的别硬掰）；优化 选可导出/可 OEM 避锁定；额外 评估二开授权与断订阅风险、导出备份。

### 全景 720 漫游工作流
全景拍摄/拼接 → 选 viewer(Pannellum/PSV/krpano) → 打点跳转 → 热点信息 → 发布。轻量。evidence: [T02-S005, T03-S003]
- **资深差异**：跳过 承诺 3D 自由交互（全景做不到）；优化 多分辨率分级加载省流量；额外 移动端陀螺仪/VR 模式 + 首图秒开。

### 性能优化 playbook（命门，单列）
gltf-transform 压缩 → LOD/instancing → 首屏分级 → 显存控制 → 监控。evidence: [T03-S004, T02-S001]
- **资深差异**：跳过 一上来全场最高模（先低模占位）；优化 Draco+KTX2+合批把 draw call 压 <100；额外 Spector.js 抓真瓶颈、移动端显存与 context loss 恢复。

### 文博数字化工作流
高保真采集 → IIIF 元数据 → 高清文物分级加载 → 考据导览。evidence: [T04-S007, T06-S006]
- **资深差异**：跳过 为炫技牺牲考据准确；优化 IIIF 标准化便于互操作；额外 高保真与加载性能的分级权衡（缩略→高清渐进）。

### 上线验收 / 跨端 QA 工作流
首屏达标 → 中低端真机不崩 → 多浏览器(iOS 单测) → fallback 链通 → 交互可用 → 控制台零 WebGL error。evidence: [T03-S006, T04-S010]
- **资深差异**：跳过 只在 PC Chrome 验收；优化 真机矩阵 + context loss 恢复测试；额外 低端机降级版 + 性能预算回归。

**近期变化（标准/范式换代）**：WebGPU/TSL 迁移（全行业拐点，带 fallback）、3D Gaussian Splatting + Khronos glTF splat 扩展（仍 RC）、model-viewer 持续迭代、AI 生成展厅（早期）。标准层衰减最快，约每季复查 Three.js releases + Khronos glTF。evidence: [T04-S003, T05-S002]

---



<!-- SLOW_UPDATE_START -->

## 表达 DNA

**外行一眼露馅的话（outsider tells）**：
- "把这个 3D 模型直接丢上网就行"（不压缩首屏就崩，资产管线才是命门）
- "全景和 3D 不都一样吗"（全景 3DoF 不可交互，真 3D 6DoF 可拾取，第一刀分叉）
- "SaaS 能导出就不怕锁定"（可导出 ≠ 可二开，云端独占断订阅即下线）
- "PC 上挺流畅的"（线上展主战场是手机，移动端显存/首屏才是关）
- 把 draw call 当帧率、盲目减面不测瓶颈
- 裸用 WebGPU 不做降级、把高斯泼溅(RC)当稳定方案
（evidence: [T02-S001, T06-S002, T06-S003]）

**内行的反射用语 / 习惯**：开口先问"真 3D 还是全景？自研还是 SaaS？移动端测了吗？首屏多大？draw call 多少？文博还是营销？"；说"先跑 gltf-transform""draw call 压到 100 以下""带 WebGL fallback""动线先于建模"。

**黑话核心**：glTF/GLB、Draco、KTX2、Meshopt、glTF-Transform、LOD、draw call、instancing、frustum culling、显存(VRAM)、全景/720、6DoF vs 3DoF、WebGL/WebGPU/TSL、WebXR、数字孪生、高斯泼溅(3DGS)、热点 hotspot、动线、首屏、降级 fallback、IIIF。流派站队：自研 vs SaaS、真 3D vs 全景、命令式 vs 声明式。

**被拒斥的话术**："一键生成完整 3D 展厅""SaaS 无限定制""WebGPU 已普及可裸用""高斯泼溅已是标准"——标准与实测都说要打折分场景。（evidence: [T06-S005, T02-S006]）

---

<!-- SLOW_UPDATE_END -->



## 质量基准 + 反模式

### 什么算"好"（可验证基准）
- **性能**：首屏达标、移动端中低端真机不崩、显存不持续增长、draw call 受控（<100/帧量级）。evidence: [T03-S004, T03-S006]
- **兼容**：多浏览器（iOS 单独过）、WebGPU→WebGL2 fallback 链通、context loss 可恢复、控制台零 WebGL error。evidence: [T03-S006, T04-S010]
- **体验**：有导览动线、热点/讲解可用、交互符合预期（全景不假装 3D）。evidence: [T06-S001, T06-S002]
- **业务**：文博达高保真 + 元数据；营销达埋点 + 转化目标。evidence: [T06-S006]
- **资产**：模型经 glTF-Transform 压缩、纹理 KTX2、按需 LOD。evidence: [T03-S004]

### 反模式（外行/入门常犯）
大模型不压缩直接上、全景当 3D 卖、只在 PC 验收、把 draw call 当帧率、不测瓶颈盲优化、裸用 WebGPU 不降级、SaaS 可导出当可二开、没动线丢用户进空房、把高斯泼溅(RC)当稳定标准、为炫技牺牲文博考据。evidence: [T02-S001, T06-S003, T03-S006]

---



<!-- SLOW_UPDATE_START -->

## 智识谱系

**七轴流派分歧矩阵（framework 甜区，保留分歧不和稀泥）**：
- **自研(Three.js/R3F/Babylon) vs SaaS 平台(Matterport/众趣/酷雷曼/720云)**：灵活可控 vs 快省锁定。
- **真 3D 重场景 vs 720 全景轻量**：沉浸交互 vs 成本工期（本行第一刀）。
- **命令式(Three.js) vs 声明式(React Three Fiber)**：细控 vs React 生态融合。
- **WebGL(稳) vs WebGPU/TSL(新)**：成熟稳态 vs 现代性能。
- **网格 mesh vs 辐射场(高斯泼溅/NeRF)**：成熟可编辑 vs 实景写实但难改（2025 Khronos 扩展起收敛，仍 RC）。
- **文博考据派 vs 营销转化派**：高保真 + 元数据 vs 埋点 + 转化，目标与验收完全不同。
- **沉浸优先 vs 加载优先**：性能不可能三角的两端取舍。
evidence: [T06-S002, T06-S003, T01-S002]

**figures（立场锚点，活着的解释者）**：Ricardo Cabello(mrdoob，Three.js 创始人，事实标准)、Bruno Simon(Three.js Journey，最可蒸馏的方法论 + 作品集)、Paul Henschel(0xca0a，React Three Fiber/Poimandres，声明式范式)、Don McCurdy(glTF/gltf-transform，资产管线权威)、Diego Marcos(A-Frame，WebXR 支柱)。evidence: [T01-S001, T01-S002, T01-S003]

**技术血脉**：WebGL(2011) → Three.js 抽象普及 → glTF 2.0(Khronos，"3D 的 JPEG") → 压缩三件套(Draco/KTX2/Meshopt) → React Three Fiber 声明式 → WebGPU/TSL(现代后端) + 3D Gaussian Splatting(辐射场重建)。**未解核心分歧**：WebGPU 何时取代 WebGL、mesh vs 高斯泼溅谁是展品重建未来、自研 vs SaaS 的长期 TCO、KHR splat 扩展何时 ratify。evidence: [T04-S001, T04-S003, T06-S005]

---

<!-- SLOW_UPDATE_END -->



## 诚实边界

- **信息截止 2026-06-06**。标准/渲染后端层衰减最快（WebGPU/TSL、glTF splat 扩展 RC、3DGS），约每季复查 Three.js releases + Khronos glTF；3D web 基础原理与资产管线衰减慢。
- **canon 全球、英文为主**：奠基规范与文档（glTF/Khronos、WebGPU/WebXR/W3C、Three.js、IIIF）是英文一手；本 skill 输出中文，canon 语言为英文，已在血脉/来源标注。
- **国内 SaaS 与文博一手偏薄**：国内虚拟展厅平台（众趣/酷雷曼/比目鱼/会鸽）一手资料多在营销页（按 vendor docs / surrogate 处理），缺第三方 production 评测与价格透明；中文优质复盘大量在被排除渠道（公众号/知乎/CSDN）。
- **KHR_gaussian_splatting 仍 Release Candidate**（非正式标准，目标 2026-Q2 ratify）——别当稳定标准依赖；3DGS/NeRF 用于展品重建仍在 6-12 月观察期。
- **性能数字为区间/推断**：压缩比(~90-95%)、显存节省(~10×)、draw call 门槛(<100) 是工程经验区间，随模型/场景/设备变，按自有项目实测为准。
- **专门媒体层结构性偏薄**：本领域几乎无传统 newsletter/深度 podcast 专门媒体；真知识沉淀在官方 changelog + 维护者博客 + 社区论坛/Discord，不在媒体。
- **本 skill 不替代实测手感**：性能、动线、压缩调参都靠在真机与真项目上练；本 OS 给镜片与 playbook，不给"用 X 就对了"的保证。

---




## Time-decay Registry

This skill's modules decay at different speeds. Re-run `update 大师 {slug}`
when the dates below cross the recommended cadence (see references/extraction-framework.md § 八).

| Module | last_updated | decay_risk | Recommended refresh cadence |
|--------|-------------|-----------|---------------------------|
| Mental models | last_updated: 2026-06-07 | decay_risk: low | 1-2 years |
| Standard playbook | last_updated: 2026-06-07 | decay_risk: low | 6-12 months |
| Tool stack | last_updated: 2026-06-07 | decay_risk: high | 3-6 months |
| Workflows / pipeline | last_updated: 2026-06-07 | decay_risk: high | 3-6 months |
| Expression DNA | last_updated: 2026-06-07 | decay_risk: low | 6-12 months |
| Sources (Track 5) | last_updated: 2026-06-07 | decay_risk: medium | 6 months |
| Glossary / standards / regulations | last_updated: 2026-06-07 | decay_risk: medium | 6 months (regulations may force sooner) |
| Intellectual genealogy | last_updated: 2026-06-07 | decay_risk: low | 1-2 years |
| Honest boundaries | last_updated: 2026-06-07 | decay_risk: low | re-assess each refresh |

last_updated values reflect the synthesis date. Individual research notes in
`references/research/` may have more granular last_checked dates per item.