# Kriki 产品重新定义与功能蓝图

版本：V0.1 · 讨论稿  
日期：2026-10-21  
范围：产品定义、核心服务逻辑、功能蓝图与首轮原型方向。不是实施级 PRD，也不是对现有原型页面的修补。

本稿以本轮提出的新方向为出发点，结合三份说明材料及 HTML 原型的内容与交互规则重新判断。材料中的定位、功能、商业假设均视为过程产物，不自动成为本稿的结论。以下“建议”是待讨论的产品判断，不代表已经得到用户或科学验证。

## 一、我的核心判断

Kriki 不应该只是从“恢复与训练”扩充为“工作、生活、健康”三个栏目。

真正值得改变的是它与用户的关系：

> 从解释身体、给出健康建议，转向理解用户正在经历什么、当前承受得怎么样，并持续协助用户安排事情、应对变化和照顾自己。

用户交给 Kriki 的不只是日程和健康数据，而是一部分“兼顾重要事情与自身状态”的协调负担。

这是一种成立的 Personal AI 方向，但它成立的理由不是 Personal AI 正在流行，而是现有信息之间存在断层：日程知道我要做什么，身体数据反映部分身体反应，我自己知道事情的意义和实际感受，却仍要独自把它们联系起来，反复做取舍。

Kriki 要承担的，正是这部分联系、协调和后续跟进。

### 1.1 一句话定义

**Kriki 是一个以个人状态为中心、连接真实事务与身体反馈的 Personal AI。它理解用户的目标、处境和感受，结合可用的生理数据，持续协助用户安排与推进重要事情、应对变化，并找到更适合自己的日常节奏。**

这里的“推进”，主要是帮助用户判断怎么做、什么时候做、如何调整与跟进，不是替用户完成所有专业工作或生活事务。

### 1.2 它最终服务什么

不是让用户一直保持高分，也不是让用户每天完成更多任务，而是：

> 把重要的事情做好，也把自己照顾好；在真实生活中，保持值得且可持续的投入。

有些重要事情确实值得疲惫，有些训练会带来短期消耗，有些家庭和生活安排不能被工作效率替代。Kriki 应帮助用户理解和承担这些取舍，而不是把“少消耗”当作唯一正确答案。

保持年轻、巩固健康与改善活力仍然是长期价值，但不需要把每次使用都包装成训练、恢复或逆龄。

### 1.3 这次重定义的实际变化

| 层面 | 原有重心 | 新的重心 |
| --- | --- | --- |
| 理解对象 | 身体指标、训练与恢复行为 | 正在经历的事情、个人感受，以及身体反应 |
| 核心问题 | 今天恢复怎样，应该练多少 | 今天在意什么、能怎样推进、有什么需要照顾 |
| 帮助方式 | 健康解读与行动建议 | 理解交代、协商安排、持续跟进与局部调整 |
| 日计划 | 健康任务的集合 | 用户事务与必要健康行动共同形成的现实安排 |
| 个性化 | 根据指标调节训练与恢复 | 根据目标、处境、偏好及真实反馈调整帮助方式 |
| 使用关系 | 查数据、看建议、做任务 | 交代事情，有人记着；变化之后，不必从头解释 |

## 二、用户为什么需要它

### 2.1 首要服务的人

建议先聚焦：**工作与生活要求经常变化，既想把事情做好，也在意精力、身体和长期活力的人。**

他们不一定是运动爱好者，也不一定愿意维护复杂的效率系统。典型困扰是：

- 事情很多，重要程度与可调整程度不同，身体和精力并不总与安排匹配。
- 我知道自己累，却不清楚哪些安排值得改、该怎么改。
- 我把情况告诉过工具，但下一次变化时，它又像第一次认识我。
- 我做了许多事，却不太了解哪种日常节奏更适合自己。

拥有可用的穿戴数据是有利条件，不应是获得第一份价值的前置门槛。

### 2.2 用户真正要完成的事

> 当我有重要事情要推进，同时还要顾及自己的身体和精力时，我把承诺、目标及变化交代给 Kriki。它帮我判断下一步、提出可采用的安排；事情或状态改变时，接着帮我调整并跟进结果，不用我每次重新解释，也不替我擅自放弃重要事情。

这个需求比“帮我生成一份日计划”更完整，也比“什么事都可以问的 AI”更有边界。

### 2.3 愿意透露信息的交换条件

