再之后的OCC网络，意思其实和GOD一样，也是生成三维空间用的，把感知到的信息做成三维建模。之所以在初期普遍会选择BEV+OCC/GOD网络的组合使用，是在OCC/GOD网络没有达到成熟之前，确保感知精度、准确性、车辆安全性等多个角度考量的，简言之单靠OCC/GOD满足不了这些条件。
现阶段，小米的智能驾驶在技术层面，其实做到了与华为ADS 2.0齐平的基础。
实际使用，可能遇到哪些问题？
看完底层技术逻辑之后，其实已经做到了第一梯队的水准。那么，在使用效果端理论上很难做不好，而我们该注意的，是这套系统的上限在哪里，和初期的城区NOA效果能达到什么样的使用水平。
这套辅助驾驶软件算法能实现的效果，从前期的测试视频、直播中我们大概也能摸清楚一些，先说测试中明显做的很好的效果。在复杂路口的工况下，抉择和操作都相对来说是比较快，而且果断的，这是做好城区NOA的一个大前提。
然后，说具体工况下的使用情况。
在十字路口的让行上，行人、电动车优先级最高，基本在直行、转弯的时候，遇到正常通行/突然窜如的行人或电动车的时候，小米SU7在90%的情况下都会做出刹停等待的操作，并且确认前方没有任何障碍物时候才会加速通行（但这个过程可能需要几秒钟的时间来做判断），相对来说，是一个比较保守的通行策略。
还有在面对无序车辆在十字路口拥堵的情况下，小米SU7也会通过跟随规划路径按序行驶的形式来通过拥堵路口，整个过程没有被驾驶员接管，这是一个不错的体验。但，整个过程的操作执行，会有一些“犹豫”和延迟。
这个工况下，小结一个点，小米SU7的城区NOA在遇到复杂路口、多车并行通过、无序的情况下的这种“博弈”，是一个绝对温和的策略，不激进的去抢车道，而是在低速行驶等待机会出现。在下面的工况，也出现了同样的操作。
左转路口，转完后等待接下来的直行操作的时候，会遇到一个情况，让行同路口右转弯车型先行通过；同时，左转弯路口车辆在转弯后，跨越虚线车道线行驶进入直行道。在这个场景下的决策，有一些不够拟人，这也暴露了小米这套智能驾驶系统的一个状态，大多数情况下，是处于非常保守的状态。以上工况，如果是驾驶员亲自开的话，那么，左转弯后面对三条车道，会优先选择无车/车辆较少的车道通行，而非是等待右转弯车型先行后再通行，可以做到同步通行。
虽然部分工况下，可以顺利执行操作，并且决策和规划的行车路径，大部分都是比较合理的状态。但，有一些工况其实还是需要进一步加强，例如，跟车距离（容易被插队）、刹停时候的姿态、起步时候的快速响应等，都是一些比较考验细节的优化能力。
整体来看小米SU7的智能驾驶部分，大体的框架没有任何问题，逻辑跑的通，只是欠缺细节优化的问题，估计会在后续的OTA中去逐步优化。
然后期待一下它的后续更新，分为几个阶段，持续用BEV+OCC网络的方案，用这套逻辑把细节处理好，至少解决跟车距离远近问题（或者是可以调节的一个设置）以及跨车道行驶的逻辑打通；然后，后续的大版本更新，肯定也会弃用BEV网络，在能把2D信息转化为3D建模的网络出现之后，BEV就真的是个累赘般的存在了（类似于ADS 2.0到3.0的路子）。