前言
先给一个明确结论：这是一套运行在 AI Agent 之上的小红书运营技能包，名叫 rednote-bootstrap。
但它不是又一份 Markdown 格式的“小红书运营指南”。它是一个活的智能知识系统——当你提出一个运营问题，它会主动打开浏览器、前往小红书搜索真实笔记、翻页截图并读取图片内容、交叉验证多个来源，最后将知识提炼成一份结构清晰、可直接执行的指南。下一次再遇到类似问题，它直接从知识库调取，无需重复调研。
先来看一段实际运行效果——
我提问“小红书发布流程是什么”，它的执行过程如下：
1. 主题拆解：将“发布流程”拆解为 5 个子维度（准备、流程、审核、时间、运营）
2. 自动搜索：在小红书上执行 3 轮关键词搜索
3. 筛选高赞：按点赞数筛选出 6 篇头部笔记（最高 4479 赞）
4. 逐篇阅读：打开每篇笔记，翻页截图，用视觉理解提取图中文字
5. 知识蒸馏：去重 + 交叉验证 + 冲突消解，生成结构化的子 Skill
6. 注册复用：存入知识库，下次同类问题零延迟响应
最终输出了一份涵盖七步发布法、2026 年最新审核规则、各赛道黄金发布时间表、20 个限流危险行为的完整指南——全程无需人工整理，全部来自小红书上真实创作者的一手经验。
如果你正在做小红书运营，或者对 AI Agent 在实际场景中的应用感兴趣，这篇文章或许能给你带来一些启发。
为什么要做这个？
痛点：小红书运营知识的“三不靠”
做过自媒体运营的朋友应该都有同感——你想搞清楚一个运营问题（比如“新号怎么养”），通常需要：
- 去小红书搜一圈
- 翻十几篇笔记，发现内容都在图片里，还得一页页翻
- 发现各家说法不完全一致，不知道该信谁
- 自己整理成文档
- 过了两个月，平台规则改了，文档作废
这个过程存在三个根本问题：
不靠时间——平台规则更新太快，你整理的文档三个月就失效。比如 2026 年小红书新增了 AI 内容强制标注要求、CES 评分权重大幅调整，去年的指南基本没法再用。
不靠 LLM——直接问大模型“小红书怎么发笔记”，它会给你一个看起来合理但可能已经过时的回答。因为训练数据有截止日期，而且很多细节藏在创作者的实战经验里，不在任何官方文档上。
不靠效率——小红书笔记最大的特点是核心内容都在图片里，不是纯文本。你没法用爬虫直接抓文字，必须“看图”才能获取信息。
所以我就在想：能不能让 Agent 自己去做这件事？像一个真实用户一样，打开浏览器、搜索、翻阅、阅读图片、整理知识？
核心思路：“搜索优先”的知识自进化
rednote-bootstrap 的核心思路可以用一句话概括：
具体来说就是三层：
┌─────────────────────────────────────────────────┐
│路由层：理解意图 → 查注册表 → 命中就复用 │
├─────────────────────────────────────────────────┤
│研究引擎：搜索 → 采集 → 评估 → 蒸馏 → 注册 │
├─────────────────────────────────────────────────┤
│知识库：持续增长的子 Skill 集合 │
└─────────────────────────────────────────────────┘
用户的每个问题，先走注册表路由。命中了就直接用，没命中就启动研究引擎。研究引擎跑完后把结果存到知识库，然后注册表就有了新的条目。下次类似问题就不用再研究了。
这意味着：你用得越多，它知道的越多，响应越快。
技术实现
五阶段研究引擎
这是整个项目的核心，拆成了五个阶段：
Phase 1：主题分析与搜索词生成
收到一个主题后，先拆解成 3~5 个子维度。比如“小红书发布流程”会被拆成：发布前准备、完整发布步骤、审核规则、发布时间优化、发布后运营。
然后为每个维度生成搜索词，用了三种策略：
- 直接词：子维度本身（“小红书发布笔记流程”）
- 长尾词：加入场景或痛点（“小红书笔记发布后没流量怎么办”）
- 反向词：从失败角度搜索（“小红书发笔记常见错误”）
Phase 2：浏览器自动化采集
这里用的是 agent-browser，一个基于 Rust 的浏览器自动化 CLI。整个流程是：
打开小红书 → 搜索关键词 → 获取搜索结果的无障碍树快照
→ 按点赞数筛选 Top N → 逐一点击打开 → 翻页截图 → 视觉理解提取内容
这里有几个关键点：
必须用真实浏览器：小红书没有公开搜索 API，反爬也做得很严格。agent-browser 通过 CDP 直接操控 Chrome，是以“正常用户”的身份在浏览。
必须截图读图：这是最关键的一点。小红书笔记的核心内容几乎都嵌在图片里，DOM 里拿不到。所以每一页都需要截图，然后通过多模态模型来“看”图片内容。
登录态管理：首次需要用户扫码登录，之后 agent-browser 会把认证状态持久化到
xhs-auth-state.json，后续自动复用。平台适配层：在
reference/platforms.md里定义了小红书的完整 DOM 交互映射——搜索框选择器、结果列表结构、笔记详情页结构、图片翻页机制。相当于给 Agent 写了一份“小红书操作手册”。
Phase 3：自适应深度控制
这是最有意思的部分。
一开始是固定采集数量的——每个搜索词读 5 篇，共读 15 篇。但很快发现两个问题：有些主题 5 篇就够了（信息高度重叠），有些主题 15 篇还不够（每篇都有新信息）。
所以设计了一个饱和度评估模型，用四个指标动态决定“够不够”：
| 指标 | 怎么算 | 阈值 |
|---|---|---|
| 信息新增率 | 本轮新增独立要点 / 总提取要点 | < 20% → 饱和了 |
| 维度覆盖率 | 已有内容的维度数 / 总维度数 | > 80% → 够了 |
| 矛盾检测 | 不同笔记间有没有互相矛盾 | 有矛盾 → 继续验证 |
| 权威性 | 有没有认证博主/官方内容 | 缺乏 → 补充 |
决策逻辑是：
新增率 < 20% 且 覆盖率 > 80% → 停止，进入蒸馏
新增率 < 20% 但 覆盖率 < 80% → 针对未覆盖维度生成新搜索词
存在矛盾 → 针对矛盾点搜索更多来源
都不满足 → 继续当前计划
同时有安全边界：最多 5 轮搜索、30 篇笔记、15 分钟。防止无限循环。
Phase 4：知识蒸馏
采集完成后，按照五条规则蒸馏：
- 去重：不同笔记说的同一件事，合并
- 交叉验证：被 3 篇以上笔记提及的要点，标记为“高置信度”
- 冲突消解：有矛盾的观点，并列呈现，不强制裁决
- 时效标注：标注信息基于哪个时间点的规则（“此为 2026 年 3 月规则”）
- 可执行化：把“建议优化标题”这种笼统建议，转化为具体步骤
最终生成的子 Skill 不是一堆信息的堆砌，而是一份结构化的可执行指南，包含：领域概述、核心知识体系（按维度 + 置信度）、可执行工作流、工具资源、常见误区、时效说明、信息来源（可溯源到每篇笔记）、以及知识缺口（诚实标注没覆盖到的部分）。
Phase 5：注册与路由
生成的子 Skill 会被注册到 registry.json，记录 topic、keywords、置信度、分析笔记数等元数据。后续用户的问题会先匹配注册表：
- 精确匹配 topic → 直接复用
- keywords 覆盖 > 70% → 复用 + 检查是否需要增量更新
- 无匹配 → 启动研究引擎
对于增量更新，也有策略：如果新问题的子维度已有 Skill 没覆盖，只研究差异部分并增量合并，不从头来过。
子 Skill 模板
每个自动生成的子 Skill 都遵循统一模板：
---
name: xiaohongshu-publishing-guide
topic: 小红书发布流程及注意事项
researchDepth: standard（分析了 6 篇内容）
---
# 小红书发布流程及注意事项
> 信息来源：小红书平台 6 篇内容的交叉验证
> 置信度：高
> 上次更新：2026-04-23
## 领域概述
## 核心知识体系← 每个维度标注置信度
## 可执行工作流← 步骤化操作指南
## 工具与资源
## 常见误区与避坑
## 时效性说明← 哪些信息可能过期
## 信息来源← 溯源到每篇笔记
## 知识缺口← 诚实标注没覆盖的
特别看重“信息来源”和“知识缺口”这两个部分——前者让知识可追溯可验证，后者避免了 AI 常见的“什么都知道”的幻觉问题。
实际生成案例
目前已经生成了两个子 Skill 作为示例：
? 小红书笔记发布流程
这是测试时生成的第一个子 Skill，分析了 6 篇高赞笔记（总点赞超过 7600），覆盖了：
- 七步发布法（重点：不要直接点 + 号，要通过创作者中心 → 笔记灵感入口）
- 2026 年最新审核规则（AI 标注强制要求、CES 评分权重调整、导流红线）
- 各赛道黄金发布时间表（美妆、美食、娱乐、学习、育儿等 15 个赛道）
- 20 个导致限流的危险行为清单
- 发布后冷启动关键期（2 小时内互动质量占流量分配权重 60%）
- 阶梯式处罚标准和申诉流程
? 小红书日常养号流程
分析了 4 篇笔记，覆盖了：
- 五边形权重体系（观看、互动、发文活跃度、主页访问、涨粉）
- 新号 7 天养号周期（Day 1-3 纯浏览 → Day 4-5 试发 → Day 6-7 稳定运营）
- 八大伤号禁忌行为
- 僵尸号复活流程
这些内容全部来自小红书上真实创作者的经验分享，经过多源交叉验证。比如“不要直接点 + 号发布”这个技巧，被 4 篇不同笔记同时提及，置信度标记为“高”。
架构设计的几个取舍
为什么不用 API 而用浏览器？
小红书没有公开的内容搜索 API，第三方 API 不稳定且可能违反 ToS。用 agent-browser 以真实浏览器操作是最合规、最稳定的方式。代价是速度稍慢（一次完整研究约 5-10 分钟），但对于“研究一次复用多次”的模式来说完全可以接受。
为什么不直接用 RAG？
RAG 需要先有一个语料库，而小红书的内容是图片为主的、动态更新的。你没法提前把所有笔记索引好。rednote-bootstrap 的做法是“按需检索、实时蒸馏”——需要什么就去搜什么，搜完蒸馏成可复用的知识。可以理解为一种“动态 RAG”。
为什么要生成 Skill 而不是直接回答？
三个理由：
- 复用：生成一次，后续同类问题零延迟
- 可编辑：用户可以审查、修改蒸馏结果
- 可增量：新知识可以合并进已有 Skill，而不是从头来过
如果只是直接回答，那每次都要重新搜索 + 阅读，既慢又浪费。
为什么自适应深度而不是固定数量？
不同主题的信息密度差异极大。违禁词清单需要 15 篇才能覆盖全面，而一个具体操作流程可能 3 篇就够了。固定数量要么不够要么浪费，自适应深度让 Agent 自己判断“够不够”。
可扩展性
虽然目前主力支持小红书，但架构上预留了扩展空间：
reference/platforms.md 定义了平台适配层，包括 DOM 选择器、交互模式、内容质量信号等。理论上，为其他内容平台（抖音、B站、知乎）写一份类似的适配配置，就可以让研究引擎支持新平台。
子 Skill 模板和蒸馏规则也是与平台无关的——它们定义的是“如何组织知识”，不绑定具体平台。
快速上手
依赖
- QoderWork 桌面应用（Agent 运行环境）
- agent-browser：
npm i -g agent-browser && agent-browser install - Chrome / Chromium
安装
git clone https://github.com/MrMao007/rednote-bootstrap.git ~/.qoderwork/skills/rednote-bootstrap
使用
在 QoderWork 里直接对话即可，Skill 自动加载：
你：小红书发布流程是什么？
你：新号怎么养号？
你：违禁词有哪些？
首次使用需要扫码登录小红书（一次性，之后自动复用认证状态）。
写在最后
rednote-bootstrap 本质上是在探索一个问题：Agent 能不能像人一样“现学现卖”，而不是只靠预训练知识？
答案是肯定的——通过浏览器自动化获取实时信息，通过视觉理解突破图片内容的壁垒，通过知识蒸馏把碎片信息变成结构化知识，通过注册复用实现“越用越聪明”。
这个项目目前还在早期，有很多可以改进的地方（更多平台支持、更智能的搜索词生成、更精细的蒸馏规则）。如果你对这个方向感兴趣，可以到项目仓库看看，提 issue、贡献代码或者分享你生成的子 Skill。
```
