不管怎样，让自己的英语越来越好，将会越来越受益。说可能受限于环境，但听读写不限。当然我觉得最重要不是英语，是责任。这里不谈责任，但都源于责任。
作为汽车软件工程师，肯定都知道图1的V流程，左边的需求，设计，右边的测试。在工作中，V流程的各环节几乎都做过，很有感触。
这些需求之间有什么关系呢？我觉得下图2作了比较清晰的说明，即正向地来说利益相关者先提出了一个大概需求，经与系统，技术反复沟通与反馈，确定了利益相关者需求，再据此确定了系统需求，最后再据系统需求确定了软件需求；反向地来说，具体实现过程中也可能存在软件需求不合理情况，进而依次去更新软件需求，系统需求和利益相关者需求。
软件工程师也许属于图2红圈的一份子吧，当然这里的目的不在于探究细节，通过这个图主要想表达是：
软件工程师应具备强烈的需求意识，不仅仅局限于代码层面，应明白从需求层面到代码层面，只有深入理解了需求，才能写出更加准确精炼的模型或代码。
其次谈文档规范。认真对待文档规范，你将会有意想不到的收获。软件工程师一般都不喜欢写文档，写了一份又一份，关键最后还可能几乎没人看，但规定要去写那还必须得写，些许无奈。那何不换个角度，先从认真对待开始，接下来就会逐渐思考如何写？如何写好？为什么文档模板这么安排？不知不觉就会去看一些标准规范，通过这些就能逐渐去理解文档的别有用心以及这些模板的由来，一般标准会提供一些参考模板，比如图4（源引自：IEEE Recommended Practice for Software Requirements Specifications，IEEE Std 830-1998）。然后结合自身工作经验，再来理解这些文档，会发现文档不再那么抽象，其实非常科学，非常严谨，最后会学着利用这些文档来帮助自己形成一个更有逻辑更有层次的表达。所以认真对待文档规范（也包括流程），有了这方面的强烈意识，我觉得一方面不管是要符合ASPICE，还要AUTOSAR，应该都可以很快遵循这些规范来指导实践；另一方面也极有助于我们从项目管理和软件工程角度来看待项目。
最后谈测试。本质上就一句话：纸上得来终觉浅，觉知此事要躬行。从零开始的项目一般还好，边开发边测试；有base的项目，最好得主动多仿真多测试，通过数据和现象来快速理解。说到测试，分享一个小故事：曾经看着德国同事准备集成测试报告的图，类似于下图5，他创建了多个子窗口归类地来分别显示数据，调好数轴标尺等操作，以使得他人一眼就看懂测试结果。当然他就是这么想的，然后我就照学了。看个反例（图6），自行对比感受下。
这里又想分享一个小故事：看到过有个人解决问题能力非常强，几乎来了一个bug，看看数据看看模型，咔咔两下就给解决了，但我发现很奇怪的现象，这个人天天都有bug要解决。后面不幸让我接手了，发现补丁好多好多，有些还无法追溯。后面又遇到了一位很有要求的同事，每次一有bug就问我“这个bug对功能有什么影响？”，刚开始我大概都这么回答“不知道，但代码层面分析了bug的影响和解决方法，该方法不会影响其他代码逻辑，能满足客户的要求，balabala. ......该方法”。
故事到这，首先得从功能层面去分析：这个bug对功能有什么影响？如果你都不清楚功能，怎么能够确定这就一个bug呢？怎么能够保证修复方案是最佳的呢？怎么能够确保修复后仍满足需求呢？当然要更全面更理想的分析可参见图7。
所以，应该加强从功能层面理解好软件，当然模型或代码层面也很重要，这样宏微观上都能切换自如，软件就会被你玩的溜溜的。
先谈软件方面，曾经为了了解从软件到硬件的最终执行，我花了几个月听计算机科学课程，从计算导论与C语言基础（北京大学，李戈）：记得当时听明白了计算机硬件如何实现0101，图灵机怎么工作等等，讲得非常精彩。
整个听课过程下来，虽然我没有做作业，忘了绝大部分，但是我觉得从软件到硬件怎么运行，我基本上有个概念，假如真要我去做这方面的深入，给我时间肯定没问题。
总的来说，从广度上对软件要有一定的认识。当然，从深度上对软件也需要很深的认识。比如：运行时序问题，一定要明白先有谁后有谁；精度（scaling）问题，配置就要求很细致；内联函数问题，使用就要特别小心。
再谈工具方面，以MATLAB/Simulink为例。我个人受益于两方面：一方面是来自同事，有同事的悉心指导和用心分享，也有看同事怎么做的，去模仿学习怎么做，去思考谈论为什么这么做（当然更多时候后者去看去试去悟）；另一方面来自mathworks提供的demo和研讨会视频。比如入门变速箱控制模型时，我就找到了一个特别有用的demo包，如图7示意，通过这个demo包做仿真做调试，这样很快就上手建模操作。另外通过一系列的研讨会视频，很快就入门了MBD，以及如何使用Simulink工具做模型检查，验证与确认等，如图8。所以，把握身边的和网上的，工具肯定没问题。
最后谈专业知识，以变速箱控制为例，变速箱控制目的就是开车的人踩了多大油门或多大刹车，变速箱就要自动地去操作挡位和离合器，让开车的人开加速不错，的很爽，很是舒服（当然不仅仅是变速箱的功劳）。那么怎么实现的呢？比如图10示意一个升档控制过程（引自：i/pdf/10.1177/7）。
本质上就讲理解此公式：\Delta T=J\omega就基本可以应付变速箱的离合器控制工作了。再深挖电液系统的话，那么牛顿第二定律和伯努利方程都来了。
一个人的精力是有限的，上述所说大多数人还是很难做到位。但是不管怎样，一个汽车工程师最好要具备这些意识，不管是重在广博，还是贵在专精，选好自己的方向，认真工作，一定会越来越优秀。
本部分基于先建立宏观认识，再逐步深入的观点。以业余学习智能驾驶专业为例，分享下先如何快速概览一门新知识，然后设定明确的学习目标；最后从新手开始逐渐积累。
从被动接收到主动吸收。刚开始对一门知识完全没有概念的时候，我偏向于被动去接收，一般通过视频课程或文章先强行接收概念，比如参考[1]的多伦多大学的《智能驾驶专业课程》，很全面地介绍了智能驾驶知识点，这里也有非常优秀的知乎文章能达到类似的效果。由于智能驾驶方向相当火爆，所以优秀的网络资源特别多，也很适合来作为入门概览。总的来说，书籍或者课程是获得系统化概念的最好的途径（网络文章一般都是碎片化知识，我觉得刚开始不太适合建立全面的概览认识）。这里最好能从学术与工程两个视角去概览。
当被动接收到一定程度，好像从什么都想问进入到有问题但不知道怎么问的阶段，这时开始主动吸收了，逐渐地知道了想问什么，且答案不是一两句话说得清的。有了这样的感觉，已接触了整个内容后，那么基本上就概览了一门新知识。
目标的重要性无需多说，比如个人2020目标是要多总结多分享，不知不觉已在知乎写了好多篇了。回到智能驾驶，就软件来说有：感知，定位，规划，控制等方向。不同方向侧重的知识不一样，这时候的选择就与个人息息相关了。当我选择确定以控制为大目标后，发现有百度Apollo项目开源了。
这样就可以开始以Apollo开源代码为基础的学习，这时会有几个问题：是否有编程基础，会不会C++?是否会汽车动力学分析？是否有经典控制与现在控制理论基础？是否有对车辆横纵向控制的实际工况了解呢？等等...不管怎样，从长期来看，要入门这些最终要会的。从短期来说，以当前自己擅长的为主突破点，同时不擅长也需要加入日常学习。结合个人情况，就如当前我以汽车动力学和控制算法为主突破点，以输出高质量的学习笔记为目标来促进自己不断深入学习。（当然当前输出的学习笔记质量很有待提升，但迫于当前时间有限和学习本就是一个循序渐进的过程）以此确立一个清晰的目标，学习新知识将会更有行动力。
另外还有一个很好的视角来帮助确立目标，那就是以市场角度来看，市场需要什么。比如截取自猎聘的一个职位：
15年进入汽车行业到现在，尤其经过疫情后，特别感受个人选择顺应时代潮流的重要性，不管是行业的选择还是行业内的方向选择，看下几个数据，首先是汽车行业与人工智能行业对比。
对于绝大多数人，绝大概率上来说，方向比努力更重要。对于未工作的或工作时间很短，掉头转向就好；对于工作有一定年限，挺难的，差不多都要综合考虑家庭因素了。然后时间不会停止，生活不断滚滚向前。在这个快速变化的时代，如何做好汽车软件工程师的变与不变。本质上就是要认清现实，坦然接受，积极应对，如本文的第1部分和第2部分所述：通用技能与方法，拥抱学习新知识。
