嵌入式 Linux 开发会被 AI 取代吗?BSP 工程师和应用开发者的真实处境

一个朋友最近在面试，面试官直接问他："你觉得你自己三年后还有没有被雇佣的价值？"

这问题听着像刁难，但我觉得这是 2026 年每一个嵌入式 Linux 工程师都应该认真想一遍的问题。

AI 写代码这件事已经不是新鲜事了——GitHub Copilot 全球超过 2000 万用户，41% 的代码由 AI 参与生成。但嵌入式 Linux 这个圈子有它独特的复杂性：你不只是在写代码，你是在让 Linux 跑在一块可能从没见过 Linux 的板子上。

这里面的水，比你想的深。

很多人说"嵌入式 Linux 开发"，其实在说两件差别很大的事：

嵌入式 Linux 开发├── BSP 层（Board Support Package）│   ├── Bootloader 移植（U-Boot）│   ├── 内核配置与裁剪（Kconfig、DTS）│   ├── 设备驱动开发（字符设备、平台驱动、子系统驱动）│   └── 根文件系统构建（Yocto / Buildroot）│└── 应用层（Application）    ├── 系统级应用（守护进程、systemd 服务）    ├── 驱动用户态接口（ioctl、sysfs、netlink）    ├── 网络与通信（socket、MQTT、OTA 升级）    └── 业务逻辑开发

这两层被 AI 影响的方式截然不同。搞清楚这个，才能判断自己的饭碗有多稳。

Linux 内核社区其实已经在用 AI 了，而且用得很务实。

AUTOSEL 是 NVIDIA 工程师 Sasha Levin 写的工具，用多个 LLM 联合投票，每天自动筛选哪些 upstream 补丁值得 backport 到 stable/LTS 内核树。以前维护者每天要人工看 100 个补丁，只有 5~10 个值得 backport——这种重复劳动 AI 干得比人好，速度也快。

Btrfs 的作者、Meta 工程师 Chris Mason 也在搞 AI 辅助的 patch code review，把大段 diff 拆成小块，逐块让 LLM 审查，再汇总报告。

这些都是真实落地的 AI 应用，不是 PPT。

但是——

BSP 最硬核的挑战在于，你的目标平台可能是全球独一份的。

假设你在给一块基于 RK3568 的定制工业板做 BSP，板子上挂了一颗你们硬件团队自研的 FPGA，通过 SPI 连接，中断走的 GPIO 扩展器。

你让 AI 写这个驱动，它会给你一段"看起来很完整"的 spi_driver 代码：

staticintmy_fpga_probe (struct spi_device *spi){    struct my_fpga_dev *dev;    int ret;    dev = devm_kzalloc(&spi->dev, sizeof (*dev), GFP_KERNEL);if (!dev)        return -ENOMEM;/* AI 生成的代码在这里会自信地填上 SPI 参数 */    spi->max_speed_hz = 10000000;  /* 10MHz，AI 猜的，没有根据 */    spi->mode = SPI_MODE_0;        /* MODE_0，也是猜的 */    ret = spi_setup(spi); if (ret < 0)        return ret;/* 中断处理？AI 根本不知道你的 GPIO 扩展器型号 */    dev->irq = spi->irq;  /* spi->irq 在你这块板子上是 0，永远触发不了 */return0;}

这段代码能编译，甚至能 insmod 不报错——但它不工作。spi->irq 是 0，因为 AI 不知道你的中断实际上经过了 GPIO 扩展器（比如 PCA9555），DTS 里需要专门声明 interrupt-parent 和 interrupts。

AI 不读你的原理图，不知道你的硬件拓扑。 这个问题无解，除非你告诉它。

DTS 是 BSP 工程师的日常，也是 AI 最容易翻车的地方。

我测试过让 AI 写一个 I2C 温度传感器（LM75A）的 DTS 节点，以及对应的 Linux 驱动绑定。AI 给的结果：

/* AI 生成 */&i2c1{   lm75@48{       compatible="national,lm75a";        reg=<0x48>;        /* AI 忘了加这个，但你的板子需要 */        /* vs-supply = <&reg_3v3>; */    };};

漏了电源域声明，在有电源管理的系统上，传感器在 suspend/resume 之后挂掉，i2c_transfer 返回 -EIO，你要花几个小时才能定位到这里。

更糟的是，有时 AI 会编造根本不存在的 compatible 字符串。比如 "myvendor,custom-sensor" 这种，写进 DTS 能过编译，内核启动时找不到匹配驱动，设备静默地不工作，没有任何报错。这比崩溃还难定位。

Linux 内核没有稳定的驱动接口——这是官方立场，不是抱怨。

内核从 v5.10 到 v6.10，API 变化量巨大。AI 训练数据有截止日期，它给你写的 request_irq 参数列表可能对应的是旧内核，你用的是新内核，编译直接报错还算好的，运行时行为异常更麻烦。

有研究团队（DRIVEBENCH / AUTODRIVER）专门研究了这个问题：让 LLM 自动迁移跨内核版本的 out-of-tree 驱动，成功率在 74% 左右——这已经是优化过的结果了。换句话说，1/4 的驱动迁移还是要人来收尾。

/* Linux 5.x 写法 */ret = request_irq(irq, handler, IRQF_SHARED, "mydev", dev);/* Linux 6.x 某些场景推荐用 devm 版本 */ret = devm_request_irq(&pdev->dev, irq, handler,                        IRQF_SHARED, "mydev", dev);/* AI 可能给你混用，也可能给你一个已废弃的接口 */