车辆流量统计项目：先跑通“假闭环”，再替换真模型

车辆流量统计项目：先跑通“假闭环”，再替换真模型

项目背景：无人机视频车辆流量统计（含方向），技术路线为 检测 → IOU 跟踪 → 虚拟断面计数 → 评测 → 部署，PRD v1.0 已冻结。本文回答两件事：问题定义做到什么程度了，以及推荐的高效执行顺序。

一、问题定义做好了吗？——基本完成，还差最后一块拼图

先说结论：问题定义的 90% 已经完成，具体到 PRD v1.0 已经冻结：

问题定义要素	状态
做什么（唯一业务目标）	✅ 车辆流量统计（含方向）
不做什么（非目标清单）	✅ 速度/密度/拥堵/多光谱/车型分类
输入输出规格	✅ 视频输入、事件 JSON 输出
评测指标与验收线	✅ MAPE ≤ 15%、漏计率 ≤ 10%、重复计率 ≤ 5%、方向准确率 ≥ 95%
技术路线	✅ 检测 → IOU 跟踪 → 虚拟断面计数 → 评测 → 部署
完成定义（DoD）	✅ 7 条
里程碑	✅ W1–W8

但严格来说还差 10%，这 10% 恰好是整个项目第一个关键决策点——数据审计。 PRD 里留了两个开放问题（O-1、O-6），它们的答案会改变技术选型：

待审计问题	影响什么
车辆密度分布（每帧平均几辆车）	密度高 → 极简 IOU 不够，要升 ByteTrack；密度低 → 项目太简单，要多车道补深度
视频稳定性（悬停/巡飞比例）	巡飞多 → 方向判别和跟踪都需要运动补偿兜底

所以准确的说法是：“问题定义已冻结，方案闭环等 W1 数据审计”。这不需要再改文档，审计结果记入数据审计报告即可。

二、推荐的高效着手顺序：先“假”后“真”

大部分人拿到这个任务会按学习计划的 W1–W8 线性走：搭环境 → 建骨架 → 训练模型 → 写跟踪 → 写计数 → 最后集成。这条路慢且风险后置——你可能在第 5 周才发现“检测框和虚拟线匹配不上”这种集成问题。

我推荐的方式是先假后真（Walking Skeleton）：

第 1 步（半天）：最小数据审计——只回答三个问题

不要做完整审计，先花半天看视频，回答：

1. 平均每帧几辆车？（决定跟踪方案）
2. 悬停片段占比多少？（决定要不要 GMC 兜底）
3. 帧率 ≥ 25fps 吗？（决定帧间关联可行性）

产出：一页纸的数据快照，直接决定第 2 步的模型选择。

第 2 步（1–2 天）：用预训练模型跑通端到端“假闭环”（关键动作）

不要先训练自己的模型。 直接用现成的 YOLOv8/v11 COCO 预训练权重（自带 car 类），跑通整个链路：

视频 → 解码 → 预训练YOLO检测 → 极简IOU跟踪 → 虚拟断面计数 → 方向判别 → 输出JSON

这一步的价值远超想象：

• 1–2 天内你就有了第一个可运行系统，心理正反馈极强；
• 集成问题（坐标映射、断面定义、时间戳对齐）全部提前暴露；
• 得到“未训练模型能达到什么水平”的天然基线——这是你作品集故事的第一章。

第 3 步（1 天）：人工 ground truth 标注（关键路径，尽早开始）

选 3–5 段代表性视频（密度不同、时段不同），人工逐段数通过车辆数和方向。这一步是全局关键路径，越早做越好，因为：

• 它是所有精度指标的基准，没有它第 4 步无法进行；
• 标注过程会让你“人肉体会”什么场景会导致误判（遮挡、模糊、边缘车），这些直接转化为第 4 步的误差假设。

第 4 步（半天）：用“假”系统跑第一个评测

预训练模型 + 极简跟踪 + ground truth → 第一个 MAPE/漏计率/重复计率报告。

这是项目最重要的第一个里程碑。无论结果好坏都有价值：

• 如果预训练模型已经数得不错（MAPE 小于 20%）→ 说明瓶颈不在检测，重点转向跟踪消融和部署优化；
• 如果误差大 → 逐个归因（漏检？跟踪断裂？方向误判？），这些就是你自己训练模型时的改进方向。

第 5 步（第 2 周起）：训练自己的模型，替换并对比

此时你已经：

• 知道数据长什么样（审计）
• 知道系统怎么跑（假闭环）
• 知道评测怎么做（ground truth + 指标）

训练自己的 RGB 模型，替换预训练权重，对比计数精度提升多少。这条“预训练 baseline → 自训练模型”的对比线，就是项目叙事的主线。

第 6 步（第 5–6 周）：部署链路（ONNX → TensorRT → Triton）

注意：部署链路的正确性用“假闭环”已经验证过一遍，这里只需要替换推理后端，不会有架构级返工。

第 7 步（第 7–8 周）：压测、可观测性、验收、作品集

三、为什么这个方式更快

传统线性顺序	先假后真
第 1 周搭骨架，无产出	第 2 天就有可运行系统 + demo
集成问题第 5 周才暴露	集成问题第 2 天暴露
训练完才发现数据切分有问题	审计先行，切分问题第 1 周发现
“为什么要训练模型”说不清	有预训练 baseline 对照，动机清晰
评测体系最后才建	评测体系第 1 周建好，全程指导

核心原则：让“可评测的端到端系统”在第 1 周内出现，之后所有工作都是在它上面做替换和增量，而不是从零组装。

四、三条纪律（防止重新陷入慢路径）

1. 每个模块配一个最小验收点：跟踪 → “有/无跟踪计数差异”；检测 → “mAP 切片报告”；部署 → “四列 benchmark”。没有验收点的模块不要开始写。
2. 人工标注提前做，且只做一次：ground truth 是冻结评测集，标注规范要先写清楚（什么算“通过”、什么算“一辆车”、边缘模糊车算不算），否则后面返工。
3. 每周留一个可运行版本：学习计划里已有这条，但配合“先假后真”它变得自然——你的版本是从第 2 天开始连续进化的，而不是第 5 周才从零变出第一个。

一句话总结

问题定义已 90% 完成，剩下 10% 是数据审计；动手时先拿预训练模型在第 1 周内跑出一个“能数车”的假闭环，再逐步替换成自己训练的真模型——先有系统，再优化系统。