当AI助手遇上游戏开发：IU国际应用科学大学研究团队亲测GPT-4o改写游戏代码，结果喜忧参半

这项由德国IU国际应用科学大学（IU International University of Applied Sciences）团队完成的研究，以预印本形式发表于2026年6月19日，论文编号为arXiv:2606.21171v1，收录于计算机科学软件工程方向。有兴趣深入了解的读者可以通过该编号在arXiv平台上查阅完整论文。

**研究概要：一场关于"AI能帮程序员干多少活"的真实测试**

每一个玩过电子游戏的人，大概都没想过游戏背后的代码有多复杂。一款看似简单的"跑酷"小游戏，实际上需要处理角色跳跃、障碍碰撞、敌人行为、道具效果……这些系统相互交织，牵一发而动全身。现在，如果让一个"万能AI助手"来帮忙修改或扩展这套代码，它能胜任吗？

这正是IU国际应用科学大学的研究团队想要弄清楚的问题。他们用自己开发的一款Python语言编写的横版跑酷游戏作为实验对象，邀请当时最热门的AI语言模型GPT-4o来完成一系列真实的编程任务，然后仔细检验每一项任务的完成质量。

这项研究的价值在于，它不是在实验室里出几道干净的编程题让AI作答，而是把AI直接丢进一个真实存在的、有历史包袱的游戏项目里，让它对着一堆相互依赖的代码文件动手术。这种场景，才是现实中程序员每天面对的真实处境。研究结果颇为耐人寻味：AI在某类任务上表现稳定，在另一类任务上则频频翻车——而这两类任务之间的区别，揭示了当前AI辅助编程能力的一道清晰边界。

---

**一、研究背景：AI助手正在涌入程序员的工作间**

过去几年，以GPT为代表的大型语言模型（简单说，就是能读懂并生成文字和代码的超级AI）正在快速渗透软件开发的各个环节。从自动补全代码、解释错误信息，到直接根据需求生成完整功能模块，这类工具让不少开发者感叹"写代码的方式正在被彻底改变"。

然而，学术界对一个更具体的问题的研究还相当有限：当AI生成的代码不是孤立存在，而是必须嵌入一个已有的、运行中的软件系统时，它的表现究竟如何？这个问题的答案，对游戏开发者来说尤为关键。游戏代码的特殊性在于，它不仅要逻辑正确，还要在运行时与视觉渲染、物理碰撞、玩家输入、计时器等一大堆动态系统协同工作。光靠"代码没有语法错误"根本不够，还得在真正运行游戏时不出岔子。

正因如此，该研究团队认为游戏开发是研究AI辅助编程的一个绝佳场景：它既有足够的技术复杂度，又能通过实际试玩来检验AI产出的代码是否真正有效——而不仅仅是看起来有效。

已有的相关研究提供了一些有用的线索。有研究者发现，AI在建议代码简化和重构方面有一定能力，但也会给出不安全或改变原有功能的建议。另一些研究则反复指出，AI生成的代码往往表面上看起来像模像样，仔细审查时却暴露出正确性、可维护性或安全性方面的问题。还有研究者观察到，在实际使用场景中，AI生成的代码更适合作为探索性草稿，而非直接投入使用的产品级代码。

这些发现都指向同一个核心问题：AI辅助编程在游戏这个特定领域，尤其是在需要与现有系统深度整合的任务中，究竟能走多远？

---

**二、研究对象：一款自制跑酷游戏，一位AI"临时工"**

研究团队选用的实验平台，是他们自己用Python和Pygame（一个常用于开发2D小游戏的编程库）从零构建的横版无限跑酷游戏。在这款游戏里，玩家操控一个角色在不断向前滚动的场景中奔跑，需要躲避陨石和汽车等障碍物，应对机器人和无人机等敌人的攻击，同时可以利用无敌、冻结、武器强化等道具增强生存能力。角色能够水平移动、跳跃、滑行和射击。一旦在没有防护状态下碰到障碍物或敌人攻击，游戏就结束了。

