老实说：当苹果首次宣布 Genmoji 时，我们 ViviDiary 产品团队经历了一阵集体恐慌。
多年来，我们整个追踪理念都是建立在约束之上的。您打开应用程序，点击五个核心心情之一（棒、好、一般、低落、糟糕），也许再点击几个标准表情符号来添加背景信息，然后就完成了。我们刻意保持约束，因为约束等于速度。
但 iOS 27 给我们的生态系统带来了一个巨大的难题。突然之间，用户不再局限于标准的 Unicode 表情符号集。他们可以输入“拿着小咖啡的疲惫鸽子”，系统就会立即生成一个自定义表情符号。
我们立刻意识到用户会想要这个功能。但我们也知道，无限的输入会破坏模式识别。当每一个数据点都是完全独特的 AI 生成图像时，您该如何构建每周洞察仪表板呢？
以下是关于我们如何为 ViviDiary 设计 genmoji 心情记录 ios 27 功能、我们遇到的技术障碍，以及为什么我们最终选择文本提示映射而不是保存图像资源的原因。
快速回答：ViviDiary 如何处理 iOS 27 Genmoji 心情记录 1. 用户在每日 3 秒的记录过程中选择一个 Genmoji（例如“疲惫的鸽子”）。 2. 我们捕获底层的文本提示，而不是沉重的图像资源。 3. 该提示经过去标识化处理，并去除了任何个人数据。 4. 系统将提示映射到标准的心情效价（例如“疲倦”、“低能量”）。 5. 去标识化的元数据被安全地保存在我们云端的 Supabase 架构中，以生成您的每周洞察。
---
iOS 27 的难题：当表情符号变得无限时
要理解这个问题，您必须了解 ViviDiary 在后台是如何运作的。我们是一个模块化的心情和生活追踪器。唯一必需的输入是您的核心心情。其他一切——备忘录、语音笔记、照片以及我们的 22 手动表情符号类别——都是严格可选的。
标准表情符号的美妙之处在于它们充当了通用的、结构化的数据标签。如果您在一个月内三次记录 🌧️（雨）表情符号和 😞（难过）表情符号，我们每周的“镜像”功能可以温和地指出相关性。这背后有真正的心理学依据；记录表情符号背后的科学在很大程度上依赖于一致的情感标记。
Genmoji 打破了这种一致性。
在 ios 27 健康应用设计 的早期测试中，我们看到用户创建了极其具体的情感化身。一位用户生成了一个“画着笑脸的瘪气球”。另一位用户创建了一个“正在振动的咖啡因松鼠”。
这些是复杂人类情感的绝佳、高度准确的表达。但对于数据库来说，“瘪气球”和“振动松鼠”只是随机的图像文件。它们没有任何关系价值。如果我们只是让用户将这些放入他们的每日记录中，我们将彻底破坏使 ViviDiary 首先变得有用的模式发现功能。
我们拒绝了什么：原始图像资源的陷阱
我们的第一个原型采取了阻力最小的路径：直接将 Genmoji 图像资源保存到用户的每日记录中。
我们构建了它，在内部进行了测试，并在不到一周的时间内就放弃了它。
以下是我们拒绝它的原因：
- 数据库臃肿： 一个标准的 Unicode 表情符号占用大约 4 字节的存储空间。一个生成的 Genmoji 图像资源大约是 50-100 KB。如果用户每天记录三个自定义表情符号，那么每个用户每年就是 100 MB 的纯粹臃肿。将其乘以我们的用户群，我们的服务器成本将飙升，却没有任何功能上的好处。
- 性能下降： ViviDiary 速度很快。当我们之前重新设计主屏幕时，我们明确优先考虑两秒交互而不是沉重的 UI 元素。每次打开日历视图时加载自定义图像资源网格会导致明显的卡顿。
- 黑盒问题： 如果我们只保存图像，我们就不知道它意味着什么。我们无法在您的每周“镜像”中将“疲惫的鸽子”与“疲倦的狗”归为一类。数据变得视觉丰富，但在分析上毫无用处。
我们意识到我们把问题想反了。Genmoji 的价值不在于图像。价值在于图像背后的意图。
对提示到效价的映射进行 A/B 测试
我们决定捕获用户输入以生成 Genmoji 的文本提示，而不是保存图像。
苹果的 API 允许开发者访问 Genmoji 的描述性文本。因此，当用户放入那只疲惫的鸽子时，我们不保存 PNG。我们保存字符串：`"exhausted pigeon holding a tiny coffee"`。
但我们仍然需要对其进行分类。这让我们回到了去年做出的一个核心产品决策，即为什么我们取消了心情表情符号，转而采用基于文本的效价映射。
我们对 400 名测试用户进行了 A/B 测试，看看我们如何将这些自定义提示映射到我们标准的 5 级心情量表（棒、好、一般、低落、糟糕）以及我们现有的表情符号类别。
* A 组（对照组）： 用户记录 Genmoji，我们将其保存为原始图像。没有模式映射。
* B 组（测试组）： 用户记录 Genmoji。我们提取文本提示，通过一个轻量级的、去标识化的分类脚本，并将其映射到核心效价（例如，“疲惫的鸽子”映射到“低能量”）。
结果：
B 组在 14 天的时间内更好地保持了他们的记录习惯 38%。为什么？因为在周末，B 组收到了一份真正了解他们的“镜像”报告。应用程序能够说：“我们注意到在您记录与‘疲惫’相关的自定义表情符号的日子里，您的能量处于低落状态。” A 组只得到了一堆奇怪的图片。
通过专注于提示而不是像素，我们成功地支持了无限的 自定义表情符号心情追踪，而没有丢失使应用程序正常工作的结构化数据。
数据架构：Supabase 中的去标识化云存储
每当您在日记应用程序中引入 AI 或提示处理时，您都必须谈论隐私。
目前健康应用领域有一种巨大的趋势，即对绝对隐私做出广泛的声明。我将对您完全透明：我们使用安全的云存储并对您的文本进行去标识化处理，我们相信真正的隐私来自数据最小化。
ViviDiary 依赖于构建在 Supabase 上的隐私优先云架构。您的数据是云存储的。
为什么？因为真正的隐私不是来自假装云不存在；它来自严格的数据最小化和去标识化。
当您记录像“对我的老板感到沮丧”这样的 Genmoji 提示时，我们的架构中会发生以下情况：
- 提示在边缘与您的用户身份 (UUID) 分离。
- 原始文本在离开应用程序之前，使用本地正则表达式过滤器去除了任何可识别的名词。
- 去标识化的字符串 (`"frustrated with [REDACTED]"`) 被发送到我们的 Supabase 后端。
- 我们的后端对情绪进行分类（效价：糟糕，标签：沮丧）。
- 只有分类后的元数据和原始的、加密的提示存储在您的云数据库中。
我们在云端处理此问题，因为它允许我们运行比手机本地处理器所能处理的更准确的分类模型，而不会耗尽您的电池。我们的 AI 功能是严格可选的，不是因为我们在本地隐藏数据，而是因为 ViviDiary 的核心价值是 3 秒的记录。AI 只是为您想要更多深度的日子提供的一个可选助手。我们从不保存或确认 AI 生成的内容，除非经过您的明确审查。
为什么核心记录必须保持在 3 秒以内
最终，我们构建的每一个功能都必须经受住时间的考验。
我们从内部指标中得知，如果每日签到时间超过 30 秒，用户留存率就会大幅下降。这就是为什么我们不做压力式的连续记录。我们不做完成百分比。我们不发送“您错过了昨天！”的内疚通知。
如果您使用我们的“专注”模块（默认关闭），例程只是您想要注意的事情，待办事项只是您勾掉的事情。错过一天没有任何惩罚。
ViviDiary 对所有输入模块、无限心情和表情符号记录、3 个月的日历存档、您的每周“镜像”以及最多 3 个例程 / 5 个待办事项完全免费。（我们确实有一个高级层级，价格为 $2.99/月或 $11.99/年，可解锁更深的历史存档和无限的专注项目，但核心体验是完全免费的）。
集成 Genmoji 有可能减慢整个过程。用户很容易在花费五分钟制作完美的自定义表情符号中迷失方向。
为了应对这种情况，我们将 Genmoji 流程深度集成到了我们的基于手势的心情记录系统中。您滑动到您的核心心情，键盘会立即显示您最近使用的 Genmoji 以及标准表情符号，您点击一下，就完成了。
如果您想花时间生成一个新的，您可以这样做。但无摩擦的路径仍然保持在 3 秒以内。
接下来是什么
我们目前正在向我们的 TestFlight 测试组推出提示到效价的映射功能。目前最大的挑战是处理边缘情况——比如当用户生成一个“快乐流泪的小丑”的 Genmoji，而我们的分类引擎不太确定这是“好”的一天还是“糟糕”的一天。
但这正是产品设计的乐趣所在。您构建约束，用户找到打破它们的美妙方式，然后您调整系统以迎头赶上。
一旦 iOS 27 公开发布，我们下个月将分享更多关于用户如何与自定义表情符号交互的数据。在此之前，请保持您的记录速度，不要担心打破您的连续记录。
