返回 Kriki Coach 产品蓝图
Reference Material / Fitbit

Fitbit 用户评价调研

这份材料聚焦 Google Health / Fitbit 新体验的公开用户反馈：用户并不反对 AI Coach，但反对 AI 在还没有创造更高价值之前，占用更多空间、时间和控制权。

01 / 证据边界

早期反馈足够暴露产品结构矛盾。

Google Health 正式替代 Fitbit App 的时间还很短，目前能看到的主要是老 Fitbit 用户公开反馈、媒体评测和 Fitbit Air 新用户试用，不是大规模满意度统计。但这些反馈已经足够暴露产品结构上的关键矛盾。Google 也迅速修改 Today 页、恢复指标自定义和缺失功能，说明不少抱怨不是个别噪声。

方面 用户具体感受 具体表现 主要用户 判断
迁移后的第一印象 原来的 Fitbit 被“强行换成”一个不熟悉的新产品。 老用户需要重新找入口、重新理解页面结构。 长期 Fitbit 用户 明显负面，旧心智被打断。
AI Coach 过度突出 Coach 不像可选工具，而像整个 App 的主角。 Today 页数据区域被缩小，下面直接接 AI 对话框，继续向下还有多块 AI 洞察和继续提问入口。 老用户、只想看数据的用户 负面居多；AI 积极用户认为是真升级。
AI 太啰嗦 不是一句判断，而是连续解释、总结、追问。 初始化大段能力说明；晨间长文复述睡眠、恢复和天气，再给预设回复引导继续聊天。 轻量用户、部分评测者 负面；深度用户有时认为详细才有价值。
正确但没用 Coach 经常把已经可见的数据重新说一遍。 例如已经看到睡了八小时，AI 又写一段“你睡了八小时、恢复不错”。 目标不明确、只记录基础指标的用户 明显负面。
数据变得更难找 AI 未替代数据，却让数据入口更深。 以前 Today 页能直接看运动天数，现在可能要进入多层页面。 老 Fitbit 用户 强烈负面。
关闭 AI 的控制感不足 能关闭功能，不等于能移除界面。 某些 Ask Coach / 活动区域仍可能占位。 不想用 AI 的用户 形成产品强推感。
02 / AI 太啰嗦与过度突出

问题不是字数本身，而是信息层级错了。

Google 的困难在于：短了容易变成空泛总结，长了又挤压核心数据和行动。这不是单纯调整字数能解决的，而是必须重新定义信息层级：先给结论和动作，用户主动展开时再给完整证据。

啰嗦的几种表现

  • 能力说明过长：用户还没得到价值，就先付出阅读和回答成本。
  • 复述已有指标：感觉 AI 只是把图表翻译成文章。
  • 解释超过行动价值：阅读成本大于建议本身。
  • 主动追问过多：对轻使用者像额外作业。
  • 同类建议重复：让用户怀疑它是否真正理解场景差异。

过度突出的位置

  • Today 页直接把 AI Chat 放在关键数据区域附近。
  • 某些 AI 晨间文本占据约三分之二首屏。
  • 睡眠等洞察模块下继续提供 AI 分析和对话提示。
  • 旧版纵向浏览指标被压缩、横向滑动或转移到更深页面。
  • 用户只是打开 App 查数据，Coach 就可能主动发起计划讨论。
AI 不能用“更详细”来证明自己有价值。真正有价值的是更快做出判断，并在需要时能展开依据。
03 / 老用户与新用户

新用户没有迁移成本，但也不等于更满意。

