# 📋 YoVision 智能视频事件平台 — 需求收集文档

> 版本 v0.3 · 2026-08-03
> 配套文档：《02-需求分析》《03-通用场景应用方案》
> 参考输入：`其他项目的文档/` 下三份跌倒检测项目文档（居家养老单场景），本文档将其经验泛化到多场景

---

# 1. 项目定位

## 1.1 一句话说明

**用开源 NVR 统一接入各类场景的 IP 摄像头，用深度学习模型识别场景中的指定人群与指定行为，命中规则的画面组装成「事件实例」推送到管理系统，预警信息按升级链推送到 App 与其他终端。**

## 1.2 与参考项目的关系

| 维度 | 参考项目（跌倒检测） | 本项目（YoVision） |
| --- | --- | --- |
| 场景 | 居家养老，单一 | 家庭 / 学校 / 社区 / 园区，多场景 |
| 检测目标 | 跌倒，单一行为 | 可配置的「人群 × 行为 × 区域 × 时段」组合 |
| 组织模型 | 家庭（扁平） | 租户 → 站点 → 区域 → 设备（多级、多租户） |
| 规模 | 200 户 / 250 路（历史参考项目） | **默认交付 16 路，单站点按 32 / 64 / 128 路横向扩展；本阶段上限 128 路** |
| 输出 | 跌倒告警 | 事件实例（结构化 + 证据）+ 分级预警 |
| 复用 | — | 接入层、对账器、推理流水线、预警状态机可整体复用 |

**结论：参考项目是本项目的一个场景实例。本项目要做的是把它拆成「通用底座 + 场景包」。** 这个判断决定了后续所有需求的分层方式。

## 1.3 容量决策（已定，2026-08-03）

| 项 | 决策 |
| --- | --- |
| 默认交付规格 | 单站点 **16 路视频设备** |
| 扩展档位 | 32 / 64 / 128 路 |
| 单站点本阶段上限 | **128 路**；超过 128 路需拆为多个逻辑站点或另行评估 |
| 扩容方式 | 增加媒体分片与推理 Worker，禁止靠单进程、单 GPU 硬扛 |
| 代码约束 | 16 只能是默认配额，数据库、规则、数组与循环中不得写死；配额必须可配置 |

推荐配置项：`site.max_video_channels` 默认 16、最大 128；`media_shard.max_streams` 与 `inference_profile.max_sources` 按硬件压测确定。平台管理、批量导入、监控和前端列表从第一版起按 128 路设计。

---

# 2. 干系人与诉求

## 2.1 干系人矩阵

| 干系人 | 角色 | 核心诉求 | 最怕什么 |
| --- | --- | --- | --- |
| 最终使用者（家属 / 校方安保 / 社区物业） | 预警接收与处置 | 该报的必报、报了必须有人知道 | 误报太多导致不再看 |
| 被监护/被拍摄对象（老人、学生、居民） | 数据主体 | 不被过度监视 | 隐私泄露、被"全天候盯梢" |
| 管理方（养老机构 / 学校 / 街道） | 运营与考核 | 事件可追溯、可统计、可导出 | 出事后拿不出记录 |
| 平台运维 | 系统可用性 | 设备在线率、告警不淹没 | 业务预警被运维噪声淹没 |
| 实施/交付 | 部署上线 | 装得快、开通批量化 | 摄像头型号五花八门装不上 |
| 算法团队 | 模型迭代 | 真实场景数据回流 | 只有公开数据集，与现场脱节 |
| 法务/合规 | 合规落地 | 知情同意、留存期限、权限边界 | 人脸识别越界 |

## 2.2 关键诉求冲突（需在需求分析阶段裁决）

| 冲突 | A 方 | B 方 | 初步倾向 |
| --- | --- | --- | --- |
| 全量录像 vs 隐私 | 管理方要"什么都能查" | 数据主体要"平时别看" | 事件驱动采集，非事件不上云 |
| 灵敏度 | 使用者要"绝不漏报" | 使用者要"别老误报" | 两级判定 + 误报反馈闭环 |
| 人脸识别 | 管理方要"认出是谁" | 合规要"最小必要" | **已定**：ReID 为默认手段，人脸按租户授权开启（见 §5.1） |
| 边缘算力成本 | 交付要"盒子便宜" | 算法要"跑得动模型" | 触发式推理，非常态全量 |

---

# 3. 需求来源与收集方法