这款游戏的代码结构相当完整，包含核心游戏逻辑、玩家角色行为、敌人行为、投射物与道具系统、资源管理，以及一套基于pytest框架的自动化测试。整个项目的代码量换算成AI能理解的"token"（可以理解为AI处理文字的基本单位），大约是31,947个，完全在GPT-4o一次能处理的范围之内，因此AI能看到完整的项目全貌，而不是只见树木不见森林。

被选中担任"临时程序员"的AI，是OpenAI于2024年推出的GPT-4o。研究团队选择它的原因很直接：在实验进行时，它是市面上代码能力最强、最广泛使用的通用大语言模型之一。不过研究者也明确指出，这项研究评估的是GPT-4o在特定时间点、特定项目中的具体表现，不代表所有AI编程工具的能力，也不适用于更新的模型版本或专门面向编程的AI系统。

---

**三、任务设计：两类手术，六个切口**

研究团队为GPT-4o安排了六项任务，分成两大类，每类三项。这两类任务分别代表了日常游戏开发中两种非常典型的工作：一种是"整理现有的屋子"，另一种是"在旧房子上加新房间"。

第一类任务叫做"重构"（Refactoring），通俗说就是在不改变游戏功能的前提下，把代码整理得更整洁、更合理。研究团队选择了三个具体的重构目标。第一个（R1）是优化游戏的"总指挥"——负责管理游戏状态和事件的核心逻辑模块，原来的代码像一棵枝杈密布的大树，层层嵌套，难以阅读，目标是把它改造成更清晰的模块化结构，让不同的状态切换逻辑彼此分离。第二个（R2）是清理游戏资源加载部分，原来的代码里有大量重复的图片加载语句，就像一个仓库里同一件物品堆了好几叠，目标是把这些重复操作替换成一个统一的、可配置的加载流程。第三个（R3）是统一玩家角色的移动控制，原来跑步、跳跃、滑行各有一套单独的实现逻辑，目标是把它们整合进一个更通用的控制机制里。

第二类任务叫做"游戏功能生成"（Gameplay Feature Generation），也就是给游戏添加全新的玩法内容。同样选了三个目标。第一个（F1）是实现"像素级精确碰撞检测"，原来的碰撞判定只看角色和障碍物的外框矩形，新版本要改成只看实际可见的像素，这样判定会更公平、更自然。第二个（F2）是新增一个"缩小道具"，捡到它之后玩家角色暂时变小，理论上更容易躲避攻击，但必须与跳跃、滑行、武器等现有系统正常配合。第三个（F3）是实现"汽车平台"机制，让玩家能跳上行驶中的汽车并站在上面移动，这需要专门处理与汽车的碰撞逻辑，以及玩家在汽车上运动和离开时的稳定行为。

---

**四、操作方式：给AI下指令的学问**

在实际操作中，研究团队每次都把完整的游戏代码一次性提供给GPT-4o，让它在看到全貌的情况下作答，而不是只给它看相关的一小片段。每一项任务都在一个全新的对话窗口里进行，避免前一个任务的讨论内容影响后一个任务。

在正式开始之前，团队还特意让GPT-4o先用自己的语言概括一遍整个项目的结构，以此验证AI是否真正理解了代码的整体框架和各模块之间的依赖关系，而不是在不明就里的情况下乱改一气。

与此同时，研究团队针对不同任务类型选用了不同的"提示策略"（也就是如何向AI提问的技巧）。对于重构任务，他们主要采用了"自一致性提示"（让AI生成多个方案再比较选优）、"数据驱动重构"（用软件质量指标来引导AI的重构方向）和"结构化推理提示"（要求AI为选择某个方案提供清晰的理由）。对于功能生成任务，他们则采用了"测试驱动提示"（先让AI写出测试用例再写实现代码）、"少样本提示"（给AI展示现有测试代码的写法作为参考）和自一致性提示。

