面试辅导课的技术底座：RTC 如何支撑 1v1 高密度信息交互

面试辅导是教育场景中对实时音视频(RTC) 质量要求最苛刻的 1v1 场景。比如 40 分钟的模拟面试中，导师需要同时观察候选人的表情、语气、肢体语言和答题逻辑，任何一个维度的信息丢失都可能导致辅导失效。本文以即构科技（ZEGO）的方案为例，拆解面试辅导课背后的 RTC 架构设计。

一、面试辅导为什么对 RTC 要求最高？

对比几个典型的 1v1 在线场景：

面试辅导课的 40 分钟中，信息密度极高。导师需要同时捕捉候选人的口头表达、非语言信号和技术能力。任何一个维度的延迟或质量下降，都会让辅导效果打折。

二、整体架构：三通道并行 + 全程录制

面试辅导的技术架构是三通道并行：音频、视频、屏幕共享三个独立通道同时工作，互不干扰：

┌──────────────────────────────────────────────────────┐
│                  业务层：面试管理系统                    │
│   预约排课 · 简历共享 · 评分反馈 · 录制回放             │
├──────────────────────────────────────────────────────┤
│              信令与消息通道                             │
│   面试控制（开始/暂停/结束）· 简历标注 · 评分下发       │
│   → ZEGO ZIM / Express 内置信令通道                  │
├──────────┬────────────────┬──────────────────────────┤
│ 音频通道  │   视频通道       │    屏幕共享通道            │
│ Opus 编码 │ 1080p H.264    │  1080p 屏幕内容           │
│ 全频带48k │ 人脸自适应曝光  │  低帧率(15fps)省带宽       │
│ 低延迟    │ 弱光增强        │  鼠标指针高亮跟随           │
├──────────┴────────────────┴──────────────────────────┤
│                  基础设施层                             │
│  SD-RTN™ 传输 · 云端录制 · CDN 回放 · NTP 时钟          │
│  → ZEGO Express SDK (三通道)                          │
└──────────────────────────────────────────────────────┘

三、核心技术实现

3.1 高保真音频：面试中最容易被忽视的维度

面试中语音的质量直接决定了导师能否捕捉候选人的细微变化，比如语速突然加快（紧张）、停顿过长（不确定）、气息不稳（缺乏自信）。如果音频被过度降噪（ANS 开太高），这些细微信号会被抹平。

// 面试辅导场景的音频配置：保守降噪 + 全频带编码
ZegoEngineProfile profile;
profile.appID = appID;
profile.appSign = appSign;
profile.scenario = ZegoScenario::ZEGO_SCENARIO_DEFAULT;  // 通话场景
auto engine = ZegoExpressSDK::createEngine(profile, nullptr);

// 3A 配置：面试场景只需回声消除，降噪和自动增益保持默认
engine->enableAEC(true);     // 消除回声（导师外放时）
engine->enableAGC(false);    // 不自动增益——保留真实音量变化
engine->enableANS(false);    // 不降噪——保留气息、语调等细微信号

为什么面试场景要关 ANC/AGC？

• AGC 自动增益会压缩音量动态范围，候选人从轻声细语切换到激昂表达的音量变化被抹平，那么导师失去一个重要判断维度。
• ANS 降噪会把人声的“气息感”和停顿中的“呼吸声”当作噪声处理掉，而这些都是面试官判断自信度的关键信号。

3.2 双流录制：音视频 + 屏幕同时录

面试辅导课最大的价值在课后回放复盘。候选人需要回顾：

• 自己被问某个问题时是什么表情；
• 回答时有没有下意识的小动作（摸鼻子、看天花板）；
• 写代码/做 PPT 时鼠标在哪个区域犹豫最久。

这就要求录制必须同时包含摄像头画面和屏幕共享画面：