用户不是为了“喂养 AI”而输入。每次交代至少应该产生一种可感知的回报：

1. **事情被接住。** 知道我交代的是哪件事，有什么需要留意，之后不会无故丢失。
2. **安排真的改变。** 出差、晚睡、重要汇报等信息实际影响建议，而不只出现在客套话里。
3. **变化有人继续处理。** 不必重新讲清整天背景，仍能协调后面的安排。
4. **经历变得可理解。** 能联系实际发生的事、感受和身体变化，帮助我观察自己。
5. **下次有所不同。** 过去的反馈能改变下一次相似情境的建议，而且可以被纠正。

如果一条信息既不影响理解、安排，也不值得跟进，就没有必要主动收集。

## 三、“状态”究竟是什么

### 3.1 不把所有东西压成一个分数

建议把三个对象明确分开：

| 对象 | 它回答什么 | 典型内容 |
| --- | --- | --- |
| 人的当前状态 | 我现在大致怎么样 | 身体恢复与疲劳、主观精力、清醒程度、心理负担等 |
| 现实要求与处境 | 我接下来要面对什么 | 截止时间、会议、出差、家庭承诺、体力与认知要求 |
| 个人目标与取舍 | 什么对我重要，愿意怎样投入 | 当前重点、长期健康目标、不可牺牲的边界、生活偏好 |

**产品协调的是这三者之间的关系；状态指数只能表达其中有证据支持的一部分。**

这一区别非常重要：日历排得满，不等于身体状态一定差；生理数据不错，不等于用户不疲惫；状态不佳，也不自动意味着重要事情应该取消。

“状态”不应扩张成涵盖事业、财务、关系和人生满意度的万能评分。

### 3.2 生理、感受和处境各自有价值

生理数据提供部分身体反应的证据；主观感受提供外部设备无法完整知道的体验；事务信息提供负担、意义和时间要求。

它们不必一致，也不能互相冒充：

- 用户说脑子很累，即使身体数据正常，也应认真考虑认知负担。
- 心率较高可能与运动、情绪、环境等有关，不能直接解释成工作压力。
- 用户觉得精神很好，不代表近期睡眠不足等事实可以被抹去。
- 一个会议占用两小时，只说明已知时间要求，不能直接当作实测消耗。

遇到分歧，Kriki 应明确说明看到了什么、还不知道什么，再提出适当建议，而不是让某个分数压过用户的真实感受。

### 3.3 健康仍是底层能力，不是被替换的旧包袱

工作与生活被纳入之后，训练、睡眠、恢复、活动与必要补给仍然重要。变化在于它们不再单独构成一套要求用户服从的健康程序，而要进入用户真实的生活条件。

例如，同样是改善活力，今天可能需要安排训练；也可能是保护睡眠、降低不必要的晚间负担，或者先把一件悬而未决的事情处理好。

但健康不是只为了支持更多工作。它本身就是需要被保护的目标，生活空间也不应成为所有任务竞争后剩下的边角料。

## 四、动态状态指数：保留方向，重新定义意义

### 4.1 我的建议

**保留动态状态指数的方向，但不要把“必须先做出一个万能新分数”作为整个产品成立的前提。**

建议它表达：

> 相对于自己的近期常态，当前身体与精力处于怎样的水平，以及这种判断有多少依据。

它不是精确剩余电量，不是工作能力分，也不是今天还有多少任务配额。

晨间恢复可以是一天开始时的重要依据；动态状态需要随着白天新出现的有效证据更新；长期健康与活力趋势则属于另一个时间尺度。三者有关联，但不应混成同一个指标。

### 4.2 三个必须分开的表达

1. **当前估计：** 根据已有身体数据与感受，目前大致怎样。
2. **接下来可能面对的负担：** 根据已知安排，后面可能比较紧张或消耗较多。这是预测，不是已经发生的下降。
3. **后来观察到的变化：** 实际行动之后，感受和可用指标发生了什么变化。它仍不自动证明因果。

日程增加了一个会议，可以改变负担预测和建议，但不能自动伪造一次身体状态下降。休息、冥想、训练完成，也不能按预设点数直接增减状态分。

### 4.3 用户实际看到什么

不应只看到一个数字，而应看到一组简洁的信息：

- 当前状态概况；数据充分且模型可靠时，附带状态指数。
- 与近期常态相比的主要变化，以及必要的维度差异。
- 最近一次有效依据的时间、来源和数据充分程度。
- 对当前安排有何实际意义，而不是只有“高一点、低一点”。

