1. 从"快捷指令不够用"说起：iFlow是个什么存在
第一次听说 iFlow，是在某个效率社区的帖子里。帖主说自己写了一个"自动化动作"，能把长截图自动切 strips、拼接成长图，再 OCR 提取文字，最后打包成 Markdown 存进备忘录。底下有人回复：这不是快捷指令也能做吗？帖主回了一句：快捷指令能做到，但 iFlow 写起来更像在写代码，而且能跑后台、能存档、能防误触。
这句话击中了我。用过快捷指令的人都知道，它强在"轻量组合"，但一旦流程里带条件分支、循环、正则、HTTP 请求，甚至要按行解析 JSON，快捷指令的模块拖来拖去简直像拿筷子吃火锅——不是不能吃，是真的费劲。
iFlow 是 iOS 上一款自动化工作流应用，中文名也叫"专注工作流"，核心思路是把复杂任务拆成一个个节点，用连线串起来，形成一个可反复执行、可调试、可导出的流程。它跟快捷指令最大的区别在于：iFlow 更强调"工程化"和"可读性"，每个节点都像函数一样有输入输出，流程里可以插 JavaScript 脚本，还支持真后台运行。
这篇文章我就围绕 iFlow 到底是什么、能干什么、怎么用、以及我用它踩过的坑展开。适合以下读者：快捷指令已经玩腻了但不想学完整编程的人、经常和文本/API/文件打交道的 iOS 用户、以及所有觉得"手机上的自动化应该更硬核一点"的人。
2. 核心概念拆解：iFlow 的设计哲学
2.1 节点：流程的最小单元
iFlow 的所有流程都建立在节点之上。一个节点就是一个独立操作，比如"获取剪贴板""写入文件""发送 HTTP 请求""解析 JSON""格式化日期""分支判断""循环遍历"等等。每个节点左侧是输入，右侧是输出，节点与节点之间通过连线传递数据。
这种设计和 Node-RED、ComfyUI 这类工具是同构的——就是把编程中的函数调用变成了可视化的"积木"。好处是显而易见的：你不用记住语法，只看节点名称就知道它在做什么；坏处也是显而易见的：一旦节点多了，连线会乱成一锅粥，所以 iFlow 单独做了"子流程"机制，可以把一组节点折叠成一个块，降低视觉复杂度。
从实际体验来说，iFlow 最值得表扬的是它的节点文档质量。我见过的很多自动化工具，节点说明写得跟天书一样，但 iFlow 对每个节点的参数、输入输出类型、使用场景都有比较清楚的解释，有的还带例子。这点对于新手特别友好，我最初就是靠挨个翻节点文档入的门。
2.2 流程：像写函数一样组织自动化
在 iFlow 里，一个完整的自动化任务叫"流程"。流程可以接收外部输入（比如剪贴板内容、从别的应用分享过来的文本），也可以完全独立运行（比如定时触发的日报生成）。
流程本身有三个关键属性：
- 输入参数：在流程开头定义好需要接收哪些数据，比如"url""keyword""count"。
- 输出结果：流程跑完之后会产出什么，可以是一个文本、一个文件，也可以是一段通知内容。
- 运行模式：前台运行或后台运行，后台运行是 iFlow 的招牌特性，后面我会细说。
这其实就是"函数"的思维方式。如果你写过任何编程语言，哪怕只写过 Excel 公式，都能秒懂。流程就是一个自定义函数，定义好输入、逻辑、输出，剩下的就是重复调用。
我自己的习惯是：把所有常用操作都做成"参数化流程"。比如，我给"抓取网页标题并生成链接"这个需求做了一个流程，输入是一个 URL，输出是带 Markdown 格式的[标题](URL)。这样每次我在 Safari 里看到好文章，直接分享到 iFlow，选这个流程，结果就自动进了剪贴板。
2.3 后台运行：iFlow 的真正护城河
快捷指令最大的痛点是：跑稍复杂的流程时，必须停留在快捷指令 App 界面，一锁屏就中断。iFlow 对这个问题的解决方案是后台运行机制——流程可以脱离前台界面，在系统后台继续执行，跑完之后发一个本地通知告诉你结果。
后台运行听起来简单，但在 iOS 的沙盒限制下能做成这件事，技术含量不低。iFlow 的做法是巧妙地利用系统的后台任务窗口，把流程拆成可以在后台执行的操作队列，同时限制单个流程的执行时间和资源占用，避免被系统杀掉。
实际用下来，一个 50 个节点以内、不涉及大文件下载的流程，放到后台跑基本没问题。跑完之后通知栏会弹出结果，点开就能看到详细日志。这个特性带来的改变是巨大的：我可以把 iFlow 当成一个"放在口袋里的小服务器"，定时任务也好、数据处理也好，不用盯着屏幕等结果。
3. 场景实操：从零搭一个"每日信息汇总"流程
光讲概念不落地等于白说。这一部分我拿一个我每天都在用的真实流程做演示——每日信息汇总。需求背景很简单：我每天早上需要看几个固定网站的最新文章标题、HN 的热榜、以及某个 GitHub 项目的 star 数，原来要打开三个 App 来回切换，现在用 iFlow 一个流程全搞定。
3.1 流程设计
整个流程的思路是：用多个"获取网页内容/发送 API 请求"节点并行抓不同类型的数据，然后统一拼装成一段文本，最后用"发送通知"节点把结果推送到锁屏界面。
具体节点规划如下：
| 步骤 | 节点类型 | 作用 | 关键参数 |
|---|---|---|---|
| 1 | HTTP 请求 ×3 | 抓取三个信息源的数据 | 请求类型 GET，超时 15s |
| 2 | 正则提取/JSON 解析 | 分别从响应中抽出标题、分数等信息 | 按信息源类型分别配置 |
| 3 | 字符串拼接 | 把三组数据处理成统一格式 | 用换行符和 Markdown 符号 |
| 4 | 通知 | 展示结果 | 标题设为"今日信息汇总"，内容为拼接结果 |
3.2 关键参数说明
HTTP 请求节点：这个节点支持 GET、POST、PUT、DELETE，可以自定义 Header 和 Body。抓取普通网页用 GET 就行，但如果目标站有反爬机制，就需要带 User-Agent 和 Cookie。我的经验是：在 Header 里伪装成正常浏览器访问，把 User-Agent 设为 Safari 的 UA，成功率会高很多。
正则提取节点：用于从 HTML 或纯文本中按规则抽取信息。iFlow 支持 JavaScript 风格的正则表达式。比如你想提取<h2>标签里的内容，表达式可以写成<h2[^>]*>(.*?)</h2>，注意用非贪婪匹配.*?而不是贪婪匹配.*，否则会把同行多个标签一股脑全吞进去。
JSON 解析节点：API 接口返回的数据基本都是 JSON。这个节点支持 JSONPath 语法，比如$.items[*].title可以取出 items 数组里所有元素的 title 字段。新手容易在这里卡住，我的建议是先在脑子里把 JSON 想象成一颗树，JSONPath 就是从树根到你要的节点的路径写法。
3.3 拼接与格式化
三个数据源的数据格式不一样——一个是 HTML 页面，一个是 JSON API，一个是直接返回纯文本的接口。它们不能直接拼接，需要先分别处理成"所见即所得"的文本格式。
我是这样设计的：
- HTML 数据源：先用正则提取所有标题，再用"循环"节点遍历标题数组，每个前面加上
-变成列表项。 - JSON API：直接用 JSONPath 取出数组，同样遍历拼成列表。
- 纯文本接口：直接作为正文段尾。
最后用"模版拼接"节点把三段内容按顺序组合起来，中间用\n\n分隔，保证推送通知里换行正常。这里有个小技巧：通知节点的内容支持简单 Markdown 渲染，加粗标题、列表符号在锁屏界面都能正常显示。
3.4 运行与调试过程
我第一次跑这个流程时，发现 HN 的数据死活抓不到。排查步骤是这样的：
- 单独运行 HTTP 请求节点，查看返回的原始响应。
- 发现返回的不是我预期的 JSON，而是一段 HTML 提示"访问太频繁"。
- 检查请求头，发现我没带 User-Agent。
- 加上了浏览器 UA 后，请求成功返回 JSON。
这个过程在 iFlow 里特别顺畅，因为流程里每个节点都可以单独"运行到此节点"，并且能查看过程数据。这个能力比快捷指令的"逐步调试"要强太多，可以说是我最离不开 iFlow 的原因之一。
4. 工具对比：iFlow、快捷指令、Pythonista 三选一
4.1 对比维度与侧重点
很多人问我：iFlow 和快捷指令到底选哪个？和 Pythonista 比又怎么样？我的回答是：这不是替代关系，而是在不同复杂度层级上的工具选择。
| 维度 | 快捷指令 | iFlow | Pythonista |
|---|---|---|---|
| 上手难度 | 低 | 中 | 高 |
| 可视化程度 | 高 | 高 | 低 |
| 后台运行 | 有限支持 | 强 | 强（需技巧） |
| 脚本扩展 | 极少 | 支持 JavaScript | 完整 Python |
| UI 自动化能力 | 强 | 中 | 弱 |
| 适合场景 | 轻量快捷操作 | 中等复杂度数据处理 | 重度编程 |
4.2 什么时候用 iFlow
我的判断标准非常简单：
- 如果你只需要"发送短信""打开某个 App""调暗屏幕"，快捷指令零成本上手，完全没必要换。
- 如果你需要对数据进行多步处理、调用多个 API、带判断和循环，快捷指令的逻辑模块会把你逼疯，这时候 iFlow 是效率终点。
- 如果你要写几百行代码、用第三方库、做机器学习推理，那直接上 Pythonista 或 Jupyter 更合理，iFlow 的脚本节点更适合做"胶水逻辑"而不是"核心算法"。
我从快捷指令过渡到 iFlow，最直观的感受是"终于能看懂自己写的自动化了"。快捷指令的逻辑模块藏得深，流程一长就变成一串看不出顺序的小图标；iFlow 的节点图可以缩放、折叠、分组，管理起来舒服得多。
4.3 一个典型迁移案例
说个具体例子。我之前在快捷指令里做了一个"翻译并保存生词"的流程：输入英文单词，调用免费翻译 API，再把结果追加到一个备忘录文件里。
流程逻辑很简单，但在快捷指令里跑了两周就放弃了。原因有四个：一是 API 请求的 Header 设置选项少，有些免费接口的鉴权参数加不进去；二是 JSON 解析后无法直接按字段取值再拼接到字符串里，必须经过"获取字典值"模块，非常繁琐；三是没有异常处理，接口一报错整个流程就静默失败；四是锁屏必断，每次都要盯着跑完。
同样一个流程，我在 iFlow 里重写，核心逻辑只花了不到二十分钟：HTTP 请求节点做完鉴权，JSON 解析节点取出译文，字符串拼接节点格式化文本，文件节点以追加模式写入本地 Markdown 文件。整个流程节点数不超过十个，但可读性、稳定性完全是另一个量级。再加上后台运行特性，我甚至不用打开 iFlow，直接在分享面板触发就行。
5. 深度功能解析：脚本、文件与自动化触发
5.1 JavaScript 节点的正确用法
iFlow 内置的 JavaScript 节点可以帮助处理那些可视化节点"表达不了"的逻辑。比如条件判断逻辑比较复杂时——多个条件组合、嵌套判断、需要递归处理数据——用可视化节点会画出一堆线，但用 Script 节点十几行代码就完了。
关键注意事项：
- 同步执行：Script 节点默认是同步执行的，一次只跑一段代码。不要在脚本里发起网络请求并等待回调，那样容易断。
- 数据交互：节点输入的数据会挂载到一个预置对象上，输出则通过返回语句交给下一个节点。
- 能用内置节点就不用脚本：尽量把重活交给专门的节点做，脚本只处理"粘合"工作。
我拿它做过一个经典场景：把一段微信聊天记录导出文本按人分钟数和发言频率排序。这个逻辑用可视化节点写，需要嵌套三次循环；用 Script 节点，二十行代码搞定。但要注意，Script 节点跑复杂循环时，如果数据量过大（比如几万行文本），性能会明显下降，这时候就该考虑拆分成多个流程分批处理。
5.2 文件系统的读写策略
iFlow 支持读写本地文件，文件可以存放在 App 的沙盒目录中，也可以通过"文件"App 共享目录访问。
我建议所有写操作用追加模式，而不是覆盖模式。原因很简单：流程可能因为某个环节出错而重复执行，如果用覆盖模式，上一次的数据就丢了；追加模式配合时间戳字段，每次执行都生成新记录，既方便回溯，也能避免误操作导致的数据丢失。
另外，iFlow 处理 CSV、JSON、纯文本、Markdown 都有对应的解析/生成节点，可以做到一键导入导出。我经常用它抓取网页数据后生成 CSV，再分享到 Numbers 做进一步分析。整个过程不需要电脑，体验相当丝滑。
5.3 触发方式：分享面板、快捷指令、定时
iFlow 的流程可以通过多种方式触发，这也是它实用性的关键。
- 分享面板扩展：在 Safari、备忘录、文件等 App 中选择内容后分享，分享面板里会出 iFlow 的图标，选中后自动跑对应流程。这是最高频的触发方式。
- 快捷指令联动：iFlow 提供"通过 URL 运行流程"的能力，可以把 iFlow 流程作为一个动作嵌入快捷指令里，实现交叉联动。
- 定时触发：设置时间点或时间间隔，到点自动跑流程。我的每日信息汇总就是用定时触发实现的，每天早上 8 点准时报到。
需要特别说明的是，定时触发功能依赖 iFlow 的后台运行机制，但 iOS 对后台任务的管理很严格，定时触发的精度不是 100% 保证的，偶尔会延迟几十秒甚至几分钟。如果任务对执行时间有硬性要求（比如必须在零点整执行），iFlow 不是最稳妥的方案，建议还是用服务端定时任务。但如果只是"每天早上汇总信息给我看"这种级别，延迟几分钟完全无感。
6. 常见问题与避坑指南
6.1 流程突然不跑了？先看日志
iFlow 最值得称道的功能之一，是每个流程都有一份完整的运行日志。日志会记录每个节点的开始时间、结束时间、输入输出快照以及报错信息。流程不跑了，第一件事永远是打开运行日志，定位到第一个报错的节点。
我总结的排查顺序：
- 看第一个报错的节点，而不是最后一个。
- 把节点的"过程数据"点出来，验证输入是否正常。
- 如果输入为空，往上追查上游节点——大概率是数据解析没匹配上。
- 如果输入不为空但报错，检查节点参数类型，比如"文本"和"数字"的混用是最常见的坑。
绝大多数 iFlow 流程失败，原因都是"上游节点输出格式变化"导致下游解析失败。比如某个网页改版了，原来的正则表达式匹配不上了，流程自然不会工作。这类问题不是 bug，是维护问题——所以我的原则是：重要流程做好监控，每天看一次日志，发现异常及时更新规则。
6.2 后台定时不生效？检查这三个地方
后台定时流程不触发，十有八九是这三类原因：
- 通知权限没开：iFlow 跑完流程后靠本地通知告诉你结果，如果通知权限被关，你不会收到任何反馈，还会误以为流程没跑。
- 电池优化限制：iOS 可能会把长时间不用的 App 放进"暂停"状态，导致定时任务不触发。解决方法是把 iFlow 的电池优化关掉，或者定期打开一次 App。
- 流程太复杂：如果流程执行时间太长，后台任务会被系统直接终止。建议把大流程拆成小流程，分多次触发。
如果你配置了定时任务但从来没看到结果，第一步不是检查流程逻辑，而是手动运行一次，确认流程本身没问题，再去查触发条件。
6.3 正则表达式匹配不到？别硬调，先换思路
正则提取节点是 iFlow 里最常出问题的节点。很多人在正则上死磕半天，最后发现是自己把 HTML 的结构想得太单纯了。
我的建议是分三步走：
- 先确认网页源码里实际的长什么样子，把目标内容附近的上下文拷贝出来看（很多网页内容是通过 JavaScript 异步加载的，初始 HTML 里根本找不到）。
- 如果是异步加载的，果断放弃正则，改用"网页内容读取"节点或者直接调它的 API 接口。
- 如果内容确实在 HTML 里但复杂，考虑先做 HTML 转纯文本，再在纯文本上匹配。
正则表达式本身是个值得花时间学习的技能。iFlow 的正则表达式遵循 JavaScript 语法，网上随便搜一篇 JS 正则教程就能入门。但比语法更重要的是"该怎么想"——把"我要匹配什么"翻译成"这段文本的边界在哪"，是解决所有正则问题的钥匙。
6.4 流程运行太慢？优化节点顺序
同一个流程，节点顺序不同，运行效率差异可以超过十倍。我踩过最明显的坑是：先用"解析 JSON"节点处理一个 10MB 的大 JSON 文件，再做数据筛选。后来发现有个专门的数据筛选节点，可以直接在解析前过滤数据，运行时间从 40 秒直接降到 3 秒。
给 iFlow 流程做性能优化的经验：
- 尽早缩小数据规模：先筛选、去重、截断，再进入后续计算。
- 避免不必要的循环：能用内置的 map/filter 类节点，就别手写循环。
- 合理缓存中间结果：如果同一个数据要复用多次，存成文件变量比重复请求/解析高效得多。
7. 我自己的使用心得
用了 iFlow 一年多，它已经成了我手机上除微信外打开频率最高的工具类 App。但我必须坦诚：它不是一个完美工具。
它最大的短板是生态规模。快捷指令有海量的模板库和社区分享，iFlow 的用户量没那么大，很多流程只能自己写。另外，它的 UI 虽然整洁，但对偏好极简的人来说还是偏复杂——更像电脑上的专业软件，而不是手机上那种"傻瓜应用"。
但反过来看，这也是它最大的价值：它不试图取悦所有人，而是服务真正有自动化需求的人。你愿意花一小时学习，它能帮你省下每天十分钟的重复劳动，这么算下来，投资回报率非常可观。
如果你确定要入坑，我的建议是：不要一上来就追求做出大而全的流程，先抄几个简单的、能解决你具体场景的小流程，跑通了再说。等你慢慢熟悉每个节点的作用，你会在某一天突然发现，以前觉得"要写代码才能实现"的事情，现在用 iFlow 拖拖拽拽就做出来了，那种感觉，跟亲手拼好一台机器的成就感是一样的。
最后分享一个我最近一直在用的小流程：每当我在 Safari 里看到感兴趣的文章，我就把网页分享到 iFlow，流程会自动提取正文、生成摘要、保存到我的"稍后读"文件，同时把链接按标签归档。这套流程没有用到任何复杂的技巧，却实实在在地改变了我的阅读习惯。有时候，自动化的意义不在于省了多少秒，而在于它让原本懒得做的事，变得顺手就能完成。
