AI程序员连续写了六天代码，做出了一款能打的FPS游戏

一个AI程序员被要求"做一个平台跳跃游戏"，没有别的指示，没有人在旁边盯着，它会怎么办？

大部分人的直觉是,它会写一堆代码,跑起来试试,然后说"完成了"。可现实是,这类AI经常在写了几十次修改之后,自己都不记得当初要做什么了。它可能会把之前写好能用的功能改坏,可能反反复复修一个小问题却始终没有真正解决,也可能在游戏根本跑不起来的情况下,煞有介事地告诉你"任务完成"。

这不是危言耸听。上海人工智能实验室的一组研究者,最近做了一件挺有意思的事:他们让AI编程助手连续工作了70多轮,耗时六天,从零开始造出一款第一人称射击游戏,有剧情、有战斗、有音效、能让人真正上手玩。这篇论文的名字叫Harness-of-Harness,简称HoH,意思大概是"给AI程序员套一层新的工作流程外壳"。

先说清楚这件事难在哪。

现在的AI编程助手,不管是Codex、还是别的什么工具,本质上都是在一个叫作harness的东西里运行。

harness：可以理解成AI干活时用的"工作台",它决定了AI能看到什么信息、能用什么工具、执行完一步之后结果怎么反馈回去。

这些harness在处理"改一个bug""加一个小功能"这类任务时表现不错,但如果让它从零开始做一整个软件,持续开发几十上百轮,情况就变了。研究者观察到三个具体的问题。

第一个问题是遗忘。软件越做越大,AI的对话窗口却是有限的,早期做的设计决定、暴露出来的bug、已经验证过能用的功能,这些信息会随着开发的推进逐渐从它的"脑子"里溜走。你可以想象一个装修工人,今天上午刚跟你确认好客厅要留插座的位置,下午砌墙的时候就把这事忘了,把插座砌进了墙里。不是他不认真,是他手头信息太多,没有一个稳定的地方帮他记住这些约定。

第二个问题是决策失焦。给一个笼统的需求,比如"做个平台跳跃游戏",接下来具体先做什么、怎么做,这中间有太多可能的分支。做错了选择,或者选择的范围太大太杂,一次改动牵连好几个模块,出了问题都不知道从哪查起。这就像你搬家收拾东西,如果不分房间不分类别,把厨房的锅碗瓢盆和卧室的衣服书籍全塞进一个大箱子,等你想找一件东西的时候,翻遍整箱都未必找得到,而如果按房间分箱、按类别贴标签,出问题时至少知道该往哪个箱子里找。

第三个问题最要命,是虚假完工。软件测试这件事,天然就不是靠"我觉得写完了"就能验证的,得靠实际跑起来看行不行。如果开发和验收都是同一个AI自己说了算,它很容易高估自己的工作,把一个其实跑不起来或者功能缺失的半成品,当成合格产品交出去。

这三个问题堆在一起,就变成了论文里说的核心矛盾:自主软件开发不只是"跑得更久"的问题,而是怎么在很长的开发周期里,让进展保持连贯和有效。

三个角色,一个循环:HoH到底改变了什么

HoH的解法,说穿了并不复杂,复杂的是怎么把它落到实处。

它把原本一个AI harness单打独斗的开发过程,拆成了三个角色轮流上场:项目规划师、开发者、QA测试员。这三个角色其实是同一个AI模型、同一个harness,只是每次调用的时候,给它的权限和任务不一样。规划师只能看,不能改代码,负责决定这一轮该干什么;开发者拿到规划师定的任务,负责真刀真枪地写代码、跑测试;QA测试员则拿到一份"冻结"的最终版本,独立地把它当成一个真实用户去检验,不许自己动手改代码。

这三步循环一轮又一轮地跑,论文里管这个循环叫loop。每一轮循环结束后,产出两样东西传给下一轮:一个是软件本身(代码、资源、配置这些实打实的东西),另一个是"证据",也就是这一轮测试下来到底验证了哪些功能是真的能用、哪些还有问题。

这里有个设计选择值得多说几句。为什么不干脆做一个"记忆模块",让AI自己把重要信息记下来?

论文的做法是不做专门的记忆模块,而是把所有的计划、报告、历史记录都存进文件系统里,先给一个简明的分类索引,只有需要的时候才去翻具体内容。这个思路叫渐进式披露。

渐进式披露:不是把所有历史信息一次性塞给AI,而是先给它一个目录式的概览,等它真正需要某项细节时,再让它自己去查阅完整内容。

这个设计的用意在于,AI的注意力和上下文窗口都是有限资源。如果每一轮都把过去几十轮的所有细节一股脑塞进去,信息量太大,反而会稀释掉真正重要的东西,就像你让一个新来的同事一次性读完公司过去五年的所有会议记录再上手干活,他大概率会被淹没,还不如给他一份索引,让他缺什么查什么。

