大模型辅助C++小游戏开发：从生成到运行全流程实践

用大模型辅助编写 C 小游戏看起来是一条很顺的路把需求描述清楚让模型输出完整代码再复制到编译器里运行就行。真正完整做一次之后才会发现这条链路比想象中长很多。这次实测记录的过程是以 Claude Fable 5.1 作为生成引擎让它完成两个 C 小游戏——2D 滑板跑酷和地铁场景 FPS并完整走完提示词设计、代码生成、编译修正、运行验证、成本核算五个阶段。由于模型版本和计费规则变化较快本文只把模型当作被测对象重点保留可复用的方法、提示词模板和工程结论。实测整体结论是生成效果确实能让人眼前一亮尤其在 2D 游戏逻辑和基础 3D 场景搭建上模型能给出结构清楚、可读性不错的 C 代码但同时成本也明显偏高。这里说的成本不只是接口调用费还包括上下文维护、错误回传、大段代码重写带来的时间开销。如果你正准备用类似方式做游戏原型、练习 C或者评估编程助手类工具这篇文章能帮你建立一套更省 token、更容易收敛的对话式开发方法。1. 先界定测试任务与评估方式1.1 两个游戏任务的功能边界先把任务范围写清楚避免在过程中反复追加需求。任务玩法核心模块主要技术点2D 滑板跑酷角色骑滑板向右前进跳跃躲避障碍物成功躲避后计分移动、重力跳跃、矩形碰撞、计分、绘制简单物理、帧循环、矩形碰撞检测地铁场景 FPS站在地铁站台场景中第一人称视角移动射击红色球形目标3D 摄像机、角色移动、射线拾取、目标系统、HUD透视相机、射线与球体碰撞、玩家输入这两个任务覆盖了 C 游戏开发中最常遇到的两类基础能力2D 的碰撞与物理手感以及 3D 的摄像机与射线检测。如果模型能把这两类任务独立跑通后续扩展到横版动作、迷宫、塔防等题材时会顺利得多。需要说明的是文中讲的“地铁 FPS”是技术演示性质的第一人称射击场景没有复杂剧情或联机机制主要验证“摄像机控制、射线命中、目标消失”这几段逻辑。它和商业 FPS 游戏的距离主要差在关卡设计、动画、网络同步、音效和性能优化这些不是本次模型测试的重点。1.2 为什么选 raylib 而不是 OpenGL 或 SFMLC 写小游戏可选库很多测试前先做了选型三个候选是 OpenGL、SFML、raylib。方案优点缺点适合场景OpenGL图形能力最强可深入理解 GPU 管线直接写 GL 代码比较复杂初始化、着色器、矩阵都要自己处理需要精细控制渲染或学习图形学原理SFML窗口、事件、音频封装完整2D 表现稳定3D 能力弱需要配合 OpenGL 使用传统 2D 游戏、跨平台桌面应用raylib内置窗口、2D/3D 绘制、摄像机、射线碰撞API 简单封装层次较高底层细节不如 OpenGL 直观原型开发、教学、快速验证实测选择 raylib原因有三个。第一它内置Camera3D、Ray、CheckCollisionRaySphere这类高层 API模型生成代码时不容易因为渲染细节而出错。第二raylib 使用简单头文件和静态库配好后一个main.cpp就能跑起来符合 AI 生成“单文件代码”的习惯。第三它对新手友好能把注意力放在游戏逻辑而不是窗口系统上。1.3 用哪些维度评估生成结果评估不能只看“能不能编译”。本次实测使用五个维度编译通过率首轮代码不修改的情况下能否直接编译。可玩性游戏是否具备基本的输入、反馈、结束条件。代码可读性变量命名、函数划分、注释是否清楚。人工修改量从模型输出到可运行版本需要改多少行。token 成本生成过程和迭代过程总共消耗多少 token以及为此付出多少等待和纠错时间。这五个维度中前四项决定模型输出质量最后一项决定工程上是否可持续。很多模型评测只展示“生成很惊艳”的片段却忽略从生成到落地之间的反复这篇文章会按完整链路描述。2. 环境准备VS Code、CMake 与 raylib 对齐2.1 工具链版本清单AI 生成的代码质量再高环境不对也跑不起来。本次环境如下注意版本以自己本机为准不要照搬。组件本次使用的示例版本说明操作系统Windows 11raylib 跨平台Linux/macOS 同样可以编辑器VS Code需要安装 C/C 官方扩展编译器MinGW-w64 g 或 MSVC建议 g 12 以上以支持 C17构建方式CMake 3.20也可以直接用 tasks.json 调用 g图形库raylib 5.x头文件与库文件放在 external/raylib 下MinGW 和 MSVC 二选一即可。如果用 MSVC 构建运行目标机器需要安装对应的 Microsoft Visual C Redistributable如果用 MinGW 的 g要注意运行时是否缺少libgcc_s_seh-1.dll、libstdc-6.dll后面排错章节会说明。2.2 VS Code 的 C/C 环境配置先把依赖库放好。推荐项目结构ai-cpp-games/ ├─ CMakeLists.txt ├─ external/ │ └─ raylib/ │ ├─ include/raylib.h │ └─ lib/libraylib.a ├─ src/ │ ├─ main_skate.cpp │ └─ main_fps.cpp └─ build/使用 VS Code 编辑时需要先让 IntelliSense 找到 raylib.h。.vscode/c_cpp_properties.json示例{ configurations: [ { name: Win64-Debug, includePath: [ ${workspaceFolder}/**, ${workspaceFolder}/external/raylib/include ], defines: [_DEBUG], compilerPath: C:/mingw64/bin/g.exe, cStandard: c17, cppStandard: c17, intelliSenseMode: windows-gcc-x64 } ], version: 4 }这里的关键是把external/raylib/include加入includePath否则编辑器会画红色波浪线但编译不一定报错。看到波浪线不要急着怀疑代码先检查 include 路径是否配置正确。2.3 CMake 构建脚本使用 CMake 可以同时管理两个可执行文件也方便以后加入测试。CMakeLists.txt示例cmake_minimum_required(VERSION 3.20) project(ai_cpp_games CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) add_executable(skate_runner src/main_skate.cpp) target_include_directories(skate_runner PRIVATE external/raylib/include) target_link_libraries(skate_runner PRIVATE raylib) add_executable(subway_fps src/main_fps.cpp) target_include_directories(subway_fps PRIVATE external/raylib/include) target_link_libraries(subway_fps PRIVATE raylib)需要注意链接顺序target_link_libraries写在add_executable之后。MinGW 环境下如果出现undefined reference to InitWindow多半是 raylib 库没有放进链接参数或者库文件的位数和编译器不一致。2.4 准备一个随时能跑的最小程序写正式代码之前先用下面的最小程序验证环境#include raylib.h int main(void) { InitWindow(640, 480, raylib env check); SetTargetFPS(60); while (!WindowShouldClose()) { BeginDrawing(); ClearBackground(RAYWHITE); DrawText(hello raylib, 200, 200, 30, DARKGRAY); EndDrawing(); } CloseWindow(); return 0; }如果这个程序能编译并弹出窗口说明工具链没有问题。窗口能打开但控制台报缺少 DLL说明运行库还差一步窗口完全没有出现优先检查编译链接这一步。这一步虽然简单但在 AI 生成游戏代码之前做掉能避免把“环境问题”和“模型生成问题”混在一起。3. 生成 2D 滑板小游戏从提示词到可运行3.1 第一版提示词的设计滑板小游戏的核心需求是“右侧生成障碍物、玩家跳跃躲避、碰撞结束、计分”。首轮提示词不要写得太长但要写清约束条件用 C 和 raylib 写一个 2D 滑板跑酷小游戏。 要求 1. 玩家是一个矩形角色站在地面高度 380 像素。 2. 按空格键跳跃跳跃需要重力和落地判断。 3. 右侧不断生成矩形障碍物向左移动。 4. 角色与障碍物碰撞后游戏结束。 5. 每成功躲过一个障碍物分数加 1。 6. 窗口 960x540目标 60 FPS。 7. 输出一个完整的 main.cpp不要使用多个文件。写提示词的要点是明确输入、明确输出格式、明确限制条件。第 7 条尤其重要它要求模型输出单文件避免生成一堆头文件导致复制和编译都麻烦。模型首轮给出的版本包含窗口初始化、主循环、绘制三个部分结构基本正确编译后能直接看到一个矩形在移动。3.2 首轮代码的核心结构最终工程里的主文件核心片段如下。这个版本已经包含修正后的跳跃参数#include raylib.h int main(void) { const int screenWidth 960; const int screenHeight 540; InitWindow(screenWidth, screenHeight, Skateboard Runner); float playerX 120.0f; float playerY 380.0f; float playerVY 0.0f; float gravity 0.55f; float jumpVelocity -13.0f; bool onGround true; const float groundY 380.0f; float obstacleX (float)screenWidth; float speed 6.0f; int score 0; SetTargetFPS(60); while (!WindowShouldClose()) { // 跳跃输入 if (IsKeyPressed(KEY_SPACE) onGround) { playerVY jumpVelocity; onGround false; } // 重力与位置更新 playerVY gravity; playerY playerVY; if (playerY groundY) { playerY groundY; playerVY 0.0f; onGround true; } // 障碍物向左移动 obstacleX - speed; if (obstacleX -60.0f) { obstacleX (float)screenWidth; score; } // 碰撞检测 Rectangle playerRect { playerX, playerY, 40.0f, 40.0f }; Rectangle obstacleRect { obstacleX, 420.0f, 50.0f, 100.0f }; if (CheckCollisionRecs(playerRect, obstacleRect)) { break; } BeginDrawing(); ClearBackground(RAYWHITE); DrawRectangleRec(playerRect, BLUE); DrawRectangleRec(obstacleRect, RED); DrawText(TextFormat(Score: %d, score), 20, 20, 30, DARKGRAY); EndDrawing(); } CloseWindow(); return 0; }这段代码用一组简单的物理量模拟跳跃playerVY gravity让角色下落playerY groundY判断落地碰撞使用 raylib 的CheckCollisionRecs。对跑酷小游戏来说这套结构足够清楚也是模型输出中的典型写法。人工要改的地方主要是参数初版跳跃高度过高、下落太慢把gravity从 0.4 调到 0.55、jumpVelocity从 -15 调到 -13 后手感才正常。3.3 首轮暴露的三个问题首轮代码能编译能运行不代表需求完成。实测中遇到三个问题问题现象处理方式结果跳跃手感差角色滞空接近 1.5 秒落地感弱调整gravity和jumpVelocity参数滞空缩短到约 0.8 秒障碍物固定间隔每次都在同一位置出现重复感强让障碍物生成间隔随机化形成基本跑酷节奏游戏结束即关闭窗口玩家看不到结束画面增加 Game Over 绘制和重新开始逻辑可玩性提高这三个问题说明一个规律AI 生成的代码在“结构正确性”上通常不错但在“手感”和“完整交互闭环”上需要人工介入。手感是主观体验模型无法靠自然语言完全理解必须自己调参数。3.4 修正轮次的提示词写法修正时不要只说“跳跃不好”要给出现象和期望。下面是第二次对话中使用的提示词现有代码已经在本地编译运行。 当前问题 1. 跳跃太高、下落太慢角色在空中停留约 1.5 秒。 2. 游戏结束后窗口立刻关闭我想看到 Game Over 画面和重新开始功能。 3. 障碍物现在固定间隔出现请改成随机间隔间隔范围控制在 300 到 700 像素之间。 请针对这三个问题修改输出修改后的完整 main.cpp。这种写法的好处是让模型定位明确先声明“现有代码已编译运行”避免模型从零重写每个问题都带现象和期望最后限定修改范围。代价是要求输出完整文件会推高输出 token但对一段 150 行左右的小游戏来说可以接受。4. 地铁 FPS 的分步生成与上下文控制4.1 为什么 FPS 不能一轮生成2D 滑板小游戏比较小单轮生成加两轮修正就完成了。地铁 FPS 不同它包含 3D 摄像机、玩家移动、射线发射、球体命中、HUD 绘制等模块代码量是滑板游戏的 3 到 5 倍。如果在一轮对话里让模型输出完整 FPS容易出现两个问题。一是上下文超长模型首尾不一致前半段定义的结构后半段用不上。二是错误叠加初始代码里某个 API 用错后续所有修改都建立在这个错误基础上越改越乱。因此FPS 采用分步生成策略。4.2 分步任务拆解步骤输出内容验证方式第 1 步窗口、摄像机、地面网格看到 3D 场景并可旋转视角第 2 步WASD 移动与视角控制可以在场景中自由移动第 3 步生成 5 个红色球体目标看到目标出现在站台区域第 4 步鼠标左键发射射线判定命中点击后目标消失分数增加第 5 步HUD 文本与重新开始逻辑文字、分数、重置都正常每步生成后先编译运行确认通过再进入下一步。这样即使某一步出错也能把问题范围缩小到最近新增的代码里。4.3 用“新会话 摘要”控制上下文分步生成时如果所有步骤都在同一个长对话里进行前面的代码会反复作为输入 token 被计算成本迅速上升。推荐做法是每完成一个模块就开新会话只带上一模块的接口摘要我已经完成一个 raylib 项目的一部分代码 - 窗口 1280x720主循环已经建立。 - 摄像机使用 Camera3D 类型通过 CAMERA_FIRST_PERSON 更新。 - 现有结构InitWindow - while - BeginDrawing/BeginMode3D。 接下来要增加在地铁站台位置生成 5 个红色球体目标按鼠标左键发射射线判定命中。 不要重写整个主循环只输出需要新增的代码片段并说明插入位置。这个提示词保留了关键接口信息又去掉了全部历史代码。它牺牲的是模型对细节的完整记忆换来的是更低的 token 消耗和更少的幻觉空间。对于几百行的小项目这种“断点续聊”足够用。4.4 射击核心逻辑解析地铁 FPS 最终工程的核心片段如下简化版#include raylib.h typedef struct { Vector3 pos; float radius; bool alive; } Target; int main(void) { const int screenWidth 1280; const int screenHeight 720; InitWindow(screenWidth, screenHeight, Subway FPS Demo); Camera3D camera { 0 }; camera.position (Vector3){ 0.0f, 1.8f, 6.0f }; camera.target (Vector3){ 0.0f, 1.8f, 0.0f }; camera.up (Vector3){ 0.0f, 1.0f, 0.0f }; camera.fovy 60.0f; camera.projection CAMERA_PERSPECTIVE; Target targets[5]; for (int i 0; i 5; i) { targets[i].pos (Vector3){ -8.0f i * 4.0f, 0.5f, -2.0f }; targets[i].radius 0.6f; targets[i].alive true; } int score 0; DisableCursor(); SetTargetFPS(60); while (!WindowShouldClose()) { UpdateCamera(camera, CAMERA_FIRST_PERSON); if (IsMouseButtonPressed(MOUSE_BUTTON_LEFT)) { Ray ray GetMouseRay(GetMousePosition(), camera); for (int i 0; i 5; i) { if (!targets[i].alive) continue; if (CheckCollisionRaySphere(ray, targets[i].pos, targets[i].radius)) { targets[i].alive false; score; } } } BeginDrawing(); ClearBackground(DARKGRAY); BeginMode3D(camera); DrawGrid(20, 1.0f); for (int i 0; i 5; i) { if (targets[i].alive) { DrawSphere(targets[i].pos, targets[i].radius, RED); } } EndMode3D(); DrawText(TextFormat(Score: %d / 5, score), 20, 20, 30, WHITE); EndDrawing(); } CloseWindow(); return 0; }这段代码的关键是GetMouseRay和CheckCollisionRaySphere。鼠标点击时先从摄像机出发构建一条射线再与每个球体做相交检测命中就把目标标记为死亡。CAMERA_FIRST_PERSON模式负责让摄像机跟随鼠标转动并响应 WASD 移动省去大量手动旋转矩阵代码。模型首轮生成的版本里目标坐标是简单排列在一条直线上的没有真正模拟地铁站台遮挡关系。手工补充了柱子绘制和移动边界限制后场景才更像一个站台。建议不要指望模型直接生成完整关卡手工或脚本维护场景数据更可控。5. 编译、运行与验证5.1 编译错误按这个顺序排查实测过程中遇到的编译错误可以归纳为四类排查优先级从高到低。第一头文件找不到。错误信息形如fatal error: raylib.h: No such file or directory。检查 include 路径是否写对。c_cpp_properties.json只影响 IntelliSense真正编译时看的是 CMake 或 tasks.json 里的-I参数。第二链接错误。形如undefined reference to InitWindow collect2.exe: error: ld returned 1 exit status这说明 raylib 的库没有进入链接检查target_link_libraries和库文件位数。第三API 名称或参数不匹配。模型按某个版本回忆 API但本地 raylib 头文件版本不同。直接打开raylib.h对照函数签名。第四类型错误和 C 语法错误。比如Vector3初始化漏了强制转换TextFormat参数类型不匹配。这类错误看编译器给出的行号即可不需要回传给模型。一个值得注意的现象是把完整报错日志直接贴给模型常常会让它“过度修复”把本来正确的部分也改掉。先人工读日志前 20 行找到第一个真正错误再贴效率更高。5.2 运行验证清单程序能启动只说明没有崩溃不能说明功能正确。下面两个清单用于验证每个游戏的核心逻辑。验证点操作方法预期结果跳跃按空格角色上升后下落落地可再次跳碰撞结束不操作等待障碍物撞到角色游戏停止或显示 Game Over计分连续躲过障碍物分数每次加 1无负数窗口关闭按 ESC 或点关闭按钮主循环正常退出进程结束验证点操作方法预期结果视角控制移动鼠标视野左右上下跟随角色移动WASD摄像机按第一人称移动射线命中鼠标左键点击球体球体消失分数加 1帧率观察窗口标题或日志稳定接近 60 FPS建议把验证结果写成简短记录比如“空格跳跃 OK落地判断 OK碰撞后必现退出”。这比“能跑”更有价值也方便在下一轮对话里反馈给模型。5.3 性能与资源观察两个项目都使用 raylib 的单窗口绘制模型没有额外纹理和音频资源因此在普通配置的机器上都能稳定跑到 60 FPS内存占用也很低。要观察帧率可以把GetFPS()拼进窗口标题SetWindowTitle(TextFormat(Subway FPS Demo | FPS: %d, GetFPS()));地铁 FPS 场景里只有 5 个球体和一个网格没有遮挡剔除需求性能压力可以忽略。如果后续要支持大量动态目标才需要考虑空间分区、射线步进检测和对象池这些内容已经超出本次模型生成测试的范围。6. 成本到底高在哪里6.1 成本不能只看单次输出接口调用费用按 token 计算一次请求有两个部分输入 token提示词 历史上下文 代码和输出 token模型生成的代码或文字。多次请求成本累加。计算总成本的方法很简单每次请求都记录输入 token 数和输出 token 数最后汇总。不同区域、不同版本的模型单价不同文章不引用任何固定报价实际评估时以控制台的数据为准。6.2 本次实测的量级下面是本次任务按上述统计口径得到的量级任务对话轮次最终代码量估计总 token备注滑板小游戏3 轮约 140 行约 8 万到 12 万两轮修正会回传完整文件地铁 FPS5 轮约 400 行约 20 万到 30 万分步生成每步保留摘要这里的“估计总 token”包含每次请求的输入和输出也包含错误日志回传。它不是一个精确数字不同提示词风格下差异很大但可以说明生成几百行可运行的 C 小游戏代价并不低尤其在多轮纠错时。6.3 三个真正烧钱的行为第一个是每一轮修正都把整个 main.cpp 重新贴回对话。文件越长输入 token 越高。第二个是要求模型“输出完整 main.cpp”。整理后的 140 行代码输出 token 并不算高但如果文件到了 1000 行每次完整重写输出成本会直线上升。第三个是把整个构建日志原封不动贴给模型。一条链接错误日志动辄几十行这些都会按输入 token 计费而且大部分内容模型并不需要。6.4 控制成本的可行手段小文件才要求完整输出。超过 200 行的文件建议要求模型“只输出修改的函数并用注释标明插入位置”。报错只贴关键片段。先人工读日志前 20 行保留错误行号和错误类型。模块间开新会话用接口摘要接续而不是把整段代码留在上下文中。设定输出长度上限比如“代码不超过 150 行”逼模型压缩实现。批量小任务放在同一个提示词里减少冷启动和重复描述。这五条本质是同一个原则控制输入 token 和输出 token 的体量而不是减少对话次数本身。7. 常见问题排查清单7.1 环境与运行问题问题现象常见原因检查方式处理建议VS Code 报找不到 raylib.hincludePath 未配置查看 c_cpp_properties.json把 raylib include 目录加入 includePath编译报 undefined reference未链接 raylib 库查看链接参数增加-lraylib及相关系统库exe 双击闪退缺少运行库 DLL命令行运行或查看事件查看器安装 VC Redistributable或 MinGW 静态链接运行时库桌面版没有控制台输出编译使用了-mwindows检查编译选项调试阶段先去掉该选项中文文字乱码源码编码与终端编码不一致检查文件编码统一使用 UTF-8编译加/utf-8或使用纯英文文本7.2 模型生成代码的典型问题问题现象常见原因处理建议模型反复修改不对上下文里混入了旧版本代码新会话中只给最新代码片段生成的代码调用了不存在的 API模型版本与本地头文件不一致打开 raylib.h 检查函数签名生成的代码内存泄漏或数组越界模型缺少人工审查按第 8 节审查清单逐项检查修改一处后其他功能被破坏一次要求修改过多问题每轮最多要求修改 3 个问题排查 API 不匹配时最快的方法是直接打开external/raylib/include/raylib.h搜索GetMouseRay或CheckCollisionRaySphere对比签名。模型按 5.x 版本生成的代码如果本地装的是旧版就会在编译阶段看到参数类型不匹配。字符串处理上也容易出问题。比如模型生成char* p name; p[0] N;这种写法现代编译器会直接崩溃或报只读错误。C 中字符串字面量默认是const char[]需要初始化为std::string或可修改的字符数组。这类属于 C 新手常踩的坑审查时要注意。7.3 用最小复现法定位问题当游戏运行行为和预期不符但不知道代码哪一段有问题时推荐用二分法先注释掉一半功能看问题是否消失如果消失说明问题在被注释掉的那一半里再继续细分。这个方法在排查 AI 生成的代码时特别有效因为模型可能把多个逻辑纠缠在一起。实测中地铁 FPS 的“点击球体不消失”问题就是通过注释掉 HUD 绘制逻辑后才发现是TextFormat的格式化字符串写错导致主循环提前退出。单看日志很难定位缩小代码范围后一眼就能看到问题。8. 对 AI 辅助 C 开发的工程判断8.1 适合交给模型的场景从这次实测来看以下场景适合用大模型辅助场景原因游戏原型逻辑结构固定、单文件可验证教学示例代码需要清晰注释和典型写法经典算法与八股文式题目冒泡排序、二分查找、快速幂、链表反转等模板化代码样板代码初始化、文件读写、简单构建脚本这类任务的共同点是逻辑边界清楚、验证成本低、失败影响小。模型生成后人工只需读一遍关键函数、跑一次用例即可。8.2 不适合交给模型的场景性能敏感的热路径不适合直接使用生成代码。网络同步、内存池、多线程、高频渲染路径等场景模型生成的代码往往没有充分处理缓存局部性、锁粒度、异常安全和资源释放。std::thread、std::atomic使用稍有差错就会产生难以复现的问题。这类代码建议由有经验的开发者手写并配套压测。8.3 落地到工程前的人工审查清单每次使用模型生成的 C 代码前至少检查下面几项资源是否释放使用 new/delete、malloc/free 的地方是否符合 RAII 或智能指针。数组是否越界循环边界和索引是否符合容器长度。浮点比较是否直接用比较浮点数。输入校验用户输入和文件内容是否可能非法。错误处理文件读取、网络请求、类型转换失败时是否有兜底。字符编码源码是否统一为 UTF-8字符串数组和字符串字面量的初始化是否安全。依赖版本使用的 API 是否与本地库版本匹配。这条清单同样适用于人工手写代码。区别在于模型生成代码时更倾向于“功能正确”而不是“边界完整”所以审查重点放在边界条件。8.4 下一步可以扩展的方向让模型根据游戏主循环生成单元测试覆盖碰撞边界、计分逻辑和移动算法。用 JSON 或文本描述关卡数据再让模型生成读取和渲染代码把“生成关卡数据”和“生成游戏逻辑”分开。把命令式代码拆成纯函数提高可测试性和可维护性也降低模型生成的复杂性。加入构建脚本和 CI每次模型生成后自动编译、自动跑冒烟测试缩短反馈回路。这次实测最有价值的结论是大模型生成 C 小游戏的“首版质量”已经很可靠真正决定项目成败的不是生成那一下而是后续的迭代方式、上下文管理和成本控制。如果能把任务拆小、把报错压缩、把代码审查变成习惯这套工作流完全可以用在学习和原型开发中。对刚入门 C 的开发者建议从 2D 小游戏开始先跑通一个最简单的生成-编译-修正循环再尝试 3D 场景和更复杂的模块对已经在做商业项目的开发者则建议把模型当作“快速生成草稿”的助手而不是替代编译验证和代码审查的工具。