一句话回答：让 AI 自动发小红书，目前网上主流做法是装一个小红书专用 MCP server，靠手动从浏览器复制 cookie 完成登录；但 cookie 会过期、签名算法会变、账号只能单设备在线。用本机真实登录态直接接 AI，是另一条不用碰 cookie 的路。
你让 AI 把文案和配图都写好了，本想着一句话让它“发到小红书”就完事，一查怎么接，教程第一步写的是：打开浏览器开发者工具，找一个小红书网页请求，把 Cookie 头的值整段复制出来，粘贴进 MCP server 的配置文件。这不是某个冷门项目的特例，搜一圈“AI 自动发布小红书笔记”能找到的方案，十有八九都绕不开这一步。
现在让 AI 发小红书，网上教程基本是这两条路
第一条是内容生成 + 人工发布。用扣子（Coze）、Kimi 这类平台搭一个工作流，AI 负责把选题变成图文（起标题、写正文、挑封面图），产出的东西你还是得自己动手发到小红书 App 里。省下的是写文案的时间，发布这一步没有真正交给 AI。
第二条是装一个小红书专用 MCP server，让 Claude、Qwen3 这类支持 MCP 的 AI 客户端直接调用发布接口。这类项目不少，功能也做得比较全：有的支持 create_note 发图文、create_video_note 发视频，有的还带账号数据采集、能定时拉创作者后台的粉丝画像。看起来是把“AI 写完就能自动发出去”这件事跑通了，但代价藏在配置的第一步里。
cookie 类 MCP server 的真实成本，教程里通常不会写在标题里
这类工具能工作的前提，是小红书没有开放的发布 API 给第三方调用，这一点在小红书自动发布工具的选型里也拆过。没有官方接口，就只能靠拿到你的登录凭证去模拟网页请求，代价体现在几个地方：
- cookie 要手动抠出来。以 jobsonlook/xhs-mcp 这类项目为例，文档写得很直白：登录网页版小红书，打开开发者工具，在 Network 标签页里找一个请求，把 Cookie 头的值复制出来贴进配置，这一步没有捷径，每次都得你自己动手。
- cookie 会过期，得反复来。同一份文档里也写明“小红书的 cookie 有时效性，需要定期更新”，意味着这不是配置一次就能撒手不管的事，隔一段时间就得重新登录、重新复制。
- 签名算法说变就变。小红书网页请求带的
x-s、x-t是动态签名，这类项目本质是对签名算法做逆向。平台一升级签名逻辑，工具就会失效，得等维护者跟着更新——你的发布流程被绑在了一个业余维护的开源项目的更新速度上。 - 单账号只能单设备在线。有创作者在分享 n8n 接小红书 MCP 的工作流时特地提醒：“小红书的同一个账号不允许在多个网页端登录，如果你登录了当前工作流后，就不要再在其他的网页端登录该账号，否则就会把当前工作流里的账号’踢出登录’”（n8n+小红书MCP 工作流分享）。也就是说你在手机上正常刷小红书、回复评论，都可能把 MCP 里的登录状态顶下线。
- 项目本身也在提醒你风险自担。jobsonlook/xhs-mcp 的免责声明写着“本项目仅用于学习交流，禁止用于其他用途，任何涉及商业盈利目的均不得使用，否则风险自负”——这类未经授权的接口调用，本身处在灰色地带，维护者也不打算为你的商业使用兜底。
这些不是某一个项目做得不够好，是这条技术路线本身的代价：没有官方发布接口，就只能靠逆向登录态，逆向的东西天然不稳定、天然需要你手动维护。
PublishPort 的模型：AI 不用碰你的 cookie，因为它用的是你本机真实登录的账号
我们走的是另一条路：不让 AI 去逆向任何接口，而是让 AI 在你自己电脑上，通过你本机真实登录的浏览器和账号去操作。背后的原理是 ppcli（基于开源 opencli 的自有 fork），它把小红书（别名 rednote）当作一个命令行工具，支持搜索、查询、创作者数据和内容发布这几类操作。给 AI 的接口只有两个：local_bash 在你本机跑命令，list_capabilities 告诉 AI 现在能调用哪些工具。AI 自己 ppcli xiaohongshu -h 查用法，不需要谁给它单独写一套小红书专属的 MCP 适配层。
这跟前面拆过的 cookie 类方案有个本质区别：cookie 是把你的登录态“偷”出来给一个脚本冒充你，而 ppcli 是让 AI 直接指挥你本机那个已经登录、正常使用的浏览器动作，账号凭证从头到尾没有离开过你的设备。签名算法怎么变都影响不到你，因为走的是真实浏览器发出的真实请求，不是拼出来的伪造请求。免装一个个平台专属 MCP server 的另一个好处是，同一套 local_bash + list_capabilities 接口能覆盖 65+ 平台，接进 PublishPort 客户端 之后，AI 发小红书、发抖音、发知乎走的是同一条通道，不用为每个平台单独维护一个 MCP 配置。
具体接进你的 AI 工作流，要做这几步
- 装 PublishPort 客户端，跟平时装软件一样，不需要额外的开发环境。
- 在客户端里正常登录小红书，用你自己的账号扫码或输入密码，跟你平时用浏览器登录没有区别，不涉及复制 cookie。
- 把 MCP 接入地址配进你的 AI 客户端（Claude Desktop、Claude Code 或其他支持 MCP 协议的客户端），协议细节可以参考 Model Context Protocol 官方文档。
- 让 AI 自己摸索怎么用：AI 调用
list_capabilities看到“支持小红书搜索/发布”，再执行ppcli xiaohongshu -h查具体参数，不需要你写任何适配代码。
这套“AI 自己是适配器”的模型，和只给 Claude 接一个小红书专属 MCP server 的思路有什么不同、代价差在哪，这篇拆过更细的架构对比。
一个真实例子走一遍
假设你想让 AI 每天帮你出一条小红书笔记：AI 先用 ppcli xiaohongshu 的查询能力看一眼同类笔记最近的热门话题，写好标题和正文、配上生成或你准备好的图片，调用发布命令把笔记发出去。发布之后，AI 还能用同一套账号去拉这条笔记的评论和数据，把新增评论摘出来给你看、把点击和互动数据整理成一份简单的复盘——从选题到发布再到回评论，走的都是你本机那个真实登录的账号，中间没有第二份 cookie 在别处流转。
边界：这条路能省什么，省不掉什么
用本机真实登录态替代 cookie，解决的是“登录凭证要不要暴露、会不会因为逆向签名说崩就崩”这类问题，但小红书本身的平台规则不会因为换了个技术方案就消失：
- 单设备登录限制依然存在。小红书同一账号不能在多处同时保持登录，这是平台机制本身，不是某个 MCP 工具的限制，换成本机真实浏览器一样受这条约束——你在客户端里登录了账号，就尽量别再拿手机或别的设备重复登录同一账号引发冲突。
- AI 生成内容仍要主动标识。小红书“薯管家”已上线 AI 内容治理规则，未主动标注的 AI 生成合成内容会被限制推荐；这源于国家网信办等四部门发布的《人工智能生成合成内容标识办法》，自 2025 年 9 月 1 日起施行。AI 帮你写的笔记，该勾选的 AI 标识不能省。
- 不承诺绝对不限流、不封号。平台规则会调整，账号本身的历史和行为也是变量，本机真实环境能降低“一眼被识别成自动化脚本”的概率，但不是免死金牌。按真人节奏发布、别把发布频率拉到明显异常，仍然是最基本的自我保护。
接入前检查清单
- 确认小红书账号是在本机客户端里正常登录的，不是复制别处的 cookie
- AI 客户端已经能调用
list_capabilities看到小红书能力 - AI 生成的文案，发布前确认勾选了 AI 内容标识
- 发布频率贴近真人节奏，没有明显的批量痕迹
- 同一账号没有在别的设备上重复登录导致互相顶号
常见问题 / FAQ
小红书有没有官方 API 或官方 MCP 能让 AI 直接发布？
没有。小红书目前不对第三方开放发布接口，市面上能找到的小红书 MCP server 基本都是通过拿到用户登录 cookie 去模拟网页请求实现的，官方没有提供正式的开发者发布通道。
小红书 MCP 用的 cookie 是不是很快就会失效？
会。小红书的登录 cookie 有时效性，隔一段时间就需要重新登录网页版获取新的 cookie 并更新到配置里，这是这类方案需要长期手动维护的地方。
一个小红书账号能不能同时挂在 MCP 工作流和手机 App 上使用？
不建议。小红书同一账号不允许在多处网页端同时登录，如果你在 MCP 工作流里登录了账号，又在别的设备重复登录，会互相把对方的登录状态顶下线。
用 AI 生成并发布的小红书笔记，需要标注是 AI 生成的吗？
需要。小红书已上线 AI 内容治理规则，要求创作者对 AI 生成或合成的内容主动标识，这源自国家网信办等部门发布的相关规定，未标注的内容会被限制推荐。
用本机真实登录态代替 cookie 发布，就一定不会被限流吗？
不能这么保证。这种做法降低的是被平台识别为自动化脚本的概率，但账号行为、发布频率、平台规则调整都是变量，按真人节奏使用、别批量刷屏，仍然是必须守住的基本前提。