研究中定义的"一次迭代"，指的是一个完整的交互循环：向AI提交一个需求，AI返回一版实现，然后对这版实现进行验证。如果验证不通过，就要用新的提示词再来一轮。迭代次数越多，意味着需要来回打磨的次数越多。

---

**五、评判标准：三重关卡，缺一不可**

判断AI的任务完成得好不好，研究团队设计了三个层面的评估，必须全部过关才算成功。

第一关是"软件质量指标"，相当于给代码做体检。研究团队使用SonarQube这一业界常用的静态代码分析工具，以及一个自定义的Python脚本，测量了几项核心指标。代码行数（LOC）衡量代码的规模；圈复杂度（CC）反映代码的逻辑分支数量，数字越大代表代码越复杂，越难测试；认知复杂度（CGC）衡量人阅读代码时的理解难度，与圈复杂度略有不同；代码异味（CS）是指代码中存在的可能导致未来问题的不良写法；可维护性指数（MI）是一个综合得分，分数越高代表代码越容易维护。

第二关是"单元测试"，也就是运行一系列自动化程序，验证代码的各个功能模块是否按预期工作。这就像工厂里的质检环节，每个零件单独测试是否合格。

第三关也是最关键的一关——"人工游戏测试"。研究团队实际运行游戏，亲手试玩，看修改后的功能在真实运行环境中是否表现正常。这个关卡能捕捉到那些在代码层面看似正确、却在实际运行时出现问题的情况。只有当三个关卡全部通过，一项任务才被判定为"成功"。

---

**六、重构结果：整理旧屋，AI完成得还不错**

三项重构任务，GPT-4o全部完成，但花费的迭代次数各不相同，分别是3次、7次和5次。这说明结果虽然都达标了，但并非一蹴而就，都需要反复调整。

从代码质量指标的变化来看，三项重构呈现出各不相同的画面。状态管理优化（R1）作用于游戏核心文件game.py，代码行数从314行增加到了349行，圈复杂度也从65上升到76，但认知复杂度从118降到了96，代码异味从3减少到2，可维护性指数从37.37小幅上升到39.52。换句话说，这次重构让代码对人类阅读更友好了，异味也少了，但文件变长了，逻辑分支变多了。

资源加载优化（R2）的效果最为显著。assets.py文件从118行骤降到45行，就像把一个堆满重复物品的储物间清空整理了一遍，文件瘦身了六成多。可维护性指数也从80.83提升到88.37，明显改善。代价是圈复杂度和认知复杂度都有所上升，因为新的统一加载逻辑内部引入了更多判断。代码异味保持不变。

移动控制统一（R3）的成效则相对有限。player.py从144行增加到165行，圈复杂度从49升到54，认知复杂度从59小幅降到54，但代码异味从1增加到3，可维护性指数从52.41微降到52.04。这次重构在减少认知负担上有一定作用，但同时带来了更多的代码异味，整体可维护性几乎没有改善。

这种"有得有失"的模式反映出一个现实：重构不总是能让每项指标同步改善。AI完成了功能层面的要求，代码能运行、测试能通过，但在代码质量的不同维度上，改善程度参差不齐。对于这类有明确边界的"局部整理"工作，GPT-4o基本上能胜任，只是不能指望它把每一个角落都收拾得完美无缺。

---

**七、功能生成结果：新建房间，AI撞了南墙**

三项游戏功能生成任务，结果却截然不同，只有一项真正成功，另外两项都在最后关头败下阵来。

像素级精确碰撞检测（F1）是唯一的成功案例，经过4次迭代后通过了全部三项评估。从指标变化来看，这次改动相当克制：game.py文件从314行增加到318行，圈复杂度从65升到66，认知复杂度维持在118不变，代码异味维持在3不变，可维护性指数从37.37小幅降至36.93。改动面积很小，这或许正是它能成功整合的原因之一——新功能的边界相对清晰，对其他系统的干扰有限。

