轻量级WebAR贺卡开发实战：离线、低门槛、高可用

1. 项目概述：当贺卡从纸面“跳”进现实空间

“Reinventing Greeting Cards Through Augmented Reality”——这个标题不是一句空泛的科技口号，而是我过去18个月里亲手打磨、反复迭代、最终在三场本地手作市集和两家独立书店落地验证的真实项目。它讲的不是把一张普通贺卡拍个照再加个滤镜，而是让祝福真正“活”起来：你举起手机对准卡片上一朵手绘的樱花，花瓣便簌簌飘落，在你掌心上方半米处悬停、旋转；翻到背面，一段亲笔写的生日祝福文字自动浮空展开，字迹随你转动手机微微倾斜，像被微风托着；最绝的是，收卡人还能点击右下角那个极小的AR图标，调出一个30秒的语音留言——声音来自送卡人当天清晨录下的、带着咖啡香气的即兴祝福。这背后没有用Unity做重型引擎，没接入任何公有云AR平台，整套方案跑在一台2019款iPad Air上都流畅不掉帧。核心就三件事：轻量级图像识别锚点设计、离线优先的3D内容分发机制、以及最关键的——让非技术人员（比如一位58岁的书法老师或一位刚学会用剪刀的小学生）也能在15分钟内完成自己的AR贺卡创作。它解决的从来不是“能不能实现”，而是“愿不愿意打开手机、愿不愿意多看三秒、愿不愿意把这张卡留在书桌最显眼的位置”。如果你是文创店主、独立插画师、婚礼策划人，或者只是想给父母寄张不一样的春节贺卡，这个项目就是为你准备的实操指南，所有工具免费、所有流程可截图复现、所有坑我都替你踩过了。

2. 整体设计思路与技术选型逻辑

2.1 为什么放弃主流AR开发路径？

市面上90%的AR贺卡方案，要么走微信小程序AR（依赖微信生态、审核严、功能受限），要么堆砌Unity+Vuforia（学习成本高、包体动辄80MB、安卓低端机直接卡死）。我试过三种典型路径：

• 第一轮：微信AR开放能力
  用过微信官方提供的AR模板，优点是用户扫码即开，但致命缺陷是：所有3D模型必须托管在微信云存储，且每次加载需联网请求token。去年春节前帮一家老字号糕点铺做“年货礼盒AR贺卡”，测试时发现——城中村老小区4G信号弱的地方，加载一个1.2MB的灯笼模型要等6秒，72%的用户在等待中退出。更麻烦的是，微信对“营销类AR”审核极其严格，我们设计的“点击灯笼触发红包雨动画”被判定为诱导分享，驳回三次。

• 第二轮：Unity + AR Foundation
  搭建了完整开发环境，做了个demo：卡片识别后弹出3D生肖转盘。技术上很酷，但编译出的iOS包体47MB，安卓包体63MB。拿去给合作的校园文创店测试，店员反馈：“学生用千元机扫半天没反应，以为卡坏了。”而且每次更新贺卡内容（比如换一句祝福语），必须重新打包、提交App Store审核，周期长达48小时——这完全违背贺卡“即时性”的本质。

• 第三轮：纯WebAR（Three.js + A-Frame）
  这是转折点。用纯前端方案，用户无需下载APP，扫码即开。但早期版本问题集中：iOS Safari对WebGL支持不稳定，iPhone 11以下机型频繁白屏；安卓端Chrome又因权限策略，首次访问必须手动点“允许摄像头”，流失率高达40%。关键还在于——它无法离线运行。而真实场景中，很多人是在地铁上、电梯里、甚至飞机客舱里打开贺卡，网络不可靠是常态。

最终选定Model Viewer + Custom Image Tracking组合，原因很实在：

• Model Viewer是Google开源的Web组件，专为3D模型轻量展示优化，支持GLB格式（压缩率比OBJ高60%），且自带降级策略——不支持WebGL的旧设备自动切换为静态图+文字说明；
• 图像追踪不用Vuforia那种重型SDK，改用开源的AR.js，它基于JSARTOOLKIT5，核心追踪算法仅127KB，识别响应时间压到300ms内；
• 所有资源（3D模型、音频、文字）全部打包进单页HTML，生成一个.zip文件，用户扫码后下载解压即可离线运行，彻底摆脱网络依赖。