| 来源 | 方法 | 状态 |
| --- | --- | --- |
| 参考项目文档 | 文档分析（三份 Notion 导出） | ✅ 已完成，见本文档全篇 |
| 场景走访 | 家庭 / 学校 / 社区各 2–3 个点位实地踏勘 | ⬜ 待执行 |
| 竞品与开源调研 | Frigate / ZoneMinder / Shinobi / MiBeeNvr / mediamtx / Savant | 🔶 NVR 选型已完成，见《03》§1.4；推理框架与商业竞品继续调研 |
| 硬件兼容性摸底 | 采购 3–5 款候选摄像头做 ONVIF 实测 | ⬜ 待执行（M0 出口） |
| 法务咨询 | 人脸识别、未成年人影像、留存期限 | ⬜ 待执行（阻塞 M3） |
| 现场误报采集 | 试点期真实误报案例库 | ⬜ 待执行（M3 首要产出） |

> **踏勘清单**（走访时必须带回的东西）：点位平面图与摄像头安装高度/俯角、现场网络出口带宽与是否有公网 IP、现有 NVR/平台型号、值班人员的实际工作流（现在出事怎么处理）、他们目前最痛的三件事。

---

# 4. 场景与需求清单

## 4.1 场景总览

| 编号 | 场景 | 典型部署点 | 主要目标人群 | 网络特征 |
| --- | --- | --- | --- | --- |
| S1 | 居家养老 | 客厅、走廊 | 老人（独居/失能） | 家庭 NAT 后，带宽小，易掉线 |
| S2 | 校园 | 教学楼、操场、宿舍、围墙、实验室 | 学生、教职工、外来人员 | 校园专网，带宽充足，有机房 |
| S3 | 社区/物业 | 出入口、电梯、周界、楼道、垃圾站 | 住户、访客、陌生人 | 小区专网，可能有本地机房 |
| S4 | 园区/厂区（扩展） | 车间、仓库、施工区 | 员工、承包商、访客 | 企业网，合规要求相对宽松 |

## 4.2 各场景原始需求条目

需求编号规则：`RQ-<场景>-<序号>`。优先级：P0 必须 / P1 应该 / P2 可以。

### S1 居家养老

| 编号 | 需求 | 优先级 | 来源 |
| --- | --- | --- | --- |
| RQ-S1-01 | 检测老人跌倒并在 10s 内发出首次预警 | P0 | 参考项目 §10.10 |
| RQ-S1-02 | 长时间静止/无活动（如卫生间超时、多小时无位移）告警 | P0 | 参考项目 §10.4 `no_motion` |
| RQ-S1-03 | 夜间离床未归（起夜超时）告警 | P1 | 走访待确认 |
| RQ-S1-04 | 陌生人进入居所告警 | P1 | 走访待确认 |
| RQ-S1-05 | 卧室、卫生间**不得安装摄像头**，仅可用雷达等非成像传感器 | P0 | 参考项目 §3 隐私 |
| RQ-S1-06 | 平时不解码、不上传，仅事件片段上云 | P0 | 参考项目 §3 隐私 |
| RQ-S1-07 | 家属只能查看自己家、且与告警关联的片段 | P0 | 参考项目 §3 |
| RQ-S1-08 | 无人 ack 时逐级升级，最坏 3 分钟内有真人接手 | P0 | 参考项目 §10.3 |

### S2 校园

| 编号 | 需求 | 优先级 | 备注 |
| --- | --- | --- | --- |
| RQ-S2-01 | 打架/推搡/围观聚集检测 | P0 | 校园安全核心诉求 |
| RQ-S2-02 | 翻越围墙、攀爬护栏检测 | P0 | 周界 |
| RQ-S2-03 | 危险区域（实验室、配电房、水池、天台）非授权人员闯入 | P0 | 需区域 + 身份/角色判定 |
| RQ-S2-04 | 外来人员尾随进入校门 | P1 | 需与门禁事件融合 |
| RQ-S2-05 | 上课时段学生在楼道/校外徘徊 | P1 | 需课表时段配置 |
| RQ-S2-06 | 宿舍晚归/夜间离寝 | P1 | 需时段策略 |
| RQ-S2-07 | 学生跌倒/晕倒 | P1 | 复用 S1 能力 |
| RQ-S2-08 | 未成年人影像的采集与留存需单独合规方案 | P0 | 法务阻塞项 |

