一、视频说的 6 平台，实际是 11 个
视频截图写「一条视频发 6 个平台」，但 GitHub API 实查 + README 全读完发现：实际支持 11 个平台——抖音 / Bilibili / 小红书 / 快手 / 视频号 / 百家号 / 支付宝生活号 / 微博 / 虎扑 / TikTok / YouTube。截图漏了 5 个（百家号 / 支付宝 / 微博 / 虎扑 / 支付宝生活号）。星标也差一档：截图写 15.3K，实查 15,406（2,613 forks / MIT / Python / pushed 2026-09-02 / created 2023-12-04，71 open issues）。
二、机制：为什么走浏览器自动化不是官方 API
这是正文最关键的一节。抖音、TikTok、小红书都没有开放给第三方的视频上传 API（官方 API 主要面向企业内部数据查询、广告投放，不是「第三方自动发内容」），所以这工具的实际落地路径是：用 patchright（Playwright 的一个隐蔽 fork）驱动 Chrome 跑无头模式，模拟真人点浏览器上传流程，再配上 sau CLI 把命令行参数转成浏览器动作。这是它跟"走官方 API 的发布工具"（比如走 YouTube Data API v3 的）本质不同的地方——YouTube 那条线其实可以走官方 API，但抖音/快手/小红书/B站这几条只能走浏览器自动化。
架构上：CLI 命令（sau douyin login --account xxx → upload-video）+ Skill 文件（skills/douyin-upload/SKILL.md 等 4 个平台已上线，给 Claude Code / OpenClaw / Codex 直接读）+ SQLite 记录防重复上传 + account.json 多账号配置 + 定时发布。作者 2026.03.24 在 README「近况说明」里自述「最近创业没怎么投入，9k+ star 社群 2000+ 人，决定停下来重构」，当前主线是换 patchright 驱动（比 Playwright 更隐蔽）+ 补齐 CLI/Skill + 无头模式，web 管理界面（sau_backend/ sau_frontend/）已明确「不保证可直接运行」。
三、能力矩阵（README 表原样摘）
| 平台 | 视频上传 | 图文上传 | 定时发布 | CLI | Skill | 底层 |
|---|---|---|---|---|---|---|
| 抖音 | ✅ | ✅ | ✅ | ✅ | ✅ | 当前主线重构最完整 |
| Bilibili | ✅ | ❌ | ✅ | ✅ | ✅ | 运行时自动装 biliup |
| 小红书（浏览器版） | ✅ | ✅ | ✅ | ✅ | ✅ | 浏览器自动化 |
| 快手 | ✅ | ✅ | ✅ | ✅ | ✅ | 浏览器自动化，CLI/Skill 初版 |
| 视频号 | ✅ | ❌ | ✅ | ✅ | ❌ | 浏览器自动化（tencent_uploader） |
| 百家号 | ✅ | ❌ | ❌ | ✅ | ❌ | 浏览器自动化 |
| 支付宝生活号 | ✅ | ❌ | ❌ | ✅ | ❌ | 浏览器自动化 |
| 微博 | ✅ | ❌ | ❌ | ✅ | ❌ | 浏览器自动化，标题 ≤30 字 |
| 虎扑 | ✅ | ❌ | ❌ | ✅ | ❌ | 浏览器自动化，标题 4-40 字 |
| TikTok | ✅ | ❌ | ✅ | ❌ | ❌ | Chrome 版实现 |
| YouTube | ✅ | ❌ | ❌ | ✅ | ❌ | 浏览器自动化（Studio），可加播放列表/可见性 |
四个「★全项」的平台（抖音/B站/小红书/快手）是当前主线，剩下 7 个是「浏览器自动化」的补齐项。
四、跟站内 2 篇同题材的分流
站内已经发过 2 篇「多平台分发」相关的：
- article-118 矩媒 MatrixMedia（825★ / GPL-2.0 / Electron+CLI+MCP）：一条视频铺 8 平台（抖音/快手/百家号/B站/头条/视频号/小红书/番茄视频），走 Electron 桌面 UI + CLI 退出码脚本化 + 4 个 MCP tool。跟 social-auto-upload 的差异：MatrixMedia 是「GUI 桌面工具 + MCP 入口」，social-auto-upload 是「纯 CLI + Skill + 多账号」，后者平台更多（11 vs 8）、MIT 更宽松（GPL-2.0 传染性对商用不友好）。
- article-91 MultiPost（1.2K★ / 浏览器插件 / 偏文字社交）：同步 Twitter / LinkedIn / Reddit 这类「文字帖」，跟 social-auto-upload 主攻「视频」是完全不同赛道。
三者关系：MultiPost = 文字社交分发 / MatrixMedia = 视频矩阵 GUI 桌面版 / social-auto-upload = 视频矩阵 CLI 脚本版（平台最多、License 最宽松）。
五、账号安全边界（截图评论区就问的）
这是正文要专门钉死的一节。截图底部就有用户问「@元宝 账号安全吗？」。诚实回答：这工具本质是伪装正常用户行为（patchright 跑无头 Chrome 模拟点击），不是走平台官方 API（抖音/TikTok 没开放第三方视频上传 API，绕不开浏览器）。所以：
- 封号风险客观存在——平台风控系统识别的是「行为模式 + 环境指纹」，patchright 比 Playwright 隐蔽是相对事实（作者 README 明说在换它就是为了降检测风险），但**不是零风险**，尤其是新号 + 频繁操作 + 多账号同 IP 这种场景。
- 作者自述的「密集重构降检测」还没完成（2026.03.24 说的计划，到 09-02 pushed_at 还在推进中），别当成"已经很安全"。
- 别拿主号跑——工作室矩阵账号 / 养号跑没问题，个人唯一抖音号跑自动上传，封了没得哭。
- 多账号隔离：每账号独立
account.json配置，建议每账号独立 IP + 独立浏览器 profile，sau_backend里的account_manager模块就是干这个的。
一句话：它是「省事的灰区工具」，不是「安全的白区工具」。平台没给你开放 API，你又要自动化发布，就只能走浏览器伪装，天经地义地承担平台检测风险。这个边界正文必须讲清，不能当"免费神器"直接推。
六、判断
该不该用？分两档：个人偶尔发视频——不推荐，手工 6 个平台点 6 遍也就 30 分钟，装环境 + 登录 + 配 CLI + 跑脚本的成本更高，还搭上封号风险；工作室 / 内容矩阵运营——推荐，11 平台 + 定时 + 多账号 + SQLite 防重，就是为这种场景生的，且 MIT 协议商用不碍事。跟 article-118 MatrixMedia 二选一：想开箱即用桌面 GUI 选 MatrixMedia（825★/GPL-2.0），想纯脚本化 + 平台更全 + MIT 选 social-auto-upload（15,406★/MIT）。核心卖点不是"能发"（能发的不少），而是"平台最多 + License 最宽松 + Skill 化能喂给 Claude Code"，这三条组合起来是同类里最完整的。