作为一个常年泡在 AtomGit 上的开发者最近看到平台首页挂出一个挺有意思的活动帖让 GLM-5 和 Qwen3.5 用同一句中文提示词生成一个可玩的游戏然后让社区投票。我第一反应是——这不就是变相晒提示词功底吗但转念一想模型能不能把一句含糊的话变成能跑的代码确实是检验自然语言理解能力的硬指标。我决定花几个晚上把手头的一个小游戏需求分别丢给两个模型做几组对比。这篇就把完整过程、跑出来的结果和我的真实感受记录下来给同样想玩“一句话生成游戏”的朋友做个参考。这次 PK 我特意选了一个足够典型但又不复杂的题目接球小游戏。规则简单但涉及 Canvas 绘图、碰撞检测、鼠标事件、计分逻辑够模型发挥也容易暴露问题。下面我会按时间线写清楚提示词是怎么设计的两个模型首轮生成了什么我实测过程中踩到哪些坑以及最终怎么评价它们。1. 一句话生成游戏表面是挑战模型实际是考验提示词1.1 为什么选“接球小游戏”当考题选游戏题目时我纠结过一阵。太复杂的比如 3D 射击一句话提示词做出来大概率是空壳太简单的比如猜数字纯文本逻辑又体现不出“生成游戏”的视觉交互能力。最后定了 HTML Canvas 的接球游戏。理由有三点技术栈足够标准任何模型都接触过大量同类代码不容易出现“没学过所以乱写”的情况。功能粒度适中一个游戏循环至少要包含小球运动、挡板跟随鼠标、碰撞检测、分数重置这四件事缺一个游戏就玩不起来。反馈直观打开浏览器就能跑不需要安装依赖也不受平台限制。对一个自然语言生成代码的模型来说这个题目好就像让一个新手厨师做番茄炒蛋材料常见步骤清晰但火候、调味、出锅时机全是细节做得好不好立刻能吃出来。1.2 我定的 PK 规则同提示词、同环境、三轮迭代为了尽量公平我提前定了规矩两个模型使用完全相同的初始提示词一字不差。运行环境统一为桌面端 Chrome 浏览器直接打开本地 HTML 文件。评测分为首轮生成、实测反馈、两轮追加迭代三个环节。首轮看“从零到能跑”的效率后续看模型修复 bug 和改需求的能力。追加迭代也很重要因为现实中没人会满足于第一版代码。真正拉开差距的往往是模型能不能听懂“小球速度太快”“挡板应该限制在画布内”“分数要显示在左上角”这类反馈然后准确改到对应的变量和逻辑上。实测环节我给自己定了一个主观但可复现的打分标准每局游戏主动玩五次统计小球是否会在非预期位置消失、挡板是否跟手、分数刷新是否即时、控制台是否有报错。总共从 0 到 10 分5 分起步出现严重影响体验的问题就扣分。2. 赛前我把提示词压缩到一句话但里面藏了四个必要约束2.1 提示词逐字拆解技术栈、玩法、交互、反馈很多朋友以为“一句话生成游戏”就是把需求说个大概越简短越好。其实不然模型对“一句话”的理解是这句话里每个词都可能隐含代码层面的约束。我最终使用的初始提示词是这样写的用 HTML Canvas 实现一个接球小游戏小球从上方随机下落鼠标控制底部挡板左右移动接住小球得一分掉落后分数清零界面保持简洁并显示实时分数。拆开看信息密度很高“HTML Canvas”限定了实现技术栈模型不会绕到 DOM 动画或 WebGL。“从上方随机下落”要求生成小球初始位置和下落方向的随机逻辑。“鼠标控制底部挡板”要求监听 mousemove 事件而不是键盘。“接住小球得一分掉落后分数清零”定义了两种状态转移。“界面保持简洁并显示实时分数”把绘图范围和 UI 要求都圈死了。只追加一个约束不难但要在不超出一句话的条件下同时塞进这些需求还要避免歧义是这次 PK 最有意思的部分。有些说法看着清楚比如“分数清零”模型可能理解成“游戏结束重新计分”也可能理解成“分数归零但游戏继续”后续生成结果会完全不同。我这里用“掉落后分数清零”配合“实时分数”就把行为约束到位了。2.2 运行环境与评测方式浏览器直接跑手测五把我没有选择 Node.js 或任何构建工具原因很简单生成的是单文件 HTML浏览器是最直接的运行容器省去安装依赖可能带来的意外错误。这也更贴近大多数想快速体验“一句话生成游戏”的人的需求。具体操作步骤是把模型输出的完整 HTML 保存成 index.html。用 Chrome 打开按 F12 打开控制台看有没有红色报错。手动玩五轮记录每次游戏时长、得分变化、画面是否有异常残留。每轮之间不修改任何代码保证首轮评价只针对模型原始输出。这套方法看起来朴素但非常有效。因为模型生成的代码即使语法没问题也可能在运行时出现逻辑 bug比如小球位置更新了但画布没有清屏、挡板移动没有限制导致鼠标拖出窗口后消失等这些只有实实在在玩过才能发现。2.3 关于 PK 公平性的设置禁止额外解释只给一句话很多人让模型写游戏时会习惯性补一句“请用简单清晰的方式实现”或者“注意性能优化”。这些其实都是额外引导会影响对比结果。我这次特意把提示词限定为必须“一句话”并且不允许在提示词里出现“逐步思考”“请解释代码”等附加指令。为什么要这样因为模型的输出策略会跟随提示词的详细程度变化如果我给 A 模型多一句“注意细节”给 B 模型少一句最终差距就说不清是模型能力还是提示词导致的。只有两边吃完全一样的料比较生出来的菜才公平。当然迭代阶段是可以自由对话的。我的规则是第一轮用相同提示词第一轮之后的对话允许针对各自的生成结果提出不同修改要求这更符合实际开发习惯也可以观察两个模型在“回应反馈”上的差异。3. GLM-5 首轮输出能运行的 MVP但玩法反馈太单薄3.1 代码结构和首版效果GLM-5 的完整输出是单个 HTML 文件包含约 110 行代码内联 CSS 和 JavaScript 都放在同一个文件里。核心逻辑非常简单const canvas document.getElementById(game); const ctx canvas.getContext(2d); let score 0; let ball { x: 200, y: 0, r: 10, sx: 2, sy: 3 }; let paddle { x: 150, w: 100 }; function draw() { ctx.clearRect(0, 0, canvas.width, canvas.height); // 省略球、挡板、分数的绘制代码 ball.x ball.sx; ball.y ball.sy; if (ball.y ball.r paddle.y) { if (ball.x paddle.x ball.x paddle.x paddle.w) { score; ball.sy -ball.sy; } else { score 0; ball.y 0; ball.x Math.random() * canvas.width; } } requestAnimationFrame(draw); }只看这段抽象出来的代码逻辑是通的。清屏、画球、画挡板、碰撞判断、计分、重置都有。实测打开页面游戏确实能跑小球会从顶部下落鼠标移动挡板也能接住分数归零后小球会重新回到顶部。但玩起来有一个非常明显的感受手感单薄。小球永远是同一个颜色、同一个速度挡板宽度固定得分后没有任何视觉反馈。分数清零时也只是数字变成 0没有提示动画。整个游戏更像是一个验证“需求是否被满足”的最小演示而不是一个“能让人想玩第二把”的作品。3.2 我复现时遇到的三个小问题第一次实测时我把鼠标快速移到窗口最右侧挡板跟着到了边缘然后继续往右移动挡板有一小段会被推出画布外导致边缘接球时出现盲区。第二小球初始下落方向虽然说是“随机”但实际上每次重置后的横向速度 sx 都是固定值 2只有初始 x 坐标是随机的下落轨迹看起来比较呆板。第三当小球和挡板碰撞时判断条件是ball.x paddle.x ball.x paddle.x paddle.w只判断球心是否落在挡板范围内如果小球移动步长比较大就可能出现“穿模”——球心前一刻还在挡板上方下一帧已经越过挡板进入了下方区域导致看起来像穿透。这三个问题里第一个和第三个是直接玩出来的第二个是读完代码后发现的。模型生成的逻辑在理想帧率下没问题但真实浏览器处理高 DPI 或快速鼠标移动时暴露出的还是物理细节考虑不足。3.3 第二轮追加指令后的变化我尝试给了一个追加指令“挡板不能超出画布边缘小球每次重置位置时让横向速度随机碰撞点靠近挡板边缘时增加反弹角度变化。”GLM-5 的修改很直接在挡板 x 坐标更新处加了Math.max(0, Math.min(canvas.width - paddle.w, newX))给小球重置增加了一个随机速度生成ball.sx (Math.random() 0.5 ? 2 : -2) * (0.8 Math.random())。反弹角度部分则是在碰撞判断里根据碰撞点偏移计算了一个新的横向速度增量。改动完成后重新运行手感比以前好不少边缘盲区消失了小球下落轨迹也不那么单调。但反弹角度那部分实现得有点粗暴它直接修改了 sx 值没有保留动量守恒的感觉几次反弹后小球会越弹越快。这轮迭代能看出 GLM-5 更擅长做“明确指向的改动”而不是主动重构整套物理模型。4. Qwen3.5 首轮输出细节更完整却有一个隐蔽 bug4.1 代码结构和首版效果Qwen3.5 首轮输出约 150 行代码结构和 GLM-5 类似但多了一层模块化划分初始化函数、更新函数、绘制函数、事件绑定函数分得很清楚。最明显的是它在顶部直接定义了一个常量对象把所有可调参数集中管理const CONFIG { canvasWidth: 400, canvasHeight: 600, ballRadius: 8, paddleWidth: 90, paddleHeight: 12, baseSpeed: 3, resetScore: true };这种写法对代码维护非常友好。我后续想调整球速不需要到逻辑代码里找魔法数字改一行配置就行。首版运行效果也比 GLM-5 完整分数实时显示在画布左上角得分时挡板会短暂闪烁一下小球掉落到地面时分数归零并且出现一个“Game Restart”的文本提示点击任意位置继续。玩法反馈明显更丰富至少你清楚当前处在什么状态。4.2 隐藏 bug 的定位过程第一轮愉快玩了两分钟后我发现一个非常隐蔽的 bug挡板最左侧的位置比画布左边界要窄大约 4 个像素但不是每次都能触发。我把窗口缩放了几次才发现原因。Qwen3.5 在事件监听里用的是event.clientX然后直接把它赋值给挡板的x没有先减去画布边界偏移window.addEventListener(mousemove, (e) { paddle.x e.clientX; });当画布居中且页面有默认 margin 时鼠标的真实绘图坐标和clientX之间存在一个偏移量。这个偏移就是挡板比鼠标偏右的根源。我首次打开时是最大化窗口画布正好贴在页面左边缘所以没暴露。后来窗口变小画布跟着居中偏移值变大bug 就出来了。这个 bug 如果能提前用canvas.getBoundingClientRect()把坐标换算成相对坐标就不会发生。模型没有主动做这一步原因是生成的 demo 里默认画布位置固定。这提醒我模型生成的交互代码最好在非标准页面布局下多测几轮。4.3 两次迭代后才达到干净状态我针对这个 bug 给 Qwen3.5 追加了指令“鼠标坐标应该基于 canvas 的实际位置计算不要直接用 clientX另外挡板移动要限制在画布内部。”第一轮修改后它把clientX改成了e.clientX - rect.left并且加了Math.min(Math.max(...,0), canvas.width - paddle.w)。但让我意外的是这轮修改引入了一个新问题当鼠标在页面右侧快速移动时挡板的移动范围虽然正确但挡板响应出现了一小段跳跃怀疑是 rect 缓存时机不对。我继续追问“在窗口尺寸变化时也要重新获取 canvas 的 bounding rect”Qwen3.5 在 resize 事件里重新计算了 rect并再跑一轮才彻底干净。Qwen3.5 的迭代过程比 GLM-5 更像真实结对编程它会保留原有模块结构在函数内部做局部修改很少破坏整体设计。代价是修改点可能不止一处需要检查更仔细。5. 横向对比GLM-5 和 Qwen3.5 的差异比我想象的更明显5.1 六项维度的评分表几轮实测下来我按照自己的反馈做了一个六项指标的打分10 分制每个指标都是基于第三轮迭代后的最终状态对比维度GLM-5Qwen3.5首轮运行成功率98代码可读性79逻辑细节完整性69交互体验反馈68修改需求执行度79底层 bug 暴露率46首轮运行成功率 GLM-5 更高因为它的代码更短依赖路径更少几乎不会有初始化时序问题。Qwen3.5 第一版就成功运行没有大问题但那个隐藏的clientX偏移 bug 让我给它扣了分。逻辑细节完整性和代码可读性 Qwen3.5 优势明显它考虑到了配置管理、函数分层、视觉反馈GLM-5 更偏向“怎么简单怎么来”。这里要说明bug 暴露率低对开发者来说不完全是优点。GLM-5 隐藏 bug 更少但也说明它生成的代码复杂度有限。Qwen3.5 因为功能丰富出错的概率自然更高后续修复能力和代码组织能力把它拉回了很多分。5.2 从代码里读出的模型风格差异用同样一句提示词可以看出两个模型的“表达偏好”完全不同。GLM-5 倾向于生成满足约束的最短实现。它理解了你不要什么但不会主动做一些你没要求的事。它的代码读起来像是一个熟悉问题的人快速写出的原型变量命名简短函数边界模糊改起来很快但扩展时容易牵一发动全身。Qwen3.5 倾向于生成“有先验工程习惯”的实现。它会自动引入 CONFIG 常量、明确区分 update 和 draw 职责、添加简单的状态反馈。这些不是提示词要求的但它判断这些是“一个可维护代码”的基本元素就塞进来了。对刚接触编程的人来说这种风格更好理解对追求快速验证的人来说可能显得有点啰嗦。这也可以解释为什么第二轮追加“挡板不能超出画布”时GLM-5 只改了一行几乎零副作用Qwen3.5 则需要从事件绑定和 resize 逻辑里一起检查修改范围更大但更系统。5.3 这次 PK 给我的通用经验体验完一轮后我最深的感受是给模型下指令不要迷信“模型越强生成越完美”这个结论。生成代码能不能用很大程度上取决于你愿不愿意把它当作新同事来“带”。实际开发中大家不会只发一次指导肯定会根据运行结果一条一条反馈。这次对比里两个模型的差距在三轮迭代后迅速缩小因为追加指令能帮模型补齐缺失的信息。真正决定项目下限的是你这个“需求方”能不能清晰描述问题决定上限的才是模型自己的工程化能力。6. 如果你也想玩“一句话生成游戏”这几个坑请提前绕开6.1 一次生成完美游戏基本不存在无论是 GLM-5 还是 Qwen3.5第一轮生成的结果都只能说“能跑”离“能让人顺手玩下去”还有距离。这不意外因为一句话里的信息再密集也无法覆盖你脑海里的全部想法。比如“手感”这种主观体验模型感知不到它只能从行为规则里做推断。所以建议降低预期把第一轮当成草稿。如果目标是快速做个 Demo 验证想法首轮结果已经很香如果想发布到社区或者给朋友玩至少要准备两到三轮迭代。6.2 提示词模板可以直接抄我这次用下来觉得“技术栈 核心玩法 交互方式 关键反馈”这个结构很稳以后生成游戏类项目我会继续沿用。一个可以直接套用的中文模板是这样用 {技术栈} 实现一个 {游戏类型}{核心对象} 会{行为}玩家通过 {交互方式} 控制 {控制对象}当 {失败条件} 发生时 {处理方式}每 {成功条件} 增加分数界面保持 {风格要求}并用文字显示 {实时信息}。用这个模板写出来的提示词本质上是把需求拆成模型生成代码时最容易对齐的原子项。哪怕你临时想生成一个别的类型游戏只要替换大括号里的内容就行。6.3 实测环境才是唯一标准代码能生成出来不一定说明没问题。这次 Qwen3.5 暴露的坐标偏移 bug就是只有在真实浏览器窗口缩放时才会出现。类似的情况还有某些模型生成的代码在电脑上没问题一到手机端布局就崩点击事件用鼠标没问题一换触摸屏就没反应高分屏下 Canvas 绘制模糊等等。我最后强烈建议在多个窗口尺寸、缩放比例下各跑一遍至少验证一次“窗口从窄变宽”和“从全屏变半屏”的过程。很多交互类 bug 都藏在这种状态切换里。6.4 把模型当结对编程伙伴而不是许愿机“一句话生成游戏”真正的价值不是让你从零变成游戏开发者而是把从“想法”到“可运行原型”的成本降到一个极低的水平。这个过程中你的角色更像产品经理和技术复核员的合体负责说清需求、运行验证、发现 bug、给出修改建议。所以不要太在意两个模型谁更厉害。对我来说GLM-5 是那种“你说一步他做一步”的快手搭档Qwen3.5 是“自带工程洁癖”的细活型队友。真到实际项目里反过来用他们各自的优点才是正解快速验证需求用前者沉淀代码库用后者。最后分享一个我自己的使用习惯生成游戏代码后我会把首轮提示词和所有迭代对话一起放进项目的 README 里。这样以后翻到这个项目能完整看到当时哪些需求是模型一次就懂的哪些需求是我反复纠正才实现的。长此以往你对自己写提示词的短板和模型能力的边界会比任何横向评测表都清楚。