📋 YoVision 智能视频事件平台 — 需求收集文档
版本 v0.4 · 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/M5 上线门禁） |
| 现场误报采集 |
试点期真实误报案例库 |
⬜ 待执行（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 不够"。
首期边界（2026-08-03 已定）：S2 校园 MVP 不启用人脸。首个人脸试点最早在 M5，候选为 S4 成人园区的访客/承包商白名单，首库不超过 10,000 人，不用于考勤、课堂分析、未成年人或一般匿名同一性场景，并必须提供等效的非人脸替代方式。
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 合规上线门禁
下列事项不阻塞 M1 的 Sense 技术骨架，但必须在对应真实业务上线前，由客户与法务形成可审计结论：
其中，真实公共安全视频场景进入 M3 生产试点前，必须确认适用法规、告示/备案义务、角色查看范围和最终留存期限。技术默认值不能替代该结论。
人脸识别专项（方向已确认，但授权 ≠ 合规完成，见 §5.2；阻塞 M5 人脸试点上线）：
8. 架构影响型问题决策台账（2026-08-03 已批准）
项目负责人已确认以下产品与技术方向。涉及个人信息和公共安全视频的项目，批准的是架构边界与治理路径；客户/法务仍须在对应上线里程碑前完成专项审查，不能把本表当作法律意见。
| # |
已批准决策 |
状态 / 后续门禁 |
| Q1 |
首期打穿 S2 民办寄宿学校；客户侧 16 路高风险点位，优先越线、危险区域、聚集等匿名安全规则，不启用人脸 |
已关闭；M3 场景基线 |
| Q2 |
客户侧私有化部署优先；tenant_id、RBAC、schema 与租户边界从第一版保留，代码保持 SaaS-ready |
已关闭 |
| Q3 |
默认 16 路，按 32 / 64 / 128 路横向扩展，单站点本阶段上限 128 路 |
已关闭，见 §1.3 |
| Q4 |
M1–M3 只保证 ONVIF/RTSP；售前盘点存量 NVR。GB/T 28181-2022 不进入当前 MVP，客户只能走国标时另建适配任务 |
已关闭；项目级适配任务按需触发 |
| Q5 |
M1–M3 只验证 NVIDIA x86/Jetson + Savant/DeepStream，不承诺信创；保留 ONNX/框架适配边界，信创作为独立硬件 POC 和报价 |
已关闭；目标硬件版本仍由基准任务冻结 |
| Q6 |
自研 Bell 核心管理系统；以版本化 OpenAPI/Webhook 对接客户平台。事件、Alert、ack、升级链、租户和审计以 Bell 为真相源 |
已关闭 |
| Q7 |
M3 不做独立原生 App；交付值班室 Web + 响应式移动 H5，并提供嵌入/API；M4 根据试点反馈再决定原生 App |
已关闭 |
| Q8 |
人脸属于后续可选能力，默认仍以 ReID 为主，只用于必须知道“是谁”的需求 |
已关闭，见 §5.1–5.3 |
| Q8-a |
S2 不启用人脸。首个人脸试点最早 M5，候选为 S4 成人园区访客/承包商白名单，首库 ≤ 10,000 人，且提供非人脸替代 |
架构方向已关闭；法务/客户专项门禁阻塞 M5 人脸上线 |
| Q8-b |
客户作为个人信息处理者负责合法来源、告知和单独同意；YoVision 作为受托处理方提供加密导入/现场录入、有效期、撤回和删除。禁止抓取或购买第三方人脸底库，原图默认不长期留存 |
治理方向已关闭；数据来源与处理流程须由客户/法务在 M5 前签字确认 |
| Q9 |
首期 S2 不使用毫米波雷达；S1 卧室/卫生间的非成像传感器在 M6 实现，Sense 先保留设备型触发接口 |
已关闭 |
| Q10 |
Bell 使用供应商无关的 provider 接口。试点采用本地声光/Web + 一条短信或语音；生产前补齐两条独立路径及故障切换，供应商按客户采购、覆盖和成本选定 |
架构方向已关闭；生产供应商选择仍是交付门禁 |
| Q11 |
事件片段存客户侧 MinIO/S3，常态录像仍在客户 NVR；技术默认 30 天并在目的完成后删除，元数据/审计另设策略，人脸和训练样本独立且更短 |
技术方向已关闭；客户/法务在 M3 前确认法规适用性和最终期限 |
| Q12 |
不承诺统一“准确率 ≥ X%”；M3 至少 dry-run 2 周，冻结现场标注集，按规则报告召回率和每路每天误报数，数字阈值在基线后写入站点验收附件；系统 SLA 独立验收 |
验收方法已关闭；站点阈值由客户在基线后签署 |
9. 验收期望（需求收集阶段的初步共识）
9.1 效果类指标的表述方式
⚠️ 不要在合同里承诺"跌倒检测准确率 ≥ 95%"这类数字。 参考项目已记录的教训：公开数据集（Le2i / UR Fall）全是演员摆拍的表演性跌倒，真实老人多为缓慢滑落、部分遮挡，两者分布完全不同。在拿到现场基线之前，任何准确率承诺都无法验证。
建议表述方式：
| 阶段 |
承诺形式 |
| 试点期（M3） |
交付现场实测基线报告：真实召回率、每路每天误报数、误报归因分类 |
| 运营期 |
承诺误报收敛趋势（如：运营 3 个月后每路每天误报 ≤ N 次）而非绝对准确率 |
| 全程 |
承诺系统性 SLA（延迟、可用性、投递成功率），这些是可测可控的 |
M3 试点必须先进入不少于 2 周的 dry-run：冻结站点、机位、规则版本与人工标注口径，形成现场标注集；按每条规则分别计算召回率与每路每天误报数。只有基线报告评审后，客户与项目方才在站点验收附件中签署数值阈值，不将一个场景的阈值直接复制到另一场景。
9.2 系统性 SLA 目标（可承诺，待 M3 实测校准）
| 指标 |
目标 |
| 事件发生 → 首次投递 |
< 10s |
| 首次投递 → 送达回执 |
< 5s（推送）/ < 30s（短信） |
| 全链路无人响应 → 人工介入 |
< 3min（S1 场景）/ 按场景配置 |
| 告警丢失率 |
0（持久化后才确认触发） |
| 设备在线率 |
≥ 99%（排除用户侧断网断电） |
| 平台可用性 |
≥ 99.5% |
10. 下一步
| 动作 |
责任方 |
阻塞什么 |
| 按 §8 已批准决策拆解里程碑与任务，并持续跟踪下游门禁 |
产品 / 技术负责人 |
M1–M6 范围控制 |
| 采购 3–5 款摄像头做 §6.1 实测 |
硬件 / 交付 |
M0 出口、所有接入开发 |
| 客户/法务确认 §7.3 通用五项及公共安全视频法规适用性 |
客户 / 法务 |
M3 真实生产试点上线 |
| 法务确认 §7.3 人脸专项七项 + 出具授权书模板 |
法务 |
人脸能力启用（不阻塞 M3 主线） |
| 采购 Ultralytics Enterprise License（§7.2.1） |
采购 / 技术负责人 |
M3 前必须完成，否则走 YOLOX 替代路径 |
| 核对人脸识别模型的权重与代码许可 |
算法 |
人脸能力启用 |
| 三个场景各走访 2–3 个点位 |
产品 |
场景包定义 |
本文档负责记录需求来源、澄清结果和已批准边界。需求的分层与规格化见《02-需求分析》；技术实现路径见《03-通用场景应用方案》。
