Car #1 Truck #2 Ped #3 Zone A
计算机视觉
在交管场景的应用
从一个路口摄像头到一套可部署平台——完整实战方法论
🔍 案例载体：traffic_counter ⏱ 75 分钟（60 讲授 + 15 互动） 👥 架构师 & 项目经理 🎤 贵州大数据集团政企事业部 · 林星宇
📍 课程路线图
五站到达
🔍
需求挖掘
需求从哪来
怎么"挖"出来
💼 PM 核心
📐
需求分析
四象限拆解
数据流设计
🔧 架构师
⚡
MVP 验证
3 天交付
让客户说"就是它"
🔧 深潜
🏗
产品化
安全/监控/部署
从 Demo 到产品
🔧 深潜
🚀
垂直产品
行业复制
从项目到公司
💼 全员
🔧 架构师关注
系统设计 Trade-off · 性能优化 · 架构演进 · 算法实现
💼 项目经理关注
需求拆解方法 · MVP 策略 · 交付节奏 · 风险控制
模块一 · 需求挖掘
交警在愁什么？
从"交警话"到"技术话"
👁 看不见 数据盲区
关键路口缺少流量监控，决策凭"感觉"
🔢 数不清 人工不可靠
每天站 2 小时人工数车，误差大、成本高
🔄 管不过来 缺优化依据
信号灯配时无数据支撑，月报手写
🌐 技术翻译四步法 PM 核心
🗣 交警原话→ 技术方案
"这条路堵不堵？"实时车流量检测 + 拥堵指数
"周五晚高峰哪方向车多？"历史统计 + 方向性计数
"能跟现有系统对接吗？"开放 API + HMAC 签名
听懂业务 → 还原场景 → 映射技术 → 提出方案
模块一 · 需求挖掘
需求不是等来的，是"挖"出来的
🗺 方法一：场景还原法
跟着交警走一天

跟岗观察 → 记录数据需求 → 识别缺口 → 提方案

📖 项目故事 发现高空鹰眼视角 → 俯瞰检测精度远超路侧
💡 最好的需求是看出来的
🔄 方法二：替代发现法
找到他们已经在用的"笨办法"

人工计数 → Excel → 手写报告
海康平台"只能看不能数" → 接入 API + 叠加检测

💡 边界条件 = 护城河
💡 不要创造新需求，替代低效方案
❓ 方法三：边界探索法
"如果...会怎样？"

"10 个路口同时看？"
→ 多路并行 + GPU/CPU 调度
"摄像头断了？"
→ 自动重连 + 帧缓存降级
"第三方接入？"
→ 开放 API + 双轨认证
💡 边界条件决定玩具还是产品
模块一 · 需求挖掘
动手前，四个必须问
📹
数据源
摄像头什么型号？
什么视角？
有 RTSP 地址吗？
→ 检测可行性
🎯
准确率
可接受误差？
置信度阈值？
召回率要求？
→ 模型选型
⚡
实时性
多快出结果？
延迟容忍度？
并发路数？
→ 推理架构
🔗
集成方式
对接什么系统？
什么数据格式？
谁来付费？
→ API 设计
📖 项目教训 踩坑经历
没问 RTSP 格式 → 到现场发现海康需 AK/SK 签名取流 → 紧急开发 hikvision_client.py
模块二 · 需求分析方法论
拿到需求，先画四个象限
低复杂度 ← → 高复杂度
高价值
低价值
📋 计划做
多路并行
API 开放
GPU/CPU 调度
✅ 立即做
单路口实时
车流量检测
简单 Web 展示
⏭ 不做
车牌识别
(用海康即可)
➕ 顺带做
车型分类
统计导出
方法论 PM 核心
业务价值 × 技术复杂度

• 高价值+低复杂度 → 立即做（MVP 核心）
• 高价值+高复杂度 → 计划做（产品化）
• 低价值+低复杂度 → 顺带做
• 低价值+高复杂度 → 不做
💡 核心价值
让技术决策可讨论、可说服、可对齐
模块二 · 需求分析方法论
一帧画面经历了什么？
DetectionEngine._process_frame() — 单帧 7 步管线
🔍
1
YOLOv8 检测
→
🔗
2
ByteTrack 跟踪
→
📊
3
区域计数
→
🎨
4
视频渲染
→
📡
5
RTMP 推流
→
💾
6
Redis 帧缓存
→
推送
7
状态推送
🖥 双进程架构 Trade-off
Python GIL → 单进程无法同时高效处理 HTTP + GPU 推理

方案 C ✅ API 进程 + 检测进程 + Redis 通信
代价：多进程部署复杂度 + 需心跳检测 + 自动恢复
💡 关键洞察
架构师：7 步管线 = 性能优化主战场
项目经理：7 步 = 工时估算基础

