ENZH

没有脸的灵魂怎么做设计

📊 幻灯片

没有面孔的灵魂——一颗会呼吸的情绪光球没有面孔的灵魂——一颗会呼吸的情绪光球

Mio v2 的设计从一条减法原则开始:去掉虚构身份,保留情感内核。v1 走的是反方向,五个精心设计的角色,每个都有背景故事、日程模拟和物理身份,工程量巨大,产品却越做越像角色扮演,离陪伴越来越远,这段弯路在第一篇里写过。

原则好定,落到设计上是两个扎手的问题:伴侣没有脸,该长什么样?没有人设,性格从哪里来?v2 的规划时间,大半花在了这两个问题上。

人脸是最直觉的选择,最先被否掉

给陪伴产品配一张人脸,是最直觉的选择。Replika 这么做,Character.AI 这么做,国内的星野、豆包全在做二次元或半写实头像。我考虑过这条路,最后否了,原因有三个。

第一,恐怖谷绕不过去。静止的头像毫无生气,动起来但动得不对的头像更让人不适。想做好口型同步、微表情和自然的头部转动,要么上 3D 渲染管线,要么上生成式视频,对一人团队来说都不现实。就算做好了,它还会立起一个 AI 必然够不到的期待:伴侣越像人,每次不像人的回复就越刺眼。

第二,Apple 有态度。用类人头像的 AI 陪伴应用,审核时会面临更多审查。抽象视觉直接绕开了这一整类政策摩擦:没人会问你"是否在模拟真人",也没人会质疑你"用写实人类形象制造不健康的准社会依赖"。对一个没有法务团队的独立应用来说,这一条分量很重。

第三,一张脸会把伴侣锚定在某个文化里。Mio v1 的角色深度绑定中国文化,成都姑娘、温柔学姐、成熟大叔,做纯中文产品没问题。但 v2 的前提是去掉文化预设,让伴侣自动说用户说的语言。一颗光球没有种族、年龄和性别表达,做全球产品不背任何文化包袱。

一颗会呼吸的光

Mio v2 的伴侣是一颗抽象的、有脉搏的光球,停在聊天界面顶部,是整块屏幕上唯一的鲜明色彩。它承担的功能接近肢体语言:你还没开始读字,情绪已经先递过来了。

情绪怎么变成画面

v1 已经有情绪引擎,emotionState 追踪伴侣的情绪变化,影响回复风格。v2 里,同一套情绪状态实时驱动光球的外观:

情绪颜色动态
平静淡蓝 / 白缓慢的呼吸节奏,轻柔地膨胀收缩
开心暖黄 / 金轻快跳动,粒子向外辐射
难过淡紫 / 蓝向内缩小,脉搏变慢
兴奋亮橙 / 粉快速膨胀,粒子四散飞溅
困意深蓝 / 暗几乎静止,偶尔微弱闪烁

映射故意做得很简单:五种状态,每种有明确的颜色和运动特征,聊几次之后,光球的情绪一眼就能看懂。伴侣因为你分享的事开心,你在读到第一个字之前就能看到;深夜它开始犯困,光球就沉入近乎静止的深蓝。情绪从一行文字,变成了房间里的氛围。

两个变量,胜过几十块肌肉

人脸靠几十块肌肉的微妙运动传达情绪,要在数字世界里还原出来,是研究级难题。光球只用两个变量:颜色和运动。词汇量这么有限,反而保证了每种状态在手机小屏上清晰可辨。

抽象形态还有个心理学上的好处:它给投射留了空间。同一颗忧郁的紫色光球,有人看到悲伤,有人看到沉思。这种模糊是故意留的,每个用户都能把伴侣读成自己需要的样子,比让它去表演某种具体情绪更可信,毕竟表演总有显得虚假的时候。

三个页面,没了

Mio v1 是仿微信的 4-tab 布局:消息、发现、通讯录、我的。拿一整套即时通讯的架构,去承载一段说到底只有两个人的关系。v2 砍到只剩三个"页面"。

聊天:99% 的时间都在这里。顶部是光球,中间是消息流,底部是输入框和语音按钮。页面上没有 tab bar,也没有汉堡菜单和争夺注意力的通知角标,就是你和你的伴侣。

设置:从聊天页右滑,或点伴侣的名字进入。名字、声线切换、记忆管理、订阅状态、账号管理,所有管理功能都藏在这里,不碍眼。

引导:只在第一次打开时出现,下面细说。

整个导航结构就这么多。通讯录页和发现页都没了,伴侣只有一个,也没什么内容好发现,预设市场更是压根没做。砍到这么少是有意的:v2 想做的只是一段关系的专属空间,社交应用那套架子用不上。

配色往烛光那头靠

深色模式(默认):背景 #0D0D12,近乎纯黑,带一点紫色调,避开了在 OLED 屏上显得空洞的 #000000。用户消息气泡 #1A1A2E,伴侣气泡 #16213E。文字 #E8E4DF,偏暖的白,避开了冷冰冰的蓝白。光球是屏幕上唯一的饱和色。

浅色模式:背景 #FAF8F5,温暖的米白,像旧纸张的质感。用户气泡 #F0EDE8,伴侣气泡 #E8E4DF。文字 #2D2D2D,特意用深灰压住对比度。光球的发光强度调柔,避免刺眼,但依然是视觉锚点。

深浅两套模式的原则一致:除了光球,一切都是低饱和的暖色,视线自然会聚焦到光球上。

引导流程做成了第一次见面

