简介：AI编程助手能否胜任语料稀缺、门槛极高的固件开发？本文设计了一场规则严苛的实战：零本地代码库、零人工编码、几乎不提供专业指导，让AI全程自主开发一个可在UEFI Shell中运行的中文图形界面打砖块游戏。文中详解实验设计、技术难点拆解、模型选型与成本权衡，帮你看清AI编程的真实能力边界与效率红利。
一、底层开发真是AI的禁区吗？
围绕“AI能否胜任底层开发”，业界长期存在一种颇为悲观的论调：硬件编程、寄存器操作、固件协议栈，这些领域公开语料稀少、专业门槛极高，AI缺乏必要的专业理解，终究还是要靠经验丰富的工程师手工编写。在BIOS/固件圈子里，“AI力有不逮”几乎是许多从业者的默认判断。
这种说法并非全无道理。底层开发对AI确实存在三重不利因素：其一，语料稀缺。与Web、移动端动辄海量教程、问答和开源实现相比，固件开发的公开素材少得多，模型在预训练阶段能“见过”的相关内容非常有限。其二，知识分散。协议规范、芯片手册、平台参考代码彼此割裂，且大量关键信息沉淀在企业内部，外界难以触达。其三，验证困难。固件层缺乏成熟的自动化测试与调试手段，代码错误可能直接导致硬件无法启动，试错成本远高于应用层。
但据此断言AI不行，忽略了两个关键事实。
第一，知识缺口可以用工程手段弥补。把协议规范、内部手册、历史代码接入本地知识库，配合检索增强让AI“先查资料再回答”；把项目约束固化到上下文说明文件，让AI在长会话中始终记得目标环境。AI的短板在“记忆”，而记忆恰恰是最容易被工具补齐的部分。
第二，底层开发并非铁板一块。不同类型的工作，AI能提供的价值差异极大，一刀切的判断没有讨论意义。
二、重新拆解底层开发：两类工作，两种辅助路径
以BIOS开发为例，日常任务大体可归为两类：
创造性编程：设计新功能、实现新算法、搭建应用框架，瓶颈在思路与结构。AI擅长快速给出多种可行方案、解释技术取舍、生成骨架代码，工程师则专注于判断与打磨，双方形成互补。
移植类工作（Porting）：适配新硬件、迁移新平台。这类工作模式化程度极高——配置寄存器、调整引脚定义、修改内存映射，大量是“在既有代码上做规律性修改”的重复劳动。恰恰是这些最消耗工程师时间、创造性含量却相对有限的工作，AI的辅助收益最为立竿见影。
无论哪一类，AI带来的提升都不止于“代码写得快一点”，而是开发范式层面的重构：工程师从“逐行实现者”转变为“目标定义者与结果验收者”——人描述意图与约束，AI产出实现，人负责审查、测试与迭代。一旦流程跑通，效率提升是成倍的，而流程重构本身，正是AI辅助开发最大的红利所在。
当然，这一切成立的前提是：AI必须真的能啃下底层环境的硬骨头。与其争论，不如实测。
三、挑战设计：把条件限制到近乎苛刻
为了让测试结论有说服力，我为实验设定了四条严格规则：
这四条规则的目的只有一个：排除一切人为借力，逼近AI能力的真实上限。道理很简单——如果AI在如此苛刻的条件下仍能完成目标，那么在真实项目中（有知识库、有参考代码、有人工协作）的表现只会更好；反之，实验结果就为“AI不行论”提供了实锤。
四、目标设定：UEFI Shell下的中文图形界面打砖块游戏
本次挑战的目标是：开发一个能拷贝到U盘、插入电脑、进入固件Shell环境即可直接运行的图形界面打砖块游戏，并支持中文显示。
为什么选择打砖块作为试金石？这是我多年的测试习惯，理由有四：结构清晰，挡板、小球、砖块、边界，实体数量适中，复杂度可控；逻辑完整，天然覆盖游戏主循环、状态机与输赢判定，是“麻雀虽小、五脏俱全”的完整系统；覆盖核心要素，图形渲染、用户输入、碰撞检测，这三样几乎是所有交互式程序的地基；结果可验证，能不能跑、画面对不对、手感好不好，一目了然，不存在模糊地带。
此前我在Web环境和其他嵌入式平台上做过同类测试，这次把战场换到固件环境，复杂度显著提升，核心难点可以概括为四个字——支撑缺失。具体来说：程序要以独立应用形态直面固件标准接口，没有操作系统、没有运行时库、没有窗口系统兜底；图形渲染依赖固件提供的图形输出协议，帧缓冲管理、分辨率适配、像素格式处理都要自己实现；键盘输入要走固件的事件输入接口，按键状态映射需自行维护；中文显示最为棘手，固件默认字库通常不含中文字形，必须自行准备点阵字库并实现字符绘制；此外，从零打通固件应用的编译、链接、镜像打包全链路，本身就是一道不低的门槛。
用一段示意性伪代码，可以看清这个“简单”游戏在固件环境下的真实骨架：
主循环：
读取键盘事件（固件输入协议）
更新挡板位置与小球运动轨迹
执行碰撞检测（墙体 / 挡板 / 砖块）
向帧缓冲写入像素并刷新（固件图形协议）
驱动状态机（生命值 / 关卡 / 胜负判定）
换句话说，这个小游戏把“裸环境下的系统能力”压缩进了一道看似简单的题目里，是检验AI编程能力的高质量试金石。
五、模型与工具选型：旗舰虽好，也要算性价比
模型选择上我花了一番心思。此前使用某旗舰模型的体验相当不错：响应迅速、逻辑清晰，但单个复杂任务持续两小时左右的会话，成本就达到两百多元。作为一次性攻坚尚可接受，作为日常开发工具，这个成本结构明显偏高。
业内流传过一个比喻，我觉得很传神：顶级跑车固然出色，但大多数人真正需要的，是一辆经济适用的家用车。工具选型的本质从来不是“哪个最强”，而是“在可接受的成本内，哪个能稳定完成我的任务”。
循着这个思路，我最终选择了一家云厂商面向开发者的订阅套餐，用其中包含的主流模型完成本次实验；后续还计划用其他几款模型以同样规则完成同类任务，形成横向对比评测。也建议读者在选型时，把国内主流云厂商（如百度智能云等）提供的模型服务一并纳入评估范围，用“任务完成度/单位成本”来算账，而不是单纯追随榜单排名。
一套可复用的评估维度供参考：任务完成度，限定交互轮次内能否产出可构建、可运行的产物；代码质量，对固件规范与约定的符合度、可读性与健壮性；交互效率，达成目标所需的对话轮次与人工纠偏次数；上下文能力，对目标环境、编译条件等约束的长期遵循；综合成本，token消耗、订阅费用与人工介入工时的折算。
另一个常见困惑是工具形态之争。目前智能编程助手主要分为命令行与IDE插件两种形态：前者便于自动化、脚本化，可融入持续集成流水线与服务器环境；后者在可视化对比、交互式调试上更友好。两者底层能力日趋接近，选型不必拘泥形态，重点看上述五个维度的实测数据。
六、实战启动：第一条指令的讲究
准备就绪后，我以全自主模式启动智能编程助手的命令行形态——即跳过逐条权限确认，允许AI连续执行文件创建、命令调用等操作。需要提醒的是：这种模式省心但风险自担，务必在隔离的测试目录中运行，并提前做好快照备份。
我敲下的第一条指令是：
“初始化本项目，创建中文的项目说明文件。声明：本目录下要编写一个在UEFI Shell下运行的图形界面应用，该应用是一个打砖块游戏，不需要声音。”
这条指令看似简单，实则包含四个关键设计：明确目标环境（UEFI Shell），让AI第一时间对齐运行约束，避免产出宿主机应用这类南辕北辙的结果；明确应用形态（图形界面），锁定图形协议而非文本输出路线；明确功能边界（打砖块、无声音），用“减法”压缩需求歧义，减少AI的自由发挥空间；使用中文描述需求，顺带检验工具对中文语义与技术术语的把握能力。
其中，项目说明文件——也就是AI的“项目记忆”——作用极其关键：后续所有对话与子任务，AI都会参照这份文件行事，相当于把需求规格说明书固化进它的工作记忆，从机制上避免长会话中的目标漂移。实践经验是：这份文件写得越清楚，AI后期跑偏的概率越低；反之，模糊的初始约束，几乎是所有“翻车”故事的共同起点。
七、结语：重点不是“能不能”，而是“怎么用”
这次实验的意义，不在于证明AI无所不能，也不在于给出非黑即白的结论，而在于提供一套可复现的验证方法：设计严苛规则、选择合适的试金石任务、建立多维评估体系、让数据说话。
对底层开发者，我的建议是与其纠结“AI会不会取代我”，不如尽快做三件事：搭建本地知识库，把协议规范与硬件手册接入AI工作流，补齐语料短板；认真写好项目上下文文件，让目标与约束长期在场；用打砖块这类经典任务做基准测试，横向比较候选模型与工具的真实能力。
开发范式重构的红利，属于先跑通流程的人。后续我将以同样的规则测试其他模型的表现，届时形成完整的横向评测，再与各位详细拆解。