前言先说结论我开源了一个叫rednote-bootstrap的项目它是一个运行在 AI Agent 上的小红书运营技能包。但它不是又一份小红书运营指南的 Markdown 文档。它是一个活的知识系统——你问它一个运营问题它会自己打开浏览器、去小红书搜索真实笔记、翻页截图读图片内容、交叉验证多篇来源然后把知识蒸馏成一个结构化的可执行指南。下次你再问类似问题它直接从知识库调用不再重复研究。GitHub 地址github.com/MrMao007/rednote-bootstrap先来看一段实际运行效果——我问了一句小红书发布流程是什么它的执行过程是这样的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 分钟但对于研究一次复用多次的模式来说完全可以接受。为什么不直接用 RAGRAG 需要先有一个语料库而小红书的内容是图片为主的、动态更新的。你没法提前把所有笔记索引好。rednote-bootstrap 的做法是按需检索、实时蒸馏——需要什么就去搜什么搜完蒸馏成可复用的知识。可以理解为一种动态 RAG。为什么要生成 Skill 而不是直接回答三个理由复用生成一次后续同类问题零延迟可编辑用户可以审查、修改蒸馏结果可增量新知识可以合并进已有 Skill而不是从头来过如果只是直接回答那每次都要重新搜索 阅读既慢又浪费。为什么自适应深度而不是固定数量不同主题的信息密度差异极大。违禁词清单需要 15 篇才能覆盖全面而一个具体操作流程可能 3 篇就够了。固定数量要么不够要么浪费自适应深度让 Agent 自己判断够不够。可扩展性虽然目前主力支持小红书但架构上预留了扩展空间reference/platforms.md定义了平台适配层包括 DOM 选择器、交互模式、内容质量信号等。理论上为其他内容平台抖音、B站、知乎写一份类似的适配配置就可以让研究引擎支持新平台。子 Skill 模板和蒸馏规则也是与平台无关的——它们定义的是如何组织知识不绑定具体平台。写在最后rednote-bootstrap 本质上是在探索一个问题Agent 能不能像人一样现学现卖而不是只靠预训练知识我的答案是可以的——通过浏览器自动化获取实时信息通过视觉理解突破图片内容的壁垒通过知识蒸馏把碎片信息变成结构化知识通过注册复用实现越用越聪明。这个项目目前还在早期有很多可以改进的地方更多平台支持、更智能的搜索词生成、更精细的蒸馏规则。如果你对这个方向感兴趣欢迎来 GitHub 上看看提 issue、贡献代码或者分享你生成的子 Skill。GitHub 地址github.com/MrMao007/rednote-bootstrap如果觉得有用欢迎给个 Star ⭐️这对开源作者来说是最好的鼓励。