适用前提
本规划按以下假设制定：
- 场景是中国大陆室内泳馆
- 朋友所在泳馆可作为第一试点
- 产品定位是辅助救生员预警
- 不是替代救生员，不自动判责
- 预算有限，不追求第一期覆盖每条泳道的极致方案
- 可接受少量水下摄像头
试点目标
第一期目标不是“完美识别所有溺水”，而是：
- 对若干明确定义的高风险场景做辅助报警
- 缩短救生员从“事件发生”到“注意到异常”的时间
- 降低救生员因分心、视角盲区、密集人流造成的漏看概率
- 建立可复盘的数据闭环
可选扩展目标
如果朋友特别在意“救生员玩手机 / 低头分心”这类问题，可以把它定义为第二阶段可选能力，但不建议作为第一期主目标。
原因：
- 它涉及人员管理和现场敏感性
- 容易引发内部抵触
- 即使做了，也不能替代对池内泳者本身的检测
更合理的做法是：
- 第一阶段先把“泳者异常发现”做起来
- 第二阶段再考虑“岗台在位 / 长时间低头 / 空岗提醒”等轻量提示功能
第一版建议的能力边界
建议纳入第一期的事件
- 深水区长时间未上浮
- 水下静止或沉底异常停留
- 长时间低位无明显位移
- 特定高风险区域异常停留
- 救生员确认后标记为真实异常的事件
暂不建议第一期承诺的能力
- 所有泳姿 / 所有玩闹动作的精准区分
- 无人值守自动救生
- 替代人工责任
- 一套模型直接适配所有泳馆
检测策略建议
方案 A：上方机位为主，水下机位补强
这是最推荐的试点方案。
为什么
- 上方机位更适合全池覆盖和多人跟踪
- 水下机位更适合发现沉底、长时间静止和深水盲区问题
- 两者结合，比单纯“只看静止”更靠谱
基本思路
- 上方机位持续跟踪池中泳者
- 估计每个泳者的位置、速度、轨迹和停留时间
- 在深水区和重点区域叠加水下机位识别
- 用规则引擎把多种弱信号合成为一个风险评分
- 分级触发报警
为什么不建议只靠“水下静止检测”
因为这样容易漏掉：
- 还没完全沉底但已经失去有效运动的泳者
- 被他人短暂遮挡的异常
- 上方已经可见异常但水下还未形成静止的情况
更稳妥的方式是：
- 上方看全局
- 水下看关键区域和深水异常
- 规则引擎综合判断
第一版机位建议
保守版
- 上方摄像头：2 到 3 路
- 水下摄像头：0 到 1 路
- 适合先做影子模式验证
推荐版
- 上方摄像头：3 到 4 路
- 水下摄像头：1 到 2 路
- 适合单馆试点
不建议第一期
- 每条泳道都配独立水下摄像头
- 大规模多池区同时上线
- 同时做跨馆平台化
第一版设备建议
摄像头
- 支持 RTSP 的网络摄像头
- 上方机位优先考虑固定枪机或半球机
- 水下机位需满足长期浸水、低照度和抗眩光要求
边缘计算
第一期不要优先考虑 Jetson 开发板量产化。
更实用的选择是：
- 一台本地 GPU 工作站或工业边缘服务器
- 有独立显卡和稳定散热
- 能放在馆内机房或弱电间
原因：
- 开发更快
- 调试方便
- 后续模型更替更灵活
软件架构建议
1. 视频接入层
- RTSP 拉流
- 视频缓存
- 录像切片
- 时间同步
可用组件：
- FFmpeg
- GStreamer
- OpenCV
2. 主检测层
职责：
- 人体 / 头部检测
- 目标跟踪
- 区域定位
- 水下静止检测
推荐方向：
- YOLO / RT-DETR 一类检测器
- ByteTrack / BoT-SORT 一类跟踪器
- 需要时加入 pose 模型辅助判断
3. 规则引擎
核心不是“模型一句话说危险”，而是多规则叠加：
- 在深水区停留超过阈值
- 水下持续静止超过阈值
- 上方轨迹长时间低速 / 无位移
- 与正常泳姿或正常游动模式偏差过大
- 同时满足多个条件时提升报警等级
4. 告警与联动层
- 大屏弹窗
- 值班电脑提示
- 手机 Web 通知或企业微信 / 钉钉
- 声光告警
5. 复盘与标注层
- 自动保存报警前后片段
- 人工标记真阳性 / 假阳性
- 每周回看并调整阈值
国内模型在这个试点里的合理位置
可作为辅助层的国内模型
- Kimi K2.5
- 智谱 GLM 视觉模型
- 阿里云百炼 Qwen 视觉理解
- 火山方舟视频理解
适合做什么
- 报警后自动生成事件摘要
- 对报警片段做自然语言解释
- 管理员用自然语言检索录像
- 辅助分析误报原因
不适合做什么
- 直接接管主实时告警
- 替代 CV 跟踪与规则链路
- 在没有现场标定的情况下直接给生死级结论
详细实施阶段
阶段 0：现场勘查
- 确认池深、池型、照明、反光、水面遮挡
- 标出高风险区域
- 清点现有摄像头与新增机位可能性
- 明确救生员当前值守流程
交付物：
- 机位草图
- 高风险区域图
- 现有网络与机房条件说明
阶段 1：离线验证
- 收集历史录像与演练视频
- 跑通视频接入和初版检测
- 不上线真实告警，只做后台验证
交付物：
- 离线检测报告
- 初版误报样例集
- 第一版规则阈值
阶段 2：影子模式
- 系统后台持续跑
- 不直接打扰救生员
- 仅记录报警结果并人工复盘
目标：
- 确认误报率
- 找出最常见误报来源
阶段 3：软告警试点
- 启用低等级告警
- 先推给管理端或值班端
- 不用高强度声光联动
目标：
- 观察救生员是否愿意使用
- 观察是否能真正缩短发现时间
阶段 4：正式试点
- 对有限场景启用正式辅助告警
- 建立每日 / 每周复盘机制
- 评估是否值得扩展机位
试点验收指标建议
必看指标
- 报警延迟
- 每小时误报数
- 高风险事件召回率
- 设备在线率
- 救生员接受度
推荐目标
- 关键报警延迟控制在 5 到 10 秒内
- 误报率降到救生员可接受范围
- 每周能复盘并优化阈值
推荐的第一期预算拆法
馆内最小验证版
- 预计总额：5 万到 15 万
构成：
- 一台本地推理主机
- 少量开发与集成
- 复用现有上方摄像头
- 小范围影子模式
推荐单馆试点版
- 预计总额：15 万到 40 万
构成：
- 3 到 4 路上方机位
- 1 到 2 路水下机位
- 一台本地边缘服务器
- 告警界面和复盘后台
- 安装、调试与试点支持
试点时最容易踩的坑
- 一开始就想识别所有异常动作
- 没有先定义“哪些事件算有效报警”
- 没有留影像和人工复盘机制
- 没有把救生员使用反馈纳入迭代
- 过早把通用大模型放到主链路
对你朋友最实用的下一步
- 画出本馆泳池平面图和现有机位图
- 标出深水区、盲区和最容易漏看的区域
- 明确是否允许新增 1 到 2 路水下摄像头
- 找一个能做 CV 与边缘部署的技术合作方
- 先按“影子模式”跑第一版，不要直接上正式报警
关键来源
- Poseidon: https://poseidon-tech.com/
- SAFE SWIM 技术页: https://www.safeswim.io/tech
- 三体云动智能泳池防溺系统: https://www.styd.cn/site/aiot/products/swimming-pool.html
- 水滴智店防溺方案: https://zd.drip.im/solution/antidrown
- Kimi K2.5: https://platform.moonshot.cn/docs/guide/kimi-k2-5-quickstart
- 智谱模型概览: https://docs.bigmodel.cn/cn/guide/start/model-overview
- 阿里云百炼视觉理解: https://help.aliyun.com/zh/model-studio/vision/