移动端 AI 排障先建可回放测试环境

锁屏后转录停住、队列迟迟不清空，新人却只能先翻模型接入代码，因为能用的推理端点依赖资深同事的电脑。dev.to 的这篇文章提出：先把运行配置、故障环境和请求回放材料留在仓库，再深入模型代码。这是一套排障方案，作者明确表示尚无具体设备的实测数据。

目前能确认什么

作者要求先提交三份材料：端点切换配置、环境记录卡和回放脚本。

端点配置提供 on_device、staging、prod 三个目标，默认走 on_device，目标是让没有密钥的新电脑也能构建运行。但配置开关本身不会提供端侧推理能力，应用仍需实现对应路径。

环境卡记录设备、OS、框架版本、网络、权限、电量和故障时的应用状态。节选中的 JSON 是占位示例，不是真实采集记录。锁屏涉及应用进入后台；移动系统可能限制后台执行，不能只检查网络。

回放脚本在应用之外发送音频请求，保存响应、HTTP 状态、首字节时间和总耗时。作者还提出在首小时内演练切回 on_device，检查离线反馈，以及进行中的请求能否正常结束或明确失败。

我的判断

这套方案最有价值的地方，是让第二个人拿到足够的复现材料。

对接手移动 AI 项目的程序员，先确认请求发往哪里、故障发生在什么状态，比直接钻进模型集成层更容易缩小范围，也能减少对同事本机环境的依赖。

但回放成功，不能直接证明故障就在客户端。脚本是否使用相同音频、认证条件和网络路径，都会影响判断；它也无法复现手机锁屏后的完整生命周期。

另外，示例中的端点目标是构建时配置，切换后需要重新构建。节选没有交代如何复现切换时的在途请求，也没有展示完整的权限撤销验证步骤。「首小时」应当看作流程目标，不能当作已经验证的排障耗时。