03 核心判断

技术可行性评估

回答“这个馆现在能不能做试点，以及该怎么定义可行”。

返回首页 下载 PDF
查看本项目全部研究文档

结论先行

结论分三层：

  1. 做“馆内辅助预警试点”是可行的。 在单一室内泳池、有限机位、明确值守流程的前提下，可以做出能持续监控、发现异常并推送预警的系统。
  2. 做“稳定商用版”难度明显更高。 难点不在于“有没有模型”，而在于误报、漏报、场景泛化、设备安装、责任边界和长期运维。
  3. 你朋友并不是“完全没有资源”。 他有真实泳馆和真实使用场景，这使得“做内部试点”比“凭空创业”更现实；但仍然不适合单独从零做完整产品。

为什么说“能做”

当前技术已经具备以下构件：

  • 摄像头视频流实时接入
  • 边缘端或云端的视频分析
  • 目标检测、人体姿态估计、跨帧跟踪、事件规则引擎
  • 实时告警、录像回放、报警位置提示、通知联动

现有产品也证明了市场上已经存在可部署方案，而不是纯论文概念：

  • Poseidon 面向公共泳池，区分浅水池和深水池，浅水采用上方监控，深水采用水下摄像头，并宣称 10 秒内报警。
  • SAFE SWIM 面向有救生员的泳池与开放水域，强调 AI 识别、跨视角追踪和多重预警。
  • 国内也已有杨浦体育活动中心、三体云动、“安全眼”等案例，说明中国市场并非空白。

为什么说“不能太乐观”

1. 这不是通用大模型的标准强项

OpenAI Realtime API 官方文档当前明确写的是低延迟语音交互，输入输出核心是音频、图像、文本；gpt-realtime 模型页也明确标注 Video: Not supported。这意味着它不适合直接充当“高帧率泳池监控主引擎”。

Google Gemini Live API 官方文档虽然支持实时语音与视觉，但技术规格里写的是输入模态为音频、JPEG <= 1FPS 的图像和文本。这个边界更像“低频视觉流交互”，不是标准安防级视频检测引擎。

阿里云百炼的视觉理解文档支持图像与视频理解，并允许通过 fps 参数控制视频抽帧，默认值是 2.0。Moonshot Kimi K2.5 官方文档也给出了视频理解 video_url 示例，并列出支持的视频格式。智谱官方文档则明确列出了视频、图像、文本输入的视觉模型和实时音视频模型。这些都说明国内平台的多模态能力已经足够强，但它们提供的是模型能力，不是已经调好规则和流程的泳馆防溺产品。

2. 溺水场景是低频、高风险、容错极低

  • 漏报可能直接导致严重事故
  • 误报太多会让救生员疲劳，最终把系统静音
  • 泳池反光、水花、遮挡、多人并行活动、儿童玩闹、潜水训练都会制造困难样本
  • 真正危险事件很少发生，导致数据极度不平衡

3. 馆内试点同样依赖场地适配

同一个模型在不同泳池很可能表现差异很大，变量包括：

  • 池深与池型
  • 室内光线
  • 摄像头高度、角度、畸变
  • 是否存在训练区、儿童区、盲区
  • 人流密度
  • 是否允许水下摄像头

因此，真正能落地的系统通常都不是“一个通用模型卖全国”，而是“基础算法 + 场地标定 + 规则调优 + 值守流程”的组合。

你朋友这个场景下，最合理的目标是什么

不是一上来做“全行业通用产品”，而是：

  • 在自己所在室内泳馆先做辅助预警试点
  • 明确对外口径是“辅助救生员提高发现效率”
  • 先验证在本馆内是否能稳定识别几类高风险事件
  • 在可接受预算内，证明系统能减少漏看、分心和响应迟缓

这种系统到底怎么监测

用户最常见的误解是：系统是不是只看“静止不动的人”。

更准确的答案是：成熟方案通常是混合策略，不是单一规则。

