数据闭环其实是任何有机器学习相关经验的人的朴素思路，并没有值得特别多的强调，反而是具体的做法才是重点。
从怀疑数据数据闭环的角度来说（其实完全没有值得怀疑的）：
当然，前提是真的能够建立起这套系统。虽然建立这套系统的原型并没有太大难度，但是 scale up 才是这套系统的关键。
这套系统可能包含了多个组件，每个组件可能实现的代码基都不一样。整合在一起更快、更好的运转本身就是一个工程挑战。
传统的融合工作可能会有一部分转入数据准备，主要的应用会在自动标注和时序预测上。
感知做到最后就是预测，这两个的任务应该融合在一个统一的框架下进行。对目标运动状态的估计可以天然的扩展到未来的预测，感知中的裸特征相比单纯的结构化数据更有提升的潜力。
目前的技术路线尚未收敛，起码目前阶段还有很多可能性。
在特斯拉 BEV 的相关工作公开出来之前，基本没人提；出来后，似乎人人都觉得 BEV 是未来的必由之路。这显然不像一个具备成熟技术路线的领域。
整个自动驾驶实际是一整套复杂系统，整个技术栈之间互相影响互相耦合，而且直接和物理世界接触。
相比纯软件系统，和物理世界有关的部分很难隔离，可能遇到一个问题就会捅穿整个技术栈。比如量产车的传感器布局，一个小的变化可能就需要从硬件到算法整套的调整。
结合上面的技术路线尚未收敛的原因。整个系统的调整都是不断迭代的，可能同公司的两代车型，传感器和算法都会有大的变化。那么后面的感知、数据、融合都需要对应的调整。
这个大系统涉及的知识领域过于宽泛，而且很多领域还十分依赖实践积累的经验：硬件布置、电子系统、信号和数据传输、传感器、算法（感知、融合、规控）。同时，这个产业发展起来本身也才十年不到的时间段。
所以熟悉整套系统细节的专家，出现的概率可能还不如开车路上看见大象跳草裙舞的概率。那么人之常情的“救世主情节”在这里就显得十分不可能：很难有一个人的存在可以利用某一个技术手段让整个系统瞬间焕然一新。如果抱着这个思路，只会是不同的人继续在这套复杂系统上堆东西。
因为真的卷不出来。除非是有明确项目上线的时间点，以及各个因素确定性比较高。否则，卷与不卷对整个系统的作用并不显著。
这时，更加看重的是如何“有效的卷”，尽量多的积累数据和验证方案，提供更加有效的技术决策支持。互联网的一周一个功能，在 AD 领域里意义不大。
不过，各种 Roadmap 和饼带来的时间表让卷变得不可避免，毕竟，ddl 快到了，自然而然的自上而下的焦虑。
一个没有通过充分内部测试的系统，连在各工况下平均表现的数据都没有的系统（包括市面上的很多 L3 级），直接发到用户手上，本身就是一个安全隐患。