例如：

> 你说现在脑子有些累，昨晚睡眠也偏少。最新身体数据还不能说明下午的完整变化。下午汇报不动，建议把晚间训练改成较轻候选，先留出准备和恢复空间。

数据不足时可以只表达感受与已知事实，不强行给分；证据相互矛盾时保留差异，不用平均数把它们掩盖。

### 4.4 指数的成立条件

具体算法、分值区间、更新频率与权重，需要在指标定义、设备数据可用性及验证之后确定，不在产品叙事里先编出来。

原型可以使用明确标注的示例数据展示动态变化，但必须同时展示“依据是什么”和“为什么影响安排”，不能让动效或数字波动冒充真实测量。产品服务可以持续存在，测量不一定连续、实时。

## 五、Kriki 应承担的完整服务

核心链路是：

> 理解交代 → 判断状态与现实要求 → 协商安排 → 跟进变化与执行 → 理解结果 → 改进下一次帮助。

这条链路可以从任何一个环节开始，不必每次从问卷、目标选择或整天规划开始。

### 5.1 理解：接住交代，而不只是保存聊天

用户可以说：

- “这周在出差，明天下午有一场重要汇报。”
- “今晚想陪家人，别把训练排到很晚。”
- “今天不是身体累，是一直开会，脑子转不动了。”
- “刚才那段训练做着挺勉强。”

Kriki 应识别这些内容分别属于事务、约束、持续处境、临时感受还是执行反馈。不是每句话都生成任务，也不是每句话都变成永久记忆。

只追问会改变决策的缺失信息。例如，是否能调整某个承诺，可能比精确填写所有事务的“消耗等级”更重要。

用户只交代一件事情，也应能够开始获得帮助；日历、设备与历史信息用于减少重复解释，而不是提高使用门槛。

### 5.2 判断：把“知道情况”变成有用的取舍

判断需要同时考虑：

- 用户当前最在意什么，以及已有的长期目标。
- 哪些承诺不可移动，哪些只是初步想法，哪些可以协商。
- 当前感受、有效身体证据、近期实际负担与可用时间。
- 准备、通勤、洗漱、切换与恢复等真实成本，而不只是任务本身的时长。

目标不只是用于挑选开场话术。同样的事情与状态，不同目标应实际改变安排重点：

- 重要事务优先：保护关键推进时段，协调其他可调整事项，同时说明代价。
- 改善精力优先：减少可避免的负担，保护恢复与适当活动。
- 维持平衡：保留工作、生活、健康的边界，不让其中一项无限挤占其他项。

这些是持续有效、可以临时调整的取向，不是每天必须重新选择的模式。也不需要强迫用户把三个方面排出永久的绝对优先级。

### 5.3 安排：让帮助有落点

日计划是重要的落实载体，但不是产品全部。

一份有价值的日计划应共同容纳：

1. **已有承诺：** 已确定的工作、生活、日程及不可动时间。
2. **需要推进的重要事项：** 用户想完成但尚未放好、或需要协调的事情。
3. **针对性的健康行动：** 根据当天需要安排的活动、训练、睡眠准备、恢复或必要补给。
4. **有意留下的空间：** 缓冲、休息和不需要继续优化的自由时间。

不是给所有时间都塞满任务，也不是把工作和生活排完后，再硬插一套健康打卡。

用户可以自己加入事情，可以局部修改 AI 的建议，也可以只确认其中一部分。已确认的安排与候选建议必须分开；不能把 AI 的想法默认当作用户的新承诺。

用户不做每日设置，Kriki 也应能沿用已有目标、偏好和最新情况，提供可用的候选安排；但不能借此静默更改用户的重要承诺。

### 5.4 健康行动：专业能力保留，但不机械重复

健康行动应满足“为什么今天需要、怎样做适合今天”的条件。

- 训练保留必要的项目、强度、时长与执行指导，不能退化成“去运动一下”。
- 步数、停止咖啡因摄入、入睡准备与上床时间等，在确有当天个性化依据时仍有安排价值。
- 饮食补给在训练类型、量及其他相关条件确有需要时单独安排；不需要时不硬放一项。
- 针对连续会议、出差、长时间静坐等情境，可以提出必要的活动、缓冲或恢复安排。
- 每天完全一样、对当日取舍没有帮助的常识，不必重复占据日计划。