提示：这不是技术上的“妥协”，而是对使用场景的精准判断。贺卡的核心价值在情感传递，不在炫技。当一位老人需要花2分钟搞懂如何开启“AR权限”，这份心意就已经打折了。

2.2 “轻量化”的三个硬指标

整个架构围绕三个可量化的硬指标设计，每一条都来自真实踩坑：

1. 首帧渲染时间 ≤ 400ms
   用户举起手机对准卡片，从画面稳定到3D模型出现，不能超过眨眼一次的时间（人眼单次眨眼约300–400ms）。超时就会产生“卡顿感”，下意识移开手机。我们通过预加载关键帧纹理、禁用模型阴影计算、将3D模型顶点数控制在1500以内来达成。例如那朵樱花模型，原始Blender文件有8000+顶点，经MeshLab简化后剩1327顶点，体积从2.1MB压到187KB，渲染帧率从18fps升至52fps。

2. 离线包体 ≤ 5MB
   这是能塞进微信聊天窗口直接发送的极限。超过5MB，iOS会提示“文件过大，需用iCloud下载”，安卓则常被微信自动拦截。我们把所有资源做极致分层：基础HTML/JS（120KB）、核心追踪图谱（86KB）、主3D模型（≤2MB）、备用语音文件（≤2MB，MP3格式，采样率16kHz）。连字体都用系统默认的San Francisco（iOS）和Roboto（Android），绝不嵌入WOFF字体文件。

3. 创作者零代码门槛
   最终交付给插画师或小店主的，是一个带图形界面的本地APP（用Tauri框架开发，非Electron，包体仅28MB）。她只需拖入自己画的贺卡扫描图（PNG）、拖入3D模型（GLB）、粘贴祝福文字、录制语音（APP内置录音器），点击“生成”，30秒后得到一个.zip文件。整个过程不需要知道什么是“UV映射”，也不用理解“世界坐标系”。我亲眼看着一位教水墨画的李老师，用这个工具给自己孙女生日卡加了AR水墨游鱼效果——她全程只问了两个问题：“这个‘缩放比例’调大点，鱼会不会变胖？”“语音能录两遍吗？第一遍我打了个喷嚏。”

2.3 内容分发：二维码不是终点，而是入口开关

很多人把AR贺卡做成“扫一下看个动画”就结束，这浪费了AR最大的优势——上下文感知。我们的二维码设计成“动态开关”：

• 默认状态：二维码中心嵌入一张微缩版贺卡预览图（200×200像素），用户扫之前就能猜到内容风格；
• 首次扫描：加载基础AR场景（3D模型+文字），同时后台静默检查设备是否支持离线包；
• 若支持，弹出小按钮：“保存离线版”，点击后生成一个带时间戳的ZIP包（如birthday_20240315_1422.zip），用户可存到相册或微信文件传输助手；
• 若不支持（如老旧安卓机），自动降级为“增强版H5”：保留语音播放、文字动画、背景音乐，但3D模型替换为高质量GIF循环播放（已预渲染好，体积<800KB）。

这个设计解决了最痛的场景：婚礼请柬。新人发电子请柬时，长辈常因不会操作而错过AR环节。现在，他们扫完码，点一下“保存”，回家用WiFi慢慢看，孩子还能在平板上反复拖拽3D蛋糕模型——技术退后，体验上前。

3. 核心细节解析与实操要点

3.1 图像锚点设计：让贺卡自己“长眼睛”

AR识别的稳定性，70%取决于图像锚点（Image Target）的设计。这不是随便拍张贺卡照片就能用的。我们总结出一套“贺卡专用锚点四原则”，所有合作插画师都必须遵守：

• 原则一：拒绝纯色块，拥抱“可控噪点”
  很多人以为锚点要越清晰越好，于是用PS把贺卡LOGO抠出来单独做锚点。错。纯色块（尤其是大面积红/黑）在不同光照下反光率剧变，手机摄像头极易误判。正确做法是：在锚点区域刻意添加低频纹理。比如在贺卡右下角设计一枚“复古邮戳”，内部填充0.8透明度的浅灰网点（10%覆盖率），肉眼几乎不可见，但AR.js能稳定捕捉其灰度梯度变化。实测对比：纯色LOGO锚点在台灯直射下识别失败率37%，加网点后降至2.1%。

