大家好我是老刘腾讯混元Hy3正式版出来了。参数量只有300B却号称不少领域超过700B级别的模型。公开榜单上的漂亮分数老刘一向不太信。题目公开的测评水分大像LiveBench这种题目不公开的国内厂商提交的也不多目前主要是GLM、Qwen、DeepSeek、Kimi和MiniMax。正好最近不少平台免费开放Hy3试用我就拿自己的Flutter项目实测了一把。简单任务和复杂任务中的表现差距还是挺明显的。先说结论它很适合当flash级模型的升级版但很难替代GLM 5.2这类pro模型当开发主力。1. 简单问题它确实香日常开发里这类任务它基本都能稳稳接住写一个小组件整理一篇文章结构汇总几个表格的数据这种体量的问题Hy3表现很好。准确率高但说实话这个级别的任务大多数flash模型也差不到哪去。真正让使用体验提升的是速度。参数量小响应快你丢过去一个小需求它几乎是秒回。用flash模型时那种「等一等、再改一改」的拖沓感在Hy3上轻了不少。简单任务上Hy3能给你更爽快的使用体验。2. 复杂问题三轮对话才露出真实水平真正能看出模型成色的还是复杂问题。正好老刘在处理一个Flutter路由拼接的bug几十个页面每个页面都有基础名称和固定后缀中间那段path却不统一。大约80%的页面走同一套规则剩下20%各有各的特殊逻辑。规模不大但规则一乱就很容易拼错。我把这个路径拼错的bug直接丢给Hy3看它能不能正确的定位和解决。第一轮准确定位方案考虑不周Hy3自己定位到了问题路由失败就是路径拼错了。全程没有额外提示这一步做得干净。定位速度倒没有简单任务那么惊艳和其他pro级模型差不多。到了修复方案这一步。它找到了那80%页面的通用规则然后直接把这套规则当成了全部答案。剩下20%的特殊页面它当没看见。看起来很聪明其实只学到了大多数。第二轮追求统一算法过度设计我提醒它不是所有页面都遵循同一套规则。它立刻推翻了第一版方案这点值得肯定。但接下来它又钻进了另一个坑试图写一套能覆盖所有路径的统一匹配算法。我很欣赏这种尝试结果却不理想。算法复杂度高后面一旦有新页面加入很容易再出问题。它在追求「一次写完」却没有考虑「以后怎么维护」。第三轮在约束下给出可维护方案我把缺陷点明了要考虑后续新页面接入。同时告诉它源码里有一个类似场景可以参考。又聊了几轮之后它终于给出了我想要的方案默认的基础路径生成算法加自定义路径覆盖的回调。通用逻辑走默认特殊页面走覆盖。既不硬造统一算法也不把80%的规则硬套到100%的页面上。小结Hy3能干具体的执行性工作但去分析复杂问题它需要你提供更多的限制和思路不能完全自己发挥。定位问题可以独立给出可维护方案还差点意思。如果你不把边界条件、后续扩展、参考实现喂清楚它很容易停在看起来能跑的半成品上。3. 怎么用适合什么不适合什么测完之后老刘给它的定位很明确。适合写小组件、改文案、整理结构、汇总表格中低复杂度的日常开发任务对响应速度敏感、想比flash更爽一点的场景不适合规则多、边界多、需要可维护架构的复杂问题指望它独立想清楚业务约束再一次性给出稳妥方案直接替代GLM 5.2这类pro模型当开发主力和常见模型比可以这么理解模型层级定位老刘的用法flash级便宜、够用、偶尔拖沓简单任务(低成本甚至免费)Hy3比flash更快更稳复杂任务仍需带着走flash的升级版GLM 5.2级逻辑更深复杂问题更扛打开发主力成本低、速度快日常工作里完全可以拿它替换一部分flash模型。复杂逻辑、架构设计和需要深入推演的问题还是得交给更强的pro模型。长程多轮任务这次没专门测测过的朋友可以评论区补充。你测过Hy3吗复杂任务上它有没有让你惊喜还是也得你一步步带着走 如果看到这里的同学对客户端或者Flutter开发感兴趣欢迎联系老刘我们互相学习。 私信免费领老刘整理的《Flutter开发手册》覆盖90%应用开发场景。可以作为Flutter学习的知识地图。 : laoliu_dev 老刘也把自己历史文章整理在GitHub仓库里方便大家查阅。 https://github.com/lzt-code/blog
腾讯混元Hy3在Flutter项目中的实战体验
发布时间:2026/7/14 5:22:29
大家好我是老刘腾讯混元Hy3正式版出来了。参数量只有300B却号称不少领域超过700B级别的模型。公开榜单上的漂亮分数老刘一向不太信。题目公开的测评水分大像LiveBench这种题目不公开的国内厂商提交的也不多目前主要是GLM、Qwen、DeepSeek、Kimi和MiniMax。正好最近不少平台免费开放Hy3试用我就拿自己的Flutter项目实测了一把。简单任务和复杂任务中的表现差距还是挺明显的。先说结论它很适合当flash级模型的升级版但很难替代GLM 5.2这类pro模型当开发主力。1. 简单问题它确实香日常开发里这类任务它基本都能稳稳接住写一个小组件整理一篇文章结构汇总几个表格的数据这种体量的问题Hy3表现很好。准确率高但说实话这个级别的任务大多数flash模型也差不到哪去。真正让使用体验提升的是速度。参数量小响应快你丢过去一个小需求它几乎是秒回。用flash模型时那种「等一等、再改一改」的拖沓感在Hy3上轻了不少。简单任务上Hy3能给你更爽快的使用体验。2. 复杂问题三轮对话才露出真实水平真正能看出模型成色的还是复杂问题。正好老刘在处理一个Flutter路由拼接的bug几十个页面每个页面都有基础名称和固定后缀中间那段path却不统一。大约80%的页面走同一套规则剩下20%各有各的特殊逻辑。规模不大但规则一乱就很容易拼错。我把这个路径拼错的bug直接丢给Hy3看它能不能正确的定位和解决。第一轮准确定位方案考虑不周Hy3自己定位到了问题路由失败就是路径拼错了。全程没有额外提示这一步做得干净。定位速度倒没有简单任务那么惊艳和其他pro级模型差不多。到了修复方案这一步。它找到了那80%页面的通用规则然后直接把这套规则当成了全部答案。剩下20%的特殊页面它当没看见。看起来很聪明其实只学到了大多数。第二轮追求统一算法过度设计我提醒它不是所有页面都遵循同一套规则。它立刻推翻了第一版方案这点值得肯定。但接下来它又钻进了另一个坑试图写一套能覆盖所有路径的统一匹配算法。我很欣赏这种尝试结果却不理想。算法复杂度高后面一旦有新页面加入很容易再出问题。它在追求「一次写完」却没有考虑「以后怎么维护」。第三轮在约束下给出可维护方案我把缺陷点明了要考虑后续新页面接入。同时告诉它源码里有一个类似场景可以参考。又聊了几轮之后它终于给出了我想要的方案默认的基础路径生成算法加自定义路径覆盖的回调。通用逻辑走默认特殊页面走覆盖。既不硬造统一算法也不把80%的规则硬套到100%的页面上。小结Hy3能干具体的执行性工作但去分析复杂问题它需要你提供更多的限制和思路不能完全自己发挥。定位问题可以独立给出可维护方案还差点意思。如果你不把边界条件、后续扩展、参考实现喂清楚它很容易停在看起来能跑的半成品上。3. 怎么用适合什么不适合什么测完之后老刘给它的定位很明确。适合写小组件、改文案、整理结构、汇总表格中低复杂度的日常开发任务对响应速度敏感、想比flash更爽一点的场景不适合规则多、边界多、需要可维护架构的复杂问题指望它独立想清楚业务约束再一次性给出稳妥方案直接替代GLM 5.2这类pro模型当开发主力和常见模型比可以这么理解模型层级定位老刘的用法flash级便宜、够用、偶尔拖沓简单任务(低成本甚至免费)Hy3比flash更快更稳复杂任务仍需带着走flash的升级版GLM 5.2级逻辑更深复杂问题更扛打开发主力成本低、速度快日常工作里完全可以拿它替换一部分flash模型。复杂逻辑、架构设计和需要深入推演的问题还是得交给更强的pro模型。长程多轮任务这次没专门测测过的朋友可以评论区补充。你测过Hy3吗复杂任务上它有没有让你惊喜还是也得你一步步带着走 如果看到这里的同学对客户端或者Flutter开发感兴趣欢迎联系老刘我们互相学习。 私信免费领老刘整理的《Flutter开发手册》覆盖90%应用开发场景。可以作为Flutter学习的知识地图。 : laoliu_dev 老刘也把自己历史文章整理在GitHub仓库里方便大家查阅。 https://github.com/lzt-code/blog