一、先看清两条腿

本章的自动化分成左右两半，各自在各自的软件里干活：

        ┌────────────────── GPT 平台（Agent 侧） ──────────────────┐
        │                                                          │
        │   公众号写作助手（3.3）                                   │
        │   ├─ 角色指令：公众号作者的人设与写作规则                  │
        │   ├─ 知识文件：过往文章、品牌调性、禁用词表                │
        │   └─ 多轮对话：先出提纲 → 再扩写 → 再改                 │
        │                                                          │
        └──────────────────────────┬───────────────────────────────┘
                                   │
                    ┌──────────────┴──────────────┐
                    │   一张表（交接台，本章核心）  │
                    │   字段 ＋ 状态 ＋ 备注        │
                    └──────────────┬──────────────┘
                                   │
        ┌──────────────────────────┴───────────────────────────────┐
        │                   影刀 RPA（执行侧）                      │
        │                                                          │
        │   3.4.1 提交创作信息  ── 把选题与要求送进去                │
        │   3.4.2 多轮对话取结果 ── 追问、取回、解析                │
        │   3.4.3 排版创作结果  ── Markdown 转内联样式 HTML        │
        │   3.4.4 公众号发布    ── 建草稿箱，人点发布              │
        │                                                          │
        └──────────────────────────────────────────────────────────┘

为什么两条腿不直接连：因为 RPA 不该关心 Agent 长什么样，Agent 也不该知道 RPA 怎么跑。中间隔一张表，两边都可以独立换——你把 GPT 换成扣子智能体，下面的四条流程一行都不用改。

二、与第二章的分工对照

把本章与上一章并排放，差别一眼看得出来：

三处结构性差异，各自对应后面的一节：

1. 多轮对话 → 3.4.2（长文一次写不好，必须分步）；
2. 排版工序 → 3.4.3（公众号不吃 Markdown）；
3. 接口出口 → 3.4.4（草稿箱 API，人点发布）。

三、交接台：这张表上有什么

本章的表比第二章多几列，多出来的每一列都有明确用途：

四、状态机：八态

沿用第二章的做法，一行数据在流程中只可能处于八种状态之一：

两个关键设计：

1. 【待审核】是一个独立的、必须由人推进的状态——它不是流程中的装饰，而是红线二（留人把关）在状态机上的落点。任何一行数据都不能从【已排版】直接跳到【已入草稿箱】；
2. 【异常】不是一个终点——它的作用是让坏数据停下来、并带着原因停在表上等人。RPA 遇到异常时绝不跳过、绝不猜测，只做两件事：写备注、改状态。

五、完整链路：一次走完

把九个环节串起来，一次完整的运行长这样：

① 人填表（选题/关键词/风格/字数）         → 状态：待提交
② 3.4.1 RPA 提交创作信息                  → 状态：已提交
③ 3.4.2 RPA 多轮对话（提纲 → 扩写 → 定稿） → 状态：对话中
④ 3.4.2 RPA 取回并解析最后一轮            → 状态：初稿就绪
⑤ 人审初稿（改错、补事例、定调）           → 状态：初稿就绪
⑥ 3.4.3 RPA 排版：Markdown → 内联样式 HTML → 状态：已排版
⑦ 人审排版（并在后台预览）                 → 状态：待审核
⑧ 3.4.4 RPA 建草稿箱（含 AI 声明）         → 状态：已入草稿箱
⑨ 人登录公众号后台，核对后点【发布】       → 状态：已入草稿箱

注意 ⑤ 和 ⑦ 两处，都是【人】。第三章一共留了两个人工关卡，比第二章（也是两个）持平——但性质变了：第二章的两个关卡是【内容审核】和【发布确认】，本章的两个是【内容审核】和【排版审核】，最后一下发布在平台后台里点（因为接口没权限）。

六、三个设计决策，以及为什么

七、⚙️ 2026 现状：本章涉及的三处平台变化

