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产品的基座？

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

用HY3从0做一款游戏

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

测试从一个很小的游戏概念开始：玩家是一名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需要基于已经实现的《Neon Deadline》生成PPT、Word媒体资料包、正式HTML、短视频脚本和社媒文案。

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

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

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

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

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

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

有了HY3，腾讯还会羡慕别人吗？

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

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

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

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

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

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

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

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

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