# Kriki Coach 正式产品需求入口

**目录状态**：当前有效  
**建立日期**：2026-08-13  
**适用对象**：产品、设计、Flutter、服务器、算法、Agent、测试及参与本项目的 AI

## 1. 这个目录解决什么问题

本目录是 Kriki Coach 正式产品需求的唯一入口，用于把全局产品规则、Agent 共用规则和各模块的具体需求分开管理。

过去的产品总览、Demo 内嵌 PRD、页面说明、研究稿和历史 PRD 提供了大量有价值的思路，但它们混合了产品介绍、设计探索、历史决定、模拟数据、内部名称和未确认参数，不能直接作为开发与测试依据。

从本目录建立后：

- 全产品必须共同遵守的稳定规则写入《Kriki Coach 产品需求基线》；
- 所有 Agent 功能共同遵守的运行规则写入《Agent 系统产品要求》；
- 页面、流程或业务对象的完整实现要求写入对应模块 PRD；
- Demo、产品蓝图、历史文档、研究资料和生成内容只作为需求输入，不因被展示或被引用而自动生效；
- 团队可复制提示词必须从当前正式 PRD 提取，不再把旧提示词或对话上下文当作需求来源。

## 2. 当前文档

| 文档 | 作用 | 当前状态 |
| --- | --- | --- |
| [Kriki Coach 产品需求基线 V1.0.md](./Kriki%20Coach%20产品需求基线%20V1.0.md) | 规定产品定位、范围、业务闭环、对象关系、算法边界、版本和全局验收底线。 | 当前草案，供模块 PRD 共同引用；待产品评审。 |
| [Kriki Coach 对象与责任台账 V1.0.md](./Kriki%20Coach%20对象与责任台账%20V1.0.md) | 统一正式业务对象、唯一形成方、消费者、版本关系和模块归属。 | 当前草案，随模块 PRD 联合评审。 |
| [Agent 系统产品要求 V1.0.md](./agent/Agent%20系统产品要求%20V1.0.md) | 规定 Agent 何时运行、读取什么、如何使用知识与工具、怎样形成和保存结果、如何失败恢复与验证。 | 当前草案，供所有 Agent 模块共同引用；待产品与技术联合评审。 |
| [Kriki Coach 待确认事项台账 V1.0.md](./Kriki%20Coach%20待确认事项台账%20V1.0.md) | 把各模块的未决参数组织成有优先级、负责人、阻塞范围和关闭条件的决策包。 | 当前草案；所有决策仍须评审并写回对应正式 PRD。 |
| [modules/](./modules/) | 按完整业务对象和用户任务编写的模块 PRD。 | 已形成 16 份正式候选草案；均需关闭各自阻塞项并完成评审后才能作为上线依据。 |

文档已经形成不等于需求已经批准。任何模块仍不得仅凭 Demo、候选草案或未关闭的参数进入正式上线。

## 3. 文档效力顺序

出现冲突时按以下顺序处理：

1. 用户最新明确决定；
2. 已评审通过且标记为当前有效的模块 PRD、产品需求基线和 Agent 系统要求；
3. 已评审的数据规范、算法规范、安全规则、设计稿、技术方案和验收方案；
4. 当前有效的正式业务对象及其版本；
5. 产品全景说明、Demo、产品蓝图、历史 PRD 和架构参考中的一致内容；
6. 外部研究、竞品信息、模拟数据和未确认假设。

较新的正式文档只覆盖明确修改的内容，未修改部分继续沿用原有效规则。无法确认冲突时，必须进入“待确认事项”，不能由页面、工程师或 AI 自行选择一种解释。

## 4. 文档状态

所有需求文档必须标明状态：

