決策模型如何讓 APP 自動化測試提速 40 倍、成本降低一個量級？

2026-11-03 7

版权

版权声明：

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 上周公开课揭示：大模型不擅“实时决策”，却常被用于APP自动化测试。新路径是引入专用决策模型——结构化输出、毫秒级响应、成本降5–10倍，专攻流程判断、元素选择、失败归因等确定性任务。决策层用它，生成层用大模型，分层协同更稳更快。

上周公开课讲完，后台收到最多的一条留言是：“原来我们一直把大模型用在它最不擅长的地方。”

这句话挺准确的。过去一年，大家做APP自动化测试、做测试智能体，默认路径都是“给大模型一段Prompt，让它生成下一步操作”。能跑，但慢、贵、还不稳定。这次公开课重点聊的，是另一条路：把“决策”这件事，交给专门做决策的模型。

没赶上直播的同学，文末有直播回放和课件领取方式，可以先收藏再看。

下面把课上的核心内容整理一遍，给没赶上直播的同学补个课。

一、先看一个大家都有体感的问题
用传统大模型驱动APP自动化，流程大概是这样：

截图或页面结构喂进去 → 模型“思考” → 输出一段操作描述或代码 → 解析 → 执行 → 再截图 → 再思考。

这个循环里，最耗时间的不是“点按钮”，是模型每次都要把一整段内容一个token一个token地生成出来。生成完还要解析，解析错了还要重试。页面稍微复杂一点，一轮十几秒、几十秒就过去了。

更麻烦的是“失控”。传统模型是“决策+解析”混在一起输出的，它可能生成一个看起来合理、但实际不存在的元素，也可能在几个都能走的路径里随机挑一个。你没法提前知道它为什么选这个、不选那个。

课上有一句话我印象很深：“普通模型就算概率不高，它也会哐哐给你生成一大堆东西。你拿到手才知道靠不靠谱。”

二、决策模型不一样在哪？
课上对比了几组差异，我挑最关键的三个说。

第一，输出是结构化的，不是一段自由文本
传统大模型输出的是自然语言或代码，你得再解析。决策模型的输出是结构化的选择结果——类型是确定的，每一种可能都会附带一个执行度或概率，由你来做最终判断。

这带来的变化是：它不替你“编答案”，它把几个可能的答案和各自的把握程度摆在你面前，你来选。

对于测试场景，这个特性很关键。比如“下一步该点哪个元素”，传统模型可能直接给你一个选择器，错了你才知道。决策模型会把几个候选元素和各自的执行度都给你，你可以设定阈值：高于0.9的直接执行，低于0.9的转人工或走兜底。

第二，不逐token生成，所以快
这是速度差距的根源。

传统大模型是自回归采样，一次预测一个token，生成长内容时计算成本很高。决策模型不涉及逐token的文本输出，它只生成概率分布，可以并行完成多个选择判断。

课上给的数据大致是：传统大模型响应经常在十几秒到几十秒，决策模型可以做到1—5秒，整体快40倍到200倍。本地环境慢一些，也能做到几秒级。

放到APP自动化里，这意味着原来一轮“截图—思考—执行”要十几秒，现在可能一两秒就完成了。自动化脚本的整体执行速度，会被这个环节直接拉起来。

第三，成本差一个量级
课上提到，费用上至少有5到10倍的差距。原因还是同一个：不逐token生成，计算量小得多。

对于需要频繁调用模型的测试场景——比如每一步操作都要判断、每个失败都要归因——这个成本差距会非常明显。

三、一张表看懂两种模型的区别
维度
传统大模型
决策模型（课上讲的JV/GEB系列）
输出形式
自然语言/代码，需要解析
结构化选择结果，类型确定
不确定性处理
可能失控、幻觉，概率低也生成
给出多个可能及执行度，由人判断
计算方式
逐token自回归生成
只生成概率，可并行判断
速度
十几秒到几十秒
1—5秒，快40—200倍
成本
较高
低5—10倍
适合场景
开放生成、内容创作、复杂推理
工作流程、条件判断、选择决策、实时应用
四、那它适合测什么？
课上给了一组适用场景：工作流程、条件判断、大数据的map reduce、实时应用、检测核实、选择类任务。

翻译到APP自动化测试里，大概是这几类：

第一，流程分支判断。 页面上有多个可走路径，下一步该点哪个、该走哪个分支。这本质上是二叉树式的选择，决策模型很擅长。

第二，元素选择和定位兜底。 主定位器失效时，从多个候选元素里选一个最可能的，并给出执行度。高于阈值自动修，低于阈值转人工。

第三，失败归因分类。 一条用例失败了，是环境问题、用例问题、代码Bug还是数据问题。这是一个典型的多分类决策，不需要生成长文本。

第四，用例优先级和回归范围判断。 这次改动影响哪些模块、哪些用例必须跑、哪些可以抽测。也是选择问题。

第五，实时性要求高的巡检。 需要快速判断“页面是否正常”“流程是否走通”的场景，决策模型的速度优势会很明显。

五、课上那个“公司”的比喻，值得单独说
课上有一个比喻，我觉得比技术对比更好记：

一家公司里，高层做决策，底层干具体活。决策模型就像高层——它不负责写代码、不负责生成大段内容，它负责判断“走哪条路、先做哪个、哪个更急”。传统模型像底层的执行者，负责把选定的事做出来。

所以不是“决策模型替代传统模型”，而是分层使用：

编排层、判断层、路由层，用决策模型。快、便宜、输出可控。
内容生成层、复杂解释层、开放推理层，用传统大模型。
测试智能体也是一样。让决策模型决定“下一步做什么”，让传统模型负责“把这一步的内容生成出来”。 两者结合，比单用任何一种都稳。

六、落地时要注意什么
课上没有回避限制，我补几条自己的理解。

第一，不是所有任务都适合。 需要生成大段解释、写复杂脚本、做开放域推理的任务，还是传统大模型更合适。决策模型强在“选”，不强在“写”。

第二，执行度阈值要自己定。 决策模型会把多个可能和执行度都给你，但“高于多少自动执行、低于多少转人工”，需要根据业务风险来定。支付、退款这类高风险操作，阈值要更保守。

第三，工作流程要先可预测。 课上有一句话很关键：“只要是可预测的工作流程，都可以用这类模型。”反过来说，流程本身混乱、规则不清的场景，换什么模型都救不了。先把流程拆清楚，再谈模型选型。

第四，别指望它替你做最终判断。 它给的是概率和执行度，最终“走哪条路”还是人来定。它把信息摆得更清楚，但不替你做决策责任。

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