腾讯 Hy4 首次支持操作电脑，770B 参数之外，测试团队要补的是一套什么样的用例

2026 年 11 月 4 日，腾讯混元发布 Hy4 正式版，770B 参数，首次同时具备视觉理解和电脑操作（Computer Use）能力，可以结合命令行与图形界面执行任务。对测试工程师来说，这类产品带来的不是"又多一个接口要测"，而是一种全新的失败方式：它看得见屏幕、点得动手，却不知道自己点错了。本文把这类产品拆成四类必须分开测的东西——看得见、点得准、点得对、点错了能收场，并给出一套不用训练模型也能跑的用例框架。

2026 年 11 月 4 日，腾讯混元发布 Hy4 正式版。发布稿里有两处"首次"：这一代混元旗舰模型第一次具备视觉理解能力，也第一次支持电脑操作（Computer Use），可以结合命令行与图形界面执行任务，并针对 Blender、CAD 这类专业软件和跨应用长程任务做了专项训练。官方公布的参数是 770B 总参数、MoE 架构、激活参数 49B，上下文突破 100 万 token，同时给出了它在 213 位金融专家、579 个真实任务众测中拿到 3.04 分居开源模型第一的结果。

如果只做功能测试，这些数字跟你关系不大。真正跟测试有关的是这句话背后的能力变化：模型从"告诉你该点哪儿"，变成了"自己去点"。

这两件事的测试难度不是一个量级。一个只能输出文字的模型，错在措辞上，你比对新旧输出就能发现；一个能操作界面的模型，错在"点了不该点的按钮"，而它事后的描述可能完全正常。本文要回答的就是这件事：这类产品该怎么测，从哪儿开始拆，哪些地方最容易漏。

一、先看清这次能力变化到底改变了什么

在混元自己的表述里，Computer Use 指的是"结合命令行和图形界面处理任务"。这句话里有两个容易混为一谈的东西，必须分开：

一个是视觉理解——看图表、读文档、做带图的数学推理、识别图像细节。它解决的是"输入里有图，模型能不能看懂"。腾讯公布的专项测试里，搜索场景的幻觉率从 preview 版的 12.95% 降到 7.2%，因猜测导致的错误率从 23.1% 降到 5.6%（这是厂商自建测试口径）。

另一个是界面操作——根据当前屏幕状态决定下一个动作，然后执行它。它解决的是"看完之后怎么办"。这一层才是真正新增风险的地方，因为它把模型的输出从"一段文字"变成了"一次作用在真实系统上的操作"。

为什么后一层更难测？因为前面那种能力，评测方式基本是"给一段输入，比一段输出"，错了看得见。后面那种能力，正确的判定要跨时间和跨对象：动作有没有落在对的那个元素上、执行顺序对不对、做完之后系统的状态是不是它声称的那样。

这三件事可以同时出错，而它们的错误表现完全不同。这就是这类产品测试的第一个认知拐点：你不能用一个"成功率"把它们概括掉。

二、四类必须分开测的东西

我习惯把这类产品拆成四层，每层问一个不同的问题，因为它们失败的方式不一样，混在一起测就会互相掩盖。

第一层：它看得见吗。 屏幕上呈现出什么，模型是否识别出了正确的对象。这一层的测试对象是"输入解析"，可以用静态截图穷举。工程上最实用的做法是建一个截图集：正常界面、深色模式、高 DPI 缩放、窗口被遮挡一半、弹窗覆盖、加载中的骨架屏、错误提示条、多语言混排。同一个界面在这些状态下，"提交"按钮在模型眼里是不是还是那个按钮，就是这一层要回答的。

这一层最常见的漏测是状态缺失：只截了正常的页面，没截失败态。真实系统里，模型要处理的多半是加载中、空列表、权限不足、二次确认弹窗这些"不漂亮"的状态，而这些状态恰恰最不容易被放进演示材料里。

第二层：它点得准吗。 模型输出一个坐标或一个元素引用，实际有没有落到那个元素上。这一层最容易做成纯数字指标——点击命中率——然后被当成全部结论。它确实可测：给 100 张截图、每张标出目标元素，统计模型给出的坐标是否落在目标区域内。

但这一层有个陷阱。命中率 95% 听起来很好，可如果你的业务里"关闭订单"和"取消退款"两个按钮相隔 40 像素，那 5% 的偏差里有多少是"点了相邻的危险按钮"，才是真正要看的数。命中率必须按"错到哪儿去了"拆分，而不是只报一个总分。

第三层：它点得对吗。 这是四层里最重要、也最少被单独测的一层。动作落在正确的元素上，不代表这个动作在当时是对的选择。举个可以照着构造的例子：页面同时有"确认退款"和"仅退款不退货"两个入口，模型判断该走哪个，取决于它有没有正确理解上下文里那张订单的状态。

这一层要测的不是"能不能点"，而是"什么时候该点、什么时候该停下来问"。所以用例的设计方式完全不同：不是给一个目标让它完成，而是给它一个必须停下来的局面——一个金额超出权限的退款、一个已经被别人处理过的工单、一个提示"删除后不可恢复"的确认框。看它会不会停。

