作者 ｜ 董道力 微信｜ ddl941110

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

根据官方技术文档，焦虑Hy3采用混合专家（MoE）架构，游戏总参数量达295B，后看缓缓激活参数为21B，腾讯支持256K超长上下文窗口，正式是版用一款融合“快思考”与“慢思考”能力的模型。相较于4月发布的焦虑Hy3 Preview版，正式版在复杂逻辑推理、游戏指令遵循、后看缓缓上下文学习、腾讯代码生成及Agent自主智能体能力上均有显著跃升，正式同时稳定性和性价比进一步优化。版用

腾讯官方指出，焦虑Hy3已展现出显著优于同尺寸模型、并能比肩参数规模为其2至5倍的旗舰级模型的智能水平。

目前，Hy3已全面接入腾讯内部AI产品矩阵。WorkBuddy、CodeBuddy、元宝、Marvis、ima等核心业务线均已接入该模型，API服务也已同步上线腾讯云TokenHub。

此前在与腾讯集团高级副总裁汤道生对话时，混元负责人姚顺雨透露了一个关键细节：在元宝（Yuanbao）早期阶段，混元团队曾派出后训练阶段最精锐的骨干力量，优先协助元宝适配DeepSeek模型。

这一细节颇具深意。一方面，它折射出腾讯务实的产品策略：在AI落地初期，谁能解决实际问题，就先采用谁的技术；另一方面，这也侧面反映出，在那个阶段，混元自身的底层底座尚未完全成熟，尚不具备独立支撑所有场景的能力。

这也解释了为何过去两年，腾讯在AI领域的给外界留下了复杂且矛盾的观感。

很难说腾讯动作迟缓，元宝、ima、WorkBuddy、Marvis等产品几乎覆盖了腾讯所有的关键流量入口。

但矛盾点也正在于此：应用层越热闹，基础大模型能力的短板就越发凸显。

腾讯不缺流量入口，也不缺应用场景。它真正稀缺的，是一个能够统一调度、稳定支撑这些庞大入口的模型中枢。

那么，Hy3正式版的实际表现究竟如何？它能否胜任腾讯众多AI产品的基座角色？

我们第一时间对Hy3进行了深度上手测试。

1. 从零构建一款游戏：Hy3的工程化能力实测

为了更贴近真实开发场景，我们设计了一条涵盖游戏策划、技术拆解、代码生成、Bug修复、版本迭代及宣发物料生成的完整测试链路。

测试起点是一个极简的游戏概念：玩家扮演一名AI媒体编辑，在霓虹风格的虚拟编辑部中，躲避不断涌来的“选题焦虑怪”，通过移动、射击、收集灵感碎片来延长生存时间。游戏暂定名为《Neon Deadline》。

该设定虽简单，但完整覆盖了小游戏从策划到开发再到宣发的核心环节。

第一阶段：从概念到可执行策划案

首先，我们要求模型将概念扩展为一份可执行的游戏策划案。模型需定义核心玩法、目标用户、操作逻辑、敌人类型、成长系统、UI设计及第一版MVP（最小可行性产品）范围。

此处考察的核心并非想象力，而是收敛能力。模型需明确第一版的核心要素：移动、射击、刷怪、掉落、计分、死亡判定及重开机制。

测试结果：
Hy3将《Neon Deadline》拆解为一份结构完整的MVP方案，涵盖了核心循环、玩家操作、敌人设计、道具成长、美术风格、UI布局及开发优先级。

值得注意的是，Hy3已将玩法设计与Godot引擎的实现逻辑进行了关联。例如，它明确指定玩家使用CharacterBody2D，子弹使用Area2D，敌人抽象为Enemy基类，难度曲线由Timer和时间系数驱动，霓虹特效则调用Godot内置的Glow和粒子系统。

这并非单纯的创意发散，而是具备工程意识的策划。然而，问题也随之显现：尽管Hy3强调MVP原则，但在实际输出中仍塞入了部分非核心功能，表现出模型常见的“范围扩张”倾向。

结论：Hy3在“创意转方案”方面表现优异，但在“控制第一版范围”上仍有改进空间。这对应了Agent规划能力中的一个关键痛点：难的不是制定计划，而是知道哪些功能在现阶段不该做。

第二阶段：Godot 4.x 技术方案拆解