规划师做的这份文档,论文里叫development document,开发文档。它不是一份大而全的项目规划,而是刻意做得又小又完整。

小,是说每一轮只圈定一小块范围的任务,不允许无关的重构和额外功能扩张混进来。完整,是说这一小块任务必须包含让它真正可测试、可运行所需要的全部相关改动。研究者管这个原则叫bounded but locally complete,有边界但局部完整。

如果只追求"小",完全孤立地选一个任务,可能会漏掉这个任务真正跑通所需要的依赖关系。如果只追求"完整"而不设边界,一次改动牵连太广,出了问题就很难定位是哪个环节出的错。这两个约束合在一起,才让每一轮的进展既可控又可验证。

这里可以做一个类比。假设你要重新装修一整套房子,如果你的施工计划是"今天把厨房、卧室、卫生间同时动工",那么某一天突然停水,你根本分不清是哪个房间的施工出了问题。反过来,如果你今天只做厨房的水电改造,但只改了插座没改水管,厨房照样没法用,因为水电本来就是配套的。真正靠谱的做法,是圈定"厨房水电改造"这一个完整的小任务,做完之后立刻能验收,这个房间的水电到底通不通电、出不出水,一目了然。HoH对每一轮开发范围的控制,本质上就是在做这件事。

测试的两副眼镜:白盒与黑盒

开发者写完代码之后,并不是直接把成果扔给QA测试员就完事了。论文里强调,开发阶段本身就要嵌入测试,这个理念在软件工程里有个专门的说法,叫shift-left testing。

shift-left testing:把测试环节尽量提前,而不是等所有代码都写完才开始测,这样问题暴露得离改动更近,更容易定位和修复。

开发者在写代码之前先建立一个行为基线,每改一点东西就重新跑一遍相关路径,检查有没有引入新问题。这个过程更像是自己给自己把关,决定"这个东西准备好被拿去验收了吗"。

但自己把关和真正的验收,是两码事。真正的QA测试员在拿到最终版本的时候,论文特别强调了一个细节,这份代码是冻结的、只读的。

冻结、只读,意味着测试员不能一边测一边悄悄把bug改了。这个设计初衷其实很朴素:如果测试员既能看又能改,那测出来的结果到底是原本的产品能用,还是测试员顺手补救之后能用,这两者会混在一起分不清楚。就像考试监考老师如果拿着答题卡帮学生涂改答案,那这场考试的成绩到底反映的是学生的真实水平,还是监考老师的水平,已经说不清楚了。冻结机制保证了每一次评估都对应着一个确定不变的候选版本,观察到的结果不会因为评估过程本身而被污染。

测试的方式分成两种,论文管它们叫白盒测试和黑盒测试。

黑盒测试:像普通玩家一样操作游戏,通过键盘鼠标输入、观察屏幕反馈,来判断这个功能玩家能不能感知到、能不能正常使用。

白盒测试:直接检查源代码、配置文件、运行日志这些内部信息,用来诊断问题出在哪、佐证那些光看屏幕表现判断不出来的内部状态。

这两种测试合起来,才能给出一个相对可靠的结论:某个功能到底是真的验证通过了,还是仍然存在缺口。论文里特别提到一点,源代码的存在本身不能被当成"这个功能已经实现"的证据,必须真的跑起来、看见结果才算数。这句话听起来朴素,但恰恰击中了很多AI自证清白的老毛病:写了代码不代表这段代码真的被执行过,更不代表执行的结果符合预期。

跨轮次的记忆:艺术品和证据分开存放

前面提到,每一轮循环结束会产出两个东西传给下一轮,一个是软件本体,一个是测试证据。论文用了数学符号来表示这个传递关系,写作 A_t 和 E_t,分别对应第t轮之后的软件状态和证据状态。

为什么要把这两样东西分开来存,而不是混在一起?

软件本体记录的是"这个东西现在是什么样子",但它不记录"为什么当初要这么改""还有哪些需求没满足""哪些行为已经被验证过、不能再改坏"。这些属于隐藏在开发过程背后的判断依据,光看代码是看不出来的。

举个例子,假设你接手一个前任程序员留下的项目,代码本身能跑,但你不知道当初为什么某个函数要绕这么一大圈去实现一个简单功能,可能是因为这么写能规避某个隐藏的bug,也可能纯粹是历史遗留的坏习惯。如果没有额外的文档记录这些决策背后的原因,后来者要么重新踩一遍前人踩过的坑,要么盲目地把看起来多余的代码删掉,结果引入新的问题。HoH把测试证据单独保留下来,就是为了避免这种"知其然不知其所以然"的困境,让每一轮的规划师能读到前面验证过什么、还差什么、什么地方绝对不能碰。

