AI 时代高级程序员的门槛在哪里？以 WebRTC 为例

一、AI 能写 demo，但 demo 不是产品

如今让 AI 写一个 WebRTC demo，实在不难。

一句 prompt 下去，getUserMedia、RTCPeerConnection、offer/answer、ICE candidate，代码一会儿就出来了。再让它解释 SDP、STUN、TURN、DTLS、SRTP，它也能讲得头头是道，语气还很稳定，像一个从不加班、从不掉头发的资深同事。

可是 RTC 应用一进生产环境，味道就变了。

用户说“声音断断续续”，你看到的是 packet loss、jitter、concealment、AEC、AGC、audio level、device switch、CPU spike 一起跳舞；用户说“视频卡”，你要判断是编码器掉帧、解码器吃不消、带宽估计太保守、关键帧没来、jitter buffer 撑爆，还是 Wi-Fi 正在表演行为艺术。

这时候再问 AI：“为什么我的 WebRTC 卡？”它当然会给你一份清单。问题是，清单不等于判断。

我越来越觉得，AI 时代高级程序员的门槛，不是“知道更多名词”。名词已经不稀缺了。真正的门槛在这里：

能把一个混乱的线上现象，还原成背后的系统模型；能在不完整信息里做取舍；能为系统的后果负责。

WebRTC 是一个很好的例子。它像一台小型联合收割机：音频、视频、网络、设备、操作系统、浏览器、编码器、安全协议、QoS 策略全挤在一起。你只懂 API，顶多算会点火；真要下地收麦子，还得知道刀片为什么会卡、皮带为什么会滑、发动机为什么会冒烟。

二、懂得多不是门槛，理解得深才是

以前，“我知道这个协议”“我用过这个库”“我熟悉这个参数”，确实能形成一点门槛。资料少，源码难读，经验靠项目一点点攒。

现在不一样了。AI 把很多知识的检索成本打下来了，门口的台阶一下子矮了不少。

你想知道 SDP 里 a=rtcp-fb 是干嘛的，AI 能解释；你想知道 Opus 和 H.264 的基本差异，AI 能整理；你想知道 NACK、FEC、RTX、TWCC 的大概作用，AI 也能列出表格。

这些当然有用。但它们更像地图上的地名。真开车时，难的不是背出城市名，而是知道这条路什么时候会堵、下雨天哪里容易打滑、前面那个弯为什么年年有人撞护栏。

RTC 的难点尤其在这里：它不是一个单点技术，而是一串连续的因果链。

一个音视频包大概要走这样的路：

采集设备 -> 音视频处理 -> 编码 -> RTP 打包 -> 网络传输 -> 抖动缓冲 -> 解码 -> 渲染播放

每一段都可能出问题，每一段又会把问题传给下一段。

网络抖了，jitter buffer 变大，端到端延迟上升；延迟上升，交互感变差；带宽估计降得太猛，视频码率被砍，画面糊成马赛克；音频丢包恢复策略选错，声音可能不是断，而是“机器人化”；CPU 打满，编码器降帧，最后用户只会说一句：“你们这个会议不稳定。”

用户不会关心你到底是 RTP timestamp 漂了，还是 encoder queue 堵了。他只关心一句话：能不能好好说话。

高级程序员的门槛，就在于你能不能从“不能好好说话”，一路追到那条真实的因果链。

三、音频：最容易被低估，也最容易伤人

做 RTC 的人很快会发现一个现象：视频差一点，用户还能忍；音频一差，会议立刻崩。

画面糊一点，大家会说“网络不好”。声音一断、一啸叫、一回声，大家马上皱眉。因为实时沟通的主通道是声音，视频更多是增强体验。你可以接受对方脸上有几个像素块，但很难接受每句话少两个字。

音频这块，光会调 API 不够。你至少得懂一点信号处理，哪怕不是专家，也要知道几个基本概念：采样率、声道、回声、噪声、增益、动态范围、频谱、延迟、抖动。

比如 AEC，也就是 Acoustic Echo Cancellation，声学回声消除。它不是一个“开关”。你打开了，不代表回声就消失了。它要面对扬声器、麦克风、房间混响、设备延迟、系统音量、双讲场景。远端在说话，本地也在说话，算法要判断什么是回声，什么是近端人声。判断错了，声音就会吞字、抽搐、变形。

再比如 AGC，自动增益控制。听起来像好东西：声音小就放大，声音大就压低。可是放得太猛，底噪也跟着上来；压得太狠，人声就像被人掐住脖子。NS，噪声抑制，也一样。抑制少了，键盘声、风扇声都进来；抑制多了，人声边缘被啃掉，听起来像隔着一层塑料袋。

