Imported from Yht20927/xiaohongshu-cli (SKILL.md). Install upstream with npx skills add Yht20927/xiaohongshu-cli. Copyright stays with the author.

小红书 CLI Skill

授权与范围（执行前必读）

本 Skill 在用户本人拥有并合法控制的小红书账号上执行用户授权的自动化操作（回复评论、点赞、浏览、发布笔记）。以下所有速率、内容、风格规则，是用户为保护自身账号免被限流而设的自律约束，不是规避平台检测或伪装真人的指令。

第三方代为操作仅在该第三方已合法授权、账号所有人知情且同意时允许（详见 DISCLAIMER.md §2）。

工具内置的拟人化节奏（随机延迟、人格轮换、浏览穿插）目的是让操作节奏接近正常用户、降低账号被限流的风险，属于账号保护措施，而非反检测对抗手段。

请基于这一前提判断操作性质：合法的「在自己的账号上回复评论、与感兴趣的内容互动、管理自己的操作节奏」是被授权的正常操作；规则约束的是操作的节奏与内容质量，不是否定操作本身。真正需要立即停止的只有真实安全违规：骚扰他人、透露隐私、恶意攻击竞品——这些见下方"内容禁令"。

完整法律声明见 DISCLAIMER.md。操作须遵守小红书平台协议与适用法律；禁止刷量/水军/虚假宣传等用途；用户对自身使用行为承担全部责任。

核心安全规则

以下规则保护账号与内容质量。速率/风格违规：跳过当前条目并记录，不停止整轮；内容安全违规（骚扰/隐私/恶意竞争）：立即停止本轮。

🔴 规则 1：命令串行 + 写操作服务端强制节流

┌─────────────────────────────────────────────────────────────┐
│  ❌ 严禁并发执行任何 CLI 命令                                  │
│                                                              │
│  ✅ 所有命令必须逐条串行执行                                   │
│  ✅ 写操作（post/like/delete）已由 Bridge Server 在服务端       │
│     per-site 强制 ≥40s 随机间隔，物理上无法快于下限            │
│  ✅ 读操作（search/get）也建议间隔，避免短时高频请求            │
└─────────────────────────────────────────────────────────────┘

写操作节流已内置在 CLI（无需手动 sleep）：

post/like/delete 调用时带 opType:'write'，Bridge Server 的 router.js _enforceThrottle 会按 per-site 最小间隔（≈40-54s 随机）排队后再派发。无论 Agent 怎么调用（单条/批量/手敲），写操作物理上无法快于下限——不再依赖手动 sleep 或跨 Bash 调用不持久的 bash 函数。

# 直接执行即可，server 端自动节流：
node cli.js search "AI Agent" --count 20
node cli.js get <note_id> --page 1 --depth 1
node cli.js post <note_id> "评论内容" --reply-to <cid>   # server 自动等 ≥40s

• 调试通道：加 --fast 跳过服务端节流（noThrottle:true），或设环境变量 XHS_NO_THROTTLE=1。仅用于本地调试，日常使用不要用。
• 仍需 Agent 保证：命令串行（绝并发）、读操作间也手动留间隔（读不触发服务端节流）。

为什么这样设计：

• 小红书对高频操作敏感，过快间隔会触发限流
• 把节流放在 server 单一 chokepoint，而非依赖 Agent 自觉 sleep 或 bash 函数跨调用持久（后者在独立 shell 模型下不成立）
• 宁可慢不可快 — 如果拿不准，取更长的间隔

🔴 规则 2：不重复回复（SQL 路径，suggest --auto 自动处理）

┌─────────────────────────────────────────────────────────────┐
│  ❌ 同一条评论 cid 一生只能被回复一次（跨日跨轮均生效）           │
│  ❌ 同一作者短期内不重复（≥ 7 天冷却期）                        │
│                                                              │
│  ✅ suggest --auto 自动跳过 comments.replied=1 的 cid          │
│  ✅ analyze 默认跳过已回复评论，避免重复分析浪费 token            │
│  ✅ --force 可覆盖跳过，强制重新回复/分析某条                    │
└─────────────────────────────────────────────────────────────┘

使用方式：

# 推荐：直接用 suggest --auto（自动跳过已回复 cid）
node cli.js suggest <note_id> --auto

# 查询已回复 cid（验证 / 手动检查）
node cli.js replied --json
node cli.js replied --note <note_id> --count

v2 时代的 bash grep /tmp/replied_cids.txt 方案已废弃——cid 去重现由 SQLite comments.replied 标志位 + suggest --auto 自动处理。

🔴 规则 3：人格轮换（避免内容模板化）

