BIOS AI辅助开发已经成熟了吗?它将会把我们带向何处?

回答这个问题，我们得先跳出 BIOS 这个细分领域，看看这场 AI 革命正在沿着怎样的脉络席卷整个产业。很多人最初的预判，是 AI 会先替代重复性强、技术门槛低的蓝领劳动，再逐步渗透到需要脑力的白领岗位，但现实的演进恰恰走向了相反的方向。这场技术变革的核心逻辑，是从大脑到身体、从白领到蓝领的替代路径 ——AI 最先击穿的，从来不是物理世界里的体力劳动，而是数字世界里依赖符号逻辑、知识沉淀与规则化创作的认知劳动。蓝领劳动的全面替代，需要实体机器人硬件、运动控制、环境感知与适配的全链条技术成熟，需要突破物理世界的无数非标约束，而程序员的工作，本身就生长在数字世界的原生土壤里，是 AI 最擅长、也最容易落地的战场。我们不得不承认，作为数字世界规则的构建者，程序员群体，恰恰站在了这场替代浪潮的最前沿。

而在程序员这个群体内部，替代的节奏也绝非齐头并进，而是沿着一条清晰的路径逐级渗透：从上层软件到底层软件，从外围软件到内核软件。上层应用开发，无论是前端页面构建，还是业务后端的逻辑实现，都有着成熟的标准化框架、海量的开源代码样本、清晰的需求边界与可快速闭环的测试验证体系，AI 可以在这个体系里快速完成代码生成、迭代优化甚至全链路交付，这也是我们看到 AI 最先在应用开发领域掀起效率革命的核心原因。但越往技术底层走，情况就发生了变化。代码与硬件的耦合度越来越高，通用可参考的开源样本越来越少，调试的复杂度与对硬件环境的依赖度越来越强，需求的非标性也越来越突出，AI 的渗透难度便随之逐级抬升。从 SaaS 应用到操作系统内核，再到工业级嵌入式开发，这条技术链条上，AI 的替代节奏呈现出明显的梯度放缓，而我们所处的 BIOS 开发领域，恰恰位于这条链条的最深处。

如果把整个软件开发产业比作一组层层嵌套的同心圆，最外层是边界清晰、样本海量的泛互联网应用开发，向内依次是标准化程度较高的企业级软件开发、场景多样的通用嵌入式软件开发，而越往内核走，领域的专业壁垒越高、硬件耦合度越强、通用样本越稀缺，位于同心圆最核心的圈层之一，便是我们深耕的 BIOS 与固件开发。

作为嵌入式软件开发的一个特殊子集，BIOS 开发有着两个极为鲜明的 “二八定律”，正是这两个特征，让它在 AI 替代浪潮里，比其他软件开发领域显得更 “抗造”，替代节奏也慢了许多。第一个二八定律，是 BIOS 开发中 80% 的代码，都与特定的硬件强相关。不同于上层软件可以在通用的操作系统环境里实现跨平台复用，BIOS 代码直接对接 CPU、芯片组、主板硬件的底层寄存器、时序规范与接口定义，每一款新的硬件平台，都需要做针对性的适配与修改，几乎不存在可以完全通用的代码，这就意味着 AI 很难通过海量的通用样本学习，直接生成可用的代码。第二个二八定律，是 BIOS 开发中 80% 的工作量，都集中在调试、移植、问题定位与兼容性修复，而非从零到一的代码创作。我们这行的人都懂，BIOS 开发最磨人的，从来不是写一段驱动代码，而是对着串口打印的几万行日志，找一个因为寄存器时序错了一位导致的启动失败，是在新平台 bring up 的时候，连串口都出不来，只能靠示波器一点点抠信号的绝望时刻，是在不同硬件平台之间做移植时，把无数个硬件相关的宏定义、回调函数、驱动适配一一对应校准的繁琐工作。这些工作极度依赖工程师对硬件行为的深度理解，依赖在无数次踩坑中积累的调试经验，很难通过简单的代码生成完成，这也是很多同行觉得，BIOS 开发很难被 AI 替代的核心原因。

