“我们需要一个 AR 应用”通常是错误的起点
几乎每一个 AR 项目启动时都带着同一个假设：这必须做成一个应用。有时这个假设是对的。但更多时候并非如此，而“必须先安装”这一要求，恰恰会在任何人看到体验之前就把它扼杀掉。
真正的问题不是“要不要做成应用”，而是用户究竟是如何接触到这个体验的，以及要求他们先安装点什么，能不能经受住那一刻的考验。
没人算过的“安装摩擦”账
如果用户是通过广告、包装上的二维码、展会展板或社交媒体帖子发现你的 AR 体验的，那么真实的转化路径是这样的：看到、想尝试、跳转到应用商店下载页面——然后，绝大多数人会在这一 步直接放弃。靠“发现”驱动的 AR 体验如果需要先安装应用，往往在真正的体验加载出来之前，就已经流失了大部分用户。
WebXR 以及 8th Wall 这类工具解决的正是这个问题：直接在浏览器里运行 AR，通过链接或二维码启动，无需安装，几秒钟就能跑起来。对于产品试用活动、展会演示，或者任何核心诉求是“无论你在哪里，现在就想试一试”的场景，去掉安装这一步不是锦上添花，而是决定用户会不会真正尝试、还是直接划走的关键。
原生 AR 真正的优势场景
用 ARKit 和 ARCore 在完整应用中构建的原生 AR，在以下几种情况下，额外的复杂度是值得的：
用户已经经常使用这个应用。 家具零售商的购物应用、人们每次装修都会用到的家装应用——AR 试用功能是叠加在已有关系之上的能力，而不是为了看一件商品就要求用户专门安装。
需要跨会话保持的追踪能力。 记住虚拟物体摆放位置的房间级锚点、需要在多次访问中保持精度的测量数据——这些都需要更深层的系统集成，而浏览器沙箱做不到这一点。
需要特定硬件能力。 新款 iPhone 上的 LiDAR 深度感应、精确的遮挡效果（让虚拟物体正确地被真实物体挡住），或是 Meta Quest 上的手部追踪，在浏览器环境下要么无法使用，要么效果大打折扣。如果体验依赖这种精细度，原生开发就是唯一的选择。
确定平台之后，如何选择引擎
对于移动游戏、轻量 AR 以及大多数跨平台项目，Unity 6 是默认之选——工具链成熟，设备支持广泛，AR SDK 插件生态也很丰富。当画面精度本身就是核心诉求时——高端 3D 展示、电影级产品可视化，任何品牌调性直接体现在渲染质量上的场景——Unreal Engine 5 更有优势。而如果要在浏览器里做到无需安装、即点即用，Three.js 和 WebXR 能覆盖交互式 3D 和 AR 的需求，让体验只差“一次点击”，而不是“一次下载”。
Apple Vision Pro 和 Meta Quest 属于另一个类别：原生 visionOS/RealityKit 应用和 Quest 原生构建，适用于手机屏幕或浏览器标签页无法复制的、真正沉浸式的房间级体验——培训模拟、空间设计评审，任何核心在于“置身其中”而非“隔着屏幕看”的场景。
在下决定之前，做一个简单的测试
只问一个问题：这个体验会被人从广告或链接中偶然遇到、并需要在短时间内做决定，还是会成为已经打开你应用的用户会反复使用的功能？偶发且需要快速决策 → 选择 WebXR，不要安装，把“看到”和“尝试”之间的每一个摩擦点都去掉。高频且属于应用内功能 → 把它构建进用户已经信任的原生体验里。
AR 项目中最常见、也最昂贵的错误，就是把这个判断做反了：为一场本该零摩擦的一次性营销活动开发了完整的原生应用，或者为一个本该持久留存、并与用户每天使用的应用集成的功能，做成了一个浏览器演示。
大致费用
一款轻量移动游戏或品牌 AR 体验——无论是 WebXR 还是原生方案——起步价通常在 $15,000 左右。多人 3D 游戏和完整的 VR 项目，由于需要额外开发网络同步、物理引擎以及针对头显的专项优化，起步价则为 $50,000+。
结论
不要默认“就做一个应用”。默认先去问用户究竟是如何接触到这个体验的，再让答案决定技术平台。我们的游戏、AR 与 VR团队会根据你的目标受众实际的接触方式——而不是哪个平台在提案里听起来更炫——来确定引擎和交付方式：WebXR、原生移动应用，还是 Vision Pro/Quest 构建。
