一次偶然的机会我把四款大模型拉进了同一个测试房里K3、Fable5、GLM5.2、Hy3。测试项目不是写八股文不是做算法题而是让它们从零开始帮我做一个可运行的页游小项目。乍一看这个选题有点“轻”。页游又不涉及复杂后端也没有高并发能测出什么但真正跑完一轮之后我的判断变了页游是一个非常合适的“大模型代码能力试金石”。它够小适合单次生成它又够完整一个回合制战斗就得覆盖状态管理、事件交互、界面刷新和简单AI。更关键的是它特别容易反复改需求——战斗逻辑调一版、存档方式换一种、敌人AI再加强一轮。这种“小规模、高频率、多变化”的开发节奏和真实项目里日常写代码的状态非常接近。这篇文章不打算给你一个“XX模型最强”的结论。我真正想分享的是拿页游做横评时四个模型各自适合什么开发目标以及在它们背后我发现的大模型辅助编程真正值钱的地方在哪里。1. 为什么我拿“页游”来当大模型的测试题1.1 常规编程题的两个局限先说说我为什么不直接用网上常见的大模型评测题。这些题目里LeetCode 风格的中等难度算法题是主流其次是“写一个贪吃蛇”“写一个待办事项”这类经典需求。它们确实能测出模型的基础编码能力但有两个明显局限。第一个局限是“语料过拟合”。像贪吃蛇、扫雷、待办清单这类题目在大模型训练语料里出现的次数可能达到几十万次模型生成出来的代码已经接近“背诵”而非“理解”。你看到的结果往往非常流畅但它并不能反映模型面对一个陌生需求时如何拆解、如何取舍、如何写出好用的代码。第二个局限是“离真实开发太远”。算法题考的是单点逻辑待办事项考的是CRUD但实际开发中真正消耗时间的是另外几件事把一个模糊需求逐步澄清把一个模块嵌入到已有代码里在报错之后通过调试修复问题以及在不破坏现有功能的前提下调整行为。这些能力很难用一道题测出来。1.2 页游场景的独特价值页游正好补上了这两块短板。首先页游是一个完整的小型产品但它不需要复杂的工程基建。一个回合制页游用纯 HTML、CSS、JavaScript 就能跑起来没有数据库依赖也不需要构建工具。你需要的所有逻辑都可以塞进几个文件里这对大模型生成非常友好——它不需要跨几十个文件协作单次生成就能给出一个能跑的东西。其次页游对“状态管理”和“逻辑分支”的要求不低。玩家角色和敌人之间互相攻击血量变化会触发不同的技能效果自动战斗时要排队执行动作存档时要序列化和恢复整个战斗状态。这些逻辑会逼着模型去处理变量生命周期、边界条件和事件顺序而这些恰恰是工程代码里最容易出错的部分。第三页游非常适合连续迭代测试。你可以让模型先做出一个基础战斗然后追加背包系统再要求加入自动战斗最后加上本地存档。每轮需求之间都存在“如何在已有代码上增量修改”的问题。这比重新生成一个新文件难得多也会更真实地暴露模型的上下文理解能力。所以我设计的页游横评本质上不是一个“谁生成的游戏更好玩”的比赛而是“谁能在这个渐进式开发过程中保持代码质量不塌方并且愿意主动补齐必要细节比如空状态、边界判断、进度持久化”。1.3 一个补充判断为什么不用纯框架项目也有朋友问我为什么不干脆让它们写一个 React 或 Vue 项目这样不是更接近生产环境吗我的回答是框架项目会引入太多干扰变量。每个模型对某个框架版本的认知不一样生成的依赖配置可能也不同。如果 A 模型生成的 React 版本和你本机环境不一致你花在修环境上的时间会比看代码质量的时间还多。相比之下原生三件套HTML/CSS/JS零依赖、零构建跑不起来就是代码本身有问题能直接反映模型的逻辑能力。等你用原生项目验证出模型的能力分布之后再把它放进你熟悉的框架里做专项测试会更有意义。2. 这次横评的测试环境与方法设计2.1 四款模型的接入方式先说接入方式。这次横评里K3 和 GLM5.2 我通过官方 API 接入Fable5 和 Hy3 在测试时的接入方式不太一样一个通过在线对话界面一个通过本地部署的接口调用。这种不一致确实会影响响应速度和交互方式但为了保证任务一致性我在提问时统一采用了同一套提示词模板只在必要的时候追加报错信息。需要说明的是这四款模型的版本、参数量、上下文长度、架构细节不同渠道描述会有差异。比如热搜词里有人提到“K3 细颗粒度 MoE”“K3 2.8T 模型核心原理”这类说法但在我们的测试环境里模型版本是动态更新的很难锁定一个精确参数来复现。所以我更建议大家把这里的结论理解为“在某个时间节点、某次测试环境下的表现”而不是对某个模型版本的永久定论。如果你想自己复现这套测试可以按下面的通用配置准备运行方式优先使用 API 调用保证可以批量、反复测试不具备 API 条件的模型使用网页端时要把浏览器控制台里的报错一并截图记录。输出目标全部要求给出可直接保存为.html的单文件代码不允许拆成多个文件后再组装。上下文策略每个新任务都在原有对话上继续追问模拟真实开发中的连续对话。记录方式每一轮都记录模型是“一次生成通过”还是“经过修复后通过”以及修复过程中报错信息是否被有效利用。2.2 五连测试任务我给四款模型设计了一个渐进式的任务序列严格按顺序执行不跳题回合制战斗核心生成一个单文件页游。玩家和敌人分别有生命值、攻击力按回合轮流攻击显示当前血量并判断胜负。加入技能与冷却给玩家增加两个技能一个高伤害但冷却3回合一个低伤害但可以回血。界面需要显示技能冷却状态。加入背包系统战斗胜利后随机掉落物品物品进入背包。背包界面能以弹窗形式打开并且可以查看物品描述。自动战斗与收益加入“自动战斗”模式玩家可以连续挑战5个敌人战斗过程自动进行每场胜利后自动累积掉落。本地存档使用 localStorage 保存玩家等级、背包物品、当前战斗进度刷新页面后可以恢复。这个序列看起来简单但每一轮都涉及“在上一轮生成的代码基础上继续改”的复杂操作。如果模型没有真正理解上一轮生成的数据结构第三轮的背包系统很可能会在第二轮的战斗代码里“翻车”。2.3 四个评分维度与一个体验项我在横评时没有只盯“能不能跑”而是按四个维度加权打分维度权重关注点需求理解20%是否准确识别用户的核心诉求有没有遗漏关键规则代码可维护性30%变量命名、函数拆分、状态管理方式后续是否容易扩展调试成功率30%给报错后能否定位问题修复后是否引入新问题迭代稳定性20%增量修改时是否破坏已有功能逻辑是否保持前后一致另外记一个体验项响应速度和输出篇幅。响应快但代码质量差以及代码好但输出特别慢这两种模型适合的场景完全不同。后面选型的时候会用到。注意横评最忌讳“一道题定生死”。同一个模型用不同提示词写同一个游戏结果差异可能比不同模型之间的差异还大。想得到可信结论至少要让每个模型完整跑完整个任务链并且中间不要因为某一步不满意就立刻重开对话。3. 四款模型的实际表现三个最值得关注的观察这一章不会给“模型A得分9.2模型B得分8.7”这种明细表。原因很简单单次横评的误差太大一次生成的结果受采样随机性影响很明显。但四款模型在任务链中暴露出的行为差异确实是稳定的值得展开分析。3.1 第一次生成K3 和 GLM5.2 的拆解习惯不一样第一轮“回合制战斗”是最基础的题四款模型都能跑通但代码结构差异很大。K3 在第一次生成时就主动用了一个gameState对象来管理全局状态而不是让玩家生命值、敌人生命值、当前回合数各自散落在全局变量里。这个细节在第二轮加入技能冷却时立刻产生了收益技能冷却直接挂到gameState.skills上更新逻辑很自然。在四款模型里K3 对“状态集中管理”的意识是最明显的它写出来的代码更像一个有经验的前端开发者给出的结构。GLM5.2 的第一次生成同样不错但它更偏向把逻辑写在事件处理函数内部代码整体更短可读性也不错。问题出在第二轮加入技能冷却时它需要修改战斗流程由于第一轮的状态分散在多个函数里这次修改的改动面明显更大。给我的感觉是GLM5.2 很擅长“快速给出一个能跑的结果”如果目标是原型验证这种风格是有优势的。Fable5 和 Hy3 在第一轮的表现相对平庸。它们能生成正确运行的代码但在结构设计上没有明显亮点甚至偶尔会把setTimeout和requestAnimationFrame混用来控制战斗节奏造成战斗动画无法预测。这类问题不算致命但会让后续迭代变得痛苦。3.2 调试环节谁在真正“读懂”报错第三轮背包系统开始模型开始踩坑。最常见的问题是弹窗中的“关闭”按钮没有绑定事件打开后无法关闭以及背包数据与战斗掉落没有关联打十场也看不到掉落物。我把报错信息或现象发给模型让它自己修复。这个过程最能看出模型的差异。K3 的修复思路比较稳。它不会只修你指出的那一行还会顺手检查同一区域的边界条件。比如在修复背包关闭按钮时它额外补了一个event.stopPropagation()因为弹窗是在战斗界面里渲染的点击弹窗内部时会冒泡到战斗界面的点击事件导致战斗流程被意外触发。这种“关联修复”的能力确实是长期写前端的人才会养成的习惯。GLM5.2 在修复时更直接它会很快给出新的完整文件但有时会“修好了背包破坏了战斗”。典型表现是它在修复弹窗时顺手把原本战斗区域的结构也调整了导致攻击按钮失效。这说明模型对“改A不碰B”的局部修改控制力还有提升空间。Hy3 在调试环节的表现比较依赖提示词。如果你明确告诉它“只需要修改renderInventory函数其他部分保持不变”它通常能完成任务但如果只给一句“背包打不开”它会返回一整版重构后的代码反而增加了回归风险。Fable5 在调试中有一个特点比较明显它能很好地处理“语法错误”和“运行时报错”逻辑错误则需要你多给一些提示。比如血量降到负数后界面显示异常它容易把问题归结为样式问题而不是攻击溢出的边界判断问题。3.3 增量迭代这是整场横评中最拉差距的环节到了第四轮和第五轮四款模型的差距开始真正拉开。K3 在加入自动战斗和本地存档时保持了很好的“温和演进”风格。它会沿用之前已经定义的GameState和Inventory结构只在上面增加新方法。到第五轮结束整个页面只有一个saveGame方法负责把状态写入 localStorage而且存档结构里预留了一个version字段。坦白讲这个version字段不是题目要求的但它是一个清晰的工程意识对后续存档迁移非常有价值。GLM5.2 在迭代中表现中规中矩它不会主动重构但也不会引入特别离谱的新设计。唯一的问题是它有时会在新增代码中重复使用一个已经存在的函数名造成覆盖。这提醒我们当上下文里的代码越来越长时模型是否能记住“哪些标识符已经被占用”是一个真实的工程问题。Fable5 和 Hy3 在第四轮开始出现比较明显的上下文遗忘。特别是 Hy3到了第五轮要求加存档时它读取的是第四轮生成的变量名却写了一段基于第一轮代码结构的读取逻辑导致保存和读取的数据结构对不上。这种错误在模型对话里不算新鲜但在真实项目里会很致命——因为你可能根本注意不到它读的是旧版本的字段。3.4 我的体验观察总结一下这次横评给我的直观感受K3 更擅长“长跑型任务”如果你会连续让模型做多轮迭代它在第五轮时的代码结构仍然能维持在一个较好的水平。GLM5.2 更擅长“短跑型任务”如果你只要一个能跑的Demo它的输出效率和代码完整度都很不错适合快速验证想法。Fable5 属于“需要明确边界”的类型它适合在限定范围内工作前提是你把需求拆分得足够细。Hy3 更适合做探索性验证比如“先帮我试一个新玩法”但离稳定承接整个项目还有距离。需要再次说明的是这只是我们在规定任务链下的表现观察。不同环境、不同版本、不同提示词下排序完全可能变化。我不希望你把这当成“购买指南”更希望你把这里的维度当成自己评估模型时的参考。场景优先考虑原因连续多轮迭代开发K3状态管理稳定增量修改时回归风险低一次性快速原型GLM5.2输出完整效率高适合短任务小范围专项任务Fable5需求边界清晰时能稳定完成玩法探索、脑暴验证Hy3试错成本低适合快速验证想法4. 从不同开发目标出发怎么选这四款模型4.1 如果你刚学前端只是想练手选 GLM5.2 或 K3 都可以。区别在于如果你希望模型多给你一些解释多回答“为什么这么写”GLM5.2 的注释会更友好一些如果你希望看到一个相对完整的工程结构K3 生成的代码更接近你以后在团队里会看到的写法。不过更建议的做法是不要只让模型给你完整代码。你可以在模型生成后刻意问一句“战斗流程中switch和if-else的取舍是什么”让它解释自己的设计。这个追问过程往往比看十遍代码更能帮你建立判断力。4.2 如果你已经在写业务代码想用大模型提升效率如果你日常写的是需求明确、模块边界清楚的代码我建议优先考虑接入速度快的模型。GLM5.2 在短任务上的响应效率和一次性通过率都不错可以帮你快速生成工具函数、页面组件、模拟数据等“短平快”代码。但也要提醒当你把一个模型生成的长代码直接贴进自己的项目之前一定要先读一遍。因为大模型生成代码时偶尔会默认引入一些它“熟悉”但你可能没有安装的依赖或者使用了一个和你项目里已有函数同名的自定义函数。这种问题在代码量小的时候很容易发现放在真实项目里就需要靠代码审查来兜底。4.3 如果你在做一个真实的上线项目这时候选模型的核心指标不是“谁写得好”而是“谁出错后更好修”。从这个角度看K3 会是我个人更愿意使用的选择。不是因为它的代码完美无缺而是因为它生成的结构更接近“可以维护”的状态——状态集中、函数职责清晰、命名规范。这意味着一旦出了问题你在局部的修复不需要牵动全局。另一个重要的经验是不要把任何模型当成“一次生成完整系统”的工具而是把它当成“帮我生成一个模块我来审核后接入”的协作者。4.4 如果团队预算有限只能免费渠道Fable5 和 Hy3 在免费渠道里可以作为补充工具使用。它们特别适合那些“不要求长期维护、只用来跑数据、做临时脚本”的小任务。比如写一个批量文件名转换脚本或者生成一份测试用的假数据它们完全能胜任。5. 横评之后我把“用大模型写页游”的流程固化成了五步横评结束后我并没有停留在“哪个模型更强”这个判断上。我更在意的是既然四款模型都能在多轮迭代里完成一个页游那普通开发者真正需要掌握的是什么答案是用一个稳定的流程来降低不确定性。我把自己在横评里实际使用的工作流提炼成了五个步骤现在写任何小游戏或者小型前端Demo都会用这套流程。5.1 第一步在代码之外先手写规则不要一上来就把需求丢给模型。先用自然语言把游戏规则写清楚包括玩家和敌人的属性、回合顺序、胜负条件、异常情况。这个“规则文件”不需要很正式写成自己看得懂的伪代码就行。这套做法的好处是当你把规则发给模型时它不再需要猜测你的意图。你不能指望模型替你决定“这个技能到底是消耗自己的血量还是回复血量”——这是产品决策不是技术决策。5.2 第二步把页面拆成“结构、样式、逻辑”三块哪怕是一个单文件页游我也建议在提示词里明确三类输出HTML 结构只定义页面元素不写样式和逻辑。CSS 样式负责布局、颜色、动效。JavaScript 逻辑只做事件绑定和状态更新不直接操作样式字符串。这样拆分之后后续迭代时你只需要让模型修改对应模块。特别是 JavaScript 逻辑只要状态管理做得清晰新增技能或物品时基本不需要改动 HTML。5.3 第三步先跑通最小闭环再加复杂度无论你多急着看到完整功能都要先让模型产出“一个能跑的最小版本”。在页游这个例子里最小版本就是“玩家和敌人各有一个攻击按钮点击后血量变化血量归零时显示胜负”。最小闭环跑通后再逐步叠加技能冷却、背包、自动战斗、存档。每一轮新增功能都要先确认前一轮功能没被破坏。这个步骤可能显得慢但它能最大程度避免“最后一轮报错不知从哪开始排查”的困境。5.4 第四步把报错信息原样回传并补充“当前环境”遇到代码跑不通时很多人的第一反应是重新让模型生成一次。我更建议把它当作一次调试机会。操作方式把浏览器控制台的报错信息完整复制给模型同时在提示词里补充你的运行环境信息比如“在 Chrome 126 下打开本地 HTML 文件点击攻击按钮后控制台报错Cannot read properties of undefined (reading hp)请定位问题并只修改 JavaScript 部分”。这样可以避免模型在不了解环境的情况下盲目重写。5.5 第五步每一次修改后提交一版“存档”这里的存档不是指游戏里的 localStorage而是项目文件的版本管理。即使是一个单文件页游我也建议每完成一个功能就用index-v1.html、index-v2.html这样的方式保存一份副本。否则当你改了五轮之后突然想回到第三轮的背包逻辑却发现旧版本已经不存在了。大模型迭代开发时最重要的能力不是“不断往前写”而是“能安全回退”。经验提醒如果你发现模型在某一次修改后大面积重构了代码即使它能跑通也要谨慎。因为重构往往意味着它没有完全理解上一轮的结构只是换了一种方式重写。此时最好的做法是回退到上一个版本换一个更小范围的提示词重新修改而不是接受这次大改。6. 写在后面模型评测真正应该看什么回到最开始的问题拿四款大模型做页游横评最终的价值是什么不是那四个模型的得分也不是谁家的代码更漂亮。而是通过这次横评我给自己建立了一套评估大模型的指标体系需求理解能力、代码可维护性、调试修复能力、迭代稳定性。这四个维度在任何类型的开发任务里都适用。今天的大模型写代码已经不是“能不能写对”的问题而是“能不能在别人的代码逻辑里继续扩展”的问题。页游恰好把这个问题压缩在一个小工程里让普通开发者也能在几个小时内完成一次可信的横向评估。如果你也想测试自己手头模型的真实水平不妨从一个小游戏开始把它当成一个标准测试集。但更重要的判断是无论模型能力多强人在这个流程里的角色都没有被削弱反而变得更关键了。你要负责拆需求、定边界、验收结果、掌控回退。大模型负责把清晰的规则快速翻译成代码但“清晰规则”本身永远是人的工作。所以下一次再有人问“哪个模型写代码最好”我大概会先反问他一句你的需求足够清晰了吗如果你自己都没有一个明确的验收标准那给你再强的模型也只会帮你生成一堆需要返工的代码。