• 原则二：尺寸必须≥卡片面积的12%
  锚点太小，手机远距离识别困难；太大，破坏贺卡美学。我们用A4贺卡（210×297mm）做基准，锚点最小尺寸定为35×35mm。计算依据是：iPhone 13摄像头广角焦距ƒ=26mm，对焦距离0.2m时，单帧视野宽约380mm，35mm锚点占视野9.2%，刚好处于AR.js最优识别区间（8%–15%）。所有定制贺卡印刷前，设计师必须用标尺工具在AI文件里框出35×35mm安全区，并标注“锚点核心区”。

• 原则三：边缘必须有强对比过渡
  锚点边界不能是柔边或渐变。必须是硬边+高对比。例如锚点是枚金色铜钱，外圈必须用#000000描边3pt，内圈填#FFD700。这样无论贺卡纸张是哑光还是亮面，摄像头都能准确分割锚点轮廓。我们曾用一款珠光纸贺卡，因铜钱边缘未描边，识别时总把周围珠光颗粒误判为锚点延伸，导致模型抖动。补上描边后，抖动消失。

• 原则四：禁止跨折痕设计
  贺卡必有折痕，而折痕处纸张微翘，造成图像畸变。锚点若横跨折痕，AR.js会因透视变形计算错误而失锁。解决方案：所有锚点必须位于卡片同一平面内。对于对折贺卡，锚点统一放在封面右侧1/3处（避开折痕）；对于Z形折叠贺卡，则放在中间折页的左侧平面。我们制作了标准定位模板PDF，发给每家印刷厂，要求他们在印前校对时用此模板覆在菲林片上核对。

注意：锚点图像必须导出为PNG-24（支持透明通道），分辨率300dpi，文件名不含中文或空格。曾有插画师用JPG格式上传，导致AR.js读取时alpha通道丢失，识别率暴跌。

3.2 3D模型制作：美工也能搞定的“减法艺术”

AR贺卡的3D模型，不是越精细越好，而是越“克制”越好。我们给合作美工的模型规范手册只有一页纸，核心就三点：

• 顶点数封顶1500，面数封顶750
  这是经过23台不同型号手机实测得出的临界值。超过此数，iPhone SE（2020）和Redmi Note 9等中端机GPU开始掉帧。模型简化不是简单“减面”，而是有策略的：

  • 保留轮廓线精度（如樱花花瓣边缘必须有足够顶点表现弧度）；
  • 合并共面三角面（如花瓣背面完全平坦处，用单个大面替代多个小面）；
  • 删除不可见面（如模型底部完全被贺卡遮挡的部分，直接削平）。
    我们用Blender的Decimate修改器，设置Ratio=0.3，再手动修补断裂边缘，10分钟内可完成一个复杂模型的瘦身。

• 材质必须用PBR基础参数，禁用程序化纹理
  程序化纹理（如Noise Texture）在WebGL中渲染开销极大，且不同浏览器解释不一致。统一要求：所有材质用Albedo贴图（漫反射）+ Normal贴图（法线）双贴图方案。Albedo必须是sRGB色彩空间，Normal贴图必须是Linear空间。我们提供标准化贴图生成脚本（Python+PIL），美工只要把PSD源文件拖进去，自动输出合规贴图，连色彩配置文件都帮你嵌入。

• 动画必须烘焙进骨骼，禁用实时计算
  想让樱花飘落？别用Three.js的物理引擎实时算轨迹。正确做法：在Blender里做好3秒飘落动画（起始位置、旋转、缩放全关键帧），然后“烘焙动画到姿态”（Bake Action），导出时勾选“Include Animation”。这样GLB文件里存的是每一帧的绝对位姿数据，浏览器只需线性插值，GPU压力极小。实测：实时物理飘落动画在低端机上帧率12fps，烘焙后稳定58fps。

3.3 语音与文字的时空耦合设计

AR贺卡最易被忽略的，是声音与视觉的空间关系。传统做法是“模型出现→播放语音”，但人脑对“声源位置”有天然期待。我们的方案叫“声景锚定”（Soundscape Anchoring）：

• 语音文件必须带空间音频元数据
  用Audacity录制语音后，不直接导出MP3。而是用开源工具spatial-audio-tools注入Ambisonic B-format元数据，指定声源方位角（azimuth）和仰角（elevation）。例如生日祝福，设为azimuth=0°（正前方）、elevation=15°（略高于视线），这样用户听到的声音就像从贺卡正上方15厘米处传来，而非手机喇叭。

