去年下半年我们团队接到一个看起来不太“正经”的需求给一款工具类 App 加一个 AI 宠物功能。产品经理的论证写了大半页核心意思其实就一句——用户每天打开 App 完成打卡之后希望有一只电子宠物在旁边陪着。我当时的第一反应是这活儿太鸡肋了甚至想过丢一张 GIF 上去糊弄了事。但真正动手以后才发现这个功能牵扯到的东西远比想象中多大模型接入、语音交互、动画调度、内存治理、上架合规……每一步都有坎。这篇复盘就是从方案选型到最终上线的完整链路我会把中间踩过的坑和排查过程全部摊开讲包括那些问了大佬才搞明白的底层原因给跟我一样要做 AI 功能的开发者参考。1. 需求缘起一个看似“不务正业”的功能为什么值得做1.1 需求文档里没有明说的东西表面上看这个需求是“做一个宠物”但产品经理真正的目标有三层第一提升 App 的日活和次留希望用户每天因为“想看看宠物”而打开一次第二延长单次使用时长鼓励用户在和宠物互动后继续使用工具本身的功能第三建立情感黏性让工具类 App 不再是一个用完即走的冷冰冰页面。这三层目标决定了后面所有的技术决策。如果我当时只按“做一个动画宠物”来理解那确实是一张 GIF 就能解决的事情。但要满足“用户想天天回来看它”这个诉求宠物就必须具备一定的交互能力和内容变化能力这也是“AI 宠物”而不是“普通桌面宠物”的核心差异所在。1.2 AI 到底给宠物增加了什么我梳理了三种方案纯静态动画、规则驱动的互动宠物、接入大模型的 AI 宠物。纯静态动画成本最低但用户几天就看腻了留存贡献几乎为零。规则驱动互动写死“摸一下摇尾巴”“喂食有反馈”这类逻辑适合儿童应用但成年用户的新鲜感维持时间也很短。AI 宠物宠物能够自由对话、识别用户情绪、记住用户偏好、根据场景自主发出互动请求这才会让用户产生“它真的在陪我”的感觉。所以结论很明确宠物功能只是壳AI 能力才是让用户留下来的内核。我当时在立项文档里写了一句“宠物的本质是陪伴陪伴的本质是对话”这句话后来成了整个产品设计的指导原则。2. 技术选型从“抄作业”到“定方案”的全过程2.1 对话引擎API 派还是模型派这是第一个要拍板的问题。当时团队里有两种声音一种是直接接国内大模型厂商的对话 API另一种是在端侧跑一个小尺寸模型完全离线。我的选择很直接主对话链路走云端 API。原因有三个。第一合规要求。App 要上架AI 生成内容必须可追溯、可过滤国内大模型 API 都自带内容安全审核自己在端侧跑一个开源模型反而要额外自建过滤系统成本更高。第二对话质量。端侧小模型在中文语境、角色扮演、长对话记忆上的表现离商用还有距离。第三部署成本。端侧模型要考虑模型文件体积、推理耗电、不同芯片的兼容性开发和测试周期都会拉长。最终我们选了智谱 GLM 系列作为主对话模型通义千问作为备选用国内大模型的标准鉴权方式接入。流式输出是必须的因为首 token 延迟和“打字机效果”直接影响用户感知——等你把一长段话一次性吐出来用户早就退出页面了。2.2 宠物外形与动画方案宠物的“身体”选型上我对比了 Live2D、Spine、Lottie 和纯序列帧四种方案列了个简单的评估表方案动画表现力资源体积运行时性能动态切换成本序列帧高大高高Lottie中小中中Spine高中高中Live2D高中高低我们最终选了 Live2D。原因是宠物功能需要大量“动态切换”场景从待机到开心、从说话到睡觉Live2D 可以用一套模型和贴图资源通过参数切换实现不同表情和动作不需要为每个动作单独切图。而且它有成熟的移动端 SDK支持网格变形、表情混合、嘴唇同步正好适合我们后续接语音。这套方案唯一的短板是需要美术同学先熟悉 Live2D 的制作流程。好在当时团队里有一个喜欢折腾插件的 UI 设计师花了一周时间就产出了第一版小猫模型。2.3 语音链路离线 ASR 与在线 TTS 的组合拳AI 宠物的完整交互体验里语音是重要一环。用户对宠物说话宠物听懂并回应这个闭环比纯打字输入更有“活物感”。语音模块我拆成了两段来选型语音识别 ASR 用了离线方案基于 sherpa-onnx支持中文普通话和部分方言模型离线跑的好处是响应快、没有延迟感、不依赖网络对用户隐私也更友好。缺点是词表有限但后来实测下来日常口语指令的识别率在 90% 以上够用了。语音合成 TTS 则用了在线 API因为在线合成的音色自然度明显高于端侧方案。我们试过好几种音色最后选了一个偏少年感的嗓音和猫咪的设定比较契合。这里有个小细节TTS 返回的音频时长是一个动态值用真实音频时长去驱动动画嘴型而不是让动画固定时间否则会出现“话还没说完嘴就闭上了”的尴尬情况。3. AI 宠物“大脑”是怎么长出来的对话、记忆与情绪3.1 Prompt 工程第一次让大模型“闭嘴”接入大模型之后我第一个任务是写系统提示词Prompt。最初版本我写了很长一段给宠物设定了名字叫“团子”年龄三岁性格粘人、好奇心重口头禅是“喵”。结果上线调试时团子变成了一个话痨每句话都要带一堆表情符号和解释回答长度动不动就上百字。后来我删掉了大部分形容词改成结构化约束核心就三条你是 App 里的电子猫咪“团子”说话要短不超过 40 个字。用户说什么你都要接住但不要主动询问用户隐私。对话中要偶尔体现“你在 App 里生活”的设定比如提到看到了用户今天的打卡记录。这版 Prompt 上线后团子终于“闭嘴”了回复简短、自然偶尔还有一点小机灵。实测下来把约束说清楚比把性格描述清楚更重要——大模型不缺创造力缺的是边界。3.2 三条记忆链路让宠物记住用户如果一个 AI 宠物每次打开都“失忆”用户很快就会觉得它是个假的智能音箱。我设计了三条分层记忆链路。第一层是会话级记忆。用户在单次对话窗口内的上下文都传给大模型让对话有连续性。这一层直接用内存和 Redis 缓存实现设置 30 分钟过期。第二层是用户档案级记忆。把用户在 App 内的关键行为沉淀成标签比如“打卡了 7 天”“最近加班多”“喜欢晚上用 App”。这些标签通过一个规则引擎生成存入数据库用户表在每次宠物对话前作为背景信息注入 Prompt。第三层是长期知识库。用户问宠物“我去年完成了多少次打卡”这类跨时间的问题需要从结构化数据里查。我用向量数据库把所有历史行为记录做成了可检索的索引每次对话前先取 top 3 相关结果拼到上下文中。这三层记忆合在一起宠物的对话就具备了“越聊越熟悉”的效果。曾经有个用户在反馈里说“团子居然知道我上周感冒了瞬间感动。”虽然那句“感冒”其实是我们从打卡时间异常推出来的但这一句话足以证明记忆机制的价值。3.3 情绪判断与宠物状态机情绪是让宠物“有血有肉”的关键。我用两种信号来判断用户当前的情绪状态一种是文本信号把用户最近的聊天内容送入一个轻量级意图分类模型识别出高兴、低落、疲惫、烦躁四类另一种是行为信号比如用户连续多次拒绝宠物建议、或者短时间内频繁滑动页面也会被标记为“烦躁”。情绪结果会映射成一个现实乐观值0 到 1驱动宠物的状态机。状态机是这样设计的IDLE待机、HAPPY开心、SAD低落、SLEEP睡觉、EXCITED兴奋、COMFORT安慰。当用户情绪偏低时宠物会从 IDLE 切到 COMFORT主动说一些安慰的话并减少活泼动作当用户情绪高涨时宠物会切 HAPPY多做一些翻滚和蹭屏幕的动作。这个状态机不仅影响宠物说什么还影响宠物怎么做。让我印象很深的是一次真实崩溃用户凌晨两点还在 App 里加班打卡宠物说了句“这么晚还在忙团子陪你一会儿吧”用户后来截图发微博说“被一个虚拟猫整破防了”。那一瞬间我觉得这个功能做对了。4. 让宠物“活”起来动画与交互层实现细节4.1 状态机驱动的动画调度动画层是宠物功能的“演技”不够自然的话再聪明的头脑也白搭。Live2D 模型的动画是由参数控制的比如头部角度、身体倾斜、眼睛开合、嘴巴开合度。我设计了一套动画调度器核心是所有动画切换都必须经过状态机不允许动画层直接调用。举个例子当用户摸摸宠物时触摸事件先上报给状态机状态机根据当前状态计算一个“被打断优先级”。如果宠物正在睡觉摸它会被判定为“轻微打扰”先播放一个“起床气”动画再转 HAPPY如果宠物正在说话摸它则不会打断当前语音只会在语气上更活跃一点。动画切换过程中还要处理关键帧插值。直接硬切会有明显的跳变感我用了简单的线性插值算法来做过渡大部分动作切换保持在 0.2 到 0.5 秒之间测试下来观感最自然。这段最初用的是系统自带的动画插值后来发现它对 Live2D 参数矩阵的支持不够平滑干脆自己写了一个 200 行的小工具类反而更可控。4.2 与宿主 App 的通信协议设计宠物不是一块独立运行的部件它要感知 App 内的各种事件比如用户完成打卡、用户进入某个页面、用户断网、用户长时间停留等。我定义了一套标准事件消息体统一通过一个事件总线传递{ event_type: user.checkin.completed, timestamp: 1700000000, payload: { streak_days: 7, checkin_time: 08:30:15 } }事件类型用点分命名空间划分领域user.*代表用户行为app.*代表应用生命周期pet.*代表宠物自身状态。各个模块解耦宠物状态机只监听它关心的事件不必关心这些事件是从哪里来的。这个设计初期看起来有点“过度设计”但后来加需求时非常舒服。比如产品想增加一个“宠物在你完成第 30 次打卡时给你惊喜彩蛋”我只需要注册一个监听器判断 streak_days 等于 30然后触发一个预置动画和语音十分钟就上线了。4.3 性能治理低端机上不能“养不起”猫Live2D 动画在高端机上跑得很流畅但一放到低端 Android 机上就开始掉帧这是一开始没想到的。排查之后发现主要问题出在三个方面第一纹理内存占用。一个 2048×2048 的图集在低端机上有不小的内存压力。我把美术源文件切分成多个 1024×1024 的纹理集按状态懒加载只加载当前需要的部分内存占用头少了一半。第二每帧全量渲染问题。Live2D 模型即使不动也在按每帧重绘整张画布。我加了一个脏标记机制当模型参数没有变化时跳过渲染直接用缓存帧。这一改动在低端机上帧率从 30fps 提升到了 45fps 左右。第三后台资源回收。App 切到后台一段时间后Live2D 模型会被系统回收回到前台时动画会白屏。解决方案是监听应用生命周期在 onStop 时保存模型参数快照在 onStart 时重新初始化并恢复参数。这个坑我后面还会详细说。性能优化的原则很简单让宠物不做无效功。渲染、语音、位置计算每个环节都要想清楚“这次计算是否有必要”。5. 上架前最折腾的一周五个坑的完整排查链路5.1 坑一流式输出的汉字被截断现象对话有时候会出现“猫尾巴是”“6”这种怪字符隔几句就会冒出来一次。排查过程最开始我以为是模型生成的文本有问题在服务端看了原始返回值发现 JSON 结构是完整的但再仔细看文本中间夹着一个不可见字符。后来定位到是 UTF-8 编码边界问题流式传输一帧不超过固定字节数时会把一个完整的汉字编码割成两半客户端拿到单帧解码时就产生了乱码。解决方式客户端不再对每一帧做独立的 UTF-8 解码而是维护一个字节缓冲队列每次先拼接再按边界切分保证任何时刻解码的都是完整字符。这个修改虽然只影响一小段代码但它是整个项目里第一个让我意识到“流式”这两个字不只是接口协议层面的事而是每一层都要考虑的机制。5.2 坑二宠物长时间无动作后动画卡死现象用户反馈说“猫不动了”应用没死其他功能正常但宠物停在最后一个姿势上怎么点都没反应。排查链路我先在真机上复现发现不是必现而是长时间挂机后再回来操作才出现。打开 Android Studio 的 Profiler 检查资源发现 Live2D 的后台模型资源被系统回收了但应用侧还拿着旧的对象引用导致状态机正常发指令动画层却没有响应。解决应用切后台时不持有 Live2D 渲染实例主动释放 GPU 资源切回前台时重新创建实例并恢复上一次的状态参数快照。同时给触摸事件、动画消息都加了一层“空保护”当动画层未就绪时先缓存指令等就绪后再执行避免状态机因为动画层不响应而卡住。5.3 坑三语音唤醒导致 CPU 飙高现象内测用户反馈手机发热看日志发现语音识别模块在后台时 CPU 占用持续在 30% 以上。排查链路最开始我把语音识别设计成了持续监听逻辑是“随时等用户叫宠物”但忽略了移动端的功耗问题。持续采集麦克风数据、跑 VAD 语音活动检测、偶尔还触发一次完整的 ASR 推理一天下来电池根本顶不住。解决把“持续监听”改成“前触发式监听”。默认状态下不启动任何音频采集只有当用户触摸宠物或点击语音按钮时才打开麦克风进入 30 秒的监听窗口。这一改动直接让 CPU 占用从 30% 降到了 2% 以下发热问题彻底消失。如果你的产品也想做“免唤醒词连续对话”请务必做好功耗评估移动端真的不适合一直开着麦克风。5.4 坑四审核被拒理由居然是“宠物会说话”现象提审应用市场反馈“存在 AI 生成内容风险请补充内容安全措施”。排查链路我们的对话 API 虽然自带内容审核但审核方不认第三方 API 的审核结果要求 App 自己具备内容过滤和用户举报能力。我们做了一系列整改接入内容安全审核 API对宠物回复做二次过滤增加用户举报入口可对不安全对话一键举报在对话页面明确展示“AI 生成内容仅供参考”的提示针对未成年人模式关闭了非预设的对话能力只保留预设问答。这个坑提醒我AI 功能上架不只是技术问题更是产品合规问题。做技术的人容易忽略这块但它在整个项目周期里占了将近一周的时间建议提前规划。5.5 坑五TTS 返回的音频流与动画嘴型不同步现象用户吐槽“猫说话像在念稿”嘴型和语音对不上有半秒左右的延迟。排查链路我一开始以为是网络延迟造成的于是加了音频缓存优化但问题依旧。后来在本地日志里对比音频时长和动画时长发现 TTS 合成音频的真实时长是 3.6 秒而动画层默认按 3 秒播完自然会出现“话还没说完嘴巴已经闭上了”的问题。解决改成音频驱动动画。先让音频播放器先解析出真实时长再把时长传给动画调度器由它决定这 3.6 秒内嘴巴的开合曲线。同时为每段话的最后 0.3 秒设置了“收尾静默期”让嘴巴在语音结束前带着一点自然的停顿再闭上效果立刻自然了很多。这个经验延伸到其他语音类功能也一样任何语音与动画的联动都应该以真实音频时长为基准而不是用经验值去硬编码。6. 复盘判断AI 宠物功能到底给 App 带来了什么6.1 数据结论留存和时长都涨了功能上线四周后我们拉了一版数据次日留存率提升了约 9 个百分点其中“在首页和宠物互动超过 5 分钟”的用户次日留存率比整体高出约 20 个百分点人均单次使用时长从 2 分 40 秒提升到 4 分 15 秒提升主要发生在“打卡后”这个时间点主动向宠物发起对话的用户占总活跃的 35% 左右其中约 60% 的用户在对话后继续使用了 App 的其他功能。最让我意外的不是时长提升而是“对话后继续使用工具”这个数据。这说明宠物对话并没有像我们担心的那样“只让用户玩猫不干活”反而在特定场景下成了引导用户深度使用 App 的一个入口。后来回看用户访谈有些用户说“打卡后想看猫有什么反应然后就顺手把报表页也打开了”。这就是情感引导流程的典型效果。6.2 什么情况下 AI 宠物功能不值得做经历完整个项目我给自己总结了一套判断标准再遇到“要不要给 App 加 AI 功能”这类问题时我会先过三道关第一这个功能是否能创造新的使用频次。如果 AI 功能只是把原有功能换了个说法没有带来新的打开动机那它多半是伪需求。宠物之所以有效是因为它给了用户一个“每天回来看一眼”的理由。第二你能不能承受内容合规成本。只要是大模型生成内容审核这块就跑不掉。如果团队没有人力维护违规内容过滤和用户举报机制就没法保证上线节奏。第三数据反馈能不能闭环。AI 功能不是做完就结束它需要依赖埋点、用户反馈和迭代调优。如果连基础的对话日志和交互漏斗都没有功能做出来也无从优化。三道关都过了才值得立项。这道关没过即便是今年最火的 AI 概念也只是个华丽的 PPT 功能。6.3 一个技术人的后怕与庆幸整个项目做完我最想分享的一条经验是AI 功能的工程难度不在于模型本身而在于模型之外的整合工程。你既要写好 Prompt又要设计状态机、处理流式解码、管好端侧资源、应付上架合规。任何一个环节掉链子用户感受到的就是“这个宠物是假的”。我在最终复盘文档里写了这么一段把 AI 接入 App 的加分项不在你能调多少种模型而在你能把用户和模型之间的那条路铺得有多稳。这句话后来被我们产品经理拿去当了团队技术分享的封面我至今觉得很贴切。对了最后分享一个小技巧如果你也想给 App 做宠物功能可以先从“抄自己会用的功能”开始——比如做一个跟随手势移动的小球再把对话 API 接进去。一个小而完整的闭环比一开始就追求 Live2D 语音 多模态的效果要靠谱得多。等跑通了闭环再做“好看”和“聪明”都不迟。