### S3 社区/物业

| 编号 | 需求 | 优先级 | 备注 |
| --- | --- | --- | --- |
| RQ-S3-01 | 周界入侵（翻墙、跨越警戒线） | P0 | |
| RQ-S3-02 | 电动车进入电梯/楼道 | P0 | 消防强诉求，目标非人 |
| RQ-S3-03 | 消防通道占用/堆物 | P0 | 静态变化检测，非人 |
| RQ-S3-04 | 高空抛物 | P1 | 需专用仰拍机位与轨迹算法，独立评估 |
| RQ-S3-05 | 陌生人在单元门口长时间徘徊 | P1 | 需 ReID + 停留时长 |
| RQ-S3-06 | 独居老人连续 N 天未出入 | P1 | 跨天统计，非实时 |
| RQ-S3-07 | 重点关注人员（黑名单）出现告警 | P1 | 强合规约束，需授权 |

### S4 园区/厂区（扩展，本期不实现）

未戴安全帽 / 未穿反光衣 / 区域入侵 / 离岗 / 吸烟明火。列出仅为验证架构可扩展性，M4 前不投入。

## 4.3 跨场景通用需求

### 4.3.1 接入与设备管理

| 编号 | 需求 | 优先级 |
| --- | --- | --- |
| RQ-C-01 | 支持 ONVIF/RTSP 标准 IP 摄像头接入，不绑定品牌 | P0 |
| RQ-C-02 | 支持摄像头位于 NAT 之后（家庭、无公网 IP 的小区）的接入 | P0 |
| RQ-C-03 | 设备身份用序列号而非 IP（DHCP/Wi-Fi 漫游会换 IP） | P0 |
| RQ-C-04 | 支持批量开通（脚本/CSV 导入）；默认 16 路也不得依赖逐路手工配置，扩展到 128 路时操作量不得线性增加 | P0 |
| RQ-C-05 | 设备需有「待激活」中间态（批量开通时凭据待补） | P0 |
| RQ-C-06 | 设备探活与离线告警，离线超阈值主动通知 | P0 |
| RQ-C-07 | 开通时校时（ONVIF SetSystemDateAndTime），定期校准 | P0 |
| RQ-C-08 | 摄像头断线恢复后自动重连，不需人工干预 | P0 |
| RQ-C-09 | 架构需预留非视频传感器（毫米波雷达、门磁、紧急按钮）接入 | P1 |

### 4.3.2 分析与规则

| 编号 | 需求 | 优先级 |
| --- | --- | --- |
| RQ-C-10 | 检测能力与场景解耦，同一模型可被多场景规则复用 | P0 |
| RQ-C-11 | 规则支持「目标类型 × 属性/身份 × 区域 × 时段 × 行为 × 持续时长」组合 | P0 |
| RQ-C-12 | 规则可按租户/站点/单设备三级覆盖配置 | P0 |
| RQ-C-13 | 支持画区域（多边形）、画警戒线（方向性越线） | P0 |
| RQ-C-14 | 支持时段/日历（工作日、课表、节假日）策略 | P1 |
| RQ-C-15 | 规则变更不需重启推理流水线 | P1 |
| RQ-C-16 | 人脸识别/身份比对为**可选能力**，默认关闭，需按租户显式授权开启 | P0 |

### 4.3.3 事件实例

| 编号 | 需求 | 优先级 |
| --- | --- | --- |
| RQ-C-17 | 命中规则须生成事件实例，含：结构化元数据 + 抓拍图 + 视频片段 | P0 |
| RQ-C-18 | 视频片段须含事发前若干秒（pre-roll 回捞） | P0 |
| RQ-C-19 | 事件去重与防抖：同设备冷却、同站点聚合、已处置抑制 | P0 |
| RQ-C-20 | 事件推送到管理系统（Web），支持列表、筛选、详情、处置 | P0 |
| RQ-C-21 | 事件支持标记「误报」，误报样本自动进标注队列 | P0 |
| RQ-C-22 | 事件统计报表（按站点/类型/时段/处置结果） | P1 |

### 4.3.4 预警投递

