教程目标
本教程旨在指导开发者如何利用AI编程助手，在纯UEFI Shell环境中从零构建一个支持中文显示的图形界面打砖块游戏。通过这一极具代表性的底层开发挑战，探讨AI在缺乏丰富高层接口支撑的BIOS环境下的实际辅助能力，并重构底层开发范式。
适用场景
- 底层固件开发探索：适用于需要在UEFI/BIOS环境下进行原型验证或功能开发的固件工程师。
- AI编程能力极限测试：适用于技术负责人或架构师评估AI在底层硬件操作、寄存器配置及复杂协议栈调用中的可行性。
- 极简环境应用开发：适用于在无操作系统支撑、无本地代码库积累的极端受限环境中进行应用开发的场景。
前置准备
为了确保测试的客观性与严谨性，本教程采用极其严格的限制环境：
- 基础编译环境：开发机操作系统环境仅安装基础C++开发工具集（如基础IDE及编译器），不准备任何额外的UEFI专用 SDK 或开发包。
- 零本地代码库依赖：不预设任何底层驱动库、图形库或现成的 UEFI 包装代码，要求 AI 全程自主生成或寻找替代实现。
- 无人工代码干预：开发者一行代码都不写，仅提供极少的专业层面方向性指导，让 AI 全程自主完成编码、调试与编译构建。
- AI模型准备：选择具有较长上下文记忆和较强代码生成能力的主流AI编程助手。考虑到成本与效益的平衡，可优先选择具有高性价比的订阅套餐模型，而非最昂贵的旗舰模型。
实施步骤
步骤一：明确任务边界与开发约束
做什么：界定本次开发任务的最终产物与核心逻辑。
为什么做：底层开发与上层应用不同，明确边界能有效防止 AI 在生成代码时偏离 UEFI 规范，错误引入依赖操作系统的 API。
具体操作：确认目标为开发一个 UEFI Shell 下运行的打砖块游戏，涉及图形渲染（GOP）、用户输入（键盘事件捕获）、碰撞检测与基础物理逻辑。要求支持中文字库加载与显示，且不需要声音功能。
步骤二：初始化AI上下文环境
做什么：通过命令行界面启动 AI 编程助手，并建立项目的基础上下文规范。
为什么做：AI 缺乏对底层硬件编程的专业语料理解，必须通过初始化文件强制设定开发范式，约束其代码生成方向。
具体操作：
- 启动 AI 助手命令行工具，并传入跳过逐次权限确认的参数，以保证 AI 能够连续自主执行文件读写与命令调用。
- 发送初始化指令（如
/init），要求 AI 在当前工作目录下创建项目说明文档（如 CONTEXT.md）。 - 在说明文档中明确写入指令：“本目录下需编写一个在 UEFI Shell 下运行的图形界面 App，该 App 是一个打砖块游戏，不需要声音，需支持中文显示。”
步骤三：引导AI理解UEFI底层架构
做什么：要求 AI 阅读并理解系统提供的基础 UEFI 固件接口规范。
为什么做：由于未安装专用 SDK，AI 必须直接调用 UEFI 核心服务（如 Boot Services、Runtime Services）。
具体操作：
- 指示 AI 通过查阅本地基础开发工具自带的标准头文件（如 EFI 标准协议头）来理解系统表（System Table）的结构。
- 要求 AI 放弃任何依赖标准 C 库（如
stdio.h、stdlib.h）的幻想，全部使用 UEFI 原生协议函数。
步骤四：图形与输入协议接入
做什么：让 AI 编写代码以获取图形输出接口和简单输入接口的控制权。
为什么做：打砖块游戏依赖画面渲染和玩家操作，这是程序运行的基础。
具体操作：
- 图形渲染：要求 AI 通过系统表定位并调用图形输出协议（GOP）。AI 需自行编写代码查询当前视频模式，设置合适的分辨率与像素格式，并封装一个基础的画点或画矩形函数。
- 用户输入：要求 AI 调用简单文本输入协议（SIMPLE_TEXT_INPUT），捕获键盘按键的扫描码，将其映射为游戏内挡板的左移、右移及发射指令。
- 中文显示支持：由于 UEFI 默认不支持中文，指示 AI 思考中文字库加载方案。通常的做法是将点阵字库（如 HZK16）作为资源文件打包，或者在代码中硬编码所需中文的点阵数据，通过画点函数逐像素绘制。
步骤五：核心游戏逻辑构建与编译
做什么：组合图形、输入模块，构建完整的游戏循环。
为什么做：实现打砖块的基础玩法，验证 AI 的逻辑控制与碰撞检测算法编写能力。
具体操作：
- 要求 AI 编写主循环，包含状态更新、碰撞检测（球与墙壁、球与砖块、球与挡板）和画面刷新。
- 指示 AI 生成构建脚本（如
build.sh 或 Makefile）。由于缺乏专用编译工具链，AI 需调用基础 IDE 的命令行编译器，设定特殊的链接参数（如 /SUBSYSTEM:EFI 或相关链接指令），以生成 .efi 格式的可执行文件。
配置说明
在上述步骤中，涉及几个关键的底层配置概念：
- GOP（图形输出协议）：UEFI 中用于直接操作帧缓冲区的标准协议。AI 需正确配置其 Mode 结构体，获取 FrameBufferBase 和 FrameBufferSize。错误配置会导致系统直接卡死或花屏。
- 无标准 C 库环境：底层环境没有
malloc 或 printf。内存分配必须使用 UEFI Boot Services 中的 AllocatePool，字符串处理必须使用 Unicode 标准且需自行实现输出逻辑。 - 编译链接选项：生成 UEFI 应用要求入口点为
EfiMain，且不能链接任何依赖宿主操作系统的运行时库。AI 需自行摸索并配置编译器的裸金属链接选项。
结果验证
- 文件生成验证：检查项目目录，确认 AI 是否成功生成了
.c 源码文件、字库数据文件以及构建脚本。 - 编译产物验证：运行构建脚本，观察编译输出。若 AI 正确配置了编译器参数，最终应生成一个
.efi 可执行文件。 - 实机运行验证：
- 将编译生成的
.efi 文件拷贝至 FAT32 格式的 U 盘根目录。 - 将 U 盘插入物理机，重启进入 BIOS Shell 环境。
- 在 Shell 提示符下输入对应文件名运行程序。
- 观察屏幕是否成功渲染出打砖块的游戏边框、中文提示文字，并能否通过键盘控制挡板移动且球体能正常进行物理碰撞反弹。
常见问题与排查
- 问题一：AI 直接生成了包含
<stdio.h> 的代码，导致编译报错。
原因分析：AI 的训练语料中上层应用代码占绝对多数，容易产生惯性思维。
排查思路：在上下文规范文件中进一步强化约束，明确指出“禁止使用任何标准 C 库”，并要求 AI 在生成代码前先列出将要调用的所有 UEFI 协议供人工确认。 - 问题二：程序运行后直接重启或黑屏。
原因分析：通常是 GOP 帧缓冲区指针获取错误，或内存越界写覆盖了关键系统数据。
排查思路：要求 AI 在代码中加入调试输出机制（如向特定端口写数据或通过串口输出日志），隔离排查画点函数是否在合法分辨率范围内操作。 - 问题三：中文字符显示为乱码或方块。
原因分析：字库偏移地址计算错误，或未正确处理 UTF-8/GBK 与点阵字库索引的映射关系。
排查思路：要求 AI 编写一个独立的单元测试，仅渲染单个汉字，验证其点阵解析算法的正确性。
优化建议
- 引入本地知识库补充：虽然本次挑战要求零代码库，但在日常生产中，可通过向 AI 提供标准 UEFI 规范的 Markdown 版本或主流开源固件的代码片段作为 RAG（检索增强生成）背景知识，大幅降低 AI 试错成本。
- 重构开发流程：从“人工编写底层驱动”向“人工指导 + AI 生成底层逻辑”转变。利用 AI 快速生成不同硬件平台的 Porting 代码框架，将开发者精力释放到架构设计与性能调优上。
- 成本控制与模型选择：对于重复性高、模式固定的底层代码生成，选用具备高性价比的主流模型套餐即可满足需求；对于复杂的协议栈重构，再考虑调用算力更强的旗舰模型，以此平衡开发效率与调用成本。
总结
本次教程通过在极度受限的 UEFI 环境下开发图形界面游戏的实践，验证了 AI 编程助手在底层固件开发中的潜力。尽管面临语料匮乏、无标准库支撑等挑战，通过科学的上下文初始化与严格的约束引导，AI 依然能够完成从协议调用、图形渲染到逻辑控制的核心开发工作。这种全新的开发范式，不仅为传统底层开发提供了提效的新路径，也为评估 AI 在复杂系统级编程中的边界提供了极具价值的参考。后续可进一步探索 AI 在多平台 Porting 及驱动适配中的自动化能力。