论文的消融实验直接验证了这个设计的分量。他们把HoH拆掉三个部分单独做对比实验:不更新开发计划、不把测试证据反馈给下一轮规划、不保留之前的软件版本从头重建。结果显示,这三种阉割版本的最终得分,都比完整版HoH低了6到8分左右,其中不保留旧版本从头重来的那种做法,还额外多耗费了不少计算资源,因为每一轮都要把之前搭好的东西重新搭一遍。这说明,继承证据和继承软件本体,两者缺一不可,少了任何一个,系统都会在原地打转、做重复功。

数字说话:三套配置,三个基准,都在涨分

光讲道理不够,得看实际效果。研究者在三个基准测试上验证了HoH,分别叫GameCraft-Bench、FrontierSWE、ProgramBench,涵盖游戏开发、软件工程仓库级任务、从零重建程序这三类场景。测试用了三套不同的AI配置,分别是Codex配GPT-5.5、OpenCode配DeepSeek-V4-Pro、Pi配MiniMax-M3。

在GameCraft-Bench这个游戏开发基准上,三套配置在跑了三轮HoH循环之后,平均分都有大幅提升。用Codex配GPT-5.5的那套,从49.58分涨到71.52分,涨了超过21分。用OpenCode配DeepSeek-V4-Pro的那套涨幅更夸张,从26.90分涨到48.98分,涨了22分,几乎翻倍。用Pi配MiniMax-M3的那套从42.16分涨到58.78分。

在FrontierSWE这个更偏工程实操的基准上,涨幅同样明显,Codex这套配置的官方评分从0.31涨到0.54。研究者还特意让Codex这套配置多跑了几轮,一直跑到第十轮,发现分数还在继续涨,从22%一路涨到72.67%,说明这个方法不是"跑三轮就到头了",而是能持续吃到红利。

有一点特别值得单独拿出来说。研究者担心,涨分会不会只是因为让AI多干了几轮活,跟HoH这套流程本身没关系,单纯是"多花时间就能多得分"。为了排除这个疑虑,他们专门做了一组对照实验,叫Vanilla Continuation,就是让原始的、没套HoH流程的AI,单纯地被反复要求"接着开发和测试",跑一样的轮数。结果发现,同样跑三轮,普通反复迭代的方案只能拿到58.24分,而套了HoH流程的能拿到71.52分,差了13分。更关键的是,普通反复迭代那组用的token数(可以理解成AI思考和输出消耗的资源量)其实更多,达到6.33百万,而HoH跑两轮才5.67百万就已经超过了普通方案跑三轮的成绩。这说明真正起作用的不是多花了多少计算资源,而是这套planning-coding-testing的循环结构本身,让每一份计算资源用得更有效率。

这个结果不难理解。反复地对同一个AI说"继续开发和测试",相当于让它自己既当运动员又当裁判,还没有人帮它整理前面留下的坑;而HoH的三角色循环,相当于强制引入了一个独立的、不受开发者本人立场影响的验收环节,再加上有条理的任务拆分,自然更能把力气用在刀刃上。

六天,七十轮,一款真正能玩的FPS游戏

前面说的都是标准化基准测试,规模相对可控。真正让这篇论文有说服力的,是他们做的一个更硬核的案例:让HoH从零开始,连续开发六天、跑了七十多轮循环,做出一款叫Fusepoint的第一人称射击游戏。

这个游戏的产品需求文档写得相当具体:一个五分钟的单人拆弹任务,需要按顺序占领两个控制点,在最终目标处完成三阶段拆弹,固定配置18个敌人分布在三个区域(3个、5个、10个),还要有成功和引爆两种不同的结局分支。这些需求要真正落地,得把三维场景、外部美术资源、任务逻辑、战斗机制、剧情推进、界面反馈、运行稳定性全部拧到一起。

整个开发过程用的是Godot游戏引擎,配合一个叫Godot MCP的工具让AI能直接操作引擎、执行调试。研究者还给HoH配了一整套专门为游戏开发准备的技能包,包括怎么找素材、怎么保持美术风格统一、怎么测试游戏行为。所有外部素材都遵守可商用的授权协议。

人类在整个过程中的参与,严格限定在"网络断了帮忙重连一下""API额度用完了续个费"这种基础设施层面,规划、写代码、调试、测试、验收,全部是AI自己完成的。

七十轮下来,研究者用GitHub的issue系统追踪了整个开发轨迹,记录下新增问题、关闭问题、重新打开的问题这三条曲线。观察到的模式挺有意思,大致能分成三个阶段。前27轮是初始构建期,AI把可执行的项目骨架和核心交互路径搭起来,这个阶段随着代码越写越多,能测试的东西也越来越多,暴露出来的问题反而在增加,积压的待办事项数量是上涨的。接下来28到49轮是能力扩展期,新功能和持续修复交织在一起,因为项目已经变得比较复杂,改一个地方经常牵连到之前搭好的任务状态、战斗系统、界面反馈或者运行稳定性,处理起来更费劲。到了后期,新功能添加的速度慢下来,修bug占了上风,积压问题开始逐渐下降,进入稳定收尾阶段。

