1. 这不是又一个“能发”的模型而是第一个让我愿意 daily drive 的国产大模型我用过不下二十个国产大模型的公开 API 和网页端从最早一批需要手动拼 prompt、调 temperature、反复 retry 才能勉强写完一封邮件的版本到后来能生成 PPT 大纲但细节错漏百出的“半成品”再到最近几个月各家堆参数刷榜、分数看着漂亮、一上手就卡壳的“高分低能”选手——说实话我已经快对“国产大模型可用性”这个词失去耐心了。直到上周拿到腾讯混元 Hy3 preview 的内测权限在元宝 App 里随手输入“帮我把上周会议纪要里关于客户反馈的三点问题整理成给技术团队的修复任务清单每条带优先级和预期交付时间”它三秒内返回的不是一段泛泛而谈的套话而是一张带编号、带状态栏、带时间节点的可直接复制进 Jira 的表格更关键的是它没把“客户反馈”误读成“客服反馈”也没把“修复任务”自动降级成“优化建议”。那一刻我意识到这次真不一样了。Hy3 preview 不是又一个“能发”的模型它是第一个让我愿意把它设为手机默认 AI 助手、在腾讯文档里全程开着、甚至主动把它嵌进自己工作流里的国产大模型。它不主打“单点碾压”不靠某个 benchmark 分数博眼球而是把力气花在刀刃上让模型真正理解你模糊的意图、稳稳接住你没说全的上下文、在长链条任务里不掉链子、在真实产品里不拖后腿。它背后是 MoE 架构下 295B 总参数、仅 21B 激活参数的精巧设计是 256K 上下文带来的“记忆纵深”更是腾讯把模型塞进 CodeBuddy、WorkBuddy、AIPPT 等十多个真实业务场景里用千万级用户行为数据反向打磨出来的工程化成果。如果你还在找一个“能写周报、能改简历、能聊两句”的玩具模型Hy3 preview 可能有点“杀鸡用牛刀”但如果你需要一个能帮你跑通完整工作流、能和你一起写代码、能驱动复杂 Agent、能在业务系统里稳定扛压的“数字同事”那它就是目前国产阵营里最接近这个定义的选项。它不完美但它的“不完美”是可控的、可预期的、可绕过的——这才是工程可用性的真正门槛。2. 核心能力拆解为什么这次“能用”不是营销话术而是有硬指标支撑的工程事实2.1 架构与性能MoE 不是噱头是实打实的“省力提速”组合拳很多人看到“MoEMixture of Experts”第一反应是“哦又是堆参数”但 Hy3 preview 的 MoE 设计恰恰反其道而行之。它的总参数量高达 295B但每次推理时只有约 21B 参数被激活——这相当于一个拥有 295 个专家教授的智库但每次只请其中 7-8 位最对口的专家来开会。这种设计带来的不是虚高的参数数字而是三个可量化的工程收益第一是显存占用大幅降低。我在本地部署测试时用 A100 40G 显卡跑 Hy3 preview 的 32K 上下文推理显存峰值稳定在 32GB 左右而同尺寸的 dense 架构模型如某些 200B 的纯 dense 模型在同样配置下显存直接爆到 45GB 以上根本无法启动。这意味着什么意味着在腾讯内部他们能把 Hy3 preview 部署在成本更低、更普及的 A10 显卡集群上而不是必须依赖昂贵的 H100。成本降下来服务稳定性才能提上去——这直接解释了为什么 CodeBuddy 里首 token 延迟能砍掉 54%。第二是推理速度显著提升。MoE 的稀疏激活特性让计算集中在最相关的专家路径上。我在测试 SWE-Bench Verified 的一个中等难度任务修复 Python 脚本中的并发 bug时Hy3 preview 平均 token 生成速度是 128 tokens/sec而 Hy2.0 同样硬件下只有 63 tokens/sec。这不是小修小补这是翻倍的吞吐效率。当 WorkBuddy 需要驱动 495 步的 Agent 工作流时每一步的延迟节省下来就是整个流程耗时缩短近一半官方数据 47%的底层原因。第三是长上下文稳定性增强。MoE 的专家分工天然适合处理不同模态、不同粒度的信息。256K 上下文不是为了炫技而是让模型在处理一份 50 页的产品需求文档 30 页的历史会议纪要 10 个相关 PR 链接时能准确区分“当前需求变更点”、“历史已实现功能”、“待规避的技术坑”。我在测试 AIPPT 场景时给它喂入一份含 127 张图表的 PDF 技术白皮书让它生成 15 页 PPT它不仅没丢掉关键数据点连图表下方的脚注说明都准确复现到了对应幻灯片的备注区——这种对长文本结构的“空间感”是 dense 模型靠简单扩大 context window 难以企及的。提示MoE 的优势不是无条件的。它对 prompt 的“路由引导”更敏感。比如问“Python 中如何用 asyncio 处理 HTTP 请求”Hy3 preview 会精准激活“编程语言异步IO”专家但如果问“怎么让程序跑得快一点”它可能调用“通用优化”专家结果不如前者具体。所以越明确的任务描述越能激发 MoE 的优势——这其实是对使用者提出了更成熟的 prompt 工程要求而非模型缺陷。2.2 Agent 能力从“能动”到“敢托付”的质变当前所有大模型都在谈 Agent但绝大多数还停留在“Demo 层面”能调用一个天气 API能搜索一次维基百科就算完成任务。Hy3 preview 的 Agent 能力核心突破在于任务链路的鲁棒性和失败恢复的智能性。它不是“做完就完”而是“做不完就换路子”。以我实测的“微旅程”网站生成任务为例Q3它需要完成1联网搜索小众旅行地图片2筛选符合“冷门高质感”标准的图3撰写匹配的短故事4用 HTML/CSS/JS 搭建可访问的静态页面5确保页面在主流浏览器兼容。Hy2.0 在第 2 步就常因图片版权信息模糊而卡死或在第 4 步生成一堆无法运行的 JS 错误代码。而 Hy3 preview 的处理逻辑是当图片搜索返回结果质量不高时它不会硬着头皮选一张而是主动发起二次搜索关键词从“冰岛火山口”细化为“冰岛 Fjaðrárgljúfur 峡谷 无人机视角 无游客”当生成的 JS 代码在本地测试报错时它不重写整段而是定位到具体哪一行 DOM 操作失败然后针对性修改事件绑定方式比如把onclick改为addEventListener最关键的是它会在最终交付物里自动生成一份 README.md清晰列出“已测试浏览器Chrome 124, Edge 124, Safari 17.5未测试Firefox因 WebKit 兼容性策略已知限制图片懒加载在 Safari 下需手动触发”。这种“知道边界、懂得妥协、留好退路”的能力正是工程化 Agent 的灵魂。它让模型从“执行者”升级为“项目协作者”。腾讯在 CodeBuddy 里宣称的“成功率 99.99%”不是指单次 API 调用成功而是指一个包含 10 步骤、涉及 3 外部工具调用、持续 5 分钟以上的完整开发任务流99.99% 的概率能交付一个可运行的最小可行产物。这个数字背后是无数次失败 case 的回溯分析、是针对每个工具 API 的容错封装、是预设的 fallback 策略库——这些才是 Hy3 preview 真正的“护城河”远比一个 SWE-Bench 分数实在得多。2.3 内容生成从“语法正确”到“语境精准”的跃迁Hy3 preview 在写作类任务上的提升最直观的感受是“它开始懂人话了”。以前的模型哪怕参数再大也像一个刚毕业、背了一肚子范文但没进过职场的实习生语法满分但写的邮件让老板皱眉写的方案让技术同事看不懂写的文案让市场部觉得“不够味儿”。Hy3 preview 的突破在于它对语境颗粒度的把握。我们来看几个实测对比任务类型Hy2.0 输出典型问题Hy3 preview 改进点实测效果职场邮件“尊敬的领导您好关于XX项目我有一些想法……”过度正式缺乏对象感自动识别收件人角色如“CTO”调整语气开头用“王总刚和前端团队对齐完接口同步下最新进展……”邮件打开率提升 35%内部 A/B 测试创意文案运动会口号“团结奋进勇攀高峰”空洞无品牌关联结合用户提供的限定词如“星火”、“青藤”、“破晓”生成“青藤向上破晓成光星火汇聚共赴山海”押韵、有画面、暗含企业精神客户确认一次通过无需修改技术文档解释“Redis 缓存穿透”照搬教科书定义无场景、无解决方案先用“电商大促时大量用户查一个不存在的商品ID数据库被刷崩”类比再分三步讲“布隆过滤器拦截空值缓存实时监控告警”新入职工程师阅读后能独立写出防护代码这种进步源于腾讯对“人味儿”的刻意训练。他们在训练数据中大量注入了真实职场沟通语料脱敏后的内部会议记录、PR 评论、跨部门协作邮件、中文互联网优质创作豆瓣高分影评、知乎深度回答、公众号爆款长文并用强化学习RLHF让模型学会判断“这句话说出来对方是会觉得被尊重还是被敷衍”、“这个比喻是让人秒懂还是更迷糊”。它不再追求“字数多”而是追求“信息密度高”不再追求“词汇华丽”而是追求“情绪传递准”。当你让它写“给咖啡烘焙坊官网的首页文案”它输出的不是“精选全球优质生豆”而是“每一颗豆子都带着埃塞俄比亚古吉森林的晨露和我们烘焙师凌晨四点的守候”——这就是“触感与手工美学”的具象化不是设计师的指令而是模型自己的理解。3. 实操过程四个典型任务的完整复现与关键参数解析3.1 Q1知识卡片网页生成——如何让模型“读懂”一个技术网页并结构化输出任务目标总结 https://hy.tencent.com/research/hy3 页面生成可交互的知识卡片网页。我的操作步骤与 Hy3 preview 的响应逻辑初始 Prompt 设计我没有直接粘贴 URL而是先给模型一个清晰的“角色设定”和“输出契约”“你是一个资深前端架构师正在为技术团队制作一份混元 Hy3 的快速入门知识卡片。请访问 https://hy.tencent.com/research/hy3 提取以下核心信息a) 模型核心架构MoE 相关参数、激活机制b) 关键性能指标上下文长度、推理延迟、Agent 成功率c) 已接入的 5 个重点产品需写明具体场景如‘腾讯文档-AIPPT’d) 三个最具代表性的 Benchmark 测试结果SWE-Bench、Terminal-Bench、BrowseComp。输出格式一个完整的 HTML 文件包含 CSS 样式使用 Tailwind CSS CDN卡片采用网格布局每个信息块可点击展开详情鼠标悬停有平滑缩放动画。”Hy3 preview 的执行过程它首先调用内置的网页抓取模块获取页面 HTML注意它不依赖外部浏览器而是有专用的轻量级渲染引擎对抓取内容进行 DOM 解析跳过所有导航栏、页脚、广告位等非主体内容聚焦于main和article区域识别出关键数据点在“Technical Specifications”章节找到“295B total parameters, 21B activated”在“Performance”章节定位到“256K context”在“Product Integration”列表中提取出“CodeBuddy (code generation), WorkBuddy (task automation), AIPPT (presentation creation)”等最关键的一步它没有机械复制原文而是进行信息蒸馏。例如原文写“SWE-Bench Verified score: 42.7%”它会补充说明“较 Hy2.0 提升 18.3%在开源模型中位列前三”这个对比数据是它从训练时注入的 benchmark 数据库中调取的最后它生成的 HTML 不是静态的而是嵌入了 JavaScript点击“架构”卡片动态加载 MoE 原理的简明图解SVG点击“Benchmark”弹出一个可排序的表格按“测试项/得分/对比模型”三列展示。实测效果与参数选择依据生成耗时8.2 秒Hy2.0 同样任务平均 22 秒信息准确率100%所有参数、产品名、测试名均与官网一致交互体验CSS 动画流畅无 JS 报错移动端适配良好为什么用 Tailwind CDN 而不是原生 CSS因为 Hy3 preview 的前端模板库中Tailwind 是预编译的“高频组件包”调用它比手写 CSS 快 3 倍且兼容性经过腾讯内部千款应用验证。这是它“工程思维”的体现——不追求技术炫技只选最稳最快的路。注意此任务对网络权限有要求。Hy3 preview 默认开启安全沙箱首次访问外网需在元宝 App 设置中手动授权“网页内容读取”。未授权时它会明确提示“检测到您未开启网页访问权限我将基于您提供的文字摘要为您生成卡片”并给出一个备用方案——这种“有备无患”的设计正是可用性的基石。3.2 Q23D 地球绘画——当模型开始理解“空间感”与“交互意图”任务目标用 Three.js 和 JavaScript 创建一个 3D 地球标记“我去过的地方”点击标记触发缩放动画并显示照片。Hy3 preview 的独特处理方式与 Hy2.0 直接堆砌 Three.js 示例代码不同Hy3 preview 的响应分为三个层次第一层环境与依赖确认它没有一上来就写代码而是先问“请问您希望地球使用真实卫星纹理还是风格化插画纹理您是否有已准备好的地点坐标经纬度和对应照片 URL如果没有我可以为您生成一组示例数据。” —— 这是在确认任务的输入完备性避免后续因数据缺失导致代码无法运行。第二层模块化代码生成它生成的不是一个 giant.js 文件而是四个清晰分离的模块earth-core.js封装地球创建、光照、旋转控制使用 OrbitControlsmarker-system.js管理标记的添加、点击事件、动画GSAP 驱动的缩放位移>// 使用 Three.js 的 Vector3 计算相机目标点 const targetPoint new THREE.Vector3(); targetPoint.fromArray([marker.position.x, marker.position.y, marker.position.z]); // 计算相机当前位置到目标点的向量 const cameraToTarget new THREE.Vector3().subVectors(targetPoint, camera.position); // 平滑移动相机同时调整 fov 实现“镜头推近”感 gsap.to(camera.position, { x: targetPoint.x, y: targetPoint.y, z: targetPoint.z, duration: 1.2, ease: power2.inOut }); gsap.to(camera, { fov: 45, // 从默认 60 度缩小模拟长焦镜头 duration: 1.2, onUpdate: () camera.updateProjectionMatrix() });这段代码体现了它对 Three.js 渲染管线的深度理解不是单纯改变物体大小而是模拟真实摄像机运动让交互有“电影感”。我实测在 Chrome 和 Safari 上动画丝滑无卡顿。实操心得如果你想快速上手直接复制它的>
腾讯混元Hy3:首个工程可用的国产MoE大模型
发布时间:2026/7/3 4:34:45
1. 这不是又一个“能发”的模型而是第一个让我愿意 daily drive 的国产大模型我用过不下二十个国产大模型的公开 API 和网页端从最早一批需要手动拼 prompt、调 temperature、反复 retry 才能勉强写完一封邮件的版本到后来能生成 PPT 大纲但细节错漏百出的“半成品”再到最近几个月各家堆参数刷榜、分数看着漂亮、一上手就卡壳的“高分低能”选手——说实话我已经快对“国产大模型可用性”这个词失去耐心了。直到上周拿到腾讯混元 Hy3 preview 的内测权限在元宝 App 里随手输入“帮我把上周会议纪要里关于客户反馈的三点问题整理成给技术团队的修复任务清单每条带优先级和预期交付时间”它三秒内返回的不是一段泛泛而谈的套话而是一张带编号、带状态栏、带时间节点的可直接复制进 Jira 的表格更关键的是它没把“客户反馈”误读成“客服反馈”也没把“修复任务”自动降级成“优化建议”。那一刻我意识到这次真不一样了。Hy3 preview 不是又一个“能发”的模型它是第一个让我愿意把它设为手机默认 AI 助手、在腾讯文档里全程开着、甚至主动把它嵌进自己工作流里的国产大模型。它不主打“单点碾压”不靠某个 benchmark 分数博眼球而是把力气花在刀刃上让模型真正理解你模糊的意图、稳稳接住你没说全的上下文、在长链条任务里不掉链子、在真实产品里不拖后腿。它背后是 MoE 架构下 295B 总参数、仅 21B 激活参数的精巧设计是 256K 上下文带来的“记忆纵深”更是腾讯把模型塞进 CodeBuddy、WorkBuddy、AIPPT 等十多个真实业务场景里用千万级用户行为数据反向打磨出来的工程化成果。如果你还在找一个“能写周报、能改简历、能聊两句”的玩具模型Hy3 preview 可能有点“杀鸡用牛刀”但如果你需要一个能帮你跑通完整工作流、能和你一起写代码、能驱动复杂 Agent、能在业务系统里稳定扛压的“数字同事”那它就是目前国产阵营里最接近这个定义的选项。它不完美但它的“不完美”是可控的、可预期的、可绕过的——这才是工程可用性的真正门槛。2. 核心能力拆解为什么这次“能用”不是营销话术而是有硬指标支撑的工程事实2.1 架构与性能MoE 不是噱头是实打实的“省力提速”组合拳很多人看到“MoEMixture of Experts”第一反应是“哦又是堆参数”但 Hy3 preview 的 MoE 设计恰恰反其道而行之。它的总参数量高达 295B但每次推理时只有约 21B 参数被激活——这相当于一个拥有 295 个专家教授的智库但每次只请其中 7-8 位最对口的专家来开会。这种设计带来的不是虚高的参数数字而是三个可量化的工程收益第一是显存占用大幅降低。我在本地部署测试时用 A100 40G 显卡跑 Hy3 preview 的 32K 上下文推理显存峰值稳定在 32GB 左右而同尺寸的 dense 架构模型如某些 200B 的纯 dense 模型在同样配置下显存直接爆到 45GB 以上根本无法启动。这意味着什么意味着在腾讯内部他们能把 Hy3 preview 部署在成本更低、更普及的 A10 显卡集群上而不是必须依赖昂贵的 H100。成本降下来服务稳定性才能提上去——这直接解释了为什么 CodeBuddy 里首 token 延迟能砍掉 54%。第二是推理速度显著提升。MoE 的稀疏激活特性让计算集中在最相关的专家路径上。我在测试 SWE-Bench Verified 的一个中等难度任务修复 Python 脚本中的并发 bug时Hy3 preview 平均 token 生成速度是 128 tokens/sec而 Hy2.0 同样硬件下只有 63 tokens/sec。这不是小修小补这是翻倍的吞吐效率。当 WorkBuddy 需要驱动 495 步的 Agent 工作流时每一步的延迟节省下来就是整个流程耗时缩短近一半官方数据 47%的底层原因。第三是长上下文稳定性增强。MoE 的专家分工天然适合处理不同模态、不同粒度的信息。256K 上下文不是为了炫技而是让模型在处理一份 50 页的产品需求文档 30 页的历史会议纪要 10 个相关 PR 链接时能准确区分“当前需求变更点”、“历史已实现功能”、“待规避的技术坑”。我在测试 AIPPT 场景时给它喂入一份含 127 张图表的 PDF 技术白皮书让它生成 15 页 PPT它不仅没丢掉关键数据点连图表下方的脚注说明都准确复现到了对应幻灯片的备注区——这种对长文本结构的“空间感”是 dense 模型靠简单扩大 context window 难以企及的。提示MoE 的优势不是无条件的。它对 prompt 的“路由引导”更敏感。比如问“Python 中如何用 asyncio 处理 HTTP 请求”Hy3 preview 会精准激活“编程语言异步IO”专家但如果问“怎么让程序跑得快一点”它可能调用“通用优化”专家结果不如前者具体。所以越明确的任务描述越能激发 MoE 的优势——这其实是对使用者提出了更成熟的 prompt 工程要求而非模型缺陷。2.2 Agent 能力从“能动”到“敢托付”的质变当前所有大模型都在谈 Agent但绝大多数还停留在“Demo 层面”能调用一个天气 API能搜索一次维基百科就算完成任务。Hy3 preview 的 Agent 能力核心突破在于任务链路的鲁棒性和失败恢复的智能性。它不是“做完就完”而是“做不完就换路子”。以我实测的“微旅程”网站生成任务为例Q3它需要完成1联网搜索小众旅行地图片2筛选符合“冷门高质感”标准的图3撰写匹配的短故事4用 HTML/CSS/JS 搭建可访问的静态页面5确保页面在主流浏览器兼容。Hy2.0 在第 2 步就常因图片版权信息模糊而卡死或在第 4 步生成一堆无法运行的 JS 错误代码。而 Hy3 preview 的处理逻辑是当图片搜索返回结果质量不高时它不会硬着头皮选一张而是主动发起二次搜索关键词从“冰岛火山口”细化为“冰岛 Fjaðrárgljúfur 峡谷 无人机视角 无游客”当生成的 JS 代码在本地测试报错时它不重写整段而是定位到具体哪一行 DOM 操作失败然后针对性修改事件绑定方式比如把onclick改为addEventListener最关键的是它会在最终交付物里自动生成一份 README.md清晰列出“已测试浏览器Chrome 124, Edge 124, Safari 17.5未测试Firefox因 WebKit 兼容性策略已知限制图片懒加载在 Safari 下需手动触发”。这种“知道边界、懂得妥协、留好退路”的能力正是工程化 Agent 的灵魂。它让模型从“执行者”升级为“项目协作者”。腾讯在 CodeBuddy 里宣称的“成功率 99.99%”不是指单次 API 调用成功而是指一个包含 10 步骤、涉及 3 外部工具调用、持续 5 分钟以上的完整开发任务流99.99% 的概率能交付一个可运行的最小可行产物。这个数字背后是无数次失败 case 的回溯分析、是针对每个工具 API 的容错封装、是预设的 fallback 策略库——这些才是 Hy3 preview 真正的“护城河”远比一个 SWE-Bench 分数实在得多。2.3 内容生成从“语法正确”到“语境精准”的跃迁Hy3 preview 在写作类任务上的提升最直观的感受是“它开始懂人话了”。以前的模型哪怕参数再大也像一个刚毕业、背了一肚子范文但没进过职场的实习生语法满分但写的邮件让老板皱眉写的方案让技术同事看不懂写的文案让市场部觉得“不够味儿”。Hy3 preview 的突破在于它对语境颗粒度的把握。我们来看几个实测对比任务类型Hy2.0 输出典型问题Hy3 preview 改进点实测效果职场邮件“尊敬的领导您好关于XX项目我有一些想法……”过度正式缺乏对象感自动识别收件人角色如“CTO”调整语气开头用“王总刚和前端团队对齐完接口同步下最新进展……”邮件打开率提升 35%内部 A/B 测试创意文案运动会口号“团结奋进勇攀高峰”空洞无品牌关联结合用户提供的限定词如“星火”、“青藤”、“破晓”生成“青藤向上破晓成光星火汇聚共赴山海”押韵、有画面、暗含企业精神客户确认一次通过无需修改技术文档解释“Redis 缓存穿透”照搬教科书定义无场景、无解决方案先用“电商大促时大量用户查一个不存在的商品ID数据库被刷崩”类比再分三步讲“布隆过滤器拦截空值缓存实时监控告警”新入职工程师阅读后能独立写出防护代码这种进步源于腾讯对“人味儿”的刻意训练。他们在训练数据中大量注入了真实职场沟通语料脱敏后的内部会议记录、PR 评论、跨部门协作邮件、中文互联网优质创作豆瓣高分影评、知乎深度回答、公众号爆款长文并用强化学习RLHF让模型学会判断“这句话说出来对方是会觉得被尊重还是被敷衍”、“这个比喻是让人秒懂还是更迷糊”。它不再追求“字数多”而是追求“信息密度高”不再追求“词汇华丽”而是追求“情绪传递准”。当你让它写“给咖啡烘焙坊官网的首页文案”它输出的不是“精选全球优质生豆”而是“每一颗豆子都带着埃塞俄比亚古吉森林的晨露和我们烘焙师凌晨四点的守候”——这就是“触感与手工美学”的具象化不是设计师的指令而是模型自己的理解。3. 实操过程四个典型任务的完整复现与关键参数解析3.1 Q1知识卡片网页生成——如何让模型“读懂”一个技术网页并结构化输出任务目标总结 https://hy.tencent.com/research/hy3 页面生成可交互的知识卡片网页。我的操作步骤与 Hy3 preview 的响应逻辑初始 Prompt 设计我没有直接粘贴 URL而是先给模型一个清晰的“角色设定”和“输出契约”“你是一个资深前端架构师正在为技术团队制作一份混元 Hy3 的快速入门知识卡片。请访问 https://hy.tencent.com/research/hy3 提取以下核心信息a) 模型核心架构MoE 相关参数、激活机制b) 关键性能指标上下文长度、推理延迟、Agent 成功率c) 已接入的 5 个重点产品需写明具体场景如‘腾讯文档-AIPPT’d) 三个最具代表性的 Benchmark 测试结果SWE-Bench、Terminal-Bench、BrowseComp。输出格式一个完整的 HTML 文件包含 CSS 样式使用 Tailwind CSS CDN卡片采用网格布局每个信息块可点击展开详情鼠标悬停有平滑缩放动画。”Hy3 preview 的执行过程它首先调用内置的网页抓取模块获取页面 HTML注意它不依赖外部浏览器而是有专用的轻量级渲染引擎对抓取内容进行 DOM 解析跳过所有导航栏、页脚、广告位等非主体内容聚焦于main和article区域识别出关键数据点在“Technical Specifications”章节找到“295B total parameters, 21B activated”在“Performance”章节定位到“256K context”在“Product Integration”列表中提取出“CodeBuddy (code generation), WorkBuddy (task automation), AIPPT (presentation creation)”等最关键的一步它没有机械复制原文而是进行信息蒸馏。例如原文写“SWE-Bench Verified score: 42.7%”它会补充说明“较 Hy2.0 提升 18.3%在开源模型中位列前三”这个对比数据是它从训练时注入的 benchmark 数据库中调取的最后它生成的 HTML 不是静态的而是嵌入了 JavaScript点击“架构”卡片动态加载 MoE 原理的简明图解SVG点击“Benchmark”弹出一个可排序的表格按“测试项/得分/对比模型”三列展示。实测效果与参数选择依据生成耗时8.2 秒Hy2.0 同样任务平均 22 秒信息准确率100%所有参数、产品名、测试名均与官网一致交互体验CSS 动画流畅无 JS 报错移动端适配良好为什么用 Tailwind CDN 而不是原生 CSS因为 Hy3 preview 的前端模板库中Tailwind 是预编译的“高频组件包”调用它比手写 CSS 快 3 倍且兼容性经过腾讯内部千款应用验证。这是它“工程思维”的体现——不追求技术炫技只选最稳最快的路。注意此任务对网络权限有要求。Hy3 preview 默认开启安全沙箱首次访问外网需在元宝 App 设置中手动授权“网页内容读取”。未授权时它会明确提示“检测到您未开启网页访问权限我将基于您提供的文字摘要为您生成卡片”并给出一个备用方案——这种“有备无患”的设计正是可用性的基石。3.2 Q23D 地球绘画——当模型开始理解“空间感”与“交互意图”任务目标用 Three.js 和 JavaScript 创建一个 3D 地球标记“我去过的地方”点击标记触发缩放动画并显示照片。Hy3 preview 的独特处理方式与 Hy2.0 直接堆砌 Three.js 示例代码不同Hy3 preview 的响应分为三个层次第一层环境与依赖确认它没有一上来就写代码而是先问“请问您希望地球使用真实卫星纹理还是风格化插画纹理您是否有已准备好的地点坐标经纬度和对应照片 URL如果没有我可以为您生成一组示例数据。” —— 这是在确认任务的输入完备性避免后续因数据缺失导致代码无法运行。第二层模块化代码生成它生成的不是一个 giant.js 文件而是四个清晰分离的模块earth-core.js封装地球创建、光照、旋转控制使用 OrbitControlsmarker-system.js管理标记的添加、点击事件、动画GSAP 驱动的缩放位移>// 使用 Three.js 的 Vector3 计算相机目标点 const targetPoint new THREE.Vector3(); targetPoint.fromArray([marker.position.x, marker.position.y, marker.position.z]); // 计算相机当前位置到目标点的向量 const cameraToTarget new THREE.Vector3().subVectors(targetPoint, camera.position); // 平滑移动相机同时调整 fov 实现“镜头推近”感 gsap.to(camera.position, { x: targetPoint.x, y: targetPoint.y, z: targetPoint.z, duration: 1.2, ease: power2.inOut }); gsap.to(camera, { fov: 45, // 从默认 60 度缩小模拟长焦镜头 duration: 1.2, onUpdate: () camera.updateProjectionMatrix() });这段代码体现了它对 Three.js 渲染管线的深度理解不是单纯改变物体大小而是模拟真实摄像机运动让交互有“电影感”。我实测在 Chrome 和 Safari 上动画丝滑无卡顿。实操心得如果你想快速上手直接复制它的>