训练减少不是必然更好，状态良好也不自动代表需要加量。改变计划应符合用户目标、专业规则和实际条件。

### 5.5 跟进：离开首页之后，服务仍然成立

持续在场不等于让用户一直打开 App，也不等于不停聊天。

Kriki 应在相关信息变化、接近关键时间、存在重要待决定事项或约定的回访条件时继续处理。例如：

- 会议延长，影响了后面的训练与家庭安排。
- 用户补充“今天很累”，需要重新核对后续节奏。
- 明天的重要事项临近，今天仍有准备事项没有安排好。
- 用户曾请它留意某段训练后的体验，现在出现了可用反馈。

没有新信息、没有必要决策时，可以保持安静。不是每项日程结束都问感受，也不是每次指标波动都发通知。

通知应让用户知道“为什么现在找我、什么需要我看”，并能直接回到相应事项。用户回来时，应接着看上次交代的事，而不是重新开始一段无上下文的对话。

### 5.6 调整：保持连续性，而不是不断重生成

变化之后，先确定影响了哪些安排，再局部协调。

- 保护未受影响的承诺、已开始的事情和真实执行记录。
- 说明改了什么、为什么改、有什么代价，还有什么保持不变。
- 没有可行解时明确指出冲突，请用户做真实取舍；不能偷偷缩短重要工作或假设别人同意改约。
- 用户可以拒绝、换方向、暂不处理，或在适用时撤回修改。
- 涉及外部日历时，内部调整与外部同步分别说明结果；同步失败不能声称已经改好。

例如：“汇报时间不动。训练有两个候选：今天保留较短版本，或挪到明天。家庭晚餐不变。”比“根据你的状态，已为你重新生成最佳一天”更可信。

### 5.7 反馈：让用户理解自己的经历

反馈至少区分：

- 原先怎么安排。
- 实际发生了什么。
- 用户感受怎样。
- 有哪些身体观察。
- 可以怎样理解，哪些还不能确定。

日历时间过去，不等于事情发生；开始不等于完成；完成不等于达到预期效果。设备能够可靠提供的执行证据应尽量接入，不要求用户在手表和 App 重复打卡；无法知道的结果不假装知道。

反馈不必每天变成一篇长复盘，也不要求对每项事务评分。围绕有变化、有疑问或对下次有价值的事情进行就够了。

### 5.8 学习：逐步形成个人策略，而不是堆积记忆

Kriki 应逐渐知道：在相似处境下，什么安排对这个人更可行、更合适。

例如：

- 连续外出之后，用户更能接受短而轻的活动，而不是固定时长的晚间训练。
- 某种强度的训练多次带来勉强体验，需要重新核对，而不是继续沿用原量。
- 用户明确反馈，某类重要事务前保留缓冲更合适；下次可把它作为候选策略。

个人策略必须保留适用条件、证据与可修正性。一次“有点累”不能变成永久偏好，一次指标变化不能证明某种行为的效果。

真正的个性化是“下一次做法有所改变，并能解释为什么”，不只是“我记得你喜欢什么”。

## 六、整体功能蓝图

以下按服务能力组织，不意味着必须拆成同名页面或一级导航。

| 功能域 | 必须能做什么 | 用户得到的实际结果 |
| --- | --- | --- |
| 交代与接入 | 自然语言录入；可选日历、设备数据接入；识别事务、处境、感受和约束 | 已知情况不重复问，新交代不会丢 |
| 个人理解与记忆 | 保存可追溯的目标、偏好、承诺与临时情况；允许查看、更正和删除 | 知道 Kriki 理解了什么，可以纠偏 |
| 状态理解 | 汇总有效身体证据与主观感受，区分当前、预测和长期变化 | 知道自己大致怎样，判断依据是什么 |
| 目标与取舍 | 维护长期方向和阶段重点，支持临时优先事项及不可牺牲边界 | 建议符合自己的生活取向，而非统一模板 |
| 安排协作 | 接住现有承诺、补入用户事务和健康行动，支持候选、局部确认与修改 | 一份现实可用、共同认可的日计划 |
| 持续跟进 | 记住相关事项；按变化和约定条件主动处理；控制通知与回访 | 离开 App 之后，事情仍有人继续留意 |
| 局部协调 | 识别影响范围，提出可行取舍，确认后更新，保留历史与同步结果 | 有变化时不用从头重排，也不丢承诺 |
| 执行与体验 | 接收可靠执行信息，允许补充实际情况和必要感受 | 计划、真实行动和效果不再混为一谈 |
| 回看与个人策略 | 联系处境、安排、实际反馈与身体观察，形成可修正策略 | 逐渐知道什么节奏适合自己 |
| 授权与控制 | 分开管理读取权限、写入权限、主动联系和代办范围 | 知道它能看什么、能做什么，随时收回 |