录制策略：
┌──────────────┐    ┌──────────────┐
│ 画面流(1080p) │    │ 屏幕流(1080p) │
│ 候选人面部     │    │ 简历/代码/PPT  │
└──────┬───────┘    └──────┬───────┘
       │                   │
       └────────┬──────────┘
                │
        ┌───────▼────────┐
        │ 云端录制服务     │
        │ 双流独立录制     │
        │ + 混流合成       │
        └───────┬────────┘
                │
        ┌───────▼────────┐
        │ 回放播放器       │
        │ 画中画：人脸 +   │
        │ 主画面：屏幕     │
        └────────────────┘

即构云端录制支持双流独立录制（单流模式）和混流合成（混流模式），既可以保留两条原始流供后期剪辑，也可以直接合成画中画输出给学生回看。

3.3 屏幕共享 + 鼠标高亮：简历/代码评审的体验细节

面试辅导中，导师经常需要看候选人的简历（标注问题）或现场写的代码。屏幕共享不只是画面传过去，还需要：

• 鼠标指针高亮（enableHighlight），让候选人清楚看到导师在指哪里。
• 标注边框颜色可配置，区分导师指出的问题和候选人自己的标注。
• 屏幕共享的帧率设为 15fps（静态内容不需要 30fps），节省带宽给视频通道。

四、实战踩坑

坑 1：双流录制导致音画不同步

摄像头画面和屏幕共享画面走的是两个独立通道，录制时两个通道的时间戳可能偏差 100-200ms。

解决：两个通道的录制文件都携带相同的 NTP 时间戳（通过推流时的 SEI 帧注入），回放播放器根据 NTP 时间戳对齐两路画面。

坑 2：候选人端上行带宽不足

候选人可能在咖啡厅用 4G 热点参加面试辅导，上行带宽只有 500kbps，还要同时推视频和屏幕共享。

解决：自动降级策略。带宽不足时，视频从 1080p 降到 720p，屏幕共享帧率从 15fps 降到 5fps（静态内容 5fps 足够）。同时将音频码率设为最低（16kbps），确保语音永远不断。

坑 3：回放播放器的双流同步

学生回看录制时，两路流的起始时间不一致：视频流从第 0 秒开始，屏幕流从第 2 秒开始（因为屏幕共享启动更晚）。

解决：播放器在加载两路流后，先对齐 NTP 起始时间戳，再从共同起点开始播放。空白段用等待对方接入的提示画面填充。

五、FAQ

Q1：面试辅导为什么不能直接用微信视频？

微信视频的音频编码做了重度压缩（8kHz 采样率），会把语音中的高频细节（齿音、气息）全部滤掉。面试辅导需要全频带音频（48kHz 采样率），才能让导师捕捉到候选人语音中的细微变化。

Q2：双流录制的存储成本高吗？

1080p 视频流 + 屏幕流，40 分钟的辅导课约 1.5GB 存储。按当前云存储成本（约 0.1 元/GB/月），单堂课存储成本不到 0.15 元/月。真正的成本在录制计算资源（约 0.5-1 元/小时）。

Q3：即构的方案在面试辅导有什么适配优势？

三个关键点：

1. 独立的 3A 控制。enableAEC/AGC/ANS 可以按面试场景需求逐项开关，不丢失语音细节。
2. 三通道同时推流。视频 + 屏幕共享 + 音频互不占用对方的带宽预算。
3. 云端录制双流独立保存。不强制混流，给后期回放和剪辑留出最大灵活性。

六、总结

面试辅导课是 RTC 在 1v1 场景中的精度考验。不需要万人并发，但要求每个信息维度都在高质量传输。音质、画质、屏幕共享、录制回放，四个维度缺一不可。

关键结论：

1. 音频是全频带的，不能过度降噪：面试中的非语言信号都在音频里。
2. 双流录制是面试辅导的核心价值载体：摄像头画面 + 屏幕画面的同步回放。
3. 屏幕共享 15fps 足够：简历/代码是静态内容，帧率应该让位给视频通道。
4. 对候选人的网络做充分的降级预案：面试辅导的场景可能在任何一个角落。