在实际项目里把大模型从“聊天对话”推向“生成可运行产物”页面小游戏是一个很合适的中间地带。K3、Fable5、GLM5.2、Hy3 这四款大模型放在一起做页游横评如果只看自然语言问答很难看出差别真正拉开差距的往往是同一个需求被还原成代码后的可运行性、交互完整度和维护成本。本文围绕“用四款模型生成同一个贪吃蛇页游”这条主线展开先说明为什么页游适合做横评再给出统一提示词、验收清单、评分口径然后记录四款模型的抽样表现拆解能通过验收的关键实现最后提供自动化复现脚本、常见坑排查路径和选型建议。整个过程可以在本地复现结果也能作为后续评估模型代码生成能力的参考样本。1. 为什么拿页游做大模型横评一个能闭环验证的任务样本1.1 页面小游戏同时覆盖多种编码能力页面小游戏虽然看起来轻量但它并不是单一的“画按钮”或“写一段 JS 函数”而是把前端常见问题集中到了一个文件里。以贪吃蛇为例一个完整实现至少包含HTML 结构画布、按钮、得分区、UI 容器。CSS 样式页面居中、按钮状态、移动端布局。JavaScript 数据模型蛇身坐标、移动方向、食物位置、游戏状态。事件处理键盘事件、触摸事件、按钮点击。渲染循环Canvas 绘制、定时移动、帧率控制。状态机开始、运行中、结束、重新开始。边界处理撞墙判断、撞身体判断、食物与蛇身重叠。这些能力并不是零散无关的。任何一个环节缺失都可能导致同一个提示词下的产物无法直接运行。正因如此用页游做横评比用“让模型写一段排序算法”更能暴露模型在真实开发场景里的综合表现。1.2 页游任务的可验证性高于文本生成任务自然语言任务的评分带有主观性而页游任务的验收是相对客观的文件能不能打开、浏览器控制台有没有 JS 报错、蛇能不能移动、吃食物后分数是否变化、撞墙后是否结束、重新开始后是否恢复初始状态。这些都可以用“通过/不通过”判断也可以进一步转为 0 到 10 分的评分项。横评的流程并不复杂但必须提前固定。实际操作中最容易出现的问题是每个模型收到的提示词不一样、测试标准不一样、评分人凭感觉打分。结果就是文章写得热闹结论却无法复现。本文采用的流程是三步固定任务、统一指标、记录原始输出。所有生成结果统一保存到本地目录后续可以随时重跑。1.3 本文的边界这不是一份长期能力排行榜要特别说明一点K3、Fable5、GLM5.2、Hy3 的版本和接口能力会持续变化一个模型的输出质量也受采样参数影响。下面的对比结果只代表“本文写作时的一次受控抽样”不代表“四款模型的长期能力排名”。如果你是自己做选型评估更稳妥的做法是同样用本文的提示词和验收清单对每个模型至少采样 3 次再汇总通过率和常见问题类型。单次横评适合积累方法不适合作为采购或技术选型的唯一依据。2. 横评前先定基准提示词、验收清单、评分口径2.1 先把四个模型的调用方式统一横评前需要固定模型参数否则结果会受到随机采样影响。这里使用的参数建议如下参数建议值说明temperature0.2降低随机性让输出更稳定top_p0.8配合 temperature 使用避免生成过于发散max_tokens4000贪吃蛇单文件通常需要 2000 到 4000 token太短会被截断提示词语言中文与测试场景一致输出格式要求直接输出 HTML 代码块方便从响应中提取文件如果模型支持网页版对话也可以直接使用同一份提示词但需要人工复制生成结果。无论通过 API 还是网页版都要记录调用时间和模型标识便于后续追溯。2.2 统一需求模板生成一个单文件贪吃蛇页游为了让四款模型面对完全相同的输入这里使用统一提示词你是一名前端工程师。请生成一个完整的单文件 HTML 贪吃蛇小游戏文件名为 snake.html。要求如下 1. HTML、CSS、JavaScript 全部放在同一个文件中不引用任何外部资源。 2. 使用 Canvas 绘制游戏画面。 3. 游戏区域为 20x20 网格每个网格大小为 20px。 4. 支持键盘方向键和 WASD 控制蛇的方向。 5. 吃食物后蛇变长分数加 10食物随机出现在空白格。 6. 蛇撞到边界或身体时游戏结束并显示最终得分。 7. 页面包含“开始游戏”和“重新开始”按钮。 8. 适配手机屏幕支持触摸滑动控制方向。 9. 添加基本 CSS 样式保证页面居中且不溢出。 10. 请直接输出完整可运行的 HTML 代码并用代码块包裹。选择贪吃蛇而不是一个静态页面是因为它有“状态变化”和“运行闭环”。只生成静态页面时模型即使写错了交互逻辑也可能因为页面能打开而被误判为通过。贪吃蛇必须让事件循环跑起来才能验证真正的代码生成能力。2.3 验收清单从文件能打开到交互完整生成结果不能只看“代码像不像”。建议按这条清单逐项验收HTML 文件是否完整是否以!DOCTYPE html开头是否以/html结尾。直接双击文件或通过本地服务打开后页面是否渲染。浏览器控制台是否出现 JS 报错。是否能看到 Canvas 游戏区域和开始按钮。点击“开始游戏”后蛇是否按一定时间间隔自动移动。是否出现食物并且食物不在蛇身上。蛇吃到食物后蛇身长度是否增加分数是否加 10。撞到边界或身体后是否进入结束状态并显示最终得分。点击“重新开始”后是否恢复到初始状态。使用手机尺寸模拟时页面是否完整显示触摸滑动是否能改变方向。任何一项不通过都应记录具体现象。记录时不要写“体验一般”这类模糊描述而是写“点击重新开始后分数没有归零”这种可以直接定位问题的句子。2.4 评分维度与权重设计人工主观打分容易失真因此要给每个维度设计明确标准维度权重检查点通过标准可运行性25%页面渲染、控制台报错无致命 JS 错误页面可直接打开功能完整度30%游戏闭环开始、移动、吃食、加分、结束、重启全部有效代码质量20%命名、结构、注释、可维护性变量清晰函数职责明确逻辑不混乱移动端适配15%viewport、触摸事件、按钮尺寸手机尺寸下可操作触摸方向控制有效性能与体验10%帧率、移动节奏使用 requestAnimationFrame 或合理定时器无明显卡顿每个维度按 0 到 10 分打分再乘权重求和。最终分数只对当次生成结果负责。如果某个模型在某次生成中因为偶尔截断导致得低分不能直接判定该模型整体不行需要多采样几次再下结论。2.5 学习环境与生产环境的横评口径学习阶段的横评重点是“能不能跑通”。因此允许使用单文件 HTML不需要构建工具也不需要单元测试。但一旦要进入生产环境单文件页游通常不是最终形态。生产环境还要考虑代码拆分HTML、CSS、JS 分离便于维护。构建工具压缩、转译、静态资源 hash。错误监控全局捕获异常并上报。安全策略限制内联脚本配置 Content-Security-Policy。可测性把游戏逻辑抽象成纯函数便于写单元测试。横评时可以先按学习环境的口径验收再针对“可维护性”和“安全性”做单独评估两者不要混在一起。3. 四款模型在同一需求下的生成结果对比3.1 本次横评抽样记录下面记录来自一次受控抽样四个模型分别接收同一份提示词温度设为 0.2每个模型只取一次典型输出。结果用于说明差异类型不构成长期结论。模型首轮可直接运行主要差异点功能完成度移动端适配K3是注释较完整边界处理清晰完整完整Fable5是按钮在窄屏下偏小完整基本完整GLM5.2是函数拆分较细方向反转偶发完整完整Hy3是缺少触摸滑动控制完整不完整这张表并不是模型能力排名。它的价值在于说明一个问题同一个需求四款模型的首轮结果都能打开但差异不会体现在“能不能运行”上而是体现在“细节是否完整”上。3.2 可运行性对比首轮验收时四份输出都没有出现白屏也没有在控制台报告致命错误。这是本轮横评最大的共同点。可运行性不通过的情况通常在另外两种场景出现模型输出的 HTML 被截断script标签没有闭合。模型在代码中引用了外部 CDN 资源导致离线打开时样式或脚本失效。本次提示词里明确要求“不引用外部资源”“直接输出完整 HTML”这两条约束有效降低了不可运行的概率。如果去掉这些约束首轮通过率会明显下降。3.3 交互完整度对比四份实现都覆盖了开始、移动、吃食物、得分、结束、重启这六件事。差异主要在细节K3 对“食物不能生成在蛇身”处理得更直接。Fable5 的“重新开始”按钮在窄屏下点击区域偏小容易误触。GLM5.2 在连续快速改变方向时出现过一次方向反转导致蛇头撞向身体的情况。Hy3 没有实现触摸滑动控制只支持键盘在移动端无法正常操作。交互完整度并不是“按钮越多越好”而是“每个状态是否都有出口”。一个常见评价技巧是按用户的完整行为路径走一遍从打开页面到结束游戏中间任何一步断掉都不算通过。3.4 代码质量对比代码质量主要是维护成本问题。几个模型的输出都能跑但结构差异比较明显K3 的注释更完整关键函数前面都说明了输入、输出和边界条件。GLM5.2 的函数拆分更细移动、碰撞检测、食物生成各自独立。Fable5 的代码更“短平快”适合快速原型但一个函数里混杂了移动和渲染逻辑。Hy3 的命名比较随意例如t、s、f这类缩写后续维护需要额外理解成本。如果只是临时玩一下代码质量不那么重要。但如果要把模型生成的代码并入团队项目缩写命名、函数过长、缺少注释都会成为隐患。3.5 多端适配和性能对比移动端适配是这轮横评里差异最大的一项。K3 和 GLM5.2 的生成结果包含viewport设置、触摸事件和响应式按钮Fable5 有触摸事件但按钮偏小Hy3 则完全没有触摸控制。性能方面四份实现都使用了requestAnimationFrame或固定时间间隔的定时器在桌面端没有明显卡顿。性能问题在简单页游里不太容易暴露但如果游戏逻辑复杂比如频繁创建对象、没有清除 Canvas 路径帧率会明显下降。3.6 一个容易忽略的差异错误处理页游的错误处理通常体现在两个地方食物生成时是否检查“生成的坐标是否落在蛇身上”。撞墙和撞身体时是否提前判断而不是等蛇已经越过边界才处理。这些逻辑不影响“页面能否打开”但直接影响游戏体验。横评时不只要看主流程还要主动用边界输入去测试。比如让蛇朝一个方向走到底观察是“撞到边界停止”还是“越界后报错”就能看出模型的边界处理能力。4. 关键实现拆解能通过验收的贪吃蛇页游长什么样4.1 页面骨架、Canvas 尺寸和 DPI 适配一份能通过验收的生成结果首先要把 Canvas 尺寸和 CSS 尺寸区分清楚。常见错误是只设置 CSS 宽度没有设置 Canvas 的width和height导致绘制区域默认只有 300x150。!DOCTYPE html html langzh-CN head meta charsetUTF-8 meta nameviewport contentwidthdevice-width, initial-scale1.0 title贪吃蛇/title style body { margin: 0; display: flex; justify-content: center; align-items: center; min-height: 100vh; background: #f5f5f5; } canvas { border: 1px solid #333; background: #fff; touch-action: none; } /style /head body canvas idgame width400 height400/canvas script // 游戏逻辑 /script /body /htmltouch-action: none是为了避免手机浏览器在 Canvas 上滑动时触发页面滚动。如果不加这一条触摸滑动控制方向时会同时滚动页面体验很差。4.2 蛇的移动、方向队列和碰撞检测蛇的移动不需要每个像素都重绘只需要按固定节奏更新坐标。核心数据结构是数组蛇头是数组第一个元素蛇身依次排列。const grid 20; const cols 20; const rows 20; let snake [ { x: 9, y: 10 }, { x: 8, y: 10 }, { x: 7, y: 10 } ]; let direction { x: 1, y: 0 }; let directionQueue []; function nextDirection() { if (directionQueue.length 0) { const next directionQueue.shift(); // 禁止 180 度反向 if (next.x ! -direction.x || next.y ! -direction.y) { direction next; } } } function moveSnake() { nextDirection(); const head { x: snake[0].x direction.x, y: snake[0].y direction.y }; if (head.x 0 || head.x cols || head.y 0 || head.y rows) { gameOver(); return; } for (let segment of snake) { if (head.x segment.x head.y segment.y) { gameOver(); return; } } snake.unshift(head); if (head.x food.x head.y food.y) { score 10; generateFood(); } else { snake.pop(); } }方向队列是用来避免“快速连按导致方向反转”的经典方案。按钮和键盘的事件顺序很难控制如果直接修改direction玩家连续按“上”和“左”时旧方向可能还没被使用导致蛇瞬间反向。方向队列让每一次按键先进入队列再在每次移动前取一个方向同时禁止 180 度反向可以显著降低这类问题。4.3 食物生成、得分和重新开始食物生成最简单的做法是随机取一个网格坐标然后判断是否落在蛇身上。如果落在蛇身上就重新生成。function generateFood() { let x, y; do { x Math.floor(Math.random() * cols); y Math.floor(Math.random() * rows); } while (snake.some(segment segment.x x segment.y y)); food { x, y }; }注意do...while循环在蛇占据大量网格时可能出现多次随机尝试。对于 20x20 的棋盘这种写法足够但如果是 100x100 或更大棋盘且蛇身很长建议改成“收集所有空白格再随机取一个”避免长时间循环。重新开始要把蛇、方向、分数、食物和游戏状态全部重置而不是只清空画布。function resetGame() { snake [ { x: 9, y: 10 }, { x: 8, y: 10 }, { x: 7, y: 10 } ]; direction { x: 1, y: 0 }; directionQueue []; score 0; food { x: 15, y: 10 }; running false; updateScore(); draw(); }4.4 键盘与触摸控制键盘监听一般挂到window上避免页面焦点不在body上时事件丢失。触摸控制则通过touchstart和touchend计算滑动方向。window.addEventListener(keydown, (event) { const keyMap { ArrowUp: { x: 0, y: -1 }, ArrowDown: { x: 0, y: 1 }, ArrowLeft: { x: -1, y: 0 }, ArrowRight: { x: 1, y: 0 }, w: { x: 0, y: -1 }, s: { x: 0, y: 1 }, a: { x: -1, y: 0 }, d: { x: 1, y: 0 } }; const next keyMap[event.key]; if (next) { event.preventDefault(); directionQueue.push(next); } }); let touchStart null; canvas.addEventListener(touchstart, (event) { touchStart { x: event.touches[0].clientX, y: event.touches[0].clientY }; }); canvas.addEventListener(touchend, (event) { if (!touchStart) return; const dx event.changedTouches[0].clientX - touchStart.x; const dy event.changedTouches[0].clientY - touchStart.y; if (Math.abs(dx) Math.abs(dy)) { directionQueue.push({ x: dx 0 ? 1 : -1, y: 0 }); } else { directionQueue.push({ x: 0, y: dy 0 ? 1 : -1 }); } touchStart null; });event.preventDefault()要保留否则方向键会触发页面滚动。4.5 requestAnimationFrame 与 setInterval 的取舍蛇移动并不需要每一帧都改变位置常见做法是用setInterval控制移动节奏用requestAnimationFrame控制绘制。如果只用setInterval移动和绘制可能不同步如果只用requestAnimationFrame则需要记录上次移动时间。简单项目里用setInterval也能接受。更规范的做法是let lastMoveTime 0; const moveInterval 150; function gameLoop(timestamp) { if (timestamp - lastMoveTime moveInterval) { if (running) { moveSnake(); } draw(); lastMoveTime timestamp; } requestAnimationFrame(gameLoop); } requestAnimationFrame(gameLoop);这种方式既能控制移动速度又不会让绘制脱离浏览器渲染节奏。5. 横评结果落盘与复现脚本5.1 自动化与人工验收结合页游横评不能只靠人工肉眼判断。建议把每个模型的输出保存到独立目录outputs/ k3/snake.html fable5/snake.html glm5.2/snake.html hy3/snake.html scores.csv自动化脚本负责打开页面、收集控制台错误、截图、检查关键元素人工负责实际玩一遍判断手感、交互和边界情况。两者结合比单纯自动或单纯人工都可靠。5.2 本地启动静态服务直接双击 HTML 文件通常也能运行但为了更接近真实访问场景建议使用本地静态服务。cd outputs python3 -m http.server 8080然后访问http://127.0.0.1:8080/k3/snake.html。使用本地服务可以避免部分浏览器对本地文件模块路径的限制也更容易配合 Playwright 等自动化工具。5.3 用 Playwright 自动打开页面并收集错误以下脚本可以自动打开页面、监听控制台错误、执行一次点击、截图并返回基本结果。它适合作为横评的第一步过滤。from playwright.sync_api import sync_playwright import pathlib def check_game(file_path: str): file_url pathlib.Path(file_path).resolve().as_uri() console_errors [] page_errors [] with sync_playwright() as p: browser p.chromium.launch() page browser.new_page(viewport{width: 390, height: 844}) page.on(console, lambda msg: console_errors.append(msg.text) if msg.type error else None) page.on(pageerror, lambda exc: page_errors.append(str(exc))) page.goto(file_url) page.wait_for_timeout(1000) start_button page.locator(button:has-text(开始)) if start_button.count() 0: start_button.first.click() page.wait_for_timeout(500) page.screenshot(pathscreenshot.png, full_pageTrue) browser.close() return { console_errors: console_errors, page_errors: page_errors } if __name__ __main__: result check_game(outputs/k3/snake.html) print(result)脚本只验证“页面能打开、开始按钮能点击、无致命错误”并不能代替人工验证游戏手感。自动化的价值是快速筛掉明显不通过的输出把人工精力集中在交互体验上。5.4 评分结果的数据结构记录评分时不要只记总分。建议使用 JSON 或 CSV 保存以下字段{ model: k3, prompt_version: v1, temperature: 0.2, max_tokens: 4000, sampled_at: 2026-08-20T10:30:0008:00, passed_runnable: true, passed_flow: true, score: { runnable: 9, feature: 9, code_quality: 8, mobile: 9, performance: 8 }, issues: [ 食物生成逻辑偶发出现在蛇身附近, 重新开始按钮在窄屏下偏小 ] }保存原始输出和评分记录后续如果需要重新评估可以对照同一份提示词和同一份产物做差异分析。6. 常见坑与排查路径6.1 模型输出被截断或包在代码块里现象生成的 HTML 无法打开或打开后空白检查文件发现script标签没有闭合。原因max_tokens设置过小模型生成到一半被截断或者提示词没有要求“直接输出完整代码”模型把 HTML 包在 Markdown 表格或说明文字中间。检查方式查看生成文本尾部确认是否以/html结束搜索文件里是否只有一段html代码块。解决方式将max_tokens调到 4000 以上在提示词末尾增加“不要输出任何解释文字直接输出 HTML 代码块”。如果需要从包含解释的响应里提取代码可以写脚本截取第一个html和最后一个之间的内容。问题现象常见原因检查方式处理建议文件不完整max_tokens 不足查看文件尾部调大 max_tokens页面打开空白代码被 Markdown 包裹搜索代码块标记解析第一个 html 代码块CSS 丢失引用了外部 CDN搜索 http/https提示词要求不引用外部资源6.2 Canvas 内容不显示现象页面能打开按钮能看到但 Canvas 区域是空白。原因Canvas 的width和height没有设置或者绘制代码在canvas元素还未挂载时就执行了也可能是颜色和背景色一致看起来“什么也没画”。检查方式打开控制台执行document.querySelector(canvas).width和height确认不是默认的 300x150再检查getContext(2d)是否返回null。解决方式把脚本放到/body前在 JS 开头获取 Canvas 元素后先判断是否存在。绘制时先设置ctx.fillStyle再调用fillRect避免颜色与背景混淆。注意不要只验证页面“有 Canvas 标签”还要验证绘制指令是否真正产生了像素。截图后放大看有没有黑色蛇身是简单有效的方式。6.3 键盘和触摸事件不生效现象点击开始后蛇不动或点击方向键没有反应。原因keydown监听挂在了canvas或某个局部元素上键盘事件没有冒泡到该元素或者移动端只监听了keydown没有处理touchstart/touchend。检查方式在监听器第一行加console.log(event.key)按方向键看控制台有没有输出模拟手机视口后在 Canvas 上滑动试一下。解决方式键盘监听挂在window上移动端触摸监听挂在 Canvas 上并加touch-action: none阻止页面滚动。6.4 方向快速反转导致蛇“自杀”现象玩家快速按“上”再按“左”蛇头直接撞向身体。原因方向更新没有使用队列也没有禁止 180 度反向。第一次按键改成了向上第二次按键在同一次移动前又把方向改成了向左但蛇头目前仍朝右向左会让蛇头瞬间反向。检查方式打开游戏后按住一个方向键紧接着快速按反方向键观察蛇是否在下一步反向。解决方式使用方向队列在读取下一个方向时增加if (next.x ! -direction.x || next.y ! -direction.y)判断。这条规则能阻止大多数“瞬间反向”问题。注意横评验收时一定要测试这类边界输入。只测正常顺序按键很难暴露方向管理的缺陷。6.5 食物生成在蛇身上或导致无限循环现象蛇很长以后吃食物后长时间不出现新食物或者页面卡死。原因随机生成食物坐标后没有检查是否与蛇身重叠或者蛇几乎占满棋盘时do...while循环反复碰撞随机数导致长时间空转。检查方式在generateFood里加console.log查看尝试次数或缩短到蛇身占满一半棋盘时观察。解决方式蛇身较短时用随机重试即可蛇身较长时改成收集所有空白格再随机取一个。后者的复杂度是 O(棋盘网格数)不会出现空转。7. 选型建议、提示词工程与可复用清单7.1 选型不能只看一次横评做页游横评最容易犯的错误是“一次生成定胜负”。模型生成本身有随机性即使temperature0.2同一提示词在不同轮次也可能得到不同结果。选型时建议每个模型至少采样 3 次统计通过率。至少准备 2 个不同的页游需求例如贪吃蛇和打地鼠避免模型只擅长某一种题型。分别记录首轮可运行率、最终可运行率、代码质量问题数。把“生成后用多少人时能修复到可用”也纳入评估而不是只看首轮效果。如果首轮效果接近真正值得关注的指标是“修复成本”。有的模型输出能直接跑但读代码要花很久有的模型输出有小问题但结构清晰几分钟就能改好。后者在工程里的价值往往更高。7.2 提示词模板的优化方向本文使用的提示词只是一个基线。实际项目里可以在提示词中加入更多约束指定函数命名风格和注释语言。要求把游戏逻辑拆成初始化、更新、渲染、事件处理四个函数。要求不依赖外部资源方便离线运行和自动化测试。要求输出验收说明例如“请额外给出浏览器打开后应检查的三个关键步骤”。优化的提示词模板请生成一个单文件 HTML 小游戏。要求 1. HTML、CSS、JS 全部在一个文件内不引用外部资源。 2. 游戏逻辑拆分为 init、update、render、handleInput 四个函数。 3. 使用 requestAnimationFrame 驱动游戏循环。 4. 适配桌面端和移动端移动端支持触摸滑动。 5. 假设游戏出现 JS 错误时需要能通过浏览器控制台快速定位。 6. 输出完整 HTML 代码不要解释性文字。提示词越具体模型的输出越接近可验收状态。但也不要一次塞太多要求否则模型可能会顾此失彼。建议先跑通基线版本再逐条补充约束观察哪条约束能真正降低人工修复成本。7.3 生成页游的工程化落地页游横评之后如果要把大模型生成的代码用于实际项目还需要补充工程化环节把单文件拆分为独立模块至少把 CSS 和 JS 分离。对关键逻辑写单元测试。贪吃蛇可以测试“移动后坐标是否符合预期”“吃食物后分数是否增加”“撞墙后状态是否变为结束”。增加配置化的游戏参数例如网格大小、移动间隔、初始蛇长度。使用构建工具压缩和转译确保目标浏览器兼容。配置错误监控捕捉运行时异常。审查代码中是否引用外部域名避免第三方接口和数据泄露风险。页面小游戏虽然简单但作为模型输出样本它足够检验一个模型是否理解“输入、状态、输出”三者之间的关系。这也正是它适合做横评的原因。7.4 可复用清单横评或前端代码生成验收时可以直接使用这份清单固定模型参数temperature、top_p、max_tokens。固定提示词版本记录 prompt_version。使用统一验收清单逐项打钩。先自动检查控制台错误再人工试玩。测试边界输入快速反向、撞墙、食物重叠。测试移动端视口和触摸事件。保存原始输出、验收记录和评分明细。对每个模型多次采样避免单次误差。评估修复成本而不是只看首轮可运行率。不把单次横评结果当作长期选型结论。这套方法不仅适用于“大模型生成页游”也可以迁移到“生成表单页面”“生成管理后台面板”“生成接口 Mock”等场景。只要任务可以被拆成明确输入和可验证输出都可以用同样思路做横评。K3、Fable5、GLM5.2、Hy3 这四款模型在本次横评里都展示了“能生成可运行页面”的基本能力真正的差异集中在细节处理、移动端适配和代码可维护性。对实际项目来说最值得留住的不是某个模型的分数而是这套“固定提示词、统一指标、保留原始输出、人工加自动双重验收”的横评流程。后续再遇到新的模型或新的前端生成需求可以直接把本文的方法复用过去用最小成本判断一个模型是否值得进入你的工具链。