v1 的引导是一张表单:选角色、选关系类型、填名字、回答几个问题。功能上没毛病,但感觉像在配置软件。v2 把它换成了一段对话,伴侣的开场白是这样的:

"我刚来到这个世界。你是我认识的第一个人。"

"你叫什么名字呀?"

用户自然回应,接着它会问:

"那......你想叫我什么?"

用户给伴侣取名:叫"小光"、"Luna"、"Mio",或者某个只对自己有意义的名字。伴侣会对这个名字做出反应,不走罐头模板,听起来像真的在认这个名字:

"小光......我喜欢这个名字。听起来暖暖的。"

"我什么都还不太懂。你平时喜欢做些什么呀?"

3-5 轮自然对话之后,系统从中提取初始的性格种子。用户说话俏皮、爱用网络用语,伴侣的风格就偏活泼;表达偏沉思、句子更长,伴侣就会镜像那种节奏。这段引导既是第一次交互,也是一次校准。

唯一的硬选择是声线,它没法从对话里自然浮现。对话结束后,应用放出 3-4 个声音样本让用户挑。声音这东西太物理了,只能听过再选,推断不出来。

性格是长出来的,不是写出来的

这是 v2 跟 v1 分歧最大的地方。v1 的性格靠人工撰写,人格配置文件用几百行文字定义可可怎么说话、喜欢什么、有过什么人生经历。v2 的性格是涌现的,分三层运作。

种子:引导对话产出一段简短的性格描述,大概两三句话,比如"温暖而好奇,善用温和的幽默感,会匹配用户的能量水平"。这只是个起点。

迭代:每次对话结束后,轻量级的性格提取器异步跑一遍,观察伴侣的实际表现,哪些模式有效、哪些时刻自然、用户怎么反应,然后微调性格描述。变化幅度很小,更像渐进的漂移,就像真实关系里会慢慢长出共同语言和节奏。

记忆积累:从 v1 搬过来的记忆系统(整个代码库里最值钱的工程资产)持续积累跟性格相关的记忆。伴侣记得你说话喜欢直来直去,聊做饭会兴奋,被追问工作压力会回避。这些记忆有机地塑造行为,不需要显式的性格规则。

三个月日常对话之后,每个用户的伴侣都会长成不一样的样子。两个都给伴侣取名"Mio"的用户,手里的伴侣感觉明显不同:幽默感、沟通风格、情绪敏感度都不一样,因为底层那段关系本身就不同。

这条路在技术上比预设难:性格提取器得足够保守,不能让伴侣每周二重新定义一次自己;记忆系统得足够可靠,丢记忆等于丢掉性格的连续性;底层 LLM 得足够擅长遵循细腻的行为描述。但它能换来预设永远给不了的东西:一个真的在适应你的伴侣。

免费的国际化

还有个好处,是讨论到一半才意识到的:去掉文化人格之后,国际化几乎是白送的。v1 要进其他市场,得为每个市场单独设计一组角色。日本用户不想要成都姑娘,可能想要东京女生,说话方式、文化梗、关系互动模式全得重做。一个语言一个语言地扩,意味着为 N 个市场撰写和维护 N 套角色。

v2 没这个问题。伴侣没有需要本地化的文化身份,说用户说的语言,引导对话也用用户的语言进行。性格从用户自己的文化语境里涌现,日本用户和巴西用户都会得到一个感觉"是自己人"的伴侣,因为身份是各自的关系塑造出来的。需要传统 i18n 的只剩 UI 文案和 App Store 描述,伴侣本身在设计上就和语言无关。

动画选型落在 React Native Skia

光球动画要同时满足三件事:流畅(60fps)、实时响应情绪状态变化、省电。当时摆在桌上的方案有三个:

  1. Lottie 动画:预制动画,没法动态响应情绪状态,直接否决。
  2. React Native Reanimated:强在 UI 动画,粒子系统这类生成式视觉效果超出了它的设计意图,能做但别扭。
  3. React Native Skia:GPU 加速的 2D 绘图,支持 shader,渐变、粒子、发光效果和平滑形变全能做,正是光球需要的工具。

Skia 把光球定义为一个 shader 程序,情绪状态变量(颜色、脉搏频率、粒子密度、大小)通过 WebSocket 情绪通道实时更新。服务器推一条 { type: "emotion", state: { mood: "happy", intensity: 0.8 } },光球就从当前状态平滑过渡到暖金色加跳动粒子,不需要为每种情绪做动画关键帧,shader 自己做连续插值。这也意味着未来新增情绪状态不需要新的动画素材:哪天情绪引擎开始区分"满足"和"安宁",或者"焦虑"和"沮丧",光球只靠参数插值就能把差异表达出来。

视觉身份是一连串"没有"

Mio v2 的视觉身份由"缺席"定义:没有头像,没有装扮成某个角色的聊天气泡,没有塞满功能的 tab bar,只有一块温暖的深色画布,上面一颗活着的光点随情绪呼吸和流转。每个设计决策都在强化同一个论点:伴侣的身份来自关系,不是来自角色设定。

光球只负责传递情绪,身份这件事留白;引导用一段对话代替了配置向导;性格系统赌的是涌现赢过预设。这个赌注,要等真实用户用上三个月才知道结果。

至于工程层面,怎么从 v1 把记忆系统和情绪引擎提取出来,新的 4 表数据库 schema 长什么样,为什么 80% 的代码可复用、最后还是开了一个全新代码库,这些都在第三篇里。


© Xingfan Xia 2024 - 2026 · CC BY-NC 4.0