工作总结

发表时间：2026-03-17

2026年汽车电子研发工程师工作札记。

去年冬天那个凌晨，售后群里弹出消息的时候，我正在改一份标定文档。消息说某款商用车在哈尔滨批量出现仪表黑屏，有的车甚至无法启动。当时我扫了一眼，心想又是低温惹的祸，但没料到这个问题会让我在接下来一个月里，反反复复折腾了无数个深夜。

一

最开始拿到故障日志，我盯着一串DTC码看了半天，直觉是CAN唤醒时序出问题了。低温环境下晶振起振延迟，控制器没能在规定窗口期内完成网络同步，导致防盗认证失败、仪表掉线。这个判断逻辑上说得通，但问题在于——实验室里死活复现不出来。

那几天我们把环境箱调到零下三十度，控制器冻得结霜，上电测试一遍遍跑，结果全是pass。同事开玩笑说，这故障怕不是跟咱们捉迷藏。我嘴上没接话，心里其实有点发毛：如果复现不了，问题就永远别想根治。

后来是售后老张提了个醒：“你别老盯着恒温箱，去现场看看真实的车。”这话听着简单，但细想确实戳中要害——实验室里供电是稳压源，实际车辆电瓶已经冻了一夜，电压掉的厉害；实验室总线干干净净，实际车上挂满了节点，负载率高得吓人。说白了，我们一直在理想条件下找问题，问题却只肯在恶劣条件下现身。

去哈尔滨那天，零下二十五度，风刮在脸上跟刀子似的。物流园里停了上百辆同款车，我跟司机师傅套近乎，递了根烟，人家才同意让我连夜测几台。凌晨三点多，我蹲在驾驶室外面，手冻得拧不开螺丝刀，最后还是师傅从车窗递了个保温杯，倒了杯热水给我焐手。那场景，现在想起来都觉得滑稽——一个工程师，坐在马路牙子上，捧着热水杯等设备跑数据。

凌晨五点多，第一组故障终于复现了。我盯着电脑屏幕上跳出来的波形，心里不是激动，是踏实——总算找到你了。

二

回头看这个问题的排查过程，最让我受益的不是最后那个补丁怎么打，而是中间那些走弯路的经历。

比如，最开始我怀疑是晶振选型问题，让采购调了一批不同厂家的样品，换上去测了一圈，没用。后来怀疑是电源管理芯片配置不对，翻了几百页的datasheet，逐行对寄存器，还是没用。那段时间团队里气氛挺压抑，大家嘴上不说，但都知道压力在累积。

转机出现在一次内部讨论会上。负责软件集成的老李随口说了一句：“会不会不是单点故障，是多因素耦合？”他这么一说，我才反应过来——我们一直在找“那个”原因，但问题可能压根不是一个原因造成的。

于是重新梳理。把问题拆成三层：供电、时钟、总线负载。每层列出可能的偏移量，然后组合测试。低温加低电压，pass；低温加高负载，pass；低温加低电压再加高负载——故障出现了。那一刻，好几个人围到电脑前，盯着波形图上那个迟到了47毫秒的报文，谁都没说话。然后不知道谁笑了一声，大家才跟着笑起来。

最后修复方案其实简单——调整唤醒任务的优先级，从5级提到3级，同时增加两次重试机制。代码改动不到二十行。但为了这二十行，前前后后折腾了一个月。

三

这一个月让我想明白一件事：技术问题从来不只是技术问题。

比如，为什么前期测试没发现？因为我们太依赖标准测试用例了，没想过把“低电压”和“高负载”这两个条件组合在一起跑。标准里没写，不等于现场不会发生。再比如，为什么售后老张能想到让我去现场？因为他天天跟司机打交道，知道那些人用车有多糙——电瓶亏电了硬撑，仪表黑了拍两下接着开。这些信息，报告里看不到，测试用例里也写不进去。

后来我带新同事，总爱唠叨一句话：别光盯着代码，多想想用代码的人是谁。代码是写给机器执行的，但机器最终是给人用的。如果你没见过那个在零下二十多度还舍不得进驾驶室休息的卡车司机，你很难理解他为什么宁可拍仪表盘也不愿停车报修——因为货必须按时送到，晚一小时罚款几百块。

迷你日记网（w286.coM）经典永流传系列: