洞见 | 搞智驾这7年，绝大多数的数据闭环都是伪闭环
转载一篇来自知乎的高赞文
作者知乎-李众力
万字长文，建议先收藏
原文如下，略有改动
2025 年年底了，我也来回答一下（上面这个问题）。
先说结论：据我能接触到的一圈国内玩家，大家嘴里的“数据闭环”，绝大多数还是各个算法团队内部的“小闭环”，离当年 PPT 里畅想的那种“数据直接解决问题”的大闭环，还有好几层台阶。
先简单说下我自己的背景（方便大家判断我是不是在瞎说）
我从事自动驾驶行业大概 7 年多了，从最早那种“开完车工程师拎着硬盘，从工控机上拔下来，抱着去机房拷数据”的年代一路干到现在。
这几年主要在一家互联网大厂的物流无人车项目里，从封闭园区到高速公路再到城市公开道路，从载人到拉货都有涉及，负责整车的数据体系和质量体系搭建，带团队做的事情大致包括：
设计并落地一整套触发器（Trigger）体系：从车端实时触发，到云端历史数据挖掘、仿真评价，做到代码级统一； 搭建从“线上问题发现 → 自动分发 → 数据挖掘 → 训练 / 仿真验证 → 上线回归 → 指标追踪”的闭环平台； 把多模态大模型（LLM + VLM）嵌进来，做问题自动分类、自动路由到对应团队，以及辅助研发 / 测试写 Trigger 规则； 把“每一次急刹车、每一次接管、每一次奇怪行为”都结构化、可计算，减少拍脑袋和微 信群里吵架。
日常工作基本就是跟各种 log、Trigger、标注平台、仿真平台、QA 流程和一堆诡异 bug 打交道，是一个比较典型的“数据闭环 + 质量体系”视角。
下面所有观点，都是站在这个视角下的个人经验，不代表任何公司官方意见。
一、先对齐一下：什么叫“真的数据闭环”？
我心目中“真闭环”，至少要满足以下两层：
1. 问题发现自动化
不是靠“司机吐槽 + 群里截图 + 领导试驾骂了一句”触发，而是系统能从海量运行数据里自动发现异常行为：
急刹、急打方向、蛇形行驶、异常接管激增； 某些路段/路口的安全指标或体验指标显著变差； 难得一见的安全边缘场景（险撞、鬼探头、复杂博弈）。 问题到方案的路径是“可重复、可量化”的
简单讲就是：
一个线上问题 → 自动被归类、建成数据集 → 自动进训练 / 仿真 → 产出候选方案 → 自动评估效果
人主要做的是定义目标 & 拍板，而不是从 0 到 1 手工搬砖。
2. 解决效果可量化、可复盘
新版本上线后，系统要能持续回答三件事：
这个问题的发生频率有没有下去？ 有没有引入新的负面问题？（典型：安全好了体验全崩） 这次数据、算力、开发投入，值不值？
一句话概括：
真正的数据闭环，是“问题会自己长脚走完从『被发现』到『被解决并被验证』的路径”，人是设计规则和做决策的，不是不断重复体力劳动的。
二、现实里大多数厂商在做什么？
比较诚实的说法：
今天很多所谓“数据闭环”，其实是“数据驱动的研发流程 + 一些自动化工具”，而且大多局限在单个算法团队的小视角。
一个典型流水线大概是：
线上触发 / 抽取 各模块（感知 / 预测 / 规划 / 控制……）各自定义一些 Trigger，捞“疑似有问题”的包； 清洗 & 标注 离线脚本过滤脏数据； 扔给标注平台做 2D/3D/语义/地图各类标注； 好一点的有自动 / 半自动标注。 训练 / 回归 算法选一堆 case 训练，离线回归集跑指标； 有条件的多加一步仿真 / 重放。 上线 & 监控 A/B、灰度，上线； 继续靠新一轮 Trigger+人工发现问题。
这一套当然也算“闭环”，但更多是模块级、算法视角的小闭环，离“系统级的闭环”差得不少。
三、为什么说“还没真闭”？几个典型断点
1. 起点是“被动闭环”，不是“自动发现问题”
现在大量问题还是这样来的：
司机反馈：某个路口老出事； 运营/客户投诉：体验太差； 领导试驾了一圈觉得某段路不对劲； 测试同学肉眼刷录像刷出来的坏 case。
然后才反推：
“我们加个 trigger 把这种情况捞上来吧。”
这其实是问题驱动数据，而不是数据自动发现问题。
理想状态是：
安全 / 体验 /效率等指标被持续量化； 某个区域、某个版本、某个车型某项指标异常偏离，系统自动报警； 自动聚类对应数据包，把相似问题聚成“问题簇”。
这一块目前能做得比较好的厂并不多，大多数还是停留在“若干 Trigger + 一些报表”。
2. 归因困难：只知道“有坑”，但不知道“谁填坑”
同一个现象背后，往往是高度耦合的组合原因：
感知偶发漏检 → 预测轨迹偏差 → 规划保守 → 控制多次点刹； 地图拓扑错误 → 规划路径不合理； 标定漂 / 传感器轻微移位 → 融合结果整体偏。
没有成体系的诊断工具，就容易变成：
每个团队都说“不是我，是他”； 或者大家各改一点，谁也说不清到底哪步真正解决了问题。
现实里，很多地方还是靠有经验工程师肉眼跳 N 个界面，一点点分析，离“数据自己定位问题”远得很。
3. 数据到“方案”的链路，停在了“数据到模型”
很多团队的闭环，其实可以概括成：
数据 → 标注 → 训练 → 离线指标涨了 → 上线
但是：
解决了哪个线上“真实问题”？ 这次改动的经验，以后能不能自动复用？ 这次投入算下来值不值？
要么没人追，要么追得很粗。
大多数只是在“技术指标”的层面闭环，
不是在“问题 / 业务”的层面闭环。
4. “自愈”的程度非常有限
PPT 里常见的一条线：
线上问题 → 自动收集 → 自动标注 → 自动训练 → 自动评估 → 自动上线
现实里更像：
自动收集：有一部分自动，但经常被各种异常打断； 自动标注：有预标，但人力复核仍然是大头； 自动训练：流水线是自动的，但选数据、配配置很多手动； 自动评估：离线指标自动，仿真和线上表现难以完全自动； 自动上线：真到“上路要负责”这一步，大家都不敢真全自动。
所以现在很多所谓“闭环平台”，本质是一个高度自动化的工厂生产线，
而不是一个可以自我决策的“自愈系统”。
5. 组织结构天然把闭环“拆成几节”
还有一个被低估的问题：组织结构本身就是断点。
感知、预测、规划、控制、地图、云平台，各有各的 OKR； Tier1、整车厂、云服务商，各有各的边界； 数据安全、合规、成本，随时可以卡你。
于是：
每个团队内部都能画出一条“还挺漂亮”的小闭环； 拼在一起，从系统角度看，就是一堆多边形战士。
四、我自己在做的一套数据闭环实践
上面说的是行业横截面，下面讲讲我自己这几年在做的一整套实践。
不敢说“完美闭环”，但我自认为无论是理念还是落地程度，在国内自动驾驶里算比较激进的那一拨：我们是真把“数据当产品、指标当第一公民”来设计的。
整体思路可以概括成一句话：
从“体感指标”出发，用 Trigger 把世界离散成 token，
再用 LLM 做分类和路由，最后用统一代码把“发现”和“验证”串起来。
1. 从“体感指标”出发：先把真实世界的“痛”量化出来
我们做的是物流无人车，乘客不在车里，但客户和路人是有“体感”的：
急刹、急转、蛇形、频繁停、莫名其妙慢，都会投诉。
所以我们从数据上传设计的第一天起，就把一批绝对真实、用户有感的体感指标当作“第一公民”：
急刹车次数（按不同等级划分严重度）； 接管次数（包括现场接管、远程接管、异常切人工）； 大幅转向、频繁修正方向； 一些“体验上明显不对”的行为（比如场景不复杂却极度保守）。
要求很简单也很残酷：
所有的接管、所有的急刹，必须 100% 被记录下来。
不靠人工挑“看起来像问题”的，而是完整如实记录现象。
在云端，这些体感行为会沉淀成类似：
每万公里急刹车率（按不同等级分桶）； 不同道路类型 / 场景下的接管率； 不同版本 / 不同区域的体感指标对比。
没有这一层客观、全面的统计，后面讲什么闭环，基本都是 PPT。
同时，我们也彻底放弃那套“拷盘式”数据上传方式，而是做得更像互联网埋点：
不是把原始传感器数据一股脑上传； 而是按事件上报： 事件发生时间； 当前驾驶模式（自动 / 远程 / 人工）； 若干关键环境信息： 道路类型（高速 / 城快 / 主干 / 支路 / 园区路 / 场地）； 周围障碍物的数量级； 是否处于路口 / 汇入 / 会车等关键场景。
这样做的目的是：把“真实世界发生了什么”先说清楚，
至于原因之后再慢慢分析。
2. 车端 Trigger：高召回 + 极低开销的 micro log / mini log 机制
我们的车上只有一颗 Orin X，要跑完整套 L4 算法，算力压榨得非常狠，所以车端有几个硬约束：
Trigger 必须实时，但极其轻量； 优先保证高召回，而不是一开始就追求高精度——宁可多报，不能漏报。
车端一旦发生：
接管； 急刹车； 大幅转向； 或者其他体感明显不好的动作；
就由一个高召回 Trigger，将前后若干秒的数据打包成一段micro log，加入上传队列。
micro log 是一段很小的“问题线索”日志切片： 带上关键状态、姿态、部分中间结果； 体积很小，但足够做第一轮判断。
micro log 上传到云端之后，还会再过一遍云端规则 / 模型管线：
用更复杂的规则判断“这是不是一个真正意义上的急刹车 / 异常事件”； 比如要求连续若干帧减速度超过阈值、持续时间达标、场景符合要求等。
通过这一步，我们从“高召回的疑似事件”，筛出客观可信的指标事件。
被认定为严重急刹车等一级指标的事件，会触发下一步：
给这一小段时间下发更大粒度数据的上传任务（mini log）。
mini log 里会包含：
更多中间结果（比如感知/预测/规划的细致输出）； 一小段压缩后的视频（十几秒，几 MB 量级），人能看清，又不会压垮带宽和存储。
3. 按团队定制“拉更细数据”：解决问题而不是“只记 KPI”
mini log 到了云端，还要解决一个关键问题：
“这个问题具体应该扔给哪个团队？扔过去之后，他们到底需要什么数据？”
我们先用一拨人工问题分发团队做初分：
看 mini log + 短视频，大概分一下：感知 / 规控 / 地图 / 硬件 / 其他； 人工分发结果本身，会被记录下来，用于给后面的 LLM 分类做训练数据。
一个重要的设计是：
不是简单地给各团队“记 KPI”，
而是根据分发结果，再给各团队定制上传他们真正需要的数据。
典型比如：
分到规控团队：再下发任务，让车上传规划轨迹、约束、代价函数等更细的中间结果； 分到感知团队：下发任务拉原始传感器数据，或者更高分辨率/码率的视频，用于重放和训练； 分到硬件 / 底盘团队：多拉完整的 CAN 报文、电源状态、温度、电机、传感器健康状态等。
也就是说：
第一层触发只上传非常轻量的“问题线索”，
确认这个线索值钱之后，再有选择地拉重数据上来，
避免一开始就“云端无限吞吐原始数据”的浪费。
4. 代码级统一：车端挖掘 / 云端挖掘 / 仿真验证用“同一段代码”
这一点是我个人非常看重、也觉得很多团队没做到的：
我们把车端数据挖掘、云端历史数据挖掘、仿真验证评价
做到了Trigger 逻辑代码级统一。
什么意思？
定义“什么叫一个问题”的那段逻辑（Trigger），
既可以在车上实时跑，也可以在云上跑全量历史数据；
同一段 Trigger 逻辑，也可以直接在仿真 / 重放的验证集上跑，用来评估新版本是否改善了这个问题。
好处很直接：
一套规则，从“线上发现问题”到“仿真里验证问题是否被修复”，完整走一圈； 中间没有“语义断层”和“实现偏差”； 真正做到：
同一段代码定义的问题 → 挖训练 / 验证数据 → 改算法 →
再用同一段代码去验证“这个问题在线上和仿真里是不是都变好了”。
在我看来，这一层才能称得上是真正的“从发现到验证”的闭环。
很多团队只是在“数据采集”和“模型训练”之间画了一条线，就说完成数据闭环，其实差了这一大块。
五、问题自动分发：把 Trigger 体系当成领域专用 tokenizer + classifier
再往下一层，就是怎么把“问题线索”自动、可靠地分发到对应团队。
我们做了一套比较“学术味”的设计，本质上是：
在多模态时序日志上，构建一个领域专用 tokenizer + classifier 的两阶段架构：前半段是特征工程，后半段是时序分类。
1. Trigger = 领域专用的时序 tokenizer / 特征工程
线上所有的数据流（传感器、状态机、控制指令、报文……），都会被各种 Trigger 扫一遍：
每个 Trigger 都可以看作一个领域专用 tokenizer： 在原始连续时序信号上，识别出某类“事件片段”； 把它编码成一个离散 token：发生时间 + 事件类型 + 若干关键属性。
最终得到的是一串多模态时序事件序列，可以类比成：
从波形到音素 / subword 的过程 —— 先切分，后建模。
2. 文本化：把这些 token 对齐到 LLM 的词表空间
为了让通用大模型（LLM）能直接利用这些结构化事件，我们会把上述时序 token 再做一次文本化映射：
把某段 micro/mini log 对应的 Trigger 序列，转写成一段 LLM 易于理解的“事件时间线”；比如：
第 3 秒：前方某障碍物的感知尺寸出现明显跳变，疑似距离估计不稳定；
第 5 秒：同一障碍物的预测轨迹发生明显跳动；
第 10 秒：车辆因为该障碍物触发了紧急制动事件。
从模型视角看，这一步就是把我们自定义的 token 序列，投射到通用 LLM 的词表空间里，完成一次语义对齐。
3. LLM = 时序事件序列 classifier
在这个表示之上，我们把 LLM 当成一个时序事件序列的 classifier 来用：
输入：一段“车辆从正常驾驶到急刹的文本时间线”； 输出：
对这次事件的主导原因归因（感知估计波动 / 预测不稳定 / 规划博弈失败 / 控制执行异常 / 底盘异常……）； 建议的责任域 / 团队路由（感知 / 规控 / 地图 / 硬件 / 其他）。
用机器学习的话说，就是很标准的：
feature engineering（Trigger + 文本化） → sequence classification（LLM）的流水线。
Trigger 把原始高维、多模态、长时序信号压成“抽象 token 序列”，
LLM 在这串 token 上建模时序依赖，做判别。
4. 用真实“改派行为”做弱监督，形成 online 学习闭环
更关键的是，我们不是拍脑袋觉得“分类应该挺准”，
而是用真实的研发“改派行为”做弱监督标签，形成一个在线学习闭环：
所有自动分发出去的问题，都会挂在统一的问题管理系统； 我们只统计研发真实有回复的问题： 如果研发回复时，并没有修改自动分发的团队 / 子模块 → 记为一次命中； 如果研发回复时，把问题从“感知问题”改成“规控问题” → 记为一个 bad case。 所有 bad case 会自动回流到 LLM 的分类知识库，用来更新分类边界。
从 ML 视角看，就是：
用研发“改派”作为弱监督标签，在真实线上分布下做 continual learning，让 classifier 在真实业务分布下越用越准。
六、Trigger 框架统一：Python + 大模型，让“写规则”变成大众技能
前面说了，我们做到了“车端挖掘 / 云端挖掘 / 仿真验证用一套 Trigger 代码”。
这里补充一个实现细节，也是我非常在意的一点：
所有 Trigger 逻辑统一用纯 Python 实现，并且跨平台可跑。
为什么这么做？因为这直接决定：
Trigger 上手门槛有多高； 有多少非算法的同学（测试、运营、QA）也能参与写规则； 有多少经验能从“嘴上说说”变成“代码”。
我们做了几件事：
1. 统一 Trigger 框架与接口
不管跑在车端、云端历史数据挖掘，还是仿真评价，写 Trigger 面对的是同一套 Python 接口和运行模型； 只要会一点 Python，测试 / 数据 / 运营同学都能写自己的“问题触发器”。
2. 写好大模型“看得懂”的文档和示例
给 Trigger 框架写了结构化、示例丰富的文档，让 LLM 能理解“Trigger 怎么写、输入输出是什么”； 然后做一个小工具：研发 / 测试只需要用自然语言描述“想监控什么现象”；LLM 根据文档 + 示例，生成一段可跑的 Trigger 代码，人再微调。
3. 更多、更细的 Trigger → 更“密”的标签
当写 Trigger 不再是某几个资深算法的特权，而是：
“懂业务 + 一点 Python + LLM 辅助”就能上手
自然结果就是：
Trigger 的数量和覆盖度急剧增加； 每一帧数据上被打的标签越来越多维度（体感行为、场景属性、算法中间状态……）； 这反过来进一步提升： LLM 做问题分类 / 根因分析的输入质量； 自动数据挖掘和构建训练 / 仿真数据集的效率。
本质上，我们是用“Python Trigger 框架 + LLM”，把过去散落在脑子和会议里的经验，逐步固化成一个可协同维护、可演进的“规则代码库”，并直接挂在数据闭环的主链路上。
4. 量产环境中的解耦：挖数 Trigger 当“配置”，脚本跑在车端沙箱里
现实里还有一个非常关键、但容易被忽略的工程问题：
量产环境的版本更新是非常慢的
同一时间路上可能跑着一堆不同版本，
但数据挖掘的需求却是高度实时、强时效性的。
举个特别常见的例子：
某个城市突然下大雪，就这几天；
你必须在有限的时间窗口里，把雪天的数据赶紧挖上来；
不可能等一个“带新 Trigger 的版本”完整上线全网。
为了解决这个矛盾，我们在设计里把“数据挖掘 Trigger”和“线上算法版本”彻底解耦：
允许我们针对某一段时间 / 某一类场景，快速上线一段挖掘逻辑，比如“只在雪天 + 城市主干路 + 车速 30km/h 以下时挖某类数据”。
在量产环境中，数据挖掘绝对不可能无限制，我们会在云端对挖掘策略做动态控制：
一旦某个挖掘任务的数据量“够了”（覆盖了必要的场景和分布），云端会自动下发关闭 / 降采样的指令；
这样可以避免：
大量重复、无意义的数据；
不必要的带宽、存储成本浪费。
整体来看，这一套机制保证了：
1）挖数能力不跟随主版本节奏慢吞吞走，可以相对灵活地应对突发场景（例如极端天气）；
2）同时又不破坏量产环境的稳定性，安全、实时的主算法和“更激进的挖数逻辑”严格隔离；
3）挖数本身也在闭环：数据够了就自动收手，不做无意义堆量。
七、区分“世界标签”和“算法标签”，以及向量检索的正确用法
有了这么多标签，还有一个经常被忽略但非常重要的点：
要把“客观物理世界的标签”和“算法中间结果标签”严格区分。
1. 世界标签 vs 算法标签：两条不同的轴
我们体系里维护两类标签：
不依赖当前算法好坏，尽量接近“世界本身”：
天气：晴 / 阴 / 雨 / 雾 / 夜间等； 场景：高速 / 城市快速 / 主干 / 支路 / 园区 / 停车场； 道路结构：有无遮挡路口 / 十字 / T 字 / 环岛 / 无路口； 交通参与者：行人、非机动车、机动车的大致数量区间； 车速、流量、车道数等。 用于支撑更精细的筛选和分布分析，比如： “只看雨天、城市支路、车速 <30 km/h 的急刹车”； “只看有弱势交通参与者、且在路口附近的接管”。
感知的检测框是否抖、尺寸是否异常变化； 预测轨迹是否短时间大幅跳变； 规划是否频繁重规划、是否在安全约束边缘抖动； 控制是否出现“油门刹车来回切”的不稳定模式。 更适合作为归因与调参的特征，而不是描述世界本身。
这两类如果不分，就容易变成：
你以为在看“现实世界的难度分布”，
实际上是在看“当前算法在哪些地方表现得更差”。
2. “全靠向量检索”的伪闭环：为什么不适合做粗筛
还有一个常见误区：
“把原始数据丢给一个模型做 embedding，再用以图搜图 / 向量最近邻检索，就能搞定数据挖掘。”
这类方法当然有用，但绝对不是主力入口，尤其面对海量存量数据时问题很大：
未筛选的全量数据做向量检索：
召回太大、成本太高； embedding 语义受训练分布影响很大，“看起来相似其实不相干”的情况很多； 你真正想要的长尾场景很容易被淹没。
更合理的姿势是：向量检索做精筛，不做粗筛。
我们的做法：
先用结构化标签规则，把 80%–90% 的无效数据筛掉
比如想挖“老奶奶过马路”的场景，即便感知里没有“老奶奶”这个类别，也可以先用规则过滤一遍：
必须在路口附近； 车辆有明显减速甚至短暂停车； 周围存在近距离行人目标。 先把高速、畅通路段全扔掉，再往下看。 在规则过滤后的子集上，用向量检索补做语义级细筛 此时数据量已大幅缩小； 模型可以在这个子集中进一步区分：老年人 vs 年轻人、独自 vs 有人陪同、慢速穿越 vs 停顿再走等； 整体效率更高，算力浪费更少。
总结一句：
向量检索是精细手术刀，不是砍树的斧子。
对存量数据，一定要先靠结构化标签缩小空间，再让 embedding 去“挑刺”。
八、生成式 / 仿真数据：用得上，但不能拿来“自嗨”
最后讲讲最近很火的“生成式数据 / 仿真数据”，以及它在这套体系里的位置。
我们团队也有比较成熟的仿真数据生产能力（包括基于高斯表征的场景生成等），但内部有个共识：
生成式数据是用来补长尾训练短板的手段， 不是用来替代真实评测的万灵药。
1. 生成数据主要用在“现实里很难凑齐”的长尾场景
在训练层面，我们重点把生成式数据投到：
现实中很难大量遇到、但又很关键的场景，比如： 路上的锥桶、临时围挡； 路面坑洼、塌陷、突出结构； 某些复合稀有工况。
目的很简单：
扩大模型在这些长尾 case 上的“见世面”； 给模型一个“这类东西可能出现”的先验； 在真实数据不够丰富时，把召回先拉起来一点。
但最终用于评测和放行的评测集，我们仍然坚持只用真实数据。 因为你永远无法证明自己“完全模拟了真实世界”，只能让真实世界来兜底。
2. 只看“召回涨了”是不够的：误检的副作用常被忽视
以感知为例，生成式数据拉召回，很容易引入另一个风险：
在已有评测集上，召回率确实能看到在涨； 但在未知分布 / 新场景里，误检可能在悄悄恶化。
更麻烦的是，现实流程里：
增量标注几乎都优先关注漏检（FN）； 误检（FP）很难在评测集中完全覆盖： 你不可能预先知道模型将来会“哪里莫名其妙多出框”，也就无法在所有潜在位置都画一遍真值。
于是就容易出现一种错觉：
评测集上召回涨了，FP 指标表面看着也还好， 大家都很开心， 但真实线上有些区域模型已经开始“到处乱看东西”。
3. 我们的做法：版本间逐帧全量 diff，不先争真值，先看差异模式
我们在这块的策略是：
对两个版本，在同一批数据上的逐帧全量差分，系统性监控副作用。
具体步骤：
选一批有代表性的真实评测集； 用版本 A 和版本 B 分别跑一遍，拿到两套感知结果； 对结果做逐帧、逐目标的全量比对，标记所有“不一致”的地方。
一个关键点是：
只要两个版本在某一帧某位置给出的结果不一样，
那么就一定是“有一个错，或者两个都错”。
至于谁对谁错，我们可以先不急着判断。
在“不争真值”的前提下，我们先做的是差异模式分析：
给差异打维度标签： 距离段（0–20m、20–40m……）； 方位（前 / 侧 / 后）； 类别维度：是多了目标，还是少了目标； 对这些维度做统计和排序：看哪些距离段 / 类别 / 方位，在新版本下“差异特别多”。
接着再结合人工抽查、可视化检查：
哪些差异是“召回真正变好”； 哪些是“误检开始泛滥”。
如果在某些维度新版本的误检明显爆炸，
那么在我们这边，即便研发同学拿着召回曲线说“涨了很多”，
QA 这边这关也是不会放行的。
工程实践里，“涨多少”不是唯一指标，“涨得干不干净”同样重要。
尾声：从 Data-Driven 到 Bug-Driven，再到真正的数据驱动
写了这么多“数据闭环 / 数据驱动”，如果让我给现在这套东西起一个更诚实的名字，我反而会叫它：
Bug-Driven 开发体系。
听上去一点也不“高大上”，甚至有点土，但这几年实践下来，真正在一线推动车辆迭代往前走的，往往就是一个个具体的 bug：
某个路口总是左转犹豫； 某段路总是在鬼畜急刹； 某种障碍物在某种光照下经常漏检 / 误检。
我们搭建的所有数据体系，本质上就是：
更快、更准、更系统地发现这些 bug，量化这些 bug，跟踪这些 bug 的出现与消失。
如果说现在这套体系还有什么让我不敢说“已经跑顺了”的，那卡口已经不在“发现问题”这一侧，而是在：
“谁来解决问题、怎么解决问题”这一侧。
哪怕我能：
把问题发现得再多、分类再精细、优先级排得再合理， 真正能“动手解决”的，始终是团队里那几拨研发同学。
人的带宽是刚性的，长尾问题也不是一朝一夕能搞定的：
对感知来说，解决一个问题往往还是：采集数据 → 标注真值 → 训练 → 回归 → 上线； 标注这件事尽管业界都在宣传什么自动标注率，但从标注公司生意的景气程度就能看出来：人工标注依然是非常硬的一环。 仿真验证这边，也绕不开那句老话：
仿真结果到底能不能代表真实世界？
你说完全能，自己都不会信；你说完全不能，又很难支撑大规模自动化验证。
这些都是当下整条数据闭环链路里普遍存在的问题：
问题可以被越来越精准地“抬上手术台”，但做手术的人、手术刀的效率、术后评估体系，还远远没有那么优雅。
好消息是，最近这两年有两个方向，我觉得是值得乐观一点的：
1. 端到端 / 模仿学习类架构的兴起
在端到端视角下，“标签”更多直接对齐人类驾驶员的行为表现：
中间结果的对错、模块边界的划分没那么重要； 可以更直接地用“人类怎么开”去约束整体行为。
这在某种程度上绕开了很多“中间真值极难标”的问题，也给“真值标注”找到了一个更自然的出口。闭环仿真 / 世界模型的快速发展
大家频繁讨论的世界模型，本质上就是想把：
在仿真里充分暴露问题、充分迭代
把这一环做得更接近真实世界。
一些头部玩家公开说他们有非常大的工程投入砸在最后的验证环节上，本质也是在强调：如果闭环仿真这一环不做扎实，前面的“数据闭环”很难给真正的安全感。
我自己的判断是：
如果未来我们能够真正降低解决一个 bug 的边际成本，让端到端 / 世界模型类的方法在验证和安全约束上更可控，再叠加这几年在 Trigger 体系、标签体系、自动分类、代码统一这些工程实践上的积累，
那么大家这些年挂在嘴边的“Data-Driven”，
才有可能从口号，变成一套能持续跑、能算账、能规模化复 制的基础设施。
到那时候，“数据闭环”大概就不会再被拿来当卖点讲，
就像今天没人再把 CI/CD 当成卖点一样——
没有，大家才会觉得奇怪。
