每天刷B站找素材太费时间？把这件事自动化掉

有段时间，我每天用来刷 B 站的时间比写文章的时间还多。

划啊划，看到不错的视频就截图，评论区里有意思的讨论就复制粘贴，扔进备忘录。第二天打开，一堆乱截图，完全没法用——想找某个视频的播放量，翻半天找不到；记得有个爆款，忘了是哪个关键词搜到的；有时候评论区里某句话很有共鸣，想拿来做文章开头，早就不知道在哪了。

后来搭了一套自动化：每天 22:00 n8n 自动触发，按关键词搜昨日 B 站新发布的视频，顺手拉热门评论和字幕，结果写进飞书多维表格。第二天早上打开表格，视频按播放量排好，10 分钟搞定选题调研，不再靠「今天碰巧刷到了什么」。这篇聊聊这套系统怎么搭的。

一、三个工具，先说清楚各自是干什么的

这套流程用了 n8n、TikHub 和飞书多维表格三个工具，不是每个人都接触过，先一句话说清楚各自是做什么的。

n8n 是一个开源的流程自动化工具，可以把它理解成「会自己定点上班的执行员」——你告诉它什么时候做、做什么事，之后就不用管了，它按时自动跑，不需要你守着，也不需要手动触发。

TikHub 是专门给开发者用的第三方数据平台，提供 B 站、抖音等平台的公开数据接口，包括视频搜索、评论拉取、字幕提取。直接爬 B 站有封号风险，用第三方接口更稳定、也更安全。它按调用次数付费，费用不高。

飞书多维表格 是最终的数据落点，把 n8n 抓到的结果都写进来，每天在这里浏览和筛选选题。

三者的分工是：n8n 负责调度，TikHub 负责从 B 站取数，飞书多维表格负责沉淀。

二、飞书多维表格先建好

先把表格建好，n8n 才知道往哪里写数据。我们建一张选题监控表，可以用如下字段：

字段名	类型	说明
视频标题	文本
作者	文本
bvid	文本	视频唯一 ID，去重用
视频url	文本
视频播放次数	数字
视频发布时间	文本
搜索关键词	文本	哪个关键词搜到的
视频评论	文本（多行）	热门评论，自动采集
视频字幕	文本（多行）	字幕文字稿，截取 8000 字符，接 AI 分析用

建好之后，记下表格 URL 里的两个参数——App Token（URL 里 /base/ 后面那段）和 Table ID（URL 里 table= 后面那段），后面 n8n 配置要用到。

三、n8n 工作流：7 个节点，各有分工

整个流程 7 个节点，先说各自是干什么的：节点 1（Schedule Trigger）每天 22:00 自动开跑；节点 2（Code）初始化配置，包括关键词、API Key、昨日时间范围；节点 3（HTTP Request）换取飞书 Token；节点 4（Code）把 Token 和配置打包传给下一步；节点 5（Code，核心）搜索 \+ 去重 \+ 评论 \+ 字幕，一个节点完成；节点 6（IF）有新视频才写入，没有直接结束不报错；节点 7（HTTP Request）批量写入飞书多维表格。

我们说说几个关键节点的配置逻辑是怎样的。

节点 2：配置初始化

这个节点做三件事：填关键词、填认证信息、算出「昨天」的时间范围。

关键词就是你想让 B 站搜的词，根据自己的内容方向来填：

keywords: [
  '飞书多维表格', 'n8n', 'AI工作流',
  '自动化工作流', '多维表格教程',
  'AI Agent', '企业数字化', '低代码工具',
],

认证信息填 TikHub API Key（注册后在个人中心取）和飞书的 app\_id \+ app\_secret（在飞书开放平台自建应用里拿）；飞书的 bitableAppToken 和 bitableTableId 就是第二节记下来的那两个。

时间范围那段是把「昨天的北京时间」换成 Unix 时间戳。n8n 服务器通常跑在 UTC，不做这步日期会搞乱：

