一、八条必须记住的结论

按篇序，每篇至少一条：

如果只记一条，记这条：

【内容可以试错，数据不能。所以这一章的每一步都是"先检查、后动作"——把错误拦在"写进系统"之前，因为写进去之后的成本，不是重做，是冲销。】

二、一条链与两个把关点

本章的完整链路：

① 人整理收件目录（把单据收进来）                          → 待处理
② 6.4.1 送单前三查（在不在／对不对／重不重）→ 送 → 任务号    → 已提交
③ 6.3.1 识别工作流（看→认→写，强制 JSON）                 → 已识别
④ 6.2   业务校验（用规则：合计平不平、税率合不合法）        → 已校验
⑤ 6.4.2 取回判档（通过／待人／重试）＋ 对账                 → 已判档
⑥ ── 人处理异常表上那几条（看原图、补主数据）──          ← 把关点 ①
⑦ 6.4.3 填报前预检（A 组／B 组）→ 干跑 → 真填             → 已填报
⑧ 回挂影像（备注里写原图地址）                            → 已留痕
⑨ ── 人点【审批／保存】──                              ← 把关点 ② ＋ 最后一下

注意这条链和前五章最不一样的地方："人"出现的位置从"每次一节"变成了"只在异常时"。

三、字段与术语速查表

异常表字段（本章版：异常组 ＋ 源组 ＋ 处置组）：

关键术语：

四、常见误区（本章汇总）

1. 【采购订单识别就是把字认出来】——错，认字只是第一步。 真正的时间花在【认出来的名字要能对上系统里的编码】（6.1.1：查编码占 32.3%）。"识别对了但主数据没有"是最常见的失败，而它不是识别的问题（6.4.2）。
2. 【金额不一致就取一个】——绝对不行。 "订单合计 1200、识别合计 1356"，取哪个都是替业务做决定。这类必须停下交人——因为哪个数对，只有原单说得清。6.3.1 那句"禁止虚构、推断、补全"，在代码里就是"不许猜"。
3. 【解析失败就交人，反正人比机器靠谱】——浪费人的时间。 解析失败大多是"模型这次话说得不规矩"，重发一次多半就好。判据永远是那条：重跑一遍能不能修好。
4. 【结果丢失会报错，不用专门查】——它根本不报错。 一条结果静悄悄地没了，那张单既不在 ERP 也不在异常表——等到供应商来催款已经是三个月后。所以每轮必算那行加法。
5. 【调用工作流和调用智能体是一回事】——不是，接口族不同。 而且入参出参是动态 schema，以部署页面的参数说明为准——未发布的工作流调不了，会报 4200。
6. 【API Token 写进脚本方便】——绝对不行。 扣子的 Token 只显示一次、永久有效、每项目上限 10 个——泄露了别人就能拿你的额度跑你的工作流。
7. 【RPA 用人的账号最方便】——这是审计上最忌讳的一条。 分不清"是张三填的还是机器人填的"，一出问题就查不清。2026 年超 40% 的企业在 RPA 规模化时撞上审计或合规阻碍，大多栽在账号与日志上。
8. 【坐标点击最省事】——坐标最脆弱。 记住顺序：能抓元素就不要截图，能截图就不要点坐标。 RPA 脚本的寿命，取决于它绑定的东西有多稳定。

五、动手 Demo：给自己出一张【第六章试卷】

做法：把下面九道题的答案写在一个纯文本文件里，不看笔记回答；答不上来的，回去翻对应的一篇。

一、判断题（对／错）

1. 采购订单识别出错了，像文章发错一样删掉重做就行。
2. 主数据里没有这个物料编码，说明模型识别错了。
3. 一条识别的 JSON 里多了一个尾逗号，应该把它归到"待人"那一档。
4. 只要把单据图传给大模型，它就能准确读出型号里的每个字符。
5. RPA 填 ERP 需要 ERP 厂商先开放接口。

二、填空题

1. 本章异常表比前五章任务表多出的两个关键字段是 __ 和 ____。
2. 送单前三查是：__ 、 _ 、 ；其中"重不重"要按 ___ 判断。
3. 对账纪律的公式是：__ ＋ _ ＋ ＝ ___。

三、情景题

1. 一张单识别得好好的，字段置信度都在 0.95 以上，但行小计加起来与合计栏差 156 元。它该走哪个档？为什么？如果把它丢进"重试"会怎样？