| 状态 | 含义 |
| --- | --- |
| 已批准 | 已完成对应角色评审，可以作为开发、设计和测试依据。 |
| 当前草案 | 当前正在维护的正式候选稿，可以用于讨论和补充，尚不能独立批准上线。 |
| 待确认 | 会影响产品结果但尚无明确决定，不得在实现中自行猜定。 |
| 历史参考 | 保留形成过程和旧决定，只用于追溯，不再指导当前实现。 |
| 研究参考 | 外部证据、竞品、原理或可行性材料，不直接构成 Kriki 产品规则。 |
| Demo / 生成内容 | 用于展示、试验或从正式文档派生的内容，不能反向覆盖正式需求。 |

文件名中带有“PRD”不等于已经批准；是否有效以文档状态和评审记录为准。

## 5. 当前模块 PRD 目录

当前模块按业务对象和完整用户任务组织，而不是按页面零散写说明：

| 模块 | 主要责任 | 当前状态 |
| --- | --- | --- |
| [00-账号、登录注册与会话](./modules/00-账号、登录注册与会话.md) | 账号身份、邮箱注册与验证、登录、找回、认证会话、退出切号和跨账号隔离 | 当前草案；身份复用、凭据、验证、会话和合规规则仍有阻塞项 |
| [01-首次使用](./modules/01-首次使用.md) | 有效身份成立后的启用说明、首次资料、权限、同步、三项结果与首份方案串联 | 当前草案；资料、同步、形成条件和订阅先后仍有阻塞项 |
| [02-长期目标与阶段](./modules/02-长期目标与阶段.md) | 目标维护、阶段形成、复核及向周计划传播 | 当前草案；目标结构、周期和复核条件仍有阻塞项 |
| [03-本周计划](./modules/03-本周计划.md) | 周计划形成、修改、版本传播和周进度读取 | 当前草案；目录、结算、调整和跨周规则仍有阻塞项 |
| [04-今日方案与调整](./modules/04-今日方案与调整.md) | 今日方案、同批解释、日内调整、确认和恢复 | 当前草案；调整风险分级、重排和过期规则仍有阻塞项 |
| [05-执行与结算](./modules/05-执行与结算.md) | 执行事实、日/周账本、去重、修订和进度事实 | 当前草案；来源、结算、纠错与晚到数据规则仍有阻塞项 |
| [06-每日与每周回顾](./modules/06-每日与每周回顾.md) | 日/周回顾、干预验证、冻结历史和已读 | 当前草案；形成时点、验证和修订规则仍有阻塞项 |
| [07-Age Delta](./modules/07-Age-Delta.md) | Age 指标目录、确定性结果、贡献、趋势和解释边界 | 当前草案；模型、目录、窗口和发布标准仍有阻塞项 |
| [08-三项身体状态算法](./modules/08-三项身体状态算法.md) | 睡眠、恢复、负荷的数据质量、确定性形成、发布和解释 | 当前草案；正式输入、模型和质量参数仍有阻塞项 |
| [09-对话与主动联系](./modules/09-对话与主动联系.md) | 消息、对话、任务路由、历史搜索、主动联系与已读 | 当前草案；输入、并发、频控和历史规则仍有阻塞项 |
| [10-个人与 Kriki 设置](./modules/10-个人与Kriki设置.md) | 个人资料长期维护、摘要、Kriki 偏好、记忆、目标入口和关系事件 | 当前草案；资料字段、传播、记忆、冲突和熟悉度规则仍有阻塞项 |
| [11-数据看板](./modules/11-数据看板.md) | 三项状态、方案影响、指标趋势与数据证据的同版读取 | 当前草案；指标目录、默认排序、历史范围和快照规则仍有阻塞项 |
| [12-系统设置与隐私](./modules/12-系统设置与隐私.md) | 账号安全摘要与操作入口、数据来源、权限、App 偏好、数据权利和支持 | 当前草案；权限矩阵、隐私范围、时限和兼容规则仍有阻塞项 |
| [13-订阅与服务权益](./modules/13-订阅.md) | 商品、收据、权益、能力门控、到期和恢复 | 当前草案；商品、价格、试用和权益矩阵仍有阻塞项 |
| [14-跨模块安全](./modules/14-跨模块安全.md) | 风险信号、安全判断、受影响范围、跨模块保护、复核和解除 | 当前草案；风险目录、动作矩阵、复核和升级规则仍有阻塞项 |
| [15-长期总结](./modules/15-长期总结.md) | 跨周期证据、长期方向、不可比断点、历史和阶段候选证据 | 当前草案；周期、证据门槛、判定和传播规则仍有阻塞项 |

