# Reflekt 用户故事（US）文档改进建议（广州团队参考版）

版本：Review v1.2 | 适用范围：/requirements/02_03_user_stories/（US-01~US-24）

---

## 一、现状结论（请先统一认知）

当前用户故事整体方向正确（安全 / 独立 / 信任），但大量 US 只有"目标 + 要点"，缺少可落地的交付信息。

如果不改，结果通常是：

- UI 设计自由发挥，信息堆叠，页面像不够高级的健康 App 或后台系统。
- 开发在接口、状态、异常上靠猜，返工多，节奏失控。
- 测试缺少量化验收，只能凭感觉讨论，无法压住质量。
- 上线后配网失败、离线解释不清、告警处理不闭环，售后压力增大，用户信任崩。

结论：P0 用户故事建议升级成"更可执行规格"，否则后续 UI 评审没有统一尺子。

---

## 二、Top 8 建议改进的问题（问题在哪里 & 为什么会毁产品）

### 1) P0 用户故事不够"可交付"

- 现象：只有描述，没有明确交付物（哪些页面、几步完成、失败怎么办）。
- 风险：UI/开发各自理解，最终产物不一致，验收无抓手。
- 改法：所有 P0 US 建议按统一模板补齐（见第三部分）。

### 2) 缺少"全局状态机"（State Model）

- 现象：离线、学习中、告警处理中被提到，但没有统一状态集合与流转。
- 风险：用户无法确认系统是否在工作；养老安全产品一旦不确定=不可信。
- 改法：新增《System State Model》，并要求每条 P0 US 引用。

### 3) 缺少"关键页面清单 + 首屏信息结构"

- 现象：US 没写 Screen List、首屏建议出现什么、主按钮是什么。
- 风险：UI 容易堆字段，信息层级混乱，告警不突出，不够高级感。
- 改法：每条 P0 US 推荐写 Screen List（≤10屏）、Above-the-fold、Primary action、Exit criteria。

### 4) 缺少"失败分流表"（Error & Recovery）

- 现象：只有"失败可恢复"的口号，没有原因→动作→兜底。
- 风险：只会出现"失败，请重试"；用户卡住；客服背锅。
- 改法：硬件/网络/告警相关 US 建议带失败分流表。

### 5) 告警闭环缺少"动作矩阵 + 证据包 + 处理回执"

- 现象：写了强推送/电话，但没规定告警卡建议有哪些一键动作、证据怎么呈现、处理回执怎么记录。
- 风险：能推送不能处理，用户不安心。
- 改法：US-09 等告警类增加 Action Matrix + Evidence Pack + State Receipt。

### 6) 老人端适老化缺少"固定屏幕结构 + 语音脚本"

- 现象：只有字号/对比原则，没有固定主界面结构与关键话术模板。
- 风险：老人端变成"手机 App 缩小版"，老人用不了。
- 改法：US-16 明确 3 入口主界面 + 核心语音脚本（安全确认/无回应升级/离线提示）。

### 7) 合规 / 非医疗边界缺少"措辞库"

- 现象：有原则但没统一禁用词/替代词/免责声明模板。
- 风险：文案风格不一致 + 容易踩到"诊断/医疗建议"的红线。
- 改法：新增《Reflekt Language System》（禁用词、替代词、免责声明模板）。

### 8) 建议完善埋点，以便定位失败点并持续优化

- 现象：部分 US 有成功率指标，但没写怎么统计/归因。
- 风险：上线后无法定位失败步骤，无法优化。
- 改法：每条 P0 US 建议写 Telemetry：step_view/success/fail + reason_code + 耗时 + 放弃率。

---

## 三、P0 用户故事统一标准模板（推荐执行）

建议：P0 用户故事尽量按此模板补齐，以便 UI，开发、测试更顺畅对齐与验收。

### US-XX 标准模板（可复制）

1. **目标**：一句话写清用户要得到的结果。
2. **Scope（包含/不包含）**：明确包含与砍掉的范围，防止膨胀。
3. **Preconditions（前置条件）**：账号/设备状态/权限条件。
4. **Happy Path（编号步骤）**：每一步写"用户看到什么→做什么→系统做什么→成功反馈"。
5. **Screen List（屏幕清单 + 首屏信息）**：每屏只做一件事；首屏建议出现什么；主按钮；完成/退出条件。
6. **State Model（状态机引用）**：引用全局状态机，说明状态流转。
7. **Error & Recovery（失败分流表）**：原因→用户提示（非技术）→立即动作→兜底/升级。
8. **Acceptance Criteria（验收标准）**：可测、可量化（成功率/耗时/点击数/闭环回执等）。
9. **Telemetry（埋点与归因）**：step_view/success/fail（reason_code）+ 每步耗时 + 放弃率 + 客服介入率。
10. **UX Hard Rules（体验硬规则）**：两步完成、风险优先、适老化阈值等"不可违反项"。