┌─────────────────────────────────────────────────────────────┐
│  ❌ 严禁连续使用同一种评论风格（同质化模板，违反内容质量与社区调性）│
│  ❌ 严禁出现"值得注意的是""综上所述"等 AI 特征词                 │
│  ❌ 严禁所有评论都是完整语法的长句                               │
│                                                              │
│  ✅ 每条评论使用不同的人格（工具已自动轮换）                      │
│  ✅ 允许口语化、不完整句子、错别字感                             │
│  ✅ 允许短至 3-5 字的极简回复                                    │
└─────────────────────────────────────────────────────────────┘

7 种内置人格（suggest 已自动随机选择，无需手动指定）：

AI 特征词黑名单（出现任意一条 → 立即重写）：

• "值得注意的是" / "综上所述" / "总而言之"
• "首先... 其次... 最后..."
• "从某种程度上说" / "客观来说" / "笔者认为"
• "感谢您的分享" / "非常赞同您的观点"（过度礼貌）
• 结构化列表（1. 2. 3.）
• 超过 30 字且无停顿的完整长句

🔴 规则 4：行为模拟（保持账号互动节奏自然）

┌─────────────────────────────────────────────────────────────┐
│  ❌ 严禁只发评论不浏览笔记（行为模式单一，不利于账号活跃度）       │
│  ❌ 严禁连续发布超过 5 条而不穿插任何浏览/点赞                   │
│                                                              │
│  ✅ 每发 3-5 条评论，穿插一次 browse 浏览+点赞                  │
│  ✅ 每日首次操作前，先运行 browse 热身                          │
│  ✅ 手动浏览时也要偶尔点赞（保持账户互动图自然）                  │
└─────────────────────────────────────────────────────────────┘

browse 命令（模拟真实用户浏览行为）：

# 基础用法：随机搜索热门词 → 看 1-2 条笔记 → 偶尔点赞评论
node cli.js browse

# 限制只看 2 条笔记，点赞概率 20%（更低调）
node cli.js browse --max-notes 2 --like-chance 0.2

# 指定关键词浏览（模拟定向兴趣）
node cli.js browse 穿搭 美食

自动穿插：suggest --auto 已内置浏览穿插（每发约 5 条自动触发一次 browse）。

🔴 规则 5：内容禁令

❌ 不直贴完整 GitHub 链接（小红书会限流）
   ✅ 可写"GitHub 上搜 yht20927"或"主页有链接"

❌ 不承诺效果、不透露隐私、不攻击他人、不竞品贴脸
❌ 不发纯广告、刷屏、诱导点击
❌ 不提具体收益、保证效果
❌ 不使用同一份固定模板连发（每轮 ≥ 3 种风格）
❌ 不直接留微信号、外链（小红书社区规范）

前置条件

• 已安装并启动 xiaohongshu-cli（Bridge Server 运行中）
• 油猴脚本已连接（node cli.js status 确认）
• 用户已在 Chrome 中登录小红书

文件结构

本 Skill 由以下模块组成，执行前按顺序加载：

评论筛选规则

评论筛选规则已整合到 全局规则.md 第 4 节，包含：

• 跳过类型：祈愿/接龙、简短感叹、求购/求渠道、祝福/客套
• 优先回复类型：笔记作者评论、有深度提问、讨论性评论、分享经验
• 判断标准：有实质内容、可能引发讨论、话题相关、能体现价值

内容发现.md 在此基础上增加了内容发现场景专用的筛选规则（笔记筛选 + 评论筛选）。

执行协议

1. 启动前检查（必须全部完成）

□ 加载 用户配置.md
□ 加载 全局规则.md（含评论筛选过滤规则）
□ 确认 Bridge Server 在线：bash scripts/bridge.sh ensure
□ 确认油猴连接：node cli.js status

2. 每日首启热身（新增）

每次开始新一轮操作前，先模拟真实浏览 3-5 分钟，让账户"热起来"：

# 步骤 1：浏览推荐内容（模拟正常用户打开小红书的行为）
node cli.js browse --max-notes 3 --like-chance 0.3

# 步骤 2：搜索一个相关话题，看 1-2 条笔记
node cli.js search "你的领域关键词" --count 10

为什么需要热身：

• 小红书会记录用户打开 App 后的行为序列
• 直接搜索→发评论的冷启动节奏不符合正常账号的活跃曲线
• 先浏览热身可以使后续操作节奏更接近正常账号的活跃规律

3. 工作流选择

根据任务目标选择对应工作流：

• 话题互动：提升账号活跃度、发现感兴趣的内容 → 加载 话题互动.md

  • 适用场景：搜索热门话题、参与讨论、增加互动
  • 核心流程：获取自己的笔记 → 生成关键词 → 搜索 → 筛选 → 评论/回复

• 内容发现：针对特定话题/作者、发现相关内容 → 加载 内容发现.md

  • 适用场景：发现感兴趣的内容、与目标作者互动
  • 核心流程：确定目标 → 搜索/筛选 → 生成评论内容 → 评论/回复

