室内三人剪影眺望城市天际线

先看技术：一个曾经拒绝 UEFI 的项目转向了

Libreboot 是替代专有 BIOS/UEFI 的自由开源引导固件。2026 年 10 月 15 日发布的 26.10 版（代号 Ominous Olive）里，最重要的技术变化是默认载荷换成 EDK2——Intel 的 UEFI 参考实现，经 MrChromebox 移植成通用的 coreboot payload。项目过去几乎不提供 UEFI，现在绝大多数主板（连很老的 ThinkPad X200 也包括）都用上完整的开源 UEFI，并且能引导 Windows 10/11、9front、各种 Linux UKI 与 systemd-boot、OpenBSD（EFI + GPT 分区）、FreeBSD（UEFI 模式，不再需要 txtmode）。ReactOS 不支持 UEFI，仍然不行。

233 个 Chromebook 和一堆老机器被救活

这一版从 MrChromebox 的 coreboot 项目导入了 233 个 Intel/AMD Chromebook 主板（Baytrail/Kip 已实测通过），由作者写的 util/mrimport 工具自动生成配置。AMD Fam15h 主板（例如 KGPE-D16）改用 15h.org 的 coreboot fork，用 AMD AGESA 源码替代原来的自定义初始化代码：内存初始化与 CPU 初始化可靠得多，支持更大内存，IOMMU 与 TPM 也正常了。想用现代显卡的用户，EDK2 配合 Resizable BAR 可以使用需要 4GB 以上地址空间的显卡，但 rebar 默认关闭——测试中它会让 libgfxinit 下的 Intel GPU 输出失效。

向后兼容的做法是把 GRUB 和 SeaBIOS 以 EFI 形式留在 flash 里，开机按 ESC 进 EDK2 菜单即可选用；纯 32 位的老主板仍沿用上一版的方案。

真正被讨论的，是那段反 AI 政策

作者在更新日志里写明：本版最重要的改动不是技术，而是新增的 AGENTS.md——一份立场强烈的反 AI 政策。项目表示不会采用任何“vibe coding”产出的分支，具体指向一个大量由 AI 生成的 U-Boot 分支，并计划今后审计 GCC、GRUB 等依赖项目中的 AI 辅助提交，必要时甚至自行 fork。给出的理由是维护者与用户之间的信任、贡献者的技能退化，以及对许可证与版权来源的不确定。

这只是一家之言，但它指出了一个所有团队都会碰到的问题：一段代码能不能进主干，标准应该是“谁写的”，还是“能不能被读懂、被验证、出了问题有人负责”？

对做企业数字化/小团队的实际启发

把两件事放在一起看很有意思：同一个维护者，一边用自写的自动化工具批量导入 233 个主板配置（能测试、随时能和上游 diff），一边拒绝 AI 生成的引导代码。差别不在工具，而在后果——主板配置错了当场能测出来，引导固件坏了就是砖。

给团队的规矩可以照这个思路定：对可回滚、可测试、能当场验证的环节，让 AI 放开手；对不可逆、不可测、故障代价高的环节，要么禁止 AI 直接产出，要么强制一个读得懂它的责任人签字。真正的风险从来不是“用了 AI”，而是没人能解释这段代码为什么能工作。