---

## 四、先补哪几条（MVP 成败关键 5 条）

不要平均用力。先把这 5 条补成"可交付版"，否则 UI 评审没有意义：

- **US-05**：绑定与设备初始化向导（漏斗 + 失败分流 + SOS 闭环 + ≤10屏）。
- **US-09**：红色告警升级与处理闭环（动作矩阵 + 证据包 + 回执 + ≤2步完成）。
- **US-21**：设备离线检测与分级提醒（短/中/长离线规则 + 排障路径 + 不骚扰）。
- **US-22**：离线兜底与透明沟通（避免假装安全 + 911/紧急联系人兜底 + 恢复后补报）。
- **US-16**：老人端交互与适老化（固定 3 入口 + 语音脚本 + 硬阈值验收）。

---

## 五、广州团队交付要求（建议作为交付参考）

建议从即日起，对每条 P0 用户故事尽量补齐以下内容：

11. 可点击高保真原型（不是静态截图）。
12. Screen List + 首屏信息结构（写回 US 文档）。
13. 状态机引用 + 状态流转（写回 US 文档）。
14. 失败分流表（写回 US 文档）。
15. 验收标准（可量化）。
16. 埋点清单（漏斗 + reason_code）。

---

## 六、Jira 可下发的任务表（建议拆分）

| 任务 | 影响文档/模块 | 改动点 | 验收标准 |
|------|----------------|--------|----------|
| 建立全局状态机文档 | User Stories 总览 | 输出 System State Model（设备/告警）并要求所有 P0 引用 | 任意页面能明确显示状态；状态命名全局一致 |
| 新增文案系统（合规） | User Stories + 文案规范 | 禁用词/替代词/免责声明模板 | 任意告警文案符合"发生了什么 + 建议动作"，无诊断性措辞 |
| P0 US 模板落地 | 全部 P0 用户故事 | 按模板补齐10项内容 | P0 US 均具备屏幕/状态/失败分流/验收/埋点 |
| US-05 可交付化 | US-05 | ≤10屏、失败分流、SOS 闭环、漏斗埋点 | 达成成功率目标；失败不出现"请重试" |
| US-09 可交付化 | US-09 | 动作矩阵、证据包、处理回执、≤2步完成 | 红色告警从推送到动作≤2步，回执完整 |
| US-21/22 可交付化 | US-21 / US-22 | 离线分级、透明沟通、排障步骤、补报机制 | 离线时不显示"安全结论"；恢复后补发摘要 |
| US-16 可交付化 | US-16 | 老人端固定3入口、语音脚本、适老化硬阈值 | 字号/按钮/对比达标；老人端无多级菜单 |

---

## 七、执行原则（避免扯皮）

- P0 建议写得更具体：写不清 = 做不对 = 必返工。
- 先救命链路，后锦上添花：绑定/告警/离线/老人端是生死线。
- 尽量避免为了"酷"牺牲可用性：适老化阈值与风险优先为最高优先级。
- 无埋点 = 无优化：上线后建议能回答"哪里失败最多、为什么、怎么改"。

---

### 附录补充（复审新增建议）

版本增量：v1.2（新增 DoD / UI Kit / Evidence Pack / Notification Policy / Real-world Constraints / Internationalization）

---

## 附录A：P0 Definition of Done（全局验收参考）

建议：P0 页面/流程可参考以下 DoD 清单进行自查，减少联调/提测/上线阶段返工。

- **状态覆盖**：正常态 + 加载态 + 空态 + 异常态 + 无网络态 + 权限拒绝态（必要时含弱网态）。
- **关键路径**：高频动作（确认安全/拨打/升级/确认已处理）≤2步；主动作在拇指热区；可单手完成。
- **可达性**：老人端正文≥20sp、按钮高≥56dp、触控区域≥44dp；强对比，正文避免浅灰。
- **错误分流**：避免"失败请重试"；每个失败建议给原因（非技术）+ 立即动作 + 兜底入口。
- **告警闭环**：告警建议有处理回执（处理人/时间/结果/误报原因如适用）。
- **埋点可用**：step_view/success/fail（含 reason_code）+ 每步耗时 + 放弃率；后台能看漏斗与失败榜。
- **文案合规**：遵循禁用词/替代词/免责声明模板；避免诊断性语句。
- **一致性**：组件样式遵循 Reflekt UI Kit；图标风格统一；间距遵循 8pt 栅格。

