简介：这是从虚拟现实、增强现实到混合现实演进脉络的PPT课件，面向信息技术、新媒体艺术、数字媒体等方向的师生与从业者，用于理解三者核心概念、差异及产业应用。内容参考黄鸣奋相关论述，从VR的沉浸性、交互性与想象性切入，介绍了数据手套、头盔显示器、CAVE等虚拟现实形态，也举例说明艺术创作中的VR实践；随后讲述AR依靠叠加数据层增强用户对物理世界的感知，覆盖导航、教育、游戏等场景；最后阐明MR融合现实与虚拟、可实现双向互动的特点，并关联科幻作品、主题公园与数字娱乐的发展趋势。压缩包内仅1个pptx文件，大小约276KB，页面组织紧凑，适合作为课程辅助讲义、行业科普或技术分享底稿。目前已有86人学习下载，方便快速了解VR/AR/MR的全貌，并可直接在此基础上继续编辑或摘取所需部分用于汇报展示。
1. 从增强现实到混合现实：这份 PPTX 到底在讲什么
一份名为「从增强现实到混合现实介绍24.pptx」的课件，通常不是一份简单的技术科普，而是一张技术选型与认知升级的路线图。做 AR 的人会告诉你增强现实是把虚拟信息叠加到真实世界上，做 MR 的人则会纠正你：混合现实要求虚拟物体能感知真实空间、能跟你产生遮挡关系和因果交互，而不是悬浮在屏幕上的贴纸。这个差异看起来是名词之争，落到项目立项、硬件选型和交互设计上，就是完全不同的两套方案。我从 2017 年开始接 AR 相关的可视化项目，到 2020 年后几乎每个客户都在问能不能做成 MR，这中间踩过的坑、推翻过的原型，基本都能浓缩进这样一份 PPTX 里。这篇笔记想讲清楚的只有一件事：当你拿到一份讲 AR 到 MR 的 PPTX 时，该怎么读、怎么用、怎么把它拆成一个能落地执行的技术方案。
2. AR 与 MR 的概念分界线：四个判定维度与实际选型
2.1 空间锚定能力：贴纸和物体的本质区别
判断一个方案到底是 AR 还是 MR，我一般不看宣传物料，先看它的空间锚定能力。AR 时代的典型形态是手机屏幕上的虚拟物体，它通过图像识别或平面检测放在一个位置上，你转动手机，虚拟物体相对屏幕的位置会变，但它并不真正“知道”自己在这个房间里的三维坐标。MR 的核心差异是空间锚定：虚拟物体必须能建立一个持久的、与世界坐标系绑定的位置关系，你绕着它走，它的位置、朝向、尺度都保持稳定，甚至关掉设备再打开，它还能被恢复到之前安放的坐标点。
这个能力直接决定了你能做什么类型的应用。做家具摆放类应用，平面检测加粗略的锚点就够用，手机 AR 能应付大部分场景。做工业维修指导，你需要虚拟的管线走向叠加在真实的设备上，如果锚定漂移超过两厘米，操作人员就会看错螺丝位置。这类场景下，ARKit 和 ARCore 自带的 world tracking 已经提供了基础能力，但真正要扛住长时间、大范围的使用，还是要用到 SLAM 的置信度评估和重定位机制。我在做配电柜巡检项目时，最初用的是单目视觉 SLAM，设备启动后需要扫一圈环境才能建立初始地图，后来换成带深度传感器的设备，初始化速度和稳定性都有明显提升。
技术选型时不要被“支持 AR”这个词迷惑。你需要在需求文档里写明锚定精度、重定位速度和可接受漂移范围，再拿这些参数去对设备。一般移动端 AR 能满足厘米级即时锚定，但重定位需要几秒时间；光学 See-through 的 MR 头显走的是另一种技术路线，锚定依赖头显侧的红外相机和重力传感器，对暗环境非常敏感。方案评审阶段，用一张表把锚定方式和指标列清楚，能避免后期大量返工。
2.2 虚实遮挡与深度感知：为什么虚拟物体会“穿模”
第二个分界线是遮挡关系。增强现实的典型问题是虚拟物体永远浮在真实物体上面，哪怕它应该藏在桌子后面，屏幕上也照样显示。因为手机 AR 只做了平面检测，没有实时深度信息，无法判断真实物体的三维轮廓。混合现实要求虚拟物体和真实物体互为前后景，虚拟角色能从门框后面探出头来，地上的虚拟箭头能被真实的柱子挡住一半。要做到这一点，设备必须获取环境的深度数据。
移动端现在的通行做法是 ARKit 的 scene reconstruction 和 ARCore 的 depth API，通过 RGB 图像和运动信息估计深度，生成一个实时更新的网格网格。用这个网格就能做遮挡渲染。实际跑下来，这种估计深度在纹理丰富的环境里效果不错，但遇到白墙、玻璃、暗光环境就容易翻车。如果你做的是展厅、商场这类受控环境，可以在场地里放置标记物来辅助深度估计。做头显 MR 方案，设备自带深度传感器，遮挡是原生能力，不需要开发者额外处理，但视角和焦平面的差异仍然会带来视觉不适感。我在测试 HoloLens 类设备的遮挡效果时发现，近距离物体遮挡远距离虚拟物体自然，反过来虚拟物体在近处、真实物体在远处时，人眼会明显感觉到对焦冲突，这个阶段只能调整内容放置的距离来缓解。
2.3 交互回路：单向展示还是双向因果
AR 到 MR 的第三个跨越在交互回路。手机 AR 的交互基本是单向的：用户点击屏幕触发虚拟内容的变化，虚拟内容不会反过来理解你的行为。MR 要求双向因果——你走了一步，虚拟角色要让开一条路；你伸手去握，虚拟开关要能感知手的位置并响应。这里的技术关键是手部追踪和空间理解。
移动端 AR 可以用 ARKit 的手部骨骼识别来做有限的手势，但它的追踪是基于摄像头图像的，手离开视场就丢失。MR 头显这边，典型设备会配备红外摄像头专门做手的骨架跟踪，能够持续追踪手指关节。开发时要注意手势识别的置信度阈值，设得太高用户要反复做动作才能触发，设得太低容易误触。我做功能对比 PPT 时，会专门留一页给交互回路的对比：AR 是 Tap + Drag，MR 是 Grasp + Release + Pinch，交互维度的变化意味着整个交互设计规范都要重写。这也是为什么很多做 AR 应用出身的团队切到 MR 后要花很大精力做手势定义和用户引导，不是技术难，是交互范式的迁移不简单。
2.4 环境理解能力：从识别平面到理解语义
最后一个维度是环境理解。传统 AR 可以识别平面、识别图像目标，把虚拟内容放在桌上或墙上。MR 在环境理解上走得更深，要求系统理解房间的结构语义——这是门、那是窗、地面是硬质还是软质、房间边界在哪，甚至能分析出物体的类别。有了语义信息，虚拟内容才能符合物理直觉地安置：虚拟标尺不会穿透墙面，虚拟家具不会悬在半空。
目前业界的落地方式有两种。一种是在设备端跑轻量化神经网络做语义分割，比如把桌面、地面、墙面分出来，这种方式延迟低，但类别有限。另一种是云端推理加空间数据库，识别精度高，但要考虑网络延迟和隐私合规，不适合在工业现场用。做方案选型时，我建议先列出应用场景必须理解的环境元素清单。比如做会议室设计评审，只需要理解墙面和地面；做手术导航辅助，需要理解人体解剖结构，这就是另一个量级的技术储备。你拿到的 PPTX 如果只讲概念，你在心里也要补上这一层环境理解的评估，否则很容易被概念演示糊弄过去。
3. 把 AR/MR 技术体系做成一份可复用的 PPTX：脚本化生成工作流
3.1 页面信息架构：每个技术点对应一页，别堆在一页里
拿到「从增强现实到混合现实介绍24.pptx」这个标题，大多数人的第一反应是打开 PowerPoint 手动编辑。但实际做技术方案讲解的人会告诉你，PPTX 可以当成一种结构化的技术文档来管理和复用，尤其是内容涉及大量截图、参数表和版本迭代时，靠手动维护页面效率太低。我自己做技术方案 PPT 时，会先拆信息架构，把每一页当成一个接口来规划，再写脚本批量生成，页面布局、配色、字体由模板统一控制，需要更新数据时改一个数据源文件重新生成就行。
信息架构的拆法可以按标题里的逻辑链路走：先说增强现实和混合现实的现状，再讲技术分水岭，然后分几个方向展开支撑技术，最后落到行业应用和选型建议。这样一个「背景→分界→技术→场景→选型」的五段式结构，配合每页一个主题点的原则，能保证听讲的人不会被复杂信息淹没。我做过的几版方案 PPT 里，最容易出问题的是把空间锚定、遮挡、交互和环境理解四个维度全放到一页讲，听众记不住，讲的人也容易发散。拆成四页，每页配一张示意图、一段简洁说明、一个典型设备或 SDK 例子，效果明显好得多。
3.2 用 python-pptx 自动生成基础页面
手动编辑可以做精调，但批量生成框架页更适合用代码。我常用 python-pptx 来做这件事，先把每页的标题、正文、图片位、备注位定义成结构化数据，再循环渲染。这样做的好处是一份 PPTX 可以持续演进，不需要每次从空白页开始。
下面是一个简化但完整的生成脚本示例，它创建一份带封面页和内容页的 PPTX，并为内容页预留图片位置：
from pptx import Presentation from pptx.util import Inches, Pt from pptx.dml.color import RGBColor # 创建演示文稿对象 prs = Presentation() # 设置标准 16:9 宽度，单位是英寸 prs.slide_width = Inches(13.333) prs.slide_height = Inches(7.5) # 使用空白版式，避免自动生成多余占位符 blank_layout = prs.slide_layouts[6] title_layout = prs.slide_layouts[0] # 标题版式，仅用于封面页 # 封面页 cover = prs.slides.add_slide(title_layout) cover_title = cover.shapes.title cover_title.text = "从增强现实到混合现实：技术演进路线" cover_title.text_frame.paragraphs[0].font.size = Pt(36) cover_title.text_frame.paragraphs[0].font.bold = True subtitle = cover.placeholders[1] subtitle.text = "概念分界 / 关键技术 / 选型建议 / 落地路径" # 定义内容页数据：标题 + 要点 + 图片占位说明 pages = [ { "title": "空间锚定：从屏幕定位到世界坐标", "points": ["移动端 AR 依赖平面检测", "MR 使用 SLAM 建立持久空间地图"], "pic": "anchor_compare.png", }, { "title": "虚实遮挡：深度感知带来的真实性跃迁", "points": ["RGB 估计深度在暗光下不可靠", "头显深度传感器原生支持遮挡"], "pic": "occlusion_depth.png", }, { "title": "交互回路：从点击到抓取", "points": ["手部追踪需要红外相机支持", "手势阈值设置影响误触率"], "pic": "interaction_loop.png", }, ] for page in pages: slide = prs.slides.add_slide(blank_layout) # 在统一位置添加标题框 title_box = slide.shapes.add_textbox( Inches(0.5), Inches(0.3), Inches(12), Inches(0.8) ) title_frame = title_box.text_frame title_frame.text = page["title"] title_frame.paragraphs[0].font.size = Pt(28) title_frame.paragraphs[0].font.bold = True # 在统一位置添加要点列表 body_box = slide.shapes.add_textbox( Inches(0.5), Inches(1.3), Inches(6), Inches(5) ) body_frame = body_box.text_frame body_frame.word_wrap = True for idx, point in enumerate(page["points"]): if idx == 0: p = body_frame.paragraphs[0] else: p = body_frame.add_paragraph() p.text = f"• {point}" p.font.size = Pt(18) # 在页面右侧预留图片位置，后续人工替换 pic_placeholder = slide.shapes.add_textbox( Inches(7.0), Inches(1.3), Inches(5.5), Inches(5) ) pic_placeholder.text_frame.text = f"[ 图片占位：{page['pic']} ]" pic_placeholder.text_frame.paragraphs[0].font.color.rgb = RGBColor(0x99, 0x99, 0x99) # 保存文件 prs.save("ar_mr_overview.pptx") print("已生成 ar_mr_overview.pptx，共", len(prs.slides.__iter__().__length_hint__()), "页")脚本的逻辑是从一个结构化的页面列表出发，逐页创建标题框、正文框和图片占位框。它的核心价值在于把「内容」和「呈现」分开。参数Inches()控制元素的位置和大小，13.333 英寸宽度对应标准的 16:9 投影比例。blank_layout = prs.slide_layouts[6]选择了白板版式，避免幻灯片自带的多余样式干扰后续设计。要点列表的word_wrap = True能保证长文本自动换行，避免文字溢出页面。最后的打印语句会输出生成的总页数，你可以据此核对页面数量是否符合预期。
3.3 从脚本到完稿：人工精调的部分
脚本生成的是骨架页，真正的技术方案 PPT 还需要人工处理三个部分。首先是截图与示意图，锚定对比、深度网格、手部追踪效果这类内容必须用真实截图或标注过的示意图，脚本只需占位；其次是参数表，比如 SDK 支持矩阵、设备锚定精度对比，这类数据最好做成独立表格再导入，不要写在代码里硬编码；最后是讲稿备注，每页的演讲者备注注是你在讲台上要说的核心逻辑链，脚本不会自动生成有价值的备注内容。
我在推荐这套工作流时，很多同事不认可，觉得写脚本比自己拖文本框更费时。但真实情况是：方案类的 PPT 往往一周之内要改三四版，手动改文本框的位置、字体、配色非常消耗耐心，而且容易漏改。脚本化的思路让你只维护一份页面数据源，改标题、改要点、增删页面都在数据层面完成，整体重生成即可。这种模式尤其适合要做成「系列课件」的场景——同样的 AR/VR/MR 框架，换数据、换截图，就能快速产出面向不同客户的不同版本，是实际做售前方案时非常实用的效率工具。
4. 从 PPTX 到可交互原型：概念验证阶段的工程路径
4.1 移动端 MR 能力验证：Unity + AR Foundation 的选型逻辑
PPTX 里的技术能力描述得再清晰，最终要被业务方信任，通常需要跑一个可交互的原型。我习惯从移动端开始做验证，不是因为手机是目标平台，而是因为它是成本最低的 MR 能力试验场。用 Unity 2019 LTS 以上版本配合 AR Foundation 4.x，可以在 iOS 和 Android 上统一使用 ARKit、ARCore 的能力，包括平面检测、锚点追踪、光照估计和部分深度感知。
选择 AR Foundation 而不是直接写 ARKit/ARCore 原生代码，原因是它的抽象层能屏蔽平台差异。同一个 C# 脚本，构建 iOS 和 Android 时分别绑定到原生 SDK，不需要维护两套代码。这个抽象带来的代价是部分高级功能无法直接在同一套 API 里使用，比如 ARKit 的人脸跟踪和 ARCore 的场景网格在 API 设计上就不完全对齐，此时需要用#if UNITY_IOS这种平台宏分写逻辑。如果只是验证空间锚定和遮挡渲染的基础效果，AR Foundation 的默认 API 足够用。
4.2 一个最小可跑的锚定演示脚本
光说不练没有说服力，我提供一个最小可跑的 Unity 锚定演示脚本，它能在检测到平面的地方放置一个虚拟立方体，并保持相对世界坐标的稳定。在 Unity 中新建场景，挂载 AR Session 和 AR Session Origin 后，把这个脚本挂到空物体上：
using UnityEngine; using UnityEngine.XR.ARFoundation; using UnityEngine.XR.ARSubsystems; public class MinimalAnchorDemo : MonoBehaviour { public GameObject cubePrefab; // 在 Inspector 中指定一个带 MeshFilter 的立方体 private ARRaycastManager raycastManager; private ARPlaneManager planeManager; void Awake() { raycastManager = GetComponent<ARRaycastManager>(); planeManager = GetComponent<ARPlaneManager>(); } void Update() { // 单指触摸：在屏幕点击位置向真实世界发射射线 if (Input.touchCount == 1 && Input.GetTouch(0).phase == TouchPhase.Began) { Touch touch = Input.GetTouch(0); PlaceObject(touch.position); } } void PlaceObject(Vector2 screenPos) { List<ARRaycastHit> hits = new List<ARRaycastHit>(); // 只检测平面，避免在无特征点区域误放置 if (raycastManager.Raycast(screenPos, hits, TrackableType.PlaneWithinPolygon)) { Pose hitPose = hits[0].pose; // 在射线命中位置生成立方体，同时继承平面的旋转 GameObject go = Instantiate(cubePrefab, hitPose.position, hitPose.rotation); // 将物体固定为平面的子物体，跟随平面移动，做持久锚定 ARPlane plane = planeManager.GetPlane(hits[0].trackableId); if (plane != null) go.transform.SetParent(plane.transform); } } }脚本的关键逻辑在PlaceObject方法里。Raycast的最后一个参数TrackableType.PlaneWithinPolygon表示只在平面多边形内部放置物体，避免在平面边界外悬空生成。命中后取hits[0]的位姿作为放置点。最后的SetParent(plane.transform)是容易被人忽略的一步：把虚拟物体挂到平面对象的变换层级下，平面在后续帧被优化调整时，物体会跟随平面一起移动，这样锚定才不会漂移。如果省略这一步，物体只放在初始位置，AR Core/ARKit 后续对平面位置的精修会导致物体与平面出现偏移。
这个原型可以在手机上验证一个核心问题：虚拟物体是否稳定地“长”在真实世界的桌面上。你围着桌子走，物体不会滑动；放下手机再拿起来，物体仍然在大致位置。如果你的目标是做 MR 头显方案，这同样是一个有效的预验证步骤，因为头显的空间锚定也是同样的世界坐标系逻辑，区别只在于交互输入从触摸变成了手势。
4.3 从手机验证到设备移植的注意点
手机上的锚定验证通过后，移植到头显设备时有三类差异需要关注。第一是坐标系与单位，Unity 场景的全局坐标系在不同设备上方位定义可能不同，移植后需要确认物体的默认朝向是否和真实世界对齐。第二是性能预算，头显渲染的屏幕分辨率虽然不算极高，但需要双通道渲染，再加上环境透视的视频流叠加，GPU 压力是手机的 1.5 到 2 倍，模型面数和透明材质数量要主动降低。第三是交互重构，手机端的触摸事件要改为手势识别事件，事件触发阈值需要重新标定。
这些差异听起来不大，但每一个都能让你在适配阶段多花一两周。所以如果初始目标就是头显设备，我反而建议直接拿头显设备来做第一步验证，而不是先在手机上打磨再移植。手机验证更适合验证「内容逻辑是否成立」，设备验证更适合验证「交互体验是否顺畅」。PPTX 里写技术路线时，你完全可以把这两步分开描述，不做多余承诺。
5. 做 AR/MR 概念及演示方案，最容易踩的五个坑
5.1 把 MR 讲成了「更高级的 AR」，导致客户预期错位
现象：方案对客户讲的是混合现实，演示时用的却是手机 AR 的录屏。客户看完觉得「这不就是个 AR 应用吗」，对 MR 的价值产生质疑，甚至觉得你们和市面上的 AR 拍照小程序没有区别。
原因：手机 AR 的视频录屏天然只有叠加效果，没有遮挡和空间交互这些 MR 关键特征，客户无法从二维屏幕感受三维的空间一致性。这是展示媒介造成的认知落差，不是技术本身的问题。
解决：任何对外演示的 MR 素材，都要包含一段「人物拿着设备在房间里走动，虚拟物体固定不动」的实拍画面，突出虚拟物体被真实物体遮挡、或者用户伸手与虚拟物体互动的段落。你要让观众通过屏幕看到空间关系的变化，而不是看到静止的叠加画面。我在所有 MR 相关 PPTX 里都放一条铁律：演示视频必须拍到人的手和脚，让观众以第三人称视角感受到那个「混合空间」。
5.2 锚定测试只做一个位置，换环境就漂移
现象：头显或手机 demo 在办公室的一角效果很好，拿到客户现场的大厅就出现虚拟物体滑动、跳动甚至错位。
原因：SLAM 依赖环境特征点。实验室环境里通常有大量纹理和固定物体，现场大厅可能有大面积白墙、玻璃幕墙和空旷地面，特征稀疏，追踪质量不高。另一个因素是光照，现场灯光频闪或强烈直射会干扰相机曝光。
解决：现场布置时主动制造视觉特征。在空旷区域放一些高对比度、带纹理的立牌或地贴，作为跟踪锚点；投射灯下要布暗色地毯减少过曝。同时在代码里增加追踪质量监控接口，实时获取TrackingState.Relocalizing状态，当追踪丢失时提示用户重新扫描环境，而不是假装稳定运行。
5.3 深度估计的「玄学」：看起来一样的两个设备，遮挡效果差异很大
现象：两个同样支持 AR 的手机，用同一个 App 做遮挡 demo，一部设备能正确隐藏被桌面挡住的虚拟物体，另一部直接穿透显示在桌面上方。
原因：遮挡效果依赖设备端的深度估计能力。只有带 ToF 或结构光的设备能拿到硬件级深度，纯软件方案需要持续运动才能估计出深度，静止时深度图是空的，遮挡效果缺失。不同芯片平台的深度 API 实现也不一样，部分中端机干脆不支持深度 API。
解决：在需求文档里写清楚「遮挡能力依赖硬件深度传感器」，不要写「支持遮挡」这样模糊的描述。测试时至少选三台不同档次的设备做遮挡专项验证，拿到的结论才能写进 PPTX。对于纯软件方案，除了提示用户移动设备让深度收敛，没有太好的补救办法，这也是硬件选型时要把 ToF 列为必需项的最直接理由。
5.4 忽略了人的视场角，把内容放到看不见的地方
现象：MR 演示视频里，虚拟物体明明在人的正前方偏左 30 度，视频里却看不到，变成对着空气比划的尴尬画面。
原因：手机 AR 的显示区域就是屏幕，视场角与摄像头一致，不存在这个问题。头显 MR 设备的可视视场角普遍偏窄，光学透视式头显通常只有 40 到 60 度，人眼余光区域是看不到虚拟内容的。内容设计者如果不理解这个限制，会把关键信息放到屏幕边缘外。
解决：做交互设计时，把关键操作和视觉提示放在画面中心 30 度范围内，重要信息要跟随视线中心。另一个常用做法是加入视线引导机制，当虚拟物体不在视场内时，在视场边缘显示一个方向指示箭头，引导用户转头。这个细节在 PPTX 里最好单独提一页，因为它直接反映团队是否真正用过 MR 设备，是评审时一个很好的加分点。
5.5 只演示最优光线和空间，没有准备 B 方案
现象：现场演示的灯光一暗，追踪丢失，demo 彻底白屏，讲稿讲不下去。
原因：设备在弱光环境下无法获取足够的视觉特征进行追踪。演示时往往只准备了内容，没有为环境失效做备用方案。
解决：任何现场演示都要准备一套离线渲染的视频兜底。追踪正常时演示实时交互内容，一旦设备追踪丢失，无缝切换到预先录好的彩排视频，保证讲解节奏不被打断。同时把追踪丢失的画面做成正常的转场，而不是直接白屏，客户看不出这是事故，只看到你在切换内容。这套流程我在多次展会演示中验证过，确实是救命的方案。
6. 从概念到可信投入：用「最小对抗测试」验证一份 AR/MR 方案的成色
一份 PPTX 能不能经得住推敲，最终取决于你有没有做过「最小对抗测试」。这个方法是我做技术选型时养成的习惯：拿到任意一份技术方案材料，先找出它最核心、最不寻常的 3 个论断，然后设计 3 个测试去尝试推翻它们。空间锚定不是「支持」就完事，你要在 8 米距离走一圈看漂移多少；遮挡不是「有深度图」就成立，你要拍一段暗光环境的遮挡效果视频。对抗测试做下来，方案里哪些是真实的工程结论，哪些是宣传话术，一眼就能分辨。
我最开始做 MR 方案评审时吃过亏。有一份从别处流转来的演示 PPT，看起来技术链条完整，各种图表数据都齐备，直到去现场测试才发现它依赖的深度 API 在目标设备上根本没实现，说白了就是一个「概念完整但工程不可用」的片子。后来我给自己定了规矩：任何新的 MR 方案，必须在自己手里过一遍「拍摄真实环境测试视频→检查关键指标数值→亲手做一次交互体验」三件套，哪怕只花一两天时间，也比事后推翻方案损失小得多。这个方法被我用在每次拿到新方案、新 SDK 甚至新硬件时，也推荐给你。如果你是带着具体需求来了解 AR 和 MR 的读者，希望这份拆解能帮你少走一些弯路，希望帮到你。
本文还有配套的精品资源，点击获取
