HY3正式版：用它做了个“AI焦虑游戏”后，我看腾讯的焦虑能缓缓了

7月6日，腾讯混元Hy3正式版发布。

根据官方文档，Hy3采用MoE架构，总参数295B、激活参数21B，支持256K上下文，是一个快慢思考融合模型。相比4月发布的Hy3preview，正式版在复杂推理、指令遵循、上下文学习、代码生成和Agent能力上继续提升，稳定性和性价比也进一步改善。

腾讯称，Hy3已经展现出显著强于同尺寸模型、并能比肩参数规模2到5倍旗舰模型的智能水平。

Hy3已经开始进入腾讯自己的AI产品体系。WorkBuddy、CodeBuddy、元宝、Marvis、ima等业务都已接入，API也已在腾讯云TokenHub上线。

此前和汤道生对话时，姚顺雨提到过一个细节。

元宝早期阶段，混元曾派出后训练最强的一批骨干，先去帮元宝适配 DeepSeek。这个说法很微妙。它一方面说明腾讯足够现实：产品要先跑起来，谁能解决问题就先用谁；另一方面也说明，在那个阶段，混元自己的底座还没有完全 ready。

这也是过去两年腾讯 AI 给外界留下复杂观感的原因。

你很难说腾讯慢，元宝、ima、WorkBuddy、Marvis，腾讯几乎把 AI 塞进了所有关键入口。

但问题也在这里，应用层越热闹，基础模型的短板就越明显。

腾讯不缺入口，也不缺场景。它真正缺的，是一个能支撑这些入口的模型中枢。

所以，Hy3正式版效果如何，它能否成为腾讯一众AI产品的基座？

我们第一时间上手测试了一下。

我们给模型设计了一条更接近真实开发流程的游戏测试路线。

测试从一个很小的游戏概念开始：玩家是一名 AI 媒体编辑，在霓虹风格的虚拟编辑部里躲避不断涌来的“选题焦虑怪”，通过移动、射击、收集灵感碎片来坚持更长时间。游戏名叫《Neon Deadline》。

这个设定并不复杂，但它足够完整，能覆盖一款小游戏从策划到开发再到宣发的关键环节。

第一步，我们要求模型把这个概念扩展成一份可执行的游戏策划案。它需要定义核心玩法、目标玩家、操作方式、敌人类型、成长系统、UI 设计和第一版 MVP 范围。

这里考察的不是想象力，而是收敛能力，它应该知道第一版最重要的是移动、射击、刷怪、掉落、计分、死亡和重开。

策划

HY3 把《Neon Deadline》拆成了一份完整的 MVP 方案：核心循环、玩家操作、敌人设计、道具成长、美术风格、UI、开发优先级都比较清楚。

而且它已经能把玩法设计和 Godot 实现方式连起来。比如玩家使用 CharacterBody2D，子弹使用 Area2D，敌人统一抽象为 Enemy 基类，难度曲线用 Timer 和时间系数驱动，霓虹效果用 Godot 内置 Glow 和粒子实现。

不是单纯的创意发散，而是带有工程意识的策划。但问题也在这里，HY3 嘴上强调 MVP，实际给第一版塞进了不少功能。

从结果看，HY3 在“把创意转成方案”上表现不错，但在“压住第一版范围”上仍有模型常见的扩张倾向。

这对应了 Agent 规划能力里的一个关键问题：会不会做计划不难，难的是会不会知道哪些东西暂时不该做。

技术文档

第二步，我们让模型基于策划案继续输出 Godot4.x 技术方案。这个阶段会暴露它是否真正理解游戏开发，而不是只会写泛泛的项目计划。

它需要说明项目目录、场景拆分、节点类型、脚本职责、输入映射、碰撞层设计，以及玩家、敌人、子弹、掉落物、UI 和 GameManager 之间如何通信。