但难被替代，绝不代表不会被替代，更不代表这个领域不适用于 AI 技术的赋能。很多人陷入了一个误区，觉得 AI 在 BIOS 领域不好用，是 AI 本身的能力不行，却忽略了一个核心问题：我们有没有找到适配 BIOS 开发场景的正确方法论。这让我想起了第二次工业革命的历史，电气时代取代蒸汽时代的标志性转折点，从来不是电的发明，而是整个工业生产流程的彻底重构，让整个工业体系适配电气的特性，而非把电机硬塞进蒸汽机的传动轴里。在蒸汽机时代，工厂的布局完全围绕着中央传动轴与皮带轮展开，所有的生产设备都必须围着动力源排布，而电力的出现，让动力可以分布式部署到每一台设备上，只有彻底重构了工厂的流水线、生产流程与管理体系，才能真正释放电气的全部威力。同样的道理，现在很多团队用 AI 辅助 BIOS 开发，还停留在把 AI 当成一个高级代码补全工具的阶段，让它写个简单的函数、查个寄存器定义、解释一段 UEFI 规范代码，这就像当年把电机装在蒸汽机的传动轴上，根本没有触碰到 AI 的核心价值，自然会觉得 AI 不好用、不实用。要真正用好 AI，甚至未来实现 AI 主导的 BIOS 开发，我们必须从根上改造已经沿用了十几年的 BIOS 开发工作流，让整个开发体系适配 AI 的能力边界，而非让 AI 去迁就我们早已习惯的手工开发模式。

事实上，在整个软件开发领域，已经有不少先行者验证了这个逻辑。目前业内广受认可的 AI 辅助开发实践，比如 Superpowers 与 gstack，它们的核心价值从来不是一个更强大的代码生成工具，而是一套完整的、AI 原生的开发工作流。我们必须承认一个事实：AI 生成代码的质量，除了模型本身的能力之外，如何组织它的工作方式，如何给它设定清晰的边界、输入完整的上下文、规范标准的输出格式、建立可闭环的验证反馈机制，往往起到了更决定性的作用。那些真正能把 AI 的效率释放出来的实践，无一不是把软件开发的全流程，从需求拆解、架构设计、模块拆分、代码生成、单元测试、集成验证到问题修复，全链路拆解成了 AI 可以标准化执行的步骤，给每一个节点设定了明确的输入输出规范、校验规则与错误回滚机制，让 AI 不是在无边界的自由创作，而是在一套严谨的工程化体系里，完成可验证、可追溯、可迭代的标准化任务。这也是为什么同样的大模型，有些团队用起来能把开发效率提升数倍，有些团队却只能生成一堆看起来能用、一跑就崩的废代码，核心的差距，就在于有没有这套适配 AI 的工作流体系。

基于这样的认知，我们团队在过去一年多的时间里，在 AI 辅助 BIOS 开发领域做了大量的落地探索，也和业内多家头部的 BIOS 厂商、芯片厂商与整机厂商做了深入的技术交流与经验互换，沉淀出了我们认为当前阶段 BIOS AI 辅助开发的三个核心要素，也是我们的三板斧：第一要素，是选择一个足够强大的大模型，这是整个体系的大脑。BIOS 开发对大模型的要求，远高于普通的应用开发场景，它不仅需要模型具备极强的代码理解与生成能力，更需要模型拥有扎实的硬件知识储备、对 UEFI 规范与 x86/ARM 等体系架构的深度理解、超长上下文的处理能力，以及足够严谨的逻辑推理能力，来最大程度减少幻觉的产生，这是整个体系的基础，没有一个合格的大脑，后续的所有设计都无从谈起。第二要素，也是我们投入精力最多的部分，是试图改造一套完全适配 BIOS 开发与调试场景的 AI 原生工作流，这是整个体系的行动手册。我们改造了一些成熟的工作流，希望打破传统 BIOS 开发中，以工程师个人经验为核心的线性流程，把 BIOS 开发的全生命周期，从新平台 bring up、驱动移植、功能模块开发、硬件兼容性调试、问题定位到回归测试，全链路拆解成了 AI 可执行的标准化节点，每一个节点都有明确的输入，比如硬件 spec 文档、芯片勘误表、UEFI 核心代码库、上一节点的输出成果，也有明确的输出规范与校验规则。并且要求改工作流，深入嵌入到我们已有的CI/CD中。第三板斧，是沉淀一整套可复用、可迭代的 Skills。把我们几十年积累的 BIOS 开发调试经验，进行固化与标准化的载体，业内也有一种调侃的说法，叫把工程师的经验 “蒸馏” 成 AI 可调用的能力。我们都知道，BIOS 开发最核心的壁垒，从来不是对 UEFI 规范的字面理解，而是无数代工程师在踩坑中积累的隐性经验，比如不同芯片组的常见适配坑点、启动异常的快速定位流程、调试日志的异常特征识别、跨平台移植的核心校准要点。我们把这些原本只存在于资深工程师脑子里的隐性知识，拆解成了一个个 AI 可以理解、可以调用、可以执行的标准化 Skill，比如我们已经落地的 Byo 开发调试系列 Skills、Byo 平台移植 Skills 等等。当 AI 遇到对应的开发场景时，可以直接调用这些经过无数次验证的经验流程，而非凭空生成内容，这从根本上解决了 AI 最致命的幻觉问题，让它的输出始终在我们可控的、经过验证的经验框架之内。

