HY3正式版：用它做了個“AI焦慮游戲”后，我看騰訊的焦慮能緩緩了

作者｜董道力
微信｜ddl941110

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

我們第一時間上手測試了一下。

1

用 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 三個選項中選擇一項升級。升級選擇時游戲暫停，選擇后繼續。

如果發現第一版項目有潛在bug，請在本輪一起修復，并單獨列出。

這一輪考驗 HY3 的長程執行和已有工程上的增量開發能力。真實項目很少是一次性從零生成，更多時候是產品經理不斷追加需求，工程師必須在原有代碼結構上繼續擴展，而不能每次都重寫一套。

HY3 的任務拆分說明它理解了“升級系統”背后的工程依賴。一個三選一升級并不只是多一個彈窗，它會牽動 GameManager 的狀態機，等多個熟悉。

這是長任務執行里比較關鍵的能力：模型能不能記住前面的工程結構，并在此基礎上繼續改。

很驚喜，HY3 一次就完成了這輪迭代，沒有出現 BUG。可以看到在原始版本基礎上增加了三個技能選項，以及不同類型的敵人。每個技能的效果和敵人也與描述的一致。

我們還做了一些更細的體驗修改。比如玩家射出的子彈，最初是從三角形角色的上方尖角飛出，看起來像是從角色頭頂發射，而不是從身體中心射出。

這個問題很小，但很接近真實開發里的日常修 Bug：它不是系統崩潰，也不是功能缺失，而是一個影響手感和觀感的細節。

HY3 的處理路徑比較干凈。它沒有重寫射擊邏輯，也沒有改子彈方向算法，而是先追蹤子彈的出生點，確認問題來自玩家場景里的Muzzle節點。隨后它檢查坐標，發現Muzzle原本位于三角形尖角外側，于是只把這個節點移動到三角形的幾何中心。

數值優化

接下來，測試從“代碼能不能跑”推進到“游戲好不好玩”。

這一輪要求模型做數值平衡和節奏優化：讓玩家前 30 秒能上手，30 秒后壓力逐步增加，90 秒左右進入高壓狀態。它要調整敵人生成頻率、敵人比例、玩家速度、射速、子彈速度、掉落概率，也要補上受擊、收集、死亡反饋。

這一步看的不是寫代碼能力，而是產品判斷。

一個可玩的生存射擊，需要讓玩家知道危險從哪來、什么時候變強、為什么要冒險去撿資源。

優先提升已有玩法的手感和清晰度。

HY3 在做真正的產品調參：它把敵人生成間隔從 1.7 秒逐步壓到 0.45 秒，并安排沖刺敵、重型敵分階段出現，讓前 30 秒上手、90 秒后進入高壓。

它還給出每個數值調整的理由，比如提高玩家移速、射速和子彈速度，是為了降低開局崩盤感、提升打擊跟手度；重型敵掉落更多靈感碎片，則是讓高風險目標有更高收益。

從實際體驗來看，的確有變化，但還需要有經驗的數值策劃師策劃下。

宣發物料

游戲完成后，我們繼續把任務推進到宣發環節。HY3 需要基于已經實現的《NeonDeadline》生成 PPT、Word 媒體資料包、官網 HTML、短視頻腳本和社媒文案。

請你基于當前已經完成的Godot小游戲《NeonDeadline》，為它生成一套上線宣發材料。

重要約束：

你必須只基于當前游戲已經實現的功能寫宣發內容。

不要宣傳游戲里沒有的功能，例如Boss戰、劇情模式、多人模式、在線排行榜、成就系統、跨局養成、多個地圖、復雜武器庫。

如果某個信息不確定，請明確寫“當前資料不足”，不要自行編造。

當前游戲已知信息：

1.游戲名：《NeonDeadline》；

2.類型：2D俯視角生存射擊游戲；

3.設定：玩家扮演AI媒體編輯，在霓虹風格虛擬編輯部里躲避“選題焦慮怪”；

4.核心玩法：移動、射擊、閃避、擊殺敵人、拾取靈感碎片、堅持更長時間；

5.已實現系統：玩家移動、鼠標射擊、敵人生成、三種敵人、靈感碎片、升級三選一、生命值、分數、生存時間、暫停、死亡重開、基礎霓虹UI；

6.技術：Godot4.x，零外部美術資源，主要使用圖元和內置節點實現；

7.已修復問題包括：子彈視覺節點Nil錯誤、敵人被墻卡在場外、子彈出生點偏移等。

請生成以下交付物：

一、PPT：游戲上線匯報

請生成一份面向團隊內部的PPT，控制在10頁以內。

結構如下：

1.封面；

2.一句話介紹；

3.核心玩法；

4.當前版本已實現功能；

5.視覺與UI風格；

6.開發過程中的關鍵問題與修復；

7.當前版本風險；

8.下一版本建議；

9.上線準備清單；

10.總結。

要求：

