运动数据与 AI 产品可信度——从“展示数字”到“支持决策”

一、承上启下：服务对了人，为什么还会失去信任？

上一讲，产品经理终于决定不再用一套训练计划服务所有跑者。他选择先帮助“有 5 公里或 10 公里目标、尚未形成稳定训练习惯”的用户建立连续训练。

新版本上线后，用户会在每次训练后看到一张“训练状态卡”：绿色代表可以按计划继续，黄色代表建议降低强度，红色代表建议休息。

看起来简单、友好、也符合入门用户的理解能力。

但三周后，产品经理再次收到投诉：

• “我昨天只跑了 20 分钟，为什么你让我休息？”

• “我感觉状态很好，系统却给我黄色，它到底懂不懂我？”

• “这个颜色是根据什么来的？是不是随便算的？”

• “我按照建议休息了，第二天还是累。那我为什么要听它的？”

用户不是在反对一个颜色，而是在问一个非常严肃的问题：我是否应该把自己的行为交给这个系统影响？

这也是所有数据、算法和 AI 产品共同面对的问题。一个系统能算出结果，不代表它已经成为一个好产品；一个结果在实验中有一定准确性，也不代表用户会相信、理解或正确使用它。

---

二、开场困境：同一条“恢复建议”，为什么三种用户都不满意？

请想象三个场景。以下人物和指标均为教学模拟案例。

场景一：跑完长距离后的严肃跑者。

用户刚完成一次长距离训练，手表提示“建议休息 48 小时”。他觉得这太保守：自己本来就知道要休息，而且想确认的是“明天能不能做轻量活动”。

场景二：轻松跑后的入门用户。

用户只是慢跑了 20 分钟，手表同样提示“建议休息 48 小时”。他觉得不合理，决定不再看建议。

场景三：连续高强度训练的用户。

用户已经连续几天训练负荷较高，系统却提示“状态正常”。他没有立刻受伤，但从此把这个功能当作装饰。

表面上，三个问题都可以归结为“算法不准”。但作为产品经理，我们不能在这里停止。

第一位用户需要的是更细的行动选择；第二位用户可能遇到了数据质量、个人基线或解释方式问题；第三位用户可能遇到了输入缺失、模型边界或风险控制问题。甚至有些用户不是要求绝对正确，而是希望系统在不确定时不要假装确定。

当你的产品影响训练、健康、金钱、安全或重要决策时，用户真正购买的不是一个数字，而是一种“我可以据此行动”的确定感。产品经理要设计的正是这种确定感，而不是一张看起来很科学的仪表盘。

---

三、核心概念：可信度不是准确率的同义词

3.1 用户感知的可信度由四件事组成

为了便于产品设计，我们把可信度拆成四个维度：

准确性当然重要，但只做到准确性远远不够。

一个对普通用户很难理解的指标，即使算法可靠，也可能没有价值；一个跨端口径不一致的分数，即使每一端都能自圆其说，也会破坏信任；一条无法执行的“建议注意休息”，只是把判断压力又还给用户。

3.2 数据产品与传统功能的差别

传统记录类功能往往有较清楚的输入和输出：用户记录一次运动，系统保存一次运动。算法或 AI 产品则不同：它要从不完整、有噪声、受场景影响的输入中，给出带有概率性质的解释或建议。

这会产生三个产品难题：

1. 输入并不总是可靠。 佩戴状态、设备版本、环境、缺失数据和用户自报信息都可能改变结果；

2. 输出并不是绝对事实。 一个建议通常代表系统在当前信息下的判断，而不是对未来的承诺；

3. 后果往往延迟出现。 用户今天采纳建议，明天是否感觉更好，可能受许多因素影响，难以简单归因。

所以，数据产品不应该用“系统替你做决定”的语气出现，而应成为“帮助你理解情况、做出更好决定”的工具。

3.3 不要用伪精确掩盖不确定性

“建议休息 47 小时 36 分钟”看上去很高级，实际可能比“今天建议降低强度，明天再评估”更不可信。数字越具体，用户越会把它理解为精确承诺。

产品经理要主动追问：

• 这个精度是模型真正能支持的吗？

• 数据不足时，系统会不会仍然给出同样确定的结论？

• 用户知道这条建议基于哪些信息、哪些信息没有被考虑吗？

• 用户能否告诉系统“我的体感与你不一致”？

可信不是把系统说得无所不知，而是让用户知道它知道什么、不知道什么。

---

四、方法论：从“算法输出”到“用户决策支持”的五步设计

4.1 第一步：先定义用户要做的决定

