就行从 0 到 1 使用教程：把每天重复刷平台，变成一套可运行、可沉淀、可复盘的内容监控系统。

**Skill 地址：**github.com/xintu1314/content-boom-monitor

为什么要做这个 Skill？

对内容运营和创作者来说，“盯爆款”很重要，但也是一件特别难长期坚持的事。

每天打开小红书和抖音，搜索行业关键词，再逐个进入对标账号主页：看谁发了新内容、哪条数据突然变好、标题用了什么结构。看完之后，还要把链接复制进表格，手动记下两三行分析。

这套方法短期能跑，时间一长就会变成“想起来才看一眼”。监控数量越多，记录越粗糙，最后只剩下一张没有人维护的素材表。

真正的问题不是“AI 能不能帮我拆一条内容”，而是能不能搭出一套稳定运行的系统：自动读取监控目标、抓取数据、去重、识别异常、生成报告，并把值得研究的内容沉淀到飞书。

这就是 Content Boom Monitor 想解决的问题。它已经把这条链路封装成一个可以安装到 Codex 的 Skill：

  • 在飞书填关键词或账号主页；
  • Skill 自动生成限量配置；
  • 调用 Just One API 获取两个平台的数据；
  • 自动标准化、去重和计算账号相对表现；
  • 生成可阅读的监控简报和 Top 5 AI 辅助拆解；
  • 预览无误后写入飞书内容作品库。
    安装skill后，第一次运行默认很克制：最多 3 个关键词、每个平台 2 个账号、每个任务 1 页。它优先帮助你验证数据和流程，而不是一开始就消耗大量 API 调用。没问题后可以批量测试。

适合谁

  • 内容运营、短视频团队和独立创作者；

  • 想持续观察竞品内容、热门选题和账号异常作品的人；

  • 已经使用 Codex、飞书，希望把重复盯盘变成稳定流程的人；

  • 不想开发完整 SaaS，但愿意配置 API 和飞书表格的人。
    不适合谁

  • 只想临时搜一次内容，不需要长期沉淀；

  • 要求系统直接保证“预测爆款”；

  • 没有权利处理相关平台公开数据，或不能遵守 API 与平台规则；

  • 期待完全零配置、无需 API 账号的成品 SaaS。

写在前面

这篇教程解决的不是“怎么临时找几条热门内容”，而是“怎么搭一套能反复运行、稳定沉淀、只让人处理高价值内容的监控系统”。

本教程推荐直接安装已经跑通的 Content Boom Monitor：

  • Codex Skill：封装流程、规则和执行入口；
  • Just One API：获取小红书、抖音公开内容数据；
  • 飞书多维表格：保存关键词、对标账号、作品和处理状态；
  • AI 分析：只拆解系统筛出的少量重点内容；
  • 人：只输入监控目标，并对结果做最终判断。

一、最后要搭出什么

系统包含两个互相独立的监控引擎。

  1. 关键词监控

它回答的是：搜索这个关键词，哪些笔记或视频是爆款候选？

输入关键词，例如：

  • AI工具
  • AI外贸
  • AI视频
    系统分别到小红书和抖音检索与关键词相关的近期内容：小红书优先使用热度排序，抖音优先使用点赞排序；取得结果后，再根据公开的点赞、收藏、评论和分享计算互动值，返回本次搜索中最值得优先查看的关键词爆款候选。这条链路不是为了发散新话题，也不使用账号历史基线。
  1. 对标账号监控

它回答的是：这个账号最近哪条内容明显高于自己的正常水平？

输入小红书或抖音账号主页链接，系统获取最近作品，用同账号本轮其他可用作品作为基线，计算相对表现 R。这样，小账号中突然表现异常的内容也能被发现，不会只剩下大账号占据排行榜。

  1. 人最终看到什么

