CreatorHub：本地多平台内容管理面板——抖音 / 小红书 / …

一、它要解决的麻烦：多平台内容各自为政

做内容运营或二次创作的人，常常要在抖音、小红书、快手之间反复切换账号、手动盯更新、逐个下载，再分别排版发布。CreatorHub 把这个流程收拢到一个本地 Web 面板里。它的自我定位是一套「本地运行的多平台内容管理面板，支持抖音 / 小红书 / 快手 / 视频号」。账号登录态、数据库和媒体文件全部保存在本地，不上云——这也意味着抓取、下载和发布都必须在你自己机器上跑。

技术栈上，它用 Python + FastAPI 提供统一界面，浏览器交互按平台选用系统 Chrome CDP 或开源的 Patchright，业务层统一走兼容的 Playwright API；每个账号使用独立的浏览器 Profile，Cookie、缓存和本地存储互不共享。小红书相关实现参考了 Spider_XHS。这种「本地优先 + 账号隔离」的取向，是它和一堆网页端采集服务最本质的区别。

二、四平台能力全景

README 用一张对照表列出了四个平台分别支持到什么程度，差异很大，先看清边界再决定怎么用：

• 抖音：登录（扫码 / 创作者 / Cookie）、关键词批量采集、作品与评论监控、弹幕监控、下载（可选画质）、发布、自动评论回复，几乎全功能。
• 小红书：登录（扫码 / 创作者）、作品与关键词监控、评论监控、图集 / 视频下载、发布；关键词批量采集当前还在规划中。
• 快手：登录、作品 / 评论监控、下载、发布、自动评论，但没有弹幕与关键词批量采集。
• 视频号：只支持创作者助手里的本账号数据（作品 / 数据 / 评论），不支持监控或下载他人作品。

也就是说，抖音是能力最完整的平台，视频号则被刻意限制在「本账号」范围。README 特别说明：视频号只支持创作者助手中的本账号数据，不支持监控或下载他人作品。

（一）抖音、小红书几乎全功能

关键词批量采集目前仅支持抖音：一次最多 20 个关键词，可设每词作品数、每作品评论数、是否含二级评论及是否下载媒体；已结束任务支持编辑配置、去重续跑与 Excel 导出。作品监控、评论监控、弹幕监控（抖音播放页 / 创作中心）也都以抖音为先。小红书侧则侧重于作品与评论监控、图集 / 视频下载，以及图集、视频、定时发布。

（二）视频号只管本账号

视频号没有对他人作品的监控与下载能力，发布则通过对应创作平台完成。这对只想运营自己视频号的人来说够用，但别指望把它当成跨平台采集器去抓别人的视频号内容。新增目标默认只监控订阅后的作品，也可选择回填最近若干条历史内容。

三、浏览器架构与账号隔离

CreatorHub 最值得细说的是它对「浏览器内核」和「账号隔离」的处理，因为平台风控最在意的恰恰是设备指纹与登录态。它不让所有账号共用一个浏览器，而是为每个账号维护独立的持久化 Profile。

（一）小红书走系统 Chrome CDP

默认 xhs_browser_mode: auto：每个小红书账号启动一个独立、可见的系统 Chrome CDP 会话，长期复用该账号自己的 Profile、Cookie、缓存和本地存储。项目专用 Profile 与用户日常 Chrome 默认 Profile 完全分开；机器没装稳定版 Chrome 时，auto 会回退到可见的 Patchright Chromium，账号列表会显示实际后端与回退原因。cdp 为严格模式，Chrome 缺失或 Profile 冲突直接报错。

同一轮搜索与笔记详情复用账号现有浏览器进程和 Profile，不再每条笔记重启内核；页面停留时间按可见内容长度做有界抖动，滚动、输入、详情间隔和阶段性休息采用有限随机节奏。小红书发布和评论默认走 browser 页面模式，提交按钮只点一次，缺成功证据时任务标为「结果待确认」，不自动重试。旧配置值 playwright 会自动迁移为 patchright。

（二）可插拔指纹内核

除小红书外，CreatorHub 可把开源的 fingerprint-chromium 作为可插拔 Chromium 运行时，账号、Profile、Cookie、代理、LRU 和风控仍由 CreatorHub 管理，不需要外部商业浏览器或云端账号。新账号登录前会打开「登录前指纹配置」，语言、时区、位置、窗口可跟随出口 IP 生成或自定义；操作系统、浏览器品牌、CPU、WebGL、Canvas、WebRTC 等同样可编辑。小红书始终固定走系统 Chrome / CDP——README 解释，第三方指纹内核与既有 Profile 混用容易造成 UA / Client Hints、GPU 和站点持久状态不一致，从而增加设备安全验证，后端、登录接口和账号设置页都会拒绝该组合。

四、任务队列与平台风控

Web 面板的「任务队列」统一展示采集、发布、自动评论、账号动作与下载任务，默认启用 risk_control.mode: conservative，所有平台操作统一经过持久化调度与风控检查。这套闸门才是它真正区别于「脚本堆」的地方。

（一）默认保守策略

几道不可放宽的「保护线」：

• 同一账号的评论、账号动作、私信和发布共享写操作间隔与额度，立即执行也不绕过冷却。
• 同一网络出口的账号串行访问；未配代理的统一归入 direct 出口组。
• 轻读 / 重读分别计时；命中 403 / 429 / 461 / 471、验证码或明确风控提示后，阶梯式进入冷却。
• 被额度、时段、代理或冷却拦下的任务保持 pending，服务重启后恢复；登录态失效时任务保留等待重登。