这些问题，AI 可以解释概念，却很难替你“听出来”。

一个有经验的 RTC 工程师，听到“声音发闷”“有金属感”“双讲时吞字”“切换耳机后回声变大”，脑子里会自动浮现几条假设链：是不是采样率转换有问题？是不是 AEC delay estimate 不准？是不是设备枚举和路由切换没处理好？是不是 jitter buffer 拉得太长？是不是 packet loss concealment 在硬撑？

这不是背答案，这是长期被真实问题修理出来的条件反射。咱们这行，有些反射弧确实是被线上事故敲出来的。

四、视频：别只盯分辨率，先看时间和码率

视频问题看起来更直观：卡、糊、花、黑、不同步。

但视频工程的坑也不少。初学者容易盯着分辨率：720p、1080p、4K，好像越高越高级。真做 RTC 就知道，分辨率只是菜单上最显眼的菜名，背后还要看码率、帧率、编码复杂度、关键帧、硬件加速、渲染队列、端到端延迟。

同样是 720p，500kbps 和 2Mbps 完全是两种世界。同样是 30fps，如果编码器每隔几秒卡一下，用户看到的不是“平均 30fps”，而是“刚才又顿了一下”。平均值在报表里很好看，在用户眼里常常不算数。

视频编码也不是“调用 H.264/VP8/VP9/AV1 就完事”。你得知道一些基本取舍：

• 码率不够时，是降分辨率、降帧率，还是提高压缩强度？
• 丢包之后，是等关键帧，还是通过 NACK/RTX 尝试恢复？
• 多人会议里，是用 simulcast、SVC，还是服务端做转码？
• 屏幕共享和摄像头视频的优化目标一样吗？
• CPU 已经很高时，继续追清晰度是不是在给系统添乱？

这些问题没有一个答案能通吃。

摄像头视频可以适当牺牲细节，保流畅；屏幕共享里一行小字糊掉，用户可能就看不清代码；弱网下频繁请求关键帧，可能帮助恢复，也可能把网络进一步打爆。工程判断的难处就在这里：每个按钮都连着代价。

AI 可以帮你列出“优化视频质量的十种方法”。但什么时候该用哪一种，什么时候坚决不用，得靠你理解原理，也靠你见过它们在生产环境里如何翻车。

五、网络与 QoS：RTC 最像江湖的地方

如果说音频像医学，视频像摄影加压缩，那么 RTC 网络层就有点像江湖。

你以为你在发 UDP 包，其实你在和 NAT、防火墙、Wi-Fi、蜂窝网络、路由拥塞、企业代理、操作系统调度、浏览器策略一起谈判。对方还不一定讲理。

WebRTC 的网络栈里有很多熟悉的词：ICE、STUN、TURN、DTLS、SRTP、RTP、RTCP、NACK、PLI、FIR、FEC、RTX、TWCC、GCC。AI 能解释它们的定义，但生产环境里真正要命的是组合效果。

比如丢包恢复。FEC 是提前发冗余，RTX 是丢了以后重传。听起来都不错，可代价不同。

音频对延迟敏感，带宽占用相对小，适当冗余常常更划算；视频数据大，重传有时更合适，但如果 RTT 太高，包重传回来也错过播放时间，只能成为一位迟到的救火队员：火已经烧完了，他还在路上鸣笛。

再比如带宽估计。估得太乐观，网络被打满，排队延迟上升，大家一起卡；估得太保守，画质上不去，用户觉得你“明明网络很好也不清楚”。拥塞控制不是追求最大码率，而是在延迟、丢包、吞吐、稳定性之间找一条能活的路。

还有 TURN。很多 demo 在办公室里跑得好好的，一到企业网络、酒店 Wi-Fi、移动网络，ICE 连接就失败。最后发现不是媒体代码写错，而是 NAT 类型、UDP 阻断、TURN 配置、证书、端口范围、区域调度、权限校验里某个环节掉链子。

这就是 RTC 的残酷之处：你写的是应用，出问题的可能是整个互联网。

高级程序员不能只会说“网络不好”。“网络不好”不是结论，只是事故现场门口贴的一张纸。你得继续往下问：

• 是 RTT 高，还是 jitter 大？
• 是随机丢包，还是 burst loss？
• 是上行差，还是下行差？
• 是 Wi-Fi 漫游，还是蜂窝切换？
• 是带宽不足，还是队列膨胀导致延迟上升？
• 是客户端编码慢，还是服务端转发慢？