系统输出两类结果：

  • 飞书内容作品库：所有结构化作品和处理状态；
  • 监控简报：本轮范围、每个关键词的爆款候选排名、账号异常、Top 10、Top 5 AI 拆解、选题建议和证据缺口。
    人在日常运行中只做三件事：
  1. 添加关键词或账号主页；
  2. 查看系统筛出的重点内容；
  3. 标记“值得跟进、继续观察、不相关、已采用”。

二、系统架构：稳定流程和 AI 判断分开

这套架构最重要的边界是：

不要让 AI 猜作品 ID、缺失指标或发布时间；也不要用一条固定公式代替内容判断。

三、开始前的准备

你需要：

  • 一个可以运行 Skill 的 Codex 环境；
  • 一个 Just One API 账号和 Token；
  • 一个飞书账号；
  • 已配置并授权的 lark-cli；
  • Python 3。
    建议先明确一句内容方向，例如：

面向外贸创业者，分享 AI 获客、自动化和实用 Skill。

这句话不是搜索条件，而是后续 AI 判断“是否相关”的业务背景。

安全与合规

  • 只处理你有权使用的公开数据；
  • 遵守平台规则、API 服务条款和适用法律；
  • Token 只能放在环境变量中，不写进 Skill、日志、报告或飞书；
  • 保存原始 API 响应时必须隐藏 Token；
  • 缺失数据保持为空，不要伪造成 0。

四、创建飞书内容库

新建一个飞书多维表格，建议包含三张表。

表 1：监控关键词

日常快速录入只需要两个字段：

系统字段可以增加：状态、扫描频率、最后扫描时间、下次扫描时间、扫描结果、连续失败次数等。把它们放入“系统数据”视图，不要求日常填写。

表 2：对标账号

快速录入显示：

系统可以补充平台账号 ID、状态、扫描频率、粉丝数、最近扫描时间和错误信息。

表 3：内容作品库

建议按五类设计字段：

处理状态建议固定为：

  • 待评估
  • 值得跟进
  • 继续观察
  • 不相关
  • 已采用
    视图设计

不要删除系统字段，应该用视图降低人的认知负担：

  • 监控关键词 / 快速录入：关键词、监控平台；
  • 对标账号 / 快速录入：账号名称、平台、主页链接；
  • 内容作品库 / 重点内容：标题、平台、作者、发布时间、互动值、R、监控等级、AI摘要、可复用选题、链接、处理状态；
  • 每张表保留一个 系统数据 全字段视图。
    机器使用的字段和人阅读的字段分开，是系统能长期使用的关键。

把飞书标识交给 Skill

通过 Base 链接获取 base_token，再查询三张表的 ID：

把返回的真实标识写入环境变量：

不要把个人 Base 标识硬编码进公开仓库。也可以在执行脚本时通过对应参数传入。

这些也可以复制给codex，让它自己去创建这样的飞书多维表格。

五、配置 Just One API

打开 Just One API 文档，获取自己的 Token。把 Token 写入本机环境变量：

如果使用 zsh，可以把这一行放进 ~/.zprofile，保存后执行：

如何搭建小红书和抖音的爆款监控系统？我把找选题这件事做成了Skill！ 第1张图片

不要把真实 Token 写进教程、代码仓库或飞书表格。

首次试跑只需要四类接口：

试跑建议：

  • 关键词最多 3 个；
  • 每个平台对标账号最多 2 个；
  • 每个任务只请求第 1 页；
  • 每个关键词最多保留 5 条；
  • 每个账号最多保留 8 条，保证相对评分有足够样本。
    业务响应必须满足 code == 0。HTTP 200 不代表业务成功。遇到 Token 无效、余额不足、权限缺失或参数错误时应停止，而不是无限重试。

六、安装 Content Boom Monitor Skill

项目主页：

https://github.com/xintu1314/content-boom-monitor

克隆到 Codex Skills 目录：

重新打开或刷新 Codex 后，就可以用自然语言触发，例如：

用 Content Boom Monitor 读取飞书里的关键词和对标账号，先做一次小规模试跑，不要直接写入。

