做 UI 自动化的朋友，大概率都经历过这样的深夜：回归跑了不到一半，十几个用例红成一片，点进去一看——不是 bug，是前端把按钮的 id 改了。修选择器的时间比写用例还长；弹窗、超时、加载慢这些"脏活"永远处理不完；好不容易上了 AI 生成脚本，看着行云流水，真跑起来各种翻车。
昨晚（11 月 4 日）的例行公开课，整整讲了 2 个半小时"决策模型"。有同学刚进直播间听的时候问是不是科普，可听完大家发现，它正好打在了 UI 自动化最疼的那块骨头上。
一、大模型"会聊天，不会干活"
课程先抛出一个判断：通用大模型是为聊天训练的，不是为自动化训练的。
它给你一段流畅的文本，但不告诉你这个答案有几分把握；它逐字生成、开销巨大，端到端响应动辄 3 秒起步。放在聊天场景里这没问题，可自动化流程里需要的是什么？是一个干脆的答案，外加一句"我有 82% 的把握"——因为这个概率，决定了这一步该不该执行、要不要回退。
决策模型（课程里叫 System 1 模式）反其道而行：
维度
传统大模型
决策模型
输出
非结构化文本，逐字生成
类型安全的结构化值 + 校准概率 + 置信度
采样
自回归，一个 token 一个 token 崩
一次并行输出，不产生中间 token
成本
约 0.2 美元 / 百万 token
约 0.042 美元，实际更低
延迟
3 秒 — 5 分钟
70 — 500 毫秒
对测试工程师来说，这意味着一件很本质的事：自动化里 90% 的判断，其实是选择题。 点哪个元素？该不该点？断言过不过？选哪条分支？这些不需要大模型写小作文，只需要一个又快、又便宜、还知道自己"不确定"的模型来作答。
二、课堂演示一：不写一行脚本，让 AI 自己搭"浏览器智能体"
讲师现场演示的第一个案例，是让 AI 完成"打开百度，搜索北京到上海的机票"——全程没写一行脚本。
做法是先让通用大模型加载决策模型的官方技能（skill），由它自己读文档、自己把任务拆成一串决策问题，然后在底层跑一个 Agent 循环。这个循环每一步都在问四个问题：
当前任务完成了吗？（返回一个概率，低于阈值就继续）
下一步做什么动作？（click / type / enter / scroll，四选一）
如果是点击，点哪个元素？（把页面所有候选元素交给模型挑）
如果是输入，输入什么？（文本由外部提供，模型不负责生成内容）
这里必须说点题外话：现场演示其实状况不断。官网先是登不上（讲师怀疑是国内访问受限），翻译插件跟着失灵，浏览器插件一个接一个报错。讲师倒也坦诚，干脆放弃在线模型，切到本地部署的开源平替继续讲——反而让我们看到了真实的使用路径：本地 4B 的小模型，单步决策 0.7 到 3 秒，日常自动化的量级完全够用。
三、课堂演示二：一个 YAML 文件，驱动整个 App 登录流程
第二个案例更贴近测试同学的本行：App UI 自动化。讲师选的目标是"雪球基金"的登录流程，case 用 YAML 写，结构类似我们熟悉的页面对象（PO）模式——页面、步骤、断言，然后交给决策模型驱动执行。
有三个细节，我觉得比功能本身更值得划重点。
第一，确定性动作不过模型。 Launch 这类操作直接执行，不浪费一次推理。该走模型的走模型，不该走的一点不绕。
第二，置信度低于 30% 就不执行。 这是工程化做得最聪明的地方：模型"不确定"的时候，宁可停下来，也不乱点。对比我们现在的 AI 自动化脚本，一通操作猛如虎，点错了还浑然不觉——有一个明确的"不作为"阈值，反而是稀缺品质。
第三，也是全场的高潮：把候选范围放宽，模型照样选得对。 讲师把"点击一键登录"这一步的候选条件，从"文本包含『一键登录』"（只剩 2 个候选）改成了"所有可点击元素"（一下子几十个候选）。按我们写选择器的直觉，候选越多越容易误选——结果模型依然以 94% 的概率选中了正确的按钮。
换句话说：你不需要把元素写死。 页面结构变了、元素挪了位置，只要它还在候选范围里，模型大概率能重新找对。这对被 selector 折磨了多年的测试同学来说，价值不言自明。
四、泼冷水的部分：它不是银弹
课程后半段，讲师自己也把限制讲得很透，我原样记下来：
只能做有限决策。 一步里塞进一长串操作，问题复杂度爆炸，后续执行不可控。正确姿势是一次只让它做一两个决策。
文本内容必须外部给。 手机号、验证码这类具体值，决策模型不负责生成，要么写进 case 变量，要么交给通用大模型。
AI 生成的框架"够用，但不精"。 现场让 AI 生成的测试框架就有小 bug——讲师删掉一个字段反而报错，最后选择放宽条件绕过去。他的结论很实在：让 AI 出骨架，自己改薄，或者干脆自己写循环。
但断言能力反而是增强的。 "页面有没有错别字"这种自动化脚本根本写不出的断言，交给模型判断反而可行。
五、三种路线，怎么选？
把昨晚的内容收敛成一张表，大致是这样：
路线
效率
维护成本
断言能力
适合场景
脚本生成（AI 写死脚本）
高
高：弹窗、超时、改版都得改代码
弱，只能写规则
稳定、少变的流程
纯大模型智能体
低，每步都要推理
低，自然语言即 case
强，断言灵活
探索性、低频任务
决策模型驱动
高
低
强
高频、要稳定跑量的自动化
一句话总结：决策模型不是第四种方案，而是给"纯大模型智能体"补上了效率短板，让它第一次具备了跑量产的可能性。
写在最后
整场课听下来，我觉得最值钱的不是某个具体工具，而是一个思路转变：自动化里绝大多数判断是选择题，而选择题，就该交给一个又快又便宜、还能如实报告"我不确定"的模型。
至于工具选型——课程里讲了闭源标杆，也讲了基于 Qwen3.5 微调的开源平替（4B 就能本地跑），协议互相兼容，试错成本不高。感兴趣的同学建议先拿本地开源版复现一遍课堂的登录 demo，再决定往哪走。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