用户类型 典型感受 原因
老 Fitbit 数据型用户 最不满，希望恢复旧版。 已形成固定肌肉记忆：打开 Today 快速看步数、睡眠和运动；新版让入口变深，并用 AI 内容占用空间。
老 Fitbit 轻量用户 觉得产品变复杂。 原本只需要基础记录，现在要面对 Coach、对话、目标设置和更多信息层级。
Fitbit Air 新用户 对界面抵触通常较小。 没有旧版心智，购买时已知道它与 Google Health / AI Coach 配套；基础追踪免费，AI 可以不深度使用。
主动寻求训练计划的新用户 评价相对积极。 可以提供器械限制、旅行安排、训练目标，然后让 Coach 调整周计划，价值直接可见。
高自我量化用户 可能获得最强价值，也承担最高成本。 愿意输入病史、目标、药物、化验和多数据源，建议明显更个性化，但维护上下文很累。
不愿输入背景的普通新用户 更容易觉得 AI 笨或都是常识。 Coach 缺少生活背景、健康史和明确目标，只能用通用规则给建议。
04 / 用户认可的地方

用户喜欢的不是 AI 说得多，而是 AI 真的改了方案。

结合现实调整训练

出差、无法去健身房时，Coach 重新安排目标或取消当周计划。价值在于现实变化后改方案，而不是解释数据。

考虑设备和环境限制

在酒店只有特定器械时，基于现有条件生成训练。建议具体、可执行，而不是模板内容。

伤病后的持续记忆

受伤后删除力量训练，一周后 Coach 主动询问是否恢复，体现跨时间跟进。

通过对话修正记录

用聊天补录遗漏的睡眠，比手动寻找编辑入口更方便。

复杂时期的负荷降级

疲劳或药物影响下，把目标降低，调整为轻力量和低冲击有氧。

数据有来源

给出建议时附带研究或专业来源，提高健康解释可信度。

用户不喜欢 AI 复述身体数据，但喜欢 AI 在现实发生变化时替他改计划。
05 / 深度使用断点

真正危险的是 AI 对话层与产品状态没有打通。

问题 具体表现 影响
初始化成本过高 官方初始对话约 5-10 分钟；深度用户还要投入数小时说明目标、病史、药物和检查信息。 普通用户很难坚持完成。
需要持续教育 Coach 用户状态、药物和目标变化后，需要不断补充和纠正。 Agent 没有减轻负担，反而增加管理工作。
会遗忘上下文 已输入的健康背景，下一次交互可能又回到旧数据，需要用户提醒。 破坏长期教练的信任感。
AI 和传统系统状态不一致 Coach 已把目标从每日一万步调到五千步，但 App 某些页面仍显示一万步。 暴露对话层和底层产品状态未真正打通。
对输入量高度敏感 输入丰富数据的用户得到较好计划；不提供背景的人觉得 Coach 很差。 体验差距巨大，难以形成稳定口碑。
安全与幻觉担忧 App 明确提示 AI 可能出错、不能作为医疗建议，公开反馈也有幻觉投诉。 用户不敢把真正重要的决策完全交给 Coach。
06 / 对 Kriki 的直接结论

Kriki 必须避免“AI 先抢位置，再证明价值”。

Google Health 暴露的问题 Kriki 应如何处理
AI 抢占数据入口 Coach 给结论，但数据依据必须一层可达；用户可决定首页更偏 Coach 还是偏数据。
长文才能体现深度 首层只显示“判断 + 行动”，原因按需展开，不把深度等同于字数。
新用户不给背景就很通用 首次设置轻量化，使用中按场景逐步补充上下文；能自动获得的不要反复问用户。
AI 对话修改不能真正改变系统状态 Kriki 的对话必须直接连接计划、提醒、目标和记忆，不能只在聊天里口头答应。
Coach 会忘记或使用旧信息 记忆必须区分当前事实、长期事实和过期信息，并有冲突修正和有效期。
用户不想聊天却被迫面对聊天 对话是协商方式之一，不是唯一入口；用户可以直接接受、修改、拒绝或查看依据。
通用建议反复出现 建议必须关联现实约束、预期结果和验证时间，否则宁可不说。
最值得 Kriki 吸取的一条：用户不是反对 AI Coach，而是反对 AI 在没有创造更高价值之前，占用更多空间、时间和控制权。