1. GPT 平台：自定义 GPT 正在退役，个人账号已冻结创建与发布。教材 3.3 的两个小节（创建／预览保存）按【学思维不学按钮】处理，并给出替代路线（详见 3.3.1、3.3.2）；
2. 公众号接口：draft/add（建草稿）个人订阅号可用；freepublish（发布）自 2025-07 起对个人主体与未认证账号已回收。本章的出口设计正好落在这个现状上（详见 3.4.4）；
3. 排版工具：Markdown 转公众号 HTML 的成熟工具在 2026 年已经很多（在线编辑器类、命令行类、开源类），本课选【用代码自己转】——理由不是【没有工具】，而是只有自己转才能做到【字段级可控＋可被 RPA 调用】（详见 3.4.3）。

八、动手 Demo：把这张表和状态机落成一份可用的 CSV

准备：任意表格工具（Excel、WPS、腾讯文档都行）。

第一步——建表：把第三节那张字段表原样建成一列一列的表头（16 列，顺序照抄）。

第二步——填两行样本：

第三步——走一遍状态：把第一行的 status 依次手工改成：已提交 → 对话中 → 初稿就绪 → 已排版 → 待审核 → 已入草稿箱。每改一次，问自己一句：这一步是谁在改？

看到什么算成功：

1. 改到【已排版】时你停了一下——因为你知道必须先过人审才能进【待审核】。这个【停一下】就是状态机在起作用；
2. 你能说清八态里哪两个是【人】在推进（初稿就绪 → 待审核这一段，和最后的点发布）；
3. 你能指出哪一列是合规要求（ai_declare）。

读结果：这张 CSV 就是本章后面四条 RPA 流程唯一的输入与输出。先把表结构定死，再去写 RPA——顺序反了，你会一边写流程一边改字段，最后两边都对不上。

30 秒实验

看下面这行状态，说说问题在哪：

id=003  topic=职场沟通  status=已入草稿箱  ai_declare=（空）  digest=（空）

答案：这一行跨越了【待审核】——它没有 ai_declare，说明没有人确认过 AI 声明，却已经到了草稿箱。同时 digest 为空，推送卡片上会显示自动截取的正文开头。

结论：状态机的价值不在于【记录进度】，而在于【拦截跳跃】。 一行没有经过人工确认的数据，不允许出现在草稿箱里——这个约束写在表结构上，比写在人的记忆里可靠。

常见误区

1. 【让 Agent 直接把排版也做了，省一道工序】——错。 排版是规则不是创意，用大模型做规则转换，输出会不稳定。3.4.3 专门用代码来做这件事。
2. 【多轮对话太麻烦，一次写完就行】——错。 公众号是长文，一次写完的质量不可控。拆成【提纲 → 扩写 → 修改】三轮，每一轮都能拿出来检查，出问题时也能定位到是哪一轮坏了。
3. 【摘要随便填，反正正文里有】——错。 摘要在推送卡片和分享卡片上都会显示，接口限制 120 字；不填时平台自动截取正文开头，效果通常很差。它是一个独立的字段，值得单独生成。
4. 【AI 声明可以放到最后统一处理】——错。 它必须是一个字段（ai_declare）、一个状态关卡（待审核）、一个具体动作（发布时勾选声明）。放到最后统一处理，等于没有处理。
5. 【两条腿应该直接连起来，省掉中间的表】——错。 表是解耦器：RPA 不需要知道 Agent 长什么样，Agent 也不需要知道 RPA 怎么跑。把中间的 GPT 换成扣子，下面的四条流程一行都不用改。

• ☐ 下一节（3.3.1 创建 GPT）

相关笔记

• 小红书运营增效助手工作流程设计 —— 本章沿用同一套【表当交接台＋状态机】方法
• RPA与Agent交互 —— 三种交互方式，本章选的是最稳的那种
• 工作流编排 —— 【需要创意用模型、需要确定用代码】的出处
• 公众号创作智能助手场景概述 —— 两条红线的完整说明
• 🤖 Agent+RPA实战 · 索引 —— 全课路线图