先看一眼再决定：AI 操作手机的读屏判断适合哪些活

脚本卡住的地方，往往是看不懂

用脚本做过自动化的人，大概都遇到过：按钮明明在那儿，脚本就是点不下去。

那次查了半天。问题不在定位，在判断。那个按钮长什么样、什么时候该点、点了之后走哪条路，都得提前写进代码。

举一个具体的。某个后台的订单列表，要把状态显示异常的订单挑出来。

固定脚本的做法，是把每种异常状态的文字都枚举一遍，再为每一种写一个分支。写起来累。只要出现一种新的异常状态，就得回去改代码。

人做这件事是扫一眼列表，看到不对的就挑出来。人不用把每种文字先列全，人看得懂。

下面说哪些活属于看一眼就懂，以及这类活怎么交给机器。

判断一件活是不是看一眼再决定，看三个特征。

要读内容。下一步做什么，取决于屏幕上写着什么，数字、状态、文字都算，不取决于某个按钮在哪个位置。

有分支。读完内容之后，会走到不同的路上。

靠识别。你要找的是那行写着异常的。第 320 行第 65 列这种固定点，解决不了这件事。

三个特征都有的活，固定脚本做起来很别扭。中了两个，也值得换个做法。

三类最适合的场景，以及读错了怎么办

条件触发，是达到某个条件才动手。

比如价格低于某个值就下单，库存显示为 0 就截图留证，消息数超过十条就统一处理。这类活大部分时候什么都不用做，只在条件满足时才行动。

固定脚本处理这类活很难受。它要么一直盯着，浪费；要么定时来看，可能错过。看一眼再决定，不符合就跳过，符合就执行。

内容筛选，是从一堆条目里挑出符合条件的。

比如从几十条评论里挑出带某个关键词的，从订单列表里挑出特定状态的，从消息列表里挑出没回复过的。

列表内容每次都不同。没法为每一条写一个分支，只能看一遍，然后挑。

状态判断，是异常了才处理。

比如账号状态显示异常、设备显示离线、任务显示失败。它和条件触发有点像，要先看懂异常长什么样。条件触发比对的是一个数字。

回到开头那个挑异常订单的活。用描述来做，大概是这样：

打开订单列表页，从上往下看每一行的状态。如果有哪一行的状态不是「已完成」也不是「待发货」，把这一行截图存下来，记一下订单号。全部看完之后，把截图和订单号整理到一张表里。

这段里没有「点这里」。你说的是看什么、挑什么、怎么存。

它能跑通，是因为它读的是内容。哪天后台换了一种新的状态文字，不用回去改描述。它看到不认识的文字，照样会挑出来。

固定脚本只认识你提前告诉它的那几种。多一种就可能漏掉。漏掉的，往往是真正要处理的那一种。

读错本身不致命。读错之后还继续动手，才会出事。比如把 1299 读成 129，然后按这个价格下单。

所以要加一道刹车：读到的值和预期差太远时停下来。

在描述里把边界写清楚：

如果看到的价格和上次记录的差距超过一半，不要操作，先截图存下来等我确认。

多这一句的成本很低。读错之后，它变成一条等你看一眼的提示，不会直接造成损失。

什么不适合交给它

没有明确标准的判断，不要交。

比如这条评论算不算负面，这个客户值不值得优先跟进，这张图拍得好不好。这类事你问十个人，可能得到七个答案。机器给你的，会是看起来合理的那个。它错的时候，你未必看得出来。

你能用一句话说清判断规则，就可以交。说不清，就先别交。

软件免费，装在自己电脑上。先挑一件最短的流程：看一眼，然后只做一件事。

比如打开某个页面，看价格有没有变化，变了就截图。三步。

流程越短，越容易判断它读得准不准。三步的流程读错了，你一眼就能看出来。二十步的流程读错了，你会以为是后面的环节出了问题。

跑通之后再往上加分支。顺序是：先加条件不满足时跳过，再加异常时停下，最后才加要动手的操作。

同类思路可以读把手机截图变成表格。AI 操作手机的整体能力边界，看AI 操作手机是什么。