| 编号 | 需求 | 优先级 |
| --- | --- | --- |
| RQ-C-23 | 预警须有 ack（确认）环节，未 ack 自动升级 | P0 |
| RQ-C-24 | 升级链、超时值、联系人、时段策略可按站点/租户配置 | P0 |
| RQ-C-25 | 至少两条独立投递路径，且需有绕过互联网的通道（电话/短信） | P0 |
| RQ-C-26 | 区分「已发出 / 已送达 / 已被看到」三个事实，无回执按失败处理 | P0 |
| RQ-C-27 | 支持 App 推送、短信、语音呼叫、Webhook、大屏/声光设备 | P0 |
| RQ-C-28 | 支持限时静默（维护窗口），**必须强制限时并自动恢复** | P0 |
| RQ-C-29 | 业务预警与运维告警**不得共用**投递通道与值班配置 | P0 |
| RQ-C-30 | 告警先落库再投递，进程重启后未完成的升级链能续跑 | P0 |

### 4.3.5 平台与运维

| 编号 | 需求 | 优先级 |
| --- | --- | --- |
| RQ-C-31 | 多租户隔离：数据、账号、配置、存储互不可见 | P0 |
| RQ-C-32 | RBAC：平台管理员 / 租户管理员 / 站点管理员 / 值班员 / 只读 | P0 |
| RQ-C-33 | 全链路审计日志，告警生命周期不可篡改留存 | P0 |
| RQ-C-34 | Prometheus 指标 + Grafana 看板（设备在线率、推理延迟、未收敛项） | P0 |
| RQ-C-35 | 支持边缘部署、中心部署、混合部署三种形态 | P1 |
| RQ-C-36 | 断网时边缘本地缓存事件，恢复后补传 | P0 |

---

# 5. 目标人群与检测能力清单

「指定人群」在实现上分三类，**合规风险与技术难度依次上升**，需求分析阶段必须逐条确认是否真的需要：

| 类别 | 判定依据 | 例子 | 是否需人脸 | 合规等级 |
| --- | --- | --- | --- | --- |
| A. 属性类 | 视觉外观属性 | 老人/儿童/成人、戴/未戴安全帽、穿工服 | 否 | 低 |
| B. 状态类 | 姿态与轨迹 | 跌倒、奔跑、聚集、徘徊、越线、滞留 | 否 | 低 |
| B+. 匿名同一性 | **ReID 跨镜再识别** | 同一人在此徘徊 10 分钟、跨机位跟随 | 否 | 中 |
| C. 身份类 | 人脸底库比对 | 住户/非住户、本校学生、黑白名单、具名人员 | **是** | **高** |

## 5.1 决策（已定，2026-08-01）

| 项 | 决策 |
| --- | --- |
| A、B 类 | P0，无争议 |
| **B+ ReID** | **默认手段**。所有"同一性"类需求（徘徊、尾随、跟随、跨镜追踪）一律优先用 ReID 实现 |
| **C 人脸识别** | **在方案范围内**，由客户/租户签署授权后启用；未授权租户系统层面不可开启 |

> **原则：能用 ReID 解决的，不上人脸。**
> ReID 产生的是会话内的匿名 track/person 标识，能回答"是不是同一个人在这徘徊 10 分钟"，但不回答"他是谁"。它满足 RQ-S3-05（徘徊）、RQ-S2-04（尾随）等大部分需求，且不涉及生物识别信息的采集与存储。
>
> 人脸识别只用在**必须知道"是谁"**的需求上：白名单放行（本校学生/住户）、重点关注人员告警、访客登记核验。这类需求要逐条论证"为什么 ReID 不够"。

## 5.2 人脸识别启用的前置条件

授权不等于可以直接开。启用前必须齐备：

| # | 前置条件 | 责任方 |
| --- | --- | --- |
| 1 | 租户签署书面授权（含用途、范围、期限、底库来源合法性承诺） | 客户 + 法务 |
| 2 | 被采集人（或未成年人监护人）的知情同意取得方式与留档流程 | 客户 |
| 3 | 采集场所的告示义务已履行 | 客户 |
| 4 | 底库数据的来源、录入流程、删除流程已定义 | 产品 + 客户 |
| 5 | 底库加密存储、独立访问审计、最小授权已实现 | 研发 |
| 6 | 未成年人场景的专项合规意见 | 法务 |

> 校园场景（S2）涉及未成年人，即便有租户授权，第 6 项独立成阻塞条件。

## 5.3 派生需求（人脸识别）

