脚本卡住的地方，往往不是点不到，是看不懂
用脚本做过自动化的人大概都遇到过这种情况：按钮明明在那儿，脚本就是点不下去。
排查半天发现，问题不在定位，在判断——那个按钮长什么样、什么时候该点、点了之后该走哪条路，全都得提前写死在代码里。
举个具体的：某个后台的订单列表，你要把“状态显示异常”的订单挑出来。
固定脚本的做法是把每种异常状态的文字都枚举一遍，然后为每一种写一个分支。这套东西写起来累，而且只要有新的异常状态出现，你就得回去改代码。
而人做这件事的方式完全不同：扫一眼列表，看到不对的挑出来。人不需要枚举——人看得懂。
这篇文章讲的就是，哪些活属于“看一眼就懂了”这一类，以及这一类活怎么交给机器。
这类活的三个特征
判断一件活是不是“看一眼再决定”，看三个特征。
- 要读内容：下一步做什么，取决于屏幕上写着什么（数字、状态、文字），而不是取决于某个按钮在哪个位置。
- 有分支：不是一条直线走到底。读完内容之后，会走到不同的路上去。
- 靠识别而不是定位：你要找的是“那个写着异常的行”，而不是“第 320 行第 65 列那个点”。
三个特征全中的活，固定脚本做起来都很别扭；中两个的，也值得考虑换个方式。
三类最适合的场景
条件触发类
达到某个条件才动手。
比如“价格低于某个值就下单”“库存显示为 0 就截图留证”“消息数超过十条就统一处理”。这类活的特点是大部分时候什么都不用做，只在条件满足时才行动。
固定脚本处理这类活很难受——它要么一直盯着（浪费），要么定时来看（可能错过）。而“看一眼再决定”的方式天然适合：看一眼，不符合就跳过，符合就执行。
内容筛选类
从一堆条目里挑出符合条件的。
比如从几十条评论里挑出带某个关键词的、从订单列表里挑出特定状态的、从消息列表里挑出没回复过的。
这类活的关键在于列表内容每次都不同。你没法为每一条写一个分支——你只能“看一遍，然后挑”。
状态判断类
异常了才处理。
比如账号状态显示异常、设备显示离线、任务显示失败。这类活和条件触发有点像，区别是它需要先理解“异常”长什么样，而不是比对一个数字。
一个真实的例子
回到开头那个“挑出异常订单”的活。
用描述的方式做，大概是这样的：
打开订单列表页，从上往下看每一行的状态。如果有哪一行的状态不是「已完成」也不是「待发货」，把这一行截图存下来，记一下订单号。全部看完之后，把截图和订单号整理到一张表里。
这段话里没有任何一个“点这里”的指令。你说的是看什么、挑什么、怎么存。
它能跑通的原因是：它读的是内容。所以哪天后台换了个新状态文字，不需要你回去改描述——它看到那个不认识的文字，照样会挑出来。
这一点是固定脚本做不到的。固定脚本只认识你提前告诉它的那几种，多一种就可能漏掉，而漏掉的往往是真正需要处理的那一种。
读错了怎么办
这是这类能力最需要设防的地方。
读错本身不致命，致命的是读错之后还继续动手。比如把 1299 读成 129，然后按这个价格下单。
所以这类流程要加一道刹车：读到的值和预期差太远时停下来。
具体做法是在描述里明确说清边界：
如果看到的价格和上次记录的差距超过一半，不要操作，先截图存下来等我确认。
多这一句的成本很低，但它把“读错”从一个可能造成损失的错误，变成了一个需要你看一眼的提示。
什么不适合交给它
有一条边界得划清楚：没有明确标准的判断，不要交。
比如“这条评论算不算负面”“这个客户值不值得优先跟进”“这张图拍得好不好”。这类事你问十个人可能得到七个答案，机器给你的只会是“看起来合理”的那个——而它错的时候你未必看得出来。
判断标准很简单：你能用一句话说清判断规则吗？ 能，就可以交；说不清，就先别交。
怎么开始
挑一件最短的“看一眼、做一件事”的流程。
比如：打开某个页面 → 看价格有没有变化 → 变了就截图。三步。
流程越短，你越容易判断它读得准不准——三步的流程读错了你一眼就能看出来，二十步的流程读错了你会以为是后面的环节出问题。
跑通之后再往上加分支。加的顺序建议是：先加“条件不满足时跳过”，再加“异常时停下”，最后才加“要动手的操作”。
软件完全免费，装在自己电脑就能跑。同类思路可以读把手机截图变成表格；AI 操作手机的整体能力边界，看AI 操作手机是什么。
常见问题
- 什么叫「看一眼再决定」的活？
- 屏幕上有一串内容，你要先读懂它，才知道下一步该点哪里。比如价格低于某个值才下单、状态显示异常才截图、列表里有新条目才往下走。这类活的关键不是找到按钮，是先读懂内容。
- 这和普通脚本有什么区别？
- 普通脚本执行固定顺序：点这里、等三秒、再点那里。它不读内容，所以遇到分支就得把每种情况都提前写死。而「先看一眼」是指执行到那一步时，根据看到的内容现场决定走哪条路。
- 这种能力靠什么实现？
- 把当前屏幕的内容读出来——可以是页面上的文字、也可以是图片上的字。读完再做判断。所以它可以处理界面结构变化，因为判断依据是内容，不是位置。
- 哪些活最适合？
- 三类：条件触发类（达到某个值才动手）、内容筛选类（从一堆条目里挑出符合条件的）、状态判断类（异常了才处理）。这三类在业务里占比很高，但传统脚本都做得很别扭。
- 哪些活不适合？
- 需要主观判断的，比如这条评论算不算负面、这个客户值不值得跟进。这类事没有明确标准，交给机器只会得到看起来合理的错误答案。
- 读错了会怎么样？
- 读错本身不可怕，可怕的是读错之后还继续动手。所以这类流程要加一道：读到的值和预期差太远时停下来，而不是硬着头皮往下走。
- 会不会比固定脚本慢？
- 会慢一点，因为多了一步读取和判断。但这个差价换来的是「界面改了不用重写」和「能处理分支」，多数业务场景里这笔交换是划算的。
- 怎么开始试？
- 挑一件「看一眼，然后只做一件事」的最简单流程。比如打开某个页面，看价格有没有变，变了就截图。流程越短越容易判断它读得准不准。