产品需求文档 (PRD): 跌倒告警 MVP ✅

版本	日期	作者	状态
1.0	2026-02-21	Manus AI	草稿

---

1. 背景与目标

1.1. 项目背景

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

1.2. 核心目标

本次 MVP (Minimum Viable Product) 的核心目标并非追求功能的堆砌，而是要交付一个 可复盘、可审计、可规模化 的跌倒告警服务闭环。具体来说，我们致力于实现以下两点：

1. 建立跌倒告警闭环：实现从事件监测、用户确认、到逐级通知家属的自动化流程，确保每一次真实的告警都能被有效处理。
2. 建立行为基线：为未来更高级的"行为漂移预警"功能，建立一个为期 7 天的用户个人行为数据基线 (Baseline)。

1.3. 范围定义

本次 MVP 明确采用 方案 A，即告警通知链仅触达用户预设的家庭联系人，不接入任何第三方应急响应中心。

---

2. 功能需求详述

2.1. 固定参数

为保证 MVP 阶段服务的一致性和可靠性，以下核心参数将被 硬编码【写死】在系统中，不允许在客户端或常规后台进行修改。

参数	值	说明
Baseline 学习期	7 天	系统用于学习用户日常行为模式的周期。
老人确认窗口	30 秒	跌倒事件发生后，留给老人进行语音确认的有效时间。
联系人升级节奏	20 秒/级	在未收到家属确认 (ACK) 的情况下，通知下一级联系人的时间间隔。
联系人通知顺序	联系人 #1 → #2 → #3 → 全部广播	预设的通知升级路径。
告警分级	Red / Amber / Yellow	用于对不同严重程度的事件进行分类。MVP 聚焦于 Red 告警。
告警确认 (ACK) 定义	家属在 App 端点击"我已知晓"或"我来处理"	明确定义了家属确认告警的动作。

2.2. 跌倒告警闭环 (P0 级)

这是 MVP 的核心功能，定义了从告警触发到解决的完整状态流转。

2.2.1. 状态机设计

初始状态：

• 触发条件: 毫米波雷达 (Radar) 传感器捕捉到 RadarFallEvent。
• 系统动作: 立即创建一个唯一的 alert_id，并进入 CONFIRMING_USER 状态。

第一阶段：用户确认 (CONFIRMING_USER)

• 持续时间: T=0 至 30 秒。
• 系统行为: Luma 智能音箱设备进行语音播报（例如："检测到您可能摔倒，请问需要帮助吗？"），并在此 30 秒内持续监听用户的语音指令。
• 状态转移:
  1. 用户确认安全 (USER_OK): 若监听到用户说出"我没事"、"取消"或"不用"等否定意图的关键词。
     • 系统动作: 立即停止所有告警流程，自动在后台将该告警记录标注为 false_alarm=true 及 false_reason=USER_OK。
     • 最终状态: RESOLVED_FALSE_ALARM。
  2. 用户确认求助 (USER_HELP): 若监听到用户说出"救命"、"摔倒了"、"疼"或"需要帮助"等肯定意图的关键词。
     • 系统动作: 立即进入 RED_ALERT 状态，准备通知家属。
     • 下一状态: RED_ALERT。
  3. 无响应或响应不清晰 (NO_RESPONSE / UNCLEAR): 在 30 秒确认窗口结束时，未监听到任何清晰指令。
     • 系统动作: 默认视为紧急情况，立即进入 RED_ALERT 状态。
     • 下一状态: RED_ALERT。

第二阶段：红色告警升级链 (RED_ALERT)

• 触发时间: 从 T=30 秒开始。
• 升级逻辑:
  • T=30s: 向 联系人 #1 发送 App 推送通知，并可选用短信 (SMS) 作为备用通知渠道。
  • T=50s: 若系统在 20 秒内未收到 联系人 #1 的确认 (ACK)，则自动升级，向 联系人 #2 发送通知。
  • T=70s: 若仍未收到确认，则继续升级，向 联系人 #3 发送通知。
  • T=90s: 若所有单点联系人均未确认，系统将 启动最终广播机制【运营平台是否要做记录或人工客服介入？】，向 所有紧急联系人 发送通知，并在家属端 App 内将此告警信息置顶，加强警示。
• 关键中断机制: 在升级链的任何环节，如果系统接收到来自老人的 USER_OK 语音指令，必须 立即停止 所有后续的通知和升级动作，并记录 stop_escalation_ts 时间戳。

2.2.2. 多源证据收集

为了便于后续的事件复盘、算法优化和向用户提供可信的告警解释，每次跌倒事件都必须记录一份证据集。

• 证据来源 (P0 阶段基于规则):
  • 雷达 (Radar): fall event (这是触发告警的必要证据)。
  • 手表 (Watch): impact (撞击) 和 immobility (长时间静止)。若能从穿戴设备获取，则作为辅助证据标志。
  • Luma (语音): 记录用户的语音意图，是 Help/Pain/Fall 还是 OK/No help。
  • 超时 (Timeout): 记录是否因为 30 秒无响应而触发升级。
• 数据输出:
  • evidence_flags: 一个布尔类型的集合，用以记录本次事件命中了哪些证据项。
  • fall_score (可选): 一个 0-100 的数值，可基于规则进行简单打分，用于映射告警等级 (Red/Amber/Yellow)。在 MVP 阶段，此字段可只做存储，不一定在前端展示。

2.3. 七天行为基线 (Baseline) 机制 (P0 级)

此机制为未来的高级健康监测功能（如行为漂移预警）提供基础数据支撑。

2.3.1. Baseline 状态机

