找元素这件事，决定脚本稳不稳
鸿蒙自动化脚本写到最后，花时间最多的往往不是业务逻辑，而是「怎么让鸿蒙脚本认出屏幕上那个按钮」。这段逻辑放在鸿蒙群控的批量脚本里，一对几十台设备跑，稳不稳的差别会被放大。
识别写死了，界面一改脚本就崩；识别写松了，脚本又会点错地方。HarmonyOS Next 这边提供的能力其实不少，问题在于很多人只用其中一种，然后硬套所有场景。
这篇把四条路拆开讲：找图、找色、OCR 识别，再加一路 YOLO，说清各自适合什么、参数怎么调，以及识别失败时的降级顺序。
四条路各自的定位
| 方式 | 认的是什么 | 适合的场景 | 主要代价 |
|---|---|---|---|
| 找图 | 像素特征 | 图形特征明显、位置会变 | 截图与匹配耗时 |
| 找色 | 颜色值 | 元素颜色单一、界面固定 | 抗样式变化能力弱 |
| OCR 识别 | 文字内容 | 元素是文字、文案会变 | 识别耗时，依赖模型 |
| YOLO | 目标类别 | 形态多变、位置不定 | 需要模型文件与训练 |
四条路不是互斥的，成熟脚本常常混着用：先用找图判断页面到没到，再用 OCR 读一下关键文案，最后用找色做一次兜底确认。
找图：特征匹配
图像识别里最常用的一招就是找图。它的原理是把预先截好的一小块图当作模板，在整屏截图里滑动比对，位置相似度超过阈值就认为找到了。鸿蒙这边走的是 OpenCV 的匹配能力，官方给的识别率在 95% 以上。
用它之前有两件事要做。先初始化 OpenCV，然后建议把图片存储切换到 mat 格式——官方实测这个切换能让内存降一半到八成、CPU 降两三成、速度提升一到两倍。批量跑脚本时，这个差别在几十台设备上是能感觉出来的。
写模板图有几个实用经验。截模板要在目标设备上截，别拿 A 机型的图去跑 B 机型；模板不要截得太小，太小容易误匹配；模板里尽量不要包含会变化的文字，把文字部分让给 OCR。
找色：轻量且快
找色比的是颜色值，所以它比找图快得多，也省资源。缺点是抗变化能力弱，主题色一改、背景一换，就可能失效。
它的用法一般有两种。单点比色适合判断某个位置的状态，比如某个按钮是不是变成可点状态；多点找色适合在整屏里搜一个颜色特征，比如找到那个唯一的红点。
如果单个颜色不够唯一，用多点找色，用相对偏移把几个颜色绑成一组特征，误判会少很多。还有一种反向用法：排除某个颜色再去找，用来避开背景干扰。
OCR：认字不认图
OCR 认的是文字内容，所以它天然适合处理文案会变的元素。按钮上的字改了、提示语换了，找图要重新截图，OCR 不用改。
鸿蒙这边内置了 PP-OCRv6_small，日常正立界面够用。初始化时选模型类型，识别时返回的是一个数组，每项带着文字内容、置信度和坐标范围，按坐标就能点了。
调参方面，最值得先试的是 padding，也就是给文字框外扩一圈白边。文字没被框全的时候，加这个值通常立刻见效。其次是检测框的置信度阈值，值调大召回率会降但更准，调小更容易找到但可能误报。
如果只追求速度，可以把图像最大边限制在 640，同时关掉文字方向检测和角度投票。这两项只在图片倒置的场景才需要开。
还有一点要注意：OCR 初始化失败时是有错误信息可以读的，别只看返回的布尔值，把错误信息打出来，能省掉不少猜的时间。
YOLO：目标检测
YOLO 解决的是另一类问题：目标长什么样不固定，但你知道它属于某个类别。比如识别画面里有没有出现某类图标、有没有弹出某类提示。
它需要模型文件，训练方式和安卓侧一致。初始化时给类别名列表，再给一个模型名和尺寸，然后用的时候把截图喂进去，返回检出的类别与位置。
因为多了一层模型，它的启动成本和调参复杂度都比前三者高。除非前三条路确实解决不了，一般不必优先上。
怎么选，以及失败时的降级顺序
给一个务实的判断顺序：
先看目标是不是文字。是文字、而且文案会变，用 OCR；是文字但文案固定、位置也固定，找色可能更快。
再看目标有没有明显的图形特征。有就用找图，稳。
图形特征不明显、只剩颜色能区分，就用找色。
上面三条都试过还是不行，再考虑 YOLO。
至于失败时的降级顺序，反过来走一遍就是：找图失败退到找色，找色失败退到 OCR，都不行就截图留档并记录，别让脚本硬跑到超时。
最后补一条排查习惯：把识别到的坐标和当次截图一起打到日志里。很多「找不到元素」其实是找到了、但坐标偏了，光看返回结果看不出来，对着截图一看就明白。
关于 EasyClick：手机自动化 AI 智能体平台，覆盖安卓免 root、iOS 免越狱、鸿蒙 Next 三大生态，提供脚本开发、苹果群控、本地中控投屏与云控系统。→ 了解全部产品
想要真实跑起来？
本文介绍的方案均可在 EasyClick 手机自动化平台落地。官网提供完整文档、开发工具与群控云控产品，免费体验。