(English Version: Top-right translate button OR scroll down.)
在QQ音乐车载应用项目中，音乐模块基于供应商SDK进行开发。由于涉及保密协议，项目组无法直接查看供应商SDK内部完整日志和源码，因此与SDK相关的问题通常需要通过车机日志、SDK日志上传单、公司外发流程、供应商分析反馈和内部问题表进行追踪。
项目测试过程中，测试团队在压测时发现一个低频偶现但影响较严重的问题：用户在播放过程中快速切换内容时，偶现卡顿甚至黑屏。由于播放功能是音乐应用的核心功能，如果该问题在量产版本中持续出现，可能影响用户核心体验，也会带来较高质量风险。
复现概率低：该问题属于低频偶现，测试压测中复现后，后续很难稳定复现，导致根因定位缺少连续、稳定的复现证据。
日志和源码受限：由于供应商SDK涉及保密协议，项目组无法直接查看供应商SDK内部完整日志和源码，只能依赖供应商反馈、日志上传单、会议共享和针对性代码说明。
责任边界不清：内部开发初步判断可能是SDK问题；供应商认为SDK内部日志正常，且同一SDK在其他主机厂未反馈类似问题；系统侧则认为该问题在多个平台均出现，而不同平台系统实现不同，因此更可能指向共用SDK链路。问题一度在供应商和系统模块之间反复流转。
供应商约束力有限：供应商与公司之间更多是合作关系，项目组对供应商的版本修复节奏和问题响应力度无法完全强制推动，只能通过问题证据、例会追踪和产品线升级进行推进。
跨团队接口复杂：问题涉及音乐本模块、系统模块、供应商SDK、测试团队和平台测试人员。系统模块没有统一项目经理接口，因此需要逐一确认相关开发人员并推动其参与排查。
项目经理技术边界明确：作为项目经理，我不能直接判断代码根因，也无法直接验证供应商完整日志结论，因此需要推动技术负责人基于日志、代码逻辑、复现条件和版本环境给出分析依据。
作为项目经理，我负责跟踪该严重质量问题的排查进展，拉通内部开发、系统模块、供应商、音乐测试和平台测试团队，推动问题复现、日志收集、责任方分析、风险升级和例行追踪。
我的重点不是直接判断代码根因，而是建立统一的问题追踪机制和证据收集机制，避免问题在供应商和系统模块之间被反复转交而无人持续负责。
建立问题追踪机制：在问题出现后，我要求内部开发将日志上传单号、复现平台、版本信息、问题现象、分析进展和责任方反馈记录到问题表中，由我持续跟踪每一轮分析结论和下一步动作。
拉通供应商和系统模块联合排查：当供应商和系统模块都认为问题不在自己侧时，我没有接受单纯基于“排除法”的口头判断，而是主动拉群并组织专项会议，让供应商、系统开发、内部开发和测试人员进入同一个沟通机制，避免问题在多个团队之间来回流转。
推动基于证据而非口头判断的分析：会议中，我要求供应商针对播放链路共享相关代码逻辑和日志判断依据，同时要求系统侧说明其内部代码逻辑和平台差异分析，推动双方基于日志、代码逻辑、复现条件和版本环境进行判断，而不是只用“其他客户没问题”或“多个平台都有问题”作为排除依据。
扩大复现证据收集范围：由于问题低频偶现，我将音乐内部测试人员和平台侧负责音乐测试的人员都拉入问题群，要求后续一旦复现，立即同步视频、车机日志、SDK日志、复现平台、版本信息和操作路径，避免信息分散在个人沟通中。
推动供应商提供兜底修复版本并持续验证：在多轮联合分析仍未定位根因的情况下，供应商基于可能风险点提供了一个兜底修复SDK版本。项目组更换新SDK后继续验证，但后续仍低频偶现类似问题，因此我继续组织系统侧和供应商复盘分析。