需求洞察

一、源文件分析摘要

本节列出每个源文件的详细分析内容，确保不遗漏任何重要信息。

文件 1：03_01_software.md - 软件技术选型

文件类型：.md 文件路径：docs/raw/03_01_software.md

核心内容：

家属移动 App
- 技术栈：UniApp + Vue3 + TypeScript + Pinia + Vant4
- 核心用户：子女、亲属
- 模块：用户认证、设备绑定、家庭管理、预警通知、健康数据、关怀互动、设置配置
- 场景：远程监护、健康关注、远程关怀、系统管理
Luma 智能音箱应用
- 技术栈：Android 10 + SQLite
- 核心用户：独居老人
- 模块：设备初始化、语音交互（ASR/TTS）、AI对话、屏幕显示、离线容错、提醒播报
- 场景：应急求助、接收提醒与互动、安全守护、生活辅助
运营管理后台
- 技术栈：Vue3 + TypeScript + ElementPlus
- 核心用户：运营、客服、管理员
- 模块：账户权限、用户设备管理、预警事件监控、消息推送、配置中心、数据日志
- 场景：全局监控、事件处理、用户与设备管理、系统配置
后端服务
- 技术栈：Java 17 + RuoYi-Vue-Plus5
- 模块：设备接入服务、预警规则引擎、通知服务、数据聚合服务、API网关、家庭留言服务
- 场景：数据中枢、智能分析、消息调度、业务支撑

核心洞察：

四端协同构成完整数据闭环
用户角色分明（家属/老人/运营人员）
安全与隐私为基石（GDPR合规、全链路加密）

文件 2：03_02_third_party.md - 第三方服务

文件类型：.md 文件路径：docs/raw/03_02_third_party.md

核心内容：

通信与通知服务
- Twilio：短信验证码、红色预警语音电话
- 苹果 APNs：iOS 推送
- Google FCM：Android 推送
AI与语音服务
- OpenAI API：AI对话（生活助手/情感陪聊）
- OpenAI TTS API：文本转语音（Luma播报）
- OpenAI ASR API：语音转文本（语音命令解析）
- OpenAI Realtime API：实时对话流式响应
实时音视频服务
- LiveKit：未来视频通话预留

文件 3：03_03_hardware.md - 硬件设备规格

文件类型：.md 文件路径：docs/raw/03_03_hardware.md

核心内容：

Luma 智能音箱
- 屏幕：10.1寸 IPS 800×1280
- 摄像头：500万像素
- 语音：双麦阵列，3-5米唤醒距离，唤醒率>93%
- 处理器：四核 1.8GHz + 2GB 内存
- 网络：Wi-Fi 双频 + 蓝牙
跌倒监测传感器 L4P
- 雷达技术：60GHz FMCW 毫米波
- 功能：跌倒检测、人员存在感知、姿态识别
- 监测参数：跌倒高度0.1-1m可调、布防时间、无人预警时间
- 范围：4m（置顶安装）
- 功耗：≈0.5W
睡眠监测仪 X1
- 雷达技术：60GHz FMCW 毫米波
- 功能：睡眠监测、心率/呼吸率、HRV、离床监测、翻身监测
- 睡眠分析：浅睡/深睡/REM/清醒、睡眠质量评分
- 事件预警：离床超时、心率异常、呼吸异常
4G 智能手表
- 数据类型：21种主数据类型
- 运动数据：计步、加速度计、陀螺仪
- 心血管：心率、心电ECG、PPG、HRV、血压
- 血氧与呼吸：血氧SpO2、呼吸率
- 其他：体温、环境数据、睡眠、GPS定位

文件 4：20260221产品需求文档PRD跌倒告警MVP.md - MVP详细规格

文件类型：.md 文件路径：docs/raw/20260221产品需求文档PRD跌倒告警MVP.md

核心内容：

固定参数（硬编码）
- Baseline学习期：7天
- 老人确认窗口：30秒
- 联系人升级节奏：20秒/级
- 升级顺序：联系人#1→#2→#3→全部广播
跌倒告警闭环状态机
- CONFIRMING_USER（0-30秒）：Luma语音询问
  - USER_OK：进入RESOLVED_FALSE_ALARM
  - USER_HELP：进入RED_ALERT
  - NO_RESPONSE/UNCLEAR：进入RED_ALERT
- RED_ALERT（30秒后）：逐级通知升级
多源证据收集
- 雷达：fall event
- 手表：impact + immobility
- 语音：Help/Pain/Fall 或 OK/No help
- 超时：确认超时标志
Baseline机制
- 状态：BASELINE_ACTIVE → BASELINE_COMPLETE
- 产出：wake_window、sleep_window、night_activity_baseline
安装证据包（3项）
- 设备布局照片
- 覆盖范围行走测试（≥3个位置）
- 网络自检（RSSI、延迟、丢包率）
后端字段定义
- alert_id、created_ts、severity
- confirmation_start_ts、confirmation_end_ts、voice_confirmation
- stop_escalation_ts、escalation_step
- delivery_log[]、ack_ts、ack_contact_id
- false_alarm、false_reason、evidence_flags
- baseline_status、baseline_profile
验收标准
- 30秒窗口执行准确率：100%
- 20秒升级链准确率：100%
- USER_OK中断成功率：100%
- Red事件复盘完整率：100%
- 安装证据包成功率：≥90%
- Baseline自动开启成功率：100%

文件 5：Reflekt 系统P0 & P1 级核心功能说明.md

文件类型：.md 文件路径：docs/raw/Reflekt 系统P0 & P1 级核心功能说明.md

核心内容：

P0级（Must-Have）：

紧急预警自动化闭环（Fall-to-Alert Loop）
通知分级与静默穿透（Notification Tiering）
设备心跳监控与离线报警（Heartbeat & Offline Alert）
离线状态下的SOS兜底机制（Offline SOS Backup）
多照护人权限管理（Caregiver Management）
审计日志与安全标准（Audit Log & Trust/Safety）
高龄化UI/UX标准（Senior-Friendly UI）

P1级（MVP+）：

误报闭环系统（False Alarm Loop）
试点运营看板（Pilot Ops Dashboard）
用药遵从日志（Medication Log）

开发团队执行建议：

P0是系统承重墙，不完成无法上线
数据库需为误报记录和多照护人权限预留字段
所有提示语和报警逻辑需符合美国市场

文件 6：Reflekt Health产品设计与运营深度需求文档MasterPRD.md

文件类型：.md 文件路径：docs/raw/Reflekt Health产品设计与运营深度需求文档MasterPRD.md

核心内容：

CEO战略定调：

建立"可被信任的家庭AI助理"
摒弃"监控者"思维，拥抱"陪伴与守护"逻辑
MVP简化理由在生命安全和尊严方面不成立

11大核心场景：

生命安全与应急：
- 跌倒无回应（X秒无回应→自动升级红色预警）
- 夜间静默穿透（红色预警穿透勿扰模式）
- 设备离线盲区（12h黄提醒，48h高风险标记）
- 用药遵从关怀（非压力式关怀）
算法迭代与运营：
- 误报闭环（家属标记原因，结构化数据用于算法迭代）
- 试点风险预警（Dashboard预警触发人工回访）
心理尊严与文化：
- 认知障碍锚点（Magic Morning提供时空锚点）
- 独立尊严边界（严禁诊断文案）
- 离线透明度（温和语音告知）
现实生活逻辑：
- 趋势图基线（个人基线灰带）
- 协作者移除（一键移除权限）

核心改进功能：

家属App：协作管理、静默设置、用药遵从
Luma音箱：仪式感交互、视觉硬指标、离线容灾
后台：误报闭环、试点Dashboard、审计日志

信任与安全原则：

数据隔离（familyId验证）
全链路加密（TLS + AES-256）
非医疗边界
容灾底线

文件 7：Reflekt Health MVP 研发核心指南202602011.md

文件类型：.md 文件路径：docs/raw/Reflekt Health MVP 研发核心指南202602011.md

核心内容：

MVP核心问题与愿景：

痛点：缺乏对老年人日常健康状况的持续深度洞察
愿景：成为居家养老领域的"AI大脑"
核心目标：从"事后补救"转向"事前预测与干预"

AI核心作用：

基准（Baseline）与偏离（Drift）
- Baseline：每个老年人独特的"正常"行为和健康模式
- Drift：与基准相比的细微、渐进变化
多模态数据融合
- 生理数据（可穿戴设备）
- 活动模式（环境传感器）
- 参与度/情绪（语音AI）
个性化学习与风险预测
- 针对每个用户进行个性化学习
- 可解释的风险评分
LLM交互界面
- 对老年人：自然语音伴侣
- 对家庭：冷静、清晰的摘要和建议
闭环学习
- 用户反馈：有用/无用
- 模型优化：构建纵向养老数据集

研发红线：

数据质量与隐私（HIPAA合规）
无侵入性设计
清晰、冷静、实用的信息传递
模块化设计（可扩展性）
避免过度开发

