OpenClaw Skill 自动化:公众号日更压到20分钟

📅 2026-10-23

先说结论：我们把公众号日更做成了一套 OpenClaw 自动化流水线，每天从选题、配图、写稿、门禁到出 Word 全自动跑完，一次人工介入都不需要。原来一篇稿子从选题到能发要 3 小时，现在压到 20 分钟以内，剩下的时间只是人工通读一遍。

这篇不讲 OpenClaw 是什么，只讲我是怎么搭的、你照着做能得到什么、哪里会踩坑。

✦ ✦ ✦

▎ 一、先看清楚：这套流程到底省在哪

原来写一篇公众号，流程是这样的：

选题（翻半小时）→ 找素材（再半小时）→ 搭结构写初稿（一小时）→ 配图（三张图跑两轮）→ 排版导 Word（半小时）→ 通读查错（半小时）。

3 小时里，真正需要人脑的只有两个动作：决定写什么、和最后通读确认。剩下全是搬运。

所以自动化的目标很明确：不是让 AI 代替你思考，是让 AI 干搬运。

我们把它拆成了 5 个环节，每个环节交给一个专职的 OpenClaw 子 Agent（我们叫 sub-agent）：

关键是每个 Agent 只干一件事，且只读上游的产出文件，不共享上下文。

✦ ✦ ✦

▎ 二、第一步：把 Skill 写清楚，比把 Agent 调通更重要

OpenClaw 里一个「干活的」单位叫 Agent（子 Agent），一个「干活的流程」叫 Skill（技能包）。

很多人搭自动化第一个坑就是：在 Agent 的提示词里写了一堆规矩，结果 Agent 干活干到一半忘了。

我们的做法是反过来的：规矩写进 Skill，Agent 只负责触发。

一个 Skill 的最小结构就是一个 markdown 文件：

---

name: yangsheng-tietu-batch

description: 养生贴图 Word 文档批生产，无叠字 + 门禁 + 附件交付。

---

# 养生贴图批生产

## 铁律（违反任何一条算失败）

1. 配图绝不后期叠字

2. 每张图必须逐张验字

3. 走门禁脚本，exit 0 才交付

## 出图命令

$PY generate_image_v3.py --type cover --aspect 3:4 --output "$D/images/00_cover.jpg" --prompt "..."

关键在 description 那一行 —— 它是 OpenClaw 决定「该不该用这个 Skill」的依据，写得含糊了，Skill 就永远不会被触发。

⚠️ 实测踩坑：我们最初把 description 写成「辅助工具」，结果 30 天里这个 Skill 一次都没被自动触发过。改成一句话说清「什么时候用我 + 我干什么」，第二天就触发了。

✦ ✦ ✦

▎ 三、第二步：用 cron 把环节串起来

Skill 定义了「怎么做」，cron 定义了「什么时候做」。

我们给公众号日更排了 4 个 cron，时间是错开的：

# 16:40 抓选题（读缓存，不实时调外部 API）

- cron: "40 16 * * *"

script:fetch_ai_news.py

# 16:50 挑选题并锁定

- cron: "50 16 * * *"

script:auto_pick_topic.py

# 17:30 写稿 + 配图 + 门禁 + 出 Word

- cron: "30 17 * * *"

script:run_article_delivery.py

# 19:10 复核门禁 + 推飞书

- cron: "10 19 * * *"

script:verify_and_push.py

错峰是硬要求，不是优化。我们同时跑 3 个 cron 撞同一个 API 套餐，直接吃到限流，一次挂了 53 分钟。所以每档之间至少留 10 分钟，且同一天内不允许两个 cron 用同一个模型配额。

✦ ✦ ✦

▎ 四、第三步：给每个环节装一个「不许偷懒」的检查

自动化的最大风险是 Agent 假装自己成功了。我们被这个坑过至少 5 次。

具体表现是：脚本返回成功，但文件根本没落盘；或者 Agent 在回复里说「已完成」，其实一步都没跑。