在这套体系的落地过程中，我们还认识到：这套工作流与 Skills 体系，从来不是一劳永逸的静态产物，而是一个需要持续迭代、螺旋上升的动态体系。现在的大模型市场，竞争与技术演进的速度快得惊人，几乎每隔几个月，就会有能力大幅提升的新模型出现，我们的所有工作，都必须跟着大模型的能力演进，持续进行调整与优化。有些我们当初花了很大精力拆解、打磨的 Skills，随着新一代大模型的能力升级，模型本身已经原生具备了对应的能力，甚至做得比我们的 Skill 更完善、更高效，那这个 Skill 就失去了存在的意义，需要被淘汰；还有一些 Skill，在早期模型逻辑能力不足的时候，我们需要把流程拆解得极细，给它非常多的约束与提示，才能保证输出的准确性，而随着模型推理能力的提升，我们可以把多个细分的 Skill 合并成一个更完整的模块，给 AI 更大的发挥空间，进一步提升开发效率。所以，大家需要不断评估哪些经验应该继续沉淀，哪些可以交还给模型本身，哪些需要重新设计。这种动态调整，本身就是未来工程能力的一部分。我开玩笑称作，这是一种产生Skills的Skill，也许这才是我们在后AI辅助开发时代的真正能力。

写到这里，我们终究要面对那个所有人都关心的问题：未来到底会是什么样子？我没法给出一个确定的答案。我不知道未来会走向人机对立，终结者的灰暗时间线，还是会迎来 AI 解放生产力、物质极大丰富，人类只需要专注于自己热爱的事情的极乐净土，这是整个人类社会需要共同面对的命题。但有一个事实，是板上钉钉、无可逆转的：我们靠手敲代码吃饭的日子，真的持续不了多久了。我的判断是，快则 2 年，慢则 5 年，数字世界里的绝大部分代码，都将不再由人类手工编写。我们这代工程师，从入行的第一天起，就被教育 “代码是工程师的立身之本”，“手写代码的能力是核心竞争力”，但现在，这个我们坚守了一辈子的根基，正在被 AI 以不可逆的方式彻底撼动。在技术浪潮面前，与趋势作对是最愚蠢的事情，就像汽车出现的时候，再优秀的马车夫，也不可能靠马鞭跑得过发动机，我们唯一正确的选择，就是放下对 “手写代码” 的执念，学会把 AI 为我所用，在这场浪潮里御浪前行，而非被拍在沙滩上。