| 编号 | 需求 | 优先级 |
| --- | --- | --- |
| RQ-FR-01 | 人脸能力按**租户**开关，未授权租户在 API 与 UI 层均不可见 | P0 |
| RQ-FR-02 | 底库人员档案管理：录入、分组（白名单/关注名单/访客）、有效期、注销 | P0 |
| RQ-FR-03 | 底库支持到期自动失效（如学生毕业、住户搬离、访客当日有效） | P0 |
| RQ-FR-04 | 人脸特征值加密存储，**不存原始人脸图**（或原图与特征分库、单独授权） | P0 |
| RQ-FR-05 | 每一次比对命中与查询均记入独立审计日志，可追溯操作人 | P0 |
| RQ-FR-06 | 比对不可用/未命中时规则仍须工作（降级为"未知人员"），**不得因此漏报** | P0 |
| RQ-FR-07 | 支持置信度阈值配置与人工复核（高风险动作前需二次确认） | P1 |
| RQ-FR-08 | 支持底库整体导出与彻底删除（客户终止服务时） | P0 |
| RQ-FR-09 | 人脸相关数据的留存期限独立于视频证据，可单独配置 | P1 |

---

# 6. 设备与环境约束调研

## 6.1 摄像头兼容性验证清单（沿用参考项目 M0 出口标准）

采购 3–5 个候选型号做实测，**这是整个项目第一件要做的事**。

### 必过项

| 验证项 | 通过标准 | 不通过的后果 |
| --- | --- | --- |
| GetProfiles | 返回至少两个 profile（主码流 + 子码流） | 无法自动获取子码流，需人工配置 |
| GetStreamUri | 返回可用的 RTSP URL | 无法自动化开通 |
| SetSystemDateAndTime | 调用成功且生效 | 事件时间戳不可信 |
| 子码流规格 | 可设为 640×360 或 704×576 左右 | 带宽和算力估算失效 |
| 编码格式 | 支持 H.264 | H.265 浏览器无法原生预览 |
| WS-Security 认证 | digest 或 usernametoken 任一可用 | 认证失败 |
| RTSP over TCP | 长时间稳定不断流 | 家庭/无线网络下 UDP 丢包严重 |

### 加分项

- 支持 ONVIF 事件订阅（移动侦测）—— 可作为触发式推理的一级信号
- 支持修改 GOP 长度 —— 影响 pre-roll 回捞的关键帧间隔
- 支持创建独立只读用户 —— 不必用 admin 凭据接入
- 支持 ONVIF Profile T / 双向音频 —— 社区场景的远程喊话

> 任何一项必过项失败的型号直接从采购清单划掉。**后期写兼容代码的成本远高于换型号。** 验证结果整理成表格，作为采购白名单归档。

## 6.2 网络环境差异

| 场景 | 摄像头可达性 | 上行带宽 | 结论 |
| --- | --- | --- | --- |
| 家庭 | NAT 后，无公网 IP | 20–50 Mbps 上行，共享 | 必须边缘侧主动推流，中心不可主动拉 |
| 校园 | 专网，通常有机房 | 充足 | 可中心部署，也可校内边缘部署 |
| 社区 | 专网，有无机房不确定 | 视物业投入 | 混合，按项目定 |

## 6.3 边缘硬件候选

| 平台 | 算力 | 适用 | 说明 |
| --- | --- | --- | --- |
| RK3588 | 6 TOPS NPU | 家庭单户、小型点位 | 无风扇、低噪、低功耗；模型需转 RKNN |
| Jetson Orin Nano/NX | 20–100 TOPS | 校园/社区中型边缘 | 与 Savant/DeepStream 原生契合 |
| x86 + 消费级 GPU | 高 | 中心机房 | ⚠️ GeForce 卡**同时硬件编码流数上限为 3**，做可视化回推时会卡死，需 L4/Quadro 类专业卡 |

---

# 7. 已知约束与前提

## 7.1 技术约束（来自参考项目实测经验，直接继承）

| 约束 | 后果 | 出处 |
| --- | --- | --- |
| mediamtx 通过 API 改的配置**不落盘**，重启即失效 | 设备台账必须在自有数据库，启动时 replay | 参考 §4.1 |
| 任何 path 配置变更会**踢掉当前发布者** | 改配置前必须比对哈希，没变绝不调 API | 参考 §4.1 |
| mediamtx 没有 enable/disable，只能删 path | 停用要靠鉴权回调返回 401 + kick | 参考 §4.1 |
| mediamtx 无 camera 实体，只有 path | 设备业务面必须自建 | 参考 §4.1 |
| 批量 API 调用无事务 | 只能幂等重试，不能回滚 | 参考 §6.2 |
| `sourceOnDemand` 下"挂上推理 source = 产生 reader = 开始拉流" | 暂停分析必须卸载 source，不能只在插件里 return | 参考 §6.4 |
| Savant 绑定 NVIDIA 硬件 + DeepStream 版本 | 硬件选型受限，需预留 Pipeless 备选 | 参考 §9.1 |