---

## 附录B：Reflekt UI Kit MVP（一致性参考 + 一致性锁）

目的：避免默认组件皮肤拼装；统一层级、间距、色彩与组件样式，确保高级可信质感。

### B1. 字体与层级（建议值，可按最终设计系统微调）

- H1（页面主标题）：20~22sp；H2（区块标题）：16~18sp；正文：14~16sp（老人端 ≥20sp）。
- 关键数值/风险等级：≥18sp，并与风险色绑定（红/橙/黄/绿）。
- 行高：正文 1.4~1.6；避免密密麻麻的"表格式排版"。

### B2. 色彩规则

- 颜色只用于语义：风险等级/成功/警告/错误；其他一律灰阶。
- 避免用浅灰当正文；避免多彩卡片；避免渐变装饰抢信息层级。

### B3. 组件规范（最小集合）

- **按钮**：主按钮/次按钮/危险按钮/禁用/加载态；危险动作建议长按2秒 + 可撤销。
- **卡片**：仅一种阴影/描边规则；圆角统一（例如 12 或 16）；避免多套圆角混用。
- **列表**：首行结论 + 次行证据摘要；默认≤5条，支持折叠/展开。
- **底部动作条（Bottom Action Bar）**：告警/关键任务页建议固定主动作，单手可达。
- **对话框/Toast**：建议可解释、可行动；不出现"未知错误"。

### B4. 间距与栅格

- 统一 8pt 栅格：padding/margin 只用 8 的倍数（8/16/24/32）。
- 触控间距：按钮之间至少 8~12dp，避免误触。

### B5. 图标与插画

- 只允许一套图标风格（线性或面性择一）；线宽/圆角一致。
- 插画仅用于引导/空态，不得抢占告警与关键决策信息。

---

## 附录C：事件证据包（Evidence Pack）标准（信任增强项）

说明：任何告警/事件详情页建议基于统一 Evidence Pack 展示，确保可解释、可复盘、可优化。

| 字段 | 说明 | UI展示建议 |
|------|------|------------|
| event_id | 事件唯一ID | 隐藏在详情"更多信息"中；用于客服/日志对齐 |
| type / severity | 事件类型与风险等级 | 详情页首屏显著展示；与语义色绑定 |
| time_range | 发生时间段（绝对时间） | 显示本地时区；避免仅"刚刚" |
| confidence | 可靠度（高/中/低）或置信度 | 用文字等级，不推荐暴露算法分数 |
| trigger_summary | 触发证据摘要 | 一行总结：例如"快速下落+静止40秒" |
| device_state | 设备在线/弱网/离线/学习中 | 首屏可见（决定可信度） |
| voice_check | 是否语音询问&是否回应 | 用于升级逻辑解释（无回应=升级） |
| user_actions | 查看/拨打/升级/误报原因等 | 形成处理回执；可追溯 |

---

## 附录D：Notification Policy（打扰策略建议）

目的：避免过度打扰导致关闭通知/卸载；同时确保红色告警触达可靠。

- **按等级定义渠道**：红=强推送/电话（穿透静默）；橙=强推送；黄=普通推送；绿=仅App内提示。
- **频率控制**：同类事件在X分钟内合并；避免连环弹窗。
- **升级链**：第一联系人无回应 X 分钟 → 第二联系人 →（如适用）运营介入。
- **重试策略**：电话/推送失败的重试次数与间隔明确；给用户可见状态（正在重试/已失败）。
- **安静时段**：低等级遵循安静时段；红色告警永远例外。

---

## 附录E：真实世界约束检查清单（工程可行性检查）

目的：把"现实里一定会发生的失败"提前写进 US 和测试用例，避免上线才崩。

- **Wi-Fi**：2.4G/5G同名SSID、隐藏SSID、路由器隔离、密码变更、弱信号、DNS异常。
- **移动端权限**：蓝牙/定位/通知/麦克风权限被拒绝或仅一次授权；后台限制导致断连。
- **云端不可达**：网络通但服务不可达；建议有透明提示与自动重试策略。
- **语音环境**：噪音、老人听力差、无回应；建议有无回应升级话术与流程。
- **设备摆放**：位置导致误报/漏报；UI建议提供"摆放建议/信号弱提示"。

---

## 附录F：国际化与紧急号码策略（国际化注意事项）

- **时间**：显示老人所在地本地时区；事件建议给绝对时间（YYYY-MM-DD HH:MM）。
- **紧急号码**：根据国家/地区显示 911（US）/999（UK）等，不明确单一号码。
- **措辞**：避免"国产App味"的长句与营销词；用行动导向短句。

---

## 附录G：v1.1 新增 Jira 任务（高优先级）

| 任务 | 页面/模块 | 改动点 | 验收标准 |
|------|------------|--------|----------|
| 建立 P0 Definition of Done | 全局 | 新增 DoD 表（状态/异常/离线/权限/埋点/可达性/文案合规） | P0 页面按 DoD 打勾验收，不满足即退回 |
| 输出 Reflekt UI Kit MVP | 全局 UI | 字体层级/灰阶系统/风险色/组件规范/间距/图标风格 | 任意两页并排无拼装感；组件一致 |
| 建立 Evidence Pack 标准 | 告警系统 | 定义证据包字段与展示规则 | 任意告警详情页证据结构一致+处理回执完整 |
| 通知与打扰策略落地 | 通知系统 | 等级→渠道→频率→重试→升级链路 | 红色告警触达可靠；低等级不骚扰 |
| 真实世界约束用例覆盖 | US-05/21/22+测试 | 把网络/权限/噪音/摆放等写入 US 与测试用例 | 测试报告覆盖真实失败；无"请重试" |
| 国际化与紧急号码策略 | 全局 | 时区/紧急号码/文案策略 | 文案与交互不明确单一国家假设 |

---

### 补充：复审增强项（v1.5）

目的：在不增加 MVP 复杂度的前提下，进一步提升"信任可解释性"与"多人协作可控性"。

#### 一、System State Model：增加"状态冲突优先级"（State Conflict Priority）

背景：实际运行中可能出现"连接状态"与"风险事件"同时存在的情况（例如：设备离线，但离线前最后数据触发了潜在跌倒）。为避免 UI 表达冲突，家属理解混乱，建议补充状态优先级规则：

17. 优先级规则：风险状态（告警/潜在风险）优先于连接状态（在线/离线）。
18. 透明声明：当风险事件发生在信号不佳或离线边缘时，在详情页/提示中增加一句说明："信号不佳可能导致数据延迟或不完整"。
19. 呈现建议：首屏突出风险与行动按钮；连接状态仍显示在次级位置（例如"设备当前离线/信号弱"）。

#### 二、处理回执（State Receipt）：保持可追溯，但尽量减轻用户负担

目标：既保留"谁/何时/结果"的可追溯性，又避免让家属在紧急场景下做繁琐填写。建议采用"轻量回执"策略：

- 在告警卡/详情页提供 2~4 个一键结果：已联系 / 无人接听 / 稍后再试 / 已升级紧急（可按场景微调）。
- 当用户点击 "Call Mom / 拨打电话" 后，返回 App 自动弹出轻量询问（非强制、可关闭）："联系上了吗？"并提供一键回执按钮。
- 说明：MVP 阶段不建议依赖系统级通话检测（跨平台能力不一致，且会引入额外权限/边界条件）。

#### 三、并发协同（Concurrency）：MVP 采用"降级方案"，避免引入实时同步复杂度

背景：红色告警可能同时触达多个子女。实时同步（例如"David is checking this"）价值很高，但会引入实时状态、权限与边界条件。MVP 建议先采用降级实现：

- 在告警详情页显示"最近一次查看/开始处理的人 + 时间"（例如：David · 14:32）。
- 在告警列表卡片上以小标签展示"处理中/已处理"，并显示最后更新人（如适用）。
- 处理回执记录仍保留（用于复盘与避免重复行动），但不做实时在线协同与工单流转。

#### 四、落地到关键 US 的最小改动点（建议写回对应 US）

##### US-09（红色告警处理闭环）

- 补充：状态优先级规则（风险 > 连接）与透明声明（信号不佳/数据延迟）。
- 补充：轻量回执按钮（已联系/无人接听/稍后再试/已升级）。
- 补充：降级协同信息（最近处理人+时间）。

##### US-21/US-22（离线与兜底）

- 补充：若离线边缘触发风险事件，首屏仍以风险优先展示，同时明确离线/信号不佳说明。
- 补充：离线提示文案保持行动导向，避免冷冰冰系统提示。