为什么单 App 的活都不算难
用电脑操作手机这件事，最容易被低估的不是技术，是任务的形状。
一个 App 里能做完的活，无论多少步，它的页面状态是连续的：你在首页、点进详情页、返回、再进另一个入口。整个过程都在同一个界面体系里，找元素的方式也差不多。
真正麻烦的是另一类：要来回切几个 App 才做得完的那件事。
三个跨 App 的真实场景
- 场景一：客服的三段式回复：买家在 A 平台问「我的货到哪了」，你要打开 B 后台查一下物流单号，可能还要回到 C 平台看仓库的发货记录，最后回到 A 平台把结果回给买家。一个咨询，四个 App。
- 场景二：内容运营的取材发布：在 A 平台看到一条热榜，去 B 平台搜同题材的素材，下载下来，再发到 C 平台的账号上。中间还可能要看一下 D 平台的发布时间表。
- 场景三：订单处理的来回核对：订单在 A 平台进来，库存要看 B 平台的仓库系统，发货信息录在 C 平台，对完账还要回 A 平台点发货。
这三件事有一个共同特征：没有任何一步是难的，但顺序不能错，而且中间任何一次切错，后面的会全乱。
跨 App 到底难在哪
难在每一次切换都要重新建立上下文。
单 App 的任务里，脚本可以假设「我现在还在这个页面体系内」。跨 App 之后这个假设不成立了。每一次切换都要重新回答三个问题：
- 现在在哪个 App？
- 这是这个 App 的哪个页面？
- 下一步该去哪儿？
传统脚本处理这件事的办法是写死：先点这里的图标，等三秒，再点那里的按钮。问题在于，每一步都要写死，而且每一步都可能因为界面变化而失效。四个 App 串起来有二十几个切换动作，其中任何一个失效，整条流程就断了。
这就是为什么很多团队做了单 App 自动化之后，跨 App 的活还是手动做——写脚本的维护成本太高了。
换一种说法：把顺序说清楚就行
iEasyRun 的做法是，你只描述顺序和判断条件，不描述怎么切。
比如上面那个客服场景，可以这么说：
打开 A 平台的买家消息，找到问物流的消息。记住买家问的单号，打开 B 后台查这个单号的物流状态。查到之后回到 A 平台，用「您的包裹当前在…」这个句式回复买家。如果 B 后台查不到，就先回一句「正在为您查询，稍后回复」。
这段话里没有任何一个「点屏幕左上角」这样的描述。你说的是做什么，不是怎么点。切 App、找入口、等加载这些，是它自己的事。
这个分工的意义在于：你要维护的东西变少了。 上面那段描述里，只有「句式」和「查不到怎么办」是可能变的；而切 App 的方式、入口的位置、加载要等多久，这些都不会进到你的描述里。
中间跳错了怎么办
这是跨 App 任务最实际的问题，也是必须要处理的一环。
三种应对，按投入从低到高：
- 在描述里加异常分支：最常见的是弹窗和推广页。加一句「如果出现推广弹窗，先关掉再继续」就能挡掉一大类问题。这类异常你只要遇到一次，就补一句进去。
- 让流程自己回到起点：跨 App 流程建议设计成「可以重来」的形式：如果某一步彻底卡住，回到最初那个页面重新开始，而不是硬着头皮往下走。这在描述里的写法就是「如果失败，回到 A 平台的消息页重新开始」。
- 看日志定位：每次执行都会留记录，里面标出跑到哪一步、哪一步失败了。跨 App 流程环节多，出问题时看日志比凭印象猜快得多。
存成工作流，别每次重说
跨 App 流程是最值得存成工作流的一类。
原因很简单：单 App 任务你再描述一遍花不了多少时间，但跨 App 任务段落长、顺序讲究，每次重说容易漏。跑通一次之后存下来，下次直接调用，把「描述」这件事的成本降到零。
存的时候有个建议：把会变的部分留成可填的变量。比如单号、句式、目标账号，这些每次都可能不一样，做成可以在调用时填的参数，而不是写死在流程里。这样一套工作流能用很久。
开始之前
第一次别挑四个 App 的，先挑两个 App 的。
最容易上手的是「在一个 App 里看到东西，去另一个 App 用它」这种两段式结构。跑通之后再加第三段。跨 App 流程的稳定性是叠加出来的，不是一次设计出来的。
还有一件事值得先做：手动完整走一遍，把每一步记下来。 尤其要记清楚每个步骤之间的「过渡条件」——比如你什么时候知道查完了、什么状态下该往回走。这份记录就是你写描述的依据，比边想边说靠谱得多。
软件完全免费，装在自己电脑就能跑。跑起来之后，建议再去 执行历史 看几次记录，跨 App 流程的每一步都能查到，出了问题好定位。想看更具体的场景做法，可以读 短视频自动发布 或 电商批量上架。
常见问题
- 为什么跨 App 的任务比单 App 难？
- 因为每切一次 App，环境就全变了。单 App 任务里页面状态是连续的，跨 App 之后每一步都要重新判断「现在在哪个 App、这是哪个页面、下一步该去哪儿」。脚本最怕这种状态切换。
- 用对话描述跨 App 流程，会不会说不清楚？
- 按「先做什么、再做什么、最后做什么」的顺序说就行，跟交代同事一样。不需要描述怎么切 App、怎么找入口，那些是它自己的事。
- 中间跳错了 App 或者进了广告页，怎么办？
- 在描述里补一句异常处理即可，比如「如果弹出了推广页，先关掉再继续」。它每次执行都会看屏幕状态，发现自己跑偏了会尝试回到正轨，实在回不来会在日志里标出来。
- 跨 App 任务能存成工作流重复用吗？
- 能。第一次用对话跑通之后存成工作流，下次直接调用。跨 App 的活尤其适合存，因为步骤多，每次重新说一遍比较费口舌。
- 能不能一个任务里同时操作两台手机？
- 可以按组派任务，多台设备各自跑一遍。但要注意：跨 App 任务本身耗时较长，设备多了要错开执行时间，别让所有设备同一秒开始。
- 切 App 靠什么实现？会不会被系统拦？
- 靠标准的应用启动和界面操作，不做特殊处理，也不需要额外权限。实际的卡点通常不在切换本身，而在切换之后页面还没加载完，所以流程里要留等待。
- 这种任务出错率高吗？
- 比单 App 高，这是客观的，因为环节多。所以第一版别追一步到位，先把主流程跑通，再逐步补异常分支，跑几次就稳了。
- 做成工作流之后，改了 App 要不要重配？
- 通常不用。它执行时是看屏幕决定下一步的，入口挪了位置会自己找。只有流程本身变了（比如多了一个环节）才需要回头改。