用 Gemini 3.5 Flash 搞定自动化

背景

最近 Google DeepMind 动作挺多，我重点盯了两个更新：一个是 Gemini 3.5 Flash 引入了 computer use，另一个是 Nano Banana 2 Lite 和 Gemini Omni Flash 开放构建。 老实说，以前搞 UI 自动化或者跨应用操作，写一堆 XPath 和坐标脚本真的让人头秃。现在模型能直接“看”屏幕并操作电脑，思路完全变了。我花了一周时间把这几个新模型揉进日常工具链，踩了些坑，也总结了几套可以直接抄的工作流。

技巧一：用 Gemini 3.5 Flash Computer Use 做跨系统数据搬运

• 适用场景 需要把 A 系统（比如老旧的 ERP 网页）的数据搬到 B 系统（比如现代的 SaaS 后台），且 A 系统没有 API。
• 怎么做 传统方式你得写 Selenium 脚本，还得处理各种反爬和动态 DOM。现在直接用 Gemini 3.5 Flash 的 computer use 功能。

1. 给模型提供 A 系统的登录态 Cookie 和初始截图。
2. 在 Prompt 里写明目标：找到本月未结算的订单列表，提取订单号和金额。
3. 模型会输出操作指令（比如点击坐标、输入文本），你的执行脚本接收指令并模拟鼠标键盘。
4. 执行后截个新图喂给模型，让它确认是否翻页或提取完成。 对比以前写死选择器，这种方式对 UI 微调的容错率高太多了。

• 注意事项 模型偶尔会点错位置。我建议在关键步骤（比如点击“提交”前）加一个人类确认的 hook，或者让模型先输出“我准备点击这里”的推理过程，别直接盲操。

技巧二：拿 Nano Banana 2 Lite 做端侧意图路由

• 适用场景 你的 Agent 有很多下游工具，如果全扔给大模型做意图识别，Token 费用扛不住，延迟也高。
• 怎么做 Nano Banana 2 Lite 这种轻量模型就是为这个准备的。

1. 在本地或边缘服务器部署 Nano Banana 2 Lite。
2. 收集几百条用户真实 Query，标注好对应的下游工具（比如查天气、写代码、搜新闻）。
3. 用这些数据微调或直接做 Few-shot 提示。
4. 用户请求先过 Nano Banana 2 Lite，它判断需要调用哪个复杂模型或 API，再分发过去。 我测下来，这种小模型做分类任务的延迟基本在毫秒级，成本几乎可以忽略不计。

• 注意事项 别指望它处理复杂的逻辑推理。它就是个“门卫”，只负责指路。如果 Query 太模糊，记得设置一个 fallback 机制，直接扔给大模型兜底。

技巧三：结合 Gemini Omni Flash 做多模态 UI 测试

• 适用场景 QA 团队做 UI 自动化测试时，不仅要验证元素存不存在，还得看视觉上对不对（比如按钮有没有被遮挡、颜色对不对）。
• 怎么做 Gemini Omni Flash 处理多模态输入很拿手。

1. 自动化脚本跑完一个测试用例后，截取当前屏幕，并录下最后 3 秒的操作视频或音频反馈。
2. 把截图和多媒体文件一起喂给 Gemini Omni Flash。
3. Prompt 这样写：检查这个结账页面，确认支付按钮是否可见且未被弹窗遮挡，同时判断有没有报错提示音。
4. 模型会综合视觉和听觉给出 Pass 或 Fail 的判断。 这比单纯断言 DOM 节点靠谱多了，能抓出很多“元素在但用户看不见”的诡异 Bug。

• 注意事项 多模态输入的 Token 消耗比较大。建议只在核心链路（比如支付、登录）开启这种重度验证，普通页面还是用传统的断言。

小结

这波更新里，computer use 确实改变了自动化的玩法，而 Nano Banana 2 Lite 和 Gemini Omni Flash 则补全了成本和端侧能力的拼图。如果你和我一样受够了脆弱的 DOM 选择器，建议赶紧把 Gemini 3.5 Flash 加进你的自动化脚本里试试。