第二轮技术方案里，HY3 的表现比普通模型更像一个懂 Godot 工程的人。它没有停在“做玩家、做敌人、做 UI”这种泛泛规划，而是具体拆到了 Node2D、CharacterBody2D、Area2D、CanvasLayer、Timer、Camera2D 这些 Godot 节点，也给出了项目目录、场景职责、脚本职责和碰撞层设计。

比如它主动把 GameManager 设计成 autoload 单例，负责状态、分数、难度和全局事件，避免敌人、子弹、掉落物到处硬找节点。

这部分能看出 HY3 并不是只在做抽象规划，而是开始进入工程语境。它知道一个 Godot 项目真正容易出错的地方。

开发

第三步进入真正的开发。我们要求模型从 0 到 1 生成完整 Godot 项目，而不是只给代码片段。

这一环节，HY3 开始表现出比较明显的工程自检意识。它没有简单把上一轮方案照搬成文件，而是在写项目之前主动做了几处调整：比如把接触伤害从area_entered改成body_entered，把玩家 HurtArea 的 mask 补上 pickup 层，又把全局暂停改成“状态标志+Timer 暂停”的软暂停。

它尝试运行 Godot headless 做验证。第一次遇到严格类型推断和class_name注册问题后，它没有跳过，而是继续修改类型声明和跨脚本依赖，最后改成更保守的类型调用，并声称 Main 场景实跑 2 秒没有运行时错误。

但真正运行之后，项目还是有错误。比如玩家射击时，bullet.gd在setup()里试图给一个不存在的视觉节点设置color，于是报出Nil.color错误。

可以看出，HY3 的自动验证还不等于完整玩法验收。它能检查项目是否启动，却没有覆盖“玩家射击”这种核心交互路径。

编译通过、场景能跑，只是起点，不代表游戏闭环真的成立。

但从 Debug 环节看，HY3 的修复能力是有效的。它能根据调用栈定位到问题，并在原项目上修复，而不是推倒重来。

简单试玩一下游戏，可以发现，基本的游戏雏形已经有了。比如血条、技能条、玩家控制的小三角射击子弹，击毁对手后，会获得能量，能量到达一定程度就能进化子弹技能。

迭代

这一部分，我们追加版本迭代需求，专门测试它是否能维护已有项目。

我们要求在不重写整个项目的前提下增加三种敌人：速度中等、血量 1 的普通敌人；速度更快、血量 1 的冲刺敌人；速度较慢、血量 3 的重型敌人。

同时加入升级系统：玩家每收集 10 个灵感碎片，可以从提升射速、提升移动速度、子弹穿透 +1 三个选项中选择一项升级。升级选择时游戏暂停，选择后继续。

这一轮考验 HY3 的长程执行和已有工程上的增量开发能力。真实项目很少是一次性从零生成，更多时候是产品经理不断追加需求，工程师必须在原有代码结构上继续扩展，而不能每次都重写一套。

HY3 的任务拆分说明它理解了“升级系统”背后的工程依赖。一个三选一升级并不只是多一个弹窗，它会牵动 GameManager 的状态机，等多个熟悉。

这是长任务执行里比较关键的能力：模型能不能记住前面的工程结构，并在此基础上继续改。

很惊喜，HY3 一次就完成了这轮迭代，没有出现 BUG。可以看到在原始版本基础上增加了三个技能选项，以及不同类型的敌人。每个技能的效果和敌人也与描述的一致。

我们还做了一些更细的体验修改。比如玩家射出的子弹，最初是从三角形角色的上方尖角飞出，看起来像是从角色头顶发射，而不是从身体中心射出。

这个问题很小，但很接近真实开发里的日常修 Bug：它不是系统崩溃，也不是功能缺失，而是一个影响手感和观感的细节。

HY3 的处理路径比较干净。它没有重写射击逻辑，也没有改子弹方向算法，而是先追踪子弹的出生点，确认问题来自玩家场景里的Muzzle节点。随后它检查坐标，发现Muzzle原本位于三角形尖角外侧，于是只把这个节点移动到三角形的几何中心。

数值优化

接下来，测试从“代码能不能跑”推进到“游戏好不好玩”。

