Kriki Coach · 产品功能规划

Kriki Coach 产品功能规划

版本：V0.2
文档状态：产品功能规划稿
更新时间：2026-07-22
依据：《概要设计》产品功能规划大纲

一、产品整体结构

1. 产品定义

Kriki Coach 是一个持续理解用户身体状态、生活节奏和个人目标，并据此规划、跟踪和调整每日行动的个人 AI Coach。

产品不是由若干独立的健康功能组成，而是由一个持续运行的 Kriki Agent 组织所有能力：

2. 产品功能架构

flowchart TB
    A["初始化：第一次认识用户"] --> B["Kriki Agent：持续理解与决策中枢"]
    C["Apple Health 与用户反馈"] --> B
    D["目标、习惯、规划与偏好"] --> B

    B --> E["首页：当前判断与协作入口"]
    B --> F["每日计划：今天正式做什么"]
    B --> G["查看今日数据：今天为什么这样判断"]
    B --> H["全量数据列表：长期数据与记录"]
    B --> I["个人中心：帐号、权限与产品设置"]

    B --> J["系统通知"]
    B --> K["iOS 小组件"]
    B --> L["Apple Watch 协同"]

    F --> M["实际执行与反馈"]
    M --> B

3. App 内部功能

功能 核心作用 与 Agent 的关系
初始化 建立首次可用的用户认识 为 Agent 建立初始上下文
智能体 管理 Kriki 身份、关系和对用户的认识 Agent 本体及管理入口
首页 呈现当前判断、行动和需要协商的事项 Agent 的主要工作界面
每日计划 管理当天正式生效的行动安排 Agent 决策的执行载体
查看今日数据 查看今天状态及判断依据 Agent 当前判断的解释层
全量数据列表 查看健康、行动、计划和反馈记录 Agent 长期认识的事实来源
个人中心 管理帐号、权限、提醒和通用设置 Agent 运行条件管理

4. App 外部功能

功能 核心作用 适合承载的内容
系统通知 在需要用户及时知道或行动时触达 计划提醒、重要变化、待确认事项
iOS 小组件 低成本查看当前重点 当前状态、下一行动、今日进度
Apple Watch 在行动发生时提供即时协同 查看下一行动、开始/完成、身体反馈

二、Kriki Agent 的产品架构

1. Agent 在产品中的位置

用户面对的始终是一个 Kriki，而不是多个不同名称、不同人格的智能体。

Kriki 内部按能力组织，但不在界面上表现为多个 Agent。这样既保持人格、记忆和关系的一致性，也能让不同任务由适合的能力模块完成。

Agent 的产品架构由五部分组成：

  1. Kriki 身份与关系。
  2. 用户上下文。
  3. Agent 能力模块。
  4. Agent 运行与任务组织。
  5. 安全与产品边界。
flowchart TB
    A["用户可见的唯一 Kriki"] --> B["Agent 调度中枢"]

    C["身份与关系"] --> B
    D["用户上下文"] --> B
    E["确定性数据与算法"] --> B
    F["安全边界"] --> B

    B --> G["理解当前情境"]
    B --> H["判断身体状态"]
    B --> I["形成洞察与策略"]
    B --> J["与用户协商"]
    B --> K["生成并调整计划"]
    B --> L["验证结果与学习"]

    G --> M["首页与对话"]
    H --> M
    I --> M
    J --> M
    K --> N["每日计划与 App 外触点"]
    L --> D

2. Kriki 身份与关系

2.1 形象与入口

2.2 称呼

2.3 熟悉度与亲密度

熟悉度表达“Kriki 对用户了解到了什么程度”，亲密度表达“用户与 Kriki 的持续互动关系”。界面可以统一使用“火花”呈现，但产品内部需要区分两者。

熟悉度主要由以下行为增加：

亲密度主要由以下行为增加：

长时间不使用时，火花可以缓慢减弱，用于表达关系暂时疏远；但已经确认的用户资料、习惯和偏好不会因此被删除。重新使用后，Kriki 应表现为“继续认识和陪伴”，而不是责备用户中断使用。

火花不用于限制核心功能，不设计付费式等级特权，也不以焦虑方式催促用户维持连续使用。

3. Agent 管理内容

“我的 Kriki”用于让用户查看和管理 Kriki 如何理解自己，主要包含四类内容。

3.1 习惯清单

习惯是用户在特定情境下重复发生的行为，不等同于用户明确设置的计划。