不要从“我们有 HRV、负荷、睡眠等数据”开始，而应从“用户现在要做什么决定”开始。

例如，跑后建议可能服务于以下不同决定：

• 明天是否训练；

• 训练强度是保持、降低还是暂停；

• 是否需要查看更详细的恢复信息；

• 是否应该寻求教练或医疗专业人士的帮助。

不同决定所需的信息、风险等级和表达方式完全不同。若没有明确决策，系统展示再多数据，也只是信息堆积。

4.2 第二步：明确输入、基线与适用边界

“你的训练状态偏低”必须回答三个隐含问题：与什么相比？基于什么输入？在哪些情况下不适用？

以运动状态为例，产品需要向团队定义：

这些不是“技术细节以后再说”，而是产品承诺的一部分。

4.3 第三步：按“行动—解释—证据”分层呈现

同一结果可以有三个表达层：

1. 行动层：今天可以做轻松活动，也可以完全休息；

2. 解释层：近期训练安排较密集，且昨晚的恢复数据不完整，因此系统建议保守安排；

3. 证据层：展示趋势、输入数据、历史对比、数据质量和计算口径。

入门用户大多停在行动层和解释层；希望深入的用户可以进入证据层。不要让所有人先理解专业术语，才能获得一个简单答案。

4.4 第四步：给选择与反馈，不给不可质疑的命令

低风险场景可以给明确引导；高影响场景则应保留用户的主体性。比如：

“系统建议今天选择轻松活动或休息。你也可以记录当前体感；若出现明显不适，请优先遵循专业人士建议。”

这不是为了写一行免责文案，而是让产品结构上允许用户提供新的信息、调整目标或拒绝建议。系统从用户那里学习，用户也通过系统理解自己。

4.5 第五步：设计信任验证闭环

用户不会因为第一次看到一个漂亮分数就建立信任。信任往往来自多次“我理解它、我试过、它在合理范围内帮助了我”的经验。

产品可以设计：

• 建议执行后的简单回访：这次安排是否符合你的体感？

• 关键异常时的解释：数据不足、设备佩戴异常或算法更新影响了什么；

• 长期趋势复盘：系统并非只给单次命令，而是帮助用户看到自己如何变化；

• 可纠正入口：用户能够更正训练类型、补充主观状态、报告明显异常。

这才是“从数据到信任”的闭环。

---

五、业务深度案例：HRV 与训练负荷如何从一堆数字变成行动支持

5.1 第一版：展示数字，用户看不懂

第一版恢复功能很“专业”：显示 HRV、静息心率、睡眠时长、训练负荷和一个恢复分数。研发很满意，认为数据非常完整；产品页面也做得很漂亮。

用户打开后最常问的是：“65 是高还是低？”“为什么这次和上次不一样？”“我到底能不能跑？”

产品意识到，产品把“数据收集与计算”误当成了“用户价值交付”。用户不需要证明系统知道很多指标；用户需要系统帮助自己在具体场景中减少判断成本。

5.2 第二版：只给颜色，用户开始反感

第二版把指标都藏起来，改成红黄绿三种状态。新手确实更容易理解了，但仍然出现抱怨：状态为什么是黄？我感觉很好，为什么不让我训练？

问题在于，简化不是删除解释。颜色降低了阅读成本，却也让系统看起来像一个不可解释的黑箱。

5.3 第三版：把建议做成可理解、可选择的支持

第三版重新设计为三层：

第一层，给用户下一步。

“今天建议选择轻松跑、散步或休息。若仍希望训练，请将强度控制在轻松可交谈的范围，并在结束后记录体感。”

第二层，告诉他为什么。

“系统观察到你最近几天训练较密集；昨晚睡眠记录不完整，因此建议偏保守。该结论不是医疗判断。”

第三层，让他查看并纠正。

用户可查看近几周的训练趋势，标记“今天感觉比平时好/差”，也可说明设备没有佩戴或本次运动类型被识别错误。

小马还加了一个很重要的规则：当数据质量不足时，系统不再给强结论。 它可以说“当前数据不足以生成个性化状态判断”，并提供基础训练常识或引导用户完成数据积累，而不是硬算出一个看似权威的分数。

这是一种看似“少给价值”的做法，实际上是在保护长期信任。

5.4 用一张表检查产品是否真的可信

---

六、本讲重点总结

上一讲我们解决了“服务谁”；这一讲解决了“用户凭什么信”。下一讲，即使一个建议本身可信，只要手表、App、云端给出的数据互相矛盾，信任仍然会迅速消失。于是问题从单项算法产品，进入了系统产品的世界。