当前识别出的模块缺口已经有正式候选草案承接，但尚未关闭各模块待确认参数，也尚未完成产品、专业、技术与测试联合评审。是否新增或调整模块以《对象与责任台账》和后续评审结论为准。

每个模块 PRD 至少要写清：目的与范围、用户场景、入口与前置条件、输入与来源、形成或读取方式、完整流程、业务规则、可量化参数、状态与异常、数据和版本、权限与安全、跨模块影响、埋点、验收场景、明确不做的内容和待确认事项。

涉及 Agent 时，模块 PRD 还必须写明：本区域属于形成、读取、修改入口还是确定性处理；结果由哪个任务形成；什么事件触发和不触发；选择哪些上下文；允许和禁止的写入；确认、取消、失败恢复、结果读回和后续验证。不能只写“Agent 自动分析”或“输入后自动生成”。

## 6. 更新和派生规则

### 6.1 正式需求先行

需求变化按以下顺序处理：

1. 在对应正式 PRD 中记录决定、影响范围和待确认项；
2. 在待确认事项台账中更新决策包的负责人、状态、适用版本和关闭条件；
3. 完成需要的产品、设计、健康、算法、技术、Agent 和测试评审，并把结论写回正式 PRD；
4. 更新 Demo 展示数据、页面内 PRD、团队复制提示词和任务计划；
5. 对派生结果做一致性检查；
6. 保存旧版本，不覆盖历史依据。

禁止把 Demo 或团队提示词中的修改当成需求已更新，也禁止直接修改生成副本后不回写正式 PRD。

### 6.2 Demo PRD

Demo 内的 PRD 是正式文档的便捷阅读视图，不是第二套需求来源。它应从当前有效文档提取并标明来源版本。若为了演示使用模拟数字、候选指标或虚构情境，必须明确标记为 Demo 数据，不能混入正式规则。

### 6.3 团队复制提示词

团队提示词是任务委派材料，不是缩写版产品介绍。每份提示词必须从当前任务相关 PRD 提取：

- 任务目的与用户价值；
- 当前范围、明确不做和历史兼容要求；
- 已确认的业务规则和参数；
- 所需输入、来源、版本和待核对材料；
- 角色职责、可决定事项和不能替代的专业判断；
- 具体交付物、格式、上下游和验收证据；
- 尚未确认且会改变结果的问题。

提示词不得携带其他项目或无关历史文档内容，也不得用“按最佳实践处理”代替具体规则。

## 7. 当前交付风险

目前全局基线、对象台账、Agent 共用要求和 16 份模块候选草案已经形成，但尚未完成产品、专业、技术与测试联合评审。因此：

- Demo 中已有页面不等于对应模块已经可以开发；
- Demo 内嵌 PRD 与 153 份团队复制提示词已完成首轮派生整改，但在正式草案完成联合评审、待确认项关闭和后续规则变化后，仍须从正式来源重新生成并通过一致性审计；
- Age 指标、周目标、首次使用、通知、订阅、数据权限等关键内容仍有未决项；
- 已有模块草案只能支持不依赖未决产品参数的设计、预研和通信试验，不能把临时对象、字段、Prompt 或模拟规则直接定为生产实现。

完成全局整顿的标准不是“文档数量变多”，而是每项要交付的功能都能让设计、开发和测试在不重建历史对话的前提下，得到一致且可验证的产品结果。