常见的三类检测思路

  1. 全池跟踪型 从上方摄像头持续跟踪池内每个可见泳者，估计其位置、速度、轨迹、头部出水情况和姿态变化，再用规则判断风险。
  2. 重点区域型 只对深水区、转身区、跳台附近、教练盲区等高风险区域做重点监测。
  3. 水下静止 / 底部停留型 通过水下摄像头监测底部长时间静止、异常沉底、姿态异常等信号。

第一版试点最推荐的方式

对你朋友的馆内场景，推荐：

  • 上方机位做全池跟踪
  • 水下机位做深水区或盲区补强
  • 规则引擎综合判断，不靠单一“静止”条件

也就是说，它既不是“只看水下静止”，也不是“必须精确理解每个动作的全部语义”，而是：

跟踪 + 姿态 / 轨迹特征 + 区域规则 + 时间阈值 + 人工确认

更适合你朋友的技术路线

推荐路线：馆内边缘部署 + 少量国内多模态模型做辅助

主链路：

  • RTSP 摄像头接入
  • 本地边缘计算设备
  • CV 模型做检测、跟踪、姿态 / 目标理解
  • 事件规则引擎触发报警
  • 本地大屏 / 手机 / 手表 / 声光提醒给救生员

辅助链路：

  • Kimi / GLM / Qwen 这类国内多模态模型
  • 用于录像摘要、事件复盘、报警解释、管理后台检索

这样的好处是：

  • 主检测不依赖外网
  • 本馆试点更可控
  • 国内模型可以补齐“看懂录像”和“生成人话解释”的能力

真正可落地的技术路线

路线 A：专用 CV + 规则引擎 + 人工复核

这是目前最现实的路线。

组成一般是：

  • 固定机位摄像头
  • 边缘计算盒或本地服务器
  • 人体检测 / 姿态估计 / 跟踪模型
  • 时间维度规则
  • 报警界面和通知系统
  • 救生员人工确认与处置

优点：

  • 延迟和带宽可控
  • 数据留在本地更利于隐私控制
  • 适合持续跑 24/7

缺点：

  • 需要算法调优和现场实施
  • 初期误报治理成本高
  • 对工程团队要求高

路线 B：云端视频 AI 作为原型或辅助

Google Cloud Video Intelligence Streaming API 官方文档显示，它支持 RTSP、RTMP、HLS 等协议接入，并支持实时标签、对象检测与跟踪，但页面仍标注 Beta / Pre-GA。这类能力更适合：

  • 做原型验证
  • 做后台辅助分析
  • 做非强实时的事件检索或回放分析

不适合直接承担高风险场景的唯一告警责任。

路线 C：通用多模态模型作为辅助层

通用模型适合做：

  • 事件摘要
  • 录像回顾说明
  • 报警解释
  • 运营报表
  • 管理后台自然语言问答

不适合做：

  • 作为唯一的主检测引擎
  • 在没有专用规则和人工复核的情况下直接决定生死级报警

最小可行产品（MVP）应该长什么样

推荐 MVP 目标

不是“全面替代救生员”，而是：

  • 在单馆单池稳定运行
  • 对明确定义的高风险事件给出辅助预警
  • 把报警位置和回放片段推给救生员
  • 保证系统留痕，便于复盘

推荐 MVP 能力边界

  • 单池
  • 2 到 6 个机位
  • 有明确值守救生员
  • 只做辅助报警，不做自动处置
  • 对“长时间静止 / 头部长时间没出水 / 姿态异常 / 区域越界”等少量规则先做验证

当前最容易被误解的点

  1. “有视频理解模型”不等于“有商用防溺系统”。
  2. “能识别视频事件”不等于“能承诺安全级实时告警”。
  3. “边缘盒子 + 摄像头”不等于“产品就能交付”，还差标定、测试、流程和售后。
  4. “自己有一个泳馆能试”不等于“已经具备做产品公司的能力”。

对你朋友的现实判断

在你补充的新前提下，判断需要调整：

  • 不建议他直接做创业公司
  • 建议他先做馆内内部试点
  • 建议定位为辅助预警，而不是替代救生员
  • 建议优先找懂 CV 和边缘部署的技术合作方，而不是先找大模型厂商

关键来源