AI时代，汽车软件工程师的护城河在哪里？

写在前面：

这是我在日常工作中产生的一些思考，想分享给大家。

但首先需要说明：这篇文章的观点，是基于我已经有了几年工作经验的前提下产生的。 如果你是刚入行的初学者，请先看完全文，我对你的建议会有所不同。

一、一个让我反思的瞬间

最近看到费曼的一句话：“凡我不能亲手创造的，我便无法真正理解。”

这句话在程序员圈已经被引用过无数次。

刚入行时，我对此深信不疑。我觉得工程师就该深挖到底，理解每一个细节。于是我的学习路径是：

• • 从零配置一套完整的BSW栈
• • 手写一个复杂的通信驱动
• • 把所有模块的源码读一遍

然后觉得自己很硬核：”我理解了底层原理。”

但工作一段时间后，我的工作方式开始发生变化。

举个例子：

我接到一个任务，要写一个执行器电机（Actuator）的复杂驱动CDD（Complex Device Driver）。

我以前可能会这样想：“好，我要从零开始写一个完美的CDD，先研究规格书，再设计架构，然后一行一行写代码…”

但这次，我换了个方式：

第一步：我先看看团队里有没有类似的CDD可以参考

• • 发现之前有人写过电磁阀（Solenoid）的CDD
• • 还有一些其他执行器的驱动

第二步：我去GitHub上搜了搜，看看有没有开源项目

• • 找到几个相关的开源实现
• • 研究了一下他们的设计思路和代码结构

第三步：在这些基础上，我再开始写自己的CDD

• • 参考了电磁阀CDD的架构设计
• • 借鉴了开源项目的部分实现思路
• • 根据Actuator的特殊需求做了调整
• • 利用现在AI强大的Plan mode以及Coding能力，帮我先搭一个框架

结果：

• • 开发时间缩短了很多
• • 代码质量也不错（因为借鉴了成熟方案）
• • 我有时间去处理其他任务

那次经历后，我开始思考：“我是不是可以更多地利用现有资源，而不是每次都从零开始？”

二、但我必须强调：初学者还是要”Hand dirty”

在分享我的思考之前，我想先说一个非常重要的观点：

如果你是刚入行的初学者，我的建议是：一定要自己动手造轮子，一定要深入到底！

为什么？

2.1 初学者阶段必须经历的”造轮子”

初学者需要：

• • 体验完整的开发过程：从需求分析到代码实现，再到测试验证
• • 理解底层原理的来龙去脉：知道代码为什么这么写，而不是那么写
• • 积累”手感”：知道代码是怎么跑起来的，遇到问题该如何调试

初学者阶段的”造轮子”，不是浪费时间，而是必要的投资。

我自己也是这么过来的。刚入行时，我花了很多时间去：

• • 研读CanIf模块源码，理解每个状态机的转换
• • 手写CAN驱动，理解硬件寄存器的配置
• • 配置完整的BSW栈，理解模块间的依赖关系

这些经历，是我现在能够站在系统角度看问题的基础。这个阶段不可逾越。

2.2 什么时候可以调整工作方式？

当你有了一定经验后（比如1-2年实际项目经验），你可能会发现：

• • 不是所有细节都需要深入到底
• • 有些轮子造了，对解决真实问题帮助不大
• • 真正有价值的，是站在系统角度看问题

这就是我想分享的：有了经验后，如何调整自己的工作方式。

但请记住:初学者阶段，一定要Hand dirty！

三、我开始思考：系统本质在变化

有了工作经验后，我开始意识到一个问题：未来的系统本质，可能和以前不太一样了。

3.1 一个让我醍醐灌顶的观点

前段时间看到一段话，让我思考了很久：

“如果你天天沉迷于从零写一套Docker，你多半会完美错过这个时代最大的红利。”

很多人说：”AI替不了懂系统本质的人。”这话没错。

但问题是：未来的系统本质，已经不再是”如何用C写解释器”了。

未来的系统本质，是：如何将无数个黑盒（AI/SaaS/云原生），组合成能创造价值的系统。

这段话让我意识到：

• • 跟着教程造轮子，本质上是在用确定的步骤，获得一种”我很硬核”的心理安慰
• • 但真实世界的工程，永远没有标准答案
• • 在白纸上画画，永远不如带着脚镣跳舞

3.2 我以前关注的”系统本质”

刚入行时，我认为系统本质是：

• • 如何高效管理内存
• • 如何优化CAN总线负载
• • 如何配置一个完美的BSW栈
• • 如何手写一个可靠的驱动

这些仍然重要，但我发现它们正在变成”基础能力”，而不是”护城河”。

3.3 我现在开始关注的”系统本质”

工作一段时间后，我开始关注：

