# 产品需求文档 (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%。