2.1.2 小红书运营助手实战案例 · 波仔的 Agent+RPA 课

📄 一句话概括

本节把上一节的工时测量变成一个具体案例：一个每周发 3 篇图文笔记的个人账号，用【一张表＋一个 Agent ＋三条 RPA 流程】把单篇准备时间从 120 分钟压到 30 分钟以内；交付物只有三件，而每一件都由 2.2 到 2.4 逐步造出来。

📝 本节和前面几节的关系

2.1.1 看清了【哪一段可以交出去】，本节把它收成一个可以交付的案例——先定账号、定痛点、定目标、定交付物，然后 2.2 设计流程、2.3 造 Agent、2.4 造 RPA。本节的【交付物清单】就是后面三节的任务书：看到某一个交付物，就知道该去哪一节。

一、案例设定：一个真实规模的账号

先声明案例的规模——它决定了方案该有多重：

项	设定	说明
账号类型	个人号，家居好物与收纳分享	不接商单，不做矩阵
更新频率	每周 3 篇图文笔记	不是日更，也不是多账号
每篇图片	5~8 张	远低于平台上限（单条笔记最多 18 张）
运营者	一个人，另外还有本职工作	时间是最稀缺的资源
技术背景	会打字、会用表格，不写代码	与 1.5.1 一致：影刀积木式搭建

📝 为什么要先写这张表

因为方案的重量必须匹配账号的规模。每周 3 篇的个人号，用【一堆脚本＋服务器＋数据库】是过度工程；反过来，日更的多账号矩阵，靠手工也撑不住。先量体裁衣，再谈工具——这是第一章 1.4.2 那句【能用简单方案解决就别上复杂方案】的具体应用。

二、现状：痛点清单

把上一节测出来的时间，翻译成【痛点】：

编号	痛点	现在怎么过	占用的时间
P1	不知道写什么——选题靠【刷到就记】	刷推荐流，看到好的存进收藏夹，真要用时找不到	约 20 分钟/篇
P2	写文案从空白页开始	对着空文档硬憋，反复删改	约 40 分钟/篇
P3	封面不会做	用手机拼图软件反复试，做出来还不好看	约 30 分钟/篇
P4	发布要重复填一遍	标题、正文、标签、图片分四次操作	约 15 分钟/篇
P5	数据不复盘	发完就不看，也不知道哪篇为什么好	约 15 分钟/篇
P6	不敢用 AI 写	网上教程让人【全自动托管】，账号被限流过	心理成本

P6 单独列出来的原因：它不是一个效率问题，而是一个方向问题。本案例的第一个决定就是【放弃全自动，改做半自动】——这个决定不是妥协，而是把方案从【会被封号】拉回【长期可用】。

三、目标：把 120 分钟压到 30 分钟以内

环节	现在	目标	谁来做
找选题	20 分钟	5 分钟	人挑（Agent 提供候选）
写文案	40 分钟	10 分钟	Agent 出初稿，人改
做封面	30 分钟	5 分钟	Agent 出草稿，人挑
排版发布	15 分钟	8 分钟	RPA 填好，人点发布
数据复盘	15 分钟	2 分钟	RPA 归档
合计	120 分钟	30 分钟	—

这张表要说得清两件事：

省下来的 90 分钟，全部来自【不用从零开始】——不是机器替你做了判断，而是机器把【零】变成【草稿】，你只在草稿上改；
人的时间从【生产】移到了【判断】——位置变了，不是责任变了。定选题、定终稿、点发布、回评论仍然是你。

四、交付物：三件，不多不少

编号	交付物	形态	在哪一节造	负责哪几个痛点
D1	素材表	一张表格（Excel 或在线表格）	2.2 定义字段，2.4 使用	P1、P5
D2	内容生成 Agent	扣子上的一条工作流＋一个智能体	2.3.1、2.3.2、2.3.3	P2、P3
D3	三条 RPA 流程	影刀上的三个流程	2.4.1、2.4.2、2.4.3	P4、P1、P5

三件交付物的层级关系：

         ┌──────────────────────────────────────┐
         │  D1 素材表（唯一的真相来源／交接台）    │
         └───────────────┬──────────────────────┘
                         │ 读 / 写
        ┌────────────────┴────────────────┐
        │                                 │
   ┌────▼─────┐                    ┌──────▼──────┐
   │ D2 Agent │◄──── RPA 调用 ─────│  D3 RPA     │
   │  负责【想】│                    │  负责【做】  │
   └──────────┘                    └─────────────┘
                         │
                    ┌────▼─────┐
                    │  人：把关  │
                    └──────────┘

中间那张表不是【顺手存的表格】，它是整套方案的枢纽——Agent 和 RPA 之间不直接对话，全部通过这张表交接（为什么这样设计，2.2 会讲透）。

五、七个环节的分工表

对照第一章 1.7.2 的七步骨架，本章的落地版：

