结论：四个开发脚本的权限差异很大，不应统称「开发插件」。dump.py 与 filter_log_message.py 主要读取消息/日志，extract_audio.py 会导出含乘员信息的音频，而 cycle_alerts.py 会主动发布核心状态主题（selfdriveState、deviceState、pandaStates）。至少两个反直觉的事实：--json 对 Cap’n Proto 原始字节调用 json.loads 通常无法解析，真正转 JSON 的是 --dump-json；cycle_alerts.py 先声明九个告警却随即重赋值为只剩两项，实际只循环 cameraMalfunction 与 cameraFrameRate。远端 --addr 不能当作权限、脱敏或租户隔离策略。
四个脚本，三种权限等级
把数据流和副作用放在一起看，权限差异一目了然：前三个工具的输出主要是「读出来的内容」，第四个则会争用发布入口。
| 工具 | 数据流 | 实际输出或副作用 |
|---|---|---|
dump.py |
raw_live_logreader() 订阅指定地址主题，默认为 SERVICE_LIST 全部服务；每条原始字节先按 log.Event 解码 |
可打印 Event、十六进制或字段；--addr 非环回时底层切换 ZMQ 并重置消息上下文 |
filter_log_message.py |
有路段参数时用排序后的 LogReader 查 logMessage、errorLogMessage、operatingSystemLog；无路段时实时订阅前者与 OS 日志 |
打印 JSON 结构化日志或 OS 日志；实时模式未订阅 errorLogMessage |
extract_audio.py |
ReadMode.AUTO_INTERACTIVE 选路段来源，LogReader.filter("rawAudioData") 得载荷，拼成 int16 样本 |
经 write_wav_file() 导出单声道 WAV，或经 play_audio() 本机播放 |
cycle_alerts.py |
构造 Honda 参数与随机化 SubMaster 状态，用 Events.create_alerts()、AlertManager 生成告警 |
每 200 个控制周期发布 selfdriveState、deviceState、pandaStates，循环不停 |
dump.py 与 filter_log_message.py 的失效点
dump.py 即使指定 --no-print 仍逐条解析 Event；--pipe 用 str(msg) 写标准输出，得到的是 Python 字节表示文本而不是原始二进制流；--json 对原始字节调用 json.loads 通常失败。--values 只检查路径第一段存在，后续 getattr 缺失可直接抛错。顶层 codecs.register_error("strict", ...) 还会影响进程内使用该错误处理器的解码行为，插件封装时不应默许这种全局修改。
filter_log_message.py 的坑集中在时间与字段两处。等级过滤只作用于结构化日志，不影响 OS 日志；离线非 --absolute 的时间从第一条读取到的消息起算，而不是第一条匹配日志，且多个路段共享该时间原点、段间不重排序；实时模式则用原始 logMonoTime 纳秒换算秒数，两者语义不同。print_logmessage() 只捕获 JSON 解析异常，若 JSON 缺 levelnum、filename 或 msg 会抛键错误。
| 工具 | 易踩边界 | 原因 |
|---|---|---|
dump.py |
--json 通常解析失败 |
对 Cap’n Proto 原始字节调用 json.loads；转换应使用 --dump-json |
dump.py |
解码行为被全局改写 | 顶层注册了 "strict" 错误处理器 |
filter_log_message.py |
相对时间原点不是首条匹配日志 | 离线时间从第一条读取到的消息起算，多路段共享 |
filter_log_message.py |
实时模式拿不到错误日志 | 实时订阅未包含 errorLogMessage |
两个工具都会打印原始事件或日志内容，可能包含标识符、位置、进程路径及异常栈，因此远端 --addr 不能作为生产环境的权限、脱敏或租户隔离策略。
extract_audio.py：WAV 连续性与隐私
extract_audio.py 把所有 rawAudioData.data 按 NumPy 原生端序的 int16 视为连续样本，再原样写成 WAV，未显式转换字节序。它只取第一条的 sampleRate，不检查之后的采样率变化、通道数、消息时间戳或缺包间隔，因此导出文件不承诺与原车时间轴严格连续。它先把所有消息和样本拼成内存数组，长路段可能占用较大内存。
隐私侧还有一个关键前提：rawAudioData 缺省 should_log=False，loggerd 只有在启动时读取 RecordAudio 为真才订阅该主题。所以没有音频消息不等于麦克风硬件故障；而一旦录制，导出的语音可能含高度敏感的乘员信息。使用上，输出文件已存在时会交互确认，--play 会使用本机音频设备；只传 --play 或 -o 而不传路段名，主程序仍执行 args.route_or_segment_name.strip()，会报 AttributeError。
cycle_alerts.py：发布核心状态的边界
cycle_alerts.py 先声明九个可听告警，但随后把 alerts 重赋值为仅 cameraMalfunction 与 cameraFrameRate 两项，本快照实际只循环这两项。它随机改写 SubMaster 内的设备状态、模型速度、进程列表和主题 alive/valid/freq_ok，没有对这些订阅数据调用 sm.update()，由此产生的告警文本是随机夹具结果，不是车辆健康检查。
发送消息由 new_message() 构造，默认 Event valid=False，脚本没有覆写。即便如此，在实际设备上争用 selfdriveState、deviceState、pandaStates 的发布入口仍会干扰 UI 和状态消费者，不能作为行车调试插件。脚本没有发送 sendcan 或直接控制 ECU，但这不等于发布核心状态没有风险。
硬件与插件化约束
建议把原始消息/日志检索、音频导出、状态刺激拆成三个权限等级，而不是统称「开发插件」：观测插件仅获指定主题、时间范围及字段脱敏后的只读视图；音频导出需要单独授权、留审计并限定本地文件生命周期；状态刺激仅允许仿真进程或隔离测试总线，不能发布到生产 deviceState/pandaStates。源文档明确这些是重构要求，不是当前工具已有的隔离保证。
常见问题
dump.py 的 –json 为什么常常解析失败？
因为它对 Cap’n Proto 原始字节直接调用 json.loads(msg)，通常无法作为 JSON 解析。源文档指出真正把 Event 转为 JSON 文本的是 --dump-json；--pipe 得到的也只是 Python 字节表示文本，不是原始二进制流。
导出的音频能当作和原车同步的时间轴证据吗？
不能。extract_audio.py 只取第一条的 sampleRate，不检查之后的采样率变化、通道数、消息时间戳或缺包间隔，而且是按 NumPy 原生端序把 int16 视为连续样本原样写 WAV，因此导出文件不承诺与原车时间轴严格连续。
cycle_alerts.py 会循环几个告警？
本快照实际只循环两个：cameraMalfunction 与 cameraFrameRate。脚本先声明九个可听告警，随后把 alerts 重赋值为这两项，且告警文本来自随机夹具结果，不是车辆健康检查。
这些开发工具能当作「只读」吗？
不能一概而论。前三个工具主要读取数据，但远端 --addr 不是权限或脱敏策略；cycle_alerts.py 则主动发布三个核心状态主题，会干扰 UI 与状态消费者。音频导出还涉及高度敏感的乘员信息，应单独授权与审计。
延伸阅读
- 告警音频的采集链路 —— 承接音频消息从录制门到导出的同类边界。
- 开发工具、固件与回放的信任边界 —— 解释开发脚本为何需要按权限分层。
- loggerd 合成回放的隐私门 —— 录制侧隐私门与音频导出相互印证。
- Cabana：CAN 数据流、DBC 编辑与硬件边界 —— 另一个明确标注「只读采集」的开发工具对照。
- 回放前端的 CAN 数据链路 —— 承接离线日志读取与时间基准问题。
参考资料
- 项目 02 ——
openpilot-research/DEV_LOG_AUDIO_ALERT_TOOL_BOUNDARIES_DEEP_DIVE.md（取用了四个开发脚本的数据流与副作用、转储与日志过滤失效点、音频导出连续性与隐私门、告警刺激的真实范围）。
说明：本文为对固定源码快照的静态结构分析，未运行完整测试套件、未连接硬件、未验证目标车型的真实参数组合。文中所有阈值、行号索引与配置均出自源文档，标注为未验证的结论保留其原有边界。
更新记录
首次发布 2026-10-11 最近核对：2026-10-11