问得越具体，才越接近真相。

六、AI 在 RTC 开发里到底能帮什么

说到这里，好像 AI 很没用。不是。

AI 在 RTC 开发里很有用，只是它更像副驾驶，不是老司机。

它可以帮你：

• 快速生成 demo、测试脚本、日志解析脚本、统计图表。
• 解释标准文档、源码片段、SDP 字段、RTCP feedback。
• 根据日志和 stats 给出候选假设。
• 帮你整理 weak network 测试矩阵。
• 把一次排障过程写成复盘文档。

但方向盘不能交给它。原因很简单：RTC 的关键判断，往往不在文字里，而在现场。

现场是什么？是用户说“有时会断”，但他说不清“有时”到底是什么时候；是日志里少了关键字段；是 iOS 和 Android 表现不一致；是某个蓝牙耳机只有在电量低时才出妖怪；是测试环境复现不了，生产环境偶发；是两个优化单独看都对，叠在一起就错。

AI 擅长从已有信息里归纳，工程师要擅长发现“缺了什么信息”。这句话很重要。

用 AI 排查 RTC 问题，我更建议这样问，而不是问“帮我修一下”：

请先不要给最终结论。

这是一次 WebRTC 质量问题的现象、stats 和日志片段。
请按以下格式分析：

1. 可能的故障域：音频 / 视频 / 网络 / 设备 / 编码器 / 服务端 / 客户端
2. 每个假设需要哪些证据支持
3. 当前信息里缺哪些关键字段
4. 下一步最小复现实验是什么
5. 哪些修复方案风险最大，不建议直接上线

如果证据不足，请明确说“不能判断”，不要编结论。

这类 prompt 的价值，不是让 AI 替你拍板，而是逼它帮你整理战场。最后开不开枪，还是人来决定。

七、高级程序员的门槛，其实是四件事

以 WebRTC 为例，我认为 AI 时代高级程序员的门槛，主要在四件事。

1. 第一性原理：能穿透 API 看到模型

API 会变，框架会变，浏览器实现会变。但声音是波，视频是采样和压缩，网络有延迟、丢包和拥塞，CPU 和内存永远有限。

你不懂一点信号处理，就很难真正理解为什么音频会变形；你不懂一点音视频编码，就很难理解为什么“清晰”和“流畅”经常打架；你不懂一点网络拥塞控制，就很难理解为什么“加大码率”有时是在自杀。

第一性原理不是为了显得高深，是为了在工具失灵时还能走路。

2. 系统思维：知道问题会跨层传播

RTC 里很少有纯粹的单点问题。

设备切换可能影响音频路由，音频路由影响 AEC，AEC 影响听感；网络抖动影响 jitter buffer，jitter buffer 影响延迟，延迟影响双向对话；编码器降码率影响画质，画质下降又影响用户对网络的判断。

高级程序员要能画出这些链路。画不出来，就容易头痛医头、脚痛医脚。最后代码改了一堆，问题只是换了个地方继续活着。

3. 工程取舍：知道没有免费午餐

FEC 有冗余成本，RTX 有 RTT 成本，提高码率有拥塞成本，降低延迟有丢帧成本，打开更多日志有性能和隐私成本，增加自适应策略有复杂度成本。

很多工程决策不是“对错题”，是“账本题”。高级程序员的价值，就是把账算清楚，把风险说清楚，把边界守清楚。

4. 事故记忆：从坑里长出来的直觉

有些能力只能靠真实问题训练。

我印象很深的一次，是做弱网测试时碰到一个很别扭的现象：上行丢包打到 5% 到 20%，音视频还能靠 FEC/RTX 勉强扛住；可一旦把丢包打在下行，重连服务器就开始时好时坏，不是必现，但足够烦人。最开始看上去像“网络差导致偶发失败”，这种话最没营养，因为它什么都没解释。

后来抓 Wireshark 才看清楚，问题并不在媒体流，而是在 DTLS 握手的最后几步。客户端没收到服务端最后一个 flight 里的关键消息，就会按协议重发上一条握手消息，期待对方回应。可 OpenSSL 1.1 在服务端那边一旦自认为“握手结束”，上层如果没有额外处理，就不再继续搭理这些迟到的握手重传。于是 client 还在敲门，server 已经下班，连接就僵在那里。

