Hy3两周免费，救了已离不开WorkBuddy的打工人

当整个行业都在转变风向，从免费转向收费之后，腾讯做出了一个截然不同的决定，持续加码，在WorkBuddy每天免费100积分的基础上，提供两周的Hy3大模型的免费使用。

本就已经TOKEN额度饥荒的我，为了这免费的TOKEN额度，毫不犹豫的抛弃了DeepSeekV4-Pro，转用Hy3。

当我真正在WorkBuddy上重新运行起我的工作任务时，我的感受是：足够准、足够强，但也是真的慢。但这或许也是腾讯在这场诸子百家般的大模型争鸣中，给自己锚定的一席之地，职场超能力。

因为在大多数的工作场景中，准确比快更重要，合适比强更重要。

一、真实场景下的工作任务，不必用GPT-5.5打蚊子

大多数人，可能都对职场有一定程度的误解。觉得能力最强的那个人，一定就是升的最快的，但实际上你会发现，那些升职快的，可能只有不到30％是真的工作能力出众，剩下的70％，对领导而言，各有各的用处。

现在的各类AI大模型，其实就像是一个个员工，模型能力最强最快的，当然是最好用的，但是你也必须考虑一下，这样的员工，你是否用得起。

GPT-5.5的能力一定是站在第一梯队的，但是它的费用是，输出5美元/百万TOKEN，输入30美元/百万TOKEN，如果是Pro版本的话，它的价格是普通版本的六倍。但是百万TOKEN放在现在的任务模式下，是什么概念呢？很可能就是两三轮对话所消耗的TOKEN。

所以，除非是顶尖科研的需要，不然真的没必要用GPT-5.5来做工作任务。

当然，说实话，DeepSeekV4-Pro的性价比是足够高的，比起闭源模型，在基础任务的完成度上，并没有太大的体验差距，命中缓存后0.02倍率的费用消耗，也足够诱人。但问题是，在7.1号之后，它就开始变得让人感觉陌生了。

7.1号前超高的缓存命中率，到了7.1号之后，开始大幅下降，随之而来的是费用的大幅增长。

现在的Hy3，给我的感觉就是平替中的平替，虽然现在是免费的，但是从Qclaw积分消耗倍率来看，Hy3未来的定价水平，大概率是会趋近于DeepSeekV4-flsh版本的。但是从目前传出来的消息来看，Hy3正式版的水平预计是在GLM-5.1之上，GLM-5.2之下的，那么如果未来真的是这样的一个定价策略的话，那就很值得玩味了。

二、真实工作场景下的Hy3，长链条任务实现超出想象

用大炮打蚊子是不合适的，但至少，也得是一个电蚊拍才行。

不过在我最近两天的测试下来，我觉得Hy3大模型，或许就是最适合用来打蚊子的那个电蚊拍。无他，Hy3是唯一一个能够把长链条任务的拆解、执行、验证、复盘做得令我赏心悦目的。

还是那个古老的问题，如果真实场景下每个流程AI的完成率都是95％，那么十个流程之后，AI能够完整完成任务的就只剩下60％左右。

解决这个问题的关键，不在于模型的智能能力，而是工程、产品能力。

接下来进入实测部分：

第一，对长数据内容的读取、理解能力。个人觉得，Hy3在内容的读取上，做的还是很不错的，在之前把AI融入工作流的过程中，我建立了一整套完善的工作流规则、执行、存档模块，整体的内容大小，预估在几十万字的纯文本量大小。

Hy3解析我的obisdian知识库，用的时间是2分52秒，并且几乎是准确的读取了所有的信息并且进行了归纳，这个速度整体来说，可能比不上DeepSeekV4-Pro，但是也差不了多少。

第二，强规则跨Agent的执行能力。这一点，是最考验大模型能力的一件事情，因为这是一个相当负责的任务，并且有设置了很多的强规则，我给Hy3布置的任务是，在金山文档的442张发票中，寻找到6笔回款能够对应的发票，一笔回款会对应多张发票。

在这个过程中，调用金山文档自己的接口，寻找数据，进行演算，规则回款、生成网页、制作表格，这些任务，在给到Hy3充分的操作规则和信息之后，他基本上能够自主完成，在有效信息下唯一的一次的干预，是金山文档全部有442行，但是第一次Hy3之获取到了350行。

但是在经过我提醒之后，它能够找到剩下的行数，并且重新进行计算。

在这个过程中我发现，Hy3是存在一整套逻辑的，首先会对任务进行拆分，拆分之后执行，并且自主对任务进行修正，是按照真实问题的思考路径去解决问题，这一点上，和其他AI其实是有一些不同的。其他AI一般是任务遇到错误时，才会进行检验，而Hy3则是会确认每一个关键节点任务的可靠性。

第三，需求修改的能力。除非是在指令中，已经给到了充分的强制规则，不然想要让AI一次就达到理想中的状态，难度相当大。这个时候，AI对修正指令的理解能力，就显得很重要了。

这时候的AI，会存在两种状态，一是越改需求越偏，从最初的只偏了一点，到后面完全偏离直到崩溃；二是往正确的路径上发展。从我目前测试效果看来，Hy3是后者，在实际的应用中，更像我最初用GLM-5.1模型时候的状态。

能够理解我的问题，并且进行正确的响应。

三、还不够完美的Hy3,上下文容量和速度是最大的考验

但实测下来，同样有两个问题，会把真实场景下的问题放大。

第一个，就是上下文容量的问题。目前Hy3的上下文容量只有200K，这个上下文容量，是明显落后于目前的主流AI的，目前的主流AI的容量是1M上下文。

所以在我从下指令到完成任务，不完全统计，就有五次上下文压缩。

如果只是单一的任务进程，上下文压缩，不会存在很大的问题，但当我在用DeepSeekV4-Pro的时候发现，当你有几个不同的进程同时存在于一个对话中，并且还有进程没有走完的时候，上下文压缩会导致对话紊乱。

也就是当你提出了一个新的问题，但是因为上下文压缩，模型接收到的优先级别是上一个进程还没有完成，这时候需要重置上下文，才能够解决问题。

Hy3虽然还没有出现过类似的情况，但毕竟上下文压缩的原理都是一样的，大概率也会出现类似的BUG。

第二个，就是整体的运行速度。毕竟Hy3,是一个295B的模型，并且又叠加了上下文压缩和复核的过程，导致整体任务的执行速度被极大的拖慢。

为了完成这个任务，我总体的耗时接近五个小时，AI执行任务的总时长是3小时25分钟，其中执行最长的单个对话耗时是1小时15分钟，大概率是因为调用量过大导致的。

不过好在，针对这一点，今天已经看到官方发出了说明，7月8号上午十点算力资源就达到了峰值，然后官方就紧急进行了扩容。实测下来，任务速度有了不错的提升。

接下来，对于Hy3在真实场景下的任务执行能力，我还会进行更长期的测试，但可能，我会把它放在更加偏向于非紧急时效下的任务当中，例如自动化执行任务、信息搜索任务等等。

但至少Hy3的出现，已经证明了一件事，在当大多数人的工作，还没有复杂到，只有顶尖的大模型才能够解决问题时，最高的性价比和最强的工程能力，就已经够了。