OpenClaw 小红书自动化技能包:趋势抓取、AI文案与发布全流程解析

发布时间:2026/10/7 3:06:31
OpenClaw 小红书自动化技能包:趋势抓取、AI文案与发布全流程解析 简介这是一份面向小红书内容运营者与开发者的 OpenClaw 自动化技能包用于解决账号批量管理、定时发布、内容抓取等重复劳动问题。它通过浏览器调试协议实现自动填写标题正文、上传图片、添加话题标签还支持多账号隔离、无头模式运行、远程调试连接以及图片防盗链绕过。压缩包共 68 个文件主体是 46 个 Python 源码文件另有 6 个说明文档、3 个安装脚本以及配置文本等辅助文件整体大小仅为 167KB目录结构清晰方便按需调用和二次开发。已有 104 人学习下载。技能包内置登录状态十二小时缓存和登录二维码导出能自动检测登录状态抓取首页推荐流、搜索笔记详情与评论支持回复评论、点赞收藏、查看用户主页快照并将曝光、观看等数据表导出为 CSV可直接嵌入 OpenClaw 工作流适合中高级开发者快速搭建小红书自动化运营矩阵。1. 小红书 Skills为什么 OpenClaw 需要一套专属内容自动化技能做小红书运营的朋友找到我说每天光是想“今天发什么”就能耗掉两小时。我建议他别急着用浏览器插件先试一套开箱即用的 OpenClaw 小红书技能包。这套名为 Xiaohongshu automation skill for OpenClaw 的资源拿到的第一眼我就觉得它比普通爬脚本多走了一步——它把热门趋势抓取、AI 初稿生成、人工审核、定时发布串成了同一条流水线。它解决的场景很具体你想盯住某个关键词的“热度走势”让 AI 按小红书语气出几版文案再由你决定发不发。适合人群也很明确一是自己运营账号但缺选题的内容从业者二是刚把 OpenClaw 部署起来、想接一个真实业务技能的 AI agent 玩家。接下来我会从技能包目录拆起讲清每个文件是干什么的、参数怎么调再把我复现过程中踩过的坑原原本本列出来。2. 拆包看原理skill 目录、运行时序与 AI 代劳的边界2.1 技能包在 OpenClaw 里的加载路径不管是 OpenClaw 桌面版还是跑在 Docker 里的服务端技能包的本质都是一组文件放进指定目录。常见做法是把压缩包解压到skills/xiaohongshu下OpenClaw 通过目录里的SKILL.md识别技能名称、触发词和调用方式。你先别急着改代码先确认你的 OpenClaw 能找到这个目录。以官方默认配置文件来说技能根目录通常能在openclaw.yaml里用skill_paths指定没配过就走安装目录下的skills文件夹。我一般会在解压后立刻执行一次openclaw skill list看它有没有被加载。如果列表里没有小红书大概率是SKILL.md里的name字段和目录名不一致或者 YAML 语法有问题。这里补一名刚接触 OpenClaw 的读者容易忽略的点技能包不是放进去就生效很多版本需要重启对应的服务进程Windows 上用 Companion 的同学尤其要注意右下角托盘是否已经退出。# 假设你的 OpenClaw 安装在 C:\openclaw cd C:\openclaw\skills # 手动解压后目录结构应该长这样 tree xiaohongshu-skill如果tree命令在你的 PowerShell 里不可用用Get-ChildItem -Recurse也一样。看目录结构只是为了确认文件齐全真正决定行为的是下面几个文件。2.2 四个核心文件SKILL.md、config.yaml、两个 Python 脚本我把这套技能包拆开看过真正参与主流程的只有四个文件SKILL.md负责告诉 AI 什么时候触发、按什么顺序调脚本config.yaml存关键词、模型、温度这类参数fetch_trend.py负责把“趋势”拉成本地结构化数据generate_post.py负责把数据变成小红书风格文案。发布环节则靠一个publish_hook.py在你审核完之后执行这个我会放到第 5 章细讲。SKILL.md的内容很简单本质上是一份给大模型看的操作手册。# 小红书热门内容技能 - name: xiaohongshu_trending - 触发词: 小红书趋势, 小红书热点, 今天发什么 - 执行步骤: 1. 读取 config.yaml 里的 keywords 和 top_k 2. 运行 python scripts/fetch_trend.py --config config.yaml 3. 把结果整理成 markdown 表格列出笔记标题、热度分、来源链接 4. 询问用户是否继续生成文案 5. 若确认运行 python scripts/generate_post.py --brief 用户输入的主题这里的关键是第 4 步它把决策权留在人类手里。很多翻车案例都是让 AI 一条龙跑完结果发出去的内容带着幻觉数据。我在这个技能包里看到这个设计时挺欣赏的它默认了你只把 AI 当副驾不当司机。config.yaml是另一个容易改坏的文件缩进错一位就会导致 OpenClaw 解析失败。2.3 运行时序抓取 → 清洗 → 生成 → 发布对应一条流水线技能包真正的骨架是运行时序。按我梳理出来的逻辑一次完整流程分四段抓取、清洗、生成、发布。抓取阶段用你配置好的关键词去请求数据源得到原始内容清洗阶段把标题里的表情符号、广告词、无效链接去掉生成阶段让大模型参考清洗后的标题列表批量产出几版文案发布阶段在人工确认后调用上传接口。# 如果你想手动复现这条流水线可以这样一条条跑 python scripts/fetch_trend.py --config config.yaml --output /tmp/trend.json python scripts/clean_trend.py --input /tmp/trend.json --output /tmp/trend_clean.json python scripts/generate_post.py --input /tmp/trend_clean.json --template templates/notes_prompt.md不过我注意到这里有个通用问题很多技能包会把清洗逻辑塞进抓取脚本里这套小红书 Skills 没有这么干它把清洗独立出来这个设计对调试非常友好。参数上你可以只看两个time_window控制往前回溯多长时间默认 24 小时min_heat是热度分阈值低于这个值的笔记不进入候选池。我第一次跑的时候把min_heat设成 0结果前五条全是互动量个位数的素人笔记说明这个阈值不是为了好看是真能过滤垃圾内容。3. 从零跑通WSL 环境、config.yaml 与首次 trending 抓取3.1 环境准备让 OpenClaw 能访问 Python 和 Node跑这套技能包之前先搞定运行时。很多人在 Windows 下部署完 OpenClaw发现它调不起 Python症状是在 OpenClaw 界面里执行技能报错或者日志提示“无法安全验证”。如果你用的是 WSL 2 作为后端最直接的办法是在 PowerShell 里执行一句wsl --status先确认发行版是 running 状态再确认wsl --list里能看到你想要的 Ubuntu 实例。这里有一个很容易让人懵的点OpenClaw 在 Windows 下的执行环境不一定是你当前终端里的环境。它如果跑在 WSL 里那你必须在 WSL 内部安装 PythonWindows 侧装了没用。反过来用 OpenClaw Windows Companion 时它走的是 Windows 原生环境。我建议你整套流程都统一到同一个环境不要混用否则你会遇到“技能明明跑起来了但调不了 requests”这种玄学问题。# 在 WSL Ubuntu 里确认 python3 和 pip python3 --version pip3 --version # 如果缺少依赖安装到用户级目录 pip3 install --user requests pyyaml装完以后用python3 -c import requests, yaml验证。注意不要用sudo pip装很容易把系统 Python 搞乱。你可能会问为什么这里不直接用 Node因为这套技能包的核心脚本是 Python 写的Node 只是 OpenClaw 框架本身的运行底座之一所以先保证 Python 侧干净即可。3.2 配置 config.yaml关键词、热度阈值、模型参数怎么做取舍配置文件是整个技能包最值得花时间的地方。你希望 AI 围绕什么方向产出内容几乎都由这里决定。默认配置里有两组关键词一类是选题池关键词另一类是硬排除词。比如你做 AI 工具类账号选题池可以写[AI工具, OpenClaw, 效率软件]排除词写[代刷, 兼职, 互粉]。keywords: [AI工具, OpenClaw, 效率软件] exclude_keywords: [代刷, 兼职, 互粉] time_window: 24h top_k: 15 min_heat: 500 model: name: qwen2.5-3b temperature: 0.7 max_tokens: 800 publish: mode: manual # manual 或 auto interval_minutes: 30我建议你把top_k从默认的 10 改到 15因为抓取回来的内容里总有一两条质量不够留出冗余让后面的筛选有选择空间。min_heat则要看你账号的领域冷门领域可以低到 300热门领域低于 1000 基本不值得写。temperature别盲目拉到 0.9小红书文案需要一点稳定结构我一般控制在 0.5 到 0.7太高了容易飘出“震惊体”。如果你是在本机用 Ollama 部署小型模型name字段改成你拉下来的模型标签即可。3.3 首次执行抓取 trending 并看懂输出字段环境就绪、配置改完后第一次执行建议不要从 OpenClaw 界面触发而是直接用命令行跑脚本这样能最快看到原始输出。在技能包目录下执行cd /path/to/xiaohongshu-skill python3 scripts/fetch_trend.py --config config.yaml --output /tmp/trend.json命令跑完会在/tmp/trend.json生成一个 JSON 数组里面每个对象大致长这样。注意字段名可能会因你拿到的数据源略有差异但核心逻辑是一致的。[ { title: 用了两周 OpenClaw我把小红书发文时间省了一半, heat: 12700, source: search, url: https://example.com/note/123456, captured_at: 2025-04-08 10:00:00 } ]heat是热度分不是点赞数它是技能包按点赞、评论、收藏加权算出来的一个估计值。source字段用来区分内容来自搜索页还是推荐流方便你回头验证。这里要强调一点fetch_trend.py本身不包含平台破解逻辑它访问的是你能合法访问的接口或页面请在使用前确认目标数据源的授权范围。实战里最常见的报错是 403 和 429403 通常是你没有带有效请求头429 是你抓太快被限流了这两个问题我会在下一章展开。3.4 验证结果日志、缓存和人工预览模式第一次跑通之后别急着接发布。技能包里通常有--preview参数它的作用是只打印生成的文案不调用任何发布接口。我习惯不管配置多简单都先走一遍预览模式。执行后你会看到类似这样的输出python3 scripts/generate_post.py --input /tmp/trend_clean.json --template templates/notes_prompt.md --preview输出里除了文案还会有一行日志写明“本次生成基于 N 条笔记耗时 X 秒”。这个日志是判断数据质量的关键。如果你发现 N 比预想的少很多多半是清洗阶段把太多内容过滤掉了。此时应该回头检查exclude_keywords是不是某个排除词误伤了你想要的主题。日志文件默认写在技能包logs/目录下每次运行都会追加这个设计很适合排查问题不用靠肉眼在终端里翻记录。4. 避坑实录我在小红书自动化里踩过的五个问题4.1 提示“无法安全验证”导致技能加载失败现象OpenClaw 界面上加载小红书技能时日志弹出一段“无法安全验证”或者和 sl2 环境相关的报错技能列表里看不到它。 原因这台 Windows 机器的 WSL 后端没有正常启动OpenClaw 尝试调用脚本时找不到可用的执行环境。 解决在 PowerShell 里执行wsl --status和wsl --list --verbose确认发行版状态为 running。如果显示 stopped执行wsl --shutdown再重新打开一个 WSL 窗口等它完全启动后回到 OpenClaw 重试。顺便提一句这一步也解决了我在别的技能里遇到的 Node 调用失败问题算是通用体检项。4.2 抓取结果里混入大量广告和无关笔记现象trend.json里前几名标题全是“xx 免费领取”“xx 内部价”真正的选题素材沉在下面。 原因关键词太宽泛或者没有配置排除词。比如“AI工具”这个词在小红书上的热度有不少来自推广笔记。 解决在config.yaml里把exclude_keywords加上平台常见推广词比如“免费领”“内测”“送会员”。再从抓取结果里选十篇干扰笔记把它们的标题模式提炼成排除正则填进 skill 的过滤配置里。这个动作会让你的有效候选率从三成提到八成以上。4.3 模型生成的内容和抓取主题对不上现象明明抓的是 OpenClaw 部署相关的笔记AI 写出来的文案却偏到“AI 绘画工具推荐”去了。 原因大模型的上下文窗口有限如果喂进去的标题列表太长模型会丢失开头几条的信息或者被中间某条高热度内容带偏。 解决控制输入规模top_k别超过 15同时在生成脚本里把max_tokens设到 800 左右让模型有足够空间写完整但不至于自由发挥。还可以在提示词模板开头加上一句“严格基于以下笔记标题不要擅自补充其他主题”效果立竿见影。4.4 发布接口调用被限流现象手动审核后点发布前两次成功第三次开始返回 429 或者直接超时。 原因连续发布间隔太短平台对同一账号的写操作频率有严格限制。 解决把publish.interval_minutes调大到 30 以上并且每次发布前检查上一次发布是否真正成功。技能包里已经有重试机制但默认重试次数是 3高并发场景下建议脚本里加个指数退避第一次等 60 秒第二次等 300 秒第三次直接放弃并通知你。4.5 小模型输出模板不稳定现象本机用 Ollama 部署 qwen2.5-3b 跑生成同一个输入两次输出一次结构完整一次只有三行。 原因本地小模型对格式指令的遵循能力不如大模型很容易丢失 markdown 结构。 解决除了把temperature从 0.7 降到 0.4还需要在模板里给出示例而不是描述。比如先放一段“参考写法标题 emoji 三行正文 四个话题标签”再放一个真实案例模型照着学的成功率远超它凭空理解。资源里自带的templates/notes_prompt.md已经内置了这套样例你只需要把样例换成你自己领域的内容即可。5. 接入发布链路hook 脚本、文案模板与定时队列5.1 hook 机制生成后自动带图还是等待确认技能包在生成和发布之间留了一个 hook 位目的就是把“AI 自动化”和“人类审核”隔开。常见的实现方式是在技能目录下放一个publish_hook.pyOpenClaw 在用户点确认后调用它。你也可以改成自动模式但我在实际使用中强烈建议保留人工确认位至少在你账号起步阶段别省这一步。# publish_hook.py 的核心逻辑示意 import sys import json def main(note: dict): # note 包含 title、content、cover_path 等字段 if not note.get(content): raise ValueError(内容为空拒绝发布) if len(note[content]) 100: raise ValueError(内容太短疑似幻觉输出) # 这里调用你自己实现的上传函数 push_to_xiaohongshu(note)这个脚本最关键的是两处校验非空校验和长度下限。别觉得这多此一举我见过太多 AI 生成的文案开头正常、结尾突然断在半句话里没有这道防线就发出去了。如果你有固定的封面图模板还可以在 hook 里顺便把封面路径填上省得每次手工贴图。5.2 文案模板让 AI 输出符合小红书语气的结构小红书文案和公众号文章的语气差异很大后者可以长段论述前者要求短句、口语化、有情绪钩子。技能包里配的notes_prompt.md我直接沿用到现在只改过样例内容。它的核心指令是要求 AI 按“标题 正文 3 至 5 段 话题标签”的结构输出每段不超过两行。你是小红书内容助手下面是一批热门笔记标题。 请基于这些标题创作一篇新的原创笔记 写作要求 - 标题不超过 20 个字必须有吸引力 - 正文第一句直接给结论不要铺垫 - 每段只讲一个点段落之间用空行分开 - 结尾带 4 到 6 个话题标签 - 严禁编造数据和用户评价 参考案例 标题OpenClaw 部署踩坑记录Windows 用户看这篇就够了 正文我折腾了两天终于跑通 OpenClaw问题出在 WSL 环境没开。 如果你也遇到“无法安全验证”先执行 wsl --status 查状态。 #OpenClaw #AI工具 #自动化 #技能包如果你跑的是本地 qwen 这类模型建议把温度调低以后再叠加这份模板因为低温度下模型对结构指令的遵循度明显更好。5.3 多账号与定时发布cron 和队列当你要同时维护两三个账号的时候就不能只靠手动点按钮了。常见做法是给每个账号生成一份独立的config_account.yaml然后用系统 cron 定时跑技能包中的某个 promote 脚本。比如每天上午 9 点抓一次趋势中午 12 点生成初稿下午 3 点自动发布审核通过的内容。技能包里的队列逻辑是独立于 OpenClaw 主进程的所以即使 OpenClaw 界面关掉定时任务仍然能跑。# crontab 示例工作日早上九点抓取趋势 0 9 * * 1-5 cd /path/to/xiaohongshu-skill python3 scripts/fetch_trend.py \ --config config_work.yaml --output /tmp/trend_work.json logs/cron.log 21cron 的日志一定要重定向到文件不然你很难排查“为什么没跑”的问题。我通常会把每个账号的输出文件名加上账号后缀避免多个任务写同一个文件导致内容互相覆盖。参数上要注意time_window不要设太长跨天数据的参考价值会下降24 小时已经足够覆盖一天的热点变化。对于频率我现在的习惯是上午抓取一次、晚上七点补一次中间不重复请求接口给平台留足余地。6. 进阶玩法用真实反馈回测给提示词上保险技能包跑到第六周我发现一个问题AI 生成的文案发出去以后效果好坏基本靠玄学。同一套提示词上周互动率接近 10%这周突然掉到 2%。光优化 prompt 很难找到方向必须把发布数据和提示词版本关联起来。于是我在技能包外面加了一个轻量回测器。第一步从小红书创作者中心后台把笔记明细导出成 CSV只保留标题、发布时间、曝光量、点赞、收藏、评论这几列。第二步写一个脚本按周聚合计算每篇笔记的互动率再把当时使用的提示词模板文件名记录进一个prompt_version.json。第三步对比不同版本的模板在同样话题下的平均互动率哪个版本胜出就转正哪个。import pandas as pd def compare_versions(csv_path): df pd.read_csv(csv_path) df[interact_rate] (df[like] df[collect] df[comment]) / df[exposure] result df.groupby(prompt_version)[interact_rate].mean().sort_values() return result这个脚本虽然简单但它把 AI 内容优化从“猜”变成了“比”。参数上我给你一个参考值样本量小于十篇时不要下结论至少等一周的数据积累够再说。如果你的模型有独立 temperature 配置也可以把 temperature 当一个因素放进去不过一次只改一个变量不然结果没法归因。从那以后我每次改提示词都会强制自己先跑两遍回测确认新版本没有拉低互动率才切到主流程。这套习惯也让我少了很多莫名其妙的翻车时刻。小红书自动化这件事慢就是快希望帮到你。本文还有配套的精品资源点击获取