1. 时代的尘埃，落在每个人头上都是一座山​

今年过年回家，感触最深的是和几个即将毕业的年轻人聊天。​

有个学机械的孩子，秋招投了一百多份简历，好不容易拿到两个 offer。一个是某车企的 “储备干部”，月薪六千，轮岗两年不定岗；另一个是家零部件厂。他说这话时努力挤着笑，但眼睛里没什么光。​

另一个学计算机的，本科还凑合，前几年师兄们随便进大厂拿三十万，今年班里找到工作的不到一半。有 offer 的也多是小公司，月薪还不如七年前他哥毕业时的起薪。他问我：“哥，你们当年也这么难吗？”​

我一时语塞。​

回家的路上，我想起几个发小。他们学历不高，有的高中毕业就去做了房产销售，有的赶上互联网金融的浪潮，从地推干起。当年大家都觉得他们辛苦，可几年下来，都在省会买了房，扎下了根。不是因为多优秀，就是踩中了那些年狂奔的赛道 —— 房地产、互联网、金融。风口一来，只要不懒，总能起飞。​

再看看今天这些拿着名校文凭却找不到工作的孩子，忽然明白什么叫 “时代的尘埃，落在每个人头上都是一座山”。个人的命运从来不是孤立的，它被行业、被周期、被时代裹挟着往前走。选对赛道的人，未必更聪明，只是更幸运。​

作为一个在汽车嵌入式行业摸爬滚打多年的软件工程师，看着今年汽车行业的内卷、价格战、裁员潮，我想聊聊这一年来我眼中的汽车嵌入式行情，以及如果想入这行，到底该怎么学。​如果想一起交流，欢迎可佳：AutoButo，这是写给那些迷茫的年轻人的，也是写给这个时代的。​

2. 2025 汽车行业现状：从 “黄金期” 到 “内卷时代”​

2025 年的汽车行业，已经不能用 “洗牌” 来形容了，更像是进入了贴身肉搏的 “内卷时代”。​

回想起来，早期的汽车行业其实是名校学生的 “学历避风港”。那时候是燃油车的天下，行业进展慢，论资排辈严重，卡学历卡得厉害，但好处是工作强度低。一个 985 硕士进来，工资可能不如互联网的一半，但胜在稳定、体面，能准时下班。​

后来新能源风口来了，资本红利像潮水一样涌进来，遍地都是新品牌。那时候只要你跟汽车搭点边，懂点皮毛，就能进新势力拿高薪。我见过刚毕业两年的年轻人，会调个 CAN 通信、能跑几个测试用例，跳槽就能开价三四十万。那是汽车行业的黄金期，好像谁都能飞起来。​

但到了 2025 年，潮水退下去了。​

行业的洗牌加剧，热度回归本质，对技术的要求却越来越高。这一年我的观察是：有技术的同事依旧能找到工作，但薪资涨幅普遍一般，不再有前几年那种 “跳一次涨 50%” 的疯狂。反而是那些在一个平台混了多年、或者做管理太久脱离技术的同事，突然发现简历投出去石沉大海 —— 他们卡在中间，上不去，下不来，成了最难的一群人。​

行业的红利期过去了，泡沫被挤破，留下的是真正干活的人。以前是 “会一点就能拿高薪”，现在是 “技术深度广度要有”。这就是 2025 年汽车行业的真相：机会还在，但只留给那些一直没放下技术的人。​

汽车行业有非常多细分岗位，做底盘、做车身、做动力、做座舱，五花八门。但要说薪资待遇最高的，还得是软件方向。​

而做汽车软件，绕不开的一个词就是 AUTOSAR。​

3. 汽车软件的核心：为什么绕不开 AUTOSAR？​

你去网上搜 AUTOSAR，翻来覆去就那点东西：三层架构、方法论、创立背景、各大车厂联合搞的标准。看完还是一头雾水 —— 这东西到底干嘛的？为什么车企非得用它？​

今天我们不谈那些宏观的描述，从汽车行业这个制造业的底层逻辑出发，聊聊为什么需要 AUTOSAR。​

很多学生接触嵌入式，都是从 51 单片机或 STM32 开始的。写个流水灯，调个 I2C，裸机跑一跑，觉得挺有意思。再进一步，学点 RTOS，搞搞任务调度，觉得自己已经入门了。​

但真进了汽车行业，会发现完全不是那么回事。​

汽车软件开发的第一个冲击，是高度细分化。你在学校里一个人能干完的事 —— 画板子、写驱动、调应用 —— 在这里被拆得极碎。有人一辈子只写某个传感器的驱动，有人只做诊断协议，有人只负责网络管理。这不是企业故意折腾人，而是行业用血的教训换来的经验。​

世界上第一条流水线诞生于福特，不是为了炫技，是为了稳定和效率。把一辆车的生产拆成几千个工序，每个工人只拧一颗螺丝，装配速度上去了，次品率下来了。汽车软件走的是同一条路：把复杂的系统拆成标准的模块，每个团队只负责自己那一块，最后拼起来能跑。​