缩小道具（F2）经历了8轮迭代，最终仍以失败告终。这次改动涉及6个文件，代码行数从694行增加到768行，圈复杂度从138增加到140，认知复杂度从204增加到211，代码异味保持在5不变，受影响文件的可维护性指数总体持平或略有下降。单元测试通过了，但实际游戏里出了问题：让角色缩小的操作，干扰了跳跃、滑行和武器使用的正常逻辑。就好像装了一扇新门，结果挤压了旁边的墙壁，把窗户卡住了。不管怎么调整，GPT-4o始终未能在保持角色缩小效果的同时，让这些原有的游戏机制正常运作。

汽车平台机制（F3）同样经历了6轮迭代，代码层面看起来一切正常——两个受影响文件的代码行数从458增加到487，圈复杂度从114增加到122，认知复杂度从177增加到189，代码异味从4增加到5，两个文件的可维护性指数都有所下降——单元测试也全部通过了。然而，当研究人员真正进入游戏试玩时，发现玩家跳上汽车之后，落地的行为完全不对：角色要么莫名其妙地死掉，要么移动方式出现错误。代码骗过了自动化测试，却骗不过真实的玩家操作。

---

**八、核心发现：单元测试通过，不等于游戏能玩**

这项研究最值得注意的发现之一，并不是AI在某些任务上失败了——而是**失败的方式**。

缩小道具和汽车平台机制这两个失败案例，单元测试都通过了。在传统的软件开发评估体系里，"单元测试全绿"往往意味着代码基本没问题。但在游戏开发这个特殊场景里，这个结论根本站不住脚。

单元测试检验的是代码模块在隔离状态下的行为，就像在实验室里单独测试每一个零件。但游戏的真实运行，是所有零件同时转动、相互咬合的状态。角色缩小之后能不能正常跳跃，取决于缩放系统、跳跃物理、碰撞判定、动画状态机之间的精确协作。玩家站在移动汽车上的落地行为是否正确，涉及到时序控制、速度叠加、碰撞法线计算等在测试环境中难以完整复现的运行时交互。这些问题，只有在游戏真正跑起来、玩家真正操作的时候，才会原形毕露。

这一发现对游戏开发行业具有相当直接的参考价值：当使用AI辅助开发游戏功能时，代码审查和自动化测试是必要条件，但绝不是充分条件。真实的游戏试玩测试，是无法被绕过的最后一道关卡。

---

**九、背后原因：为什么重构更容易，功能生成更难**

综合来看，研究团队对这种差异给出了一个清晰的解释框架。

重构任务的本质，是在一个已知的、有边界的区域内进行结构调整，目标明确，改动范围可控，改动前后的功能预期是一样的，可以通过前后对比直接验证。AI在这种"有界"的任务上，就像一个收拾房间的工人——虽然可能需要来回几趟才能把东西放到最合适的位置，但终点是清晰的，路径是相对确定的。

游戏功能生成则完全不同。添加一个新功能，不只是在空白处写几行代码那么简单，而是需要理解现有各个系统如何协作，预判新代码加入后会在哪些地方引发连锁反应，并在编写代码时就把这些潜在冲突全部考虑进去。这更像是在一座运行中的机器里添加一个新齿轮——不仅要保证这颗齿轮本身形状正确，还要确保它与其他所有齿轮的咬合都不出问题。

当前的GPT-4o在理解代码结构方面有相当不错的能力，但在推断运行时行为的复杂交互、预见多系统联动时的边缘情况方面，能力明显不足。这不是提示词写得好不好的问题，而是当前AI在"代码阅读理解"和"运行时行为预测"之间存在的能力鸿沟。

---

**十、研究局限：这不是最终答案，只是一扇窗**

研究团队在论文中坦诚地列出了这项研究的几个重要局限，这些局限直接影响着如何理解和引用这些结论。

首先，整个研究只基于一个游戏项目，而且这个项目是研究团队自己开发的。这既保证了他们对代码有充分的了解，但也意味着结论不能轻易推广到其他类型的游戏、其他架构风格的代码库，乃至其他类型的软件项目。

