作者｜连冉
编辑｜郑玄
8 月 28 日，腾讯发布并开源混元 Hy4 preview。
这是继 Hy3 正式版之后，腾讯推出的新一代大模型：总参数从 295B 增加到 770B，激活参数从 21B 增加到 49B，上下文长度也从 256K 扩展至 1M。模型已经同步进入 WorkBuddy、CodeBuddy、元宝和 ima，并可通过腾讯云 TokenHub 及 OpenRouter 调用。
此外，Hy4 preview 继续走普惠的高性价比路线。根据公布的价格信息，Hy4 preview 输入 6 元/百万 tokens，输出 18 元/百万 tokens，缓存命中 0.3 元/百万 tokens。
Hy3 此前已经替腾讯验证过一次产品化路径。它在 7 月发布后迅速进入腾讯的办公、编程和内容产品；腾讯披露，其 API 调用量在发布一周后达到上一代模型的 68 倍以上。Hy3 的优势是实用和高性价比：降低幻觉与常识错误，改善工具调用和多轮承接，让网页、表格、代码和文档从「能生成」变得「基本可用」。
Hy4 preview 要回答的，是下一道题。
相比 Hy3，Hy4 preview 把优化重点进一步推向软件工程、办公分析、游戏开发和科学研究等生产力任务。它要处理的是更长的工作链：理解需求、拆分步骤、调用工具、验证结果，并在出现报错、信息冲突或交付问题时继续修改。
腾讯内部组织了 163 名专家，对 203 个工程任务进行盲测。按照腾讯公布的数据，Hy4 preview 平均得分为 2.99/4，略高于 Kimi K3 的 2.94 和 GLM 5.3 的 2.92。
图片来源：腾讯
还有一个细节是，腾讯称，Hy4 preview 首次参与了自身训练方法、数据策略、评估体系和底层算子的优化，并通过多轮实验将推理吞吐相较基线提升 31.8%。
这种「发现问题—运行实验—根据结果继续修改」的能力，是否也能出现在普通用户的任务里？
我们给 Hy4 preview 准备了三项测试：在多份材料中完成费用审核、使用原生 Canvas 制作网页小游戏，以及从一句话开始开发一款 Three.js 3D 竞速游戏。看当任务变长、代码报错、交付物打不开时，它是否能不能把事情继续做下去。
01
先让 AI 审 6 笔账
在做游戏和 3D 场景之前，我们先给 Hy4 preview 派了一项更像真实办公室工作、也更难靠「看起来很聪明」蒙混过关的任务。
一个模拟费用材料包里放着 6 笔申请、两版费用制度、预算台账和 3 封审批邮件。客户餐叙要算人均限额，晚间交通要找活动证明，酒店有城市住宿上限，软件订阅则要判断 IT 是否真的批准。模型需要自己翻完 12 份材料，再给出「全额通过」、「核减后通过」或「退回补件」的结论。
Hy4 preview 用了 3 分 27 秒完成任务，生成了一份 Markdown 格式的《费用审核报告》：先给出汇总表，再逐笔写明依据、计算过程和后续待办。6 笔申请总额 5364 元，模型最终核准 4294 元，核减 230 元，另有 840 元退回补件，账是平的。
它还会主动去找申请单之外的证据。
比如 RB-003 是一笔 86 元的晚间交通费。申请单里只有行程记录，没有直接附活动证明。Hy4 preview 没有就此退回，而是翻到了邮件附件：项目负责人 21:32 发邮件要求申请人在会场完成供应商确认后再离开，邮件中还写明会议预计 22:15 结束；行程记录则显示，申请人 22:28 从会场返回公司。人物、地点和时间都对得上，模型采信了这笔费用。这一步测的，是能否把几份分散材料拼成一条完整的证据链。
算账也没有掉链子。RB-002 的客户餐叙申请金额是 1050 元，参与者共 3 人，模型算出人均 350 元，超过每人 300 元的限额，于是将核准金额压到 900 元，核减 150 元。RB-005 的酒店费用为 980 元，上海住宿上限为每晚 900 元，模型同样核减了 80 元。
视频来源：极客公园
复杂的是 RB-004 软件订阅。模型识别出，申请人提交的所谓「业务负责人邮件」并不是同意购买，而是「请先完成 IT 评估，确认前暂不批准购买」。同时，材料中也没有 IT 安全确认，订阅主体是否为公司账号同样不清楚。它没有只凭邮件标题里出现了「审批」两个字就放行，而是读了邮件真正表达的意思，最终将这笔 840 元申请退回补件。
不过，这次审核也并非没有瑕疵。
模型在制度版本的总判断里，把 6 笔申请都归入了 8 月 15 日生效后的 v2；但 RB-001 的申请日期是 8 月 12 日，实际应适用 v1。不过，客户餐叙的规则在 v1 和 v2 中没有变化，因此这处判断没有影响 RB-001 的最终金额和结论。但它提醒我们：模型已经能把很多审核动作串成一条链，却还不能让人完全放弃对关键前提的复核。
总体来看，这个 Case 测到了 Hy4 preview 最值得看的几项能力：多源材料交叉核验、制度与时间的匹配、金额计算、异常附件识别，以及把结果整理成可归档、可继续流转的文件。
02
32 分钟做了一款《深海进化论》，
它给自己写了测试
接下来，我们让 Hy4 preview 不用 Phaser 等第三方游戏引擎，只用 HTML5 Canvas 和 TypeScript，做一款「大鱼吃小鱼」。
任务要求并不复杂：玩家控制一条小鱼，在海底吃掉更小的鱼、躲开更大的鱼；需要有惯性移动、三种体型、吞食成长、碰撞判定、持续生成的鱼群、开始与结算界面，以及一套可直接运行的网页交付物。
32 分 1 秒后，Hy4 preview 交付了一个 30.5KB 的 game.ts、index.html，以及可双击运行的单文件版本。它没有把任务停在「生成一个 HTML 页面」：项目支持 npm run build 打包、npm run single 生成离线文件，并配了逻辑测试和浏览器端到端测试。
先看它做出来的东西。
视频来源：极客公园
打开游戏，深海蓝色背景里有从上方落下的光线、气泡、珊瑚和海草。玩家控制黄色小鱼移动，绿色虚线圈提示可吞食目标，红色虚线圈提示危险的大鱼；分数、最高分和体型进度则固定在界面上方。吞食后，玩家鱼的体型、速度和分数都会变化，死亡后还能看到「凶手」、存活时间、吞噬数量和最大体型。
从需求覆盖度看，原始要求的 8 项功能基本都已经实现。模型还额外加了连击、暂停、静音、本地最高分和更详细的死亡结算。这些都不难写进代码，但真正容易出问题的是：它们能不能一起工作。
Hy4 preview 的处理方式，是先把小游戏拆成玩家鱼、三类 AI 鱼、环境元素、碰撞与吞食逻辑、状态机和 UI 几部分，再自己运行测试。日志显示，它在交付前跑了 15 项 Node 逻辑测试和 14 项 Chromium 浏览器端到端测试，覆盖开局、键鼠操作、吞食成长、死亡结算、重开、暂停和静音等路径。
它也没有一次跑通就收工。
第一次自测时，模型发现从屏幕上下边缘游入的鱼会被边界限制立刻拽回屏幕，视觉上像「凭空冒出来」。它把逻辑改成只在鱼尝试游出边界时反弹，进场动画才自然下来。
第二个问题更像真实游戏开发里的手感 Bug：鼠标控制的小鱼接近猎物时会减速，而逃跑的鱼保持恒定速度，于是二者之间会形成一个始终追不上的 20 到 30 像素间隙。Hy4 preview 没有简单提高玩家移速，而是给追击速度设下限，同时为猎物加入持续逃跑后的体力衰减。修复后，追击不再变成无休止的「差一点」。
这个 Case 里，模型做到了「需求拆解—代码生成—运行测试—发现问题—修复问题—再次验证」串成一条完整链路。放在「原生 Canvas、零第三方游戏引擎、32 分钟完成」的前提下，《深海进化论》能开始、能玩、能失败、能重开，也留下了一套能继续修改和验证的工程文件。
如果前一项费用审核证明了 Hy4 preview 会整理材料，这一项则证明，它开始能把一段相对完整的前端工程自己推到可交付状态。
03
一句话生成 3D 游戏，第一版却打不开
最后一项测试，我们让 Hy4 preview 使用 Three.js 制作《午夜港口》：玩家操控无人机，在雨夜集装箱港口与三架 AI 对手竞速。游戏需要包含隧道、起重机和狭窄弯道，并实现氮气、碰撞、检查点、实时排名和三圈计时。
Hy4 preview 第一次开发用了 1 小时 39 分钟，进行了 27 次文件修改。它为赛道设置了 14 个顺序检查点和 164 个碰撞盒，三架 AI 无人机可以减速过弯、切换路线和相互避让；场景里则有 GPU 雨丝、积水反射、闪电、集装箱、龙门吊和城市天际线。
实际运行时，游戏已经具有相当完整的视觉和交互框架。雨水落在霓虹港口，建筑倒映在水面；玩家无人机拖着蓝色尾迹，HUD 同时显示圈数、名次、速度、高度、氮气、小地图和实时排名。倒计时结束后，三架 AI 无人机会同时起飞，玩家偏离路线时也会收到提示。
但第一次交付并不成功。
图片来源：极客公园
模型最初提供的是一个依赖本地服务器的模块化项目。任务结束后，临时服务随之关闭；直接双击 index.html，又会因为浏览器限制加载失败。结果是代码可以运行，用户拿到的却是一张白屏。
我们把问题反馈给它。20 分 8 秒后，Hy4 preview 没有重写游戏，而是重新处理依赖和打包方式，生成了一个 0.57MB 的单文件版本。新版本不需要服务器，双击即可启动。
开发过程中，它还设计了两套自测：先用 Node 模拟四架无人机跑完整场比赛，再在 Chrome 中检查画面和交互。
根据模型留下的验证日志，两套测试先后暴露出三个问题：AI 会因前视距离过长而撞上障碍；完赛后仍然继续累计圈数；泛光阈值过低，导致整个雨夜场景严重过曝。模型分别调整了 AI 路径预测、比赛状态和渲染参数，并重新验证结果。
其中，画面过曝的排查最能体现它的调试能力。模型逐层关闭渲染效果，把问题定位到 UnrealBloom 参数，再将阈值从 0.55 提高到 0.78，雨夜港口才从一片白雾恢复成正常夜景。
视频来源：极客公园
从实际试玩看，游戏已经可以完成倒计时、起步、飞行和碰撞；AI 对手、实时排名和小地图也能正常变化。
《午夜港口》这个 Case，整个任务耗时近两个小时，首次交付还因启动方式不当出现白屏；收到反馈后，Hy4 preview 没有推倒重来，而是沿着原有工程继续修复打包、AI 路径和渲染参数，最终交付可运行版本。
这种在复杂项目中定位问题、承接上下文并持续推进的能力，也更接近 Hy4 preview 想要证明的长程 Agent 能力。
三项测试呈现出了一条相似的轨迹：Hy4 preview 并非不会犯错——费用审核选错过制度版本，3D 游戏第一次交付甚至无法打开。但与只会生成答案的模型相比，它更重要的变化是能够在错误出现后继续工作：寻找关联材料、运行测试、定位问题，并在已有结果上迭代，而不是重新开始。
这让 Hy4 preview 更接近腾讯为它设定的生产力模型定位。不过，模型留下的测试日志仍不能完全替代人的最终验收。它已经能承担更长的执行链，但交付前的最后一次复核，目前依然需要人来完成。
Hy4 preview 的发布，也发生在腾讯明显加大 AI 投入的时间点。腾讯二季度披露，混元、元宝、CodeBuddy、WorkBuddy 和小微等新 AI 业务，合计对 Non-IFRS 经营利润产生了约 105 亿元的净影响。腾讯同时明确了算力的分配顺序：优先用于自研模型训练，其次支撑 WorkBuddy 等产品的推理需求，剩余部分才通过腾讯云对外提供。
这意味着，Hy4 preview 需要证明的不只是模型能力有所提升，还要证明这些持续增加的算力投入，能够转化为真实的产品使用和商业回报。输入每百万 Tokens 6 元的定价，以及在 WorkBuddy、CodeBuddy 等产品中的同步上线，都是腾讯降低使用门槛、扩大任务调用量的方式。
混元能否在持续迭代中站上第一梯队？Hy4 preview 给出的答案是不能只看参数和榜单，更重要的是，当用户真正把工作任务交给它时，它能否稳定完成，以及用户是否愿意继续为下一项任务调用它。
*头图来源：Hy4 preview
本文为极客公园原创文章，转载请联系极客君微信 geekparkGO