步	动作	谁做	工具
1	写选题与关键词（可从下拉词、同类爆款标题里抄灵感）	人	人脑＋搜索框
2	RPA 把【待创作】的行提交给 Agent	RPA	影刀（2.4.1）
3	Agent 生成标题、正文、标签、配图提示词	Agent	扣子（2.3.1）
4	Agent 按提示词生成封面图草稿	Agent	扣子（2.3.2）
5	RPA 取回结果并写回表、下载图片到本地	RPA	影刀（2.4.2）
6	人审：改终稿、挑封面、查违禁词	人	人脑＋检测工具
7	RPA 填进发布页 → 人点发布 → RPA 记录链接	RPA ＋人	影刀（2.4.3）

请注意第 6 步和第 7 步的最后一跳——这是整套方案里【人】必须出现两次的地方，也是与网上那些【全自动教程】最大的差别。

六、边界：本案例明确【不做】的四件事

不自动发布——RPA 只填到发布按钮之前；
不自动互动——不自动点赞、评论、私信、关注；
不做多账号矩阵——只服务一个自己的账号；
不做数据爬取式采集——不做【批量抓取全网同类笔记】这种动作（涉及平台规则与数据合规），选题灵感用人工少量收集，或使用平台自己提供的创作工具。

⚠️ 这四条不是【暂时不做】，是【不做】

前两条对应平台 2026 年的治理红线（自动发布、自动互动，最重封禁），后两条对应数据合规与账号安全。把它们写在案例的第一页，是为了避免后面越做越顺手、越做越危险——很多账号出事，都是从【就多加一步自动发布吧】开始的。

七、动手 Demo：给你自己的场景写一份【痛点—解法】对照表

准备：上一节 2.1.1 那张工时测量表（如果没做，凭印象也行）。

第一步——列痛点：写下你做这件事时最烦的 3 到 6 件事（越具体越好：【写文案总是开头难】，而不是【效率低】）。

第二步——定目标：给每个痛点写一个可以减少多少分钟的目标。注意：目标是【减少多少分钟】，不是【完全不用管】。

第三步——定归属：给每个痛点标上【全交机器／交草稿／留人】。

痛点              现在(分钟)  目标(分钟)  归属(全交/交草稿/留人)
________________  ____       ____        ____
________________  ____       ____        ____
________________  ____       ____        ____

第四步——写边界：在表格下面用一句话写下你决定不做的事（比如【我不自动发布】【我不做评论区自动回复】）。

看到什么算成功：

至少有一个痛点的归属是【留人】——如果所有痛点你都标了【全交机器】，说明你在设计一个会出事的方案，回去看第六节；
你能说出自己的【枢纽数据】是什么——本案例的枢纽是那张素材表，你的场景里，Agent 和 RPA 靠什么交接？（一个表格、一个文件夹、还是剪贴板）；
你的目标时间是有数的——【减少 30 分钟】这种可验证的目标，比【提高效率】有用得多。

读结果：这张表就是你自己版本的 2.1——后面 2.2 到 2.4 的所有内容，都可以照着它改写。案例不是要你照抄，而是要你抄走这套【从痛点走到交付】的思路。

30 秒实验

看一眼你自己的手机，有没有用 AI 生成过内容并在某个平台自动发布过？

有——去搜一下那个平台的【AI 内容治理公告】，看看今天还允许不允许；
没有——太好了，你的账号还没有历史包袱。

结论：平台规则在 2025 到 2026 年之间发生了方向性变化——从【鼓励效率工具】转向【打击 AI 托管】。任何教程都要先核对它是不是基于今天的规则，这正是本课每节都带【2026 现状】段落的原因。

常见误区

【案例就是照抄一套流程】——错。 应该抄的是【从痛点走到交付】的方法，具体流程要按自己的规模与场景改（每周 3 篇和日更矩阵的方案完全不同）。
【交付物越多越专业】——错。 本案例三件交付物（一张表、一个 Agent、三条流程）就能覆盖六个痛点。多出来的每一个工具，都是以后需要维护的负担。
【先把 Agent 造得完美再连 RPA】——错。 应该【先跑通一条最短的链】（哪怕手工粘一次结果），再逐步自动化。能跑通的一条烂链，胜过三条完美的断路。
【目标定成【完全不用我管】】——错。 目标是【把 120 分钟压到 30 分钟】，而那 30 分钟正是你的价值所在（选题、终稿、发布、回评论）。要砍的是搬运，不是判断。

自测三问（点开对答案）

1. **本案例的三件交付物分别是什么？各负责哪几个痛点？** **D1 素材表**（枢纽，负责选题与数据归档）、**D2 内容生成 Agent**（扣子上的工作流与智能体，负责文案初稿与封面草稿）、**D3 三条 RPA 流程**（影刀，负责提交、取回、填发布页）。 2. **为什么 Agent 和 RPA 之间要【通过一张表交接】，而不是直接互相调用？** 因为表是**可见、可查、可重跑**的中间层：一条数据卡在哪一步一眼就能看到，单行可以重跑，人也能随时插手改。**如果让 Agent 直接调 RPA，中间状态就藏在黑盒里，出错时你既看不见也没法只重跑一条。** 3. **本案例明确【不做】哪四件事？为什么写在第一页？** 不自动发布、不自动互动、不做多账号矩阵、不做批量爬取式采集。**因为前两条是平台的治理红线（最重封禁），后两条涉及合规与账号安全；写在第一页是为了防止后面越做越顺手时顺手加进去。**

☐ 下一节（2.2 小红书运营增效助手工作流程设计）