### 6.1 需要长期存在的核心内容

不能只靠一段无限增长的聊天记录维持服务。至少需要持续保留：

- **关于这个人的理解：** 目标、偏好、边界与持续处境。
- **事情本身：** 来自哪里、约束是什么、是否确认、还需跟进什么。
- **安排：** 当前采用什么，哪些只是候选，过去怎么调整过。
- **状态证据：** 何时、来自哪里、反映什么，是否足够新鲜与可靠。
- **真实反馈：** 实际做了什么、主观体验、后续观察。
- **个人策略：** 在什么条件下、依据什么，下一次可以怎样帮忙。

同一件事情从交代、安排、调整到反馈，应保持连续，不因换页面或隔了一天就变成一件无关的新任务。

### 6.2 自动做到哪一步

建议原则是：**理解、核对和准备主动一些；改变承诺与对外操作谨慎一些。**

- 可以自动整理已授权信息、更新证据、识别冲突、准备候选和继续已约定的跟进。
- 在用户明确授权的范围内，可以执行相应的小范围操作；不能把“允许读取日历”理解成“可以修改所有日程”。
- 改变重要时间、训练方案、涉及他人的承诺或超出授权的外部操作，应让用户看清变化后确认。
- 不必让用户确认每一句总结、每一次数据更新或每一条未采用的建议，避免把主动服务变成审批负担。
- 没有授权或能力时，只能建议、准备或等待，不能声称已经通知别人、完成工作或改变外部安排。

## 七、用三个场景检验这个定义

### 场景一：今天有重要事情，但状态不理想

**情况：** 昨晚睡得少，下午有重要汇报，晚上原本想训练，家庭时间不想牺牲。

Kriki 不应该只说“恢复差，建议休息”，也不应该仅把所有事项塞进空档。

它应：

1. 沿用已知目标、日程和承诺，必要时只补问汇报准备程度等关键信息。
2. 把重要汇报及准备保护好，说明当前身体证据与用户感受。
3. 提出适合当天的推进节奏、缓冲与训练候选，不擅自取消训练或改变家庭时间。
4. 用户局部修改后，形成可采用的安排。
5. 不把汇报结束自动视为完成，也不承诺休息后一定恢复多少。

**价值：** 不是在工作与健康之间简单二选一，而是帮助用户以更合适的方式度过重要的一天。

### 场景二：事情变了，感受也变了

**情况：** 会议临时延长，用户说“脑子很累”，后面还有训练和晚餐。

Kriki 应接着处理同一组事情：

1. 识别哪些安排受影响，哪些不应动。
2. 分清“会议延长带来的时间变化”和“用户报告的疲惫”，不把两者写成一笔实测状态扣分。
3. 给出少量真实可行的取舍，说明保留什么、减少什么、推迟什么。
4. 用户选定后，只更新受影响部分；涉及外部写入时回报真实结果。

**价值：** 用户不必重新讲一遍今天，Kriki 也不会为了排出漂亮时间表擅自牺牲承诺。

### 场景三：事情结束之后，理解更进一步

**情况：** 用户完成了当天关键事项，也做了较轻的活动。晚些时候说“身体还好，但精神很耗”。

Kriki 应：

1. 将实际完成、主观感受与可用身体观察分别保留。
2. 说明目前能看到的变化，不把精神疲惫否定掉，也不把它全部归因于某场会议。
3. 必要时提出对接下来安排的建议，而不是强迫用户补齐整天反馈表。
4. 下次相似情境，将“认知负担与缓冲”作为候选考虑，并明确这是待继续验证的个人策略。

**价值：** 用户感到自己的经历被理解，过去的交代在未来真正有用。

这三个场景之外，还需要一个反向检查：如果今天顺利、用户没有调整需求，Kriki 应能维持安静，而不是为了显示存在感制造新任务。

## 八、对产品交互与首页的影响

此轮不先确定页面数量和布局，但新定义会带来几个明确的交互要求。