到第70轮的时候,累计记录了81个问题,其中65个被关闭,还剩16个没解决。有个数字很值得琢磨,一共有17个问题曾经被标记为已关闭,后来又重新打开了,原因是后续的某次改动导致之前已经验证通过的功能又坏掉了。这种回归问题的记录方式,恰好体现了HoH保留证据的价值。一个被重新打开的issue,不仅标注了这次又坏了什么,还连着它之前是怎么被验证通过的历史记录,后面的规划师不需要靠猜测去重建这段历史,直接就能看到完整的来龙去脉。

这就好比一栋房子装修,水管漏了修好了,过了两个月又漏了,这时候如果有一份完整的维修档案,记着上次是哪个师傅、用了什么材料、具体修的哪个接口,这次维修就能直接对着上次的记录排查,而不是从头开始猜是不是同一个地方。HoH靠版本化记录加issue追踪,本质上就是在给这个多天连续开发的项目建立一份"维修档案"。

从Overall分数拆开看:改进具体体现在哪

GameCraft-Bench这个基准打分并不是单一维度,它拆成了四块:核心机制、内容深度、视觉功能性、美术呈现。研究者把这四块分开来看,发现HoH在所有维度上都有提升,而不是只在某一个方面偷懒式地刷分。

拿Codex这套配置举例,视觉功能性这一项从48.67涨到74.23,涨幅最大;美术呈现从45.28涨到65.28。研究者还给了几个具体的游戏对比案例。有一款叫Momentum Lab的平台跳跃游戏,原始版本的场景是几个光秃秃的几何色块拼出来的平台,玩家很难看出目标在哪、该怎么跳;经过HoH三轮迭代之后,场景变成了有主题风格的地形,还加上了明确的视觉引导线索,指示墙跳的路线。另一款叫Kitchen Rush的餐厅经营游戏,原始版本只有一个孤零零的出餐区域,经过迭代之后变成了取餐、备菜、出餐、清理垃圾这一整套完整且可读的工作流。

这些细节说明,HoH带来的提升不只是让游戏"能跑起来"这么低的门槛,而是真的让游戏变得更完整、更好玩、更像一个正经产品。

写在后面

读完这篇论文,最让我意外的一点,其实不是HoH三角色循环本身,毕竟"规划-执行-验收"分离这个思路,在软件工程里早就有,做过项目管理的人应该都不陌生。真正让我多想了一层的,是那个"证据"这个概念的设计。它把"这个功能测试通过了"和"这个功能应该被保留、不能再改坏"这两件事绑定在了一起,变成了下一轮规划师读取的硬约束,而不是一份写完就扔的测试报告。这相当于给AI装了一套显性的"承诺记忆",逼着它不能对自己已经验证过的东西装作没看见。

还有一个细节让我觉得挺值得琢磨,就是那17个"重新打开又关闭"的issue。这说明即便有了这套流程,AI在长达六天的开发里依然会犯回头的错误,新的改动依然会踩到旧的坑。HoH解决的不是"AI不会犯错"这个问题,它解决的是"犯的错能不能被追溯、被系统性地记录下来,而不是消失在对话历史里"。这两者的差别,可能才是长周期自主开发这件事真正的门槛所在。

论文里提到的这个七十轮、六天的Fusepoint游戏案例,让我忍不住想,如果把开发周期拉长到七十天而不是六天,这套证据积累和版本回溯的机制,还能不能撑得住?积压的issue会不会到某个阈值之后开始失控地滚雪球?这大概是这篇论文暂时没有回答、但值得继续追问的问题。

Q&A

Q1：Harness-of-Harness是什么？

A：Harness-of-Harness简称HoH,是上海人工智能实验室提出的一套框架,能让现有的AI编程助手在不修改自身实现的前提下,以规划、开发、测试三个角色循环运作的方式,持续改进正在开发中的软件,支持从零开始的长周期自主软件开发。

Q2：HoH在实验中的效果具体提升了多少？

A：在GameCraft-Bench、FrontierSWE、ProgramBench三个基准上,HoH在三套AI配置下都明显超越了不套用该流程的普通方案,跑完三轮循环后平均相对提升52.25%,最高相对提升达到82.86%,并且在FrontierSWE上持续跑十轮依然能继续涨分。

Q3：HoH做的那款FPS游戏Fusepoint是完全无人工干预完成的吗？

A：开发过程中人工参与仅限于网络或API额度这类基础设施层面的恢复工作,规划、编码、调试、测试、验收全部由AI自主完成,历时六天、跑了70多轮循环,最终做出一款有剧情、战斗系统、音效和可玩体验的第一人称射击游戏。