CreatorHub：一个 Web 面板管理抖音/小红书/快手/视频号内容工作流

这个仓库创建于 2026 年 7 月，两个多月不到已经积累约 1.6k Star、267 Fork 和 93 次提交。

CreatorHub 想解决的事情很具体：做多平台内容时，账号登录、作品监控、评论、下载、发布和通知散落在不同网页，能不能放到一个本地面板里管理？

它目前覆盖抖音、小红书、快手和视频号。项目使用 Python 与 FastAPI 提供 Web 界面，登录态、SQLite 数据库、任务记录和媒体文件默认留在本机。

我打开了仓库提供的在线预览。页面可以切换四个平台，并展示账号、作品监控、关键词采集、评论、弹幕、发布、链接下载、通知和风控中心。预览用的是脱敏示例数据；真实登录、抓取、下载和发布仍要在本地运行。

它管的不只是一排发布按钮

抖音侧目前覆盖关键词批量采集、作品与评论监控、弹幕监控、下载、发布和账号管理。小红书可以监控创作者与关键词、下载图集和视频、发布图文或视频。快手覆盖监控、下载与发布；视频号更收敛，主要处理本账号数据与发布。

真正让它像“工作台”的，是任务被放进了同一条链路。

账号进入系统后，每个账号拥有独立浏览器 Profile。小红书默认优先使用系统 Chrome 的 CDP 会话，没有合适的 Chrome 才回退到可见的 Patchright Chromium。平台适配层负责页面解析、登录和发布，监控引擎负责轮询与队列，结果写进 SQLite，媒体保存到 data/media，通知可发送到 Bark、钉钉或 Telegram。

图里更该看的是下方风控闸，它把四个平台的动作拉回同一套规则。

风控中心为什么要单独做

评论、私信、关注和发布都属于平台写操作。CreatorHub 默认启用 conservative 模式，把这些动作放进共享预算：同账号保持间隔，同网络出口串行执行，遇到 403、429、验证码或明确风险提示后进入分级冷却。

发布提交后如果浏览器连接中断，又没有拿到成功证据，任务会标记为“结果待确认”，不会直接重试。这种处理看起来不够自动，却能避免网络抖动造成重复发布。

风控模块只能降低误操作概率，不能保证账号安全。平台规则、页面结构和验证策略会变化；自动评论、私信和高频采集依然需要克制使用。

安装门槛没有界面看起来那么低

Windows 克隆仓库后可以运行 start.cmd，macOS 或 Linux 使用 start.sh。启动器会创建虚拟环境、安装 Python 依赖与 Chromium、生成 config.yaml，默认打开 http://127.0.0.1:8000。

基础环境需要 Python 3.10 以上和桌面环境。小红书扫码更建议使用系统 Chrome；只有显式开启小红书 API 发布兼容模式时，才需要 Node.js。视频处理还会用到 OpenCV、yt-dlp 与 ffmpeg。

仓库准备了 selftest.py，会检查签名原语、风控策略、Patchright、Node.js 状态和分享文案解析。先跑自检，比装完依赖就拿真实账号试发布稳妥。

和几类相近项目怎么选

MediaCrawler 更偏公开内容采集，覆盖的平台更多，输出也能落到 CSV、JSON、Excel、SQLite 或 MySQL。你的核心任务是关键词、帖子和评论数据采集，它的定位更直接。CreatorHub 进一步把本账号管理、持续监控、下载、发布和通知放进同一个本地面板。

social-auto-upload 聚焦多平台发布，CLI、Skill 和定时上传路径更成熟，也覆盖 B 站、TikTok、YouTube 等平台。只想把同一批素材发出去，可以优先研究它；如果还想在发布前后管理账号、评论和监控任务，CreatorHub 的范围更完整。

OmniPost 同样主打可视化多平台发布，技术栈和前后端分层更像完整应用。CreatorHub 当前体量更轻，Python 启动脚本更直接，同时把本地数据与账号风控写得更细。

谁适合用，谁先别急

它适合愿意在自己的 Windows、macOS 或 Linux 电脑上维护登录态的内容创作者，也适合需要观察作品、评论与下载记录的小团队。

如果你只偶尔发一条内容，四个平台官方后台反而更省维护成本。没有桌面环境的服务器也不适合扫码登录和可见浏览器操作。

还有一个现实问题：截至本次检查，仓库没有正式 Release，GitHub API 也没有识别到许可证，根目录未看到 LICENSE。可以阅读和试用公开代码，但团队部署、修改分发或商业使用前，应先向作者确认授权边界。

我这次核对了 README、依赖、启动脚本、自检、配置、风控模块、测试目录和在线预览，没有替读者登录真实平台账号，也没有执行采集、评论或发布。涉及账号和外部平台的动作，应该由使用者自己确认权限与内容版权。

复制给 Agent 试一试

把下面这段复制给你的 Agent。

1. 在隔离目录拉取项目： git clone https://github.com/3441293738/creatorhub.git cd creatorhub 2. 阅读 README.md、config.example.yaml、requirements.txt、selftest.py 和 start.cmd/start.sh，检查 Python 3.10+、桌面环境及可选 Chrome。 3. 只安装本地依赖并运行环境自检。Windows 使用 .\start.cmd check，macOS/Linux 使用 ./start.sh check；不要登录平台、采集数据、评论、私信或发布内容。 4. 自检通过后以 --no-open 启动，确认 http://127.0.0.1:8000 可访问。最后汇报安装目录、依赖、配置文件、本地数据位置、自检结果和风险；不要上传 Cookie、Profile、代理凭据或 API Key。

我的建议

先把 CreatorHub 当作本地内容工作台来评估，不要一开始就添加多个真实账号。

用空数据库跑通自检和面板，读懂 data/、Profile、任务队列与风控配置，再选择一个自己有权管理的账号做低频测试。发现平台提示异常时，停下来核对，比自动重试更重要。

参考仓库

• https://github.com/3441293738/creatorhub