# Kriki Coach 团队产品全景说明 > 面向产品经理、设计师、开发工程师、算法工程师、Agent 工程师、测试工程师和未来能够读取项目文档的 Codex。 > > 本文不是宣传稿，也不是某个页面的设计说明。它说明 Kriki 是什么、为什么这样工作、各层对象如何形成和更新、用户如何使用、自研算法与 Agent 分别在哪里参与，以及团队如何判断实现是否正确。 **文档状态**：团队产品全景说明 V1.6 **整理日期**：2026-08-05 **产品**：Kriki Coach **阅读优先级**：本文件用于建立全局理解。当前 Demo、产品蓝图、既有 PRD 和 `architecture.html` 都是形成正式需求与技术方案的参考输入，不能直接交付开发；具体实现以评审通过的模块 PRD、正式技术架构、数据规范、安全规则和验收标准为准。 ## 0. 如何使用这份文档 ### 0.1 推荐阅读顺序 第一次了解产品时，按以下顺序阅读： 1. 先读第 1 至 4 章，理解产品角色、用户任务、时间层级和主要场景。 2. 再读第 5 至 7 章，理解数据、计划和 Agent 如何协作。 3. 再读第 8 至 11 章，理解界面、回顾、对象版本和异常处理。 4. 最后读第 12 至 16 章，理解研发分工、测试标准、已定规则和待定决策。 如果只需要快速定位规则： - 要了解某个页面目前怎样设计，查第 8 章和 `prd-data.js` 中对应的区域说明；正式实现查该模块评审通过的 PRD。 - 要了解 Agent 目前怎样设计，查第 7 章和现有 Agent PRD；正式实现还要查评审通过的任务规则与技术方案。 - 要知道某个数字是否算完成，查第 6、7、9、14 章以及数据结算规则。 - 要知道某个历史页面是否能改变当前状态，查第 11、12、14 章。 ### 0.2 文档之间的职责 项目中存在几类不同文档，不能互相替代： | 文档 | 职责 | | --- | --- | | 本文件 | 解释全产品的对象、关系、用户路径、系统边界和团队共识。 | | `Kriki Coach 产品蓝图.md` | 解释产品定位、竞争判断、长期价值和战略取舍，是正式需求的方向输入。 | | `Kriki Coach 首页智能体产品需求文档 V1.2-产品PRD.md` | 记录首页 Agent 与每日计划已经讨论过的产品逻辑，供正式模块 PRD 继续梳理，不直接交付开发。 | | `prd-data.js` | 展示 Demo 中的区域说明与 Agent 设计参考，不等于已经评审通过的正式 PRD。 | | `architecture.html` | 展示当前产品责任与系统分层参考，不是已经确认的部署拓扑、接口或开发方案。 | | `project-plan.html` | 解释两期范围、工作包、负责人、时间和每项工作的详细要求。 | | `Kriki Age Delta 指标衡量与年龄换算规则 V1.0.md` | 记录 Age 候选指标、计算思路和仍需验证的参数。它不能绕过当前产品 PRD 直接成为生产算法。 | | `WHOOP 产品机制研究.md` | 外部产品研究和对 Kriki 的设计启示，不是 Kriki 的直接需求。 | | `DEPLOYMENT.md` | 线上部署路径、备份和发布信息，不属于产品规则。 | 文件名中带有“PRD”，不代表它已经达到开发交付状态。产品经理仍需按模块补齐范围、规则、流程、状态、异常、数据、权限和验收，并组织评审；技术团队需要另行形成正式技术架构与接口方案。 ### 0.3 冲突处理顺序 当不同文件、原型或历史讨论出现冲突时，按以下顺序处理： 1. 用户最新明确的产品决定。 2. 已评审通过的正式模块 PRD、技术架构、数据规范、安全规则和验收标准。 3. 当前产品对象与版本数据。 4. 当前 Demo、产品蓝图、既有 PRD 和架构参考中的一致部分。 5. 外部研究和竞品行为。 6. 未确认的设计假设。 旧讨论、旧 Demo、既有 PRD、架构参考或旧算法备忘录不能因为存在得更早就覆盖新的明确决定，也不能被默认当作开发定稿。若冲突尚未解决，必须标注“待定”，不能在不同页面各自采用一套解释。 ### 0.4 怎样服务团队的每一项工作 本文是项目的共同认知和上下文服务层，不是具体任务的决定者。它不替具体任务设定结论，也不替产品、健康、设计、研发、算法、Agent 或测试完成专业判断；它的作用是让每个角色在进入局部任务时，仍然看得见 Kriki 的用户价值、对象关系、上下游、已知边界和整个闭环，减少各自形成一套产品理解的风险。 项目计划中的“复制完整任务提示词”应把本文中与当前任务有关的内容转化为一份可执行的委派上下文，而不是只附一条全文链接，也不是把全文机械塞进提示词。每份提示词至少应帮助执行者和其 AI 理解： 1. 这项工作处在当前阶段和业务闭环的什么位置，为什么现在要做； 2. 需要核对哪些上游输入、版本、权限、数据质量和待定事项； 3. 当前角色可以做什么、不能替谁做决定，以及应使用什么专业方法； 4. 结果会被哪些下游角色、页面或系统使用，怎样交付才能让对方直接接续； 5. 哪些全局边界与本任务有关，哪些内容只是参考、假设或仍待评审； 6. 最终要形成什么真实成果，并通过什么对象、版本、运行结果或测试证据验收。 团队成员把任务提示词交给 AI 后，AI 应先查看当前工作环境和已有材料，再根据提示词完成当前任务。提示词中已经提供的最小上下文应足以防止方向性偏差；只有需要查证完整关系、来源或未展开细节时，才回到本文阅读相关章节。链接暂时不可访问时，AI 也不能丢掉提示词中已经明确的项目边界，更不能自行补造缺失规则。 本文与具体交付的关系如下： - 本文负责提供稳定的全局理解、共同语言和关系查证； - 项目计划负责把工作拆到阶段、工作包、角色、时间、上下游和验收； - 模块 PRD、健康专业定义、设计稿、技术方案、算法规范、Agent 任务规则和测试方案负责形成各自可执行、可评审的正式结论； - 用户最新明确决定和已评审正式交付始终高于从本文提炼出的任务上下文。 当产品的稳定关系、共同边界或角色分工发生变化时，应更新本文并同步任务提示词版本；只影响某一任务的局部细节，则留在对应正式交付中，不把全景说明膨胀成所有任务的总 PRD。 ## 1. Kriki 是什么 ### 1.1 一句话定义 Kriki 是一个把用户当作唯一学员的个人 AI Coach：它持续认识用户的身体、目标、习惯、现实限制和真实反应，用穿戴数据和专业方法形成适合当下的行动方案，并通过执行结果和身体反馈逐步验证、修正长期方向。 ### 1.2 Kriki 不是什么 Kriki 不是以下产品的简单叠加： - 不是健康数据仪表盘。它不要求用户自己读完所有图表再做决定。 - 不是 Recovery 或 Age 分数展示工具。分数是事实和判断输入，不是产品终点。 - 不是训练计划生成器。训练只是实现某个身体目标的方式之一。 - 不是待办清单或打卡工具。只有具有真实结算来源的行动才进入正式进度。 - 不是一个附带聊天机器人的传统 App。对话是理解、解释、协商和发起任务的入口。 - 不是医疗诊断或治疗服务。健康解释必须保留证据边界和不确定性。 - 不是一个无边界的通用助手。Kriki 只能在产品知识、数据授权、用户目标和安全范围内工作。 首个上线版本的平台边界已经确定：只发布 iOS App，只交付 iPhone 客户端。客户端代码基于 Flutter 开发；HealthKit、StoreKit、通知、签名和发布等 iOS 平台能力通过 Flutter 插件、Platform Channel 或必要的原生桥接接入。Apple Watch 在首版中仅通过 Apple Health 提供活动、心率、睡眠等数据，不包含独立 watchOS App；Android、iPadOS、macOS 与 Web 客户端均不进入本轮 MVP。 ### 1.3 用户买到的不是“完成计划” 用户真正希望得到的是： - 不需要先成为半个健康专家，就能知道今天怎么照顾自己。 - 计划能根据真实生活和身体状态变化，而不是要求生活先变得理想。 - 每天的努力不是孤立的，能看见它如何进入本周进展，并最终被长期结果验证。 - 用户可以随时补充、修改、拒绝或纠正，不会因为没有完成建议而被贴上负面标签。 - Kriki 越长期使用，越能基于真实结果形成适合这个人的方法。 ### 1.4 核心闭环 Kriki 的业务闭环是： > **洞察 → 方案 → 协商 → 执行 → 验证 → 学习** - **洞察**：把穿戴数据、用户表达、现实约束和既往结果整理为当前状态判断。 - **方案**：在长期方向、当前阶段、本周计划和身体预算的边界内，形成今天可以执行的安排。 - **协商**：用户可以说明时间、状态、偏好、困难或新诉求，Kriki 解释取舍并给出新的方案。 - **执行**：用户通过活动、训练、睡眠和生活安排交付实际剂量；设备和系统记录真实结果。 - **验证**：比较计划、实际完成和之后的身体反应，判断本次安排是否值得保留或调整。 - **学习**：只有被用户确认或被足够结果验证的信息，才进入未来规划证据或长期记忆候选。 任何只生成一段话、但没有后续计划、账本、历史、验证或学习承接的内容，都不属于完整的 Kriki 产品结果。 ### 1.5 现有资产与本次新增 Kriki 不是从零开发。团队先盘点 Fitbeing 已上线能力，再决定直接复用、裁剪、适配或重做： | 能力 | 现状 | Kriki 的处理 | | --- | --- | --- | | 邮箱登录 | Fitbeing 已有成熟链路。 | 直接复用邮箱登录；注册、找回、身份和会话分别核对差异。登录只是进入产品的前置能力，不等于首次使用流程。 | | Apple Health | Fitbeing 已有成熟的读写和数据处理链路。 | 复用代码并裁剪为 Kriki 需要的较少字段。读取进入 MVP；写回是否进入 MVP 仍需单独判断用户价值。 | | 睡眠、恢复、负荷 | 已在 Fitbeing 产品化，已有数据定义、界面和历史结果。 | 以上述资产为基线，先评估是否需要调整，不默认重做。 | | 三项评估算法 | 现有算法运行在手表固件中。 | 迁入 Flutter App，适配 Apple Health 字段、来源和时间语义，并与既有结果对照验证。 | | Kriki 首次使用与健康私教闭环 | Fitbeing 没有同一套产品流程。 | 全新设计登录后的协议、资料、目标与限制、授权说明、首次同步、三项结果、今日方案和中断续接。 | | 计划、Agent、统一结算和回顾 | 需要按 Kriki 的产品对象重新形成。 | 采用唯一正式版本、真实完成账本和可验证的 Agent 任务，不沿用分散页面状态。 | ## 2. 用户问题与核心任务 ### 2.1 用户面对的困难 用户通常同时拥有大量数据、目标和现实变化，但缺少把它们变成行动的中间层： - 知道某项指标不好，却不知道今天应该做什么。 - 知道应该运动或睡好，却不知道剂量、上限和与其他目标的取舍。 - 计划形成时生活看起来可行，到了下午临时加班、出差、疼痛或疲劳后就失效。 - 完成了一次活动，却不知道它算到了哪些周目标，是否已经够了，是否还需要追加。 - 周末看到了完成率，却看不出哪些因素对长期方向产生了积极或消极影响。 - 想反馈感受，但不一定想和 AI 开一段对话，也不一定想让反馈直接触发任务。 ### 2.2 用户雇佣 Kriki 完成的工作 1. 把复杂健康事实整理成一句能理解的当前判断。 2. 将长期方向拆成当前阶段、本周要推进的目标和今天的可交付剂量。 3. 在现实变化发生后保留有效部分，重新安排受影响的部分。 4. 自动结算可以从设备或系统获得的事实，不要求用户重复打卡。 5. 对不可自动测量的内容诚实区分为辅助建议，不制造虚假进度。 6. 在日、周、长期三个时间尺度上保持关系清晰，不让本周报告抢走今天的注意力。 7. 用之后的身体反应验证计划，而不是用 Agent 自己的解释证明计划有效。 ### 2.3 用户主权 除必要的安全保护外，用户始终可以： - 接受方案； - 修改方案； - 拒绝方案； - 忽略建议； - 补充现实变化； - 纠正数据或记忆； - 取消尚未生效的提案； - 删除允许删除的个人记录。 拒绝、忽略或修改一次建议不自动形成负面记忆，不降低关系评价，也不限制后续服务。用户最新明确表达可以覆盖旧偏好，但不能改写已结算事实、历史快照和安全边界。 ## 3. 产品对象与时间层级 ### 3.1 从长期到当天的方向 Kriki 不是把所有目标放在一个平面上。对象关系是： > **长期结果与 Age → 当前阶段 → 本周计划 → 今日方案 → 实际执行 → 日 / 周回顾 → 未来规划证据** 这是影响方向，不是简单的页面跳转： - 长期结果和 Age 提供“当前值得改善什么”的依据。 - 阶段把长期方向转成一段时间内的主要改善方向。 - 本周计划独立承接当前阶段，从当时已批准的周目标目录中定义本周要推进、保持或保护的目标。 - 今日方案结合本周剩余剂量、今天睡眠/恢复/负荷和现实约束，决定今天交付什么。 - 执行账本记录真实发生了什么，不记录预期或建议本身。 - 回顾把事实放回原来的时间层级，形成未来规划证据，但不通过报告直接改写当前计划。 ### 3.2 周与周之间的关系 本周和下周是平级周期。不能因为本周完成率高或低，就机械地把下周计划顺延、惩罚、补偿或自动改写。 - 每一周都由长期目标、当前阶段、当时的身体状态、用户约束和可用数据独立形成。 - 上周结果是下一次判断的证据，不是下一周计划的直接模板。 - 本周修改可以改变本周剩余方案和本周版本，但不直接修改下周。 - 如果长期目标或阶段判断发生变化，未来周计划可以在自己的形成时点重新计算；这不是“本周影响下周”，而是上层方向变化后各周重新读取上层对象。 ### 3.3 当前状态、计划、执行和结果必须分开 | 类型 | 含义 | 例子 | | --- | --- | --- | | 事实 | 已确认的设备数据、用户输入、权限或结算结果。 | 昨夜睡眠 7 小时 42 分。 | | 判断 | 基于事实、基线和规则形成的解释。 | 今天恢复空间有限。 | | 目标 | 希望达到的方向、指标或结果。 | 本周维持睡眠规律。 | | 计划 | 已接受、带版本的行动安排。 | 今天完成 25 分钟基础有氧。 | | 提案 | 尚未生效的可能变化。 | 如果你只有 20 分钟，可以改成最低有效版本。 | | 执行 | 实际发生的活动或睡眠结果。 | 设备识别到 22 分钟 Zone 2。 | | 验证结果 | 之后用可比数据判断是否适应、有效或证据不足。 | 次日恢复未下降，暂可保留该剂量。 | 任何页面都不能把判断显示成事实、提案显示成已生效计划、预期贡献显示成已完成，或把一次执行直接显示成长期因果结论。 ## 4. 用户路径与主要场景 ### 4.1 首次使用 邮箱登录直接复用 Fitbeing 的成熟链路。注册、找回、身份、会话和安全存储分别核对后决定复用或适配。登录成功以后才进入 Kriki 全新的首次使用流程，不能把登录和首次使用混成一个状态。 首次使用的目标不是让用户填完一份复杂问卷，而是建立足以工作的最小基础： 1. 确认协议版本、身份、称呼、时区、单位和最少的基础资料。 2. 了解用户的长期目标、近期诉求、现实限制、运动偏好和不能接受的方式。 3. 说明每类 Apple Health 数据的用途，再申请本次真正需要的权限。 4. 复用 Fitbeing 同步能力完成首次回溯，并显示同步进度、已获得的数据和仍缺少的数据。 5. Flutter App 中的自研算法形成首份睡眠、恢复、负荷结果；数据不足时说明原因和下一步。 6. Kriki 基于正式结果和用户条件形成首份今日方案，用户可以接受、修改、拒绝或补充信息。 7. 每一步都保存进度，支持退出重进、网络失败、部分授权、撤权、已有账号恢复和继续完成。 数据不足时允许用户进入产品，但不得伪造精确判断，也不能把通用建议包装成已经了解用户的个性化结论。 ### 4.2 每天打开 App 首页优先回答四件事： 1. 今天身体处于什么状态？ 2. 今天最需要做什么？ 3. 当前完成到哪里？ 4. 做完会计入哪里？ 首页不应默认展示 Agent 内部推理、完整周计划、所有替代路径或所有数据原始字段。复杂度由 Kriki 承担，用户可以按需展开依据、周计划和详细数据。 ### 4.3 现实变化 用户可能说：今天只有 20 分钟、临时出差、腿有点疼、酒店没有器械、晚上安排变了、今天不想做原来的方式，或“最近吃胖了，想减减肥”。 处理原则： - 先理解用户说的困难或变化，再说明受影响的原安排。 - 保留已完成事实和仍有效的安排。 - 给出新旧差异、剂量变化、目标影响和是否需要确认。 - 直接生效的低风险替换可以立即更新当前方案；改变目标、总量、主要行动或阶段方向时，要先明确后果并等待确认。 - 结果生效后写入正式计划版本，不能只在聊天里说“那就改一下”。 - 任何修改都不把之前未完成的事实洗成完成。 ### 4.4 反馈身体感受 日内感受不是默认的 AI 任务输入。用户可以在对应日期卡片内： - 选择常用感受选项； - 输入一段自由文字； - 点击“保存”。 保存后的感受先作为该日期的上下文记录，供之后的判断和验证使用，不自动触发一段对话、不自动生成任务、不伪造结算。只有当后续规则判断它足以改变安全或计划时，才进入相应 Agent 任务。 ### 4.5 查看历史 历史按天保存真实对话、方案版本、执行结果和感受记录。用户可以通过日期、搜索或相关入口找到过去的某一天，不要求记住日期。 按天保存不等于每天机械生成摘要：没有主动对话或有意义结果时，不创建打扰用户的空摘要。需要主动联系时，消息、未读状态和原因必须单独记录。 ## 5. 数据与指标体系 ### 5.1 数据分层 Kriki 使用的数据至少分成： - **健康事实**：Apple Health、穿戴设备和其他已授权来源的记录。 - **主观事实**：用户明确输入的感受、疼痛、限制、偏好或纠正。 - **现实约束**：用户当前提供的可用时间、地点、器械、安排和意愿。 - **个人基线**：经过质量检查的近段时间可比数据。 - **目标与计划**：长期目标、阶段、周目标、日方案及版本。 - **执行账本**：实际活动、睡眠、结算结果及来源。 - **验证记录**：计划期待的观察、实际身体反应、可比性和可信度。 首版健康数据主要来自 Apple Health。Fitbeing 已有的授权、首次回溯、增量读取、来源与时区、后台同步、失败恢复和写回能力应先复用，再按 Kriki 的数据清单裁剪。读取能力属于 MVP 基础；写回是否进入 MVP 由产品价值决定，不能因为代码已经存在就自动加入范围。 运动记录能否从 Apple Health 稳定获取仍是待验证项。必须用真实 iPhone、不同设备来源和历史数据核对权限、字段、时间范围、来源差异和完整性。验证通过前，不能把运动记录承诺为稳定自动数据源或自动结算依据。 ### 5.2 Age 的角色与当前 Demo 候选 Age / Age Delta 是长期方向的代表物，不是日常任务列表，也不是每天根据分数变化就立即奖惩用户的数字。稳定的是它处在“长期结果 → 阶段 → 本周 → 今日”链路的上层，并为阶段判断提供长期证据；具体使用多少项指标、使用哪些指标以及怎样计算和表达，目前都没有生产定版。 当前 Demo 为了快速验证信息结构和交互，暂时使用以下六个候选长期因素： 1. VO₂ Max； 2. 日均步数； 3. 睡眠规律； 4. 中高强度活动； 5. 平均睡眠； 6. 静息心率。 这六项不是生产指标目录，也不表示其他候选已经被排除。历史 Age 研究稿中还出现过抗阻活动频次等候选指标；候选项是否保留、拆分、合并或新增，以及公式、权重、年龄换算和页面表达，都必须经过第 5.4 节的完整评审。不能因为某项出现在 Demo、旧文档、WHOOP 或公共指南中，就自动成为 Kriki 的生产规则。 Age 的正确产品含义是：长期、多周期、经过完整度和可比性检查的结果，用于识别阶段机会、解释周目标的价值和展示趋势。它不承担： - 直接生成某一天的训练动作； - 用单次执行证明因果； - 以一次异常数据改变长期结论； - 把本周未完成自动转成下周惩罚； - 在用户未提供足够证据时制造精确年龄变化。 ### 5.3 本周计划与当前 Demo 候选 当前 Demo 为了跑通“阶段 → 本周 → 今日 → 结算”的产品链路，暂时展示以下六个候选周目标： 1. 高强度刺激； 2. 基础有氧； 3. 抗阻刺激； 4. 步数； 5. 睡眠时长； 6. 睡眠规律。 这六项的数量、名称、分组、是否每周全部出现以及与 Age 的映射都不是生产定版。生产周目标必须服务当前阶段，能够说明目标、剂量、完成规则和安全边界；有可靠来源的目标进入正式结算，没有可靠来源的内容只能作为辅助建议或上下文。训练、骑行、跑步、散步、站立、放松等通常是实现方式，但是否需要把某类行为提升为正式周目标，也必须经过评审，不能由 Demo 直接决定。 ### 5.4 指标进入生产前的完整评审 Age 指标目录和周计划指标目录需要分别评审，但采用同一套进入生产的门槛。每个候选指标至少回答以下问题： 1. **产品价值**：它解决什么用户问题，是否会改变阶段判断、周计划或用户行动；如果移除，产品是否真正失去关键能力。 2. **科学证据等级**：记录证据来源、研究类型、适用人群、结论一致性和局限；分别写清统计关联、合理机制与已经验证的因果关系，不能把三者混成同一种结论。 3. **Apple Health 数据可用性**：确认字段、权限、时间语义、更新频率、历史范围、单位、设备来源和覆盖率，并用真实 iPhone 验证稳定性、来源差异、重复记录和长期缺口。 4. **计算与模型合理性**：明确个人基线或人群参考、观察窗口、聚合与归一化方法、相关指标的冗余和重复贡献、权重或阈值的确定方式，以及模型版本怎样验证和发布。 5. **缺失与低可信处理**：说明最小数据量、部分缺失、长期缺失、来源变化、结果冲突、低置信和不可比较时，是延期、降级、显示范围还是不输出；不得用 0、默认值或 Agent 猜测补齐。 6. **可行动与可结算**：Age 指标要能形成合理的阶段机会，但不能伪造一对一因果；周目标要有清楚的行动路径、计量单位、数据来源、完成判定、停止条件和去重规则。 7. **安全与非诊断边界**：明确适用和不适用人群、异常值、药物或疾病等混杂因素、风险覆盖和需要停止推荐的情况；不得把 Age、恢复或行为建议表达成医学诊断、寿命预测或保证改善。 8. **UI 与理解成本**：验证名称是否易懂、信息层级是否清楚、数量是否过多、主次如何表达、解释需要多深，以及数据不足、不可用、低置信和版本变化时页面怎样显示。 9. **版本迁移与历史冻结**：正式目录必须有版本和生效时间；指标增加、删除、改名或改口径时说明当前结果如何迁移，历史 Age、历史周计划和冻结报告继续读取当时版本，不用新规则重写。 评审输出至少包括候选指标清单、证据与数据评估、产品和 UI 方案、算法与结算规则、异常样例、版本迁移方案、验收用例以及明确的保留 / 调整 / 删除结论。不能只交一张指标表或一份文献摘要。 进入生产前需要完成角色签收：产品负责人确认用户价值、产品层级和范围；健康产品负责人确认科学表述、安全与非诊断边界；算法负责人确认数据、模型、校准和验证可行；设计负责人确认命名、数量、层级、解释和异常状态；Flutter、服务器和 Agent 负责人确认带版本目录、数据流转和能力边界可以实现；测试负责人确认正常、缺失、低置信、版本变化和历史冻结均可验收。任一关键角色未通过，不得把候选口径写成正式规则。 未通过完整评审时按以下方式降级：Age 不输出未经验证的精确年龄或贡献，只展示已经可靠的底层事实、趋势、数据准备状态或“暂时无法判断”；周计划只使用已经批准且可以可靠结算的目标，其他内容降为不计进度的辅助建议；Agent 只能读取已批准的指标目录版本，不能补指标、补权重或补完成；Demo 的名称、数值、阈值和映射不进入生产数据、接口与验收。 ### 5.5 行动、证据和结算 一个行动可以同时为多个周目标提供证据，但必须遵守“一次事实、一次完成、一次恢复成本”的原则。 正式进度必须具备： - 可读取的来源； - 清楚的计量单位； - 明确的目标或范围； - 可重复的完成判定； - 计划日期和账本版本； - 缺失、延迟、冲突和撤销行为。 设备直接获得且已经验证稳定的步数、心率区间、实际睡眠、活动负荷等，可以进入正式结算。运动记录目前仍需完成真机验证；验证前不能把活动类型、次数或时长默认写成自动完成。力量动作质量、压力卸载、饮食质量、主观疼痛、日光暴露等，如果当前没有可靠的设备或系统记录，只能作为辅助建议或上下文记录，不得显示虚假进度、完成率或“已结算”。 辅助建议仍然有价值，因为它们可能帮助用户完成真正可结算的目标；但界面必须明确它们是建议，不是用户需要额外打卡的第二套任务。 ### 5.6 自研健康评估与 Agent 边界 睡眠、恢复、负荷已经在 Fitbeing 产品化，现有数据定义、界面、手表固件算法和历史结果共同构成本次迁移基线。Kriki 不重新发明一套三项体系，而是把算法从手表固件迁入 Flutter App，再针对 Apple Health 的字段、来源、时间语义和缺失情况调整并验证。 迁移时先确定算法使用 Dart 实现，还是复用现有库并通过 FFI 或原生桥接接入。无论采用哪种方式，正式结果都在 App 端由同一套自研确定性算法形成。结果怎样保存、怎样提供给页面和 Agent，由 Flutter、Agent、服务器共同确定正式技术方案；无论采用哪条路径，服务器和 Agent 都不能另算第二份正式结果。 每份结果至少绑定原始数据时间、数据质量、个人基线、计算窗口和算法版本；关键数据不足、延迟、冲突或不可比时，算法降级或不输出，不用 0 分和默认值补齐。迁移结果必须用 Fitbeing 既有结果、固件与 App 对照样本，以及不同人群、设备来源和数据完整度的分层样本验证。 首页、今日数据、指标详情、计划和历史只读取算法已经保存的同一结果版本。打开页面不触发重算；历史日期读取当时保存的算法结果，不被新算法版本回写。 Agent 不参与三项指标计算，不调整算法权重，也不补写缺失结果。它只把正式结果用于解释当前状态、制定或调整方案，并清楚说明不确定性。 Recovery、HRV、静息心率、睡眠和负荷是判断和验证的输入/结果，不是用户需要手动完成的行动。用户不能通过点击“完成”改变健康分数，Agent 也不能把预期贡献提前写入已完成。 ## 6. 从长期目标到今天的方案 ### 6.1 阶段与周目标 长期目标不直接产生今天的动作，而是通过阶段和周计划逐步变成可执行的剂量： 1. 识别长期结果中当前最值得改善或保护的方向。 2. 结合个人基线、近期趋势、可比数据和用户当前目标形成阶段判断。 3. 在当前阶段下，从已批准的周目标目录中形成本周目标、优先级、剂量和限制。 4. 标记每项目标本周是重点推进、稳步推进、保持、保护或暂缓。 5. 每天根据实时身体预算和已完成账本分配当日剂量。 “重点”表示本周更需要推进，不表示其他指标不重要；完成状态与重点身份必须分开表达。今日卡片和周计划使用同一黄色星标表达重点身份，已完成只放在具体指标的完成状态上。 ### 6.2 每日方案 每日方案不是把全部周目标展开，而是决定今天真正需要用户关注的最小集合： - 今日身体策略：推进、维持、恢复或保护； - 今日主行动：目标、剂量、上限、停止条件和可结算来源； - 可替换路径：用户现实变化后可使用的等效方式； - 其他目标：现在无需处理、等待后续时点或只保留最低剂量； - 今晚或次日需要验证的结果； - 只在必要时显示的辅助建议。 除睡眠窗口或用户明确给出时间约束外，今日行动默认不捏造具体时点。Kriki 不知道用户几点下班，就不能写“下班后”；计划事项没有时间要求，就不能随意加时间点。 ### 6.3 结合用户偏好的实现方式 Agent 可以根据用户能力、喜欢的运动、器械和现实条件选择完成路径，但不能为了迎合偏好改变目标定义或结算规则。 例如同一项基础有氧目标，可以通过用户喜欢的骑行、跑步或快走完成，最终按设备实际活动结算。替换的是方法，不是目标；如果设备无法识别替换结果，界面必须降低为建议并说明结算限制。 ### 6.4 今日进度回写本周 设备或系统收到真实结果后： 1. 生成执行事实和来源引用。 2. 去重并写入日账本。 3. 将同一事实按固定规则映射到相关周轴。 4. 更新本周已到账进度和完成率。 5. 记录对今日剩余剂量、恢复成本和停止条件的影响。 6. 在数据足够形成稳定趋势后，进入长期验证链路。 预计贡献只能在计划说明中作为未来可能发生的量，不能提前计入完成率。 ## 7. Agent 系统 ### 7.1 Agent 的定位 Kriki Agent 是跨首页、计划、对话、通知、回顾、历史和记忆的决策协作层。它负责理解、解释、规划、协商、重排和验证；Kriki 自研健康算法负责睡眠、恢复、负荷的正式计算，其他确定性系统负责 Age、路由、权限、时间快照和结算。Agent 只能读取三项算法结果，不能另算、补写或改写。 ### 7.2 唯一结果所有者 每个权威对象只能有一个形成任务： | 对象 | 唯一 owner | | --- | --- | | 阶段判断 | `StagePlanFormationTask` | | 周计划 | `WeeklyPlanFormationTask` | | 今日方案 | `DailyPlanFormationTask` | | 日账本 | `DailyLedgerSettlement` | | 周账本 | `WeeklyLedgerSettlement` | | 干预验证 | `InterventionVerificationTask` | | 日回顾 | `DailyReviewFormationTask` | | 周回顾 | `WeeklyReviewFormationTask` | | 长期总结 | `LongTermSummaryFormationTask` | | 对话轮次 | `ConversationTurnTask` | | 历史搜索 | `ConversationHistorySearchTask` | | 安全结果 | `SafetyDecisionTask` | 首页、个人页、周计划页和对话页可以读取这些对象，但不能各自形成第二份方案或进度。 ### 7.3 Agent 什么时候启动 可以启动的事件包括： - 新计划日开始； - 有效健康数据变化足以改变判断； - 用户发送消息或选择快捷需求； - 用户提交现实变化、长期目标或近期诉求； - 实际活动或睡眠结算后需要重排剩余剂量； - 安全信号出现； - 计划到达复查或验证时点； - 记忆冲突需要处理。 不会仅因为以下行为启动完整 Agent： - 打开首页； - 滚动页面； - 查看已有方案； - 切换历史日期； - 展开已保存的解释； - 打开历史列表； - 复制产品文档。 ### 7.4 Agent 的上下文 Agent 只读取当前任务需要且获得授权的最小上下文： - 当前日期、时区和计划版本； - 长期目标、阶段和本周账本； - 睡眠、恢复、负荷和数据质量； - 用户当前明确的限制和意愿； - 相关的确认记忆和既往验证结果； - 权限、订阅和可用工具状态； - 触发消息、附件或现实变化。 旧历史不会因为“存在”就全部塞进上下文。历史回顾是读取已保存对象，除非用户提出新的问题，不应偷偷重跑 Agent。 ### 7.5 Agent 运行结果 Agent 输出必须能落入下列一种： - 解释当前判断； - 形成或更新正式阶段/周/日计划； - 提出待确认的调整； - 执行安全保护； - 发送必要主动消息； - 生成日/周回顾； - 形成验证结果或记忆候选； - 明确不改变当前状态。 每个结果至少记录任务身份、触发来源、基础对象版本、输入快照版本、使用的规则/模型版本、权限状态、输出版本、确认状态、过期时间和终止状态。 ### 7.6 用户确认与自主程度 低风险、可逆、局部的替换可以直接生效，但必须让用户看到变化和后果。改变周目标、总量、阶段方向、主要行动或跨日影响时，先展示旧方案、新方案、差异、代价和确认入口。 用户确认针对具体对象和版本。基础版本变化、参数变化或安全状态变化会使旧确认失效，不能把旧确认套到新方案上。 ### 7.7 失败、重试和停止 终止状态包括：成功、无变化、等待用户、用户取消、安全阻止、权限失效、版本过期、预算耗尽、可重试失败和需要人工处理。 不确定的写操作不能盲目重试。必须先读回实际状态，再使用同一任务和幂等键重试。页面出现“处理中”时，不把它当作已发送的消息或已生效的计划。 ## 8. 用户界面与交互规则 ### 8.1 首页 首页是当天决策入口，不是所有系统信息的总览页。主层级： 1. Kriki 与当前称呼； 2. 睡眠、恢复、负荷等当天状态； 3. 今日主行动和实际进度； 4. 本周进展和本周计划入口； 5. 必要的回顾、提示和对话入口。 页面应让用户一眼知道“我现在要做什么”。周计划、数据证据、替代方式和辅助建议可以存在，但不能与今日主行动争夺主角位置。 ### 8.2 Kriki 入口与气泡 左侧 Kriki 图标是快速发起入口。点击图标可以展开一级菜单；对话页也必须提供相同的快捷选项，直接进入对话的用户不需要返回首页才能使用。 入口旁的气泡用于展示当前最重要的一条可行动提示，例如处理中任务完成或一条必要主动联系： - 同一入口固定只展示最新一条气泡； - 用户点入气泡后直接进入对应对话或详情； - 点入即视为已读，返回后不再重复显示同一条气泡； - 有气泡时不额外挂未读角标； - 无气泡但存在未读历史时，未读角标挂在 Kriki 图标上，而不是发送按钮或消息列表； - 气泡应轻量、低遮挡、长期可挂，不把首页变成通知中心； - 气泡内容不替代完整消息，完整内容仍进入历史。 ### 8.3 对话 对话页的空状态只显示一句自然欢迎语，并使用用户设置的称呼。欢迎语不是 Kriki 已发送的消息，不应伪装成左右对齐的消息气泡。 对话页： - 标题栏提供历史图标入口； - 消息列表只放真实用户消息、Kriki 回复和轻量处理状态； - 快捷选项放在输入框上方，体现“用户选择后发送给 Kriki”； - 默认只展示一级常用需求；选择“调整今日方案”后才展开二级选项； - 用户可以不选快捷项直接输入； - 输入型入口进入对话后，必须在同一次点击中出现光标和演示键盘； - 从消息气泡进入阅读态时，不误弹键盘； - 用户发送后清空输入并保留线程； - 处理中任务离开页面后完成，必须通过气泡/角标通知。 ### 8.4 常用快捷需求 一级快捷需求是用户语言，不是内部研发术语： - 调整今天的安排； - 了解今天为什么这样安排； - 补充新的情况； - 说说今天的感受。 “参与调整”不是用户文案。快捷项必须与自由输入走同一意图和任务通道，不能有隐藏的后门逻辑。 ### 8.5 历史与日期 历史对话按天分组，但底层对象可以跨天关联。用户可以按日期和内容搜索，找不到日期时也能通过关键词找回“上次膝盖不舒服”等事件。 首页与今日数据共用的日期轨道可以从今天连续回溯到用户开始使用 Kriki 的第一天，不能把最近 7 天作为历史上限。这里的第一天指用户完成首次使用流程并首次进入 Kriki 首页的日期，包括数据仍在准备中的受限首页；它不是注册日期，也不要求当天已经形成完整快照。界面可以按时间窗口分段加载，日历可以直接定位范围内任意日期；某天没有完整数据时保留该日期并展示数据不足或暂无记录，不能隐藏日期或借用相邻日期结果。 日期切换是读取行为： - 历史日展示冻结快照、当日语境和当日时间； - 页面里不再把当前日期称为“昨天”； - 今天打开时可以说“昨日回顾”，切到昨日页面后应显示具体日期或“当天回顾”； - 切换日期不能用今天的计划覆盖历史事实； - 历史页面不能因为打开而产生新 Agent 任务。 ### 8.6 日内感受记录 日内感受作为独立卡片或日期上下文区域呈现，与对话分开。常用选项和输入框由同一个“保存”按钮提交。保存只写入该日期记录，并在之后可供 Agent 使用；不发消息、不直接改计划、不显示完成率。 ### 8.7 本周计划与修改 本周计划应在首页上方有明显但克制的入口，用户知道可以主动告诉 Kriki 变化。用户可以随时修改当前周计划，系统重点不是禁止修改，而是让后果透明： - 可替换执行方式：通常可直接生效； - 未来剩余几天的剂量分配：展示变化后直接生效或请求确认； - 目标、周总量、重点、主要行动或阶段方向变化：必须显示新旧差异并确认； - 已完成事实、已结算日期和历史数据：不可回写； - 周末或最后一天仍可以修改，但含义变成处理今天剩余安排或关闭当前周，不伪装还能重排完整一周； - 修改后的影响只作用于当前周版本，不自动改写下周； - 下周仍由长期目标、阶段和届时状态独立形成。 ### 8.8 每日与每周回顾 “反馈”是研发内部词，不作为产品主标题。用户看到的是“回顾”“本周结果”“计划”“变化”等自然表达。 **昨日回顾**： - 关注前一天的计划、实际完成、身体反应和仍需留意的事情； - 不阻塞今天的首页和今日方案； - 今天打开时在日期区域附近给一个醒目但轻量的入口； - 查看后不再重复提示；进入历史某一天时使用具体日期语境； - 前天、再前一天仍按各自日期可查看，不因为昨天看过就丢失。 **上周结果**： - 是一次性周期报告，与本周持续使用的计划完全分开； - 固定入口放在个人页“当前改善方向”下方； - 在新周首次打开时，日期区域上方显示一次提示，可直达报告； - 用户查看后，或新周第二个自然日打开 App 后，提示不再出现； - 报告可快速切换更早的周； - 报告展示完成情况、实际指标变化、对 Age Delta 的积极/消极影响、证据可信度和未能判断的部分； - 报告不直接替代本周计划，也不把上周大幅内容放到本周首页主位。 ### 8.9 通知与未读状态 需要触达的情况包括： - 用户离开后，Agent 完成了用户刚提交的任务； - 当前方案因新数据失效或需要确认； - 安全相关信息需要尽快看到； - 日/周回顾已形成且符合触达条件。 不应因为每次数据刷新、普通进度变化或没有新行动就打扰用户。通知、气泡和角标共用同一条消息状态，已读必须跨入口一致。 ### 8.10 视觉与设计系统 Kriki 的 UI 需要先形成统一底座，再按模块交付页面： - 先评估 Fitbeing 已上线页面和品牌资产，标明直接复用、结构复用后调整和重新设计的部分； - 确定颜色、字体、间距、圆角、图标、图表、动效和明暗模式等设计语言； - 建立 Logo、App Icon、通知图标及其单色、小尺寸和不同背景版本； - 在 Figma 中建立变量、组件、变体和主要状态，覆盖 MVP 的真实内容和异常场景； - 统一页面命名、版本、标注、切图、开发交接和真机验收方式； - 发布前由同一套品牌母版生成 App Store 展示图片和所需市场素材。 页面设计必须检查动态字号、VoiceOver、对比度、触控范围、不同 iPhone 尺寸和减少动态效果。设计系统不是展示样张，开发和测试需要能直接使用它完成实现与验收。 ## 9. 回顾、验证与长期学习 ### 9.1 日回顾 日回顾由当日已冻结的计划版本、执行账本、用户感受和次日身体结果组成。它可以解释： - 原计划交付了什么； - 实际完成了什么； - 哪些变化是设备事实，哪些只是用户感受； - 是否需要在下一个有效时点重新判断。 日回顾不把一天的偏差直接升级为长期结论，也不在用户没有主动对话时机械生成一条消息。 ### 9.2 周结果报告 周结果报告是一次性冻结对象，不是本周计划的另一个版本。它应包含： 1. 周期和使用的计划版本； 2. 当时周目标目录版本、各项目标、已结算结果和完成率； 3. 重点项目是否达成； 4. 哪些指标产生变化； 5. 这些变化与 Age Delta 因素的关系及证据范围； 6. 这周是否观察到 Age 的变化，若未更新要说明原因； 7. 哪些结论证据不足，不能假装有因果； 8. 对未来规划的可用证据，但不替下一周直接制定计划。 ### 9.3 验证链路 每个需要长期验证的方案都应记录： - 干预标识； - 预期观察； - 验证窗口； - 实际执行引用； - 身体反应引用； - 可比性判断； - 结果可信度； - 验证时间； - 下一次检查。 “Agent 说这个方案有效”不是验证结果。一次活动、一次睡眠或一次分数变化不能单独证明因果。 ### 9.4 记忆治理 记忆分为： - 工作记忆：当前任务、当前日期和当前对话所需的临时信息； - 已确认事实：用户明确要求记住或确认的稳定信息； - 偏好与协作方式：例如周末通常更容易在上午训练； - 模式候选：重复证据形成但仍等待确认的规律； - 干预证据：用于验证未来计划的历史结果。 一次性表达、一次不完成或忽略建议，不自动写入长期记忆。用户明确“记住”或系统通过足够的可比结果形成候选后，才进入记忆确认流程。用户纠正、删除、矛盾或过期会停止后续召回；历史运行仍保留当时使用的版本，不把删除内容带回当前上下文。 ## 10. 业务对象、版本和传递 ### 10.1 关键对象 产品与技术设计至少需要区分以下业务对象。这里描述的是对象含义，不预先确定接口名称、字段名、存储位置或通信方式；这些内容由正式 PRD、数据规范和技术架构共同确定： - **健康事实**：来源、时间、单位、值、质量和授权状态； - **健康评估结果**：自研算法形成的睡眠、恢复、负荷正式结果，包含原始数据时间、质量、个人基线、计算窗口、算法版本、可信度和降级状态； - **输入快照**：某次判断实际读取的信息及对应版本； - **阶段方向**：当前改善重点、周期和约束； - **本周计划**：已批准周目标目录版本，以及本周目标、重点、剂量和限制； - **今日方案**：某日行动、剂量、来源、停止条件和验证安排； - **日账本与周账本**：实际执行和正式结算； - **日回顾、周回顾与干预验证**：计划、执行和身体变化的比较结果； - **消息与对话索引**：用户和 Agent 消息、时间、状态、关联任务及历史检索信息； - **记忆候选与确认记忆**：等待确认的信息和可持续使用的信息； - **通知记录**：通知、气泡、角标和已读状态； - **Agent 运行记录**：一次任务的触发、上下文、输出和终止状态。 ### 10.2 版本规则 任何计划重排都生成新计划版本： - 保留旧版本、创建原因、用户确认和生效时间； - 已完成事实引用原账本，不因新版本变化； - 首页、对话、周计划、通知和历史读取同一当前版本； - 历史日期读取冻结版本； - 输入快照变更会使未提交任务替代、重试或过期； - 不能通过“刷新页面”隐式产生新版本。 ### 10.3 传递规则 当健康数据到账： `Apple Health → Flutter 同步与字段处理 → 数据质量与个人基线 → Flutter App 内自研健康算法形成正式结果 → 按正式技术架构保存与同步 → 页面 / Agent 读取同一版本 → 计划与验证` 这条链路只说明业务先后关系，不代表 Flutter、服务器和 Agent 之间已经确定了通信方向、接口形式或部署方式。 当真实执行数据到账： `数据源 → 执行事实去重 → 日账本 → 周账本 → 页面投影 / 回顾 → 验证证据` 当用户提出变化： `入口 → 用户消息 / 修改草稿 → Agent 任务 → 提案或正式计划版本 → 消息、首页、周计划同步` 任何页面都不能绕过这个链路直接写一个局部结果。 ## 11. 安全、权限和降级 ### 11.1 安全优先级 安全保护和用户明确的当前限制高于表现目标、周目标和便利性。出现明显疼痛、肿胀、不稳、异常恢复或其他风险信号时，Agent 可以直接降低、暂停或终止相关行动，并清楚说明边界；不能给出疾病诊断。 ### 11.2 数据质量 数据缺失、延迟、冲突、撤销或不可比较时： - 标明缺什么； - 说明仍可靠的部分； - 降低可信度或暂不生成结果； - 不用 0 分替代缺失； - 不用默认值补齐历史； - 不把异常瞬时值直接变成高风险行动。 - 算法失败或结果版本不一致时，不让 Agent 补算；显示最后可靠结果及时间，或明确暂无结果，历史仍读取当时保存版本。 ### 11.3 权限 权限按最小必要范围授予。用户撤销健康、通知、日历或后台权限后： - 新任务不得继续读取无授权数据； - 依赖该数据的未提交任务停止、降级或重算； - 已冻结历史仍按保留规则可见； - App 不因拒绝权限而阻塞基本浏览； - Agent 不得反复索取或推断用户没有提供的日程。 ### 11.4 订阅 订阅只决定新增 Agent 能力和服务权益，不改变已有数据、历史、导出、删除和基础读取权利。订阅失效时明确说明哪些能力不可用，不删除已形成的事实和计划历史。 ## 12. 研发与测试分工 ### 12.0 需求期间的并行预研与架构确认 产品经理完善各模块正式 PRD 期间，Flutter App、Agent 和服务器团队不能等待。三方先基于当前 Demo 和已经明确的业务流程，使用固定模拟数据做一个标记为 `trial-v0` 的试验性通信 Demo，大致跑通应用层发起任务、必要上下文传递、Agent 返回结构化结果和处理状态、应用层展示与读回，以及失败可见的最小链路。 这个 Demo 只用于验证技术链路和尽早发现问题，不要求完全符合之后的正式产品需求，也不作为 UI、功能或上线验收标准。临时页面、对象、字段、Prompt 和模拟业务规则默认不进入生产；只有经过三方评审确认的通信、任务状态、结构化结果、日志和错误处理底座才可以复用。 三方同时共同形成正式技术架构，至少明确： - Flutter、Agent、服务器分别负责哪些业务和正式结果； - 谁与谁通信、在什么时机通信、传递哪些信息； - 同步与异步任务怎样返回状态，正式结果由谁保存和提供； - 鉴权、权限、版本、幂等、超时、重试、取消和读回怎样处理； - 开发、测试和生产环境怎样联调，日志、监控和问题定位怎样串起来。 对应模块只有在正式 PRD 和技术方案评审通过后，才进入正式开发。当前 Demo、既有 PRD 和本文件只能作为输入，不能替代这两项交付。 ### 12.1 产品经理 产品经理负责： - 维护对象、时间层级、已批准指标目录及版本和用户语言； - 把讨论中的明确决定提炼为长期规则； - 明确哪些是已定、待确认和排除； - 为每项功能指定 owner、输入、输出、状态、传递路径和验收； - 根据现有参考材料形成可交付的模块 PRD，补齐规则、流程、状态、异常、数据、权限和验收，并组织评审通过； - 在每个模块 PRD 中定义本模块真正需要的埋点，发布前再统一汇总、去重并补齐跨模块漏斗； - 防止把 UI 调整记录、内部术语或临时例子误写成产品规则； - 在阶段、周、日、历史和回顾之间检查概念不混淆。 ### 12.2 设计师 设计师负责把系统边界变成用户能理解的层级： - 今日主行动优先于完整机制； - 重点、完成、提示、未读、处理中各自有不同表达； - 气泡、角标和通知不重复表达同一件事； - 周报告与本周计划不混成一张卡； - 历史日期使用具体日期语境； - 辅助建议不伪装成可结算任务； - 输入型入口直接进入输入态，阅读型入口保持阅读态； - 先完成 Fitbeing 页面复用评估，再确定 Kriki 视觉风格和设计语言； - 建立 Logo、App Icon、Figma 变量、组件、状态和交付规范； - 按同一套品牌规则完成 App Store 展示图片； - 大字号、VoiceOver、系统字号、键盘和减少动态效果都可用。 ### 12.3 Flutter App 开发工程师（胡磊） Flutter App 开发工程师负责： - 在正式需求完成前，与 Agent、服务器完成试验性通信 Demo，记录跑通的链路、发现的问题和可复用结论； - 与 Agent、服务器共同确定正式技术架构、通信方式、状态归属和接口边界； - 盘点 Fitbeing 邮箱登录、Apple Health 和已有页面代码，明确直接复用、裁剪、适配和需要重做的部分； - 搭建 Flutter 工程的模块、环境、路由、网络、缓存、日志、构建和代码规范； - 通过插件、Platform Channel、FFI 或必要的原生桥接使用 HealthKit、StoreKit、通知和三项算法能力； - 使用唯一 source of truth 和 outputVersion； - 区分投影、修改入口、确定性区域和 Agent owner； - 保持日期、时区、历史快照和当前计划版本一致； - 使用幂等键、读回校验和可恢复任务； - 不把自然语言直接解析成未经确认的领域对象； - 不让页面打开、滚动和历史浏览产生隐式 Agent 任务； - 让真实设备事实进入统一账本而不是各模块局部累计； - 记录可追溯的运行、权限、规则和输出版本； - 在真实 iPhone 和支持的 iOS 版本上验证权限、后台、时区、通知、订阅和发布构建。 ### 12.4 服务器开发工程师（刘振庭） 按照三方技术架构评审确认的职责分工，负责服务器侧工作： - 在正式需求完成前，与 Flutter、Agent 完成试验性通信 Demo，并参与确定正式技术架构； - 复用或适配 Fitbeing 的认证和现有服务能力；用户、协议、启用、计划、账本、回顾、历史和权益等业务能力由谁保存、怎样同步，以已评审需求和三方正式技术架构为准； - 与 Flutter、Agent 共同确定三项健康结果怎样保存、同步和读取；服务器不另算第二份正式结果； - 维护鉴权、账号隔离、幂等、版本冲突、失败恢复和读回接口； - 搭建开发、测试和生产环境，完成数据库迁移、监控、告警、备份、降级和回滚； - 为 Flutter、Agent 和测试提供同一套接口、错误状态、联调数据和问题定位方式。 ### 12.5 算法负责人（陈海杰） 负责算法侧工作： - 以 Fitbeing 已上线的定义、固件算法、历史结果和样本为迁移基线； - 把睡眠、恢复、负荷算法迁入 Flutter App，并确定 Dart、FFI 或原生桥接的实现方式； - 完成 Apple Health 字段、来源、时间窗口和缺失情况的适配； - 形成三项自研算法的正式输出； - 原始数据质量、个人基线、计算窗口、可信度、算法版本和缺失降级； - 确保相同输入和算法版本得到相同结果； - 维护算法回归样本、版本发布、监控和回退； - 确保历史读取当时保存结果，不被新版本回写； - 明确 Agent 只能读取和解释，不能参与计算或修改权重。 ### 12.6 Agent 工程师 按照三方技术架构评审确认的职责分工，负责 Agent 侧工作： - 在正式需求完成前，与 Flutter、服务器完成试验性通信 Demo，并参与确定正式技术架构； - Agent 任务触发、上下文选择、权限、工具和知识边界； - 形成对象的唯一 owner 和写入规则； - 确认、拒绝、取消、版本过期、重试和恢复状态； - 现实执行和身体反应的验证链路； - 记忆候选和长期记忆的确认、纠正、删除与过期； - 运行评估、回归用例和事故后的规则修复； - 确保 Agent 只读取自研算法已经形成的正式结果，不生成、补写或改写睡眠、恢复、负荷结果。 ### 12.7 测试与发版工程师（陈晓珠） 测试不能只验证“回复读起来像不像人”，还要验证最终状态： - 页面读取的对象和版本是否正确； - 计划、账本、回顾和 Age 是否按正确时间层级传递； - 设备事实是否重复结算； - 预期贡献是否错误显示为完成； - 用户修改是否透明、不回写历史、不偷偷改下周； - 气泡点入是否清除对应未读，是否重复出现； - 历史日期是否不使用错误的“昨天”语境； - 键盘、复制全文、搜索、日期切换和无障碍是否可用； - 数据缺失、冲突、权限撤销、算法失败或版本不一致、Agent 失败、网络中断和版本冲突是否进入可知状态。 - 相同输入和算法版本是否得到相同结果，历史是否保持原版本，Agent 是否从未自行生成或改写三项指标。 - Fitbeing 复用代码与 Kriki 新增代码是否分别完成回归和差异验证； - Flutter 客户端在真实 iPhone、支持的 iOS 版本和不同 Apple Health 数据来源下是否可用； - TestFlight 分发、App Store Connect 配置、提审、审核跟踪和正式发版是否有完整操作记录。 测试数据、缺陷和运行埋点不得保存原始健康数据、完整对话、账号凭据或完成任务不需要的个人信息。 ## 13. 关键验收场景 ### 13.1 正常晨间 给定已授权的前一晚与当日健康数据，自研算法先形成带数据质量、个人基线和算法版本的睡眠、恢复、负荷结果；首页、详情和 Agent 读取同一快照，显示当天策略、主行动、真实已到账进度和贡献目标；不显示内部推理全文。 ### 13.2 用户只有 20 分钟 用户从首页或对话输入入口进入并说明时间变化。页面立即进入输入状态。Agent 读取当前计划版本，给出原剂量与新剂量、保留内容和放弃内容，必要时确认；确认后新版本生效，旧已完成事实不变。 ### 13.3 用户报告疼痛 安全任务优先。相关行动进入保护/暂停，必要时显示停止条件和建议寻求专业帮助；不能为了完成率继续追加训练，不能把疼痛写成诊断。 ### 13.4 用户离开后任务完成 消息线程保留处理中状态但不把它写成消息。Agent 任务完成后生成一条通知记录；入口展示最新气泡，点入对应对话后标记已读，返回不重复显示。 ### 13.5 普通数据更新 设备更新步数或负荷，但未达到会改变判断的阈值。确定性服务更新账本，页面刷新可见进度；不启动完整 Agent，不发送无意义通知。 ### 13.6 上周报告 新周首次打开时日期区域上方显示一次入口。用户查看后不再显示；即使用户第二天首次打开，也不显示入口。进入报告可切换更早周，报告不替换本周计划主卡。 ### 13.7 历史日期 用户可以从首页或今日数据连续回溯至首次进入 Kriki 首页的日期，也可以通过日历直接定位；最近 7 天只能作为默认可见或分段加载窗口，不能成为可查看范围。切换到某个历史日期后，页面显示该日冻结数据、该日方案和该日回顾；当天没有完整快照时显示真实缺失状态，不借用其他日期结果。所有文案使用具体日期，不把“昨天”相对当前日期重新计算；打开不会新跑 Agent。 ### 13.8 日内感受 用户选择“腿有点酸”并输入补充，点击“保存”。记录落入当前日期上下文，不发消息、不生成完成率；未来 Agent 任务可以读取这条记录并引用其日期和来源。 ### 13.9 复制产品全景说明 在 PRD 的产品目录中进入“团队产品全景说明”，页面显示本文标题、更新时间、阅读提示和全文。点击“复制全文”后，剪贴板内容应包含完整 Markdown 文本，不截断、不只复制当前屏幕；失败时给出可选中复制的降级文本区域。 ### 13.10 算法失败与版本切换 当自研算法不可用、关键输入不足或结果版本不一致时，页面显示明确降级状态，不让 Agent 临时补算。恢复后以新版本形成当前结果，但历史日期继续读取当时保存的算法结果；QA 必须验证同输入同版本结果一致。 ### 13.11 复用账号能力并完成全新首次使用 从冷安装开始，邮箱登录使用 Fitbeing 已确认可复用的链路；登录成功后进入 Kriki 全新的协议、资料、目标与限制、Apple Health 授权说明、首次同步、三项结果和今日方案。每一步退出后都能继续，不能重复建号、重复记录同意或重复生成结果。测试需要分别留下“复用链路回归”和“全新首次使用验收”两份结论。 ## 14. 目前已确定与仍待定 ### 14.1 已确定 - Kriki 是个人 AI Coach，终极价值是长期身体机能和活力方向，而不是完成任务本身。 - 产品闭环是洞察、方案、协商、执行、验证、学习。 - Age/长期、阶段、本周、今日和执行账本分层，低层不能反写高层。 - 本周和下周平级；本周修改不直接改写下周。 - 稳定的是长期结果、阶段、本周、今日和执行账本逐层传递，以及正式进度必须有可靠结算来源；Age 和周计划的指标数量与具体目录仍需评审。 - 真实设备可测、可结算的事实进入正式进度；不可可靠测量的内容只能是辅助建议或上下文记录。 - 完成、重点、提示、未读、处理中和回顾是不同状态。 - 对话是协商和任务入口；快捷项在输入框上方；输入型入口直接进入键盘输入态。 - 历史按天保存，周报告独立于本周计划；通知和未读状态跨入口一致。 - 睡眠、恢复、负荷由 Kriki 自研健康算法计算并输出正式结果；Agent 只读取、解释和用于计划，不能另算、补写或改写。 - Agent 不能绕过唯一 owner 写正式对象，不能用自我解释替代外部验证。 - 首个上线版本只发布 iOS App，客户端基于 Flutter 开发；Apple Watch 仅作为 Apple Health 数据来源，不开发独立 watchOS App，其他客户端不进入本轮 MVP。 - Fitbeing 的邮箱登录和 Apple Health 读写链路是成熟复用基础；Kriki 只按需要裁剪和适配，不从零重建。 - 登录后的首次使用流程由 Kriki 全新设计，并与邮箱登录状态分开保存。 - Fitbeing 已产品化的三项定义、界面、固件算法和历史结果是迁移基线；算法迁入 Flutter App 后形成正式结果，服务器不另算。 - UI 先建立视觉语言、品牌资产、Figma 设计系统和交付规范，再按模块交付页面。 - 埋点随模块需求定义，发布前统一汇总、去重和补齐跨模块事件。 - 当前 Demo、产品蓝图、既有 PRD 和架构图都是参考输入；产品经理需要按模块形成并评审正式 PRD，不能直接把参考稿交给开发。 - 产品完善需求期间，Flutter、Agent、服务器先做试验性通信 Demo，并同步共同形成正式技术架构。 ### 14.2 仍待定，不能在实现中自行猜定 - 睡眠、恢复、负荷算法的生产公式、权重、样本、阈值和发布标准； - Age 候选指标的保留、拆分、合并与新增，以及最终生产指标目录； - Age 的证据等级、数据来源、基线、窗口、归一化、冗余校正、权重、年龄换算、缺失处理、可信度和发布阈值； - 周计划候选指标的数量、名称、分组、与长期指标的映射、是否按用户和阶段选择性出现，以及对应的产品与 UI 方案； - 各周目标的数据来源、计量、结算、最低有效量、目标范围、上限、安全阈值、缺失降级和版本迁移规则； - Apple Health 与其他设备来源的完整优先级和去重细则； - Apple Health 写回是否进入 MVP，以及进入时具体写回哪些数据； - 运动记录能否稳定读取并用于自动结算； - 三项算法最终使用 Dart、FFI 还是原生桥接迁入 Flutter App； - Flutter、Agent、服务器之间的正式通信拓扑、接口与任务协议、状态归属、部署方式和运行责任； - 具体通知渠道、免打扰策略和主动联系频率； - 订阅分层、免费体验能力和服务权益； - 真实用户验证中“用户感到被理解”和长期改善的量化指标。 待定项必须由对应负责人形成版本化决策，不能由某个页面、提示文案或模型临时决定。 ## 15. 团队共同判断标准 评估一个新需求时，先问： 1. 它服务哪个用户任务？ 2. 它属于洞察、方案、协商、执行、验证还是学习？ 3. 它产生的是事实、判断、目标、计划、执行、结果还是记忆？ 4. 哪个任务拥有这个结果？ 5. 它的输入、版本、权限和数据质量是什么？ 6. 用户是否能接受、修改、拒绝或纠正？ 7. 结果如何进入账本、历史、通知、回顾或未来规划？ 8. 什么情况下它不应运行、应降级或应停止？ 9. QA 能否用最终状态证明它正确？ 10. 它有没有把内部研发语言、模型输出或视觉装饰误当成用户需要的产品对象？ 如果这些问题没有答案，需求还没有达到可以开发的程度。 ## 16. 最终理解 Kriki 的价值不是替用户增加更多目标，而是替用户承担理解、取舍和持续调整的复杂性。它需要把今天的努力做得足够具体、足够可测、足够适合现实；同时让用户看见这份努力如何进入本周、怎样被身体反应验证，最终是否让长期方向变好。 因此，团队每次设计功能都要同时守住两件事： 1. **对当下诚实**：不伪造数据、不伪造完成、不伪造确定性，不让用户做无法验证的无意义记录。 2. **对长期负责**：不把今天变成孤立待办，不让周报告取代当下，不让一次行为冒充因果，让真实执行和验证逐步形成下一次更好的判断。 这两件事共同构成 Kriki 的产品灵魂：它不是要求用户跟上一个僵硬的计划，而是持续理解这个人，在真实生活里带着他把身体慢慢带到更好的方向。