安装后的目录结构：

如何搭建小红书和抖音的爆款监控系统？我把找选题这件事做成了Skill！ 第2张图片

三个程序各做一件事：

  1. build_config_from_feishu.py：只读飞书中的关键词和账号，生成限量配置；
  2. pilot_monitor.py：调用接口、保存原始响应、标准化、去重、评分并生成报告；
  3. publish_feishu.py：预览或写入内容作品库。
    为什么推荐直接使用它
  • 关键词监控和账号监控是两个检测引擎；
  • 第一轮必须限量；
  • 保存经过脱敏的原始响应；
  • 不伪造缺失数据；
  • 账号少于 5 条可用同批作品时不计算 R；
  • 写飞书前先预览，获得授权后才正式写入；
  • AI 最多分析 Top 5，并区分事实与推断；
  • 人只填写输入和处理状态。

七、从飞书生成试跑配置

人在快速录入视图填好关键词和账号主页后，在codex运行：

用 Content Boom Monitor 读取飞书里的关键词和对标账号，获取报告和直接写入飞书

八、执行第一次监控

完成后应得到：

标准化字段

无论来源平台如何，至少统一成：

  • platform
  • post_id
  • title
  • post_url
  • author_name
  • author_id
  • published_at
  • likes / collects / comments / shares / views
  • monitor_sources
  • collected_at
    同一作品可能同时被关键词和对标账号命中。合并记录时要保留全部来源，而不是重复写两行。

去重键

使用：

没有稳定作品 ID 时，不自动入库，除非存在可以长期使用的规范链接。

九、如何判断“值得看”

  1. 互动值

不同平台的用户行为价值不同，因此使用加权互动值。

小红书：

抖音：

只计算接口实际提供的指标。某个指标缺失时，不能把它表述为“真实为 0”。

  1. 关键词爆款候选

关键词监控不计算账号相对表现 R。系统让小红书按热度降序、抖音按点赞降序搜索，再把返回结果按可用互动值从高到低排列。

例如输入 AI工具，报告会分别列出小红书和抖音中与该词相关的高互动内容、排名、作者、链接及互动证据。这是本次关键词搜索范围内的爆款候选，不等于全平台爆款认证。

  1. 账号相对表现 R

只针对对标账号作品：

至少需要 5 条对比作品。使用中位数而不是平均值，可以降低历史超级爆款对基线的干扰。

  1. 监控等级

证据门槛为：

这些等级用于安排查看顺序，不是“爆款概率”，更不是对未来流量的保证。

如何搭建小红书和抖音的爆款监控系统？我把找选题这件事做成了Skill！ 第3张图片

十、生成一份能做决策的监控简报

报告不能只写“抓了多少条”和 5 个链接。至少应包含：

  1. 执行范围、平台数量、失败任务和数据缺口；
  2. 等级分布及含义；
  3. 每个关键词在每个平台的作品数、互动中位数和最高互动作品；
  4. 每个对标账号的同批作品中位数、全部作品 R 和异常等级；
  5. 重点内容 Top 10；
  6. Top 5 AI 辅助拆解；
  7. 2—4 个适配自身业务的选题建议；
  8. 评分公式、证据边界和缺失数据说明。
    Top 5 AI 拆解每条至少回答：
  • 事实证据是什么；
  • 标题或内容结构可能是什么；
  • 哪些元素可复用；
  • 哪些背景不能照搬；
  • 如何改造成自己的选题；
  • 置信度和缺失证据是什么。
    原始正文与 AI 分析必须分开。没有正文、封面、画面或评论区时，要明确写“未获取”，不能根据标题补写不存在的事实。

十一、预览并写入飞书

先预览：

确认有效行数、目标 Base 和目标表后，再正式写入：

也可以直接写入；

十二、第一次真实试跑案例