现在每个环节都强制跑一个检查脚本，退出码不为 0 就当失败：

# 检查图片是否真的落盘 + 尺寸对不对

$PY check_images.py "$D" --account=ai

# 检查成稿门禁（字数/配图数/内容合规）

$PY gzh_gate.py "$D/draft.md" --account ai --docx "$OUT"

echo ">>> exit=$?"

# 检查 Word 成品有没有被偷偷加东西

$PY verify_docx_clean.py "$OUT" --expect-images 3

⚠️ **千万不能这样写**：`gzh_gate.py draft.md | grep 标题`

这样拿到的是 grep 的退出码，不是门禁的退出码。我们踩过一次，明明门禁 FAIL，但管道一接，Agent 看到 exit=0 就当通过了继续往下走。

正确写法是先重定向再取码：

```bash

$PY gzh_gate.py "$D/draft.md" > /tmp/gate.txt 2>&1

ec=$?

```

✦ ✦ ✦

▎ 五、踩过的 4 个坑（都是真金白银换来的）

▶ 坑 1：Skill 的 description 写虚了，永远不触发

见上文。一句话说清「什么时候用 + 干什么」，别写「辅助工具」这种废话。

▶ 坑 2：cron 里跑实时外部 API，必然挂

我们有一次在选题环节直接调外部的MCP接口，结果任务挂了 53 分钟，最后报错是「工具结果还在等待中，转断了」。

根因是外部 API 响应慢，加上调用要审批，整个环节挂在那儿等。

正路：把「进料」和「消费」分开。 进料是一个独立的、定时跑的流程，负责把素材存成文件；写稿的 cron 只读本地文件，不碰外部 API。宁可素材旧一天，也不能让写稿环节卡死。

▶ 坑 3：脚本路径必须放在允许的目录里

OpenClaw 的 cron 有安全校验，脚本路径会被检查真实路径（会解析软链接）。用软链接绕是绕不过去的。

正路：写一个 wrapper 脚本放在允许目录里，里面再用 subprocess 调真正的脚本。

# ~/.OpenClaw/scripts/cron_wrap_fetch.py

import subprocess, sys

r = subprocess.run([sys.executable, "/真实路径/fetch_ai_news.py", *sys.argv[1:]],

capture_output=True)

print(r.stdout.decode(), r.stderr.decode())

sys.exit(r.returncode)

▶ 坑 4：报告「跑通了」不等于「有产出」

有一次 cron 显示 success: true，我们以为一切正常。实际上那次是静默退出，什么都没做。

正路：验收点必须落在产物上，不在日志上。

# ❌ 不够：只看 cron 返回成功

# ✅ 够：查产物 + 查门禁状态

ls -la "$D"/draft.md

$PY -c "import json;print(json.load(open('/path/to/job.json'))['last_status'])"

⚠️ cron 显示成功但实际 `last_status: error` 的情况我们遇到过，所以这两件事必须分开查。

✦ ✦ ✦

▎ 六、这套东西适合谁，不适合谁

适合：

·内容生产有固定流水线的人（公众号、头条、小红书、多平台分发）

·每天重复劳动多、但判断权要握在自己手里的人

·愿意花一周时间把流程拆清楚的人

不适合：

·一次性任务 —— 为一件事搭自动化，成本远高于手动做

·需要大量主观判断的活 —— AI 干不了判断，只干得了搬运

·不愿意检查的人 —— 自动化不做质检 = 批量生产垃圾，我们见过跑量跑到账号被限的

最后这句是重点。自动化让你从 3 小时压到 20 分钟，但这 20 分钟你干什么，决定了结果是「省时间」还是「废号」。我们的做法是把这 20 分钟全用在通读上：查数据有没有编、查来源有没有泄漏、查结论站不站得住。

机器负责跑得快，人负责别跑偏。这两件事分开，才叫自动化；混在一起，就叫失控。