参考答案：

看到什么算成功：九题里你能答对七题以上，而且第 9 题能说出【判据是重跑能不能修好】这个理由——说明你已经不是在记流程，而是在用判断。

六、回顾：前六章其实是一张图

前六章走下来，做的是同一件事，只是对象换了六次。

      第一章        第二章      第三章      第四章      第五章      第六章
      ─────       ─────      ─────      ─────      ─────      ─────
对象  概念        小红书      公众号      今日头条    知乎        采购订单
形态  认与做      点界面      调接口      点界面×N    点界面      写系统
矛盾  ——          没接口      有接口      数量        质量        准确与合规
出口  停          停在发布前  进草稿箱    进草稿箱    停在发布前  写进 ERP
最贵
的错  ——          发出去      排版全废    信用分受伤  踩处置档    账上多一笔

三条从头贯到尾的主线：

前六章的一句话总纲：

【Agent 负责想，RPA 负责做，人负责判断——而每次判断的分量，取决于这件事"能不能撤销"。】

30 秒实验

把第一章到第六章的出口排成一列，只看一件事："最后那一下"是人点的还是机器做的。

第二章：点【发布】         → 人
第三章：点【群发】         → 人
第四章：进草稿箱           → 机器（但发布由人）
第五章：点【发布】         → 人
第六章：点【审批／保存】    → 人

问自己一个问题：六章里，有没有哪一章的最后一下是机器自己做的？

• 如果你的答案是【第一章，因为它不讲案例】—— 对了一半。再想一层：第一章定的是分工原则（1.6.1 三种交互模式），它从第一课就把"最后一下归人"写进了设计里。
• 如果你的答案是【本来就不该有】—— 更准确。六章下来，机器接走的活越来越多（填表、排版、取稿、预检、识别、填单），但没有一章让机器做"不可撤销的那个动作"。

结论：这不是巧合，是这门课最核心的一条设计原则——自动化能走多远，取决于你能把"不可撤销的动作"识别得多准。 识别得准，你就能让机器一直往前推，只把最后一下留给人；识别不准，你要么不敢自动化，要么就出了事。

常见误区（本章级）

1. 【这一章太复杂，比前五章难得多】——难的不是技术，是"容错率"。 前五章的错都能改，本章的错要冲销。同一套骨架（Agent ＋ RPA ＋ 人把关），换了对象就换了难度。看清楚这一点，比记住那些字段名有用得多。
2. 【异常表越大越安全】——错，异常表太大等于没有异常表。 如果 80% 的单都进异常，人就会闭着眼点——那"人把关"就变成了形式。 阈值要卡在"人处理得完"的量上——这是本章和 4.2 那条"批量要克制"一脉相承的地方。
3. 【这一章的细节太多，记不住】——不必全记。 记不住的（扣子的接口路径、ERP 输入框的位置、授权额度具体多少）都会变，也都可以现查；真正要记住的是三件事：判档的判据、对账的公式、A/B 分组。 细节是查得到的，判断是查不到的。
4. 【这套东西只适合大公司】——不是。 6.1.1 的工时拆解（读字 43.6% ＋ 查编码 32.3%）在任何规模的采购场景里都成立；6.1.2 那个"月 500 张约 4.5 个月回本"的测算里，真正的门槛是"量"，不是"公司大小"。量到了就值得做，量不到就先别急（S1 那个"首年净省 −4.8 小时"的例子就是提醒）。

• ☑ 第7章 应用实战：财报分析智能体 —— 已完结：财报分析智能体场景概述（本章第一次处理【别人写的公开文件】，并把【每条结论都要能指回原文】写成了纪律）

相关笔记

• 采购订单智能填报概述 —— 本章的起点：产出口为什么从内容变成了数据
• 采购订单智能填报助手整体流程设计 —— 全章的结构总图（七节点 ＋ 新增的业务校验格）
• 采购订单智能识别工作流 —— 本章技术含量最高的一节（看→认→写）
• RPA获取扣子识别结果 —— 本课反复出现的那条判据与对账纪律
• 本章小结 —— 上一章的小结，两章对照着读
• 财报分析智能体场景概述 —— 下一章的起点：第一次加工【别人写的公开文件】
• 本章小结 —— 下一章的小结，两章对照：一个错在数字，一个错在结论
• 🤖 Agent+RPA实战 · 索引 —— 全课路线图