这一轮要求模型做数值平衡和节奏优化：让玩家前 30 秒能上手，30 秒后压力逐步增加，90 秒左右进入高压状态。它要调整敌人生成频率、敌人比例、玩家速度、射速、子弹速度、掉落概率，也要补上受击、收集、死亡反馈。

这一步看的不是写代码能力，而是产品判断。

一个可玩的生存射击，需要让玩家知道危险从哪来、什么时候变强、为什么要冒险去捡资源。

HY3 在做真正的产品调参：它把敌人生成间隔从 1.7 秒逐步压到 0.45 秒，并安排冲刺敌、重型敌分阶段出现，让前 30 秒上手、90 秒后进入高压。

它还给出每个数值调整的理由，比如提高玩家移速、射速和子弹速度，是为了降低开局崩盘感、提升打击跟手度；重型敌掉落更多灵感碎片，则是让高风险目标有更高收益。

从实际体验来看，的确有变化，但还需要有经验的数值策划师策划下。

宣发物料

游戏完成后，我们继续把任务推进到宣发环节。HY3 需要基于已经实现的《NeonDeadline》生成 PPT、Word 媒体资料包、官网 HTML、短视频脚本和社媒文案。

在宣发材料生成环节，HY3 没有停留在“写一篇宣传稿”的层面，而是围绕同一个游戏项目，连续生成了上线汇报 PPT、媒体资料包、官网 HTML、短视频脚本和社媒文案。

而且，这几份材料虽然面向不同场景，但基本保持了同一套功能口径，没有出现 PPT 说一套、官网说一套、社媒再夸大一套的情况。

可以认为，HY3 已经具备一定的“口径管理”能力。它不只是把内容写得好看，而是能在多份交付物之间维持事实边界。在设计方面，PPT 和网页还统一了视觉。

但这套交付物也暴露出一个细节问题，在 Word 文档中，部分中文内容出现了字体兼容或排版不稳定的情况。

简单说，这条游戏测试不是只看 HY3 会不会写代码，而是把它放进一个连续项目里，看它能不能从策划、技术拆解、工程生成、Bug 修复、版本迭代，一直做到数值调优和宣发材料交付。

前半段测的是 Coding 能力和长程执行，后半段测的是 WorkAgent 能力和多文件一致性。HY3 不是每一步都完美，过程中也会出错，但它能很容易把项目往下推进。

这次测试之后，我对 HY3 的判断不是“惊艳”，而是“终于像一块能用来干活的底座了”。

它当然还不完美。第一次生成 Godot 项目时，玩家一开枪就报错，后面生成 Word 资料包时，中文字体和排版也有细节问题。

但更值得注意的是另一面：HY3 没有卡死在错误里，用户只需要简单指令，它就能继续推进任务。

报错给它，它能沿着调用栈往回找；玩法不对，它能回到碰撞层、节点坐标和生成逻辑里排查；需求追加，它没有推倒重来，而是在原项目上继续加敌人、升级系统和数值曲线。

这才是 Agent 真正难的地方。不是在一次对话里给出一个漂亮答案，而是在一个连续项目里不断接收反馈、修正错误、维护上下文，把事情一段一段往前推。

对腾讯来说，HY3 的价值也在这里。

腾讯过去最不缺的是入口，腾讯有太多可以接 AI 的场景。真正的问题是，这些入口背后有没有一个足够稳定的模型中枢，能把任务理解、工具调用、代码执行、文件生成和多轮修正串起来。

从这次测试看，HY3 还不能说已经解决了所有问题，但它至少开始接近这个角色。它不是只会聊天的模型，而是能在工程和办公任务里连续推进的模型。

接下来真正要看的，是 HY3 能不能成为这些入口背后的默认智能。元宝、ima、WorkBuddy 需要的不是一个偶尔答得很好的模型，而是一个能反复接住真实任务、真实反馈和真实错误的执行中枢。

如果 HY3 能在这些产品里持续稳定地工作，腾讯就不必再羡慕别人家的模型。

点个“爱心”，再走吧