const BJT_OFFSET_MS = 8 * 60 * 60 * 1000;
const nowBJT_ms = Date.now() + BJT_OFFSET_MS;
const yesterdayBJT = new Date(nowBJT_ms - 24 * 60 * 60 * 1000);
const y = yesterdayBJT.getUTCFullYear();
const mo = yesterdayBJT.getUTCMonth();
const d = yesterdayBJT.getUTCDate();
// 昨日 00:00:00 北京时间 → UTC Unix 秒
const beginSec = Math.floor((Date.UTC(y, mo, d, 0, 0, 0) - BJT_OFFSET_MS) / 1000);
const endSec   = Math.floor((Date.UTC(y, mo, d, 23, 59, 59) - BJT_OFFSET_MS) / 1000);

节点 3/4：飞书 Token \+ 打包

节点 3 用 HTTP Request 换取飞书 Token，POST 到飞书开放平台的 auth.v3.tenant_access_token/internal 接口。节点 4 是 Code 节点，把 Token 和节点 2 的配置合并成一个对象传下去。

Token 单独拎出来做一个节点，是不想把认证逻辑塞进主代码节点——出问题排查起来更清晰。

节点 5：核心节点：搜索 \+ 去重 \+ 评论 \+ 字幕

这个节点就是核心了，我们用code来去从tikhub接口获取到B站的数据

这段代码做了这几个事：先从飞书拿全部历史 BV 号来去重（之前已经同步过的相同内容的数据就不需要再次同步了），再按关键词搜 B 站，过滤保留新视频，最后逐条拉热门评论和字幕。这是整个流程最重的部分，跑完大概 2\-3 分钟。

大概逻辑是这样：

Step 1：读飞书历史 BV 号。 把表格里已有的所有视频 ID 先全部拿出来，建一个 Set，用来去重。飞书记录接口每页最多 100 条，超过要循环翻页（page_token），直到翻完为止。

Step 2：按关键词搜视频。 对每个关键词调 TikHub 搜索接口，过滤「昨日发布」的新视频，两层去重——本轮跨关键词的重复 BV 号去掉，已入库的也跳过，而且已跳过的不占每个关键词的配额（默认每词前 10 条新视频）：

if (byBvid.has(it.bvid)) continue;        // 本轮跨关键词去重
if (existingBvids.has(it.bvid)) continue; // 已入库，不占配额

Step 3：拉热门评论。 每条新视频调 TikHub 评论接口，取热门评论按序号拼成文本写入。

Step 4：拉字幕。 字幕要分两步走——搜索结果里只有 aid（视频 ID），但 TikHub 字幕接口同时需要 cid（视频分 P 号）。我在想能不能不多消耗 TikHub 额度——可以的，cid 用 B 站自己的公开接口拿，免费：

// 第一步：B 站公开 pagelist 接口拿 cid（免费，不消耗 TikHub 额度）
const pagelistResp = await this.helpers.httpRequest({
  method: 'GET',
  url: 'https://api.bilibili.com/x/player/pagelist',
  qs: { bvid: v.bvid },
  json: true,
  timeout: 10000,
});
const cid = pagelistResp?.data?.[0]?.cid;

// 第二步：TikHub 字幕接口
if (cid) {
  const subtitleResp = await this.helpers.httpRequest({
    method: 'GET',
    url: `${base}/api/v1/bilibili/web/fetch_video_subtitle`,
    headers: tikhubHeaders,
    qs: { a_id: String(v.aid), c_id: String(cid) },
    json: true,
    timeout: 30000,
  });
  subtitle_text = extractSubtitleText(subtitleResp?.data) || '';
}

拿到的字幕文本截到 8000 字符写进飞书。有的视频太长，字幕全量写入会撑爆飞书字段；8000 字对 AI 做选题分析也足够了。字幕拉失败（比如视频本身没有字幕）不影响主流程，那条记录置空继续就行。

节点 6/7：判断 \+ 写入

节点 6 IF 判断 records 数组是否大于 0，有新视频才进节点 7，没有直接结束——日志里不会出现错误，运行记录保持干净。

节点 7 是 HTTP Request，POST 到飞书多维表格的批量创建记录接口：

POST https://open.feishu.cn/open-apis/bitable/v1/apps/{{appToken}}/tables/{{tableId}}/records/batch_create

