夜班的焊台还热着，松香味压着嗓子，我把逻辑分析仪的夹子扣在SCL线上，屏幕上跳出一排不规整的方波——从机一直低着头不抬，像在闹情绪。那一刻我清楚，许多人简历里写的“熟练掌握I2C”，实则没遇到过“线被拉死”的现场。
这两年，我看过太多投递被拒的简历。词儿都写得美丽：精通C语言、熟悉多任务、熟悉各类协议。坐到面试桌前，一问“任务半夜崩了你怎么办”，有人就开始背API。我更关心的是：你有没有把崩溃现场还原过？有没有翻过栈回溯，找到那个超界的数组？企业要的，是能把问题按住的人，而不是把术语背熟的人。
说一个具体活儿。有次做环境节点，温度用SHT30，空气质量用一个气体传感器，主控是ESP32-C3。前期一切顺利，到了现场，串口日志卡住，设备不再应答。我把示波器探头扎上去，SCL一直被拉低，波形像被谁摁住。手摸了一圈，发现气体传感器的上拉电阻做成了10k，线长、干扰大，起不来。我把上拉换成2.2k，再把采样节奏挪到定时器中断里，现场恢复了。那天我对自己说一句：代码只是半条命，另一半在板子上。
也遇到过“会写，却跑不起来”的项目。某次做电池供电的监测终端，客户要求半年不充电。我把仪表放在桌上，看电流表的指针像小鸟一样扑腾，常态18mA，站不住。我把无线从Wi-Fi换成BLE，通讯改为事件驱动，主控深睡，传感器靠唤醒触发一次采样。电流掉到几微安的静态，上报瞬间抬起来再落下。不是我多机智，是在电源管理这件事上，得亲眼看见电流怎么动，再去改架构。那种“纸上谈省电”的写法，撑不过一周的实测。
去年去一家车厂的试验台，CAN网络像早市一样嘈杂。有同事用笔记本抓了一下午，还是找不到灯控模块偶发失联的缘由。我把报文一条条发现某个节点不按规矩发消息，周期忽长忽短，像拐弯时踩刹车。把这个“捣乱”的家伙隔离，再加上故障恢复逻辑，整车稳定下来。车规不是摆在PPT上的名词，它要求你在每一次异常里把风险打死。你要懂的不只是CAN的位填充，更要懂现场为什么会“翻车”。
许多新人跟我说，学完一个库就想投简历。我不太提议这个路子。真要入行，先把“看图纸”练出来。随手拿起一张原理图，能说清电源怎么稳、复位怎么触发、时钟怎么来；拿起万用表，能知道断在了哪儿；遇到蜂鸣器不叫，脑子里先过一遍“是不是IO没拉起来”“是不是驱动打错极性”。这些是你每天要用的手艺。
还有一栏常被忽视：项目怎么交付。有个同学在面试时讲智能路灯，说用了某套RTOS，说有远程更新。我问：你怎么处理更新失败的灯？他说“我们没遇到失败”。技术面直接结束。真正的项目，必须面对“边角”问题：有人会在拔电那一刻更新，有人的灯在极冷的夜里掉电压，有人会把固件包下载一半关机。你要把这些场景想全、测全、写全。简历里最有分量的，是你把一个坑填平的过程。
学习这事，我也走过弯路。刚入行那会儿，我把一本厚厚的手册从头到尾看了三遍，记了许多寄存器名。上板调试时，手还是发懵。后来我改了方法：新芯片到手先点一个定时器，再用它去驱动一件小功能，列如把采样做成固定节奏；遇到奇怪问题，不在电脑前打转，去现场，去拿仪器。周末我会玩一块RISC-V的小板，写最简单的外设，记录“这家架构中断怎么用”“它的睡眠模式醒来要几毫秒”。看起来慢，实则走得稳。
不同赛道有自己的“硬约束”。做车，安全等级是第一条，工具链严格，流程繁琐，你得习惯在规范里做创新。做IoT，成本和续航像两把尺子，随时量在你手上，方案能不能落地，关键是把每一毫安都算清。做边缘AI，模型不够轻，算力不够用，目标识别就会“拖影”，你要在算法和硬件之间拆桥重搭。做工业现场，泥水、油污、强干扰，设备不能崩，你需要的是“活过一夜”的抗性，不是“跑过一段时间”的好运。
我也有自我怀疑的时刻。有项目延期，客户催得紧，我坐在板子旁边想：是不是我做得太保守？那几天，我把测试计划缩了一半，先把骨架跑起来，再逐段加功能，及时把阶段成果给客户看。效果比我想象好。后来我清楚，稳不等于慢，稳是把风险提早拿出来，让问题“可见”。
给刚入行的朋友一条可执行的路径。先做三个小练习：计时提醒、传感器融合、无线上报。计时提醒让你搞清楚时间的来路，传感器融合逼你处理噪声、不稳定，无线上报把你拉到系统级思考。这三件做顺，再加一条远程更新的闭环：版本校验、失败回滚、断电保护。做完，你的简历就不再是“学过”，而是“交付过”。
说句实在话，这个行业不缺写代码的人，缺的是能把设备放进真实世界、还能在世界里活下去的人。我们做的每一个节点，每一行代码，最终都会挂在“数字城市”“智能工厂”的网络上。把手头的螺丝刀用好，把面前的示波器用透，把问题一个个拆开，这些不起眼的动作，会把你和企业的距离拉近。
下一次你再打开招聘软件，不用被薪资数字晃眼。先问自己两句：你能在夜里把故障定位到元件吗？你能在白天把项目讲到场景吗？能做到这两条，投出去的简历，不再像石头掉湖。你会发现，真正的门，是在现场被你推开的。
- 最新
- 最热
只看作者