习惯分为：

习惯示例：

每条习惯需要让用户看懂：Kriki 观察到什么、通常在什么情况下发生、当前强度、最近是否仍然成立。

用户可以确认、修改、暂停或删除习惯。用户否认后，Kriki 不再按原规律安排计划，除非后续再次出现新的稳定证据并重新询问。

3.2 长期目标

长期目标采用固定选项，保证 Agent 可以稳定理解和持续跟踪。首版候选包括：

用户可以选择一个主要目标和若干辅助目标。主要目标用于处理目标冲突，例如“提升体能”和“保护恢复”冲突时，Kriki 仍应先遵守当天安全与恢复边界，再在长期计划中补回训练安排。

3.3 中短期规划

中短期规划是用户为了长期目标正在推进的一段阶段性安排，例如：

规划至少表达：要达成什么、预计持续多久、目前处于什么阶段、哪些现实限制已经明确。

每日计划应服务于中短期规划，但不能为了完成规划突破当天身体状态和安全边界。中短期规划受到现实影响时，Kriki 应调整进度或节奏，而不是每天机械追赶原目标。

3.4 偏好与记忆

偏好是用户明确表达或多次行为验证后形成的选择倾向，例如：

记忆分为三类：

“我的 Kriki”应清楚区分已确认和正在观察的内容。用户可以纠正或删除任何会影响未来决策的记忆。

三、Agent 的上下文组织

Agent 每次运行时，不读取所有历史信息，而是根据当前任务组织一份足够完成本次判断的上下文。产品上分为五层。

1. 身份基础层

相对稳定的信息：

用途：决定判断的基础条件和长期方向。

2. 长期认识层

经过用户确认或多次验证的信息：

用途：让同样的数据对不同用户产生不同理解。

3. 阶段规划层

当前一段时间内有效的信息：

用途：决定今天的行动在较长规划中承担什么作用。

4. 今日情境层

当前业务日内变化的信息：

用途：形成当前状态、今天的策略和剩余计划。

5. 当前任务层

只与本次运行有关的信息：

用途：避免 Agent 每次重新思考所有问题，使每次运行有明确目标。

6. 上下文使用原则

  1. 当前安全信息优先于所有历史认识。
  2. 用户刚刚明确表达的条件优先于从历史推测的偏好。
  3. 已确认记忆优先于候选认识。
  4. 只选择与当前任务有关的信息进入本次判断。
  5. 历史习惯只能作为判断依据，不能替代用户当天的真实意愿。
  6. 当不同层信息冲突时，Kriki 应明确冲突，并决定直接处理还是询问用户。

四、Agent 的能力组织

用户看到的是同一个 Kriki，内部由六类能力共同完成工作。

1. 情境理解能力

负责回答：现在发生了什么，哪些信息与本次任务有关。

主要工作：

产出：供后续判断使用的当前情境。

2. 状态分析能力

负责回答：用户现在处于什么状态，可以做到什么程度。

主要工作：

精确指标、基线和负荷由算法负责；Agent 负责综合解释，不自行发明数值。

3. 策略与规划能力

负责回答：在当前状态、长期目标和现实条件下，今天应该采用什么方向。

主要工作：

4. 协商与沟通能力

负责回答：哪些条件必须由用户决定，怎样与用户达成一致。

主要工作：

5. 执行管理能力

负责回答：计划是否正在发生，现实变化后下一步做什么。

主要工作：

6. 复盘与学习能力

负责回答：这次判断和安排是否有效，Kriki 应该学到什么。

主要工作：

五、Agent 的运行机制

1. Agent 不是持续调用模型，而是持续管理状态

Kriki 持续运行不等于大模型一直运行。

产品需要持续接收事件、维护最新状态和判断是否需要行动；只有需要理解、权衡、协商或生成新方案时，才运行 Agent 的推理能力。

普通数据同步、指标计算、明确的计划状态更新和安全规则，由确定性能力完成。

2. Agent 完整运行循环

flowchart LR
    A["事件发生"] --> B["判断事件是否与当前状态或计划有关"]
    B -->|"无关"| C["记录变化，结束"]
    B -->|"有关"| D["组装本次任务上下文"]
    D --> E["调用数据与算法能力"]
    E --> F["判断需要哪种运行模式"]
    F --> G["Agent 理解、权衡与生成结果"]
    G --> H{"需要用户决定吗"}
    H -->|"需要"| I["提出一个关键问题"]
    I --> D
    H -->|"不需要"| J["发布状态、策略或计划"]
    J --> K["安排页面更新与必要触达"]
    K --> L["等待执行和新事件"]
    L --> M["验证结果"]
    M --> N["更新候选认识或长期记忆"]
    N --> A

3. 六种运行模式

3.1 数据维护模式

适用：Apple Health 普通更新、数据补齐、用户打开 App 检查最新数据。

处理：更新事实和指标，判断是否影响当前状态或计划。

Agent：通常不参与。

结果：数据时间更新，或进入其他运行模式。

3.2 状态更新模式

适用：睡眠完成、恢复指标变化、新训练产生、用户提交身体反馈。

处理：重新理解情境并形成当前状态、主要原因和行动边界。

Agent：负责综合与解释。

结果：首页状态和依据更新；不一定生成新计划。

3.3 主动决策模式

适用：晨间首次安排、状态变化可能影响当天行动、原计划已不适用。

处理：在目标、状态、规划和现实条件之间权衡，形成行动策略。

Agent：负责洞察、策略和备选方案。

结果：直接生成可确认方案，或进入协商模式。

3.4 协商模式

适用：缺少会改变计划的信息，或用户接受、拒绝、修改方案。

处理：提出关键问题、理解回答、更新当前条件。

Agent：负责对话理解和冲突处理。

结果：生成用户确认后的条件，并返回主动决策或计划生成。

3.5 执行管理模式

适用：计划即将开始、训练完成、计划偏离、时间或身体状态变化。

处理：更新执行状态，判断是否保留、缩短、替换、延后或取消剩余任务。

Agent：只在需要重新规划或解释复杂偏差时参与。

结果：执行状态或更新后的剩余计划。

3.6 复盘学习模式

适用：当日结束、次日恢复数据到达、同类情境重复出现。

处理：验证判断、策略和计划，形成候选认识。

Agent：负责归因、总结和提出待用户确认的经验。

结果：复盘、候选习惯、偏好或身体响应规律。

3.7 同一 Agent 的分级运行

运行级别不是用户活跃度等级，而是根据本次需求的必要性选择处理方案。通知、普通更新和完整规划仍由同一个 Kriki Agent 统一管理；轻度、正常和重度只表示各类事件发生的频率。

运行级别适用情况处理方式典型上下文与频次
通知发送已确认的训练提醒、睡前提示或已有结论使用计划生成时预产出的时间、条件和短文案，到点直接触达；默认不临时调用模型0–1K Context；5–8 次/天
普通更新状态、刷新首页表达、解释不改变计划的轻微变化只传当前状态和最新变化，完成状态更新或轻量表达2–4K Context；3–5 次/天
完整晨间计划、现实冲突、用户协商、剩余计划重新安排读取足量状态、目标、计划和现实条件，重新完成洞察、策略或计划10–15K Context；1–2 次/天

升级规则：事件只有在改变当前状态、主要原因、行动边界或剩余计划时，才从数据维护升级；只有后续行动需要重新选择时，才进入完整运行。

4. 运行优先顺序

同一时间出现多个事件时，按以下顺序处理：

  1. 疼痛、生病和其他安全事件。
  2. 用户正在等待的直接输入或操作。
  3. 即将执行但可能已经不适用的计划。
  4. 会改变当前状态或行动边界的新数据。
  5. 普通执行跟踪和数据更新。
  6. 日终验证、历史整理和候选经验学习。

高优先事项到达后，尚未展示的低优先结论不再发布，避免用户先看到旧结论再被立刻推翻。

5. Agent 何时不运行

以下情况不需要 Agent 推理：

6. Agent 运行后的产品动作

Agent 每次运行不是只返回一段文字，而是根据任务形成一个或多个产品动作：

所有产品动作必须明确下一步：等待用户、等待执行、等待新数据或等待次日验证。

六、初始化

1. 初始化目标

初始化不是完成一份长问卷，而是让 Kriki 获得第一次提供有效建议所需的最小认识，并告诉用户后续会在使用中继续学习。

2. 初始化步骤

2.1 健康数据授权

2.2 生成基础画像

Kriki 从近期数据形成初步认识：

初步认识必须标注“正在了解”，不能作为已确认习惯直接影响重要计划。

2.3 选择长期目标

用户选择一个主要目标和可选辅助目标。Kriki 说明该目标会如何影响后续建议。