每步可独立优化、可替换 → 模块化设计的价值
模块二 · 需求分析方法论
数据从哪来到哪去？
📹 RTSP 拉流
→
🔍 7步管线
→
📊 PostgreSQL
→
⚡ Redis
→
📈 Dashboard
关键技术选型决策
选型为什么？
PG over MySQLJSONB 灵活配置存储
Redis 必须帧缓存毫秒级 + Pub/Sub 即时
WebSocket大屏实时更新，轮询不可接受
配置三级体系默认值 < YAML < 环境变量 < DB
📋 交付物清单 70% 够了
01
功能清单 + 优先级标签
02
架构草图（核心模块 + 数据流）
03
技术选型表（为什么 + Trade-off）
04
API 草案（Request/Response）
05
数据模型草图（实体 + 关系）
模块三 · MVP 快速验证
MVP 不是"半成品"，是"最大价值品"
✅ MVP 做什么
• 单路口实时车流量检测
• 简单 Web 页面展示计数
• 一段 3 分钟演示视频
❌ MVP 不做什么
• 多路并行检测
• API 开放平台
• 车型分类 / 行人检测
• 可视化大屏
🎯 成功标准
客户说 "这就是我要的" 而非 "还差得远"
🔧 技术选型矩阵
原则：熟悉 > 先进，能用 > 最优
组件选型理由
检测模型YOLOv8x开箱即用 COCO 80 类
后端FastAPI自动文档 + 异步
前端React+AntD快速搭建后台
数据库SQLite→PG先验证再迁移
部署本地→Docker先跑通再容器化
模块三 · MVP 快速验证
Day 1-3 作战计划
D1
检测跑通
Day 1
上午
YOLOv8 模型加载
单张图片检测验证

下午
RTSP 拉流
逐帧检测 + 控制台输出

🏁 终端看到每帧检测结果
D2
计数 + 展示
Day 2
上午
ByteTracker 跟踪
区域判定计数

下午
FastAPI 最小 API
简单前端页面

🏁 Web 实时显示车流量
D3
打磨 + 演示
Day 3
上午
视频渲染
叠加检测框和计数
Bug 修复

下午
录制演示视频
准备演示话术

