嵌入式 Linux 的世界里有两个「老家伙」：Buildroot 诞生于 2001 年，OpenEmbedded/Yocto 诞生于 2003 年。二十多年来，它们几乎是所有嵌入式 Linux 设备的构建系统标配，从路由器到汽车中控，从工业控制到 IoT 网关，几乎每个 SoC 和核心板厂商都会优先提供 Yocto 或 Buildroot 的 BSP。但在 2026 年，一个名为 yoe 的新项目站了出来，提出了一个直白的问题：是时候换一套新的构建系统了。

提出这个问题的是 yoe build 项目的作者——一位在嵌入式领域有超过 20 年经验的工程师。他在 6 月 11 日发表的文章中系统性地拆解了 Yocto/Buildroot 模型在当前技术环境中的结构性困境，并公开了他已经默默搭建了数月的新方案。这篇文章在嵌入式社区引发了大量讨论，因为它触及的痛点几乎是所有嵌入式团队的共同体验。

问题的核心可以用一句话概括：嵌入式产品已经变了，但构建系统没变。作者指出了三个关键的转变趋势。

第一，现代边缘设备的行为越来越像云服务。它们不再是一次烧录后冻结五年的固件，而是需要持续接收更新的动态系统。

第二，现代编程语言生态。Python 的 NumPy/PyTorch 背后牵着 C/C++/CUDA，JavaScript 项目链接着原生 C 库，vcpkg 管理着庞大的 C/C++ 依赖，这些生态几乎全部是在桌面和服务器环境下设计的，对交叉编译的支持要么不存在，要么需要大量人力去适配。Yocto 的应对方式是在构建过程中封锁网络访问，这意味着 pip、npm、cargo 等语言原生的包管理器完全无法直接使用，每个依赖都必须通过复杂的 do_fetch 配方手动映射。维护数千个这样的配方已经耗尽了 Yocto 社区的精力和资源，作者直言这是整个生态中最不可持续的环节。

第三，旧的取舍正在恶化。Yocto 的「一切从源码编译」哲学意味着漫长的构建时间和巨大的内存需求，而供应商提供的 BSP 常常冻结在三四年前的 Yocto 版本上，成为引入现代软件的事实障碍。

作者用一个精准的类比描述了当前的状态：开源社区给了嵌入式团队一栋装满房间和功能的大房子，但没有给他们维护这栋房子的工具。交叉编译是这栋房子里最老旧的管道系统，它在 2000 年代是合理的工程选择，那时目标设备的计算能力远不足以支撑本地编译。但在 AWS Graviton 和 Hetzner CAX 这类高性能 ARM 云主机已经普及的 2026 年，继续坚持交叉编译的理由已经越来越弱。

yoe 项目的设计方案正是从这个观察出发的。它的核心思路不是「做一个更好的 Yocto」，而是换一种完全不同的构建范式：在 ARM 硬件上进行原生编译，彻底消除交叉编译环节。之所以可行，是因为近年来 ARM 服务器硬件的性价比已经发生了质变——AWS 的 Graviton 系列和 Hetzner 的 CAX 实例提供了足够的性能，使得在云端用 ARM 机器为 ARM 目标设备编译软件不再是低效的方案，反而比维护一套交叉编译工具链更简单、更可靠。

在此基础上，yoe 直接使用 Alpine、Debian 和 Ubuntu 作为基础发行版，不需要像 Yocto 那样从零构建整个根文件系统。这意味着嵌入式设备的根文件系统可以直接继承这些主流发行版的包维护和安全更新体系，而不是依赖一个由嵌入式团队手工维护的并行包仓库。Python 的 pip 和 JavaScript 的 npm 可以直接在目标设备上运行，不需要像 Yocto 那样封锁网络、编写复杂的 do_fetch 配方来逐个适配每个语言生态的包管理器。Go 和 Zig 这类已经内置优秀交叉编译支持的语言也不再受限于构建系统的约束。构建缓存确保同一个软件组件不会被重复构建两次。

作者特别强调了小团队的困境，他特意澄清了「小」不等于「业余」。这些团队可能是只有几个工程师的创业公司，却要维护数百到数千台工业设备。他们没有财力雇佣专职的构建工程师，对他们来说，简单性和部署速度往往比二进制可重现性和全源码构建更重要。而 Yocto 的设计默认假设你有一个专门的团队来维护配方、处理交叉编译故障、给供应商 BSP 打补丁——这在现实中有大量团队做不到。

AI 在这个新方案中占了不寻常的位置。yoe 的终端用户界面（TUI）被设计为快速响应且支持交互式监控和深入调试——更重要的是，它的操作界面和错误信息被同时设计为「人和 AI 都能理解」。构建错误不再是以数千行原始日志的形式倾泻出来，而是被转化为清晰、可操作的提示，AI 代理能够直接理解和响应。

作者明确表示，AI 代理应该能够理解 yoe 的工具链，处理大部分低级别的构建和集成工作，比如为一个新的 Python 包添加构建配置、诊断编译错误、或管理依赖版本冲突。这实际上是在为「AI 辅助嵌入式开发」铺设基础设施：如果你期望 AI 编码助手在未来几年内能参与嵌入式项目的构建和调试，那么你的构建系统必须先变得对 AI 友好。一个输出可被人类和机器共同理解的构建系统，无论是对于只有两三个工程师的小团队，还是对于希望用 AI 加速开发的大型组织，都是一种新的能力杠杆。

yoe 目前处于 pre-1.0 的早期实验阶段，以 Apache 2.0 许可证开源。项目声称已经做到了「过去需要花一天时间与交叉编译斗争的工作，现在从想法到在目标硬件上运行只需几分钟」。分布式缓存和远程构建执行器等高级功能还在规划中。作者也明确表示，这并非要取代所有场景下的 Yocto，对于需要合规认证、比特级可重现性、完全从源码构建且刻意冻结多年的深度嵌入式受监管产品，Yocto 仍然是经过实战考验的正确工具。yoe 瞄准的是一个不同的设计点：动态的、持续连接的、用现代语言构建的、由小团队维护的嵌入式设备。这个关系就像 Alpine Linux 之于 Debian——前者没有取代后者，但回答了后者没有回答的问题。

嵌入式构建系统的创新在过去十年里近乎停滞。Yocto 社区多年来一直在与「配方维护」这座大山做斗争，数千个软件包每个都需要手工编写的配方来适配交叉编译，而 Python、Rust、Node.js 等现代语言生态的加入让这项工作的难度呈指数级增长。

作者在文章中提到的一个细节很有说服力：让一个 Python 包在 Yocto 中正确构建有时需要花费一整天的时间，而同样的包在 yoe 的原生编译模式下，从想法到在目标硬件上运行只需几分钟。这不是 Yocto 的错——它诞生在一个以 C 语言和 autotools 为主的年代，当时没有人能预见 pip、npm 和 cargo 会成为软件分发的主流方式。但问题在于，行业已经前进了，工具却没有跟上。

yoe 的价值可能不在于它最终能否取代 Yocto，而在于它敢于重新审视那些被整个行业默认为「既定前提」的假设：交叉编译是否仍然必要？一切从源码构建是否仍然合理？构建系统是否应该为 AI 时代做好准备？一个构建系统是否应该默认假设用户有一个专职的构建团队？这些问题在 Yocto 统治嵌入式 Linux 的二十年里几乎从未被认真问过，而 yoe 把它们摆到了桌面上。无论 yoe 最终能否获得社区和供应商的广泛支持，仅仅是让这些问题被公开讨论，就已经是对嵌入式行业的一次有价值的推动。

参考来源：yoe build: Is It Time for a New Embedded Linux Build System?