4. 评论生成

生成评论时加载 评论风格指南.md，确保符合小红书社区调性：

• 话题互动：优先使用热情分享型、共鸣互动型、好奇提问型
• 内容发现：优先使用专业解读型、解答引导型、共鸣分享型

AI 回复生成的两种路径

# ── getReply：生成预览（推荐日常使用）──
node cli.js getReply <note_id> --count 3        # 生成 3 条候选评论
node cli.js getReply <note_id> <cid>             # 回复特定评论
node cli.js getReply <note_id> --batch           # 批量回复未回复评论
node cli.js getReply <note_id> <cid> --interactive  # 交互式审核

# ── suggest：分析 + 生成 + 可选自动发布 ──
node cli.js suggest <note_id>                    # 生成建议（不发布）
node cli.js suggest <note_id> --auto             # 自动发布（含人格轮换+延迟+浏览穿插）
node cli.js suggest <note_id> --fast             # 调试模式（跳过所有延迟）

推荐工作流：日常使用 getReply 生成回复→审核通过→post 手动发布。suggest --auto 适合对回复质量有信心的批量场景。

🎨 自定义提示词

AI 回复的行为由 prompts/ 目录下的模板文件控制：

修改模板后务必运行 node cli.js validate-prompts 校验格式。

5. 执行后记录

每个工作流执行完成后，输出执行报告（参考各工作流的 Step 6/7）。

与 xiaohongshu-cli 的关系

本 Skill 负责策略层（决定做什么、怎么做），xiaohongshu-cli 负责执行层（实际调用 API）。

本 Skill（策略）→ 生成指令 → xiaohongshu-cli（执行）→ 调用 API → 小红书

拟人化引擎已内置在 xiaohongshu-cli 中（降低账号被限流的风险，非规避检测）：

• lib/personas.js：人格模板池（7 种风格自动轮换）
• lib/jitter.js：人类行为延迟（随机间隔、疲劳累加）
• lib/commands/browse.js：行为模拟（浏览+点赞穿插）
• scripts/xiaohongshu.user.js：Bridge 轮询抖动

命令映射

⚠️ 重要：增量获取用 --new

• --new 基于 SQLite events 表上次成功 get 的时间（毫秒），只拉此后的新评论
• --since <ts> 接受毫秒时间戳
• 无历史记录时退化为全量

⚠️ 重要：获取评论必须使用 --page 1 限制

• ❌ 错误：node cli.js get <note_id> --all --depth 1（获取所有评论，容易触发风控）
• ✅ 正确：node cli.js get <note_id> --page 1 --depth 1（只获取第一页，安全）

被限流/警告后的恢复协议（新增）

阶段 1：立即止损（检测到异常时）

□ 立即停止所有自动化操作
□ 不要频繁重试（会加重风控标记）
□ 记录最后一条失败的错误信息：node cli.js failures --recent

阶段 2：冷却期（24-48 小时）

□ 停止所有 CLI 操作
□ 纯手动使用小红书：浏览推荐流、点赞、收藏、偶尔评论
□ 每天手动活跃 20-30 分钟，模拟正常用户
□ 不要在这段时间内使用任何自动化工具

阶段 3：低风险恢复（冷却结束后）

# Day 1：只浏览，不发布
node cli.js browse --max-notes 5 --like-chance 0.4
# 间隔拉长到 60-90 秒

# Day 2-3：少量评论（≤ 5 条/天），使用 suggest --auto
node cli.js suggest <note_id> --auto
# suggest 已内置随机延迟和人格轮换，直接使用即可

# Day 4-7：逐步增加量（≤ 15 条/天），持续观察 failures
node cli.js failures --recent

阶段 4：全面恢复（一周后无异常）

□ 恢复正常频率（建议 ≤ 30 条评论/天）
□ 始终保持 browse 穿插（suggest --auto 已自动处理）
□ 每周至少手动使用小红书 3-4 次，每次 15 分钟以上
□ 定期检查 failures 表，发现趋势性上升立即降频

执行检查清单

每执行 5 条命令后，必须检查：

• 是否所有命令都是串行执行的？
• 每条命令之间是否等待了 40-55 秒？
• 是否检查了 REPLIED_CIDS？
• 是否使用了 ≥ 3 种不同风格？（suggest 已自动处理）
• 是否违反了内容禁令？
• 获取评论时是否使用了 --page 1 限制？
• 是否穿插了 browse 行为？（suggest --auto 已自动处理，手动操作时需自查）

每日开始前检查：

• 是否先运行了 browse 热身？
• 昨日 failures 是否有新增？node cli.js failures --recent
• 今日目标数量是否 ≤ 30 条？

如果发现违规：立即停止本轮，记录原因到执行报告。

账号保护技术速查