🏁 3 分钟演示视频
💡 提前反馈原则 📖 项目故事
Day 2 下午前端刚能显示数字就发给客户看了 —— 客户说"方向对了"。半成品也能确认方向，不要等产品完美再给客户看。
🔧 技术深潜 · tracker.py
一帧画面里的目标怎么"跟住"的？
自研 IoU 跟踪器（非 SORT/DeepSORT）· 多目标同向直行 · 遮挡恢复 · 轨迹生命周期管理
Frame #0
CAM-01 | 1920x1080 | 25fps
小车 货车 摩托车
① 匈牙利最优匹配
scipy 匈牙利算法
高置信框 vs 已有轨迹
IoU 最优分配
② 贪心补充匹配
低置信度框补充
未匹配的轨迹
覆盖遮挡场景
③ 新轨迹创建
仍未匹配的框
创建新轨迹
分配唯一 Track ID
💡 类比：给每辆车贴一个隐形编号——即使被大车挡住一会儿，回来后还能认出它 · 轨迹 age > 30 帧未匹配则删除
🔧 技术深潜 · InferenceScheduler + TrafficCounter
GPU 爆了怎么办？
怎么判断车"过了线"？
🖥 GPU/CPU 双设备调度
🎮
GPU
显存 45% · 推理中
⇄
🖥
CPU
负载 10% · 待命
💡 同步调用无队列 → 零排队延迟 · 显存>85% 或负载>95% → 自动漂移
📍 区域判定计数
标定区域 Zone A
进入: 0 离开: 0
Shapely Polygon 质心判定 · 批量写入回调避免逐条 INSERT · 渲染器内置 3 个几何算法
模块三 · MVP 快速验证
怎么让 Demo "炸场"？
五条黄金法则 PM 核心
🎬
场景代入
先展示痛点
人工数车视频
再展示系统
⚡
即时反馈
摄像头打开
3 秒内出结果
预加载模型
👆
互动操作
客户自己画区域
看计数变化
参与感拉满
📊
数据对比
自动 vs 人工
计数结果对比
数字说话
🎁
预留惊喜
"顺便"展示
车型分类
超出预期
💡 演示成功标准
客户说 "什么时候能上线？" 而不是 "没出 bug"。
演示不是技术展示，是信任建立。
模块四 · MVP 到产品化
"能跑"和"能卖"之间
差了什么？
维度🧪 Demo🚀 产品
数据SQLite/内存PG + Redis
部署本地运行Docker Compose
安全无认证JWT + HMAC
监控看日志Dashboard + 告警
扩展单路多路并行 + 调度
接口硬编码RESTful + 文档
运维手动重启心跳 + 热更新
⚠ 产品化工作量通常是 MVP 的 5-10 倍
💾 数据三级聚合 4 线程
L0 实时 — Redis 缓存，毫秒级
L1 批量 — flush 线程每秒写入 PG
L2 聚合 — API 按小时/天/周查询
4 线程：flush(1s) · consume(Redis→PG) · reload(30s) · heartbeat(5s)
模块四 · 安全与开放
一套系统两类用户
🔐 双轨认证 deps.py + gateway.py
/admin/v1/* JWT
员工工牌
刷卡进门
Web 后台管理
/open/v1/* HMAC
银行转账
密码+签名
第三方 API 接入
HMAC：参数字典序排序 → 拼接 → AppSecret 签名 → 附加请求头
🚪 OpenAPI 自动镜像 mirror.py
Admin 路由
→
inspect 分析
→
JWT→API Key
→
Open 路由
零重复代码，admin 新增功能自动同步到 open
🛡 API 网关
请求日志（环形缓冲区 2000 条）· 流量统计 · 限流器 · 端点管控 · 调用统计（60s 批量写入）
网关能力 = 对外收费基础
模块四 · 运行时保障
让系统"活着且稳定"
🔄 热更新
Redis 即时信号
30s 周期重载
参数 diff 对比
三层保障 → 配置变更零丢失

不停机改参数
手机 OTA 式体验

detector.update_params()
💓 进程生命周期
subprocess.Popen 启动
5s 心跳监听
超时自动重启
平滑重启：Redis 信号 → 热加载
硬重启：kill + 重启

进程隔离 → 一个崩溃不影响其他
🛡 防呆设计
30s 冷却倒计时
+ 二次确认（Popconfirm）
= 双重保险

ATM "请勿重复操作"
20 行代码避免无数事故
模块四 · 可视化
让数据"看得见"
大屏不是堆图表，让不同角色一眼看到各自关心的信息
🔧 运维侧（左/上）
• CPU/内存趋势 6h, 5s 轮询
• GPU 趋势 多 GPU 分色, 30s
• 检测流实时状态表格 FPS/推理ms/丢帧率
📊 业务侧（右/下）
• 今日车流量趋势 按小时柱状图
• 车型分布 环形图
• 区域流量分布 分组柱状图
📈 刷新策略差异化
系统资源 5s(高频) · 业务数据 30s(中频) · 历史 按需(低频)
WebSocket 实时推送，非轮询
驾驶舱 — 物体检测与计数平台 CPU 23% 内存 4.2G 检测作业 3/5 今日流量 12,847 CPU/内存趋势 今日车流量趋势 车型分布 区域流量 GPU 状态 GPU0: 62°C 显存: 4.2/8 GB
模块五 · 垂直产品打造
从"一个方案"到"无限方案"
抽象的力量 —— 当检测参数不再是硬编码，系统就从"项目"变成了"产品"
📋 DetectionPlan 检测方案
模型路径
yolov8x.pt
置信度
0.5
检测类别
COCO 80 类可选
推理设备
GPU0 / GPU1 / CPU
• 一个方案绑定多个监控
• 一个监控可并行多个方案
• 标签关联，插件通过标签名匹配
🧩 插件系统
🚗
车流统计
车辆类别 + 方向性统计
🚶
行人计数
越线计数 + 区域计数
扩展：复制目录 → 修改 index.ts → 注册 → 自动菜单
🏷 标签体系
TagCategory → MonitorTag → 绑定
监控筛选 · 检测类型定义 · 插件匹配 · 批量操作
模块五 · 垂直产品打造
从一个路口到多个行业
📈 产品演进路线
V1.0
交管专用 — 路口车流量检测
V2.0
通用平台 — 场景无关的检测计数平台
V3.0
多行业垂直 — 插件 + 标签 + 方案适配
💡 核心公式
核心通用 + 边界可配
= 开发成本随复制次数递减
行业检测对象特殊需求复用度
🚦 交管车辆/行人方向统计·信号联动 90%
🏙 城管违停/占道事件检测·告警 70%
🏠 社区人员/车辆访客管理·黑名单 60%
🏭 园区人流/安全帽密度热力·合规检测 50%
可复制核心：检测管线 + 跟踪器 + 计数器 + API 网关 + 插件系统
需定制：检测类别 + 计数规则 + 业务逻辑 + 前端展示
五步法总结
从需求到垂直产品
🔍
需求挖掘
场景还原
替代发现
边界探索
📐
需求分析
四象限拆解
数据流设计
架构 Trade-off
⚡
MVP 验证
聚焦核心
3 天交付
演示五法则
🏗
产品化
安全/监控/部署
进程管理
热更新
🚀
垂直产品
方案抽象
插件系统
行业复制
这套方法论不限于交管、不限于 CV
任何"从 0 到 1 到 N"的技术产品都可以用
感谢聆听 · 欢迎交流
1 / 20
跳转至指定页