xiaohongshu-mcp：用 AI 发小红书，到底会不会被抓？

最近在 GitHub 上看到一个蛮有意思的开源项目， xiaohongshu-mcp，最近我自己也在用，可以直接让OpenClaw，Claude 这些 AI 直接帮你操作小红书：搜笔记、发帖、点赞、评论，一条龙全自动。

原理也不复杂，开了一个 Chrome 浏览器，headless 无头模式，然后帮你点按钮、填文字、上传图片。对小红书来说，它看到的就是一个正常的 Chrome 在访问页面，理论上是这样。

我翻了一遍它的源码，发现事情没那么简单。**这东西用起来爽归爽，被小红书抓到的风险其实挺多的。**我列了几个比较要命的点，大家一起看看，尤其是在最近新闻上说小红书重点打击AI托管账号的情况下，想用这个全自动发小红书的话，可能要自己改造一下。

一、浏览器指纹：裸奔上阵

这是最大的问题。

你用 Chrome DevTools Protocol（就是 go-rod 底层用的那套东西）控制浏览器的时候，Chrome 会自动设一个标记：navigator.webdriver = true。这玩意儿就像在你额头上写了四个大字，我是机器人。

小红书前端只要加一行 JS 检查这个值，你就原形毕露了：

if (navigator.webdriver) { /* 标记为机器人 */ }

更要命的是，headless Chrome 还有一堆别的破绽：navigator.plugins 是空的（正常浏览器一定有插件）、WebGL 渲染器显示的是 SwiftShader（软件渲染，正常电脑不会这样）、没有正常的屏幕分辨率信息……

项目中 browser.go 的 NewBrowser 函数只配置了 headless 模式和 Cookie 加载，没有任何反指纹注入。如 Puppeteer 生态的 puppeteer-extra-plugin-stealth 那种反检测方案在本项目中完全缺失。

小红书可以通过检测以下 CDP（Chrome DevTools Protocol）痕迹来识别自动化：

• Runtime.enable 等 CDP 命令的调用痕迹
• window.cdc_adoQpoasnfa76pfcZLmcfl_* 等 ChromeDriver 注入的变量
• document.$cdc_asdjflasutopfhvc 等变量

二、操作节奏：太规律就是不正常

真人操作小红书是什么样的？填完标题，可能楞神两秒想想措辞，打字速度忽快忽慢，中间可能还去喝口水。

但这个工具的发帖流程是这样的：

等 2 秒 → 等 1 秒 → 点 Tab → 等 1 秒 → 上传图片 → 等 1 秒 → 输标题 → 等 0.5 秒 → 输正文 → 等 1 秒 → 加标签 → 等 1 秒 → 点发布 → 等 3 秒

看出来了吗？全是固定时间间隔。每次发帖从开始到结束，花的时间几乎一模一样。你跑 100 次的时序图一叠，整整齐齐。这在统计模型面前毫无伪装可言。

有意思的是，同一个项目里的评论加载模块倒是做了随机延迟（300-700ms 之间随机），反而比发帖模块更"像人"。感觉是不同时期写的代码，反检测意识不统一。
feed_detail.go 中的评论加载，使用了

sleepRandom(min, max) 随机延迟：

// 这种随机范围更像人类行为
humanDelayRange = delayConfig{300, 700}
reactionTimeRange = delayConfig{300, 800}
readTimeRange = delayConfig{500, 1200}

三、鼠标是瞬移的

代码里的鼠标操作基本都是：算好坐标 → 直接移过去 → 点击。

x = 380 + 随机偏移

y = 20 + 随机偏移

鼠标瞬移到 (x, y) → 点击

真人的鼠标怎么动？沿着一条弧线滑过去，接近目标的时候会减速，偶尔还会稍微过头再修正一下。现在高级一点的反爬系统会看你的鼠标轨迹数据，如果是直线瞬移，那肯定不是人。
总结了一下，真人鼠标移动会有：

• 贝塞尔曲线轨迹（不是直线瞬移）
• 速度变化（开始加速、接近目标减速）
• 微小抖动
• 偶尔的过冲和修正

项目里只有 feed_detail.go 中的

clickElementWithHumanBehavior 做了简单的先悬停后点击，但仍然是瞬移定位。

同样的问题还出现在文字输入上，标题和正文是一瞬间灌进去的。想象一下你在输入框里啪一下就出现了 500 字的正文，换你是小红书你觉得正常吗？

四、每次都是"新浏览器"

这个工具每执行一个操作（搜索、发帖、点赞……），都会重新启动一个全新的 Chrome 实例，干完就关掉。

// service.go — 每个操作都是：启动浏览器 → 操作 → 关闭
func (s *XiaohongshuService) PublishContent(...) {
b := newBrowser() // 每次新建
defer b.Close() // 用完就关
page := b.NewPage()
defer page.Close()
...
}

问题在哪呢，正常人不会每做一件事就把浏览器关了再开。一个正常用户的浏览器会有浏览历史、有缓存、有 localStorage 里存的各种东西。这个工具每次都是白纸一张进去，除了 Cookie 什么都没有，看着就不太正常。
这意味着：

• 每次操作的浏览器实例 ID 都不同（正常人会保持一个浏览器开很久）
• 窗口大小、Canvas 指纹等可能每次微妙不同
• 没有自然的浏览历史和缓存——每次都是全新用户

五、没有任何频率限制

代码里没有做任何操作频率控制。也就是说如果你让 AI Agent 自动化跑起来：

• 凌晨 3 点连发 10 篇——可以
• 每隔 5 分钟发一篇，发一整天——可以
• 一个 IP 一天搜 500 次——可以

正常人哪有这种精力？小红书的风控系统对操作频率肯定是有模型的，你这种发帖节奏跟正常用户的分布差了十万八千里。

六、内容本身也可能出卖你

这一点不是工具的问题，是 AI 生成内容的通病。如果你用 ChatGPT 让它帮你写小红书文案，多多少少会带点AI味：

• 过于工整的段落结构
• 频繁出现"首先…其次…最后…"
• 用词偏正式，不像真人发的朋友圈

小红书如果在内容审核环节加了 AI 检测，大厂基本都在做这个，你发的文案可能在过审阶段就被标记了。

那它还能用吗？

能用，但得看你怎么用。

低频、自用问题不大。偶尔用它发个帖、搜搜笔记，小红书大概率懒得管你。Web 端本来流量就不大，不是风控的重点。

高频、批量基本上是在作死。没有反指纹、没有频率控制、没有行为模拟，跟在没有红绿灯的路口飙车差不多。

说到底，浏览器自动化做内容发布这件事，技术上可行但工程上很粗糙。如果真要安全地用起来，至少得补上反指纹注入、操作随机化、频率控制这几块——而这些目前在代码里完全是空白。

所以各位想拿来批量搞小红书运营的朋友，悠着点吧，工具好不好用是一回事，账号还在不在是另一回事。🫠