• 文字浮现必须匹配语音节奏
  祝福文字不是一次性弹出，而是按语音语义切分。用Web Speech API的SpeechSynthesisEvent监听每个词的发音时间点，动态控制文字DOM元素的opacity。例如语音说“祝你生——日——快——乐”，文字就分四次浮现：“祝你”→“生日”→“快乐”，每次浮现延迟对应语音停顿。我们写了一个简易切分脚本，输入语音MP3和文字稿，自动生成带时间戳的JSON配置：

  { "phrases": [ {"text": "祝你", "start": 0.2, "end": 0.8}, {"text": "生日", "start": 0.9, "end": 1.5}, {"text": "快乐", "start": 1.6, "end": 2.2} ] }

  前端加载后，用requestAnimationFrame精确控制CSS transition，误差<50ms。

• 离线语音缓存策略
  为避免重复下载，语音文件采用IndexedDB持久化存储。但有个陷阱：Safari对IndexedDB的quota限制极严（通常50MB），而语音文件累积多了会爆仓。解决方案是“语音指纹缓存”：对每个MP3文件计算SHA-256哈希值，以哈希值为key存入DB。用户下次收到同内容贺卡，先比对哈希，命中则直接读取本地，不发起网络请求。我们测试过，100条不同语音，总缓存体积仅12.3MB。

4. 实操全流程与关键环节实现

4.1 从零开始：15分钟生成你的第一张AR贺卡

以下步骤，我用一台M1 MacBook Air（macOS 13.5）和一部iPhone 14实测，全程无报错。你不需要安装Xcode、Node.js或任何开发环境。

第一步：准备素材（3分钟）

• 打开你设计好的贺卡PSD/AI文件，确保已按前述“锚点四原则”设置好识别区；
• 导出锚点PNG：菜单栏 → 文件 → 导出 → 导出为 → 格式选PNG，勾选“透明度”，分辨率300dpi，命名为anchor.png；
• 准备3D模型：从Sketchfab下载一个免费GLB模型（搜关键词“low poly flower”），或用Tinkercad在线建模（网址：tinkercad.com），建一朵简笔画风的花，导出为GLB格式，命名为model.glb；
• 录制语音：用手机自带录音机录一句祝福，保存为MP3，重命名为voice.mp3；
• 写祝福文字：新建文本文件，写“愿你如春日暖阳，自在明亮”，保存为text.txt。

第二步：使用AR贺卡生成器（7分钟）

• 下载我们的免费工具： ARCardMaker v2.1 （Mac/Windows/Linux全平台，无广告，开源）；
• 打开APP，你会看到四个拖拽区：“锚点图”、“3D模型”、“语音文件”、“祝福文字”；
• 依次将刚才准备的四个文件拖入对应区域；
• 调整参数（全部有默认值，新手可跳过）：
  • Scale：模型缩放倍数，默认1.0（适配A4贺卡）；
  • Rotation X/Y/Z：模型初始旋转角度，默认0（水平放置）；
  • Voice Delay：语音播放延迟，默认0.3秒（等模型完全加载后再发声）；
• 点击右下角【生成离线包】按钮，等待进度条走完（约25秒）。

第三步：测试与优化（5分钟）

• 生成的文件名为arcard_20240315_1622.zip，解压得到index.html；
• 用iPhone Safari打开该HTML文件（注意：必须用Safari，Chrome在iOS上不支持AR.js）；
• 对准你打印出来的贺卡（务必用激光打印机，喷墨打印反光太强）；
• 如果模型没出现：
  • 检查锚点是否在强光直射下（关掉台灯，用自然光）；
  • 检查手机是否开启了“低电量模式”（会限制GPU性能，关闭后重试）；
  • 打开APP里的【调试模式】，查看控制台报错（常见是anchor.png路径错误，重命名文件为英文即可）。

实操心得：第一次测试务必用实体打印稿，不要用屏幕显示的贺卡图。因为手机屏幕发光会干扰摄像头对印刷品的识别，失败率超80%。我们团队规定：所有内部测试，必须用A4纸+惠普M1136激光打印机输出，这是唯一被全机型验证过的组合。

4.2 印刷协同：让AR效果在纸面上“稳如磐石”

再好的AR技术，印坏了就全废。我们和三家印刷厂磨合一年，总结出“AR贺卡印刷黄金六参数”，已写入《文创产品AR化印刷规范》白皮书（可向我们索取）：

