yovision/docs/01-vision.md

# 项目愿景

## 愿景

让家庭、学校和社区现有的视频设备从“只能事后翻录像”升级为“异常发生时自动形成证据，并可靠地追到人确认处理”的安全基础设施。

## 目标用户

- 预警接收与处置者：家属、学校安保、物业值班员。
- 运营与管理者：养老机构、学校、街道/社区、物业管理方。
- 实施与运维：负责批量开通、设备健康、容量与故障处理的团队。
- 算法团队：使用真实且合规的误报反馈迭代模型。
- 数据主体：老人、学生和居民；产品必须保护其隐私和知情权。

## 产品形态

YoVision 不是单机 NVR 的换皮，而是“通用底座 + 场景包”：

- 通用底座负责设备、媒体、推理、事件、预警、租户、权限、审计与可观测。
- 场景包只装规则模板、升级策略、话术和报表口径，不复制通用代码。
- 三个独立系统通过明确契约协作：Sense 供流与信号，Brain 产出事件，Bell 消费事件并追到人。
- 首期以一个客户一套的私有化实例交付；租户标识、RBAC、schema 和集成契约仍按 SaaS-ready 边界设计，避免后续区级统采时重构。

## MVP

MVP 在 **S2 民办寄宿学校**中，以客户侧 16 路高风险点位跑通：

`设备接入 → 稳定供流 → 推理/规则 → 事件与证据 → 预警投递 → ack/升级 → 误报反馈`

首期只交付越线、危险区域、聚集等匿名安全规则，不启用人脸。M0–M2 建 ONVIF/RTSP 接入基础，M3 形成首个端到端 MVP；先用民办学校形成样板，再评估公办统采。

## 产品原则

1. **事件闭环优先于功能数量**：没有 ack、升级和处置证据的“发消息”不算预警系统。
2. **隐私最小化**：家庭场景平时不上传；私密区域不用摄像头；用户只看有权限且与事件关联的证据。
3. **配置承载场景差异**：场景变化不应向下穿透到媒体和接入层。
4. **默认可交付、扩展不推倒**：默认 16 路先做稳，128 路通过分片扩展，不靠硬编码和单机堆料。
5. **模型输出观测，规则作业务判定**：模型、规则和告警生命周期独立演进。
6. **真实反馈是产品飞轮**：误报反馈从 M3 第一天进入闭环。
7. **可恢复优先**：断线重连、断网补传、先落库再投递、对账收敛都是基础能力。

## 非目标

- M0 不产出可上线的生产 NVR，不接入真实住户或学校摄像头。
- M1 不同时开发 Brain、Bell 和完整管理端。
- 本期不实现高空抛物专用算法；建议独立立项或外采。
- M4 前不投入工厂/园区场景包，只验证架构可扩展性。
- 人脸识别不是默认能力，不得替代匿名 ReID；没有租户授权和合规前置条件时不可见、不可用。
- M1–M3 不交付 GB/T 28181、信创硬件适配或独立原生 App；这些能力按独立任务和里程碑评估。
- 不承诺单进程、单机或单 GPU 承载 128 路。

## 成功标准

- M3：S2 民办寄宿学校默认 16 路端到端稳定运行，至少三类匿名安全规则可用，首次预警与 ack/升级可观察，误报数据开始回流。
- M5：128 路横向扩展不修改业务代码；第二、第三场景通过纯配置交付。
- 新场景需要修改 L1–L4 通用底座代码时，视为架构验收失败，需要先复盘分层。

详细来源：[`raw/01-需求收集.md`](raw/01-需求收集.md)、[`raw/02-需求分析.md`](raw/02-需求分析.md)、[`raw/03-通用场景应用方案.md`](raw/03-通用场景应用方案.md)。