本教程对应的真实试跑输入：

  • 关键词：skill、AI外贸；
  • 平台：两个关键词均留空，因此同时监控小红书和抖音；
  • 对标账号：小红书账号“空格的键盘”。
    结果：

系统识别到一条 T3 内容：《10 个 Skill 帮你轻松做起小红书》，互动值 12158，R=75.52。

这个结果不能直接解释为“只要写 10 个 Skill 就一定会爆”。正确用法是：把它列为优先复盘对象，再结合正文、封面、发布时间、评论区和账号语境判断真正原因。

十三、人需要做什么

日常最小操作：

  1. 在关键词表新增关键词，平台可选；
  2. 在账号表粘贴主页链接；
  3. 在内容库把少量作品标记为“值得跟进、继续观察、不相关、已采用”。
    人不需要填写：作品 ID、作者 ID、互动指标、R、监控等级、扫描时间、AI 摘要或运行状态。

反馈应该影响下一轮：

  • 多次“不相关”的关键词降低优先级或停用；
  • 经常产出“值得跟进”的账号提高优先级；
  • “已采用”的结构进入选题模板库；
  • 不要因为一次高互动就立刻扩大采集量。

十四、从试跑扩展到稳定运行

首次试跑跑通后，一次只扩大一个维度：

  1. 先增加关键词；
  2. 再增加对标账号；
  3. 再增加页数或历史深度；
  4. 最后才增加详情、评论、下载和 ASR 调用。
    正式定时运行前，至少确认：
  • 两个平台都能稳定返回；
  • ID 和互动指标映射正确；
  • 飞书去重经过二次运行验证；
  • 至少完成一次人工相关性反馈；
  • 已从 Just One API 控制台确认每天成本；
  • 接口失败、余额不足和字段变化有告警渠道。
    第二阶段：增量监控

当前试跑主要识别“账号相对异常”。要进一步发现“正在起量”，需要保存上一轮指标快照：

  • 上次点赞 / 本次点赞 / 点赞增量；
  • 上次收藏 / 本次收藏 / 收藏增量；
  • 上次评论 / 本次评论 / 评论增量；
  • 两次采集间隔；
  • 单位时间增长速度。
    “总量高”说明它曾经表现好；“短期增量高”才说明它可能正在起量。这是素材库和监控系统的关键区别。

第三阶段：深度拆解与通知

可以继续增加：

  • 对 Top 内容获取正文、评论或视频详情；
  • 对口播视频做 ASR，原文和 AI 分析分开保存；
  • 自动创建单条爆款拆解飞书文档；
  • 把文档链接回填到内容库；
  • 在飞书群推送日报、T2/T3 告警和接口异常；
  • 增加仪表盘、排行榜和执行看板。
    这些属于扩展项，不应在第一轮全部开启。

稳定后，把这一流程设置成自动化即可。

十五、0→1 验收清单

  • 飞书三张表和快速录入视图已创建；
  • 人只需填关键词、平台或账号主页；
  • API Token 只存在环境变量；
  • 两个平台至少各有一次成功响应；
  • 原始响应已脱敏保存；
  • 标准化字段和作品链接已人工抽查；
  • 平台 + 作品ID 去重有效；
  • 账号至少 5 条同批可用作品才计算 R；
  • 报告包含统计、异常、Top 10、Top 5 拆解和数据限制；
  • 飞书写入经过预览和用户授权；
  • 人已经标记至少一条相关性反馈；
  • 扩大规模前已确认 API 成本和异常告警。
    完成以上项目，这套系统才算真正从“能跑”进入“可用”。

最后

内容监控系统的价值，不是替人刷更多内容，而是把人的注意力从“重复翻主页”转移到“判断哪些内容值得行动”。

稳定的采集、去重和计算交给工作流；需要理解的拆解交给 AI；最终取舍交给人。三者边界清楚，系统才会越用越好，而不是逐渐变成一张无人维护的大表。

来源：@DZhao63405 · 发布于 2026-08-04 12:10:14 · 原文链接