文件 8：Reflekt Features养老顾问备注建议202602011.md

文件类型：.md 文件路径：docs/raw/Reflekt Features养老顾问备注建议202602011.md

核心内容：

功能名称	适用范围	备注
日常陪伴	人工智能语音提供拟人化的信息推送、协助服务与事项提醒，依据警报开展每日健康打卡	需提醒使用者，设备并非真人陪伴。语音过于拟人化可能会引发使用者的恐慌
日常助手	语音唤醒式助手，可为使用者解答问题	限定可咨询的信息范围，如天气状况、购物清单、活动日程、亲友名录等，减少"无法解答"类回复的出现
健康预警	借助可穿戴设备采集的数据，向家人预警潜在健康风险，预警阈值由家人设定	若家人未作出回应，设备可能需承担相应责任。建议以温和的语气向老年人发送替代方案，例如"请联系你的亲友或主治医生"
健康趋势	通过可穿戴设备的数据，监测各项指标相对基线的持续异常波动，以此排查潜在健康问题	这或许是最重要的功能，可对重大健康风险进行预判。家人可将相关数据发送给医护人员，为诊疗提供参考
简易设置	扫描二维码即可完成无线网络连接	设置步骤需控制在3步以内，需配备随时可接通的技术支持，同时提供YouTube视频教程
老人档案	供家人录入老年人的个人喜好、睡眠规律、用餐及服药时间、社交偏好等信息	鼓励老年人参与档案的建立，有助于提升其使用积极性、接受度以及对任务的依从性
紧急呼叫	家人可针对警报或其他担忧，即刻与老年人取得联系，所有通话记录均会留存	呼叫对象仅限本设备，不包含老年人的手机。若呼叫无应答，家人可选择拨打急救电话
安全设置	家人需与老年人的医护人员沟通后，设定健康预警的数据阈值	该环节需要家人与医护人员协作完成，需强调双方协作沟通的重要性，且此操作需在设备安装前完成
风险仪表盘	供家人跟进已接收的警报，记录应对措施，同时标记问题的处理状态为已解决或需升级处理	建议定期汇总分析数据并生成趋势报告，例如：过去一个月共发出12次警报，其中3次为家庭警报、6次为健康警报、3次为紧急警报
关怀提醒	为老年人及家人提供日程规划工具，并推送相关提醒	鼓励老年人确认提醒事项的完成情况，存在家人过度干预的风险，可设置不同管理权限以减轻这种感受
健康数据	向家人展示特定时间段内的关键健康数据	该功能与健康趋势功能可能存在内容重叠，建议缩小两者的关注重点或区分数据统计的时间范围
聊天界面	展示与人工智能的对话内容，可将语音提问转换为文字回复，配备隐私保护界面	功能逻辑可能易造成混淆，语音对话内容能否在此界面呈现？与家人的聊天记录是否可整合至该界面？
提醒弹窗	依据预设参数弹出提醒消息，同时提供回应选项	若使用者未作出回应，弹窗提醒应升级至哪一级别并通知家人？老年人是否有权屏蔽弹窗？
语音提醒	通过人工智能语音，提醒老年人启动或完成相关任务	同上，老年人的自主设置十分关键，可平衡功能的依从性与使用体验，避免造成困扰
紧急求救	老年人可通过语音指令或按下可穿戴设备的按键，即刻向家人发出求救信号	若未收到家人回应，需为老年人提供其他应急方案
家人时间轴	将设备的所有运行记录整合至同一文档，便于核实各时间节点的回应情况	该功能的实现需要配套支持团队，需明确团队的具体构成、服务地点以及对接方式
智能通知	该系统支持向家人设备推送通知，同时具备通知重发及逐级上报给其他联系人的功能	若通知未得到回应，应向老年人反馈并给出建议，例如"暂未联系到家人，我们会持续尝试，请联系急救中心或邻居求助"
离线模式	无线网络中断时，部分核心功能仍可正常运行	若老年人在离线状态下按下求救按键，设备将在恢复联网后通知家人。此情况存在极高风险，老年人可能无法长时间等待，建议增加提醒，引导老年人联系其他应急联系人
隐私授权	需签署符合当地隐私法规的知情同意文件	必须获得老年人的授权同意，法院判定老年人无民事行为能力或已被监护的情况除外
数据安全	配备数据加密保护机制	-

文件 9：Luma产品用户体验设计规范.md

文件类型：.md 文件路径：docs/raw/Luma产品用户体验设计规范.md

核心内容：

核心用户体验原则：

老年人是主要用户，而非数据来源
独立优先，安全第二，监控第三
无内疚、无羞耻、无幼稚化
Luma是桥梁，而非障碍
透明、可控、可逆
低认知负荷

用户画像与情感需求：

自豪独立型老年人：害怕失去控制
焦虑型老年人：害怕独处
压力大的成年子女：担忧与内疚

端到端用户旅程（5个阶段）：

阶段0：决策（简单说明）
阶段1：安装（30-60分钟，三方共同设置）
阶段2：第一周（习惯建立）
阶段3：日常使用（安全后台、柔和陪伴、家庭连接）
阶段4：首次真实事件（安全事件处理）
阶段5：持续使用（孤独感反馈、家庭推送）

Luma语音用户体验：

语气规则：中性、温暖、成熟，避免儿语
安全事件语言：使用"看起来像/可能/我担心"等软性表达
陪伴语言：提及家人，避免替代人际关系

安全保障（绝不能做）：

未经本地提示向家人发送通知
内疚感提示
隐藏的行为评分
基于恐惧的营销语言
无声升级监控

文件 10：Luma 养老产品定位与沟通策略.md

文件类型：.md 文件路径：docs/raw/Luma 养老产品定位与沟通策略.md

核心内容：

核心心理学真相：

"我不想成为负担"
"我不想被当成孩子对待"
"科技是那些不愿亲自探望的人才用的"

老年人定位支柱：

"这是您的工具，不是我的监控摄像头"
"这为您带来更多自由，而非更少"
"这能消除唠叨"
"这让我们以更平静的方式亲近"

子女沟通脚本：

针对"自豪、独立的父母"
针对"焦虑型的父母"

Luma设备沟通脚本：

首次安装话术
日常互动话术
安全事件处理话术

文件 11：Reflekt Health UI+UX设计执行手册_完整版.md

文件类型：.md 文件路径：docs/raw/Reflekt Health UI+UX设计执行手册_完整版.md

版本：1.2.1（整合版） 适用范围：Reflekt MVP · 美国市场 · 中国研发&设计团队 最后更新：2025年12月

前言：写给才华横溢的你

这份文档的目标，是帮助你——中国顶尖的设计师——理解并完美执行一个针对美国市场的、极具挑战性的设计哲学。它不仅仅是一份规范，更是一份思维方式的指南。

我们之所以选择你，是因为我们相信，最优秀的设计师可以跨越文化，用同理心和专业技能创造出世界一流的产品。这份指南将为你提供所需的全部背景、原则和工具，确保你的设计不仅在像素上完美，更在情感上精准。

请忘记你之前可能接触过的所有"智能设备"的设计模式。在这里，我们将共同创造一种全新的体验：安静的、有尊严的、充满信任的科技。

版本说明：本手册整合了 v1.0 核心哲学、v1.1 补充模块（状态机、透明度、颜色矩阵、字体 Token、验收测试）以及 v1.2.1 的关键规则修订，旨在为中国团队提供一份完整，可落地、无冲突的设计执行指南。

第一部分：核心哲学 (The Core Philosophy)

1.1 产品一句话定位

Reflekt 是一套为美国独立生活的长者设计的安全与陪伴系统，旨在减少家人的焦虑，同时避免造成监视感或依赖感。

1.2 文化背景解读：为什么美国市场如此不同？

为了做出正确的设计，我们必须理解目标用户的文化心理。这三条"美国市场真相"是所有设计决策的基石。

市场真相 (U.S. Market Truth)	文化解读 (Cultural Interpretation for Chinese Designers)	设计禁区 (Design "Don't")
1. 监视敏感度极高	在美国文化中，"隐私"(Privacy) 和"独立"(Independence) 是成年人最核心的价值观。任何"被看着"的感觉都会被视为一种冒犯。这与东方文化中"关心则管"的观念有根本不同。"关心"绝不能通过"监控"来实现。	× 展示摄像头画面 × 显示"在线/离线"状态（但允许展示最后更新时间等信任提示） × 使用"鹰眼"、"天眼"等词语
2. 尊严比安全更重要	美国长者将自己视为独立的成年人，而非需要被照顾的"病人"。如果产品让他们感觉丧失了尊严（例如，像对待孩子一样对待他们），他们会宁愿不要所谓的"安全"而拒绝使用。	× 使用幼稚的卡通形象 × 在长者面前谈论他们 × 设计需要子女"批准设置"
3. 安心感并非来自更多数据	对于子女而言，过多的数据和图表只会带来"解读的负担"，引发更多焦虑。"妈妈昨晚只睡了5小时？是不是出什么事了？"——信息越多，焦虑越多。我们的目标是消除焦虑，而不是提供数据。	× 任何形式的图表 × 任何形式的仪表盘 × 任何"查看详情"的入口（首页禁止）