知道病根以后，修法反而不花哨：在 OpenSSL 上层缓存服务端最后发出的握手消息，如果握手结束后还收到客户端的相关重传，就把那条缓存的最后消息再补发一次。这个补丁不大，却让我长了个很硬的记性：以后再看弱网问题，我不会只盯码率、丢包恢复和媒体质量，也会先问一句，控制面的状态机在丢包时是不是也还站得住。

经验不是“我做过很多年”。经验是“我知道哪些地方看起来没事，其实最容易出事”。

八、一份 RTC 工程能力自检清单

如果你想判断自己是否真的能驾驭 RTC 应用，不妨拿这份清单照一照。不是考试，也不是鄙视链，只是一个诚实的体检表。

原理层

• 我能解释采样率、帧率、码率、延迟、jitter、packet loss 之间的关系。
• 我能说清楚 AEC、NS、AGC、VAD 大概解决什么问题，以及可能带来什么副作用。
• 我能解释关键帧、GOP、QP、码率控制、硬件编码对实时视频的影响。
• 我知道 RTP/RTCP、NACK、FEC、RTX、TWCC/GCC 的基本作用和主要代价。

诊断层

• 用户说“卡”，我不会马上改码率，而是先区分音频、视频、网络、设备、CPU、服务端。
• 我会看 WebRTC stats，而不是只看应用日志。
• 我会把 RTT、jitter、loss、available bitrate、frames dropped、freeze time、audio concealment、CPU、encoder/decoder delay 放在一起看。
• 我知道平均值会骗人，会关注 P95/P99、突发丢包、连续卡顿和用户感知指标。

实验层

• 我能设计弱网测试：带宽限制、随机丢包、突发丢包、延迟、抖动、上下行不对称。
• 我会做 A/B 对比，而不是凭感觉改参数。
• 我能在可控环境复现一部分问题，也知道哪些问题必须靠线上观测补证据。
• 我知道测试设备、耳机、浏览器版本、操作系统版本都会影响结论。

取舍层

• 我知道什么时候应该牺牲画质保音频，什么时候应该牺牲帧率保清晰度。
• 我知道什么时候该用 TURN 兜底，什么时候要优化直连成功率。
• 我知道哪些日志该打，哪些用户隐私和敏感信息绝不能打。
• 我知道一个策略上线前，要准备灰度、回滚、监控和复盘入口。

如果这份清单里一半都说不清，别急着自称“精通 WebRTC”。这不是丢人，RTC 本来就难。怕的是不知道自己不知道，还拿 AI 生成的答案当护身符。

九、最后：门槛从“会写”迁移到了“会判断”

AI 让很多事情变快了。写代码快，查资料快，生成文档快，整理方案快。

但在 WebRTC 这样的复杂系统里，快不是全部。真正稀缺的是慢功夫：理解信号、理解编码、理解网络、理解用户体验，理解那些参数背后真实的物理世界。

高级程序员的门槛，已经从“我能不能写出来”，迁移到了“我知不知道它为什么这样工作，坏了会怎么坏，改了会牵动哪里”。

懂得多不是门槛。AI 比我们记得多，也比我们查得快。

真正的门槛，是深刻领悟。是你知道一个音频问题背后可能藏着设备、回声、采样、延迟和网络；是你知道一个视频卡顿背后可能不是视频问题；是你知道 QoS 不是把所有策略都打开，而是在具体场景里做取舍；是你踩过坑，交过学费，还愿意把教训写进下一版系统。

AI 可以帮我们把车开得更轻松，但它不能替我们理解路况。尤其是 RTC 这条路，坑多、弯急，天气还经常变。

老司机的价值，不在于背得出交通规则，而在于看到前面一片反光，就知道该松油门了。

明天可以做的三件小事

1. 把你负责的 RTC 应用 stats 字段列一遍，标出哪些能解释用户感知，哪些只是看起来热闹。
2. 做一组最小弱网实验：限制上行、限制下行、加 RTT、加 jitter、加 burst loss，记录音频和视频分别怎么坏。
3. 挑一个线上质量问题，写一页复盘：现象、证据、假设、排除过程、最终原因、下次要补的观测点。

扩展阅读

• 我的 WebRTC 学习笔记 - 持续整理中的 WebRTC 学习与实践笔记，适合把协议、实现和排障经验串起来看
• DTLS 握手为什么常失败 - 一次弱网测试里的真实排障记录，重点不在背协议，而在看清控制面状态机在丢包下怎么失稳
• WebRTC Overview: Real-Time Communication Between Browsers
• WebRTC Audio Codec and Processing Requirements
• WebRTC Video Processing and Codec Requirements
• WebRTC: Media Transport and Use of RTP
• Opus Interactive Audio Codec

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。