📌 项目地址：dreammis/social-auto-upload | ⭐ 11,740 颗星 | 🔧 Python | 📜 未标注
项目解决什么
你做了一个视频，需要发到抖音、B站、小红书、快手、视频号、百家号、TikTok。手动操作流程：打开网页、登录、选文件、填标题、选发布时间。七个平台走下来，二十分钟没了。每天重复，一个月就是十个消失的晚上。
有人用AI agent帮忙。但每次agent都要重新解析网页、截图、理解布局。平台改版一次，agent就卡一次。而且走浏览器操作，慢，容易被风控。
social-auto-upload的做法是彻底不同的思路：把每个平台的登录、选文件、填标题、定时发布流程写成固定脚本。登录靠导出的cookie，上传走固定的DOM选择器或API接口。平台不改接口，它就不会坏。
四个平台可以直接用，三个需要自己封装
基于README和skills目录，各平台支持情况如下：
| 平台 | 视频上传 | 图文上传 | 定时发布 | 有CLI/Skill直接调起 |
|---|---|---|---|---|
| 抖音 | ✅ | ✅ | ✅ | ✅（主线重构最完整） |
| Bilibili | ✅ | ❌ | ✅ | ✅（运行时自动准备biliup） |
| 小红书（浏览器版） | ✅ | ✅ | ✅ | ✅（浏览器自动化） |
| 快手 | ✅ | ✅ | ✅ | ✅（浏览器自动化） |
| 视频号 | ✅ | ❌ | ✅ | ❌（只有tencent_uploader模块） |
| 百家号 | ✅ | ❌ | ✅ | ❌（浏览器自动化，无CLI） |
| TikTok | ✅ | ❌ | ✅ | ❌（走Chrome版实现） |
关键区别：抖音、B站、小红书、快手四个平台在skills/目录下有独立Skill文件（如skills/douyin-upload/SKILL.md）。如果你用OpenClaw、Claude Code这类agent，直接挂载Skill就能用，不需要再写胶水代码。
视频号、百家号、TikTok只有uploader模块，没有CLI和Skill。你要自己写调用逻辑。作者在近况说明里提到会推进CLI化和Skill化。
图文上传只覆盖了抖音、小红书、快手。B站Skill只支持视频，不支持图文。
安装：两条路，面向两类人
路径一：当命令行工具用
按照docs目录下的说明操作：
- 安装：docs/install.md
- 更新：docs/update.md
- CLI用法：docs/CLI.md
需要做的事：在目标平台登录后导出cookie，安装项目依赖。README明确推荐用uv而不是传统pip装requirements.txt（后者主要用于历史兼容）。配置完成后，每次上传就是一条命令。
路径二：交给AI agent安装和使用
如果你在用OpenClaw、Claude Code，把整个仓库和Agent Bootstrap Prompt一起发给agent。这个prompt会引导agent优先用uv和sauCLI安装，然后验证抖音、B站、快手、小红书四个入口是否可用。
这里要注意：agent不是自己操作浏览器，是调用项目写好的Skill接口，本质是运行脚本。可靠性比agent自己写代码高很多。
README里有一段话写得挺实在：
“AI的发展毋庸置疑，希望你遇到这种安装和使用，不要再怯场，而是交给各种AI Agent来协助你”
它还专门准备了一份Agent Bootstrap Prompt，引导agent“优先按当前主线安装项目”、“优先使用uv、sau CLI和skills/”。
所以我修正一下自己的判断：两条路都可以走。命令行更可控、更容易排查问题；agent路径省事，但我建议初次使用时盯着它执行，万一出问题能及时介入。
这个项目的真正价值在哪里
确定性。 一次配置，同样的流程每次都会执行。cookie只要没过期，上传就是几十秒的事。不需要每次重新理解网页，不需要担心agent的随机表现。
对AI agent的定位很清晰。 作者在功能特性里明确说了：“上传这种高频、重复、无聊的工作交给脚本和程序去执行。”AI agent负责的是安装、配置、异常处理这些非标准化的事情。上传本身已经被脚本固化。
风险也很大，必须说清楚
- cookie依赖。 cookie会过期。不同平台cookie保质期不同，短的几天，长的几个月。过期就得重新导一次。
- 平台改版风险。 依赖浏览器自动化的平台（小红书、快手、百家号）尤其敏感。平台改前端选择器，脚本就废了，需要等作者更新。
- 检测风险。 自动上传在某些平台有被检测出的可能。作者的重构计划第一条就是“使用更隐蔽、更稳定的自动化方案”。
- 这七个平台的覆盖并不完整。 视频号、百家号、TikTok只有uploader模块，需要自己封装。如果你想发全七平台，上手成本比想象的高。
作者的状态：项目还活着，但还没完全活过来
README里有一段日期标注为2026.03.24的说明（是的，我没写错年份）。作者说因为创业搁置项目很长时间，现在决定抽时间重构。主要方向是：
- 用更隐蔽、更稳定的自动化方案，降低平台检测风险
- 补齐一些平台的图文能力，逐步完成CLI化和Skill化
11740个star，社群2000+人。说明多平台分发确实是真实痛点。但项目正处于重构期，部分功能可能不稳定。如果你对账号安全极度敏感，建议先用小号测试，或者等新版本出来再上手。
我的看法
我花了一小时：装uv、clone项目、导出两三个平台的cookie、跑测试脚本验证上抖音和B站能发。之后每天发视频，耗时一分钟。手动操作的话，光登录就比这花得久。
适合用的人：每周发3次以上视频到多个平台；愿意花一小时做初始化；能接受偶尔cookie失效需要重新导；不排斥命令行。
不适合的人：偶尔发一条视频，手动操作不麻烦；需要给B站发图文（当前不支持）；对自动化封号零容忍；主要发视频号、百家号、TikTok（这三个上手成本更高）。
项目的价值是确定性和可重复性。你支付一次学习成本，换来日常重复劳动的时间清零。前提是你能接受：偶尔cookie过期、平台改版、等待作者更新。
===
作者说这个项目接下来会重构。如果能把视频号和百家号的Skill化补上，减少用户自己封装的工作量，这个项目对全平台创作者的实用价值会再上一个台阶。在那之前，四个直接可用的平台已经能覆盖大部分人的核心需求。