观众发个链接，AI 就把它做成直播内容

观众往直播间发一条项目链接，AI 主持人就去看这个项目，边讲边操作网页，最后还要给出评价。这样的节目，已经有人做了。

我这次整理的是 HeyGen 团队公开的一个工程案例。它在 Twitch 上做项目点评，观众可以把 GitHub 链接发进聊天里。GitHub 可以先理解成开发者放公开项目的地方。节目拿到一个链接，就有了接下来可以一起看的对象。

本文沿用这期视频的案例主线，依据作者文章和公开演示整理，没有亲自部署或运行这档节目。

点评得落在作品里的具体内容上

公开演示中，主持人正在看一个叫 Telegraf 的项目。页面上有一句介绍，大意是安装体验友好，而且明确。

主持人抓住这句话吐槽：文档应该把安装命令摆出来，光说自己好用，别人怎么开始？画面里，相关文字被选中，随后页面滚到了安装说明附近。

这有点像把自己的作品交给一个点评主播。它要围绕作品里具体的东西说话，观众也能看见，它这句话是从哪里来的。

这段演示拍的是点评中途。至于一条新链接怎样进入正在播的节目，还要看作者另外公开的接收和排队流程，不能只凭这段画面补出完整过程。

按作者介绍，观众提交链接后，聊天里可以先收到一条文字回复。后台把项目放进待处理队列，主持人再找机会开口接这条消息，转到新项目。

这几个时刻容易混在一起：

收到回复以后，节目还得安排什么时候讲你的项目。主持人可能正在说上一段，前面也可能已经准备了一些内容。

等轮到它，系统需要读到网页内容，组织讲解，同时安排页面动作。讲到文档里的某一句，就让观众找到那句话；讲到安装，就把安装区域展示出来。

这里有个很实际的问题：页面该什么时候动？

如果讲解还没到，页面已经翻过去，观众会找不到它说的是哪一处。反过来，话说完以后页面才动，大家又得等着找。

作者公开的做法，是利用说话流中的逐词时间戳，把动作绑到相应词句上。程序对照实际播放位置安排滚动、选中和点击，不只按预计语速设置一个倒计时。

这样，讲解与操作有了一份可以对照的时间依据。说到哪儿、指到哪儿，才有机会让观众顺着同一个对象看下去。

实际实现仍可能出现动作延迟或漏掉的情况。短演示能让人看见这种配合，但不能证明整场直播每个动作都准确。

假如主持人正在点评，你又发来一个项目，它为什么还要等？

因为节目为了持续说下去，会提前准备一小段内容。已经准备好的话还没全播完，新链接需要找到合适的位置接进去。

准备太少，下一段没赶上，主持人可能就没话了。准备得多一些，播起来更从容，新观众的请求却也会排得更靠后。

作者在工程文章里披露，他们刻意留了约 20—35 秒播放缓冲。另一个统计是，观众提交链接后，到节目口头确认，中位等待约两分钟。

两分钟到的是口头确认，不是点评完成，也不是生成一句话的耗时。

这段等待还受请求落在当前节目哪个位置、什么时候适合接话影响。只提高生成速度，并不能替节目决定这些事。

我觉得这个案例有意思的地方，就在于观众提交的东西变成了大家正在一起看的节目内容。一个会开口的数字人，也因此有了一件能持续做下去的事。

再看这样的 AI 直播时，可以留意三个时间：什么时候发出请求，什么时候听到确认，什么时候真正开始点评。把它们分开，就比较容易看清节目在哪个环节让人等，以及它怎样把新输入接进正在进行的内容里。