### 8.1 首页不是健康仪表盘，也不是纯聊天窗口

用户回来时，应该迅速知道：

- **我目前怎样：** 简洁、有依据的状态概况。
- **Kriki 理解并在关心什么：** 对当前处境有针对性的判断与指导。
- **接下来怎么做：** 重要事项、必要行动、下一个需要留意的时间，以及待决定的调整。

指导语可以成为情感与主体感的中心，但必须能落到具体事情、安排或跟进上；不能只是漂亮地说“我懂你”。

日计划需要能快速查阅，不要求首页展开所有细节。交流是全局入口，不局限于“今天的任务”；状态与安排的调整也应有轻量、结构化入口，不强迫所有操作都通过长对话完成。

### 8.2 四种使用都应该顺畅

1. 用户只想看一眼 Kriki 的判断和接下来安排。
2. 用户有一句话要交代，希望它记住或采取行动。
3. 用户收到有意义的通知，回来做一个具体决定。
4. 用户想了解最近的状态变化，以及自己的生活节奏是否合适。

不应把每日配置、完整晨间对话、逐项打卡或强制晚间复盘变成共同前提。

### 8.3 不再沿用的旧限制

不建议把旧原型的“固定下午时段、只能处理若干示例任务、首页只突出一件事”直接当成新产品定义。它们可以是演示选择，但不是新产品的必然边界。

实际服务需要理解跨天的重要事项与持续处境；这不等于首版就要做复杂项目排期或一整套任务管理软件。

## 九、信任边界是产品能力的一部分

- **信息可纠正。** 用户能知道系统记住了什么、来自哪里，修改偏好或临时情况；更正不应悄悄改写已发生的事实，删除历史数据则应有明确入口与范围。
- **授权可分离、可撤回。** 不授权日历仍可交流录入，不连接设备仍可获得安排帮助；同时如实降低身体判断能力。撤回后停止相应访问与后续使用，历史保留与删除范围让用户清楚可控。
- **不默认持续录音或监视。** 连接更多来源应由具体价值驱动，而不是为了打造“无所不知”的形象。
- **不装作实时知道。** 标明新旧数据与观察范围，不能把稀疏采样包装成连续测量。
- **不以指标替代医学判断。** 不做诊断，不对疾病、伤病或异常症状给出超出能力的训练处置；必要时建议专业帮助。
- **不把健康让位于无止境产出。** 用户选择重要投入时，说明代价与补偿空间，而非一味鼓励硬撑。
- **承认不知道与没做成。** 未确认、未发生、未同步成功的事情，不写成确定结果。

## 十、首版与首轮原型的建议范围

### 10.1 首版必须串通的主线

建议先做深一条链路，而不是先铺满所有工作、生活、健康功能：

> 一句有价值的交代 → 与状态、目标和已有承诺联系起来 → 形成可采用安排 → 一次真实变化后的局部调整 → 获得实际反馈 → 在下一次相似情境中用上。

需要具备的能力：

- 自由交代与轻量补充，已有内容无需重复填写。
- 可选日历、身体数据接入，以及不授权时的完整降级路径。
- 个人目标、边界、持续处境及重要事项的记忆与纠正。
- 当前状态概况，当前事实与后续负担预测分离。
- 日计划协编，保留既有承诺和针对性健康行动。
- 变化后的局部协调、用户确认与真实结果回报。
- 必要的主动跟进、执行反馈和简洁回看。
- 少量可解释、可纠正的个人策略，先验证能否实际改善下一次帮助。

状态指数的科学验证与服务主线并行进行。不能用“AI 帮忙排出一份计划”证明指数有效，也不能因为指数还不成熟就放弃状态理解。

### 10.2 首轮原型应该让人验证什么

先串通第七节的三个场景，并补上“没有设备数据”和“今天无需打扰”两种情况。

原型应让体验者看清：

1. 同一句交代，Kriki 理解成了什么，用户怎样纠正。
2. 目标、感受与身体证据，分别改变了哪一个具体判断。
3. 用户不满意时，如何局部协商，而非只能接受或全部重来。
4. 离开再回来时，事情与待决定内容如何保持连续。
5. 实际反馈怎样改变下一次建议，而不是只增加一条聊天记录。

这里不把示例规则冒充真实模型，不把本机演示操作冒充真实设备读取、通知发送或外部同步。

### 10.3 暂不扩展的范围

