20260131_启动会
正式启动Reflekt Health MVP项目，对齐项目规划、核心需求、技术方案及实施细节。
一、概览
- 会议主题： Reflekt Health MVP 项目启动与需求对齐会
- 会议时间： 2026年1月31日 15:30-18:30
- 会议地点： 腾讯会议
- 参会人员：
- Elle Wu：项目发起人
- 张总：技术顾问/硬件对接支持
- Daniel Yin：产品经理 & 架构师
- 增焕：项目经理
- 陈禹：AI工程师
- 子豪：前端/IoT工程师
- 妙锋：测试工程师
- 佩宜：UI/UX
二、议题
2.1 团队与项目规划
- 团队组成： Daniel（产品经理与架构师）负责整体设计、架构及客户沟通；增焕（项目经理）在PRD交付后负责日常推进；团队包含前端、AI、安卓、测试、UI等职能。
- 整体规划： 项目自本次会议正式启动。初步时间线：1-2月完成产品与技术设计；3-4月进入研发；5月UAT测试；目标8月上线。
- 沟通机制： 确定每周六下午4:30举行项目周会。
2.2 AI核心功能与交互设计
- 核心目标： 系统应对多源数据综合分析，向家属提供清晰、分级、安心的结论，旨在提供“可见性”和预防预警，而非罗列原始数据。
- 信息分级： 家属端界面设计三个状态：
- 绿色： 一切正常。
- 橘黄色（预警）： 需要关注（如连续起夜），系统给出结论与建议，家属可查看详细依据。
- 红色（报警）： 紧急情况（如摔倒），需立即行动。
- 摔倒处理流程： 设备检测摔倒 → 音箱主动语音询问老人状况 → 根据老人应答（无需帮助/需要帮助/无应答）判断是否触发报警及联系家属。
- 情感与主动关怀： AI需能分析老人情绪，并在关怀话术中体现；智能音箱需支持在特定时间主动发起问候和提醒。
- 知识库与记忆： MVP阶段通过系统提示词或简易知识库处理老人个人习惯等信息；深度知识库功能规划在二期。
- 生活助手： 考虑集成提醒功能（如吃药），但需谨慎设计避免烦扰。
2.3 关键技术方案讨论
- 家属端APP技术选型： 讨论了跨平台与原生开发优劣。决定： MVP为控制成本与复杂度，采用跨平台混合开发方案，并计划上架应用商店以便测试。
- 硬件对接与数据处理：
- 手环和雷达数据通过厂家协议（如MQTT）推送至项目云端。
- 数据存储策略： 确认原始数据具有价值，决定全部保留，后续可通过数据压缩优化存储成本。
- 需与硬件厂确认数据上报频率，理想情况下可动态调整。
- 离线场景： 音箱交互记录可暂存本地后补传；IoT设备数据若未推送则无法补发，系统需监控设备离线状态。
2.4 范围、权限与运维
- 场景范围： 明确MVP阶段仅支持单个老人场景。 多老人支持（包括老伴双重角色）列为二期功能。
- 权限与协作闭环：
- 家庭账号设主账号与子账号（多个子女）。
- 对于预警信息处理是否需“工单式”接单闭环暂未最终确定，担心造成负担。初步倾向由系统发送提醒，家属自行协调，系统可能仅做信息同步。
- 安装与运维：
- 目标通过指导视频让家属自行完成硬件安装。
- 需确认能否通过自有家属端APP完成设备初始化绑定，以替代厂家小程序。
- 需制定音箱的OTA升级策略，目标实现无感或极简语音交互升级。
三、结论
- 项目于2026年1月31日正式启动，并确立了每周六下午4:30的项目周会制度。
- 确定了MVP的核心产品理念与AI交互逻辑：通过多源数据分析，向家属提供分级、清晰的安心结论。
- 明确了关键技术选型与范围：家属端APP采用跨平台开发；仅支持单老人场景；所有原始数据予以保留。
- 对硬件对接、数据策略、安装运维等关键实施细节进行了初步对齐，并明确了待办事项与分工。
四、待办
- @全体参会人员
- 遵循每周六下午4:30召开项目周会的机制：即时生效
- @Daniel 团队
- 执行家属端APP采用跨平台混合开发方案并上架应用商店的计划：开发阶段
- 在产品设计中明确MVP仅支持单个老人场景：产品设计阶段
- 在技术设计中确定原始数据全保留及后续压缩策略：技术设计阶段
- 调研AWS音视频通话方案及音箱主动问候API支持情况：技术设计阶段
- @Daniel
- 输出详细的产品需求文档（PRD）及技术设计方案：2026年2月底前
- @张总 & @Daniel
- 与硬件厂家拉群，确认数据上报频率、设备安装初始化协议等细节：尽快
- @Elle
- 提供老年人交互话术、UI设计倾向（极简、大字体）的参考材料，并与养老顾问确认：持续提供