## 7.2 许可约束

| 组件 | 许可 | 影响 |
| --- | --- | --- |
| mediamtx / gortsplib | MIT | ✅ 可商用 |
| Kerberos Agent | MIT | ✅ 可商用 |
| GoAlert | Apache-2.0 | ✅ 可商用 |
| Savant | 开源 | ✅ 需复核具体条款 |
| **Ultralytics YOLO**（v8/v11，含 -pose） | **AGPL-3.0** | ⚠️ 已决策沿用 YOLO，**须购买 Enterprise License**，见下 |
| YOLOX (Megvii) | Apache-2.0 | ✅ YOLO 家族内的宽松许可选项，作为不购授权时的替代 |
| RTMPose / RTMO (MMPose) | Apache-2.0 | ✅ 姿态备选，COCO 17 点定义与 YOLO-pose 相同，判定算法可直接复用 |
| 人脸识别模型（InsightFace 等） | 视具体模型而定 | ⚠️ 需逐个核对；部分模型权重仅限非商业用途 |

## 7.2.1 模型许可决策（已定，2026-08-01）

**决策：继续使用 YOLO。**

由此产生的必办事项：

| # | 事项 | 时限 | 说明 |
| --- | --- | --- | --- |
| 1 | 购买 **Ultralytics Enterprise License** | **M3 前必须完成** | 本项目是面向付费用户的网络服务，落在 AGPL-3.0 第 13 条（网络交互）覆盖范围。不购授权而严格执行 AGPL，需开源整个服务端 |
| 2 | 授权覆盖范围核对 | 采购时 | 确认覆盖：私有化交付的每个客户实例、边缘盒子内的模型、二次训练产出的权重 |
| 3 | 若采购未获批，启用替代路径 | M3 前 | 检测换 **YOLOX**（Apache-2.0，仍属 YOLO 家族），姿态换 **RTMPose**（Apache-2.0，COCO 17 点，判定算法不用改） |
| 4 | 人脸识别模型许可单独核对 | 启用人脸能力前 | 常见开源人脸模型的权重许可与代码许可可能不一致 |

> 事项 3 是逃生通道，不是默认路径。把它写进文档是为了让"授权没批下来"不至于卡死 M3——迁移代价可控（关键点定义相同）。

## 7.3 合规约束（开工前需法务确认，**阻塞 M3**）

- [ ] 视频/图像证据的最长保存期限
- [ ] 各角色可查看范围的法定边界（家属能看什么、物业能看什么、校方能看什么）
- [ ] 被拍摄者（尤其被监护老人、未成年学生）的知情同意取得方式与留档
- [ ] 公共区域摄像头的告示牌义务
- [ ] 数据出境/第三方云服务使用的限制

**人脸识别专项**（客户已确认将授权使用，但授权 ≠ 合规完成，见 §5.2）：

- [ ] 租户授权书模板（用途、范围、期限、底库来源合法性承诺）
- [ ] 人脸信息的单独同意取得方式（生物识别信息通常需要单独同意，不能与一般隐私政策打包）
- [ ] 底库人员的知情权、查询权、删除权的响应流程与时限
- [ ] **未成年人场景的专项意见**（S2 校园，独立阻塞项）
- [ ] 人脸数据的留存期限（独立于视频证据）
- [ ] 比对日志的留存与查阅权限
- [ ] 客户终止服务时的底库彻底删除义务与证明方式

---

# 8. 待确认问题清单

需要与客户/产品明确的开放问题，**答案会实质改变架构**：

