436 lines
33 KiB
Markdown
436 lines
33 KiB
Markdown
# 老年健康系统：运动预约、志愿者协助、智能体与摄像头扩展
|
||
|
||
> 更新日期：2026-10-05（Asia/Shanghai）。本文保存用户新增愿景和实现约束，作为旧项目迁移到芋道后的设计上下文。
|
||
|
||
> 历史设计快照：健康身份与基础档案已开始实施；最新确认规则及已完成内容见 [健康业务模块与身份模型](健康业务模块与身份模型.md)。每个账号仅允许一种业务身份，第一版由管理员建号建档，志愿者须审核，家属关联须确认；本文其余设计建议不代表已实现。
|
||
>
|
||
> 文档状态：用户需求已记录；数据模型、状态名、实现阶段是设计建议，尚未写入业务代码。未启动服务、接入设备、大模型、短信或外部呼叫服务。
|
||
>
|
||
> 来源：本次用户对 7 个需求问题的回答；目标模板静态检查。不要把“目标能力”“预留接口”“已经实现”混为一谈。旧系统既有功能仍按此前迁移分析处理。
|
||
|
||
## 1. 用户已经确认的范围
|
||
|
||
### 1.1 场地与多人活动
|
||
|
||
- 需要轻量的场地、人数、设备管理。
|
||
- 允许多个老人一起参加运动。
|
||
- 保留扩展性，但不过度复杂，便于维护。
|
||
- 第一版不需要复杂排班平台、物联网平台、独立微服务或通用资源调度引擎。
|
||
|
||
### 1.2 老人预约与运动提醒
|
||
|
||
- 暂时只允许老人本人发起预约。
|
||
- 老人可以安排想运动的时间，系统应有提醒功能。
|
||
- 需要协助时，系统可自动向志愿者派单。
|
||
- 不是所有运动都需要志愿者协助。
|
||
- 管理员可以设置运动类别是否强制需要协助；部分情况下可由老人自行选择。
|
||
- 未来可以根据年龄、基础病等指标，由大模型/智能体判断是否需要协助。
|
||
- 已确认同时支持自主预约（项目与期望时间）和管理员发布活动场次供老人报名；具体预约时间/时长限制仍待后续确定。
|
||
|
||
### 1.3 志愿者安排
|
||
|
||
- 自动匹配派单与管理员派单都需要支持。
|
||
- 需要根据条件进行智能匹配。
|
||
- 志愿者可以拒单，但拒单次数有限制。
|
||
- 已确认拒单按月限制，每次拒单必须填写理由；具体上限由管理员配置。
|
||
- 拒单理由是否可申请例外、达到上限后的处理、取消/超时是否计入仍需在实施时细化。
|
||
|
||
### 1.4 健康评估与活动建议
|
||
|
||
- 希望通过大模型分析，将健康评估结果与活动关联。
|
||
- 老人可以自由选择运动，也可以接受大模型建议或安排。
|
||
- 预期会使用智能体，不能只做固定页面里的文字聊天。
|
||
- 医学限制、建议适用范围与智能安排的确认方式尚未最终确定。
|
||
|
||
### 1.5 服务过程和投诉
|
||
|
||
- 认可基本流程：提交预约 → 分配志愿者 → 接单 → 到场签到 → 开始运动 → 结束记录。
|
||
- 志愿者可以点击按钮结束服务，类似配送员确认送达。
|
||
- 老人或家属可以投诉异常情况。
|
||
- 不要求将老人/家属确认作为普通服务完成的必经步骤。
|
||
|
||
### 1.6 摄像头与视频
|
||
|
||
- 摄像头固定在场地中，后续接入。
|
||
- 计划输出骨骼信息、动作类型、次数、动作是否标准/动作评分，以及跌倒等异常检测结果。
|
||
- 希望循环保存最近 72 小时视频，超过时间自动清理。
|
||
- 当前需预留接口，识别算法和设备协议尚未确定。
|
||
|
||
### 1.7 安全告警愿景
|
||
|
||
- 检测到异常应通知管理员。
|
||
- 中控页面应有声音和视觉提示。
|
||
- 希望无回应时自动拨打 120，并给家属发短信。
|
||
- “老人是否回应”的判断尚待商榷；回应渠道、超时、复核、自动呼叫渠道均未定。
|
||
- 该愿景不代表目前已有可用的 120 呼叫 API 或接入授权；一期保留能力接口和升级规则，不把号码当成可直接调用的服务。
|
||
|
||
## 2. 本轮追加确认的实施约束
|
||
|
||
| 项目 | 用户确认 | 实施含义 |
|
||
| --- | --- | --- |
|
||
| 第一阶段范围 | 健康档案与评估迁移＋运动预约＋志愿者派单＋提醒，同时预留摄像头和智能体接口 | 一期不要求真实设备/模型接入；原系统核心评估能力需要迁移 |
|
||
| 预约形态 | 自主预约与管理员发布活动场次并存 | 老人可安排个人运动，也可报名多人活动 |
|
||
| 拒单计数周期与理由 | 按月限制，每次必须写理由；次数由管理员配置 | 保存拒单历史和理由，按月份统计，不用按天/周规则 |
|
||
|
||
以上三项已收到用户明确答复，属于确认需求。其他章节具体字段、状态和技术选型仍为设计建议；第 16 节列出尚待细化的事项。
|
||
|
||
## 3. 已探索的芋道模板事实
|
||
|
||
目标源码位置：`C:/Users/Administrator/Desktop/projects/elder-yudao`。
|
||
|
||
- `pom.xml`：`2.0.1-jdk8-snapshot`，Java 8，Spring Boot 2.7.18。
|
||
- `yudao-dependencies/pom.xml`：MyBatis-Plus 3.5.5，Flowable 6.8.0。
|
||
- 根 Maven 构建和 `yudao-server/pom.xml` 当前只接入 system、infra 业务模块；member/bpm/report 等有源码但未加载。
|
||
- 默认 `application.yaml` 选择 local 环境，多租户开启；local HTTP 端口 48080。
|
||
- 当前目录没有前端工程、health 业务模块或 ai 模块。
|
||
- 后台账号与 App 会员是两种主体：`system_users` / `member_user`。
|
||
- Web 框架按 controller.admin/controller.app 包自动添加 `/admin-api` / `/app-api`。
|
||
- system 已有短信、站内信 API，均能区分 admin/member。
|
||
- infra 已有文件配置、文件管理、定时任务和接口日志。
|
||
- framework 已有 WebSocket、Redis、锁/幂等/限流、数据权限和租户隔离。
|
||
|
||
可复用接口的位置：
|
||
|
||
```text
|
||
yudao-module-system/yudao-module-system-api/src/main/java/cn/iocoder/yudao/module/system/api/sms/SmsSendApi.java
|
||
sendSingleSmsToAdmin / sendSingleSmsToMember
|
||
|
||
yudao-module-system/yudao-module-system-api/src/main/java/cn/iocoder/yudao/module/system/api/notify/NotifyMessageSendApi.java
|
||
sendSingleMessageToAdmin / sendSingleMessageToMember
|
||
|
||
yudao-framework/yudao-spring-boot-starter-job/src/main/java/cn/iocoder/yudao/framework/quartz/core/handler/JobHandler.java
|
||
execute(String param)
|
||
|
||
yudao-module-infra/yudao-module-infra-biz/src/main/java/cn/iocoder/yudao/module/infra/framework/file/core/client/FileClient.java
|
||
upload / delete / getContent / getPresignedObjectUrl
|
||
```
|
||
|
||
注意：FileClient 的 getPresignedObjectUrl 默认实现是不支持；S3FileClient 的现有实现生成的是 PUT 上传预签名 URL，不能直接当成私有视频 GET 播放签名。实际播放适配、视频流/录像服务需额外核对。
|
||
|
||
## 4. 建议的业务结构：一个健康模块，按职责分包
|
||
|
||
保留 system、infra，启用 member，新增 `yudao-module-health`；是否拆为 api/biz 跟随目标项目现有结构。健康业务分包，不先拆成独立服务：
|
||
|
||
| 包/职责 | 内容 |
|
||
| --- | --- |
|
||
| profile / assessment | 老人档案、志愿者资料、家属关系、问卷、评分、评估结果 |
|
||
| activity / booking | 运动项目、场地、活动场次、预约、报名与人数 |
|
||
| service | 协助工单、志愿者匹配、派单、接单/拒单、签到/开始/结束、投诉 |
|
||
| exercise | 实际运动会话、参与者、运动结果、既有运动记录与汇总 |
|
||
| monitoring | 设备、检测事件、异常、安全告警、中控和录像索引 |
|
||
| notification | 运动提醒、派单提醒、告警升级、渠道发送与重试 |
|
||
| intelligence / integration | 模型分析、智能体工具、摄像头协议适配、外部呼叫适配 |
|
||
|
||
老人和家属采用 member 主体；志愿者初步也用 member 主体加健康业务身份。后台管理员/课题组操作员使用 system 主体。志愿者资质、拒单规则、服务分配属于健康业务，不直接用后台菜单角色来代替。
|
||
|
||
家属发起预约暂不开放，但有效关联且有授权的家属可以查看对应老人服务、接收通知和提交投诉。多租户继续生效；需明确课题组/机构与租户的关系，新业务不能把 tenant_id 都写成默认值。
|
||
|
||
## 5. 预约、活动场次、协助工单和运动会话的关系
|
||
|
||
这四个对象需要分开，才能支持“不需要志愿者”和“多人运动”：
|
||
|
||
| 对象 | 表达的事实 | 示例 |
|
||
| --- | --- | --- |
|
||
| 预约 Booking | 某位老人打算在某时参加某运动 | 老人 A 预约 10 月 8 日 9:00 散步 30 分钟 |
|
||
| 活动场次 ActivityOccurrence | 一个有时间、地点、人数上限的活动安排 | 社区 9:00 八段锦场次，最多 8 人 |
|
||
| 协助工单 ServiceTask | 某活动需要志愿者完成的协助工作 | 协助 9:00 八段锦活动的 3 位需要协助的老人 |
|
||
| 运动会话 ExerciseSession | 运动实际发生的一次过程 | 实际 9:05～9:36；参与者、志愿者、设备和结果 |
|
||
|
||
用户已确认同时支持两种入口；建议底层共用对象：
|
||
|
||
- 自主预约：选择运动、期望开始时间/时长、地点和协助意愿；后台可形成仅本人可见的活动安排。
|
||
- 活动报名：选择管理员已发布的场次；每位老人有独立报名/预约记录，共用场地与场次。
|
||
|
||
不需要协助的预约不创建协助工单，但仍有提醒和运动记录。摄像头可以在没有志愿者时记录运动或发现异常。
|
||
|
||
多人活动初步采用“一个场次一个协助工单，允许多个志愿者岗位/派单记录”，工单关联需要协助的参与老人。场次中不需要协助的老人仍可以参加。具体配置志愿者数量/每人协助人数，先做简单上限配置；未来可拆工单或分组，不先做复杂优化调度。
|
||
|
||
管理员发布场次时可以要求先确认最低志愿者数量才开放报名，或者报名后招募。哪种策略采用由运营流程确认；不能因为创建了工单就认为协助已经落实。
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
Elder[老人选择项目或场次] --> Booking[预约与协助判断]
|
||
Booking --> Reminder[运动提醒]
|
||
Booking --> Need{需要协助}
|
||
Need -->|否| Exercise[实际运动会话]
|
||
Need -->|是| Task[协助工单]
|
||
Task --> Dispatch[规则匹配或管理员派单]
|
||
Dispatch --> Accept[志愿者接单]
|
||
Accept --> Arrival[到场与开始服务]
|
||
Arrival --> Exercise
|
||
Device[场地摄像头] --> Exercise
|
||
Exercise --> Result[结束记录与效果评估]
|
||
Exercise --> Alert[安全告警]
|
||
Result --> Complaint[老人或家属投诉]
|
||
```
|
||
|
||
## 6. 运动协助政策与智能体边界
|
||
|
||
运动项目的 assist_policy 建议采用以下枚举，而不是单一需要/不需要布尔值：
|
||
|
||
| 政策 | 默认行为 |
|
||
| --- | --- |
|
||
| REQUIRED | 必须有协助，老人不能关闭 |
|
||
| OPTIONAL | 老人选择是否需要；智能体可以建议 |
|
||
| RULE_BASED | 后端规则结合资料决定，未来智能体参与分析 |
|
||
|
||
无协助作为判断结果，而不再另造一套工单流程。老人主动要求协助时可以增加需求；管理员禁止开放的项目/场地或强制协助约束不会被模型撤销。
|
||
|
||
决策输入建议包括：运动类型/强度/时长、年龄、既有评估结果、基础病、行动能力、明确风险信息、资料更新时间、场地设备和可用协助。存储 assist_required、decision_source、reason、rule/model_version、assessed_at 和必要的输入引用快照，便于解释“为什么派单”。
|
||
|
||
初期规则也要明确资料缺失或过期时如何处理，例如要求补充评估或转人工确认；不要把缺失数据默认等同于低风险。具体年龄/疾病阈值没有用户确认，不在此文编造医学规则。
|
||
|
||
智能体预留三个用途：
|
||
|
||
1. 评估分析：把结构化问卷、指标和历史记录转换为风险摘要与运动建议。
|
||
2. 运动规划：从管理员维护的有效项目/场次中推荐，或生成候选运动计划。
|
||
3. 协助判断/匹配解释：建议是否协助、匹配哪些志愿者，并提供依据。
|
||
|
||
建议接口为 AssessmentAnalysisProvider、ExercisePlanningProvider、AssistDecisionProvider、VolunteerMatchStrategy。首版可使用规则实现和未启用的模型适配，不要把未调用模型的结果命名为 AI 分析。
|
||
|
||
模型建议输出结构化对象，包含来源、模型版本、证据/输入引用、有效期和建议理由。智能体通过受控工具查询项目、场次和已授权资料；创建预约/调整安排必须走同一业务 Service，验证时间、容量、身份和幂等。个人未确认的“建议”不应直接变成占用资源的预约，除非后续明确允许自动计划。
|
||
|
||
安全关键动作采用确定的业务规则：告警升级、对象授权、容量与重复派单检查不能只让大模型做自然语言决定。自然语言投诉也可以辅助分类，但不由模型直接认定责任或删除记录。
|
||
|
||
## 7. 志愿者匹配、派单与拒单
|
||
|
||
### 7.1 初期匹配实现
|
||
|
||
先做“硬条件过滤 + 可解释排序 + 管理员介入”，为后续模型匹配提供稳定业务接口。
|
||
|
||
硬条件示例：账号和志愿者身份有效、允许提供服务、服务区域/场地、空闲时间、所需技能、已有工单时间冲突、可协助人数。技能要求和资质流程尚未确定，字段可先轻量维护。
|
||
|
||
排序可参考：距离/区域、技能匹配程度、近期服务次数、负载、响应表现、已拒绝当前任务。权重由管理员配置并记录版本，首版只选几项确定数据，不需要机器学习模型。
|
||
|
||
派单记录保存候选、分数/理由、发出时间、响应截止时间、结果和尝试次数。自动派单与手动派单走同一入口。已有有效接单时不得被后台操作静默覆盖；改派应撤销原记录并通知。
|
||
|
||
自动派单是发出指派并等待接单，不是替志愿者完成接单。志愿者自助抢单是否开放尚未确认；“自动匹配/管理员派单两种方式”不等于已经确定开放抢单大厅。
|
||
|
||
### 7.2 拒单限制
|
||
|
||
- 用户已确认按月限制且每次填写理由；具体次数由管理员配置，原因例外和达到上限的措施尚待确定。
|
||
- 管理端维护 monthly_refusal_limit；按服务端时间统计。建议以 Asia/Shanghai 自然月计算，保存明确月份（如 2026-10）；“自然月或滚动 30 天”未明确时，以自然月作为待确认的实施假设，不删除过去月份历史。
|
||
- 拒单 reason 必填且 trim 后非空，后端同样校验；可加原因类别和说明，但只做理由文本即可满足用户当前要求。
|
||
- 只计主动拒绝实际收到的有效指派。超时未回应、管理员撤销、老人取消、重复请求分别记录，不默认混成拒单。
|
||
- 可考虑健康、交通、突发事项由管理员标记例外；是否允许/怎么审核待定。
|
||
- 达到上限后可暂停自动派单资格或转管理员处理；不建议在真实无法服务时强迫用户维持工单。最终执行措施待定。
|
||
- 拒单后换候选，避免立即把同一工单派回同一个人。
|
||
- 所有候选耗尽、快到开始时间、协助人数不足时通知管理员；老人端准确展示等待协助，不显示“已落实”。
|
||
|
||
状态变更和拒单计数需原子处理；同一点击/网络重试不能计两次。并发派单不能让同一人占用冲突时间，也不能超出工单所需志愿者数量。
|
||
|
||
## 8. 服务状态、完成与投诉
|
||
|
||
预约、工单、单次指派、运动会话、安全告警应有独立状态，避免一列 status 混用。
|
||
|
||
| 对象 | 建议状态 |
|
||
| --- | --- |
|
||
| 预约 | PENDING（条件/协助待落实）、CONFIRMED、CANCELLED、COMPLETED、NO_SHOW |
|
||
| 协助工单 | WAITING_ASSIGNMENT、WAITING_ACCEPTANCE、READY、IN_PROGRESS、COMPLETED、CANCELLED |
|
||
| 指派记录 | OFFERED、ACCEPTED、REJECTED、EXPIRED、REVOKED；到场信息独立记录 |
|
||
| 运动会话 | READY、RUNNING、ENDED、ABORTED |
|
||
| 投诉 | SUBMITTED、PROCESSING、RESOLVED、CLOSED |
|
||
| 安全告警 | DETECTED、ACKNOWLEDGED、HANDLING、RESOLVED；升级阶段独立保存 |
|
||
|
||
这是拟定状态集；是否需要预约人工审核仍未确认，PENDING 不等于管理员审核。
|
||
|
||
简单服务流程：待分配 → 发出指派 → 接单 → 到场签到 → 开始 → 志愿者点击结束 → 保存实际时长/运动结果/服务说明。只需要一个确认服务完成的责任人时，可指定工单负责人；多人协助时区分某志愿者结束自己参与和负责人结束整个工单，避免一个人退出就关闭全场。
|
||
|
||
“无人协助运动”的实际开始/结束可以由老人按钮、场地操作员或后续设备事件触发，不能依赖志愿者。到预约结束时间只能标记超时/待核实，不直接捏造实际运动完成。
|
||
|
||
签到方式先选按钮/场地码等轻量方案，定位、二维码是否必需待定。摄像头事件作为过程证据，不自动代替服务完成声明；实际没检测到动作也不能直接认定志愿者未服务。
|
||
|
||
投诉关联 booking_id、task_id、session_id 中必要对象，包含投诉人、与老人的授权关系、内容、时间、附件和处理记录。投诉与安全事件可相互关联，但投诉不是即时紧急告警。完成后仍可投诉；投诉处理不删除原服务历史。
|
||
|
||
## 9. 轻量场地、人数与设备管理
|
||
|
||
### 9.1 场地
|
||
|
||
轻量字段建议：名称、地址/区域、负责人、启停状态、人数上限、允许时段、备注。不要首版构造多层楼宇/空间数字孪生。
|
||
|
||
场次人数与场地容量需要区分：场次有报名上限；同一场地同时存在多个场次时还要检查共享容量/占用。首版可让场地配置“独占/共享”和简单人数上限；独占场次限制重叠，共享累计人数限制容量。
|
||
|
||
预约开始/结束时间保存时间戳或目标标准时间类型，业务按 Asia/Shanghai 展示和配置，明确跨天。人数判断、报名提交和取消释放名额要在事务/锁或条件更新下执行，防止并发超售。
|
||
|
||
### 9.2 设备
|
||
|
||
设备先有：唯一 device_code、类型、所属场地、名称、启停状态、能力列表、最近心跳、在线状态、厂商/协议版本、配置引用。摄像头固定绑定场地，暂不做复杂设备借用流程。
|
||
|
||
“设备启用”和“设备在线”是两种状态；心跳超时可以发设备故障提醒，不能自动当作老人跌倒或无回应。管理员能看设备列表、绑定场地、状态和最近事件即可。
|
||
|
||
同场地多摄像头可共用一场运动会话，不默认每个摄像头都占一份场地人数。普通器材如需数量管理，可以轻量记录总量/可用量与场次需求，后续再加维护/借还。
|
||
|
||
## 10. 摄像头接入合同与多人关联
|
||
|
||
### 10.1 用业务 DTO 隔离硬件协议
|
||
|
||
预留 DeviceEventAdapter 和 RecognitionEventService；HTTP 回调、MQTT、WebSocket 或队列通过适配层转换成统一事件，尚未确认的协议不写死。
|
||
|
||
建议统一事件字段：
|
||
|
||
```text
|
||
eventId 设备事件唯一 ID/幂等键
|
||
schemaVersion 我们的事件结构版本
|
||
deviceCode 设备编号，服务端查绑定场地与租户
|
||
occurredAt / receivedAt 设备发生时间/服务端收到时间
|
||
eventType heartbeat / motion_summary / skeleton / fall_detected / ...
|
||
providerModelVersion 检测算法版本
|
||
sessionRef 已绑定的运动会话；可为空，但需标明归属状态
|
||
subjectTrackId 摄像头跟踪 ID；不是会员 ID
|
||
confidence 如算法提供，保存置信度及定义/范围
|
||
payload 动作类型、次数、分值、关节点、异常详情
|
||
clipRef 可选录像片段引用
|
||
```
|
||
|
||
设备回调通过设备凭据/签名或实际网关身份鉴别；租户、场地从服务端绑定关系取得，不信任设备传入任意会员或 tenant_id。同一 eventId 重试可安全接收；允许记录迟到/乱序事件，不能把迟到的旧检测覆盖新状态。
|
||
|
||
### 10.2 多人场景的关键问题
|
||
|
||
骨骼跟踪 ID 通常只识别视频里的一个人，并不自然知道是哪个老人。必须预留 track_id ↔ session_participant 的映射来源、有效期和可信度。
|
||
|
||
可选方案：到场登记后由工作人员绑定、站位/区域绑定、设备端提供标识映射。具体方式与课题组算法团队确认；当前不承诺使用人脸识别。
|
||
|
||
无法确认身份的跌倒事件仍可以按场地发中控告警，显示“人员待确认”；不能随机给某位老人家属发短信或把动作分写到其档案。多人参与关联是后续接入前的必要联调点。
|
||
|
||
### 10.3 数据量控制
|
||
|
||
业务数据库保存运动摘要和异常：动作、次数、标准程度、关键时间、模型版本、绑定信息。原始视频和连续高频骨骼序列不逐帧写 MySQL；保存文件/流服务引用，按需要保留关键帧或片段。
|
||
|
||
动作是否标准的分数必须记录算法定义/版本，不能直接与医学量表分数相加。后续效果评估从量表变化、服务记录和动作结果分别计算。
|
||
|
||
## 11. 最近 72 小时录像保留
|
||
|
||
目标为滚动时间窗口，而不是每天清空一个目录。优先让摄像头/NVR/录像服务按片段存储，平台保留索引：device_id、venue_id、session_id（可空）、start_at、end_at、storage_config_id、object_key、expire_at、删除状态。
|
||
|
||
建议正常录像片段以 end_at + 72h 为过期时间；应约定片段长度与清理扫描周期，因此实际剩余边界可能有一个片段长度/扫描间隔的偏差。若必须严格保留窗口，应由录像端直接执行策略。
|
||
|
||
清理 Job 或存储生命周期策略删除真实片段，同时更新索引；删除失败记录重试，不能只删数据库行。服务重启后补查过期片段；文件缺失和索引过期可核对。
|
||
|
||
活动教学视频属于长期内容库，监控录像属于短期留存，两者使用不同路径/保留策略，避免清理最近 72 小时录像的任务误删教学视频。
|
||
|
||
用户目前没有确认事故录像额外长期保存。若后续需要投诉/事故片段保全，应另行定义权限和保存期限；当前规则仍为 72 小时。异常事件的文字/结构化记录可以独立保留，但不能假装过期视频仍可播放。
|
||
|
||
平台的文件 API 适合附件与普通媒体索引，不应由 Java 应用直接把所有场地连续视频先读入 byte[] 再上传。预留录像端/对象存储接口和受控播放地址，后续决定 NVR、RTSP 拉流或摄像头推片方案。
|
||
|
||
## 12. 安全告警、中控与回应
|
||
|
||
### 12.1 将三类确认分开
|
||
|
||
| 确认 | 含义 | 不能据此推断 |
|
||
| --- | --- | --- |
|
||
| 管理员 ACK | 有管理员看见并接手告警 | 老人已经安全 |
|
||
| 老人 RESPONDED | 老人按规定渠道做了回应 | 跌倒已经解除、无需帮助 |
|
||
| 事件 RESOLVED | 经处置确认事件结束，记录结果 | 所有通知已经送达 |
|
||
|
||
提醒/短信“发送成功”、App“在线”、中控“已播放声音”同样不是老人回应。
|
||
|
||
建议告警记录 severity、来源、发生时间、设备/场地、可能的参与者、当前处理人、处理状态、升级阶段、回应结果及证据、通知尝试和处置结果。多摄像头同一异常可归并，但归并窗口由算法联调确定，不盲目吞掉重复发生的异常。
|
||
|
||
### 12.2 升级流程候选
|
||
|
||
1. 收到可信异常，创建持久化告警，中控通过 WebSocket 更新事件列表/醒目标识并尝试声音提示。
|
||
2. 管理员接手或系统请求确认，向老人端发有 event_id 和有效期的回应请求；现场志愿者/工作人员可以报告观察结果。
|
||
3. 配置时限内未得到有效确认，升级给管理员/备用负责人；向已授权且手机号有效的家属发短信。
|
||
4. 若确认启用外部呼叫接入，按明确的紧急规则发出请求并记录反馈，区分“待请求、已提交、接通、失败、人工接管”。
|
||
5. 处置完成，记录结果；解除告警由有权限人员执行，不能仅凭通知已发或模型回答正常来解除。
|
||
|
||
步骤、等待时间、严重程度例外和短信触发时间仍待确定。可能的严重事件可以不等待普通确认流程；该规则需要业务/课题组确认。
|
||
|
||
### 12.3 老人回应的候选方式
|
||
|
||
- App 弹窗按钮：如“我没事”“我需要帮助”。“需要帮助”仍为有效回应，但不能关闭告警。
|
||
- 现场志愿者/工作人员确认：记录人员、时间、结论和事件关联。
|
||
- 语音回应：后续模型辅助解析，仍保留原始回应证据、识别结果与不确定状态。
|
||
- 摄像头姿态变化：仅作辅助证据，没有确认规则前不替代老人或现场人员的回应。
|
||
|
||
回应 API 绑定老人/事件/一次性或短期 challenge，服务端核验权限和有效期，防止旧回应解除新的异常。老人端断网、没带手机或通知没送到记 UNKNOWN/UNREACHABLE 等原因，不能直接判定医学意义的无反应。
|
||
|
||
中控页面声音受浏览器播放权限和用户设置限制；提供启用声音的交互和显著视觉兜底。WebSocket 断开后重连拉取未处理事件，确保告警不只活在内存推送里。管理员无 ACK 时可升级备用人，名单和时限待定。
|
||
|
||
### 12.4 自动拨打 120 的接入边界
|
||
|
||
保存为目标需求，预留 EmergencyContactGateway，但尚未确定能调用的外部通道、所在地区/机构接入方式、可传地址和回调、自动触发条件。普通短信渠道不能直接等同于外呼服务，手机 tel: 链接也不等同于服务端自动报警。
|
||
|
||
第一版可以实现告警、升级、管理员操作记录和模拟网关联调；没有真实通道时明确显示“未配置/人工联系”，不能展示已报警成功。将来经确认启用后，遵守同一事件幂等/取消/反馈合同，防止重复触发外部呼叫。
|
||
|
||
## 13. 建议数据对象：先保持轻量
|
||
|
||
以下是逻辑对象草案，不是必须一次建齐的表清单。按当前阶段逐步建表，复杂字段和重复数据避免过早加入。
|
||
|
||
| 对象 | 关键字段/关系 | 第一阶段建议 |
|
||
| --- | --- | --- |
|
||
| 运动项目 | 名称、启停、强度/建议时长、assist_policy、技能要求 | 建立 |
|
||
| 场地 | 名称、地址、负责人、容量、开放时段、占用政策 | 建立 |
|
||
| 设备 | device_code、场地、类型、启停/心跳、能力、协议 | 轻量登记；真实事件接入后续 |
|
||
| 活动场次 | 项目、场地、起止时间、容量、公开/私人、状态、协助配置 | 若支持活动报名则建立；私人预约可复用 |
|
||
| 预约/报名 | 老人 ID、场次/项目、时间、协助意愿/结果、决策依据、状态 | 建立 |
|
||
| 协助工单 | 场次/预约范围、需要人数、负责人、服务状态、实际时间 | 仅需要协助时创建 |
|
||
| 工单参与关系 | 工单与需要协助的预约/老人 | 支持多人，不复制全部老人档案 |
|
||
| 志愿者资料 | member_id、服务区域、技能、可用时段、状态 | 复用/扩展旧档案 |
|
||
| 指派记录 | 工单、志愿者、来源、尝试/结果、截止时间、拒单原因 | 建立，兼作拒单审计来源 |
|
||
| 运动会话与参与者 | 实际起止、活动、工单、老人、人员跟踪映射 | 可先简化；为设备预留关联 |
|
||
| 提醒/通知任务 | 业务 ID、接收者与主体类型、渠道、计划时间、状态/重试、幂等键 | 建立/扩展旧提醒 |
|
||
| 投诉 | 服务/会话/老人、投诉人、内容/附件、处理状态 | 基础流程 |
|
||
| 检测事件/摘要 | event_id、设备、时间、会话、track、模型版本、payload 引用 | 先定合同，设备接入时建立 |
|
||
| 录像片段索引 | 设备/场地、起止、object_key、expire_at、删除状态 | 录像接入时建立 |
|
||
| 安全告警与处置日志 | 来源、上下文、严重度、状态、回应、升级、处理记录 | 中控阶段建立 |
|
||
| AI 分析/建议记录 | 输入引用、模型/规则版本、结构化建议、状态/有效期、采纳结果 | 模型阶段建立 |
|
||
|
||
普通后台参数如提醒提前量、拒单次数、派单响应时限、匹配权重可先用模块配置/芋道参数配置；需要各机构不同规则时再做 tenant 级业务设置。不要为了几个配置先实现复杂规则编辑器。
|
||
|
||
重要唯一/并发约束：同一老人同场次重复报名、同一设备事件重试、同一有效指派、同一提醒/渠道发送、同一告警外呼请求均需幂等。预约改期/取消同步调整提醒、释放容量、撤销指派，整个流程用服务层事务和必要异步补偿。
|
||
|
||
## 14. 提醒、通知和定时任务
|
||
|
||
运动提醒和协助派单是不同触发事件：可以在预约确认后立即发起匹配，提前提醒按配置执行；具体提前多久由业务配置，不能把“到运动时间才派单”作为固定实现。
|
||
|
||
提醒支持至少开始前提醒、变更/取消通知、志愿者待接单提醒、临近开始协助不足提醒；异常升级有自己的规则。老人可配置自己想运动的时间，但关闭普通运动提醒不应关闭后台安全告警。
|
||
|
||
调度采用持久化任务 + 芋道 Job 扫描到期任务，而不是为每个预约创建一个内存定时器。Job 扫描、领取、执行、重试有状态；服务重启、重复扫描不重复发。使用业务键约束，并记录变更版本，防止改期后旧任务仍通知。
|
||
|
||
站内信、WebSocket、短信通过通知适配调用 system/infra/framework 能力。每个渠道保存结果，推送失败可重试或升级；发送成功只表示渠道接受/反馈结果，不能冒充实际阅读或回应。
|
||
|
||
App 后台/关闭时 WebSocket 不保证收到提醒，未来选择短信、平台订阅消息、App 推送或本地通知补充。用户尚未明确普通运动提醒采用哪些渠道，不能承诺关闭手机 App 也必达。
|
||
|
||
## 15. 分阶段落地与验收重点
|
||
|
||
用户已确认第一阶段先完成核心流程并预留摄像头/智能体接口；之后 B～D 阶段是待进一步安排的候选。
|
||
|
||
| 阶段 | 工作 | 边界 |
|
||
| --- | --- | --- |
|
||
| A（已确认核心范围） | 旧健康档案/评估迁移、可信身份、运动项目、轻量场地/设备、自主预约和活动报名、协助政策、规则/手动派单、服务状态、提醒 | 可运行核心服务闭环，按月拒单且理由必填；规则判断明确标为规则；投诉基础流程是相关设计建议，实施排期再细化 |
|
||
| B | 结构化模型评估、运动建议、受控智能体工具和可解释匹配 | 明确模型提供商/规则，建议与执行区分 |
|
||
| C | 固定摄像头适配、人员映射、动作摘要、跌倒告警、中控、72 小时录像 | 与课题组联调，真实协议和算法输出到位 |
|
||
| D | 回应核验、升级与家属短信、真实外部紧急呼叫 | 确认回应政策和实际通道后再启用 |
|
||
|
||
第一阶段即使不连接设备/模型，也应把 session_id、多人参与、决策来源、协议适配和事件幂等留好，避免以后推翻预约与工单模型。只做接口合同和必要关联，不创建空壳大型平台。
|
||
|
||
关键验收场景：
|
||
|
||
- 不需要协助、老人主动需要、强制需要三类预约；协助未落实的正确展示。
|
||
- 单人自主预约、多人场次、同场地容量与时间冲突、并发最后一个名额。
|
||
- 自动与手动派单、拒单理由不能为空、按月上限/跨月计数、拒单/超时/撤销区分、达到拒单上限、无候选与快到开始时升级、网络重试幂等。
|
||
- 老人取消/改期时容量/派单/提醒一致；多人中一个取消不关闭全场工单。
|
||
- 志愿者确认服务完成、多人责任人、未协助运动开始/结束、投诉授权与保留历史。
|
||
- 老人/家属/志愿者/管理员与不同租户的数据范围；同名 ID 不混主体。
|
||
- 模型不可用/资料缺失时有明确状态；建议不得越过容量和强制协助政策；不得把静态文案伪装成模型结果。
|
||
- 设备离线与老人异常分开；匿名 track 的场地告警、多摄像头重复/乱序、身份映射与动作归属。
|
||
- 72 小时清理边界、重启补偿、删除失败重试、教学视频不受录像策略影响。
|
||
- 中控断线重连、声音不可用的视觉提示；管理员 ACK 与老人回应分开；无通道时不展示呼叫成功。
|
||
|
||
## 16. 后续仍需确认但不阻碍写设计的事项
|
||
|
||
第 2 节三项已确认；以下问题后续按实施阶段逐步细化：
|
||
|
||
- 首批运动项目、场地和老人/志愿者规模；是否有真实名单/区域资料。
|
||
- 志愿者技能/资质、可用时段采集方式、单次最大协助人数、每月拒单上限、自然月/滚动月边界、改派/拒单例外和达到上限的措施。
|
||
- 场次报名、自动计划的确认方式、预约提前/取消/改期时间限制、场地占用规则。
|
||
- 普通提醒渠道、通知提前量、服务无回应/无候选处理时限。
|
||
- 大模型提供商、现有智能体研究方案、年龄/基础病/量表规则与资料有效期。
|
||
- 摄像头设备协议、时钟同步、event_id、人体跟踪 ID 持续性、动作分定义、场地人员绑定方式。
|
||
- NVR/录像保存位置、分片长度、是否允许事故片段超过 72 小时保存。
|
||
- 异常等级、有效回应渠道、严重事件直升规则、备用管理员、短信触发条件。
|
||
- 120/其他紧急联系人呼叫实际通道和反馈，失败人工接管流程。
|
||
|
||
后续 Codex 读取本文时，先分清第 1～2 节用户确认、第 16 节待定与其他章节设计建议，再按当前芋道工程实现；不要把所有待定项一次性要求用户回答，也不要未经实现/验证就报告集成完成。
|