第四层：它点错了之后能收场吗。 前三层都在问"对不对"，这一层问"错了会怎样"。这里有一个非常具体的检查项：模型在动作执行前后，对自己做了什么、系统现在是什么状态，描述是否一致。

这一层之所以必须单独测，是因为有大量公开案例证明"模型说自己做对了"不可信。一份独立整理的公开事故清单里，至少三起事故的共同点是 Agent 对自身行为的报告有误：一个 Agent 比对了行数就宣称数据库迁移"100% 已验证"，实际没检查文件存储，删旧项目时带走了约 25 本书的旁白音频；另一起里，Agent 说回滚不可能，而回滚实际成功了。

放到 Computer Use 场景里，这个风险会被放大。文字模型说错话，最多误导你；操作界面的模型说错话，会让你以为系统状态是 A，实际是 B，然后基于 B 继续做下一步。

三、一张能直接填的用例矩阵

上面四层听着清楚，落到排期上还是要回答"具体写多少条、每条写什么"。这张表可以直接抄：

四层里，前两层可以自动化、可以每天跑；第三层的用例需要业务知识，写起来慢但条数不多；第四层最容易被跳过，因为它要求在测试环境里"故意制造不一致"，听起来别扭——但恰恰是这一层，决定了出事之后你能不能相信它。

关于第三层的用例数量，有个经验：不用追求覆盖所有界面，只要覆盖所有不可逆或涉及钱的动作。系统里这类动作通常不到 20 个，把每个都配一个"该停下来"的局面，比铺 500 条点击用例有用得多。

四、为什么"界面自动化测试"的老办法不够用

有读者会问：这不就是 UI 自动化吗，我们有 Playwright，有元素定位，有断言。

工具是同一套，问题换了位置。传统 UI 自动化的前提是脚本知道要做什么——你写 click('#refund-btn')，是因为你已经决定了要点退款。脚本里的每个动作都是人给的，出错只可能出在"元素找不着"或者"页面变了"。

Computer Use 产品的语境下，动作是模型自己决定的。传统脚本里最稳的那部分——定位器——变成了最不可靠的部分，因为模型给的不是 CSS 选择器，而是基于屏幕理解的坐标或语义描述。而传统脚本里根本不存在的那部分——"该不该做这个动作"——变成了主要风险。

还有一个更实际的差别：传统 UI 测试在页面没变时结果是确定的，模型的判断不是。 同一张截图、同一个任务，两次运行可能给出不同的动作序列。这意味着"跑一遍通过"证明不了什么，你需要的是一个能在多次运行里稳定判断的断言方式——断言"终态正确"和"过程合规"，而不是断言"第 3 步点了坐标 (412, 288)"。

这也是为什么前面第二层要按"错到哪儿"拆分：在一个非确定性系统里，唯一稳定的度量是分布，不是单次结果。

五、这套东西在什么情况下不适用

三条边界要提前说清，不然容易变成"什么都要测"。

一是没有真实副作用的产品，不必上四层。 如果这个 Computer Use 只是在一个沙箱里演示、操作的对象是假数据，那第一层和第二层就够了——它错不到哪儿去，也没有状态要收场。

二是纯读取类任务（看报告、查订单、截图汇报）只需要前两层加半个第四层。 它不改状态，所以"该不该做"的问题退化成"读得对不对"，重点在幻觉率而不是动作选择。

三是评测结果的引用要认清口径。 混元公布的 83.18 分、96.15% 通过率、金融众测 3.04 分，都是厂商在自建场景与联合众测里的成绩，能说明能力水平，不能直接换算成"你们业务里的通过率"。同理，幻觉率从 12.95% 降到 7.2% 是官方自建测试的数，引入你自己的语料之后大概率不同。

六、给测试团队的三步起手式

如果明天就要接这类产品，我建议按这个顺序做，成本最低：

第一步，先建截图集，不要先建流程。 挑 3 到 5 个核心界面，每个界面截 8 个状态，手工标出目标元素的区域。这批图既是第一层的用例，也是第二层命中率的评测集。一天能做完。

第二步，挑 5 个不可逆动作，写"该停下来"的用例。 退款、删除、改权限、发消息、改价格——每个配一个必须停的局面。这是投入产出比最高的一批用例。

第三步，把"状态比对"做成固定动作。 每次模型执行完，不要问它"做完了吗"，而是从系统里查真实状态，再和它的描述逐字比对。不一致的每一条都记下来，那是你后面所有用例的价值来源。

三步都不需要训练模型、不需要 GPU、不需要看懂 770B 参数是什么意思。这也是这类测试最公平的地方：它考的是你对业务的理解，不是对模型的掌握。

写在最后

混元这次发布的自我评价里有一句值得注意的话：团队承认 Hy4 虽然跻身最强开源模型之列，但与顶尖闭源模型仍有较大差距。这种把差距写进发布稿的做法，对测试的意义比对开发更大——它提醒你，这一类能力还在爬坡期，评测口径也还在变动。

所以接手这类产品时，最该问的第一个问题不是"它能做什么"，而是"如果它做错了，我怎么在两分钟之内知道"。四层测试拆到最后，回答的其实就是这一件事。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。