特别提醒：绝不能用数码快印！我们曾用爱普生L805喷墨打印机打样，测试发现——喷墨墨水在纸张表面形成微凸墨层，厚度约12μm，导致锚点区域产生光学畸变，识别距离缩短40%。所有AR贺卡必须走传统胶印流程，哪怕多等3天。

4.3 多场景适配：从生日卡到企业礼盒的弹性扩展

这套方案不是“一招鲜”，而是按场景做了三层弹性设计：

• 个人级（生日/节日卡）：单锚点+单模型+单语音，离线包≤2MB，适合微信发送。我们提供12套免费模板（樱花、雪人、灯笼、锦鲤等），插画师可直接替换贴图，5分钟出新卡。

• 商业级（婚礼/毕业典礼）：双锚点设计。封面锚点触发主3D场景（如旋转的婚礼蛋糕），内页锚点触发互动层（点击蛋糕某层，弹出新人婚纱照幻灯片）。此时离线包≤4MB，需用邮件或网盘分发。我们为上海某婚礼策划公司定制过“AR请柬系统”，支持新人自主上传照片、选择BGM、设定倒计时，后台生成唯一二维码，宾客扫码后所有内容离线可用。

• 品牌级（企业礼盒）：多锚点+地理围栏。在礼盒六个面各设一个锚点，手机扫任意一面，启动不同AR模块：扫顶面看品牌故事3D动画，扫侧面看产品拆解，扫底面触发LBS彩蛋（仅限门店500米内，扫出优惠券）。此时需接入轻量级后端（我们用Cloudflare Workers，月成本$0），但核心AR逻辑仍离线运行。为某国产茶饮品牌做的中秋礼盒，上线首月AR互动率73.2%，远超行业均值28%。

关键技巧：多锚点场景下，必须用“锚点ID绑定”而非“顺序绑定”。早期版本按扫描顺序加载模块，结果用户先扫底面再扫顶面，动画错乱。后来改为每个锚点PNG文件名嵌入ID（如anchor_top.glb,anchor_side.glb），前端根据文件名后缀加载对应模块，彻底解决顺序依赖。

5. 常见问题与排查技巧实录

5.1 识别失败：90%的问题出在这三个地方

我们收集了217例用户上报的“扫不出AR”问题，归类后发现，90%集中在以下三类，附带一键自查表：

独家技巧：当所有自查都无效，试试“手掌遮光法”。用手掌完全盖住手机摄像头，等3秒，再缓慢移开——这能重置摄像头自动曝光参数。我们发现，32%的“无反应”案例，用此法10秒内解决。

5.2 模型异常：扭曲、错位、穿模的根源

3D模型在AR中变形，常被归咎于“模型没做好”，其实70%是坐标系错配。WebAR的坐标系与Blender默认不同：

• Blender Y-up，WebAR Z-up：Blender里Y轴指向上方，而AR.js使用OpenGL坐标系，Z轴向上。若直接导出，模型会“躺平”在贺卡上。解决方案：导出GLB时，在Blender的导出面板勾选“+Y Up”（不是默认的“Y Up”），或导出后用gltf-transform命令翻转：gltf-transform up model.glb model_fixed.glb --up y。

• 单位制不统一：Blender默认单位是“米”，但贺卡尺寸是厘米级。若模型按真实尺寸建（如一朵花高10cm），在AR中会巨大无比。必须在Blender里按1:100比例建模（10cm花建为0.1单位），或导出后用gltf-transform缩放：gltf-transform scale model.glb model_scaled.glb --scale 0.01。

• 法线方向错误：模型背面不可见，常因法线朝内。在Blender里选中模型→编辑模式→A全选→Ctrl+N重算法线→勾选“Outside”。导出前务必在3D视图按N打开侧边栏，确认“Shading”设为“Flat”，能看到所有面的法线箭头都指向外。

5.3 语音失效：听不见、延迟高、音质差的实战对策

语音问题最影响情感传递，我们建立了一套“三阶质检法”：

• 第一阶：录制端
  禁用手机自带录音机。改用 Voice Memos Pro （iOS）或 Easy Voice Recorder （Android），设置：采样率16kHz、比特率32kbps、格式MP3。实测比系统录音机文件小60%，音质无损。

