核心问题
AI大幅降低了RTC供应的难度，对该观点做客观性分析和提供正反面论据。
RTC服务的衡量维度不同，需要分层思考
| RTC供应层次 | AI降低难度的程度 | 判断 |
|---|---|---|
| 在App中接入实时音视频 | 高 | 明显降低 |
| 基于开源SFU做单区域或垂直RTC服务 | 中等 | 进入门槛下降 |
| 建设全球、高可用、高质量RTC PaaS | 较低 | 核心壁垒仍然存在 |
显著提升了执行和接入效率
- SDK接入与跨平台封装；
- Token、用户权限和房间逻辑；
- Web、iOS、Android和React Native客户端适配；
- 录制、推流、Webhook和业务后台；
- Terraform、Kubernetes、监控规则及运维脚本；
- 文档、示例代码和客户技术支持。
上述工作内容里，原来可能需要1-2周的工作，能够缩短到1-2天。
从不同工作模块看AI的提效
如果把RTC服务分成媒体面、控制面、运营面三个方向，各自的主要工作内容则是：
- 媒体面：音视频采集、编码、传输、转发、抗丢包；
- 控制面：鉴权、信令、房间管理、调度、计费、权限；
- 运营面：监控、告警、日志分析、故障排查、容量规划。
AI对控制面和运营面的提效是非常显著的，但对媒体面的提效还有些瓶颈，不过现在进步神速，未来很难说。
换一个角度看RTC门槛下降
RTC供应门槛下降，实际上来自四股力量共同作用：
| 因素 | 主要降低的门槛 |
|---|---|
| WebRTC标准化 | 浏览器、协议和客户端互通 |
| LiveKit、mediasoup等开源项目 | 媒体服务器和SDK开发 |
| 公有云、容器和基础设施即代码 | 服务器采购与部署 |
| 生成式AI | 编码、集成、测试、文档和故障分析 |
开源RTC和云基础设施解决了“有没有现成积木”的问题，AI解决了“如何更快把积木组起来”的问题。
AI难以处理的瓶颈
站在现在看AI较难处理的瓶颈有下列这些，但动态地看，可能相当一部分会被AI接手。
- 光纤和无线网络传播时延；
- 运营商互联质量差异；
- UDP被封锁；
- 突发丢包和带宽竞争；
这些问题需要实际网络节点、流量调度、冗余链路和长期运行数据，而不是只靠生成代码。
对于不同的场景需求，有不同方向的技术难度需要解决，比如在向多地区、多场景扩展时，需要解决的更深度问题有下面这些：
- 多节点部署需要Redis作为共享数据存储和消息总线；
- 多区域部署需要区域感知的信令负载均衡；
- 不同国家和运营商的网络表现数据；
- 大量设备及操作系统兼容记录；
- 真实故障案例；
而在弱网、高负载情景下，需要解决的问题又变成了：
- 很多Bug只在特定设备或弱网环境出现；
- 修改可能改善一个网络场景，却损害另一个场景；
- 需要长时间压测和真实流量验证；
- 路由策略效果反馈；
- 客户侧长期质量基线。
小结
AI确实对RTC行业产生巨大影响。首先是数据中心基础设施的大幅增加，在硬件层面使得不需要专门建设基建，蹭一蹭其他主流需求的基建边角料可能就够满足RTC需求。其次，开源RTC服务增加，原因跟AI显著降低了软件层开发成本有关，在软件层的组装成本也大幅降低。一个资深RTC技术专家的价值在这个时代会被AI显著放大。
在部分场景需要很深的RTC技术服务，比如跨地区、弱网、高并发条件下的RTC，涉及到长期的纠错积累、私有数据，这部分门槛依然较高，不是AI可以简单替代的工作。