第二步，我们要求模型基于策划案输出Godot 4.x的技术方案。此环节旨在检验模型是否真正理解游戏开发工程，而非仅生成泛泛的项目计划。

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

测试结果：
Hy3的表现远超普通模型，展现出类似资深Godot工程师的思维。它未停留在“做玩家、做敌人、做UI”的表层规划，而是深入到了Node2D、CharacterBody2D、Area2D、CanvasLayer、Timer、Camera2D等具体节点层面，并给出了详尽的项目目录、场景职责、脚本职责及碰撞层设计方案。

例如，它主动将GameManager设计为autoload单例，负责全局状态、分数、难度及事件广播，从而避免其他脚本通过硬编码查找节点，提升了代码的解耦性。

结论：Hy3已脱离抽象规划，进入具体的工程语境。它清楚Godot项目中易出错的细节，并给出了符合最佳实践的解决方案。

第三阶段：从0到1代码生成与工程自检

第三步进入核心开发环节。我们要求模型生成完整的Godot项目代码，而非零散的代码片段。

在此环节，Hy3展现了明显的工程自检意识。它未简单照搬上一轮方案，而是在生成代码前主动进行了几处逻辑优化：
1. 将接触伤害检测从area_entered调整为body_entered，以提高物理碰撞的准确性；
2. 补全玩家HurtArea的mask，确保能正确识别pickup层；
3. 将全局暂停逻辑改为“状态标志+Timer暂停”的软暂停机制，避免逻辑冲突。

Hy3尝试运行Godot Headless模式进行验证。首次遇到严格类型推断和class_name注册问题时，它未跳过错误，而是继续修改类型声明和跨脚本依赖，最终采用更保守的类型调用方式，并声称Main场景运行2秒无运行时错误。

实际运行反馈：
尽管编译通过，但实际运行中仍存在Bug。例如，玩家射击时，bullet.gd在setup()函数中试图访问不存在的视觉节点，导致Nil.color报错。

分析：Hy3的自动验证尚未覆盖核心交互路径（如玩家射击）。编译通过和场景启动仅是起点，不代表游戏逻辑闭环成立。

Debug能力：从修复过程看，Hy3具备有效的Debug能力。它能根据调用栈定位问题，并在原项目基础上进行修复，而非推倒重来。

试玩体验：游戏雏形已现。包含血条、技能条、玩家控制的小三角射击、击毁敌人后获得能量、能量满值进化子弹技能等核心要素。

第四阶段：版本迭代与增量开发

此阶段追加版本迭代需求，专门测试模型在已有项目基础上的增量开发能力。

需求：
1. 新增三种敌人：
* 普通敌人：速度中等，血量1。
* 冲刺敌人：速度快，血量1。
* 重型敌人：速度慢，血量3。
2. 升级系统：玩家每收集10个灵感碎片，暂停游戏，从“提升射速”、“提升移速”、“子弹穿透+1”三选一进行升级，选择后继续游戏。

测试目的：真实项目极少一次性从零生成，更多时候是产品经理不断追加需求，工程师需在原有代码结构上扩展，而非重写。

测试结果：
Hy3准确理解了“升级系统”背后的工程依赖。它意识到三选一升级不仅是UI弹窗，更牵动GameManager的状态机逻辑。

令人惊喜的是，Hy3一次性完成迭代，未出现Bug。在原始版本基础上，成功增加了三种不同属性的敌人及三个技能选项，且效果与描述完全一致。

细节优化：
我们还测试了一个细微的体验Bug：子弹最初从三角形角色的尖角（非几何中心）飞出，影响手感。
Hy3的处理路径非常干净：未重写射击逻辑，而是追踪子弹出生点，定位到玩家场景中的Muzzle节点。检查坐标后发现Muzzle位于尖角外侧，遂将该节点移动至三角形几何中心。

第五阶段：数值平衡与节奏优化

测试从“代码能跑”推进到“游戏好玩”。

需求：
优化数值平衡与节奏：前30秒上手，30秒后压力递增，90秒进入高压状态。调整敌人生成频率、比例、玩家速度、射速、子弹速度、掉落概率，并补全受击、收集、死亡反馈。

测试目的：考察模型的产品判断力，而非单纯编码能力。

