✅ test(voice): 固化百炼 SparkBot 实板测试模板 - #349
Conversation
![fennoai[bot]](https://avatars.githubusercontent.com/in/1924301?s=60&v=4){kind=small}
There was a problem hiding this comment.
Reviewed the new Bailian wrapper, wake-injection harness, and the documented evidence gates. The key parsing and wrapper syntax are sound, but the wake workflow has two correctness gaps that can either report a false pass or make the documented rerun/reconnect flow fail.
Validation performed: bash -n scripts/run_bailian_sparkbot_test.sh, Python AST parsing, invalid-key exit contract, and git diff --check.
Additional findings
scripts/voice_linx_wake_injection_test.py:?: [P1] Do not wait for a one-shot boot marker on every wake run:SERIAL_VOICE_TEST_READY=1is emitted once when the firmware serial task starts, before this process opens the port; it is not re-emitted on each connection or while the board is already running. With the defaultwakecommand (which does not pass--reset-before-run), a second invocation or a reconnect therefore waits for a marker that has already been consumed and times out before injecting any audio. The documented rerun/reconnect workflow needs a readiness check that works after attach, or the wrapper must make/reset-and-wait an explicit prerequisite rather than relying on this one-shot log line.
| cursor = wait_for(log, "SERIAL_VOICE_EVIDENCE event=tts_started ", cursor, args.timeout) | ||
| cursor = wait_for(log, "SERIAL_VOICE_EVIDENCE event=capture_started ", cursor, args.timeout) |
There was a problem hiding this comment.
[P1] Require first TTS audio before declaring wake success
This success gate skips tts_first_audio even though the template requires it. The runtime intentionally opens capture after ACK_FIRST_AUDIO_TIMEOUT when the acknowledgment has started but no first PCM arrived, and that path still emits capture_started; therefore a provider/audio-output failure can satisfy the two waits below and print wake_injection_success. Wait for SERIAL_VOICE_EVIDENCE event=tts_first_audio (and reject provider/abort errors) before accepting capture_started so this harness cannot report a false wake pass.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
百炼注入与唤醒重跑验证（2026-08-22）本阶段提交： 注入方式核验
SparkBot 实板结果命令：
结论与边界百炼注入格式和注入路径已证明不会制造 Linx 非法音频帧；本阶段此前多轮测试中的 Linx RST 仍需按 WebSocket 生命周期/TX 时序单独处理，不能把本次唤醒通过扩大为多轮链路通过。 |
阶段进度更新（2026-08-22，先暂停 CI，继续实板链路）本阶段已提交并推送： 已完成
当前实板普通对话结果测试日志：
下一步对照实验将使用官方
原始串口日志只保存在本机 |
官方 SparkBot 对照实验阶段进度（2026-08-22）本阶段目标是用 已完成
当前阻塞与证据官方固件启动后明确打印 因此目前还不能把“官方固件未连接 Linx”误判为服务端问题。下一步需要在官方配网页面录入同一 Wi-Fi 和 Linx 凭据，然后用相同百炼 preflight/wake/multiturn 模板完成正式对照。 风险控制
Refs #348 |
实板对照测试进度（2026-08-22）对照基线
与 VoiceLife 症状的对照VoiceLife 之前表现为首轮可以唤醒并开始回复，后续 TTS 阶段出现 真人测试用例（严格顺序）
判定标准检查唤醒事件、WebSocket 建连、ASR/TTS 明文、打断后状态回收；全程不应出现 本阶段只做官方固件对照测试，没有新增 VoiceLife 源码，因此没有额外 commit；测试完成后会在此评论补充逐步结果。 |
真人实板对照结果（2026-08-22）已通过
未完成项
日程边界官方 串口完整记录： |
1 participant
结论：本 PR 将百炼 Key 读取、真实 TTS 预检、SparkBot 唤醒注入和多轮串口证据固定为一个可重复入口，后续测试统一从该入口开始。
请审核测试模板的配置读取和失败门禁；合并后使用
scripts/run_bailian_sparkbot_test.sh preflight、wake、multiturn，不要直接把 key.txt 整段赋给 DASHSCOPE_API_KEY。Fixes #348
Lifecycle: Ready for review; merge after required checks and human approval.
Scope
scripts/run_bailian_sparkbot_test.sh，固定qwen-audio-3.0-tts-flash + longanlingxi、SparkBot 串口和日志目录。sk-...行，支持行首尾空白和 CR；JSON、串口日志和元数据不写入密钥。standby_ready、唤醒、TTS 和采集 marker。Non-goals
Verification
bash -n scripts/run_bailian_sparkbot_test.sh。qwen-audio-3.0-tts-flash、音色longanlingxi、音频 58187 bytes、failed=0。standby_ready -> wake_detected -> local_wake_ack_requested -> tts_started -> tts_first_audio -> capture_started；屏幕同步经过“收到/说话中/准备中/聆听中”。Connection reset by peer，结果被正确判定为失败。sk-、Authorization或Bearer。Risks and closeout
/tmp/voicelife-bailian-tests下的 JSON、.meta.txt和串口.log，公开评论只粘贴脱敏汇总。AI assistance