cover

一个人管十几个抖音号：把创作者中心包成一个 API

你是不是也这样管账号：发视频要打开网页、看数据要一个个点进去、回评论要手动敲字——尤其账号一多，每个号都要重复这些操作，一天的功夫全耗在"点网页"上了。

这篇分享一个思路：把抖音创作者中心日常要做的三件事——看数据、发内容、回评论，统一封装成一套 REST API。以后不管是定时脚本、n8n 工作流还是 AI 自动回评，都能像调普通接口一样调抖音。

痛点：抖音没开放 API，运营全靠人肉

做内容矩阵的人，每天至少有这三件逃不掉的活：

问题是：官方把这三件事分散在网页各处，而且完全不开放 API。想自动化？没门。账号一多（10 个号、20 个号），这些重复劳动就成了纯体力活——这就是这个服务要解决的核心痛点：把"网页人肉操作"变成"接口调用"。

思路其实不复杂：用无头浏览器去代替人操作网页，外面再包一层统一接口。拆成三个能力域：

① 数据类（只读）——账号概览、作品列表、单作品核心指标（完播率/5s 停留/播放来源）、粉丝画像、评论、私信……想要啥有啥。特点是缓存优先：第一次请求去网页抓，5 分钟内的重复请求直接返回缓存，不烦抖音。

② 动作类（异步）——发视频、发图文、回评论、发私信、下架/置顶。这些是慢动作（要开浏览器真干），所以设计成任务队列：调用后立刻返回 task_id，后台慢慢执行，你轮询进度即可。

③ 登录/账号（扫码一次）——每个账号扫码登录一次，cookie 存本地，之后所有接口自动带 cookie。多账号就多登几个号，调用时指定用哪个账号。

几个关键设计：

统一账号体系：一个号一份 cookie，X-Account 头切换，10 个号一个 URL 全看
接口路径按 /{platform}/xxx 设计：现在实现的是抖音，将来接小红书、B 站、视频号，只加个 adapter 就行——这不是拍脑袋，是给多平台留好了位置
部署很土但有：Docker 跑起来就行，内存 ≥4GB（要养无头浏览器）

这个服务的最终价值，是把矩阵运营的成本结构彻底改变：

场景 1：定时自动发——crontab 每天 7:00 自动发一条视频。上游接"AI 写脚本 → 剪映自动剪 → 传 S3"，一个人管十几个号，一条龙全自动。

场景 2：AI 自动回评论——脚本每 5 分钟拉新评论 → 大模型带人设生成回复 → 自动回。人设保持一致，互动率反而涨。

场景 3：数据日报——每天 23:00 自动汇总今日粉丝/播放/画像变化，生成 markdown 发到 Slack。

场景 4：私信自动化销售——按关键词分流：咨询的 AI 回、购买的单记进 CRM、客服的转人工。

场景 5：闭环内容工厂——和之前的飞瓜选题、大模型生稿、TTS 配音、自动剪片组合起来：选题 → 生成 → 发布 → 数据 → 优化 → 再选题，一个人在前台看着就行。

cookie 会过期：抖音 cookie 一般 1-4 周，过期接口返 401，重新扫码即可
防封号是门玄学但也规律：风控看的是行为模式，不是"你用了 API"——回评太频、点赞太快、内容重复率太高都容易被判机器。加随机延迟、行为多样化、单账号控量（一天回评 ≤50、发布 ≤3-5 条）；真金白银的主账号别玩自动化，用小号试跑
视频素材必须公网可访问：发布页的浏览器要"下载"你的视频文件，所以素材得放 S3/OSS 或你的服务器上，且不能被反代挡住

这套东西最大的价值不是"能发抖音"，而是把账号运营从离散的网页操作，变成了可以被程序编排的标准接口。矩阵越大，省的时间越多——这才是"一个人管十几个号"真正可能的原因。