测试结果：
Hy3进行了真正的产品调参：
* 将敌人生成间隔从1.7秒逐步压缩至0.45秒。
* 安排冲刺敌和重型敌分阶段出现，确保前30秒新手友好，90秒后高压挑战。
* 提供数值调整理由：提高玩家移速、射速和子弹速度，旨在降低开局挫败感，提升打击跟手度；重型敌掉落更多灵感碎片，以匹配其高风险高收益特性。

体验反馈：游戏节奏确有改善，但距离专业数值策划的精细化调优仍有差距，需人工介入微调。

第六阶段：宣发物料生成与口径管理

游戏完成后，任务推进至宣发环节。Hy3需基于已实现的《Neon Deadline》生成全套上线宣发材料。

约束条件：
* 仅基于已实现功能撰写，严禁宣传未实现功能（如Boss战、剧情、多人模式等）。
* 不确定信息需标注“当前资料不足”，禁止编造。
* 已知信息包括：游戏名、类型、设定、核心玩法、已实现系统（移动、射击、三种敌人、升级三选一、基础UI等）、技术栈（Godot 4.x，零外部美术资源）、已修复Bug列表。

交付物要求：
1. PPT：内部上线汇报（10页以内），结构清晰，风格务实，严禁夸大。
2. Word：媒体资料包，含简介、玩法、背景、功能清单、操作、报道角度、Q&A、风险说明。
3. HTML：官网单页，暗色霓虹风格，适配多端，无外部依赖。
4. 短视频脚本：60秒，B站/抖音/小红书通用，含画面、旁白、字幕、节奏、引导。
5. 社媒文案：5条，分别面向独立游戏玩家、AI从业者、媒体人、Godot开发者、休闲玩家。
6. 自检：确保多文件功能口径一致，无未实现功能，HTML可直接打开。

测试结果：
在宣发环节，Hy3未止步于单篇宣传稿，而是围绕同一项目连续生成了PPT、Word、HTML、视频脚本及社媒文案。

关键亮点：
尽管面向不同场景，但多份材料保持了高度一致的功能口径。未出现PPT、官网、社媒说法不一或夸大宣传的情况。

这表明Hy3已具备初步的“口径管理能力”。它不仅关注内容美观，更能维持多交付物间的事实边界。在视觉设计上，PPT和网页也保持了统一的暗色霓虹风格。

暴露问题：
Word文档中部分中文内容出现字体兼容或排版不稳定现象。

总结：
本次测试并非仅考察Hy3的Coding能力，而是将其置于连续项目流中，检验其从策划、技术拆解、工程生成、Bug修复、版本迭代，到数值调优及宣发交付的全链路能力。

前半段测试Coding与长程执行，后半段测试WorkAgent与多文件一致性。Hy3虽非完美，过程中亦有错误，但其具备将项目持续向前推进的能力。

2. 有了Hy3，腾讯还需羡慕别人吗？

经过此次测试，我对Hy3的评价并非“惊艳”，而是“终于像一块能用来干活的底座”。

它当然不完美。首次生成Godot项目时，玩家射击即报错；生成Word资料包时，中文字体排版存在细节瑕疵。

但更值得关注的是其韧性：Hy3未因错误而卡死。用户只需简单指令，它便能继续推进任务。
* 报错时，它能沿调用栈回溯定位；
* 玩法异常时，它能深入碰撞层、节点坐标及生成逻辑排查；
* 需求追加时，它未推倒重来，而是在原项目上增量开发敌人、升级系统及数值曲线。

这才是Agent真正的难点：不是在一次对话中给出完美答案，而是在连续项目中不断接收反馈、修正错误、维护上下文，将任务分段推进。

对腾讯而言，Hy3的价值正在于此。

腾讯过去最不缺的是入口，拥有海量AI应用场景。真正的瓶颈在于，这些入口背后是否有一个足够稳定的模型中枢，能将任务理解、工具调用、代码执行、文件生成及多轮修正串联起来。

从本次测试来看，Hy3虽未解决所有问题，但已接近这一角色。它不再是只会聊天的模型，而是能在工程和办公任务中连续推进的执行者。

接下来，关键在于Hy3能否成为这些入口背后的默认智能。元宝、ima、WorkBuddy等所需，并非偶尔答得好的模型，而是能反复接住真实任务、真实反馈及真实错误的执行中枢。

若Hy3能在这些产品中持续稳定工作，腾讯便无需再羡慕其他公司的模型能力。

点个 “ 爱心 ” ，再走吧