2.4 补充日常状态与偏好

只询问健康数据无法获得、但会直接影响建议的内容：

2.5 首次认识确认

Kriki 用简短方式总结：我目前知道什么、还在了解什么、接下来能为你做什么。用户可以纠正后进入首页。

七、首页与智能体协作

1. 首页定位

首页是用户与 Kriki 共同管理今天的工作台，不是健康数据总览。

首页优先回答：

2. 首页结构

2.1 Kriki 形象区

2.2 当前状态

2.3 Kriki 当前观点

2.4 当前行动

2.5 协商区

2.6 今日进度

3. 首页更新方式

八、每日计划

1. 每日计划的定位

每日计划是 Kriki 与用户共同确认后，当前正式生效的当天行动安排。建议未被确认前，不视为正式计划。

2. 计划构成

计划可以包含：

每项计划说明做什么、何时做、做多久、做到什么程度、何时停止，以及无法执行时的替代方式。

3. 计划生成来源

4. 计划状态

5. 动态调整

现实变化后，Kriki 保留已完成和仍有效的部分，只调整受影响的剩余计划。页面必须说明调整原因、变化内容和当前最重要行动。

九、查看今日数据

1. 页面定位

今日数据不是把所有指标铺给用户，而是解释 Kriki 今天为什么这样判断。

2. 内容结构

3. 与首页关系

首页展示结论；今日数据展示依据。用户从当前状态或“为什么”进入，返回后继续保留首页上下文。

十、全量数据列表

1. 页面定位

全量数据列表用于查看长期记录和追溯 Kriki 的认识来源，不承担首页的即时决策任务。

2. 数据分类

3. 查看方式

十一、个人中心

个人中心管理不属于 Kriki 个性认识本身的通用产品设置：

目标、习惯、规划和偏好放在“我的 Kriki”，不与通用设置混在一起。

十二、App 外部协同

1. 系统通知

通知只用于用户需要及时知道或及时行动的事项：

普通数据更新、分数变化和没有行动价值的洞察不通知。

2. iOS 小组件

小组件优先展示：

小组件不承载复杂解释和长对话，点击后进入对应 App 内容。

3. Apple Watch 协同

Apple Watch 适合发生在行动现场的轻交互：

复杂判断、计划协商和记忆管理回到 iPhone 完成。

十三、核心业务闭环

1. 第一次使用

连接 Apple Health → 读取近期数据 → 用户选择目标并补充日常情况 → Kriki 生成初步认识 → 用户确认 → 进入首页。

2. 每日运行

新数据到达 → Kriki 更新当前状态 → 形成今日洞察和策略 → 必要时与用户协商 → 生成正式计划 → 跟踪执行 → 动态调整 → 日终和次日验证。

3. 长期学习

重复观察 → 形成候选习惯或偏好 → 继续验证 → 询问用户 → 更新“我的 Kriki” → 影响后续判断和计划。

十四、第一阶段建议边界

第一阶段优先完成一条完整闭环：

  1. Apple Health 初始化与近期数据读取。
  2. 用户目标和基础偏好输入。
  3. Kriki 形象区及“我的 Kriki”基础管理。
  4. 晨间状态、核心洞察和行动方案。
  5. 用户接受、调整和补充信息。
  6. 每日计划生成与基本执行跟踪。
  7. 计划变化后的动态调整。
  8. 今日数据依据页。
  9. 关键通知与 Apple Watch 基础协同。
  10. 当日复盘、次日验证和候选记忆。

全量数据的复杂趋势分析、丰富关系养成、自动中短期规划、多类小组件和高级 Watch 交互可以后续逐步扩展。

十五、下一步需要继续定义的问题

  1. Kriki 形象及火花的具体视觉与状态变化。
  2. 熟悉度和亲密度是否统一对用户展示，以及火花增减规则。
  3. 长期目标的正式选项和主次目标冲突规则。
  4. 习惯从“正在观察”升级为稳定习惯的产品条件。
  5. 中短期规划由用户创建、Kriki 建议还是双方共同生成。
  6. 首页第一屏在不同阶段的内容优先级。
  7. Agent 六种运行模式分别允许产生哪些产品动作。
  8. 每日计划的最小内容和计划调整确认规则。
  9. 今日数据与全量数据的信息层级和可视化方式。
  10. iPhone、通知、小组件和 Apple Watch 之间的任务承接规则。