• 第二阶：处理端
  用Audacity降噪：效果→降噪→获取噪声样本（录3秒环境底噪）→应用降噪（降噪程度30%，残留噪音比-12dB）。再用“压缩器”提升人声清晰度（阈值-20dB，比率3:1）。最后导出时勾选“恒定比特率（CBR）”，禁用VBR——VBR在Web播放时首帧加载慢。

• 第三阶：播放端
  浏览器音频API有固有延迟（iOS Safari平均120ms）。我们在前端加了“音频预加载补偿”：页面加载时，先用AudioContext创建一个无声Buffer（context.createBuffer(1, 1, context.sampleRate)），再立即播放。这能激活音频上下文，后续语音播放延迟降至23ms内。代码仅3行：

  const ctx = new (window.AudioContext || window.webkitAudioContext)(); const buffer = ctx.createBuffer(1, 1, ctx.sampleRate); ctx.createBufferSource().buffer = buffer;

5.4 商用避坑：版权、隐私与法律红线

做商用AR贺卡，必须守住三条底线：

• 3D模型版权：绝不能用Sketchfab上标“Free for Personal Use”的模型商用。我们只用CC0协议（公共领域）或明确标注“Free for Commercial Use”的模型。推荐资源站： Poly Haven （全CC0）、 TurboSquid Free Section （筛选Commercial Use）。

• 语音肖像权：给客户做AR请柬时，必须签《语音授权书》，明确“甲方授权乙方将此段语音用于婚礼请柬AR展示，不得用于其他用途”。我们模板里加了手写签名栏和日期，法律效力等同纸质合同。

• 数据隐私零采集：我们的生成器APP和离线包，不联网、不传数据、不埋点。所有处理在本地完成。曾有客户要求“统计多少人扫了请柬”，我们拒绝，并建议改用“二维码短链+UTM参数”方案（如bit.ly/ar-wedding-2024），既满足统计需求，又不触碰用户设备隐私。

最后分享一个血泪教训：去年为某儿童绘本做AR互动卡，用了网上找的“卡通恐龙”3D模型。上市三个月后收到律师函，对方持有该模型著作权，索赔20万元。我们全额赔付，并从此立下铁规：所有商用项目，3D模型必须提供原始创作证明或正版授权书，否则宁可重做。

6. 项目延展与未来可能性

这个项目走到今天，早已不止于“让贺卡动起来”。它正在变成一种新的表达语法，渗透进更多生活场景。我自己最近就在尝试几个延伸方向，有些已小范围验证成功：

• AR明信片计划：和云南一家手作邮局合作，游客在洱海边写明信片，店员用我们的便携打印机（Zebra ZQ630）现场打印AR锚点，游客寄出后，收件人扫码就能看到洱海实拍视频叠在明信片上——不是预录视频，而是调用手机摄像头实时渲染洱海天空，用地理坐标（GPS）触发。技术上用WebGL+DeviceOrientation API，难点在于iOS对GPS精度的限制，我们用“Wi-Fi指纹定位”辅助，误差缩至50米内。

• AR家书系统：为海外务工人员家庭设计。父亲在工地用手机录一段话，系统自动生成AR贺卡，母亲收到后，扫卡片能看到丈夫站在虚拟工地背景里说话，背景是实时合成的工地监控画面（已脱敏处理）。这里的关键突破是“语音驱动口型同步”，用Web Audio API分析语音频谱，驱动Three.js的面部骨骼动画，准确率82%，远超传统LipSync方案。

• 无障碍AR贺卡：和盲文出版社合作，为视障人士设计。贺卡上凸点图案既是盲文，也是AR锚点。手机扫后，不播放视觉动画，而是启动VoiceOver，用空间音频描述场景：“你现在看到一朵红色玫瑰，花瓣有五片，茎上有三根刺…”。我们把整个AR引擎的UI控件全部重构为VoiceOver可读，连“点击此处播放”都改成“双击两下播放祝福”。

这些延展，核心逻辑没变：技术永远服务于人的感官与情感，而不是让人去适应技术。当一位奶奶第一次用颤抖的手指，点开孙子生日卡里那只AR纸鹤，看着它扑棱棱飞过客厅天花板，然后停在她鼻尖前轻轻点头——那一刻，所有代码、所有参数、所有深夜调试，都有了答案。这大概就是“Reinventing Greeting Cards”最朴素也最滚烫的初心：让心意，抵达得更近一点。