• • 如何将AI代码生成工具嵌入到开发流程中
• • 如何将云服务和车载系统无缝集成
• • 如何用SaaS工具加速测试验证
• • 如何在功能安全和开发效率之间找到平衡

更重要的是：如何让AI成为我的助手，而不是替代者。

3.4 AI时代的新能力：让AI Agent帮你解决问题

这是我最近在尝试的新工作方式：

以前：遇到问题 → 查文档 → 试错 → 再查文档 → 再试错现在：遇到问题 → 先用AI工具分析 → 快速定位方向 → 再深入研究

举个例子：

• • 我需要写一个复杂的配置脚本 → 用AI生成初版 → 自己优化和调试
• • 我需要理解一个复杂的协议 → 让AI解释核心概念 → 再去看标准文档
• • 我需要优化代码结构 → 让AI给出建议 → 自己评估和调整

核心思路：系统性思维 + AI工具 = 效率倍增

但这有个前提：你得有系统性思维，才能给AI正确的指令，才能判断AI的输出是否靠谱。

如果连问题都描述不清楚，AI也帮不了你。

这不是”不求甚解”，这可能是系统思维的升级。

四、我的工作方式变化：一个真实例子

前段时间，OEM要求2周内实现一个新的诊断功能。

4.1 我以前的做法

1. 1. 研读DCM模块源码，理解每个状态机（1周）
2. 2. 手写服务处理函数，确保每个细节都正确（3天）
3. 3. 调试各种边界情况，追求完美（4天）

结果：差点超期，虽然功能实现了，但时间花得有点多。

4.2 我现在的做法

1. 1. 快速评估：这个需求能不能用现成工具生成？（1天）
2. 2. 组合方案：用AI生成框架 + 手工优化关键路径（3天）
3. 3. 集成测试：用自动化工具快速验证（2天）

结果：提前交付，OEM满意，而且有时间处理其他任务。

4.3 我自己总结的差别

• • 以前：我想理解每一个细节再动手
• • 现在：我先找到最快、最可靠的解决路径

不是说细节不重要，而是要权衡时间、成本、价值。

在真实项目中，我慢慢学会了：理解核心细节，但不过度深挖所有细节。

五、我开始尝试”跨领域系统思维”

这是我现在正在努力的方向，也是我觉得最难但最有价值的能力：

不再只从”软件”角度看问题，而是试着站在系统角度，理解软件、硬件、机械之间的协作。

5.1 什么是跨领域系统思维？

以前我可能只会想：

• • 这个功能代码怎么写？
• • 这个模块怎么配置？
• • 这个接口怎么设计？

现在我会试着多问几个问题：

• • 这个功能对硬件资源有什么影响？（内存、CPU负载、通信带宽）
• • 这个设计对机械结构有什么要求？（传感器位置、执行器响应时间）
• • 这个方案对整个系统可靠性有什么影响？（故障传播、容错机制）

5.2 一个例子

前段时间做一个车身控制功能，我以前可能只会关注：

• • 软件逻辑是否正确
• • CAN信号是否稳定
• • 诊断功能是否完整

但我现在会试着多考虑：

• • 这个功能对电池寿命有什么影响？（硬件层面）
• • 这个控制策略对电机寿命有什么影响？（机械层面）
• • 如果传感器失效，系统如何降级？（系统层面）

站在系统角度看问题，而不是只盯着自己的模块，这是我现在正在锻炼的能力。

这很难，但我发现这能帮我更好地理解整个产品，也能和硬件、机械同事更好地协作。

六、我对自己能力模型的反思

工作几年后，我重新审视了自己的能力结构。

6.1 我觉得仍然重要的传统能力

• • ✅ 深入理解AUTOSAR架构（基础能力）
• • ✅ 熟练配置BSW模块（基本功）
• • ⚠️ 手写复杂驱动（工具链在进步，但理解原理仍然重要）

6.2 我开始注重的新能力

• • 系统整合能力：如何将AI工具、传统BSW、云端服务组合成完整解决方案
• • 真实问题解决：处理OEM的真实痛点，而不是配置完美的Demo
• • 工程思维：理解技术选择的成本/收益，而不只是技术本身
• • 跨界能力：理解车载网络、功能安全、网络安全、云服务的交集
• • 学习能力：快速掌握新工具、新架构、新方法论

我慢慢意识到：传统能力是”及格线”，新能力可能是”护城河”。

不是说传统能力不重要，而是它们可能正在变成”基础”，而不是”差异化竞争力”。

七、我尝试调整的工作方式（分享给大家）

7.1 我开始问自己三个问题

每次想深入细节或造轮子时，我会问：