其次，每项任务只运行了一次，没有进行多次独立重复。AI生成代码本身就有一定的随机性，同样的提示词在不同时间运行可能给出不同的答案。单次运行的结果，无法排除偶然因素的影响。

第三，六项任务在设计时并没有刻意控制难度，使其两两等价，所以无法把"重构成功率高于功能生成"这个观察，解读为一个严格意义上的受控对比实验结论，只能作为探索性的参考。

第四，研究只评估了GPT-4o这一个模型。结论不适用于Claude、Gemini等其他模型，也不适用于GPT-4o之后更新的版本，更不能用来评估那些专门面向编程任务的AI系统，比如Cursor或GitHub Copilot这类"智能体"式编程工具。

第五，软件质量指标、单元测试和人工游戏测试的组合，提供了一个实用的评估框架，但并不能覆盖代码长期维护成本、开发者实际花费的精力，以及代码在更大规模项目中的表现等维度。

---

说到底，这项研究讲述的是一个关于"AI助手能力边界"的具体故事。在游戏开发这个充满动态交互的领域里，GPT-4o就像一个接受过良好训练、技术扎实的实习生：交给它在已有框架内整理和优化代码，它能干得有模有样，尽管有时需要多来几遍才能让你满意；但要它独立设计并植入一个需要与多个现有系统深度联动的新功能，它就很容易在你看不见的地方踩进坑里——更麻烦的是，它可能还会交给你一份让所有自动化检查都通过的"漂亮作业"，让你以为大功告成，直到你真正运行游戏才发现问题。

这个结论对于任何正在考虑引入AI辅助开发的团队都有现实意义：AI工具在边界清晰的局部修改上是有效的加速器，但在需要跨系统协调的复杂功能开发上，它更像是一个需要密切监督的协作者，而非可以放心托付的独立执行者。人工审查和实际运行测试，在这个阶段仍然是不可替代的。

另外值得思考的是，随着AI编程工具迭代加速，今天的局限明天可能就被突破。特别是新一代"智能体"式编程工具，能够自主规划多步骤操作、自动运行测试并根据结果调整策略，其表现可能与这项研究中的GPT-4o有很大不同。这也正是研究团队在论文结尾所呼吁的：未来需要更多类似研究，覆盖更多模型、更多游戏类型、更多任务种类，以及真正的多次重复实验，才能对AI辅助游戏开发的能力全貌给出更有说服力的描述。

对这个话题感兴趣的读者，可以通过arXiv平台搜索编号arXiv:2606.21171v1查阅完整论文，其中包含详细的实验数据、代码指标变化表格，以及研究团队在GitHub上公开的完整游戏项目和各任务分支代码，非常适合希望深入了解细节的技术读者。

---

Q&A

Q1：GPT-4o在游戏代码重构和功能生成上的成功率分别是多少？

A：在这项研究中，GPT-4o完成了全部3项代码重构任务，成功率为100%；在3项游戏功能生成任务中，只有像素级精确碰撞检测1项成功，另外2项（缩小道具和汽车平台机制）均以失败告终，功能生成成功率约为33%。

Q2：单元测试通过了，为什么游戏功能还是算失败？

A：因为游戏运行时涉及多个系统同时协作，单元测试只检验代码模块在隔离状态下的行为，无法覆盖跳跃、碰撞、动画、速度等系统在真实运行中的复杂交互。缩小道具和汽车平台机制都出现了"单元测试全部通过、实际试玩却出现功能异常"的情况，这说明游戏开发中手动试玩测试是不可或缺的验证环节。

Q3：GPT-4o辅助游戏开发需要多少次人工反复修改？

A：在这项研究的六项任务中，每项任务平均需要多轮迭代，从3次到8次不等。重构任务分别需要3次、7次和5次迭代；功能生成任务分别需要4次、8次和6次迭代。即使是最终失败的任务，也经历了多轮修改，说明AI不能一次性给出可直接使用的结果，需要开发者持续提供反馈和校正。