（二）风控中心与恢复

「风控中心」集中展示正常、冷却、渐进恢复、登录失效、代理异常和网络熔断等状态，提供触发原因、冷却截止、恢复进度、任务级受阻原因、网络出口与事件时间线；规则页可调整读取间隔、冷却阶梯、恢复探测、写操作额度、出口组熔断和活跃时段，配置存本地数据库即时生效。人工解除、规则修改与人工探测都写入审计记录。存量账号沿用 legacy 浏览器画像，新扫码与 Cookie 账号使用 native 模式，避免已有 Profile 漂移。

五、安装与一键启动

环境要求：Python 3.10+、桌面环境（扫码登录需弹浏览器）、Google Chrome 稳定版（建议）、Node.js 18+（仅小红书 api 发布兼容模式）、系统 ffmpeg（可选）。克隆后用自带脚本一键启动：

git clone https://github.com/3441293738/creatorhub.git
cd creatorhub
.\start.cmd        # Windows
./start.sh         # macOS / Linux

首次运行自动建虚拟环境、装依赖与 Chromium、生成 config.yaml，随后打开 http://127.0.0.1:8000。常用子命令：install 重装依赖、check 环境自检、–no-open 不自动开页、–port 指定端口、–reload 开发模式。macOS / Linux 把 .\start.cmd 换成 ./start.sh。仅当启用小红书 API 发布兼容模式时，才需要额外 npm install。

六、从加账号到内容搬运

日常流程都在 Web 面板里完成，不需要记命令；但命令行也能处理分享链接。

（一）添加与监控

顶部选平台，左侧「账号」里选扫码 / 创作者 / Cookie 登录；小红书扫码只取主站读取态，要发布需再用独立的「创作者登录」。监控方面：关键词批量采集（抖音）、作品监控（加主页 / 链接 / 短链 / ID）、评论监控（单条作品或账号近期作品）、短视频弹幕监控（按时间轴渐进探测、可过滤、持久化到 SQLite）。下载支持断点续传和失败重试，抖音可选画质，小红书支持图集和视频。搜索结果受平台排序、登录态和可见范围影响，作品数与评论数只是采集上限，不代表全量。

（二）发布与转发

小红书支持图集、视频与定时发布；抖音、快手、视频号通过对应创作平台发布。已下载的抖音作品可转发到小红书或视频号，小红书作品可转发到抖音，发布前能改标题、正文和话题。私信自动回复支持关键词、排除词、多模板、回复冷却与最大消息年龄，默认生成待审核草稿，免审后也仍经过活跃时段、写间隔、小时 / 每日上限与风险冷却。命令行也能只解析或下载分享链接，把 SHARE_TEXT 换成完整分享文案或链接即可：

python -m app.engine.share_downloader "SHARE_TEXT" -o ./data/media/share -q 1080

七、配置、数据与命令行下载

首次启动从 config.example.yaml 生成 config.yaml，常用项也能在 Web「设置」里改。

（一）配置文件片段

几个常用取值：

engine:
  scan_interval_seconds: 300
  monitor_initial_backfill_count: 0   # 0=只监控新作品，-1=尽可能回填
  worker_pool_size: 2
  scan_concurrency: 2
  media_dir: ./data/media
proxies: []   # 不使用代理

（二）数据目录与备份

数据落在本地 data/：creatorhub.db（SQLite）、media/（下载内容）、profiles/（账号浏览器配置与登录态）。备份项目时建议一并备份 config.yaml 和 data/。数据库字段启动自动迁移，升级通常无需删旧库。config.yaml、数据库、登录态和媒体默认不进 Git；每个账号独立浏览器目录，用代理建议绑稳定独立代理。

八、常见问题与避坑

从 README 的 FAQ 挑几条高频的：

• 扫码登录没弹窗：确认有桌面环境；抖音也可改用 Cookie 登录。
• 小红书扫码出现设备安全验证：装 / 更新本机稳定版 Google Chrome，保持同一账号 Profile 与网络出口稳定；验证页出现后自动任务暂停，不刷新、不跳转、不自动重试，在可见窗口按平台提示完成。
• Windows 下 Patchright 子进程报错：用单 worker 启动，不要加 –workers。
• 小红书链接解析失败：重新复制含有效 xsec_token 的完整链接。
• 仅音频仍得到 MP4 / 视频没声音：重跑安装命令更新依赖，或装系统 ffmpeg 加入 PATH。

九、总结与合规提示

CreatorHub 的价值不在「更强的模型」，而在把多平台内容运营里最琐碎、最分散的监控—下载—发布环节，用一套本地优先、账号隔离、带风控闸门的面板收拢起来。它把登录态、媒体和数据都留在你机器上，也把平台风控的「低频、稳定出口、结果待确认不重试」等纪律固化进了默认策略。对需要同时打理抖音、小红书、快手多个账号的个人或小型团队，它是个务实的本地工具箱；但请始终把它当作「自己内容的管理器」，而不是抓取他人内容的武器。

在撰写本文的过程中，我主要参考了以下来源：GitHub 仓库 3441293738/creatorhub 的 README（含平台能力表、浏览器环境、任务队列与风控、配置说明）、config.example.yaml，以及仓库自带的 Star History。文中数据（Star 数、能力矩阵等）以仓库公开信息为准，可能随版本更新而变化。