1. 1. 这个轮子，有没有现成的解决方案？
2. 2. 造这个轮子，能帮我解决真实问题吗？
3. 3. 我的时间，花在这里是最优解吗？

如果答案都是”否”，我会考虑换个方式。

不是说所有轮子都不造，而是要权衡投入产出。

7.2 我尝试去解决真实问题

我发现自己成长最快的时候，往往是：

• • 去解决一个没人管的棘手问题
• • 去优化一个长期存在的性能瓶颈
• • 去简化一个复杂的配置流程

真实世界的约束（时间、成本、资源），反而让我学到更多。

在白纸上画画，永远不如带着脚镣跳舞。真实项目的压力，是最好的老师。

7.3 我开始建立自己的”工具箱”

不要只依赖一种工具、一种方法、一种思路。

我的工具箱包括：

• • 传统BSW开发能力（基础）
• • AI辅助工具（Claude、Codex、Copilot）
• • 自动化测试工具（Vector、ETAS，或者自己写自动化脚本）
• • 云服务和DevOps（CI/CD、容器化）
• • 工程分析能力（成本估算、风险评估）

系统性思维，可能就是”如何从工具箱里选择最合适的工具”。

7.4 我正在锻炼”跨领域思维”

这是我最近在努力的方向：

不要只从软件角度看问题，而是尝试：

• • 理解硬件资源的限制和特性
• • 理解机械结构的工作原理
• • 理解整个系统的可靠性要求

站在系统角度，而不是模块角度，这是我觉得最难但最有价值的能力。

八、我对自己工作方式的三个调整（分享给大家）

调整1：重新思考”深度”

我以前认为：深度 = 我知道CanIf模块的每一行代码我现在觉得：深度 = 我知道如何快速诊断CAN通信问题，用最优方案解决

不是不要求深度，而是深度的方向可能需要调整。

理解核心原理很重要，但不需要每个细节都深挖到底。

调整2：尝试拥抱”黑盒”，但要理解”接口”

我不需要理解AI模型的所有细节，但我试着理解：

• • AI能做什么，不能做什么
• • 如何给AI提供正确的输入
• • 如何验证AI的输出是否正确

理解接口，可能比理解所有实现细节更重要。

在AI时代，可能需要学会”如何使用黑盒”，而不是”如何打开每个黑盒”。

调整3：从”技术思维”转向”工程思维”

我以前：追求代码写得最优雅，技术实现最完美我现在：在时间、成本、质量的约束下，交付最优解

我发现：工程师的价值，可能不在于技术的完美，而在于问题的解决。这正是马斯克第一性原理。

工程思维，可能就是在约束条件下找到最优解的能力。

九、最后想说的话

站在公司或资本的角度，确实倾向于让我们成为一颗标准化的“螺丝钉”，或者一把趁手的“工具”——精准、高效、可替换。这是系统运转的逻辑，追求的是稳定和效率。

但站在个人成长的视角，我绝不能只甘心做一颗被动的零件。我们需要保持清醒的自我审视：我在这里积累了什么？我的能力边界在哪里？我是在被使用，还是在增值？

真正的成长，往往始于这种“工具属性”之外的主动思考。当我们开始思考自己如何成长，其实就是在夺回对自身价值的定义权。这种内生的驱动力，能让我们在日复一日的执行中，看见更远的路径。也正因为有了这份思考，当人生关键的岔路口出现时，我们才具备了选择的底气——不仅能看见选项，更能看清哪个选项通往自己想要的未来。

所以，成为一颗好螺丝钉是职业素养，但知道自己要成为什么样的人，才是人生的核心算法。

写给不同阶段的你

如果你是初学者（0-1年经验）：请忽略这篇文章大部分内容，你的第一要务是：

• • ✅ 多动手实践，自己造轮子
• • ✅ 深入理解底层原理
• • ✅ 把基础打牢，积累”手感”

如果你有一定经验（1-3年经验）：可以开始思考：

• • ⚖️ 如何权衡细节投入和问题解决
• • 🎯 如何站在系统角度看问题
• • 🔧 如何建立自己的工具箱

如果你是资深工程师（3年以上经验）：欢迎交流你的看法，我还在学习中。

在AI时代，我还在不断调整自己的工作方式。带着脚镣跳舞，可能是我们这代工程师需要学会的本事。

关于作者

迷路员，汽车嵌入式软件工程师，专注于AUTOSAR ASW/BSW开发。正在探索：AI时代的工程师成长路径、系统性思维的方法论。

延伸阅读：

• • 《人月神话》：工程 vs 技术的本质区别
• • 《系统之美》：系统性思维的入门经典
• • 《程序员修炼之道》：从工匠到工程师的转变

本文首发于公众号【迷路员笔记】，转载请注明出处创作时间：2026-03-18