一、这条流程干什么

二、流程骨架：七步

① 打开素材表（Excel 或在线表格）
        │
        ▼
② 读取整张表（拿到所有行）
        │
        ▼
③ 循环每一行
        │
        ├── ④ 判断：状态 ≠ 待创作？ → 跳过，进入下一行
        │
        ├── ⑤ 把该行状态改成【生成中】，立刻保存
        │
        ├── ⑥ 发 HTTP 请求调用 Agent 工作流（传 4 个参数）
        │
        └── ⑦ 收到结果 → 交给 2.4.2 的解析逻辑写回表
        │
        ▼
   日志：本批共处理 N 行，成功 M 行，异常 K 行

这七步里，④⑤⑦ 三步是【防翻车】的三道闸门，比 ①⑥ 重要得多。

三、④ 判断：为什么必须有这一步

RPA 的循环最危险的地方是【它不认路，只会按顺序走】。 如果循环里没有判断，你第二次运行时会把已经处理过的行再处理一遍——重复提交既浪费额度，又可能把已经审好的内容覆盖掉。

判断的写法（一句话就够）：

如果 当前行.状态 不等于 "待创作"：
    写日志【跳过第 N 行，状态为 xxx】
    进入下一行

另外两个值得加的跳过条件：

四、⑤ 先改状态，还是先干活

这是一个顺序问题，两种做法都对，但适用场景不同：

本案例选 A。 理由：

• 重复提交的危害更大（覆盖已审内容、浪费额度），而悬行是看得见、也好处理的——它明明白白写着【生成中】，你一眼就知道该回退成【待创作】还是手动收尾；
• 看不见的错误比看得见的错误危险（第一章 1.4.2 的异常处理思路）。

五、⑦ 错误隔离：一行坏，不能带倒一整批

循环里最容易犯的错，是【一个错误直接中断整个流程】。 一旦第 3 行报错，第 4 到第 30 行全部不跑——而你往往要等十几分钟后才发现。

正确结构：

循环每一行：
    尝试：
        改状态 → 调接口 → 解析 → 写回
    捕获异常：
        把该行状态改成【异常】
        把错误原因写进备注列
        写日志
        继续下一行          ◄── 关键在这一句

同时配两条纪律：

六、表格即接口：提交时传什么

参数要传全，一次说清。 对应 2.2 那张表的四个输入字段：

七、⚙️ 2026 现状：影刀上的这几件事

• 版本节奏：影刀目前是 v6.2.x（2026-09 仍在更新），个人版免费即可完成本案例；已累计迭代 300 多个版本；
• 积木式搭建：本节用到的【读取表格／循环／HTTP 请求／写入单元格／写日志】都是现成指令，不需要写代码；需要处理复杂文本时，可以在指令里嵌一段 Python（2.4.2 会用到）；
• 应用市场与场景案例库：平台上有现成场景可参考，先抄一个相近的再改，比从空白页开始快；
• 调度（定时运行）：影刀有调度能力可以定时启动流程——但本案例的定时只做【提交与取回】，不做【填发布页】，更不做【点发布】（原因见 2.4.3）；
• 调用 Agent 的前提：扣子那边要把工作流发布并拿到接口地址与授权凭据，影刀这边才能调。具体入口与凭据形式以你打开时的界面为准。

八、动手 Demo：读 3 行，提交 1 行

准备：一张素材表（4 列输入 ＋ 状态列），3 行测试数据；一条已经发布、能拿到接口地址的 Agent 工作流。

id  选题            关键词              风格     字数  状态
001 小户型玄关收纳   玄关收纳,小户型      亲切干货  400   待创作
002 露营装备清单     露营,装备,新手      清单体    500   待创作
003 （空行）         （空）              （空）    （空） 待创作

第一步——读表：用【读取表格】指令把整表读进一个变量，先打印行数，确认 3 行都读到了。

第二步——建循环：循环每一行，第一件事就是打印当前行的 id 与状态（这一步能省掉大量调试时间）。

第三步——加判断：状态不是【待创作】、或者选题为空 → 跳过并写日志。（按上面的数据，003 应该被跳过。）

第四步——改状态：把 001 的状态改成【生成中】，立刻保存表格。

第五步——发请求：用【HTTP 请求】指令调用 Agent 工作流，四个参数从当前行取。

第六步——看返回：把返回的原始文本存进备注列（先不解析，本节只验证【能拿到】）。

第七步——跑一次看日志：应该看到【处理 3 行 → 跳过 1 行（空选题）→ 成功 1 行】。

看到什么算成功：

1. 空行被跳过了，没有报错、也没有被提交；
2. 返回的原始文本里能看出四个字段的名称（说明 Agent 正常回话了）；
3. 表里的状态确实变了（001 变成【生成中】或【待审】）；
4. 再点一次运行：001 已经不是【待创作】，它不会再被提交一遍——这就是第四节那道闸门生效的证据。

读结果：本节只做到【能拿到返回的原始文本】。把它变成表里整齐的四列，是下一节 2.4.2 的事。 分两步走的理由和 2.3.1 一样：一次只解决一个问题，出错时才能定位。

30 秒实验

在循环里故意制造一次失败——把接口地址的最后一位改掉，然后运行。

• 整个流程当场中断、后面的行一行没跑——说明你还没做错误隔离，回去看第五节，把【捕获异常 → 标异常 → 继续下一行】补上；
• 流程跑完了，那一行被标成【异常】并写了原因，其余行正常——很好，这就是【一行坏不带倒一整批】。

结论：自动化流程的价值不体现在【顺利时跑得快】，而体现在【出问题时坏得住】。 一个没有错误隔离的批量流程，跑 30 行和跑 3 行是一样的风险。

常见误区

1. 【循环里不判断状态，反正我只跑一次】——错。 你一定会跑第二次、第三次。没有判断的循环，第二次运行就是在重复提交。
2. 【失败了就整体中断，回头再跑一遍】——错。 整体重跑会把已经成功的那部分再做一遍。正确做法是错误隔离 ＋ 只重跑异常行。
3. 【先调用、成功了再改状态，避免留悬行】——不是错，但本案例不采用。 它换来的是【中途崩溃就重复提交】。重复提交会覆盖已审内容，比留一个看得见的悬行严重。
4. 【把授权凭据写在流程里方便看】——错。 凭据等于密码，放环境变量或凭据管理，流程里只引用变量名。
5. 【表格里多几个空行无所谓】——错。 空行会被当作【待创作】提交，白白消耗额度，还会在 Agent 那边产生莫名其妙的输出。用【选题为空就跳过】挡掉。

• ☐ 下一节（2.4.2 RPA获取创作结果）

相关笔记

• RPA与Agent交互 —— 【RPA 调 Agent】模式与接口四约定
• RPA 的核心能力 —— 异常处理三件套与幂等，本节是它的落地
• 小红书运营增效助手工作流程设计 —— 状态机与字段表的出处
• 🤖 Agent+RPA实战 · 索引 —— 全课路线图