• 触发: 在用户完成设备安装流程后 1 分钟内，系统自动进入 BASELINE_ACTIVE 状态。
• 持续: 此状态持续 7 天 (Day 0--7)。
• 完成: 7 天学习期结束后，系统状态自动切换为 BASELINE_COMPLETE。

2.3.2. Baseline 期间的告警策略

• 强告警: 仅允许 "Red" 级别的跌倒类强告警触发完整的家属通知流程。
• 弱信号: 其他行为漂移相关的事件（如夜间活动异常等）仅在后台生成 INSIGHT 数据，不向家属 App 发送强干扰的推送通知。

2.3.3. Baseline 产出与 App 显示

• 数据产出: 在第 8 天，系统需要为用户生成一份 baseline_profile 数据报告，其中至少包含以下三项核心指标：
  1. wake_window: 用户通常的起床时间范围。
  2. sleep_window: 用户通常的入睡时间范围。
  3. night_activity_baseline: 用户夜间活动的基线水平（如平均起夜次数、时长）。
• App 显示:
  • 在 7 天学习期内，家属端 App 首页需有明确的视觉提示，如 "行为基线建立中 (第 x/7 天)"。
  • 在第 8 天，系统需向家属端 App 发送一条通知，告知 "老人的行为基线已建立完成"。

2.4. 安装证据包 (P0 级)

为确保物理安装质量和后续服务的可靠性，安装流程必须收集一个完整的"证据包"。

• 强制性: 系统后台必须校验，在未收到完整证据包的情况下，不允许完成安装流程，也不允许启动 Baseline 学习期。
• 证据包内容 (最少三项):
  1. 设备布局照片 (Placement Photos): 安装人员必须为每个房间的设备上传至少一张照片，清晰展示其安装位置、高度【填写量化参数】及周围环境（如是否有遮挡物）【填写备注】。
  2. 覆盖范围行走测试 (Coverage Walk Test): 安装人员必须在 App 的引导下，在浴室、卧室（模拟夜间起床动线）、客厅等至少 3 个关键位置完成行走测试，以验证传感器信号覆盖无死角。
  3. 网络自检 (Network Self-test): App 或设备需执行一次网络自检，并记录当时的 RSSI (信号强度)、网络延迟、丢包率等关键指标，同时确认设备心跳上报正常。【雷达须达到普通手机的RSSI】

2.5. 家属端 UI (P0 级最小界面)

2.5.1. 红色告警 (Red Alert) 页面

当家属收到 Red 告警通知并打开 App 后，告警详情页必须提供清晰、直接的操作选项。

• 核心操作按钮:
  1. 我已知晓 / 我来处理 (ACK): 用户点击此按钮，系统将记录 ack_ts 和 ack_contact_id，并停止向其他联系人升级。
  2. 拨打老人电话: 点击后直接调用手机的拨号功能，呼叫老人的电话。
  3. 拨打紧急服务: 点击后调用本地拨号盘，并可预置或提示本地的紧急服务号码（如 120 或社区服务中心电话）。

2.5.2. 其他必要界面

• 紧急联系人管理: 在 App 的设置模块中，用户可以管理紧急联系人列表，包括添加、删除和调整通知顺序（至少需要设置 2 个，建议 3 个）。
• Baseline 状态显示: 在 App 首页或设备管理页面，需要有明确的卡片或状态栏，显示当前 Baseline 的建立进度。

---

3. 后端与数据要求

3.1. 核心字段定义 (审计与复盘)

为了确保每一个告警事件都可被追溯、分析和审计，alert 数据表必须包含以下字段：

字段名	数据类型	说明
alert_id	String	告警的唯一标识符。
created_ts	Timestamp	告警创建的时间戳。
severity	Enum	告警等级 (Red, Amber, Yellow)。
confirmation_start_ts	Timestamp	语音确认开始的时间戳。
confirmation_end_ts	Timestamp	语音确认结束的时间戳。
voice_confirmation	Enum	语音确认的结果 (ok, help, no_response, unclear)。
stop_escalation_ts	Timestamp	(若适用) 用户确认安全后，停止升级流程的时间戳。
escalation_step	Integer	记录当前通知升级到了第几级联系人。【升级逻辑序列号】
delivery_log[]	Array[JSON]	通知下发日志，数组中每个对象包含 contact_id, channel, sent_ts, delivered_ts, status。
ack_ts	Timestamp	家属确认告警的时间戳。
ack_contact_id	String	确认告警的家属联系人 ID。
false_alarm	Boolean	是否为误报。
false_reason	Enum	误报原因 (USER_OK, SYSTEM_ERROR 等)。
evidence_flags	JSON/Set	命中了哪些多源证据项的集合。
baseline_status	Enum	Baseline 状态 (ACTIVE, COMPLETE)。
baseline_start_ts	Timestamp	Baseline 开始时间。
baseline_end_ts	Timestamp	Baseline 结束时间。
baseline_profile	JSON	生成的用户行为基线数据。

---

4. 验收标准

以下为 MVP 版本必须通过的量化验收标准：

• 30 秒确认窗口: 窗口时间的执行准确率必须达到 100%。
• 20 秒升级链: 每级升级的触发时间间隔准确率必须达到 100%。
• USER_OK 中断: 在升级过程中，一旦收到 USER_OK 指令，系统停止后续升级的成功率必须为 100%。
• Red 事件复盘: 对于任何一个 "Red" 级别的告警事件，必须能够在后台查询到其从触发到结束的完整时间线，所有关键日志齐全，无信息断点。
• 安装证据包: 安装证据包的成功提交率必须 ≥ 90%。
• Baseline 自动开启: 设备安装成功后，Baseline 学习期自动开启的成功率必须为 100%。