自动驾驶数据闭环，要么被高估了，要么被低估了？

在和身边的人沟通自动驾驶的数据闭环时，会碰到两类典型的人：第一类，当你给他讲数据闭环的时候，他的眼神是迷茫的，好像没有引起太多的重视和共鸣，甚至有人会反馈：“嗯，这个没什么，我们以前干的差不多”；第二类，他会觉得数据闭环，能解决一切问题，而且，数据闭环是一种全新的工作方式。

第一类人低估了数据闭环的重要性，第二类人高估了数据闭环的重要性。

图1 特斯拉AI高级总监Andrej Karpathy 2020年2月提到的Data Engine引起热议

虽然，特斯拉AI高级总监 Andrej Karpathy 2020年2月“AI for Full-Self Driving”的演讲，是数据闭环热潮的起点，引起汽车行业的热议，但是，实际上，数据闭环是一直是软件工程领域的一种成熟的工作方式，在人工智能时代，数据闭环并没有从根本上改变“整体”软件工程的工作方法，但是，对管理、运营和工具带来了全新挑战，因此，我们必须比以前更加重视数据闭环。

传统数据闭环已经被应用了超过20年

无论是早期的windows，还是最近的安卓，我们在系统使用的过程当中，都会被问到是否允许微软或者是谷歌收集你的数据[1]，帮助改进用户体验。这就是传统的数据闭环。

图2 Windows收集信息的选项界面

图3 Google Fixel 2 Android手机的收集数据的选项界面

图4 华为Android手机的收集数据的选项界面

在微软Office软件崩溃（Crash）后，你也能够看到一个弹出对话框，问你是否允许上传本次崩溃的信息，帮助微软改进Office。那这就是最经典的数据闭环。

图5 Office崩溃后上传数据的对话框，是经典的数据闭环

我们可以看一下，经典的数据闭环是一个什么样的工作流程？

图6 传统的数据避免的工作流程

比如，终端产品（Office）捕捉到一个崩溃的问题后，软件上传现场数据。

然后，软件厂商的工程师根据这些数据，分析和解决问题。

只有有了这些现场数据，软件厂商的工程师才能够了解这到底是什么问题，才能够解决这样的崩溃问题。我们在传统的软件工程当中，常说的一句话就是，复现一个问题，等于解决问题的50%。主要是因为传统的软件代码，太过复杂，用户操作可能会引发各种Corner Cases，对于各种Crash的异常行为，是无法通过阅读代码来发现问题的。最有效的解决方法，就是能够复现问题，然后依