AI 自动化小红书发布系统搭建指南

编辑点评 · AI 连续创业者视角（以下内容由 AI 提炼，观点归原作者；读完可不看原文）

这是一套基于 MCP 的 AI 自动化工具，让 Claude 等 AI 代理自动完成小红书选图、写文案及发布全流程。作者实测 Web 端集成 13 个工具，支持定时及 Webhook 触发，解决了重复性发布的繁琐操作。对搞钱者而言，这是低成本实现内容矩阵铺号的利器，适合有稳定内容源（如 GitHub 日报）的团队。最大坑在于网页版不稳定，需持续维护选择器逻辑。

搭建 Web 后台调用 MCP 实现全自动发布
用 Cron 或 Webhook 触发实现定时分发
本地 NAS 或 Git Log 作为素材源自动转文案
注意网页端改版风险，需定期更新脚本
适合内容生产与分发分离的垂直账号运营

一、这是什么机会

为拥有稳定内容源（如 GitHub 日报、技术博客）但缺乏运营人力的创作者，提供基于 MCP 协议的小红书全自动发布系统。通过本地 Web 后台整合 AI 生成与定时任务，实现从素材到成片的闭环分发，以节省人力成本获取收益。

二、独立判断

值得做，但仅限垂直内容源用户。该方案核心价值在于“自动化流水线”而非“内容生产”，适合已有成熟内容矩阵的团队。关键风险在于依赖网页端选择器，维护成本随平台改版呈非线性增长，不适合追求“一劳永逸”的低频用户。

三、冷启动路径

第一步是部署 xiaohongshu-mcp 并搭建简易 Web 后台（可参考原文中的 localhost:3721 方案）。成本量级极低：主要消耗是 Anthropic 与 Replicate 的 API 费用，初始硬件仅需本地 NAS 或旧笔记本。验证周期 1-2 周，重点测试 Git Log 自动转文案的准确率与定时任务的稳定性。

四、最大风险与避坑

致命坑一是网页端 DOM 结构变更导致点击失效，应对策略是建立监控告警，一旦发布失败立即人工介入修复选择器；坑二是多端登录冲突，同一账号不能同时在多个网页端登录，需确保自动化节点独占会话。切勿用于搬运或违规引流，平台风控一旦触发，账号权重将永久受损。

五、案例复盘（别人怎么做的）

技术架构：作者使用 xiaohongshu-mcp 将小红书网页端封装为 13 个工具（发图文、搜素、点赞等），配合自研 Web 后台，通过 ./start.sh 一键启动。
触发机制：支持手动、Cron 定时及 Webhook 三种模式。实测中使用 Cron 每天 21:00 扫描 GitHub 仓库的 git log，由 Claude 生成文案后自动发布。
内容生成：文字由 Anthropic API 生成，配图通过 Replicate 调用 FLUX 或 SD 模型。作者设定死规则：标题 20 字、正文 1000 字、封面真人出镜且手写标题，AI 仅负责填充。
标签处理：使用 xhs-smart-tags 技能筛选 5-8 个精准标签，注入 MCP 的 tags 参数，弥补 CDP 流程不支持话题的缺陷。
维护实战：11 月 1 日因新版创作中心改版，出现离屏标签页误判、按钮点击超时等问题，需人工修补三处选择器逻辑，否则任务直接卡死。