这就是 AUTOSAR 存在的根本逻辑。​

在 AUTOSAR 的架构里，软件开发被清晰地分成三层：​

最底层叫微控制器抽象层，简单说就是把不同的芯片包装成统一的样子。不管你用的是英飞凌、瑞萨还是 NXP，上层看起来都一样。这样做的目的是什么？解耦。硬件换了，软件不用重写。​

中间层叫基础软件层，提供各种标准化的服务 —— 通信、存储、诊断、网络管理。这些是每个项目都要用的东西，没必要每次都重造轮子。AUTOSAR 把它们固化下来，像搭积木一样，需要什么功能就插什么模块。​

最上层叫应用层，这才是工程师真正写业务逻辑的地方。但有意思的是，这一层的代码完全不依赖硬件，也不关心底层怎么实现。你写的是自动驾驶策略还是车窗升降逻辑，和用什么芯片、用什么通信协议没有关系。​

这三层架构的背后，是汽车行业几十年的教训：硬件会变，需求会变，但架构最好别老变。把稳定的东西放在下面，把变化的东西放在上面，这样车厂才能活得不那么累。​

回到开头，为什么从单片机入门的人进车企会觉得不适应？因为在单片机的世界里，一个人就是一支队伍。但在汽车行业，一支队伍只做一件事。这不是个人能力的倒退，是工业逻辑的必然 —— 当系统复杂到一定程度，只有标准化和细分化，才能让几百号人协作不出乱子。​

AUTOSAR 不是什么高深的技术，它是汽车行业走向成熟的标志。就像福特流水线一样，把拧螺丝这件事做到极致，才能造出可靠的车。​

AUTOSAR 的本质是什么？​

用一句话让懂 STM32 的同学理解：AUTOSAR 就是汽车行业的 “标准化操作系统层”，它把不同芯片的底层寄存器操作封装成统一的 API 接口，让你写应用层代码时不用关心用的是英飞凌还是瑞萨，就像你用 STM32 的 HAL 库不用关心寄存器地址一样 —— 只不过 AUTOSAR 比 HAL 库庞大和复杂得多。​

说白了，HAL 库让你在不同 STM32 型号之间迁移代码，AUTOSAR 让你在不同芯片厂商、不同车企之间迁移代码。它是整个行业一起维护的一套 “超级 HAL 库”，只不过这套库的体量和对安全性的要求，远超你之前接触过的任何嵌入式项目。​

​​

4. 入门 AUTOSAR 的 3 个基础前提​

一、C 语言：不是会写，是能读懂工业级代码​

不需要你是 C 语言专家，但要能看懂指针、结构体、回调函数、内存管理。B 站找个播放量高的课，花两周过一遍。AUTOSAR 代码不花哨，但对规范性和可读性要求极高。​

二、英文阅读：不是考四六级，是能啃文档​

两个原因：一是 AUTOSAR 规范全是英文，每个模块几十上百页，你得能快速找到重点；二是芯片手册、数据手册、驱动说明，官方版本基本都是英文。不需要多流利，但要有硬着头皮读下去的耐心。​

三、嵌入式系统知识：懂基本概念就行​

寄存器、中断、时钟、GPIO、PWM、CAN 通信、I2C/SPI、DMA、看门狗 —— 这些概念不用全精通，但得听说过、知道是干什么的。很多人是进行业后慢慢补的，但基础越扎实，学 AUTOSAR 时就越能理解它为什么这么设计，而不是死记硬背。​

5. AUTOSAR 正确学习路线：从 CAN 通信切入（5 步落地）​

很多刚接触 AUTOSAR 的同学，第一反应是去找代码、看源码，想从一行行 C 语言入手。这其实是走错了方向。

AUTOSAR 的本质，是基于规范的配置开发。​

传统嵌入式开发是你亲手写代码：初始化 CAN 控制器、配置波特率、写中断服务函数、组包发送。而在 AUTOSAR 里，这些都不用手写了 —— 你拿着规范文档，通过工具把需求 “填进去”，工具帮你生成代码。你更像一个配置工程师，而不是码农。​

所以学习 AUTOSAR 的正确姿势，不是从 “先学哪行代码” 开始，而是从宏观配置逐步下沉到微观理解。下面我用CAN 通信这个最典型的场景，串起整个学习路线，让你知道每一步该学什么、学到什么程度、有什么用。​

学习路线图（用 CAN 通信串起来）​

第一步：理解分层架构 → 搞清楚 “三层分别干什么”​

先别扎进细节，脑子里得有这张图：​

应用层（Application Layer） → 你写业务逻辑：比如“车速信号发出去”​
↓​
运行时环境（RTE） → 应用和底层的“快递员”，把车速数据传给下层​
↓​
基础软件层（BSW） → 提供通信服务：CAN协议栈就在这里​
↓​
微控制器抽象层（MCAL） → 直接操作CAN寄存器，发0和1到总线上​​