| # | 问题 | 影响 |
| --- | --- | --- |
| Q1 | 首期落地哪一个场景？三个都做还是选一个打穿？ | 决定 M1–M4 的取舍与工期 |
| Q2 | 是私有化交付（一个客户一套）还是 SaaS 多租户？ | 决定多租户隔离深度、计费、升级方式 |
| ~~Q3~~ | ~~单个项目典型规模（路数）与总体目标规模？~~ **已答：默认 16 路，按 32 / 64 / 128 路横向扩展，单站点本阶段上限 128 路。见 §1.3** | ✅ 已闭环 |
| Q4 | 是否已有存量 NVR/平台需要对接（GB/T 28181 国标）？ | 国标接入是独立工作量，需单列 |
| Q5 | 是否必须支持国产化信创环境（海光/鲲鹏 + 昇腾/寒武纪）？ | 决定推理框架能否用 DeepStream/Savant |
| Q6 | 「管理系统」是本项目自研还是对接客户现有系统？ | 决定前端工作量与 API 契约 |
| Q7 | 「App」是自研还是嵌入客户已有 App？推送用什么厂商通道？ | 决定移动端工作量 |
| ~~Q8~~ | ~~是否需要人脸识别（C 类身份判定）？~~ **已答：需要，客户将授权。默认仍以 ReID 为主，人脸用于必须知道"是谁"的需求。见 §5.1–5.3** | ✅ 已闭环 |
| Q8-a | 人脸能力先在**哪个场景**落地？底库规模量级？ | 决定底库存储与比对性能方案 |
| Q8-b | 底库数据由客户提供还是系统现场采集？ | 决定录入模块工作量与合规责任划分 |
| Q9 | 家庭场景是否同步引入毫米波雷达做一级触发？ | 决定 GPU 数量能否降一个数量级 |
| Q10 | 语音呼叫/短信是否有既定供应商？ | 决定投递层对接工作量 |
| Q11 | 事件视频存哪（客户 NAS / 对象存储 / 公有云）？留多久？ | 决定存储成本与合规 |
| Q12 | 验收标准如何定义？准确率/召回率的可接受阈值？ | ⚠️ 必须在合同前定，见 §9 |

---

# 9. 验收期望（需求收集阶段的初步共识）

## 9.1 效果类指标的表述方式

> ⚠️ **不要在合同里承诺"跌倒检测准确率 ≥ 95%"这类数字。** 参考项目已记录的教训：公开数据集（Le2i / UR Fall）全是演员摆拍的表演性跌倒，真实老人多为缓慢滑落、部分遮挡，两者分布完全不同。在拿到现场基线之前，任何准确率承诺都无法验证。

建议表述方式：

| 阶段 | 承诺形式 |
| --- | --- |
| 试点期（M3） | 交付**现场实测基线报告**：真实召回率、每路每天误报数、误报归因分类 |
| 运营期 | 承诺**误报收敛趋势**（如：运营 3 个月后每路每天误报 ≤ N 次）而非绝对准确率 |
| 全程 | 承诺**系统性 SLA**（延迟、可用性、投递成功率），这些是可测可控的 |

## 9.2 系统性 SLA 目标（可承诺，待 M3 实测校准）

| 指标 | 目标 |
| --- | --- |
| 事件发生 → 首次投递 | < 10s |
| 首次投递 → 送达回执 | < 5s（推送）/ < 30s（短信） |
| 全链路无人响应 → 人工介入 | < 3min（S1 场景）/ 按场景配置 |
| 告警丢失率 | 0（持久化后才确认触发） |
| 设备在线率 | ≥ 99%（排除用户侧断网断电） |
| 平台可用性 | ≥ 99.5% |

---

# 10. 下一步

| 动作 | 责任方 | 阻塞什么 |
| --- | --- | --- |
| 回答 §8 剩余问题（Q1–Q7、Q8-a/b、Q9–Q12） | 产品 / 客户 | 需求分析定稿 |
| 采购 3–5 款摄像头做 §6.1 实测 | 硬件 / 交付 | M0 出口、所有接入开发 |
| 法务确认 §7.3 通用五项 | 法务 | M3 上线 |
| **法务确认 §7.3 人脸专项七项 + 出具授权书模板** | 法务 | **人脸能力启用（不阻塞 M3 主线）** |
| **采购 Ultralytics Enterprise License（§7.2.1）** | 采购 / 技术负责人 | **M3 前必须完成，否则走 YOLOX 替代路径** |
| 核对人脸识别模型的权重与代码许可 | 算法 | 人脸能力启用 |
| 三个场景各走访 2–3 个点位 | 产品 | 场景包定义 |

---

> 本文档只负责**收集与澄清**，不做方案裁决。需求的分层、取舍与规格化见《02-需求分析》；技术实现路径见《03-通用场景应用方案》。