Pulse Discover

pulse-discover · 发现帖子

从中文社媒平台找原始信号——那些可能代表互动机会的 URL。

本 skill 是 4 段流水线的第 1 段。它的输出（原始 URL）交给 pulse-resolve 处理。

何时使用

用户想：

• 在特定平台找评论机会
• 监控竞品的新帖
• 跨平台追踪关键词/话题
• 看自己赛道里什么在火
• 盯购买意向信号（求链接 / 怎么买 / 价格）

触发词：discover, find, monitor, watch, track, trending, 发现, 监控, 追, 找, 采集

何时不用

• 用户要标准化某个具体 URL → 直接用 pulse-resolve
• 用户要给已有 URL 补元数据 → 用 pulse-enrich
• 用户要最终报告 → 用 pulse-deliver
• 用户要自动发布或自动评论 → 拒绝并提示风控风险

工作流

Step 1 · 确定发现模式

问用户（或从意图推断）选哪个模式：

各平台的 Workflow 编号不同（小红书 A=话题搜索，B站 A=竞品监控）——读文件按标题匹配，不要按编号猜。

路径基准：_shared/ 是 PulseHub 仓库根的共享资源目录（recipes / scripts / signals）。recipe 文件缺失 → 降级为 RSSHub 路由猜测 + Chrome DevTools 直接打开平台搜索页，并告知用户该平台 recipe 缺失。

Step 2 · 选发现源

按平台 recipe，选一个或多个：

优先 RSSHub——更安全（无账号风险）更快。 知乎优先官方 API——scraping 知乎网页会触发 40362 反爬限制。

Step 3 · 执行发现

按 recipe 调对应工具。小红书话题搜索示例：

# 走 RSSHub（首选）— 从 PulseHub 仓库根执行
bash _shared/scripts/shell/rsshub-fetch.sh "/xiaohongshu/search/notes?keyword=无线耳机"

# 或走 Chrome DevTools MCP（RSSHub 路由不可用时）
# → 打开 https://www.xiaohongshu.com/search_result?keyword=无线耳机
# → 等网络空闲
# → 从页面 DOM 提取笔记 URL

Step 4 · 输出原始 URL

输出原始 URL 列表。不标准化、不补元数据，只收集。

{
  "mode": "topic_search",
  "platform": "rednote",
  "query": "无线耳机",
  "candidates": [
    "https://www.xiaohongshu.com/explore/65f8e7ab...?xsec_token=ABxyz...",
    "https://xhslink.com/a/abc123",
    "https://www.xiaohongshu.com/discovery/item/65f9a1cd..."
  ],
  "discoveredAt": "2026-07-27T10:00:00Z"
}

下一步：把每个 URL 交给 pulse-resolve。

示例

示例 1：话题搜索

用户："找小红书上关于无线耳机的笔记，要能评论的那种"

1. 读 _shared/recipes/rednote.md 的话题搜索 Workflow（Workflow A: Topic Search）
2. 选源：RSSHub 路由 /xiaohongshu/search/notes
3. 运行：bash _shared/scripts/shell/rsshub-fetch.sh "/xiaohongshu/search/notes?keyword=无线耳机"
4. 收集 10-20 个候选 URL
5. 交接给 pulse-resolve

示例 2：竞品监控

用户："看看 @数码评测师 今天在 B 站发了什么"

1. 读 _shared/recipes/bilibili.md 的竞品监控 Workflow（Competitor Watch）
2. 需要 UP 主的 UID（通过搜索把用户名转 UID）
3. 运行：bash _shared/scripts/shell/rsshub-fetch.sh "/bilibili/user/dynamic/{uid}"
4. 从今天的动态里收集视频 URL
5. 交接给 pulse-resolve

示例 3：购买意向挖掘

用户："找找哪里有人在问无线耳机怎么买"

1. 这是带信号过滤的跨平台 topic_search
2. 对每个目标平台（小红书、抖音、B站、知乎）：
   a. 读 _shared/recipes/<平台>.md 的话题搜索 Workflow
   b. 搜关键词"无线耳机"
   c. 收集候选 URL
3. 全部 URL 交接给 pulse-resolve，再进 pulse-enrich（它负责检测购买意向）

重要规则

• 自我限流：每平台每次会话最多 50 个 URL
• Chrome MCP 会话用专用小号
• RSSHub 和 Chrome MCP 都可用时优先 RSSHub
• 先读 recipe 再动手——每个平台规则不同
• 绝不自动点击/滚动超出数据提取所需的范围
• 多平台采集规则见 P6——用户没指定单平台就默认跑全量，没跑完不进分析阶段