CAN 通信在 BSW 层被拆成一堆模块：Com（信号打包）、CanIf（CAN 接口）、Can（驱动）、CanTp（传输协议）…… 各司其职。这一步不要求你记住每个模块，但要理解：发一个 CAN 报文，要经过这么多层的处理。

​

第二步：掌握工具链 → 学会 “怎么配置 CAN”​

Vector DaVinci → 配置CAN通信矩阵（DBC文件怎么导入、信号怎么映射）​
EB tresos → 配置MCAL层的CAN参数（波特率、引脚、中断优先级）​​

这一步是上手干活的关键。以前你要手写 CAN 驱动，现在打开工具：​

• 导入 DBC 文件，把 “车速信号” 拖到某个 CAN 报文里​
• 配波特率：250k 还是 500k​
• 配中断：接收中断使能，优先级设几级​

工具把规范变成了界面，你负责 “点对选项”。能独立完成一套 CAN 配置，你就已经可以开始干活了。​

第三步：精读核心模块规范 → 理解 “为什么这么配 CAN”​

​

CAN通信堆栈规范：​
- Can模块：怎么配硬件寄存器相关的参数​
- CanIf模块：多个CAN通道怎么管理​
- CanTp：超过8字节的大数据怎么分包发送（ISO 15765）​
- Com模块：信号怎么打包、周期发送还是事件触发​​

这时候回头看工具里的选项，才真正看懂：原来我点的 “周期发送周期 20ms”，背后是 Com 模块的规范里规定好的行为。原来大数据的拆包组包，是 CanTp 模块按 ISO 15765 标准实现的。这一步是从 “会用工具” 到 “懂 AUTOSAR” 的跨越。​

第四步：深入代码与调试 → 从 CAN 配置回到微观​

​

生成的代码长什么样？ → 打开Com_Cfg.c，看信号配置表怎么生成的​
数据流怎么走的？ → 应用层写一个车速值，追踪到RTE，再到Com，再到CanIf，最后Can硬件发送​
出了问题怎么调？ → CANoe抓总线数据，对比配置里的周期和信号对不对​​

这一步是分水岭。当你用 CANoe 抓到总线上确实每 20ms 跳出一个车速报文，点开看信号值就是你写的那个数 —— 你会真正理解：原来我点的那些配置，生成的代码是这么跑的。能独立调试一个问题，才算真正入了门。​

第五步：项目实战 → 用 CAN 通信做个完整例子​

​

拿一个开发板（TC275、S32K）：​
1. 配好CAN通信（波特率500k，接收中断）​
2. 应用层写一个任务：每10ms发送“0x55”到CAN总线​
3. 配一个接收信号：收到某ID报文就点亮LED​
4. 生成代码、烧录、用CANoe验证​​

没有实战，前面全是纸上谈兵。只有自己把一个 CAN 通信的 demo 完整跑起来，那些分层、模块、配置才真正变成你的东西。遇到问题、解决问题，这个闭环走完，你就知道 AUTOSAR 到底是怎么回事了。​

总结一下学习逻辑​

宏观分层（CAN 模块在哪层）→ 工具配置（配 CAN 参数）→ 规范理解（为什么这样配 CAN）→ 微观代码（CAN 代码怎么跑的）→ 项目实战（写个 CAN 收发程序）​

从 “怎么配 CAN” 入手，先能发报文；再追问 “为什么这么配”，真正理解 CAN 协议栈设计；最后下沉到 “代码怎么跑的”，彻底通透。​

这就是 AUTOSAR 的学习路线：从上往下走，而不是从下往上爬。​

6. 总结：技术，是时代浪潮里的定海神针​

这些年，见过太多人起高楼、宴宾客、楼塌了。风口来的时候，猪都能飞；潮水退的时候，才知道谁在裸泳。那些靠运气赚的钱，最后都靠实力亏了回去。而那些一直没放下技术的人，反而稳稳当当走到了现在。​

身处这个时代，我们确实被裹挟着往前走。行业的周期、资本的流向、政策的转向，都不是我们能左右的。但有一件事我们可以自己说了算：今天有没有比昨天多懂一点，有没有把手头的事做得更好一点，有没有对得起自己吃的这碗饭。​

技术的路，从来都不是最快的路，也不是最光鲜的路。但它是一条踏实的路 —— 你付出一分，它就回报一分；你走一步，脚下就实一分。​

所以，如果你刚入行，觉得 AUTOSAR 好难、规范好厚、工具好复杂，没关系。慢慢啃，一点点试，错了就改，不懂就问。那些让你头疼的坎，跨过去之后回头看，都是风景。​

如果你在行业里浮沉了几年，觉得累了、倦了，不知道坚持下去有什么意义。那就想想当初为什么入这一行 —— 不是为了发财，不是为了成名，就是单纯觉得，能让一堆代码跑起来，让硬件听话，挺酷的。​

时代的浪潮起起落落，我们左右不了潮水的方向。但只要手里有活，心里有光，潮退的时候，你总能站在岸上。​