为了WAIC多平台直播，我用AI搭了一套系统

2026年7月19日下午2点，我会在世界人工智能大会现场开播。这次我负责小红书和搜狐视频的官方报道，我的参会票也是小红书给的。我的任务，是把同一套现场画面同时送到两个平台。

很多朋友可能不知道，平时在手机上看到的直播画面，是手机持续上传到平台的。这里先把最核心的逻辑讲清楚。

如果只在一个平台播，直接打开这个平台的手机应用，点一下开播就行。此时手机拍到的画面，会持续上传到这家平台的直播服务器。这个把视频不断发出去的过程，就叫推流。

可我这次要同时给小红书和搜狐视频做直播。手机如果直接在小红书里开播，画面只会送到小红书；直接在搜狐视频里开播，画面也只会送到搜狐视频。两边同时需要同一套画面，就得在中间增加一个自己的服务器。

整个过程其实很简单。手机先把直播画面上传一份到我的服务器，服务器收到后，再复制成两份，一份送到小红书，一份送到搜狐视频。

你可以把手机理解成前方记者，把服务器理解成后方中转站。前方记者只需要交一份素材，中转站负责把它分发给不同媒体。

这套方法还有一个很现实的好处。假如手机直接向两个平台各传一路，同一段视频就要上传两遍。原本只需要1 Mbps左右的上行带宽，两路就要占用大约两倍，还会增加手机发热和耗电。

平时在家里，这点带宽可能不算什么。WAIC会场就不一样了。我提前做了功课，场馆人多，现场网络条件很可能比较差。大量观众同时用5G，基站可能拥塞；我还要边走边播，信号质量会不断变化。

你想想看，在这种环境里，能少用一点带宽，就多一点不卡顿的可能性。反正我觉得，直播前把最坏情况多想一步，总比到了现场看着画面转圈更好。

所以手机只上传一路，是我做的第一层减法。

说到这个，视频画面本身也可以继续压缩。我这次把码率设在1 Mbps左右，并使用H.265编码。

码率可以简单理解为，视频每秒钟要通过网络的数据量。码率越高，通常画面越清楚，占用的网络也越多。H.265的优势，是在相近画质下比H.264更节省带宽。对我来说，选择H.265就是为了用更少的流量，把还看得清的现场画面送回服务器。

新的问题马上又来了。这块需要注意一下，我的下游接的是小红书和搜狐视频的传统RTMP／FLV直播链路，它们对H.264的兼容性更好。直接把H.265一路送到底，容易卡在格式兼容上。

怎么办？我在服务器上做了一次实时转码。

手机到服务器这一段，继续用1 Mbps左右的H.265，尽量降低会展现场的网络压力。服务器收到画面以后，实时把H.265转换成平台更容易接收的H.264，再分别送给小红书和搜狐视频。

这一步很像把一份体积更小的压缩文件从现场带回来，到了网络稳定的中转站，再转换成两家平台都认识的格式。压缩解决现场带宽，转码解决平台兼容，服务器转推解决多平台分发，三个问题正好一层接一层。

整套服务器转推服务、实时转码程序，以及双路网络调度的逻辑，都是GPT-5.6 Sol模型帮我开发和搭建的。

我采用Vibe Coding的方式，把目标和现场限制告诉它：手机只能尽量少上传；要同时发到小红书和搜狐视频；手机传H.265，服务器实时转成H.264；某一条网络不稳定时，还要有另一条网络接力。

GPT-5.6 Sol根据这些要求写程序、配置服务、部署到服务器，再配合我做完整链路测试。这次Vibe Coding直接搭出了一套真实直播基础设施。