有个做编程教程的团队跟我算过一笔账。
在短视频平台发十条视频，从选素材到点发布，半小时不到。同样十条内容发到 B站，一条要四十分钟。
我问他四十分钟花在哪。他说：传上去要等，转码要等，审核要等，中间还得填分区、标签、封面、简介。真正动手的时间不到五分钟，剩下三十五分钟都在等。
这个账挺说明问题的。B站的投稿，难点不在操作，在等待。
先把 B站投稿的流程拆开
要判断哪些能自动化，得先数清楚一条稿件要经过多少环节。
上传。这里就分岔了：短视频通常几十兆，中长视频几百兆到几个G。同一个网络环境，上传时间能差两个数量级。
转码。平台会把你的视频转成自己的格式。这个过程你控制不了，时间跟视频长度和当时的队列有关。
审核。机器审核通常几分钟，涉及人工复审的可能要几小时到一天。这一步的不确定性最大。
填信息。分区、标签、封面、简介、分P。B站对分区和标签的要求比短视频严，选错了会影响推荐。
发布。
五个环节里，前两个是时间和带宽问题，第三个是不确定性问题，只有第四个是真正可以标准化的操作。
哪些能交给电脑，哪些只能等
按这个划分，能自动的其实是后面半段：
| 环节 | 能不能自动 | 说明 |
|---|---|---|
| 文件准备与分发 | 能 | 把视频推到设备相册，多台分别处理 |
| 填写信息 | 能 | 标题、简介、标签、分区可以批量准备并按稿传入 |
| 稿件登记与状态跟踪 | 能 | 记下投稿时间、标题，定期回来核对状态 |
| 播放数据回收 | 能 | 定期把数据汇总起来，方便复盘 |
| 上传时的等待 | 不能 | 时间取决于文件大小和网络 |
| 平台转码 | 不能 | 完全在平台侧 |
| 审核结果 | 不能 | 通过与否和时间都不由你控制 |
看清这张表，你就知道工具该用在哪了。后三行是上游的不可控因素，任何工具都帮不上忙。
分P 是个得单独对付的东西
分P 是 B站特有的结构：一个稿件下面挂多个视频分段，观众在一个页面里连着看。
对教程、系列课、合集这类内容，分P 是很实用的组织形式。但它给批量投稿添了额外的工作量，因为你要处理的不只是一个文件，是一整套参数：分P 的顺序、每段的标题、哪一段当封面、简介怎么写。
这里有个现实的取舍。如果你的内容天然适合分P（比如一个课程有二十讲），那这套参数值得花时间做模板，一次配好长期复用。如果只是普通的单段视频，硬拆成分P 反而添乱，没必要。
顺便说一句，分P 这种「一个稿件多个分段」的结构，在手机上操作比在电脑上更考验流程稳定性——每一步都要等上一段加载完成才能继续，等待时间设短了就容易出错。
多账号在 B站值不值得做
这点我建议比其他平台更谨慎。
B站的内容生态是靠 UP 主个人品牌撑起来的，观众关注的是这个人，不是这个号。这意味着账号矩阵的价值本身就打了折扣——十个没有辨识度的号，可能不如一个有忠实观众的号。
而且 B站的搬运判定和原创要求比短视频平台严格，同质内容铺到多个账号，被识别的概率更高。
真要做的话，我的建议是按内容方向拆，而不是按数量堆。比如一个号做技术教程，一个号做产品评测，一个号做行业观察。三个号定位清晰，观众不会混淆，也不容易被判定为矩阵。
所以 B站这条线更适合「每个号都当正经号运营」，而不是「铺量博概率」。这跟短视频平台的思路不一样。
怎么搭起来
如果你的判断是要做，按这个顺序：
第一步，把设备准备成可靠的执行单元。按 安装选型 装好工作站和手机端程序，把要用的手机入库、起别名、分组。别名在这一步特别有用——不同账号对应不同设备，一个能认出来的名字能省掉大量「我刚才跑的是哪台」的困惑。
第二步，把文件送到设备上。用 文件分发 把视频推到手机相册。文件大的话分批推，不要一次全推，容易把网络占满。iPhone 上要先开相册权限，不然文件推过去了脚本也存不进相册。
第三步，用中文把投稿流程说一遍。在 对话 页描述流程：打开 B站、进投稿入口、从相册选视频、填标题和简介、选分区和标签、点提交。第一次跑的时候把提交留在人工确认。
第四步，固化成工作流。跑顺之后存成 工作流，把标题、简介、标签、分区这些变动内容留成参数。这样一条模板能覆盖一批稿件，而不是一条稿件一条流。
第五步，用执行历史跟踪。跑完去 执行历史 核对结果。投稿状态和播放数据建议定期回收一次，方便复盘。
流程里如果遇到纯图标按钮（没有文字可识别），补一条 找图模板 告诉它按钮长什么样。
为什么我不建议做成全自动
有人会问：既然能自动化，为什么不干脆全做完？
因为上游那三个不可控的因素。上传要等、转码要看队列、审核结果会变，全自动在这三步上帮不上忙。而一旦某条稿件卡住，全自动流程里排查起来很麻烦——你不知道是失败了、还是正在等审核。
我更推荐的组合是：上传这一步人工操作加记录，其余的登记、状态跟踪、数据回收交给电脑。 听着不如「全自动」漂亮，但稳得多，出问题也容易定位。
回到那个做教程的团队。他们最后没追求全自动，而是把工作拆成两半：人和电脑各管一段。上传时人手点一下，同时脚本记下投稿时间和标题；其余的分区、标签、状态跟踪和播放数据回收，全都交给电脑。按他们的说法，这样反而比全自动省心——该等的地方还是等，但不用一直盯着等。
如果只是给自己一两个号投稿，说实话网页端更顺手。但如果你手上是多账号、而且想和其他平台用同一套流程管起来，可以按上面的步骤试试，先从一条视频跑通。
常见问题
- B站投稿和短视频平台，最大的差别在哪？
- 文件体积和流程长度。短视频通常几十兆，中长视频几百兆到几个G，上传时间从几十秒变成几分钟到几十分钟，中间还要等转码和审核。所以瓶颈从操作次数变成了带宽和等待时间。
- 那到底哪些环节能自动化？
- 能自动的：文件准备与分发、封面和标题的批量填写、稿件的登记与状态跟踪、数据回收。不太能自动的：上传本身的等待、平台转码、审核结果。这几步的时间你控制不了。
- 分P 是什么，为什么要单独处理？
- 分P 是 B站特有的结构，一个稿件下面可以挂多个视频分段，观众在一个页面里连着看。麻烦在于分P 的顺序、每段的标题、哪一段当封面都要分别设置，处理的是一整套参数而不是一个文件。
- 多账号在 B站上值得做吗？
- 比其他平台更值得谨慎。B站的内容生态靠 UP 主个人品牌撑着，观众关注的是人不是号，十个没有辨识度的号可能不如一个有忠实观众的号。真要做，建议按内容方向拆，而不是同一批内容铺开。
- 上传要多久？能并行吗？
- 看文件大小和网络。一个几百兆的文件在普通宽带上要几分钟，几个G 的要几十分钟。并行上传会争抢带宽，实际总时间不一定短，建议按设备的优先级分批推。
- 审核要等多久？
- 不确定。机器审核通常几分钟，涉及人工复审的可能几小时到一天。这也是为什么批量投稿不能用「发完立刻验证」的方式管流程，需要一套隔一段时间回来核对的机制。
- 视频文件怎么分发到多台手机？
- 按文件大小选。小的用批量推送，几十台也还好；大的分批推，或者把文件放在一个可访问的地址上让设备自己下载。要注意 iPhone 上相册权限要先开，否则文件推过去了也存不进相册。
- 为什么不干脆做成全自动？
- 因为上游有三个不可控的东西：上传耗时、平台转码、审核结果。全自动在这三步上帮不上忙，反而一旦出错排查成本很高。人工上传加脚本登记状态，是更稳的组合。