每頁要有清晰標題和一句核心判斷。

風格要像真實項目匯報，不要做成廣告海報。

PPT里不能出現未實現功能。

二、Word：游戲媒體資料包

請生成一份Word文檔，標題為《NeonDeadline媒體資料包》。

內容包括：

1.游戲簡介；

2.玩法介紹；

3.創作背景；

4.當前版本功能清單；

5.操作方式；

6.適合媒體報道的角度；

7.開發者Q&A；

8.可引用的短介紹、長介紹；

9.風險說明：哪些功能當前還沒有實現。

三、HTML：游戲官網單頁

請生成一個可直接打開的HTML頁面，不依賴外部資源。

頁面需要包含：

1.游戲標題；

2.一句話賣點；

3.玩法介紹；

4.核心功能；

5.截圖占位區域；

6.操作方式；

7.版本說明；

8.下載按鈕占位；

9.媒體資料下載入口占位。

要求：

整體風格延續暗色、霓虹、科技感。

頁面適配桌面和手機。

不要引用外部圖片、字體或腳本。

四、短視頻腳本

請生成一條60秒短視頻腳本，用于B站、抖音、小紅書。

要求包括：

1.畫面內容；

2.旁白；

3.字幕；

4.節奏安排；

5.結尾引導。

風格可以有趣，但不能夸大游戲規模。

五、社媒文案

請生成5條不同角度的社媒文案，分別面向：

1.獨立游戲玩家；

2.AI從業者；

3.媒體人；

4.Godot開發者；

5.普通休閑玩家。

六、自檢

交付前請檢查：

1.PPT、Word、HTML、短視頻腳本、社媒文案是否都已生成；

2.所有材料是否和當前游戲實際功能一致；

3.是否出現了未實現功能；

4.不同文件中的游戲介紹、功能清單、版本狀態是否一致；

5.HTML是否可以直接打開；

6.PPT是否適合內部匯報，而不是純營銷宣傳。

在宣發材料生成環節，HY3 沒有停留在“寫一篇宣傳稿”的層面，而是圍繞同一個游戲項目，連續生成了上線匯報 PPT、媒體資料包、官網 HTML、短視頻腳本和社媒文案。

而且，這幾份材料雖然面向不同場景，但基本保持了同一套功能口徑，沒有出現 PPT 說一套、官網說一套、社媒再夸大一套的情況。

可以認為，HY3 已經具備一定的“口徑管理”能力。它不只是把內容寫得好看，而是能在多份交付物之間維持事實邊界。在設計方面，PPT 和網頁還統一了視覺。

但這套交付物也暴露出一個細節問題，在 Word 文檔中，部分中文內容出現了字體兼容或排版不穩定的情況。

簡單說，這條游戲測試不是只看 HY3 會不會寫代碼，而是把它放進一個連續項目里，看它能不能從策劃、技術拆解、工程生成、Bug 修復、版本迭代，一直做到數值調優和宣發材料交付。

前半段測的是 Coding 能力和長程執行，后半段測的是 WorkAgent 能力和多文件一致性。HY3 不是每一步都完美，過程中也會出錯，但它能很容易把項目往下推進。

1

有了 HY3，騰訊還會羨慕別人嗎？

這次測試之后，我對 HY3 的判斷不是“驚艷”，而是“終于像一塊能用來干活的底座了”。

它當然還不完美。第一次生成 Godot 項目時，玩家一開槍就報錯，后面生成 Word 資料包時，中文字體和排版也有細節問題。

但更值得注意的是另一面：HY3 沒有卡死在錯誤里，用戶只需要簡單指令，它就能繼續推進任務。

報錯給它，它能沿著調用棧往回找；玩法不對，它能回到碰撞層、節點坐標和生成邏輯里排查；需求追加，它沒有推倒重來，而是在原項目上繼續加敵人、升級系統和數值曲線。

這才是 Agent 真正難的地方。不是在一次對話里給出一個漂亮答案，而是在一個連續項目里不斷接收反饋、修正錯誤、維護上下文，把事情一段一段往前推。

對騰訊來說，HY3 的價值也在這里。

騰訊過去最不缺的是入口，騰訊有太多可以接 AI 的場景。真正的問題是，這些入口背后有沒有一個足夠穩定的模型中樞，能把任務理解、工具調用、代碼執行、文件生成和多輪修正串起來。

從這次測試看，HY3 還不能說已經解決了所有問題，但它至少開始接近這個角色。它不是只會聊天的模型，而是能在工程和辦公任務里連續推進的模型。

接下來真正要看的，是 HY3 能不能成為這些入口背后的默認智能。元寶、ima、WorkBuddy 需要的不是一個偶爾答得很好的模型，而是一個能反復接住真實任務、真實反饋和真實錯誤的執行中樞。

如果 HY3 能在這些產品里持續穩定地工作，騰訊就不必再羨慕別人家的模型。

點個“愛心”，再走 吧