1.3 四大设计铁律 (The Four Design Laws)

这是我们必须无条件遵守的法则。任何违反这些法则的设计，无论多美观，都是错误的。

设计铁律 (Design Law)	执行细则 (Execution Details)	举例说明 (Examples)
Law 1: 冷静技术 (Calm Technology)	界面必须在视觉上保持绝对的安静，不主动吸引用户的注意力，除非万不得已。	禁止: · 任何闪烁的元素 (Flashing) · 非紧急情况下的声音或震动提醒 · 红色、黄色的高饱和警告色块允许: · 状态的平滑过渡 (e.g., Fade in/out) · 微妙的、非循环的动画
Law 2: 解读，而非展示 (Interpret, Don't Display)	系统必须像一个聪明的、有同理心的管家，把冰冷的机器数据"翻译"成温暖的人类语言。永远不要让用户做数据分析。	错误示范: · "睡眠效率：78%" · "活动步数：2,345" · "心率：75 bpm" 正确示范: · "一切看起来都好" · "昨晚似乎休息得不错" · "今天早上看起来挺平静的"
Law 3: 在场，而非评判 (Presence Without Judgment)	系统可以观察，但永远不能对用户的行为做出价值判断。语气必须是中立、尊重和非指导性的。	错误示范: · "你昨晚没睡好。" (You didn't sleep well.) · "你今天活动得不够。" (You weren't active enough today.) 正确示范: · "昨晚似乎有点辗转反侧。" (Last night seems a bit restless.) · "今天大部分时间都在家休息。" (Looks like a quiet day at home.)
Law 4: 克制带来信任 (Trust Through Restraint)	我们选择不展示什么，比我们选择展示什么更重要。每一次克制，都是在积累用户的信任。	思考题 (Self-Check): · 这个功能是满足了用户的好奇心，还是真正解决了他们的焦虑？ · 如果去掉这个元素，用户会失去什么关键信息吗？ · 我们是在"证明"我们技术有多牛，还是在"服务"用户的情感需求？

第二部分：视觉语言规范 (Visual Language Rules)

我们的视觉语言服务于"平静"和"信任"的核心哲学。它必须感觉像一个舒适、温暖的家，而不是一个冰冷，高效的医院或科技实验室。

2.1 色彩 (Colors)

核心原则：低饱和度、温暖，自然。避免任何能引起"警觉"或"医疗感"的颜色。

2.1.1 基础色板

色彩类别 (Category)	Hex Code 示例	用途说明 (Usage Guide)
主色：暖灰色 (Warm Gray)	#F5F5F3	App 背景、卡片底色。营造一个柔软、无压力的画布。
辅色：软米色 (Soft Beige)	#EAE6E1	次要背景、分割线。增加层次感和温暖感。
点缀色：静谧绿 (Muted Green)	#A3B3A1	表示"正常"、"一切都好"的状态。是主要的积极信号色。
点缀色：大地色 (Earth Tones)	#D4C6B3	用于次要信息、图标等，保持整体的自然感。
文字色：深灰 (Dark Gray)	#5A5A5A	用于所有主要文本，避免纯黑带来的高对比度刺激。
警报色：琥珀色 (Amber)	#F2AD5C	仅用于"注意"级别状态。它比红色更柔和，能提醒注意但不会引发恐慌。
紧急色：深红/酒红 (Deep Red/Burgundy)	#8B3A3A	仅用于"紧急"级别状态（如Need Help、Emergency Escalated），但需保持克制，避免大面积闪烁。
禁用色：医疗蓝 (Medical Blue)	#007AFF	绝对禁止。这会立刻让产品感觉像一个医疗器械。
禁用色：亮红色 (Bright Red)	#FF3B30	绝对禁止。这会引发强烈的恐慌和焦虑。

2.1.2 颜色使用矩阵 (Color Usage Matrix) —— 工程可执行规则

组件/区域	Light Mode (推荐)	Dark Mode (推荐)	对比度门槛 (最低 WCAG AA)	常见错误
背景 (App Background)	接近白/浅灰（不偏蓝）	近黑/深灰（不纯黑）	正文文本 4.5:1	医用蓝底/纯黑底导致压迫感
主文本	深石墨/近黑	近白但不刺眼	7:1（优先）	灰字太浅导致老人看不清
状态条：Normal	低饱和绿 + 文案克制	低饱和绿	文本 4.5:1	荧光绿/大面积绿块
状态条：Attention	琥珀/橙黄（低饱和）	琥珀/橙黄	文本 4.5:1	黄字叠黄底，可读性崩
状态条：Emergency	深红/酒红（非亮红）	深红/酒红	文本 4.5:1	亮红+大面积闪烁=恐惧感
按钮 (Primary CTA)	品牌主色（深稳）	同色系更亮一档	按钮文本 4.5:1	按钮像游戏UI、太饱和

可验收项：每个关键页面需提供一张"对比度检查截图"或对比度数值，确保符合 WCAG AA 标准。

2.2 字体 (Typography)

核心原则：可读性极高，人性化、无科技感。

2.2.1 字体家族

字体属性	规范	解释
西文字体	Publico Text, Source Sans Pro, 或类似的人文主义无衬线体	人文主义字体(Humanist)的笔画有轻微的粗细变化，感觉更自然、更温暖，不像几何无衬线体(如Helvetica, Futura)那样冰冷。
中文字体	苹方-常规体(PingFang SC Regular), 思源黑体-常规体 (Source Han Sans CN Regular)	与西文风格匹配，确保易读性。
字重	常规体(Regular)/中等 (Medium)	绝对禁止使用细体 (Light/Thin) 或特黑体 (Black/Heavy)。细体阅读困难，黑体则过于醒目，破坏平静感。

2.2.2 字号 Token (iOS/Android 工程落地版)

Token	用途	iOS (pt / Dynamic Type)	Android (sp)	最小可读门槛
S-H1	老人端大标题/确认问句	28-32（支持放大）	30-34	必须一屏读完，不换行优先
S-Body	老人端正文/提示	22-24	22-24	行高 ≥1.35
S-CTA	老人端主按钮	24-26	24-26	按钮高度建议 ≥56dp
C-H1	家属端状态标题	20-22	20-22	一眼识别状态
C-Body	家属端正文	16-17	16-17	行高 ≥1.4
Meta	时间/脚注	13-14	13-14	不得低于12sp

工程规则：开启系统字体缩放（Dynamic Type / Font Scale）。当用户放大字体时，页面必须保持不截断，不遮挡 CTA。

2.3 图标 (Icons)

核心原则：友好、具体，表意清晰。图标是情感信号，而非功能指标。

图标风格	示例描述	设计要点
圆润 (Rounded)	所有尖角都处理成半径至少为2px的圆角。	尖角会带来攻击性和紧张感，圆角则感觉更安全、更友好。
实心 (Solid/Filled)	优先使用实心图标，而非线性图标。	实心图标更具"存在感"和"稳定性"，线性图标则显得更"技术化"和"脆弱"。
表意具体 (Literal)	表示"睡眠"就用床或月亮，而不是脑电波图。表示"活动"就用一个行走的人，而不是一个数据折线。	用户不需要猜测图标的含义，必须做到一望即知。

第三部分：核心屏幕设计详解 (Core Screen Deep Dive)

这是将哲学转化为实践的关键部分。每个屏幕的设计都必须严格遵守以下结构和规则。

3.1 家人主屏幕 (Family Home Screen)

目标：3秒内了解全局，获得安心。 设计原则：一瞥即懂，无需探索 (One glance, no exploration)。

固定结构（MUST NOT CHANGE）：

总体状态 (Overall Status)：一句完整的话，用人性化语言描述。
一句话解释 (One-line Explanation)：对状态的补充，增加情感和细节。
最后更新时间 (Last Update Time)：提供时间戳，建立信任。时间表达应人性化。

状态	正确的文案示例	错误的设计
一切正常	"Everything looks fine." "All seems normal this morning." "今天看起来不错。"	× 显示"98分"的健康分 × 一个绿色的对勾图标（可用文案替代） × "所有指标均在正常范围"
轻微异常 (低置信事件)	"Dad seems to be moving around a bit more than usual today." "今天爸爸的活动似乎比平时多一些。"	× 一个黄色的警告图标 × "活动量超标20%" × "查看异常活动记录"按钮
可信度提示	（允许） "Updated just now" / "Updated a few minutes ago" / "Connection issue"	× 实时在线绿点 × 精确到秒的"最后在线：08:23:45"

绝对禁止的设计元素：

滚动条 (Scrolling)
多个卡片或模块 (Multiple Cards)
任何形式的图表或数据值 (Charts or Data)
"查看更多"或"详情"链接 (View More / Details)

3.2 警报屏幕 (Alert Screen)

目标：创造感知，而非制造恐慌 (Create awareness, not panic)。 设计原则：清晰告知三件事：发生了什么，系统在做什么、你能做什么。

固定结构 (MUST NOT CHANGE):

发生了什么 (What happened): e.g., "A possible fall was detected in the living room."
系统在做什么 (What the system is doing): e.g., "We are trying to reach Mary via voice check-in." —— 替代倒计时：不显示倒计时数字，使用温和进度语句。
你能做什么 (What you can do): 提供清晰、有限的下一步操作。允许一个入口："查看时间线 (Timeline)"。

允许的操作 (Allowed Actions)	禁止的操作 (Forbidden Actions)	视觉禁区 (Visual Don'ts)
· "我知道了" (Acknowledge) · "呼叫其他家人" (Notify another family member) · "直接呼叫妈妈" (Call Mom directly)	· × "取消警报" (Cancel Alert) - 任何单个操作都不能完全取消安全流程。 · × "标记为误报" (Mark as False Alarm) - 这是事后反馈，不能在警报当下操作。	· × 红色闪烁的背景或文字 · × 倒计时器 (Countdown timers) · × 急促的、重复的动画

3.3 证据时间线 (Evidence Timeline)

目标：通过透明度建立信任，而非数据。 设计原则：可读的事件日志，而非技术日志。这是唯一的透明窗口。

显示格式：绝对时间 + 人类可读的事件描述

正确示例 (Correct Examples)	错误示例 (Forbidden Examples)
· "10:12 — 客厅未检测到移动" · "10:18 — 系统尝试语音签到" · "10:20 — 已发送警报给家人"	· × "10:12 — Sensor_LivingRoom: motion=false" · × "10:18 — Voice_Checkin: status=initiated" · × "10:20 — Alert_Sent: target=family_group" × 显示任何原始数据曲线

3.4 长者设备屏幕 (Senior Device Screen)

目标：零学习、零配置、零压力。 设计原则：它是一个安静的陪伴者，不是一个需要操作的工具。

设计要点 (Key Rules)	错误示范 (Forbidden Elements)
· 常态 (Normal)：超大号字体，极简信息——最好只有一句问候或时间显示。 · 告警/提醒态 (Event)：允许出现1-2个超大按钮。 · 被动显示，信息自动更新，无需交互。	· 功能列表 · "您想…吗？"的确认请求 · "设置"或任何齿轮图标 · 表现反馈 · 常态下出现任何按钮或菜单

3.5 误报反馈屏幕 (False Alert Feedback)

目标：尊重用户，而非审问用户。 设计原则：一步完成，无需解释。

固定结构 (MUST NOT CHANGE): "Was this alert helpful?" (这次提醒有帮助吗？) [Yes] [Not really]

追加设计 (Recommended Addition): 当用户点击[Not really]之后，可以追加一句感谢和安抚的话。

绝对禁止的设计：

弹出评分或评论窗口
包含超过两个选项的问卷
询问"为什么没有帮助？"的开放式问题

3.6 MVP 状态机 (State Machine) —— UI 必须服从系统真相

目的：避免 UI 与算法/硬件状态相互打架。

状态	触发/进入条件	用户看到什么 + 可做什么 (UI/Actions)	超时/升级	必须记录 (Audit)
Unpaired / Offline	未绑定；设备离线；网络断开；传感器自检失败	首页显示"未连接/需要设置"；提供1个主按钮	离线 > X 分钟推送家属提醒	离线开始时间；失败原因码
Normal	传感质量合格；无异常事件；基线有效	状态卡：绿色 + 一句话安心文案	无	最近一次数据上报时间；基线版本
Attention	轻度异常	状态卡：黄色/橙色；给1条行动建议	持续 > X 小时 → 升级	异常类型；开始时间；置信度区间
Suspected Fall	跌倒疑似；触发老人确认流程	温和语音确认 + 1个按钮	T=30-60s 无回应 → 升级	确认方式；回应内容；时间戳
Need Help	老人确认需要帮助；或超时	红色但克制；明确1条"下一步动作"	T=2-5min 未处理 → Emergency	处理人；处理时间；结果标签
Emergency Escalated	家属未处理	升级通知；提供"我正在处理"确认按钮	升级链路按优先级执行	升级次数；通知对象
Resolved	家属已处理并关闭事件	时间线标记"已解决"	无	关闭人；关闭时间；结果标签

第四部分：补充模块与工程落地规则

4.1 透明度与"细节"规则

区域	允许 / 禁止
首页 (Home)	禁止任何详情入口；只给结论 + 下一步建议 + 最新事件1条。
警报页 (Alert)	允许一个入口："查看时间线 (Timeline)"。禁止：图表、指标面板、健康分数。
时间线 (Timeline)	只展示事件与上下文。不展示：心率曲线、睡眠分期、血压原始数值。

4.2 UX 验收测试 (Acceptance Tests)

测试项	场景	通过标准 (Pass)	失败判定 (Fail)
安装时长	首次安装	≤8分钟完成；目标6分钟	>10分钟或需要人工解释
安装失败态	Wi-Fi/配对/传感质量不足	每个失败都有：原因 + 一键修复	只给提示文字/用户不知所措
首页理解	家属端首页	3秒说出状态；10秒说出下一步	需要滚动/需要解释/找不到行动
警报动作	疑似跌倒 → 需要帮助	10秒内完成任一动作	超过2屏跳转才找到按钮
事件闭环	处理完成并关闭事件	≤2步关闭	事件无法关闭或无审计信息

第五部分：设计红线与自查清单 (Red Lines & Self-Check)

5.1 绝对禁止的功能概念

AI洞察可视化：任何试图展示"我们用AI发现了什么"的图表。
健康分数：任何形式的评分、评级系统。
风险评级：例如"高危"、"中等风险"等标签。
趋势分析：例如"睡眠质量呈下降趋势"的图表或结论。
游戏化：徽章、排行榜，打卡等。
医疗暗示：任何可能让用户联想到医疗诊断的词语或图标。
实时监控感元素：实时在线绿点、实时轨迹。

5.2 设计师自查清单

在完成每一稿设计后，请扪心自问以下四个问题：

这个设计感觉像监视吗？ (答案必须是"否")
这个设计感觉像医疗产品吗？ (答案必须是"否")
这个设计还能更简单吗？ (答案必须是"是"，并持续简化)
我的父母会对此感到舒适吗？ (答案必须是"是")

最终原则 (The Final Rule)

如果某个设计让你觉得"令人印象深刻"或"很酷"，请删除它。如果某个设计让你觉得"安静"和"理所当然"，请保留它。

If something feels impressive, remove it. If something feels quiet, keep it.

第六部分：场景演练 (Scenario Walkthroughs)

场景一：平静的一天 (A Calm Day)

背景：子女（David）在上班休息时，想快速看一眼独居母亲（Mary）的情况。

David打开App：
- 屏幕显示：立即展示"家人主屏幕"。
- 内容：
  - 总体状态："Everything looks fine."
  - 一句话解释："Mary seems to be having a quiet morning at home."
  - 最后更新时间："Updated just now"
设计原则体现：
- 一瞥即懂：David在3秒内获得安心，关闭App，继续工作。
- 克制带来信任：没有数据、图表或"查看详情"。
- 解读，而非展示：系统将传感器数据自动"翻译"成了"a quiet morning"。

场景二：一次真实的警报 (A Real Alert)

背景：晚上，Mary在客厅起夜时不慎滑倒。系统检测到剧烈的、非正常的身体姿态变化。

系统内部决策：
- 数据分析：传感器数据符合"高信心度摔倒模型"。
- 触发警报：系统决定进入 Suspected Fall 状态。
David的手机收到通知：
- 通知形式：一个特殊的、持续的、但不过分刺耳的通知音，伴随手机震动。
- 通知文案："A possible fall was detected for Mary at home. Open Reflekt for details."
David打开App，进入"警报屏幕"：
- 视觉：屏幕背景变为柔和的深红色（#8B3A3A），而非刺眼的亮红。
- 内容结构：
  - 发生了什么："A possible fall was detected in the living room."
  - 系统在做什么："We are attempting a voice check-in with Mary now."
  - 你能做什么：两个清晰的按钮：[Call Mary Directly] 和 [Notify Other Family]。
David点击[Call Mary Directly]：
- 操作：App 直接调用手机的拨号功能，呼叫 Mary 的电话。
- 通话后：David 确认 Mary 摔倒但意识清醒，他告诉 Mary 自己马上就到。David 在 App 内将事件标记为"已处理"，系统进入 Resolved 状态。
警报解除与事后反馈：
- 进入"误报反馈屏幕"：系统在警报结束后展示反馈界面。
- 问题："Was this alert helpful?" 选项：[Yes] [Not really]
情感收尾：
- 警报解决后，主屏幕仅出现一次临时信息条："Glad this worked out. We'll continue to keep an eye quietly."

场景三：灰色地带的处理 (Handling a Grey Area)

背景：系统连续三天检测到 Mary 的夜间起夜次数从平均1-2次增加到4-5次。

系统内部决策：
- 数据分析：检测到"夜间活动模式变化"，但信心度为"中等"，不足以触发警报。系统进入 Attention 状态。
"证据时间线"中的记录：
- 在时间线的当天记录里，可能会出现一条颜色更浅、措辞更温和的条目：
  - "Over the last few nights, Mary seems to be a bit more restless than usual."

第七部分：高级情感化设计 (Advanced Emotional Design)

7.1 提升方向一：为"正常状态"赋予轻量存在感

核心思想：不打扰，但让人觉得"它在"。

问题本质：长期的"静默"会让子女觉得产品平时没有价值。
如何执行：引入低频正面信号，频率每周最多1-2次。
文案示例："Just a quiet week. All is well." / "No news is good news."
停手点：只要它开始变得"更频繁、更智能、试图总结规律"，就必须立刻停止。

7.2 提升方向二：在警报"解决后"增加情感收尾

核心思想：系统流程结束了，但人的情绪没有。需要一个"句号"。

问题本质：经历情感冲击后，焦虑感不会立刻消失。
如何执行：在警报被标记为"已解决"之后，App主屏幕仅出现一次临时的、自动消失的界面状态或信息条。
文案示例："Glad this worked out. We'll continue to keep an eye quietly."

7.3 提升方向三：让长者感觉自己是"给予者"

核心思想：将"被照顾"的身份，反转为"让家人安心"的贡献者。

问题本质：长者抗拒监护类产品，深层心理是抗拒无力感。
如何执行：在长者设备屏幕上，以非常低频的方式展示关于"家人感受"的转述。
文案示例："Your daughter mentioned she slept better knowing you're doing well."

7.4 提升方向四：在设计语言中引入"人类时间感"

核心原则：用"人话"说时间，而不是"机器语言"。

应用范围：仅用于非警报状态下的时间描述。
替换规则：
- 几分钟内 → Just now / A moment ago
- 一小时内 → A little while ago
- 当天 → Earlier this morning/afternoon
- 超过一天 → Recently

第八部分：设计评审检查清单 (Design Review Checklist)

8.1 哲学层面检查

检查项	通过标准
是否遵循"冷静技术"原则？	界面不会主动吸引注意力，除非有真实的紧急情况。
是否遵循"解读，而非展示"原则？	所有用户面向的信息都是"翻译后"的人类语言。
是否遵循"在场，而非评判"原则？	系统的语气是中立、观察性的，不包含任何价值判断。
是否遵循"克制带来信任"原则？	每个屏幕上的信息都是必要的。

8.2 视觉层面检查

检查项	通过标准
色彩是否符合规范？	仅使用规定的色板，没有医疗蓝或亮红色。对比度满足 WCAG AA。
字体是否符合规范？	使用人文主义无衬线体，字号符合 Token，字重为常规或中等。
图标是否友好且具体？	所有图标都有圆角，是实心的，意义一望即知。

8.3 结构层面检查

检查项	通过标准
家人主屏幕是否遵循固定结构？	只有三个元素：总体状态、一句话解释、最后更新时间。
警报屏幕是否遵循固定结构？	清晰显示：发生了什么，系统在做什么、你能做什么。
长者设备屏幕是否足够简单？	常态最多一句问候或时间显示，没有任何按钮或菜单。

第九部分：常见设计陷阱与纠正 (Common Design Pitfalls & Corrections)

陷阱一：过度设计"正常状态"

现象：团队为了证明系统的价值，开始在"一切正常"时添加更多信息。
为什么错误：这直接违反了"解读，而非展示"和"克制带来信任"的原则。
纠正方式：删除所有数据和评分。保持主屏幕的绝对简洁。

陷阱二：在警报屏幕上添加"取消"或"标记为误报"按钮

现象：出于"给用户更多控制权"的想法，设计中添加了这些按钮。
为什么错误：这会让用户产生"我可以单方面终止安全流程"的错觉，增加风险。
纠正方式：警报屏幕上只能有"确认"或"呼叫"的操作，不能有"取消"。

陷阱三：在长者端显示任何形式的数据或反馈

现象：团队认为"透明度"很重要，所以在长者设备上显示数据。
为什么错误：这会让长者感觉被评判、被监视。
纠正方式：长者端应该是完全的"被动显示"。

陷阱四：过度使用"人工智能"或"机器学习"的词语

现象：在文案或UI中出现这些词语。
为什么错误：这会让产品立刻感觉像一个"技术展示"。
纠正方式：完全避免这些词语。系统应该是"无形的"。

陷阱五：在时间线中显示技术日志

现象：证据时间线中出现技术语言。
为什么错误：这会让用户感觉系统是为技术人员设计的。
纠正方式：所有时间线条目都必须用自然语言表达。

第十部分：与开发团队的协作指南 (Collaboration with Development Team)

10.1 设计交付物清单 (Design Deliverables)

在将设计交付给开发团队前，确保以下内容都已准备好：

设计系统文档：完整的色板、字体、间距规范；所有组件的状态变化；动画和过渡的时长和缓动曲线规范。
屏幕流程图：展示所有核心屏幕之间的导航关系；标注每个屏幕的触发条件和退出条件。
文案库：所有可能出现的用户界面文本；包括正常状态、警报状态、加载状态、错误状态等。
交互规范：详细描述每个按钮、链接、表单的行为；说明什么情况下元素应该被禁用或隐藏。

10.2 关键沟通要点 (Key Communication Points)

这不是一个功能堆砌的项目。每个设计决策都是基于用户心理和情感的考虑。
克制是最高的设计要求。
时间和频率很重要。
文案是设计的一部分，不是事后的想法。
状态机是核心：强调每个UI状态必须与系统状态一一对应。

第十一部分：对中国设计团队的最终寄语 (Final Words to the Chinese Design Team)

亲爱的设计师们，

感谢你们选择参与这个项目。你们将要创造的，不仅仅是一个产品，而是一个跨越文化、跨越代际的情感连接。

我想提醒你们的是，最好的设计往往是看不见的。当一个美国的子女打开Reflekt App，在3秒内获得安心，然后继续他的工作，他不会想起"这个设计有多聪明"。他只会感受到"我母亲是安全的，我可以放心"。这就是成功。

在执行这份指南时，请记住：

理解背后的"为什么"，而不仅仅是"是什么"。
跨越文化的同理心。你们来自中国，但你们正在为美国的长者和他们的子女设计。
在细节中体现关怀。一个字的选择，一个颜色的选择，一个动画的时长——这些看似微小的决定，累积起来就是用户感受到的"这个产品是否真的关心我"。
勇敢地说"不"。当你看到一个功能，一个信息，一个设计元素，觉得它会破坏产品的核心哲学时，请勇敢地说"不"。

最后，我想说的是：你们正在设计的，是一个可能会改变人们生活的产品。

祝你们的设计之旅充满灵感和成就。

文档版本：1.2.1 (完整整合版) 最后更新：2025年12月 适用范围：Reflekt Health MVP · 美国市场 · 中国设计团队 维护者：Reflekt Health Design Leadership

文件 12：Reflekt_US_Doc_Improvement_Guangzhou_Team_v1.5_Polite_Patches.md

文件类型：.md 文件路径：docs/raw/Reflekt_US_Doc_Improvement_Guangzhou_Team_v1.5_Polite_Patches.md

核心内容：

Top 8建议改进问题：

P0用户故事不够"可交付"
缺少全局状态机（State Model）
缺少关键页面清单+首屏信息结构
缺少失败分流表（Error & Recovery）
告警闭环缺少动作矩阵+证据包+处理回执
老人端适老化缺少固定屏幕结构+语音脚本
合规/非医疗边界缺少措辞库
建议完善埋点

P0用户故事统一标准模板：

目标
Scope（包含/不包含）
Preconditions（前置条件）
Happy Path（编号步骤）
Screen List（屏幕清单+首屏信息）
State Model（状态机引用）
Error & Recovery（失败分流表）
Acceptance Criteria（验收标准）
Telemetry（埋点与归因）
UX Hard Rules（体验硬规则）

MVP成败关键5条：

US-05：绑定与设备初始化向导
US-09：红色告警升级与处理闭环
US-21：设备离线检测与分级提醒
US-22：离线兜底与透明沟通
US-16：老人端3入口主界面+核心语音脚本

二、跨文件信息汇总

本节汇总不同文件中描述的相同或相似信息，标注来源并对比差异。

1. 跌倒告警闭环

涉及文件：
- Reflekt 系统P0 & P1 级核心功能说明.md
- 20260221产品需求文档PRD跌倒告警MVP.md
- Reflekt Health产品设计与运营深度需求文档MasterPRD.md
文件描述：
- Reflekt 系统P0 & P1 级核心功能说明.md：跌倒检测后，Luma 需立即发起语音询问（如 "Are you okay?" ）。若在 30 秒内未收到清晰的正面回应（ "I'm okay" ），系统 必须自动升级 为红色紧急预警，触发家属电话 / 短信 /App 强提醒。
- 20260221产品需求文档PRD跌倒告警MVP.md：T=0 至 30 秒，Luma 智能音箱设备进行语音播报（例如："检测到您可能摔倒，请问需要帮助吗？"），并在此 30 秒内持续监听用户的语音指令。
- Reflekt Health产品设计与运营深度需求文档MasterPRD.md：老人摔倒后因疼痛无法说话。询问后 X秒无回应 →自动升级红色预警。
差异分析：
- 文件1和2的30秒参数一致
- 文件3使用"X秒"表述，未明确具体数值
- 文件2包含详细的状态机设计（CONFIRMING_USER → RED_ALERT）

2. 通知分级体系

涉及文件：
- Reflekt 系统P0 & P1 级核心功能说明.md
- Reflekt Health产品设计与运营深度需求文档MasterPRD.md
文件描述：
- Reflekt 系统P0 & P1 级核心功能说明.md：
  - 普通（ Green ）：日常建议与小变化
  - 关注（ Yellow ）：作息异常、活动下降、设备离线 12h
  - 紧急（ Red ）：跌倒、 SOS 、长时间无回应、设备离线 48h
  - 红色预警必须具备 静默穿透能力，即家属手机即使在 "勿扰模式" 下，也必须强制发出警报声
- Reflekt Health产品设计与运营深度需求文档MasterPRD.md：设置项需与后端"红/黄/普通"等级联动。红色预警无视 App及手机系统静音。
差异分析：
- 两个文件对通知分级的描述一致
- 文件1包含具体的时间阈值（12h/48h），文件2未提及

3. 设备离线监控

涉及文件：
- Reflekt 系统P0 & P1 级核心功能说明.md
- 20260221产品需求文档PRD跌倒告警MVP.md
- Reflekt Health产品设计与运营深度需求文档MasterPRD.md
- Reflekt Features养老顾问备注建议202602011.md
文件描述：
- Reflekt 系统P0 & P1 级核心功能说明.md：后端实时监测雷达、手表、 Luma 的在线状态。离线 > 12 小时：推送黄色提醒给家属。离线 > 48 小时：在运营后台标记为 "高风险" 。
- 20260221产品需求文档PRD跌倒告警MVP.md：设备心跳监控与离线报警机制
- Reflekt Health产品设计与运营深度需求文档MasterPRD.md：路由器坏了两天，家属和运营均未察觉。12h⻩提醒，48h后台标记为"高⻛险家庭"。
- Reflekt Features养老顾问备注建议202602011.md：离线模式 - 无线网络中断时，部分核心功能仍可正常运行。若老年人在离线状态下按下求救按键，设备将在恢复联网后通知家人。
差异分析：
- 12h/48h 阈值在多个文件中一致
- 文件4描述了离线模式的功能，文件1-3更关注离线告警机制

4. 七天行为基线（Baseline）

涉及文件：
- 20260221产品需求文档PRD跌倒告警MVP.md
- Reflekt Health产品设计与运营深度需求文档MasterPRD.md
文件描述：
- 20260221产品需求文档PRD跌倒告警MVP.md：
  - Baseline 学习期：7 天
  - 产出数据：wake_window（起床时间范围）、sleep_window（入睡时间范围）、night_activity_baseline（夜间活动基线）
  - 在 7 天学习期内，家属端 App 首页需有明确的视觉提示，如 "行为基线建立中 (第 x/7 天)"
- Reflekt Health产品设计与运营深度需求文档MasterPRD.md：趋势图基线 - 增加"个人基线灰带"，提供判断依据。
差异分析：
- 文件1有明确的7天参数，文件2更关注基线的展示方式

5. 安装证据包

涉及文件：
- 20260221产品需求文档PRD跌倒告警MVP.md
文件描述：
- 20260221产品需求文档PRD跌倒告警MVP.md：
  - 强制性：系统后台必须校验，在未收到完整证据包的情况下，不允许完成安装流程
  - 证据包内容（最少三项）：
    1. 设备布局照片 (Placement Photos)：安装人员必须为每个房间的设备上传至少一张照片
    2. 覆盖范围行走测试 (Coverage Walk Test)：在浴室、卧室、客厅等至少 3 个关键位置完成行走测试
    3. 网络自检 (Network Self-test)：RSSI (信号强度)、网络延迟、丢包率

6. 高龄化UI/UX标准

涉及文件：
- Reflekt 系统P0 & P1 级核心功能说明.md
- Luma产品用户体验设计规范.md
- Reflekt Health UI+UX设计执行手册_完整版.md
文件描述：
- Reflekt 系统P0 & P1 级核心功能说明.md：Luma 屏幕必须严格执行：字号 ≥ 18pt 、高对比度配色、每屏信息区块 ≤ 3 个
- Luma产品用户体验设计规范.md：
  - 老年人是主要用户，而非数据来源
  - 独立优先，安全第二，监控第三
  - 无内疚、无羞耻、无幼稚化
  - Luma 是桥梁，而非障碍
  - 透明、可控、可逆
  - 低认知负荷：一次只处理一个概念
- Reflekt Health UI+UX设计执行手册_完整版.md：
  - 四大设计铁律：冷静技术、解读而非展示、在场而非评判、克制带来信任
  - 字号下限 ≥18pt
  - 每屏关键信息 ≤3个
  - 颜色语义统一（红/黄/绿）
差异分析：
- 18pt字号要求在多个文件中一致
- 文件2强调用户体验原则，文件3提供更具体的设计规范

7. 安全与隐私原则

涉及文件：
- 03_01_software.md
- Reflekt Health产品设计与运营深度需求文档MasterPRD.md
- Reflekt Health MVP 研发核心指南202602011.md
文件描述：
- 03_01_software.md：安全与隐私为基石 - 贯穿了对隐私同意撤回、GDPR合规、全链路加密、权限隔离的强调
- Reflekt Health产品设计与运营深度需求文档MasterPRD.md：
  - 数据隔离：API调用严格验证 familyId，禁止跨家庭访问
  - 全链路加密：TLS(HTTPS/WSS)加密传输，AES-256敏感数据存储
  - 非医疗边界：所有文案不诊断、不评估疾病⻛险、不做治疗建议
  - 容灾底线：设备不能在任何异常情况下保持沉默，必须有本地兜底方案
- Reflekt Health MVP 研发核心指南202602011.md：
  - 隐私至上：老年人的健康数据极其敏感。必须严格遵守所有隐私保护法规（如 HIPAA）
  - 非侵入性设计：设备和系统在老年人的日常生活中应该是"隐形"的
差异分析：
- 文件2和3都强调数据隔离和隐私保护，但文件3提到了HIPAA合规，文件2提到GDPR
- 文件2明确定义了加密标准（TLS + AES-256）

8. 用户角色定义

涉及文件：
- 03_01_software.md
- Luma产品用户体验设计规范.md
- Luma 养老产品定位与沟通策略.md
文件描述：
- 03_01_software.md：
  - 家属是管理者与响应者，核心价值是"远程安心"和"便捷关怀"
  - 老人是使用者与被守护者，核心需求是"无感监测"和"简易交互"
  - 运营人员是维护者与监督者，核心工作是确保系统稳定运行并处理特殊情况
- Luma产品用户体验设计规范.md：
  - 自豪独立型老年人：害怕失去控制
  - 焦虑型老年人：害怕独处
  - 压力大的成年子女：担忧与内疚
- Luma 养老产品定位与沟通策略.md：
  - 老年人内心独白："我不想成为负担"、"我不想被当成孩子对待"
差异分析：
- 文件1从系统角度定义角色，文件2-3从用户心理角度描述

9. 技术选型

涉及文件：
- 03_01_software.md
- 03_02_third_party.md
文件描述：
- 03_01_software.md：
  - 家属移动App：UniApp + Vue3 + TypeScript + Pinia + Vant4
  - Luma智能音箱应用：Android 10 + SQLite
  - 运营管理后台：Vue3 + TypeScript + ElementPlus
  - 后端服务：Java 17 + RuoYi-Vue-Plus5
- 03_02_third_party.md：
  - Twilio：短信验证码、语音电话
  - 苹果APNs / Google FCM：推送
  - OpenAI (GPT/TTS/ASR/Realtime)：AI对话
  - LiveKit：视频通话预留
差异分析：
- 两个文件的技术选型定义互补，无冲突

10. 验收标准

涉及文件：
- 20260221产品需求文档PRD跌倒告警MVP.md
文件描述：
- 20260221产品需求文档PRD跌倒告警MVP.md：
  - 30 秒确认窗口：窗口时间的执行准确率必须达到 100%
  - 20 秒升级链：每级升级的触发时间间隔准确率必须达到 100%
  - USER_OK 中断：在升级过程中，一旦收到 USER_OK 指令，系统停止后续升级的成功率必须为 100%
  - Red 事件复盘：必须能够在后台查询到其从触发到结束的完整时间线
  - 安装证据包：安装证据包的成功提交率必须 ≥ 90%
  - Baseline 自动开启：设备安装成功后，Baseline 学习期自动开启的成功率必须为 100%

二、项目概述

2.1 项目背景

随着人口老龄化趋势加剧，居家养老已成为主流模式。独居老人在家中发生意外（尤其是跌倒）后，往往难以第一时间获得救助。本项目旨在通过智能传感器和自动化流程，为居家老人提供可靠、及时的跌倒告警解决方案，连接老人与家属，最大程度降低意外风险。

Reflekt Health 致力于成为居家养老领域的"AI大脑"，构建一个缺失的 AI 层，能够真正理解并分析老年人"随时间变化"的健康和行为模式。

1.2 核心价值主张

Reflekt 不仅仅是一套硬件组合，它是老人的**"数字守护者"**。系统的核心价值在于：在最糟糕的情况下，即使无人看护，系统也能准确拉响警报并确保信息触达。

核心原则：

所有的"MVP 简化"理由在涉及生命安全（如跌倒自动升级）和尊严（如非医疗化文案）时均不成立
建立"可被信任的家庭 AI 助理"
摒弃"监控者"思维，拥抱"陪伴与守护"逻辑

1.3 目标用户

用户角色	核心需求
老年人（被守护者）	无感监测、简易交互、保持独立尊严
家属（响应者）	远程安心、便捷关怀、实时了解老人状态
运营人员	系统稳定运行、事件处理、配置管理

二、产品体系

2.1 硬件设备

设备名称	类型	核心功能	连接方式
Luma 智能音箱	老人交互终端	语音交互、SOS、跌倒确认、提醒播报、AI对话	Wi-Fi
跌倒监测传感器 L4P	非接触式雷达	跌倒检测、活动感知、人员存在感知	Wi-Fi + AMQP
睡眠监测仪 X1	非接触式雷达	睡眠监测、心率/呼吸率、离床预警	Wi-Fi + 蓝牙
4G 智能手表	可穿戴设备	7×24小时心率、血氧、睡眠、步数等	4G 蜂窝网络

2.2 软件端

软件端	技术栈	核心用户
家属移动 App	UniApp + Vue3 + TypeScript + Pinia + Vant4	子女、亲属
Luma 智能音箱应用	Android 10 + SQLite	老人
运营管理后台	Vue3 + TypeScript + ElementPlus	运营、客服、管理员
后端服务	Java 17 + RuoYi-Vue-Plus5	系统本身

2.3 第三方服务

服务类型	服务商	用途
通信与通知	Twilio	短信验证码、语音电话
推送	苹果 APNs / Google FCM	iOS/Android 推送
AI 与语音	OpenAI (GPT + TTS + ASR + Realtime)	AI对话、语音合成、语音识别
实时音视频	LiveKit	未来视频通话预留

三、功能需求

3.1 P0 级：硬底线功能（Must-Have）

3.1.1 紧急预警自动化闭环（Fall-to-Alert Loop）

功能描述：跌倒检测后，Luma 需立即发起语音询问（如 "Are you okay?"）。若在 30 秒内未收到清晰的正面回应，系统必须自动升级为红色紧急预警，触发家属电话/短信/App 强提醒。
关键参数：
- 老人确认窗口：30 秒
- 联系人升级节奏：20 秒/级
- 升级顺序：联系人 #1 → #2 → #3 → 全部广播

3.1.2 通知分级与静默穿透（Notification Tiering）

三级通知体系：
- 普通（Green）：日常建议与小变化
- 关注（Yellow）：作息异常、活动下降、设备离线 12h
- 紧急（Red）：跌倒、SOS、长时间无回应、设备离线 48h
关键要求：红色预警必须具备静默穿透能力，即家属手机即使在"勿扰模式"下，也必须强制发出警报声

3.1.3 设备心跳监控与离线报警

功能描述：后端实时监测雷达、手表、Luma 的在线状态
- 离线 > 12 小时：推送黄色提醒给家属
- 离线 > 48 小时：在运营后台标记为"高风险"

3.1.4 离线状态下的 SOS 兜底机制

功能描述：当设备检测到断网且老人触发 SOS 或语音求助时，Luma 必须本地播报明确提示："我现在没连上网络，如果是紧急情况，请直接拨打 911。"

3.1.5 多照护人权限管理

功能描述：支持主账号添加/移除多位协作者（子女、护工等）。一旦移除，该账号必须立即失去对所有历史数据和实时状态的访问权限

3.1.6 审计日志与安全标准

功能描述：记录所有敏感操作（改配置、删人、导数据）的"人、时、地、事"，日志保存 12 个月以上

3.1.7 高龄化 UI/UX 标准

功能描述：Luma 屏幕必须严格执行：字号 ≥ 18pt、高对比度配色、每屏信息区块 ≤ 3 个

3.1.8 七天行为基线（Baseline）机制

Baseline 学习期：7 天
产出数据：
- wake_window：用户通常的起床时间范围
- sleep_window：用户通常的入睡时间范围
- night_activity_baseline：用户夜间活动的基线水平
App 显示：需有明确的"行为基线建立中"视觉提示

3.1.9 安装证据包

强制性：系统后台必须校验，在未收到完整证据包的情况下，不允许完成安装流程
证据包内容：
1. 设备布局照片
2. 覆盖范围行走测试（至少 3 个关键位置）
3. 网络自检（RSSI、网络延迟、丢包率）

3.2 P1 级：强烈建议补齐（MVP+ / Optimization）

3.2.1 误报闭环系统

功能描述：App 端支持家属标记误报原因（如：捡东西、做操、宠物干扰）
商业价值：形成数据闭环，用于持续优化算法

3.2.2 试点运营看板

功能描述：针对试点家庭的聚合视图（在线率、跌倒数、误报率等）

3.2.3 用药遵从日志

功能描述：记录用药提醒的"执行确认"状态，形成 7-14 天的趋势报告

3.2.4 健康趋势与风险预警

功能描述：通过可穿戴设备的数据，监测各项指标相对基线的持续异常波动

四、核心场景案例库

4.1 生命安全与应急

场景	描述
跌倒无回应	老人摔倒后因疼痛无法说话。询问后无回应 → 自动升级红色预警
夜间静默穿透	女儿开启静默模式，但妈妈此时摔倒。红色预警必须穿透所有静默设置
设备离线盲区	路由器坏了，家属和运营均未察觉。12h 黄提醒，48h 后台标记"高风险"
用药遵从关怀	女儿设置用药提醒，Luma 播报 + 老人确认，家属通过 Log 进行非压力式关怀

4.2 算法迭代与运营

场景	描述
误报闭环	家属在 App 标记误报原因，结构化数据用于算法迭代
试点风险预警	试点 Dashboard 预警触发运营人工回访

4.3 心理尊严与文化

场景	描述
认知障碍锚点	Magic Morning 提供时空锚点，减少焦虑
独立尊严边界	严禁诊断文案，将监控转化为"连接的借口"
离线透明度	离线时温和语音告知，防止老人拔掉电源

五、非功能需求

5.1 安全与隐私

数据隔离：API 调用严格验证 familyId，禁止跨家庭访问
全链路加密：TLS(HTTPS/WSS) 加密传输，AES-256 敏感数据存储
非医疗边界：所有文案不诊断、不评估疾病风险、不做治疗建议
隐私授权：需签署符合当地隐私法规的知情同意文件
GDPR 合规：支持数据导出、删除请求

5.2 性能要求

30 秒确认窗口：执行准确率必须达到 100%
20 秒升级链：每级升级的触发时间间隔准确率必须达到 100%
USER_OK 中断：收到指令后停止后续升级的成功率必须达到 100%

5.3 可靠性

容灾底线：设备不能在任何异常情况下保持沉默，必须有本地兜底方案
Red 事件复盘：必须能够查询到完整的告警事件时间线

六、用户体验原则

6.1 核心原则

老年人是主要用户，而非数据来源
独立优先，安全第二，监控第三
无内疚、无羞耻、无幼稚化
Luma 是桥梁，而非障碍
透明、可控、可逆
低认知负荷：一次只处理一个概念

6.2 老年人定位支柱

"这是您的工具，不是我的监控摄像头"
"这为您带来更多自由，而非更少"
"这能消除唠叨"
"这让我们以更平静的方式亲近"

6.3 语音用户体验

语气：中性、温暖、成熟，避免儿语、虚假活泼
安全事件语言：使用"看起来像 / 可能 / 我担心"等软性表达
强调"您说了算"

七、验收标准

验收项	标准
30 秒确认窗口	执行准确率 100%
20 秒升级链	触发时间间隔准确率 100%
USER_OK 中断	停止后续升级成功率 100%
Red 事件复盘	完整时间线可查询
安装证据包	成功提交率 ≥ 90%
Baseline 自动开启	成功率 100%

八、需求来源索引

源文件	主要内容
Reflekt 系统P0 & P1 级核心功能说明.md	P0/P1 功能优先级定义
20260221产品需求文档PRD跌倒告警MVP.md	MVP 详细需求、状态机设计
Reflekt Health产品设计与运营深度需求文档MasterPRD.md	核心场景案例、技术规范
Reflekt Health MVP 研发核心指南202602011.md	AI 核心作用、研发红线
Reflekt Features养老顾问备注建议202602011.md	功能清单、顾问建议
Luma产品用户体验设计规范.md	UI/UX 设计规范
Luma 养老产品定位与沟通策略.md	产品定位、沟通脚本
03_01_software.md	软件技术选型
03_02_third_party.md	第三方服务依赖
03_03_hardware.md	硬件设备规格

本需求文档由 archon-analyze 技能自动生成

一、源文件分析摘要​

文件 1：03_01_software.md - 软件技术选型​

文件 2：03_02_third_party.md - 第三方服务​

文件 3：03_03_hardware.md - 硬件设备规格​

文件 4：20260221产品需求文档PRD跌倒告警MVP.md - MVP详细规格​

文件 5：Reflekt 系统P0 & P1 级核心功能说明.md​

文件 6：Reflekt Health产品设计与运营深度需求文档MasterPRD.md​

文件 7：Reflekt Health MVP 研发核心指南202602011.md​

文件 8：Reflekt Features养老顾问备注建议202602011.md​

文件 9：Luma产品用户体验设计规范.md​

文件 10：Luma 养老产品定位与沟通策略.md​

文件 11：Reflekt Health UI+UX设计执行手册_完整版.md​

前言：写给才华横溢的你​

第一部分：核心哲学 (The Core Philosophy)​

1.1 产品一句话定位​

1.2 文化背景解读：为什么美国市场如此不同？​

1.3 四大设计铁律 (The Four Design Laws)​

第二部分：视觉语言规范 (Visual Language Rules)​

2.1 色彩 (Colors)​

2.1.1 基础色板​

2.1.2 颜色使用矩阵 (Color Usage Matrix) —— 工程可执行规则​

2.2 字体 (Typography)​

2.2.1 字体家族​

2.2.2 字号 Token (iOS/Android 工程落地版)​

2.3 图标 (Icons)​

第三部分：核心屏幕设计详解 (Core Screen Deep Dive)​

3.1 家人主屏幕 (Family Home Screen)​

3.2 警报屏幕 (Alert Screen)​

3.3 证据时间线 (Evidence Timeline)​

3.4 长者设备屏幕 (Senior Device Screen)​

3.5 误报反馈屏幕 (False Alert Feedback)​

3.6 MVP 状态机 (State Machine) —— UI 必须服从系统真相​

第四部分：补充模块与工程落地规则​

4.1 透明度与"细节"规则​

4.2 UX 验收测试 (Acceptance Tests)​

第五部分：设计红线与自查清单 (Red Lines & Self-Check)​

5.1 绝对禁止的功能概念​

5.2 设计师自查清单​

第六部分：场景演练 (Scenario Walkthroughs)​

场景一：平静的一天 (A Calm Day)​

场景二：一次真实的警报 (A Real Alert)​

场景三：灰色地带的处理 (Handling a Grey Area)​

第七部分：高级情感化设计 (Advanced Emotional Design)​

7.1 提升方向一：为"正常状态"赋予轻量存在感​

7.2 提升方向二：在警报"解决后"增加情感收尾​

7.3 提升方向三：让长者感觉自己是"给予者"​

7.4 提升方向四：在设计语言中引入"人类时间感"​

第八部分：设计评审检查清单 (Design Review Checklist)​

8.1 哲学层面检查​

8.2 视觉层面检查​

8.3 结构层面检查​

第九部分：常见设计陷阱与纠正 (Common Design Pitfalls & Corrections)​

第十部分：与开发团队的协作指南 (Collaboration with Development Team)​

10.1 设计交付物清单 (Design Deliverables)​

10.2 关键沟通要点 (Key Communication Points)​

第十一部分：对中国设计团队的最终寄语 (Final Words to the Chinese Design Team)​

文件 12：Reflekt_US_Doc_Improvement_Guangzhou_Team_v1.5_Polite_Patches.md​

二、跨文件信息汇总​

1. 跌倒告警闭环​

2. 通知分级体系​

3. 设备离线监控​

4. 七天行为基线（Baseline）​

5. 安装证据包​

6. 高龄化UI/UX标准​

7. 安全与隐私原则​

8. 用户角色定义​

9. 技术选型​

10. 验收标准​

二、项目概述​

2.1 项目背景​

1.2 核心价值主张​

1.3 目标用户​

二、产品体系​

2.1 硬件设备​

2.2 软件端​

2.3 第三方服务​

三、功能需求​

3.1 P0 级：硬底线功能（Must-Have）​

3.1.1 紧急预警自动化闭环（Fall-to-Alert Loop）​

3.1.2 通知分级与静默穿透（Notification Tiering）​

一、源文件分析摘要

文件 1：03_01_software.md - 软件技术选型

文件 2：03_02_third_party.md - 第三方服务

文件 3：03_03_hardware.md - 硬件设备规格

文件 4：20260221产品需求文档PRD跌倒告警MVP.md - MVP详细规格

文件 5：Reflekt 系统P0 & P1 级核心功能说明.md

文件 6：Reflekt Health产品设计与运营深度需求文档MasterPRD.md

文件 7：Reflekt Health MVP 研发核心指南202602011.md

文件 8：Reflekt Features养老顾问备注建议202602011.md

文件 9：Luma产品用户体验设计规范.md

文件 10：Luma 养老产品定位与沟通策略.md

文件 11：Reflekt Health UI+UX设计执行手册_完整版.md

前言：写给才华横溢的你

第一部分：核心哲学 (The Core Philosophy)

1.1 产品一句话定位

1.2 文化背景解读：为什么美国市场如此不同？

1.3 四大设计铁律 (The Four Design Laws)

第二部分：视觉语言规范 (Visual Language Rules)

2.1 色彩 (Colors)

2.1.1 基础色板

2.1.2 颜色使用矩阵 (Color Usage Matrix) —— 工程可执行规则

2.2 字体 (Typography)

2.2.1 字体家族

2.2.2 字号 Token (iOS/Android 工程落地版)

2.3 图标 (Icons)

第三部分：核心屏幕设计详解 (Core Screen Deep Dive)

3.1 家人主屏幕 (Family Home Screen)

3.2 警报屏幕 (Alert Screen)

3.3 证据时间线 (Evidence Timeline)

3.4 长者设备屏幕 (Senior Device Screen)

3.5 误报反馈屏幕 (False Alert Feedback)

3.6 MVP 状态机 (State Machine) —— UI 必须服从系统真相

第四部分：补充模块与工程落地规则

4.1 透明度与"细节"规则

4.2 UX 验收测试 (Acceptance Tests)

第五部分：设计红线与自查清单 (Red Lines & Self-Check)

5.1 绝对禁止的功能概念

5.2 设计师自查清单

第六部分：场景演练 (Scenario Walkthroughs)

场景一：平静的一天 (A Calm Day)

场景二：一次真实的警报 (A Real Alert)

场景三：灰色地带的处理 (Handling a Grey Area)

第七部分：高级情感化设计 (Advanced Emotional Design)

7.1 提升方向一：为"正常状态"赋予轻量存在感

7.2 提升方向二：在警报"解决后"增加情感收尾

7.3 提升方向三：让长者感觉自己是"给予者"

7.4 提升方向四：在设计语言中引入"人类时间感"

第八部分：设计评审检查清单 (Design Review Checklist)

8.1 哲学层面检查

8.2 视觉层面检查

8.3 结构层面检查

第九部分：常见设计陷阱与纠正 (Common Design Pitfalls & Corrections)

第十部分：与开发团队的协作指南 (Collaboration with Development Team)

10.1 设计交付物清单 (Design Deliverables)

10.2 关键沟通要点 (Key Communication Points)

第十一部分：对中国设计团队的最终寄语 (Final Words to the Chinese Design Team)

文件 12：Reflekt_US_Doc_Improvement_Guangzhou_Team_v1.5_Polite_Patches.md

二、跨文件信息汇总

1. 跌倒告警闭环

2. 通知分级体系

3. 设备离线监控

4. 七天行为基线（Baseline）

5. 安装证据包

6. 高龄化UI/UX标准

7. 安全与隐私原则

8. 用户角色定义

9. 技术选型

10. 验收标准

二、项目概述

2.1 项目背景

1.2 核心价值主张

1.3 目标用户

二、产品体系

2.1 硬件设备

2.2 软件端

2.3 第三方服务

三、功能需求

3.1 P0 级：硬底线功能（Must-Have）

3.1.1 紧急预警自动化闭环（Fall-to-Alert Loop）

3.1.2 通知分级与静默穿透（Notification Tiering）