从音视频技术到商业场景：第一家客户带来的产品认知变化

在实时音视频产品的孵化阶段，我们接到了第一家商业化客户。客户做视频会议，希望把会议中的多路画面合成为一路视频，再转推给直播观众。

当时产品还没有合流转推能力，我们先补上这项功能，再继续补充自定义布局、背景图片和单路画面裁剪等功能点。

这个项目最大的收获，是一次关于产品主线的认知变化。此前，研发更关注把音视频技术做好；真正面对外部客户之后，我们逐渐看到，客户要把音视频能力用进业务，还需要一系列配套能力。那些看起来细小的功能，可能直接关系到客户能否完成一次符合要求的会议直播。

客户让我们看到了更完整的使用过程

客户有自己的参会端和导播系统。会议参与者提供摄像头画面、共享屏幕等素材，导播人员选择素材、组合布局，在候场区准备，再把选定的画面切换给直播观众。

从这个流程看，完成画面合成和转推之后，客户还有很多具体要求：不同内容应该放在什么位置，直播过程中如何切换布局，共享屏幕是否完整，画面背景是否符合活动需要。

这些要求与客户的使用方式紧密相连。客户已经在组织会议、准备直播，音视频产品需要提供足够的控制能力，让这段业务流程能够运转。

客户侧负责导播界面和业务编排，平台侧负责按照配置处理和组合画面。理解整个流程，有助于看清平台应该提供哪些能力，以及怎样与客户已有系统配合。

客户当时已有多种布局样式，并预期随着业务发展继续增加；同一场直播中也需要切换布局。

相应的需求，是提供位置、宽高等控制项，让客户组合不同画面。对于客户，这关系到怎样组织内容、怎样呈现不同会议环节。对于平台，需求需要进一步明确为可以配置和更新的画面布局。

这也是客户场景对能力定义的补充：只知道要把多路视频合为一路，还不足以说明最终画面应该怎样呈现。

共享屏幕与摄像头出现在同一张画布里，对画面适配的要求却不同。共享屏幕需要完整显示，文字和图表不能因为裁剪而丢失，也不应变形；摄像头画面则不希望出现背景填充，可以接受一定的裁剪或拉伸。因此需要进一步支持对单路视频分别设置适配方式。

从接口上看，这是配置作用范围的变化。从业务上看，它决定了同一场直播中，不同类型的内容能否按照各自的要求被展示。这类细节会在客户真正组合多种素材时显现出来。

原有合流布局只支持背景颜色，客户场景还需要背景图片。围绕图片，又带出了位置、尺寸和更新方式等问题。

例如，背景图是否一定铺满画布？原图与输出区域尺寸不一致时，开发者是否必须反复修改素材？如果允许配置图片尺寸，又会增加多少使用复杂度？

背景图片看起来只是一个画面元素，但对客户来说，它是最终输出效果的一部分。讨论它是否需要支持、支持到什么程度，也需要结合真实的呈现要求。

研发最初更倾向于把音视频技术本身视为产品主线，布局和背景等配套细节容易被看作主线之外的事情。这种关注点来自产品早期的技术建设，但外部客户带来了此前没有充分接触的使用要求。

这次项目让团队看到，商业化产品的能力范围还要考虑客户怎样使用核心技术。布局、背景和裁剪并不直接提升音视频传输本身的技术指标，却能影响客户是否可以把技术能力接进自己的业务。

对这类合理诉求，产品需要给出回应。判断其必要性时，可以回到具体场景：客户缺少它会遇到什么问题，现有配置为什么不够，应该提供怎样的控制能力。

这些判断也帮助保持产品边界清晰。客户负责自己的业务界面和操作流程，平台提供支撑流程的能力；一个客户带来的具体需求，可以成为我们理解能力缺口的入口。

随后，我们的视频会议产品与另一套实时音视频产品需要推进团队和产品合并。原产品已经服务商业客户，而另一套产品当时的能力还比较基础。为了让它能够承接已有客户的使用需求，我提出了屏幕共享和房间管理两组能力补齐需求。

屏幕共享已经是客户会议业务中的重要能力。当时的核查发现，另一套产品在部分平台上还缺少屏幕采集能力，窗口选择、缩略图和共享状态标识等配套能力也有缺口。合并过程中，需要把这些已有的业务依赖放进能力补齐的范围，否则客户原有的使用过程就缺少必要支撑。

房间管理则体现了参会端之外的使用场景。客户还需要在业务管理后台查看房间列表、房间状态和参会者信息，因此希望通过服务端开放接口（OpenAPI）查询这些数据，无需为管理后台集成音视频 SDK。这些接口不直接参与媒体传输，却是客户管理会议业务时需要的能力。

这次协作的研发负责人此前没有接触过外部客户，对房间管理接口是否属于真实客户诉求提出了疑问。我明确说明客户确实这样使用之后，他也认可可以做。这让我再次体会到，把客户的使用场景带进讨论很重要：同样一组接口，放回客户的业务后台中，必要性就更容易被理解。

屏幕共享的评审也涉及平台与应用的分工。例如，共享边框是否属于 RTC 应该提供的能力，窗口列表的过滤是否可以由应用层完成。

这两组需求在功能上都属于基础补齐，但与前面的合流转推项目有相同的经验主线：客户把音视频能力用进业务，需要的支撑会延伸到画面呈现、共享操作和后台查询。产品合并时，也需要把这些已经显现出来的使用要求一并纳入讨论。

对我来说，这次项目值得沉淀的，是理解商业化产品时，要把核心技术与客户的完整使用过程一起考虑。

在收集需求和编写 PRD 时，把客户场景说明白非常重要。布局要求来自怎样的导播过程，单路裁剪解决哪类内容问题，背景图片服务于怎样的输出效果——这些信息让研发能够理解功能背后的使用要求，也让后续关于坐标、尺寸等能力细节的讨论有依据。

产品与研发在这个过程中各自补充了信息。我带来客户的需求和场景，研发提醒需要进一步明确的能力细节；外部客户则让整个团队接触到了原先考虑得不够充分的业务使用方式。

这段后续经历也让我更注意区分两个问题：客户是否确实需要某项能力，以及平台应该怎样提供它。前者需要具体场景作为依据，后者需要产品与研发共同讨论实现分工、范围和约束。把这两个问题说明白，才能既回应客户的合理诉求，也保持产品边界清晰。

今后再判断某个配套功能是否属于产品主线，我会把它放回客户实际使用核心能力的过程里看：如果它解决的是合理、具体的使用问题，就应该进入产品能力的讨论。这个视角，是第一家商业化客户给我们带来的重要收获。