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

一、我的核心判断

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 应逐渐知道：在相似处境下，什么安排对这个人更可行、更合适。

例如：

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

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

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

六、整体功能蓝图

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

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 原型的内容与代码规则展示了交代、预览、确认、局部调整、执行反馈和记忆等尝试；其真实能力仍是本机规则演示。新定义不受固定演示时段与既有导航限制，也不把演示状态当作实际身体数据。
• 本轮不改现有原型、不发布线上，也不把材料内的后续开发指令视为本轮执行要求。