- 替代企业项目管理、团队协作或复杂任务管理软件。
- 替用户完成所有工作内容，例如专业方案撰写、业务决策和对外沟通。
- 全自动移动他人参与的日程、替用户作出重大承诺。
- 无限制的全天录音、自动采集所有私人生活信息。
- 医疗诊断、疾病管理，以及未经验证的生物学逆龄承诺。
- 为体现“万能”而引入与状态协作无关的通用 Agent 功能集合。

不是这些事情永远不能做，而是它们不是这次产品成立所依赖的核心。

## 十一、这个产品是否成立，应该怎样判断

### 11.1 三个最需要验证的假设

**假设一：用户愿意交代，而且值得继续交代。**

不是问“你喜不喜欢懂你的 AI”，而是观察用户是否愿意再次把真实重要事项交给它，是否觉得不必反复解释，输入与确认是否比自己处理更省心。

**假设二：状态信息实际改善了帮助。**

在相同事务、时间和目标下，多了解身体数据与感受之后，Kriki 是否做出一个具体且更合适的决定？如果只是让解释听起来更专业，就没有证明增量价值。

**假设三：反馈带来了可感知的个人化。**

下次类似情境，建议是否因为前次真实体验而改变；改变是否更可行、更符合用户感受，而不是机械“上次累了，下次就减量”。

### 11.2 不要混在一起验证的三件事

- 状态估计是否可信，是指标与模型问题。
- 安排和跟进是否有用，是服务决策问题。
- 用户长期是否更有活力、生活是否更合适，是实际结果问题。

一项成立，不自动证明另外两项成立。自己定义的状态分上升，更不能单独成为“产品有效”的证明。

比较时可以先区分：只有日程、目标与感受的帮助；再加入真实反馈形成的个人策略；再加入有效生理信息。这样才知道价值究竟来自更懂事务、更懂这个人，还是身体信息提供了额外帮助。

### 11.3 核心成功标准

建议关注：

- 用户是否反复自愿托付真实事项，而非只尝鲜聊天。
- 系统是否在重要变化后接得住、不丢承诺、不给出伪完成。
- 建议是否真的被采用，以及不采用的原因。
- 用户的输入、确认、纠错与重复打卡负担是否下降。
- 重要事情的推进、自身感受与生活空间是否被共同照顾，而非只提高完成数量。
- 个人策略是否在后续相似情境中体现出实际价值。

聊天条数、通知数量、任务越排越满，都不应成为核心成功指标。

## 十二、建议先确认的产品共识

我的建议是先把以下五条作为这一版定义的主轴：

1. **类别：** 以个人状态为中心的 Personal AI，不是健康 App 加日历，也不是带身体分数的排程器。
2. **核心责任：** 理解交代，持续协助用户协调重要事情与自身状态；不承诺包办工作和生活。
3. **价值落点：** 日计划是主要落实方式，状态理解、应对变化和逐渐形成个人策略同样构成价值。
4. **使用方式：** 默认能帮助，必要时协商；不是每天先配置一套系统，才有资格获得服务。
5. **指标地位：** 动态状态指数是有依据的理解工具，不是生活目标，更不是 AI 随口生成的电量条。

如果把这五条立住，后续原型就不应继续从“首页摆哪些卡片”开始，而应先把“一件事怎样被接住、被安排、被持续跟进，并在下次真正用上经验”做成完整体验，再决定最合适的界面表达。

---

## 附：对本次材料的取舍

- 《Kriki产品策划书_v2.0》提供了事务、状态、安排与跟进相结合的探索。保留连续协作和事实区分，不直接沿用其所有页面、场景范围或功能优先级。
- 《Kriki商业计划书_v1.0》提供了定位、目标用户与商业化假设。它们有参考价值，但本轮没有将价格、竞争优势或商业预测当作新定义已经成立的证据。
- 《Bee启发原型优化与浏览器验收_2026-10-20》提供了交互改进和验收记录。其测试结论属于材料记录，本轮未重新验证，不能等同于真实 AI、真实集成或长期效果已成立。
- HTML 原型的内容与代码规则展示了交代、预览、确认、局部调整、执行反馈和记忆等尝试；其真实能力仍是本机规则演示。新定义不受固定演示时段与既有导航限制，也不把演示状态当作实际身体数据。
- 本轮不改现有原型、不发布线上，也不把材料内的后续开发指令视为本轮执行要求。