1. 五亿token到手之后我为什么选择批量做小游戏拿到智谱赠送的五亿token额度那天我盯着后台的用量面板看了很久。五亿token是什么概念按一次对话平均消耗两千token来算理论上能跑二十五万次请求。如果拿来做代码生成一个中等复杂度的项目消耗两三万token那也能支撑上万次完整的代码生成任务。这个量级对于个人开发者来说几乎等于把试错成本这个顾虑彻底抹掉了。我当时的想法很直接既然额度管够那就找一个能批量验证、快速出成果、且能覆盖多种编程范式的方向。思来想去小游戏是最合适的载体。原因有三第一单个游戏的代码量可控通常几百到两千行就能跑起来适合用大模型一次性生成第二游戏逻辑天然包含状态管理、输入处理、渲染循环、碰撞检测这些通用编程模式能全面检验模型的代码能力第三游戏有明确的能跑/不能跑判定标准不需要复杂的测试框架打开浏览器就知道成没成。于是就有了这个周末的计划用智谱的GLM系列模型配合zcode工具链批量生成七十二个小游戏全部开源。这篇文章不是来炫耀成果的而是把这七十二个游戏从零到跑通的完整过程拆开讲——包括我怎么设计批量生成的流水线、怎么处理模型输出的各种意外、怎么在几百个文件里做质量筛选以及踩过的那些坑。如果你手里也有一批token额度不知道怎么花或者想了解大模型批量代码生成的实际工程细节这篇应该能给你一些参考。2. 批量生成流水线的设计从单次对话到七十二个产物2.1 为什么不能一个游戏一个游戏手动聊最开始我确实想过偷懒直接在对话界面里一个个让模型写。试了三个之后就放弃了。问题不在于模型写得不好而在于手动流程的摩擦成本太高每次要重新描述需求、要复制粘贴代码、要手动建文件、要改文件名、要记录哪个游戏对应哪次对话。一个游戏平均花十五分钟在非生成的杂事上七十二个就是十八个小时一个周末根本不够。更关键的是手动模式下你没法保证生成条件的一致性。第一个游戏你可能说写一个贪吃蛇第十个游戏你可能说用HTML5 Canvas写一个带计分和加速机制的贪吃蛇游戏提示词的细微差异会导致输出质量波动最后你根本分不清是模型能力问题还是提示词问题。所以我决定做一条批量化流水线。核心思路是把游戏需求抽象成结构化的配置把生成抽象成一次API调用把落盘抽象成脚本自动处理。这样每个游戏的生成条件完全一致唯一变量就是游戏类型本身。2.2 流水线的四个核心模块整条流水线我拆成了四个模块每个模块职责单一方便单独调试。需求配置模块用一个JSON文件描述所有七十二个游戏。每个游戏包含字段游戏名称、英文标识、核心玩法描述、技术栈要求、特殊机制要求。比如贪吃蛇的配置大概是这样的{ name: 贪吃蛇, slug: snake, gameplay: 玩家控制蛇在网格中移动吃到食物后身体变长撞墙或撞到自己则游戏结束, tech: HTML5 Canvas 原生JavaScript单文件, features: [计分, 速度随长度递增, 方向键控制, 暂停功能] }这个配置文件是整个流水线的输入源后面所有步骤都从这里读数据。提示词组装模块根据配置生成发给模型的提示词。这里有个关键设计——我把提示词分成了固定模板和变量填充两部分。固定模板里写死了输出格式要求比如只输出一个完整的HTML文件不要解释不要markdown代码块标记变量部分才填入具体游戏需求。这样做的好处是输出格式高度可控后面解析起来省事。API调用模块负责实际发起请求。我用的是智谱的API接口模型选的glm-5.3-flash主要是看中它在代码生成上的响应速度和稳定性。这里要处理几个工程问题并发控制不能一次性发七十二个请求把额度打满、失败重试网络抖动或限流导致的失败要自动重试、超时处理有些复杂游戏生成时间较长。我设的是并发数五单次超时一百二十秒失败重试三次。落盘与索引模块把模型返回的内容写成文件同时生成一个索引页。索引页是个简单的HTML列出所有游戏名称和链接方便一次性浏览全部成果。这个模块还要做基础校验检查返回内容是否包含HTML标签、文件大小是否在合理范围、有没有明显的截断。2.3 并发数为什么定在五而不是更高这里展开说一下并发数的选择。理论上你可以把七十二个请求一次性全发出去但实际会遇到两个问题。一是API侧的限流策略虽然额度够但单位时间内的请求频率通常有上限发太快会触发限流导致大量失败。二是本地处理能力每个返回结果都要解析、校验、写文件并发太高会导致内存和IO压力集中。我实测下来并发五是一个比较舒服的平衡点。七十二个游戏分十五批左右跑完总耗时大概四十分钟其中大部分时间花在等待模型生成上。如果你追求更快可以试并发八到十但要相应增加重试次数和错误处理逻辑。再高就不建议了收益递减明显反而增加排查成本。提示并发数不是越高越好。批量任务里稳定跑完比跑得快更重要。一次失败重试的成本往往比降低并发多花的时间更高。3. 提示词工程让模型稳定输出可运行的单文件游戏3.1 输出格式约束是第一条生命线批量生成最怕的不是模型写得差而是模型写得好但格式不对。比如它给你返回一段带markdown代码块标记的内容或者前面加一段好的我来帮你写一个贪吃蛇游戏的说明你的自动落盘脚本就得额外做清洗。清洗逻辑越复杂出错的概率越高。所以我在提示词里把格式约束放在了最前面而且用了比较强硬的措辞。大意是你是一个代码生成器只输出一个完整的、可直接在浏览器打开的HTML文件从!DOCTYPE html开始到/html结束不要有任何额外文字不要用代码块包裹。这个约束加上few-shot示例我给了一个极简的示例输出基本能把格式问题压到百分之五以下。剩下那百分之五的格式异常我在落盘模块里做了兜底处理如果检测到内容以代码块标记开头就自动剥离如果检测到内容前面有非HTML文本就找到第一个符号开始截取。这套组合拳下来七十二个游戏里只有两个需要人工介入。3.2 技术栈锁定能大幅降低不确定性小游戏的技术栈选择很多可以用纯Canvas、可以用DOM操作、可以用WebGL、可以引入第三方库。如果不锁定模型每次可能选不同的方案导致代码风格不统一后期维护和阅读都麻烦。我的做法是在提示词里明确要求使用HTML5 Canvas加原生JavaScript不引入任何外部依赖所有代码写在一个HTML文件里。这个约束带来三个好处一是零依赖意味着打开就能跑不需要配环境二是单文件意味着索引页可以直接用iframe嵌入浏览体验统一三是原生JS意味着代码量可控不会因为引入库而产生大量样板代码。实测下来这个约束执行得相当好。七十二个游戏里有六十八个是完全符合的另外四个里有两个用了内联的CSS动画代替Canvas对于某些游戏其实更合适有两个引入了一个CDN上的轻量库我手动改成了原生实现。整体符合率超过百分之九十四。3.3 玩法描述的颗粒度怎么把握这是我在调试过程中反复调整的一个点。描述太粗模型会自由发挥生成的东西可能偏离预期描述太细等于我自己把逻辑写了一遍失去了用模型的意义。我的经验是描述清楚核心循环和胜负条件就够了中间的实现细节交给模型。比如贪吃蛇我只需要说蛇在网格中移动吃食物变长撞墙或撞自己结束不需要说用二维数组存储蛇身坐标每帧根据方向更新头部位置。后者是模型应该自己决定的实现细节。但有一类信息必须写清楚就是特殊机制。比如某个游戏要求每吃五个食物速度提升一档这种非默认行为如果不写模型不会主动加。所以我的配置里专门有个features字段用来列这些额外要求。这个字段的颗粒度控制在一句话能说清一个机制的程度。3.4 处理模型自作主张加功能的情况批量生成到第二十几个游戏的时候我发现有些游戏模型会额外加一些我没要求的功能。比如一个简单的打砖块游戏它自己加了关卡系统和道具掉落。这些功能本身不坏但会导致代码量膨胀有些还引入了bug。我的处理策略分两种。如果加的功能不影响核心玩法且代码能跑我就保留当作意外收获。如果加的功能导致代码跑不起来我就在提示词里加一句只实现上述功能不要添加额外机制然后重新生成。这个约束加上之后输出就规矩多了。这里有个心得模型加功能往往是因为它在训练数据里见过类似游戏的完整版它倾向于输出一个完整的实现。你要做的不是批评它而是明确告诉它边界在哪里。4. 七十二个游戏跑下来模型在哪些地方翻车了4.1 物理模拟类游戏是重灾区七十二个游戏里翻车最集中的是涉及物理模拟的类型比如弹球、抛体运动、碰撞反弹。模型在处理这类问题时经常出现两种错误一是速度向量更新逻辑写反导致球往错误方向弹二是碰撞检测的边界条件处理不当导致球卡在墙壁里或者穿透。我印象最深的是一个打砖块游戏模型写的碰撞检测是这样的当球的位置超出边界时反转速度方向。逻辑上没错但它没有考虑球在一帧内移动距离超过边界厚度的情况导致球高速运动时会直接穿墙。修复方法是在检测到越界后把球的位置重置到边界内侧而不是只反转方向。这类问题的根源在于模型对连续运动在离散帧中如何正确处理这个经典问题理解不够深。它在生成代码时更多是在模仿见过的代码模式而不是真正推导物理过程。所以涉及物理的游戏我建议生成后一定要手动跑一遍重点看高速运动和边界情况。4.2 状态管理在复杂游戏里容易乱简单游戏的状态很少一个分数、一个游戏状态标志就够了。但稍微复杂一点的游戏比如带多关卡、多道具、多敌人类型的状态就多了。模型在这种情况下容易出现状态更新不同步的问题。具体表现是某个状态变量在A处更新了但B处还在用旧值或者两个状态变量之间的约束关系被破坏比如生命值为零时游戏结束这个约束在某个分支里没检查。这类bug不会导致游戏崩溃但会导致行为诡异比如角色死了还能动、分数不增加等。我的应对方法是在提示词里加一句确保所有状态更新在同一个游戏循环内完成避免跨帧的状态依赖。这句话不能完全杜绝问题但能减少一部分。剩下的还是得靠人工测试。4.3 输入处理的边界情况经常被忽略键盘输入处理看起来简单但边界情况不少。比如同时按下多个方向键怎么办按住不放和连续点击怎么区分游戏暂停时输入要不要响应模型生成的代码在这些地方经常有疏漏。一个典型例子是俄罗斯方块模型写的旋转逻辑在方块靠近右边界时会出错因为旋转后可能超出边界但代码没有做边界修正。另一个例子是贪吃蛇快速连续按相反方向键会导致蛇直接掉头撞到自己因为代码没有做禁止反向的判断。这些问题的修复都不难但需要你实际玩一遍才能发现。所以我的建议是每个游戏生成后至少玩两分钟把所有按键都试一遍特别是边界情况。4.4 代码截断批量生成最隐蔽的坑这个问题值得单独说。批量生成时如果模型输出较长有可能在达到最大token限制时被截断。截断的代码往往看起来差不多完整因为HTML结构可能闭合了但JavaScript逻辑只写了一半。我遇到过一个游戏HTML和CSS都完整JavaScript写到了游戏循环就断了后面的碰撞检测和计分逻辑全没了。打开浏览器能看到画面但游戏没法玩。这种问题在批量场景下特别隐蔽因为你不一定有时间逐个打开测试。我的解决方案是在落盘模块里加了一个简单的完整性检查统计function关键字出现次数、检查是否有明显的未闭合括号、检查文件末尾是否是/html。这三个检查能过滤掉大部分截断情况。对于通过检查但仍有问题的就靠索引页的批量预览来发现。5. 从七十二个产物里做质量筛选的实操方法5.1 先做机器可判定的初筛七十二个游戏不可能每个都仔细看所以第一步是用脚本做初筛。我写了几个检查项文件大小是否在合理范围太小可能是空文件太大可能是模型跑偏了、是否包含canvas或游戏循环相关关键字、是否有语法错误用Node.js的--check参数快速验证JavaScript部分。这一步能过滤掉大约百分之十的明显问题产物。剩下的百分之九十进入下一轮。5.2 用索引页做批量目视检查初筛之后我生成了一个索引页把所有游戏用iframe嵌入每个iframe给一个固定尺寸。打开这个页面七十二个游戏同时加载哪个白屏、哪个报错、哪个画面明显不对一眼就能看出来。这个方法效率极高。我花了大概二十分钟就把七十二个游戏过了一遍标记出十几个有问题的。有问题的里面又分完全跑不起来和能跑但行为异常两类前者优先修后者看时间。5.3 人工试玩只针对高价值游戏全部试玩不现实也没必要。我的策略是从七十二个里挑出二十个左右有代表性的游戏做深度试玩包括所有物理类、所有状态复杂的、以及随机抽样的简单游戏。这二十个试玩下来基本能摸清这批产物的整体质量水平。试玩的时候我会记录具体问题比如贪吃蛇反向按键导致自杀、打砖块高速穿墙、俄罗斯方块旋转越界。这些记录后来成了我修bug的清单也成了这篇文章的素材。5.4 修复策略能自动修的自动修不能的标记出来对于格式类问题比如多余的代码块标记、文件头尾有多余文字我写了脚本自动修。对于逻辑类问题我分两种处理简单的比如加一个边界判断手动改复杂的比如重写碰撞检测就标记为已知问题在README里说明。这里有个取舍不是所有bug都值得修。七十二个游戏里有五个我判断修复成本高于价值就直接标记了。开源项目里诚实地标注已知问题比假装完美更有价值。6. 开源这批产物时我做的几件事6.1 目录结构要让人一眼看懂开源项目的目录结构直接影响别人的第一印象。我的结构是这样的根目录放README和索引页games/目录下每个游戏一个文件夹文件夹名用英文slug里面放index.html和可选的README.md。这种结构的好处是别人clone下来直接打开根目录的index.html就能浏览全部游戏想找某个特定游戏也能通过文件夹名快速定位。README里我写了三部分项目简介一句话说清这是什么、如何运行其实就是打开HTML文件、已知问题列表。已知问题列表我列了五个都是修复成本较高的写清楚反而显得专业。6.2 给每个游戏加一句玩法说明索引页里每个游戏下面我加了一行说明写清楚操作方式和核心玩法。比如贪吃蛇方向键控制吃食物变长撞墙结束。这一行字看起来不起眼但能大幅降低别人的理解成本。没有这行字别人得打开游戏自己摸索有了这行字扫一眼就知道要不要点进去。6.3 开源协议的选择这批产物我选了MIT协议。原因很简单这些代码主要是模型生成的我做的事情是配置、筛选和修复独创性有限。用MIT协议最宽松别人想怎么用都行符合开源社区对这类工具产物的预期。如果你也要开源类似的批量生成产物我的建议是选宽松协议。因为这类项目的价值在于数量和多样性不在于单个游戏的代码质量。宽松协议能让更多人受益也符合开源精神。7. 关于token消耗和成本的实际账7.1 五亿token实际用了多少七十二个游戏跑完加上中间的重试和调试我实际消耗的token大概在一亿两千万左右。平均每个游戏消耗约一百六十万token这个数字比预想的高主要原因是有些游戏生成失败后重试了多次以及部分复杂游戏的输出确实很长。剩下的三亿多token我没浪费后来用来做了一些代码解释和文档生成的任务。但就这批游戏而言一亿两千万的消耗对应七十二个可运行的产物性价比是相当高的。7.2 如果按付费算这笔账假设按标准API价格来算一亿两千万token的成本大概在几十到一百多块之间具体取决于模型和计费方式。七十二个游戏平均每个游戏成本一两块钱。这个成本对比人工写代码的时间成本优势非常明显。一个熟练开发者写一个这样的小游戏怎么也得一两个小时按人力成本算远不止一两块钱。当然这里有个前提模型生成的代码需要人工筛选和修复。如果算上这部分时间单个游戏的综合成本会上升。但即便如此批量生成的效率优势依然存在因为筛选和修复可以批量化、流程化而从头写代码不行。7.3 token额度使用的几个经验第一批量任务要留出重试余量。我原本以为五亿token用不完实际跑下来发现重试消耗比预想的多所以额度规划要留百分之三十左右的buffer。第二不同模型的token消耗差异很大。glm-5.3-flash在代码生成上比较话少输出直接是代码没有多余解释这能省不少token。如果你用的模型喜欢加解释消耗会明显上升。第三批量任务建议分批跑不要一次性全发。分批跑的好处是能及时发现系统性问题比如提示词有歧义导致某类游戏普遍失败及时调整避免浪费额度。8. 这套流水线还能怎么扩展8.1 扩展到其他类型的代码生成这套流水线的核心逻辑是结构化配置加批量API调用加自动落盘这个逻辑不限于游戏。你可以把配置换成数据处理脚本、爬虫模板、API接口示例同样能批量生成。我后来用同样的思路生成了一批Python数据处理脚本效果也不错。关键是要找到那种有明确输入输出、单个产物规模可控、质量可自动判定的场景。游戏符合这三个条件所以适合。如果你的场景里产物质量很难自动判定那批量生成的价值就会打折扣。8.2 加入自动测试环节目前我的流水线里质量检查还是半自动的。下一步可以加入自动测试用无头浏览器加载每个游戏模拟按键操作检查是否有JavaScript报错、画面是否正常渲染。这样能把初筛的自动化程度再提高一截。不过自动测试也有局限它能发现跑不起来的问题但发现不了能跑但不好玩的问题。后者还是得靠人工。所以自动测试是辅助不是替代。8.3 用模型做代码审查还有一个有意思的扩展方向用模型来审查模型生成的代码。具体做法是把生成的代码再发给模型让它找出潜在的bug和改进点。这个方法我试了几个游戏确实能发现一些我漏掉的问题比如未处理的边界情况、可以优化的循环逻辑。但要注意模型审查也有误报。它有时候会把正确的代码标记为有问题或者提出一些不切实际的改进建议。所以模型审查的结果只能作为参考最终判断还是得靠人。9. 给想复现这套流程的人几条实在建议如果你手里也有一批token额度想复现类似的批量生成项目我有几条从这次实践中总结的建议。第一条先跑通一个再批量。不要一上来就写七十二个的配置先用一个游戏把整条流水线跑通确认API调用、格式解析、落盘、索引页都没问题再扩展到批量。我这次就是先跑通了贪吃蛇才敢批量铺开。第二条提示词里的格式约束要放在最前面措辞要强硬。模型对开头的内容更敏感把最重要的约束放前面执行率明显更高。第三条并发数从低往高试。先设三跑通了再往上加。不要一上来就设十出了问题你分不清是并发太高还是别的原因。第四条落盘模块一定要做完整性检查。截断是批量生成最隐蔽的坑不做检查你会在一堆看起来完整的文件里浪费时间。第五条质量筛选要分层。机器初筛、目视批量检查、人工深度试玩三层下来既能保证覆盖率又不会累死自己。第六条开源时诚实标注已知问题。不要假装完美把没修的问题写清楚反而能建立信任。别人看到你连已知问题都列出来了会觉得这个项目靠谱。最后说一句关于token额度的心态。额度多的时候容易贪心想什么都做。但批量生成的价值不在于生成了多少而在于有多少能真正用起来。七十二个游戏里我判断真正质量过关、可以直接拿去用的大概有五十个左右。这个比例我已经很满意了。与其追求数量上的好看不如把筛选和修复做扎实让每个开源出去的产物都对得起别人的时间。
