1. 从5亿token到72个游戏这个周末我到底干了什么周末两天我用智谱开放平台赠送的5亿token额度批量生成并跑通了72个可直接玩的小游戏全部代码已经整理开源。这不是标题党也不是跑个Hello World凑数——72个游戏涵盖了贪吃蛇、扫雷、2048、打砖块、俄罗斯方块、五子棋、飞机大战、连连看、数独、推箱子等经典品类每一个都是独立可运行的HTML单文件或轻量项目打开浏览器就能玩。先说清楚这件事的定位它适合有一定编程基础、想了解大模型批量代码生成实际能力边界的人适合手里攥着免费token不知道怎么花、想找个高性价比练手项目的开发者也适合想给孩子做编程启蒙、需要一批现成小游戏案例的家长和老师。哪怕你只是好奇5亿token到底能产出多少东西这篇记录也能给你一个真实的参考坐标。为什么选游戏作为批量生成的目标因为游戏是检验代码生成质量最直观的试金石。一个游戏能不能跑逻辑对不对交互顺不顺打开浏览器三秒钟就能判断不需要写复杂的测试用例也不需要搭后端环境。而且游戏天然包含状态管理、事件处理、碰撞检测、渲染循环这些编程核心概念能比较全面地暴露模型在代码生成上的强项和短板。整个周末的流程大致是先摸清token额度和接口的脾气再设计一套可复用的批量生成流水线然后分批跑72个游戏的生成任务中间不断修bug、调prompt、补逻辑最后统一整理、测试、打包开源。下面我把这套流程完整拆开讲包括踩过的坑和最后沉淀下来的可复现方案。2. 开工前的准备token额度、接口选型和环境搭建2.1 5亿token到底是个什么概念很多人对token没概念我先算一笔账。一个中文字大约对应1到2个token一段普通的游戏代码比如贪吃蛇大概300到500行折算下来差不多8000到15000个token。如果算上生成过程中的多轮对话、报错修复、逻辑补充单个游戏的实际消耗大概在3万到8万token之间。72个游戏乘下来总消耗在300万到600万token量级。也就是说5亿token对于这个项目来说是绰绰有余的我实际只用了不到2%的额度。这个数字的意义在于它给了你极大的试错空间。你可以放心地让模型反复重写、让它解释逻辑、让它补充注释、让它换一种实现方式不用担心额度见底。这种随便造的心态恰恰是批量生成能跑通的关键——如果每花一个token都心疼你就不敢让模型多轮迭代生成质量反而上不去。提示免费额度通常有有效期领到手之后先确认过期时间别攒着不用。批量任务最好集中在有效期内跑完。2.2 接口选型为什么用API而不是网页版网页版对话适合单次交互但72个游戏的批量生成必须走API。原因很直接网页版没法脚本化你不可能手动复制粘贴72次更没法做自动重试和结果落盘。API的核心优势是可控——你可以控制温度参数、最大输出长度、系统提示词可以把每次请求的输入输出完整记录下来出问题了能回溯。我用的模型是GLM系列通过标准的HTTP接口调用。选它的理由有三个一是额度给得大方适合这种批量消耗型任务二是代码生成能力在同价位里比较扎实尤其是前端JavaScript和HTML这块三是接口稳定批量跑的时候很少出现超时或限流。环境方面我用的是一台普通的开发机Python 3.10装了requests和几个辅助库。没有用任何复杂的框架因为批量生成这件事本身逻辑很简单读任务列表、调接口、存结果、跑测试。过度工程化反而会增加调试成本。2.3 目录结构设计一开始就要想清楚批量项目最怕的就是文件乱成一锅粥。我在动手前先把目录结构定死了game-batch/ ├── tasks/ # 任务清单每个游戏一个json ├── outputs/ # 模型原始输出按游戏名分目录 ├── games/ # 清洗后的可运行游戏 ├── logs/ # 每次请求的完整日志 └── scripts/ # 批量脚本这个结构的好处是每一层职责清晰。tasks里放要生成什么outputs里放模型给了什么games里放最终能跑什么logs里放过程发生了什么。出问题的时候你能快速定位是任务描述的问题、模型输出的问题还是清洗环节的问题。我见过太多人把所有东西堆在一个文件夹里跑到一半自己都分不清哪个文件是哪个版本。3. 批量生成流水线的核心设计3.1 任务清单怎么定72个游戏不是随便凑的72个游戏不是拍脑袋想出来的我按品类做了分层设计确保覆盖面广、难度递进、且每个都有明确的实现边界。品类代表游戏数量技术难点经典街机贪吃蛇、打砖块、飞机大战18游戏循环、碰撞检测益智解谜2048、数独、推箱子16状态管理、回溯算法棋牌对战五子棋、井字棋、黑白棋12胜负判定、AI落子休闲反应连连看、记忆翻牌、打地鼠14计时器、随机生成综合模拟俄罗斯方块、扫雷、生命游戏12复杂状态机、渲染优化分层的目的有两个。一是控制变量同一品类的游戏技术栈相似如果贪吃蛇生成得好同类的打砖块大概率也不会差出问题也容易归因。二是保证多样性如果72个全是贪吃蛇变体那这个项目的说服力就大打折扣了。每个任务在json里包含这几个字段游戏名、品类、核心玩法描述、技术要求比如用Canvas实现或纯DOM操作、难度等级、参考特性列表。描述写得越具体模型生成的结果越可控。我一开始偷懒只写生成一个贪吃蛇游戏结果模型给了一个用alert弹窗控制方向的奇葩版本根本没法玩。3.2 Prompt模板把要求说死别让模型猜批量生成的核心是prompt模板。我的模板大致长这样你是一个资深前端游戏开发者。请用单个HTML文件实现一个【游戏名】游戏。 核心玩法【玩法描述】 技术要求 - 使用原生JavaScript不依赖任何外部库 - 所有代码写在一个HTML文件里包含CSS和JS - 使用Canvas或DOM实现根据游戏类型选择 - 必须有开始、暂停、重新开始功能 - 界面简洁美观配色协调 必须实现的特性 【特性列表】 输出要求 - 只输出完整的HTML代码不要任何解释文字 - 代码开头用注释标明游戏名和操作说明 - 确保代码可以直接在浏览器打开运行这个模板里有几个关键设计。第一只输出完整HTML代码不要解释——这一条极其重要否则模型会在代码前后加一堆好的我来帮你实现之类的废话清洗起来很烦。第二不依赖外部库——避免引入CDN链接保证离线可运行。第三必须有开始暂停重开——这是游戏完整性的底线很多模型生成的游戏一打开就开始跑没法控制。注意不同模型对只输出代码的遵循程度不一样。有的模型很听话有的会偷偷加解释。我的做法是在清洗环节用正则把代码块提取出来不管前后有什么废话只取html和之间的内容。3.3 批量脚本并发、重试、落盘一个都不能少批量脚本的逻辑不复杂但有几个细节必须处理好。并发控制72个任务如果串行跑每个游戏平均生成时间30秒到1分钟总共要一个多小时。我用了线程池并发数设成5。为什么不设更高因为并发太高容易触发接口限流反而拖慢整体速度。5这个数字是我实测下来比较稳的平衡点。重试机制批量任务最怕的就是个别请求失败导致整个流程中断。我给每个请求加了3次重试每次间隔递增2秒、5秒、10秒。重试的时候把温度参数稍微调高一点有时候换个随机种子就能绕过一些偶发的生成异常。结果落盘每次请求的完整输入输出都存到logs里模型返回的原始内容存到outputs里。这样做的好处是即使脚本中途崩了已经生成的结果不会丢可以从断点继续。import json import os import time from concurrent.futures import ThreadPoolExecutor def generate_game(task, retry3): for attempt in range(retry): try: response call_api(build_prompt(task)) save_output(task[name], response) return True except Exception as e: log_error(task[name], str(e)) time.sleep(2 ** attempt) return False with ThreadPoolExecutor(max_workers5) as executor: results list(executor.map(generate_game, tasks))这段代码是简化版实际用的时候还要加上日志记录、进度打印、失败任务单独收集。但核心逻辑就这些不需要更复杂。4. 生成过程中的真实问题与修复实录4.1 模型生成的代码跑不起来怎么办这是最常见的问题。72个游戏里第一轮生成能直接跑通的只有大概40个剩下的要么白屏要么报错要么逻辑不对。我把问题归了几类每类的处理方式不一样。白屏问题通常是JavaScript报错导致整个脚本挂掉。排查方法是打开浏览器控制台看报错信息。常见原因有变量未定义、函数调用顺序错误、Canvas获取失败。这类问题我直接把报错信息贴回给模型让它修复。修复prompt的写法是以下代码运行时报错【错误信息】请修复并输出完整代码。逻辑错误代码能跑但游戏玩不了。比如贪吃蛇吃到食物不增长、打砖块球穿墙、2048合并规则不对。这类问题模型自己看不出来需要我描述现象。修复prompt要具体贪吃蛇吃到食物后长度没有增加请检查增长逻辑并修复。渲染问题游戏能玩但画面错位、颜色诡异、元素重叠。这类问题优先级最低因为不影响功能。我一般批量攒着最后统一让模型优化UI。实操心得修复的时候不要把整个代码重新生成而是让模型只输出修改后的完整代码。有些模型会偷懒只输出改动部分导致你还要手动合并。在prompt里明确要求输出完整可运行代码能避免这个问题。4.2 token消耗的监控与优化虽然5亿token很充裕但监控消耗仍然有必要因为你能从中发现哪些任务性价比低。我记录每个游戏的token消耗发现一个规律逻辑复杂的游戏比如带AI的五子棋消耗是简单游戏比如打地鼠的3到5倍主要消耗在修复轮次上。优化手段有两个。一是把复杂游戏的prompt写得更细减少模型自由发挥的空间从而减少修复轮次。二是对于反复修不好的游戏果断换一种实现思路重新生成而不是在错误的方向上死磕。我有个推箱子游戏修了6轮还是有问题最后换了个用二维数组表示地图的明确要求重新生成一次就过了。4.3 代码清洗从模型输出到可运行文件模型返回的内容不能直接存成HTML文件需要清洗。清洗规则我写了一个函数提取html和之间的内容如果没有代码块标记就找!DOCTYPE html到/html之间的内容。去掉代码前后的解释文字。检查是否包含html、script等必要标签缺失的补上。统一文件编码为UTF-8避免中文乱码。清洗完之后每个游戏存成独立的HTML文件文件名用游戏名的拼音避免中文路径在某些系统上的兼容问题。4.4 自动化测试怎么判断72个游戏是不是真的能玩人工一个个打开测试太慢了。我写了一个简单的自动化检查脚本用无头浏览器加载每个HTML文件检查三件事页面是否正常加载、控制台是否有报错、Canvas或主要DOM元素是否存在。这个脚本能过滤掉大部分完全跑不起来的游戏剩下的再人工抽检。// 用Puppeteer做基础检查的思路 const page await browser.newPage(); const errors []; page.on(console, msg { if (msg.type() error) errors.push(msg.text()); }); await page.goto(file://${gamePath}); await page.waitForTimeout(2000); const hasCanvas await page.$(canvas) ! null; const hasContent await page.evaluate(() document.body.innerHTML.length 500);这个检查不能保证游戏好玩但能保证游戏能打开。对于批量项目来说先把底线守住再谈质量。5. 72个游戏的分类拆解与代表性案例5.1 经典街机类游戏循环是核心贪吃蛇、打砖块、飞机大战这类游戏核心都是游戏循环——每隔一段时间更新一次状态然后重新渲染。模型对这类结构的理解比较到位生成质量普遍不错。以贪吃蛇为例模型生成的版本用了setInterval做循环方向控制用键盘事件食物随机生成碰撞检测用坐标比对。基本逻辑都对但有几个细节需要修一是方向控制没有做禁止反向处理蛇可以180度掉头直接撞死自己二是速度固定没有随分数加快。这两个问题我通过补充prompt让模型加上了。打砖块的难点在球的反弹角度计算。模型第一版用的是简单的碰到边界就反向导致球永远走直线玩起来很无聊。我要求它根据球撞击挡板的位置计算反弹角度第二版就正常了。这说明模型有能力实现复杂逻辑但需要你明确提出来它不会主动帮你想到。5.2 益智解谜类状态管理见真章2048和数独这类游戏考验的是状态管理能力。2048的核心是一个4x4的二维数组每次滑动要处理合并、移动、生成新数字、判断游戏结束。模型生成的2048第一版有个经典bug合并的时候没有处理一次滑动只能合并一次的规则导致[2,2,2,2]滑动后变成[8]而不是[4,4]。这个bug的修复过程很有意思。我一开始描述合并规则不对模型改了两轮都没改对。后来我直接把规则写清楚每次滑动每个方块只能参与一次合并[2,2,2,2]向左滑动应该变成[4,4]而不是[8]模型立刻就改对了。这告诉我一个道理跟模型沟通具体例子比抽象描述有效得多。数独的生成算法是另一个难点。模型第一版用的是随机填数然后验证效率极低有时候要跑好几秒才能生成一个合法数独。我要求它用回溯算法生成完整数独然后随机挖空第二版就快多了。这说明模型知道回溯算法但默认可能选最笨的实现方式你需要引导它。5.3 棋牌对战类AI落子是分水岭五子棋、井字棋这类游戏如果只是双人对战实现很简单。但如果要加AI对手难度就上来了。我给五子棋的要求是实现一个简单AI能根据当前局面选择落子位置。模型第一版AI是纯随机的随便找个空位就下毫无挑战性。我要求它评估每个空位的价值优先选择能形成连线的位置第二版就有了基本的攻防意识。虽然棋力还是很弱但至少能跟新手过几招了。这里有个经验对于AI逻辑不要指望模型一次生成很强的算法。合理的期望是能做出看起来合理的决策而不是能打败人类。如果你需要更强的AI得自己实现极小化极大搜索或者接入专门的算法库。5.4 休闲反应类计时器和随机性是关键打地鼠、记忆翻牌、连连看这类游戏技术难度不高但很考验细节。打地鼠的核心是随机出现和计时消失模型生成的版本经常出现地鼠不消失或者同时出现太多的问题。修复方法是明确时间参数地鼠出现后1.5秒自动消失同时最多出现3只。记忆翻牌的核心是卡牌配对逻辑。模型生成的版本有个常见问题翻开的牌在匹配失败后不会翻回去。这个需要加一个延迟翻转的逻辑用setTimeout实现。我在prompt里补充匹配失败后0.8秒将两张牌翻回背面问题就解决了。连连看的难点是路径判定——两张牌能否用不超过两个拐角的线连接。这个算法模型实现得还行但偶尔会有边界情况判断错误。我抽检了几个案例发现主要是拐角数计算的问题手动修了一下。6. 开源整理怎么让这72个游戏真正有用6.1 仓库结构让人一眼看懂开源不是把文件往仓库一扔就完事。我花了不少时间整理仓库结构目标是让任何人打开仓库30秒内就知道这是什么、怎么用。awesome-72-games/ ├── README.md # 项目说明、游戏列表、玩法索引 ├── games/ # 72个游戏按品类分文件夹 │ ├── arcade/ │ ├── puzzle/ │ ├── board/ │ ├── casual/ │ └── simulation/ ├── index.html # 游戏导航页点击直接玩 ├── docs/ # 生成过程记录、prompt模板 └── LICENSE那个index.html导航页是我额外做的把所有游戏用卡片形式列出来点击直接跳转。这个小东西极大提升了项目的可用性——别人不用去翻文件夹找游戏打开导航页就能玩。6.2 README怎么写别写成流水账README我改了三版。第一版写成了我做了什么的流水账读起来像日记。第二版改成了功能列表但太干巴。第三版才找到平衡开头一段话说清楚项目是什么、怎么来的、能用来干嘛然后放游戏列表表格再放使用说明和生成方法。游戏列表用表格呈现包含游戏名、品类、难度、直接试玩链接。使用说明分两种场景想直接玩的打开index.html想研究代码的进games文件夹想复现生成过程的看docs里的prompt模板和脚本。6.3 开源协议和注意事项协议我选了MIT最宽松的那种别人可以随便用、随便改、甚至商用。选MIT的理由很简单这些游戏代码本来就是模型生成的我没有理由限制别人使用。而且MIT协议能让项目传播得更广对大家都有好处。注意开源模型生成的代码时最好在README里说明代码来源和生成方式。一方面是透明另一方面也提醒使用者这些代码是AI生成的可能存在问题生产环境使用前需要自己审查。7. 关于批量代码生成我踩过的坑和总结的经验7.1 常见问题速查表问题现象可能原因解决方法生成结果带大量解释文字prompt未明确要求只输出代码在prompt里加只输出代码不要解释代码跑起来白屏JS报错导致脚本中断看控制台报错把错误信息贴回给模型修复游戏逻辑不对模型对规则理解有偏差用具体例子描述正确行为别用抽象描述修复多轮仍不对实现思路本身有问题换一种明确的实现要求重新生成并发请求失败率高并发数过高触发限流降低并发数加重试机制中文显示乱码文件编码不统一统一存为UTF-8HTML里加meta charset游戏无法暂停/重开prompt未要求这些功能在必须实现的特性里明确列出7.2 几条用token换来的经验第一条prompt的详细程度和修复轮次成反比。你前期多写50个字描述需求后期可能少修3轮。我统计过描述详细的游戏平均修复1.2轮描述简略的平均修复3.5轮。按每轮消耗5000 token算详细描述反而更省token。第二条不要指望模型一次生成完美代码。把批量生成理解成模型出初稿你来当编辑的流程。你的价值不在于写代码而在于判断哪里不对、怎么描述问题、什么时候该放弃重来。第三条复杂游戏拆成多个prompt分步生成比一个prompt全包效果更好。比如俄罗斯方块我先让它生成方块下落和消行逻辑再让它加上分数和等级系统最后优化UI和操作手感。分步生成每步都简单模型出错率低而且方便定位问题。第四条保留所有中间产物。模型的第一版、修复版、最终版都留着。有时候你会发现第一版的某个部分其实更好可以拿来拼装。而且这些记录本身就是很好的学习材料能看出模型在哪些地方容易犯错。7.3 这套方法还能用在哪些场景批量生成游戏只是这套流水线的一个应用。同样的思路可以迁移到很多场景批量生成数据可视化图表、批量生成表单页面、批量生成API文档示例、批量生成测试用例。核心逻辑是一样的——定义清晰的任务清单、设计严格的prompt模板、建立自动化的清洗和检查流程、保留完整的中间记录。关键不在于你生成的是什么而在于你建立了一套可批量、可复现、可追溯的工作流。这套工作流一旦跑通你换任何生成目标都能快速复用。我后面打算用同样的方法批量生成一批小工具页面比如计算器、倒计时、单位换算之类的思路完全一样。最后分享一个我实际用下来很顺手的小技巧在批量任务开始前先拿3个不同类型的任务做小规模试跑验证prompt模板和清洗流程没问题再全量铺开。这3个任务的成本很低但能帮你提前发现80%的流程问题。我这次就是先跑了贪吃蛇、2048、打地鼠三个发现清洗环节的正则有问题及时修了才没影响后面的69个。