而具体到我们 BIOS 行业的每一位从业者，未来的职业路径也会出现极为清晰的分化。首先是高级 BIOS 工程师，他们在短时间内会变得更加紧俏，但工作内容会发生根本性的重构。他们不再需要天天坐在电脑前手写代码、单步调试，核心价值会从代码的创作者，转变为 AI 的掌舵人与守门人。在项目前期，他们的核心工作是与 AI 进行头脑风暴，拆解客户的核心需求，定义系统的整体架构，设定硬件适配的核心边界与关键指标，给 AI 划定正确的航行方向；在项目中期，他们需要监督 AI 把整体架构拆分成可执行的模块任务，校验每个模块的设计合理性，提前规避潜在的硬件兼容风险与架构缺陷；在项目中后期，他们的核心精力会放在 review AI 生成的核心代码，审核测试验证的结果，尤其是那些与硬件强相关、AI 最容易出现幻觉的关键环节，把好技术的最后一道关，防止出现致命的错误与疏漏；甚至包括与客户的需求沟通、方案交付、现场问题响应，都可以由 AI 完成初稿与基础工作，高级工程师只需要做最终的把控与校准。他们的核心竞争力，不再是写代码的速度与熟练度，而是对 BIOS 体系、硬件架构、行业规范的深度理解，是对 AI 输出的判断力与纠错能力，是把控整个项目方向的架构设计与风险管控能力。

受冲击最大的，是中级 BIOS 工程师群体。中级工程师的核心工作，通常是在资深工程师定好的架构框架内，完成具体模块的开发、移植、调试，解决开发过程中的常见技术问题，完成标准化的测试与验证工作，而这些工作，恰恰是 AI 最擅长、也最快能完全替代的。一套成熟的 AI 工作流，加上经过验证的 Skills 体系，AI 可以在几个小时内，完成一个中级工程师一周甚至更久才能完成的工作，而且代码的一致性更高，出错率更低，还可以 24 小时不间断工作。对于中级工程师而言，如果不想被 AI 替代，唯一的出路，就是尽快沿着技术阶梯向上攀登，把自己的能力从 “执行代码、完成既定任务”，升级到 “架构设计、方向把控、风险预判”，从一个代码的执行者，转变为 AI 的管理者、规则的制定者，否则，被替代只是时间问题。

反而是初级 BIOS 工程师，会拥有一段短暂的安全期。BIOS 开发有一个极为特殊的行业门槛，就是硬件的物理可达性。很多调试、验证工作，必须在实体的硬件开发板上进行，需要手动连接串口、配置调试器、烧写固件、复现问题，甚至需要配合硬件工程师做信号测量与硬件排查，这些发生在物理世界的工作，AI 暂时还无法完全替代，需要人在现场完成。还有大量的客户现场支持工作，需要工程师到现场对接需求、调试硬件、解决适配问题，这些也是 AI 短期内无法覆盖的场景。但我们必须清醒地认识到，这个安全期不会太长，随着远程调试硬件的普及、机器人技术的成熟，这些需要手工操作的物理工作，迟早也会被替代。现在的这段安全期，只是给初级工程师留了一个宝贵的窗口期，让他们能快速积累经验、提升能力，完成从初级到中高级的跨越，而不是躺平在这些终将被替代的基础工作里。

写到最后，终究还是要回到那个终极问题：当 AI 真的能完成绝大部分代码工作，我们的工作到底在哪里？我给不出答案。这不是 BIOS 行业自己的问题，而是整个社会运行机制的系统性重构，是需要整个社会的制度设计、分配体系、价值认知共同进化，才能解决的宏大命题，这需要真正的大智慧。而我们作为身处浪潮之中的技术从业者，能做的，从来不是抗拒变化、固步自封，而是始终保持开放的心态，学会驾驭新的技术，把 AI 变成自己手里的利器，而非对立的敌人。在这个技术剧变的时代，唯一不变的，就是变化本身；唯一能让我们始终立足的，从来不是我们手里写了多少行代码，而是我们对技术本质的理解，是我们拥抱变化、驾驭新技术的能力。毕竟，代码会被 AI 替代，但对计算机体系底层逻辑的理解，永远不会过时。好吧，也许是暂时不会过时。。。

我开源了这个Skill，方便大家进行UEFI App开发

GLM5.1写UEFI打飞机游戏：两轮一遍过，比GLM5进步明显

GLM5 用 2.5 小时完成，Qwen 用了 4 小时还在编译—— Claude Code + qwen3.5-plus UEFI 打飞机游戏开发实录