Pitfalls

P1. 遇到登录墙 / 验证码时停下来让用户处理（2026-08-05 用户强 correction）

症状：Chrome DevTools MCP 打开小红书搜索页 → 返回"登录后查看搜索结果"。AI 没有通知用户，而是自己切换到百度/Google/Bing 搜索引擎绕路 → 搜索引擎也跳验证码 → AI 又换工具…… 用户愤怒："你他妈就不能等一下啊，需要登录我登录，需要人机验证提示我验证不就行了？？？"

正解：🛑 遇到登录墙或人机验证，立刻停下来告诉用户："页面需要登录 / 需要过验证码，请在浏览器里处理一下"。等用户处理完再继续抓取。Chrome DevTools MCP 共享用户的 Chrome 登录态，用户手动登录后 session 就有了——这是正常流程，不是异常。

原则：登录和验证码是用户该做的事，不是 AI 该绕过的障碍。不要自作主张换工具链。

P2. RSSHub 社交平台路由可能缺 Playwright 浏览器（2026-08-05 实证）

症状：RSSHub /xiaohongshu/search/notes、/weibo/keyword 等社交平台路由返回错误："browserType.launch: Executable doesn't exist"——RSSHub 服务账户（system profile）的 Playwright 浏览器路径不对。

正解：RSSHub 社交平台路由依赖 Playwright 浏览器。如果 RSSHub 以系统服务运行，需要给服务账户装 Playwright 浏览器，或改用 Chrome DevTools MCP（有用户登录态）作为 discovery source。RSSHub 的非社交路由（36氪、YouTube、B站等）不受影响。

P3. Tavily 国内不稳定时用 Chrome DevTools 兜底（2026-08-05 实证）

症状：web_search（Tavily 后端）返回 [SSL: UNEXPECTED_EOF_WHILE_READING] EOF occurred in violation of protocol。代理 fake-ip 模式下尤其频繁。

正解：Tavily SSL 失败时，用 Chrome DevTools MCP 直接打开目标平台搜索页（如小红书 /search_result?keyword=XXX），用 evaluate_script 从 DOM 提取结果 URL。不要用百度/Google 搜索引擎中转——它们要么把结果藏在 JS 里（百度），要么跳验证码（Google）。

P4. 逐条抓取时模拟人工节奏，避免反爬（2026-08-05 用户明确要求）

症状：连续快速打开 B站多个视频页 → 触发风控；小红书快速翻页 → 被限制。

正解：逐条抓正文时，每条之间停 2-3 分钟（用 sleep 180）。模拟人工浏览节奏。不要一次性连续打开 10+ 页面。用户原话："为了规避反爬，你不要一次性抓取特别多，抓取1条的时候停顿两三分钟再抓其他的内容，避免反爬，就是模拟人工真实浏览页面。"

B站优先用 API：api.bilibili.com/x/web-interface/search/type 返回完整标题/播放/弹幕/简介（见 references/bilibili-search-api.md），一次调用拿完搜索结果，不需要逐条点进去。只有需要单个视频的 __INITIAL_STATE__ 详细 stat 时才逐条导航。

P5. discover ≠ 分析+写稿——不要提前宣布完成（2026-08-05 用户两次强 correction）

症状：跑完 discover + resolve + enrich 后直接报告"核心任务完成"。用户愤怒："核心任务也没完成啊，你就说完成了？？现在只是获取数据，还没进行分析和写稿子呢。"

正解：discover → resolve → enrich 只是数据采集层。PulseHub 的完整链路是 discover → resolve → enrich → 分析报告 → 写稿（按项目定制协议/档案定位）。在 enrich 完成后，下一步是写分析报告（洞察/痛点/竞品/定位）和获客文案（档案声明的主平台形式），不是停下来说"完成"。只有用户明确说"这步够了"才能停。不确定"核心任务"包含哪些子任务 → 先问用户确认范围，不要自己猜边界。

P6. 不许自作主张跳过平台（2026-08-05 用户强 correction）

症状：用户说"搜合同审查"。AI 跑了小红书+B站就直接跳到分析+写稿，跳过了知乎。用户愤怒："你又自作主张，还有知乎平台的呢？？你直接就分析了？？？？我也没说这个步骤完成了？"

正解：用户指定多平台采集时，每个平台都必须跑完 discover → resolve → enrich，才能进入分析阶段。跑完一个平台汇报一次，但不要在中间跳到下游步骤。用户没说"这步完成了"就不算完成。宣布"核心任务完成"前，对照用户原始需求逐项核对——没对齐就继续，别凭感觉收工。

工具速查