Method 选 POST，Header 带 Authorization: Bearer {{tenant_access_token}} 和 Content-Type: application/json，Body 里用 {{ JSON.stringify({ records: $json.records }) }} 把上一节点组装好的字段直接提交。

四、关键词怎么选

关键词决定你能监控到什么，选得太宽引来大量无关内容，选得太窄会漏掉机会。

我按三个方向来选，根据自己的内容定位（飞书 \+ n8n \+ AI 工具方向）：

工具类：飞书多维表格、多维表格教程、n8n、低代码工具；

方法论类：AI 工作流、自动化工作流、AI Agent；

受众触点类：企业数字化（这个词能帮我找到面向中小企业主的内容方向）。

每个关键词每天取播放量前 10 的新视频，8 个词加起来最多 80 条候选，经过日期过滤和去重，每天实际新增 20\-40 条，够选了。

这些关键词随时可以在节点 2 的配置里调整，不用动其他任何地方。

五、为什么选 n8n，不直接用 Claude Code

这个问题有人问过。一次性的任务用 Claude Code 完全够，让它直接搜、拉、写都行。但 n8n 的好处在于「每天自动跑」和「结果沉淀在固定地方」。

配置一次之后不用再管，历史运行日志清晰，每个节点跑了多久、在哪里出了问题，一眼就看出来。这些在 Claude Code 里比较难做到。

Claude Code 适合「把数据拿来分析」，n8n 适合「定时采集和搬运」。两者分工，不是替代。我现在的用法是：n8n 每天采集，沉淀到多维表格，想深入分析的时候再把表格丢给 Claude Code。

六、现在每天 10 分钟是这么用的

每天 22:00 n8n 自动跑一遍，第二天早上打开飞书，昨天发布的相关视频按播放量排好，评论和字幕都在。

我的流程：扫一遍播放量高的，结合评论区的讨论方向，10 分钟找到 2\-3 个可以写的方向。有时候评论比视频本身更有用——读者在评论区提的问题，直接是下一篇文章的标题。

如果某个视频值得深入，就把那条记录的字幕字段复制给 Claude Code，让它结合我账号的定位给出具体的写作角度。字幕落库就是为这个准备的，比只看标题靠谱得多。

写在最后

这套系统跑起来之后，最大的变化是从「被动刷内容」变成「主动挑内容」。选题焦虑少了很多，不是因为灵感变多了，而是可以挑选的素材一直在那，不会断。

搭起来大概需要 2\-3 小时，之后每天自动跑。如果你也在做内容、每天为选题花大量时间，可以试试这个思路。

微信封面图生成指令

主标题：B站选题不用刷

副标题：n8n自动监控，每天10分钟搞定

视觉风格：手绘插画风格，带明显笔触感和艺术痕迹，非写实照片；暗黑美学，以深色调、黑色、深灰色为主导，营造神秘高级的氛围，整体曝光偏暗。

画布与排版：尺寸 900×383 像素，横向长图。文字必须位于画面上方区域居中展示，严格限制在「20%空白｜60%文字区｜20%空白」的中间60%宽度范围内，左右两侧须留出明显留白，不能有文字溢出。字体使用方正、硬朗、粗壮的无衬线中文字体风格（类似思源黑体Heavy、汉仪旗黑），灰白色或浅色质感文字，与暗黑背景形成强对比，确保可读性。

场景构思：画面下方/背景区域绘制一个雷达造型的扫描装置或机器人轮廓，正盯着一块发光的B站界面屏幕（弹幕、播放按钮等元素做简化抽象处理），旁边漂浮着飞书多维表格的数据卡片小图标，营造”自动监控、24小时值守”的科技暗夜氛围；插画元素集中在画面下半部分和左右两侧，不侵入上方文字安全区。

图文关系：文字区域背景需保持干净深沉，不能被插画元素穿插覆盖，确保主副标题清晰可读。

(注：内容由 AI 生成，请谨慎参考）

---

相关阅读

• B站自动监控系统怎么搭？n8n完整配置教程
• n8n自动收集B站YouTube更新：每天10分钟搞定选题