下一步继续扩展功能前，最值得先补的是端到端可观测性：为每个 session 贯通 device id、session id、audio frame count、ASR 文本、LLM 耗时、TTS 首帧和 close reason。Session 记录 session id、设备对应的 dialogue key、voice key、协议版本、音频格式、采样率、帧时长、累计 binary frame/

拆解原生 ArkTS 的 Stage 启动链：EntryAbility 建立 AppStorage 状态，WindowStage 加载首页、监听窗口宽度并初始化服务；说明配置更新、备份入口空实现及未实机验证边界。

解析 Flutter 与 ArkTS 插件的音频桥接：MethodChannel 传命令，EventChannel 推送帧；梳理隐私权限、AudioCapturer 采音、NSDF 检测及 release HAP 未实机回归边界。

围绕 StringtTuning 原生 ArkTS 1.0.7，梳理参考音播放、AppStorage 与 Preferences 的部分设置同步、调音会话保存和历史读取，并说明 PCM/合成分支、renderer 竞态及实机验证边界。

基于 StringtTuning 原生 ArkTS 1.0.7 源码，拆解 AudioCapturer 采集、4096 点窗口、NSDF 音高估计、跳变抑制、平滑与音分换算，并严格区分源码与实机验证边界。

从真实 StringtTuning 项目出发，梳理原生 ArkTS 1.0.7 与 Flutter 1.0.8 两条 HarmonyOS 工程线，明确版本、入口、截图、构建产物和验证边界。

也没有真实温升、电流、CPU 或无线占空比数据。建议的记录表包含：固件 SHA-256、供电电压、采样时间、环境温度、板上测点温度、电流平均值、电流峰值、屏幕亮度、音量、Wi-Fi RSSI、会话次数、TTS 播放占比、队列 overflow 次数和异常日志。前者通过 FakeWriter 收集 WebSocket frame，并用替换后的 ASR、LLM、TTS 函数检查 hello、liste

本文不连接生产服务器、不读取本地凭据文件，也不执行上传、重启、Nginx reload 或公网探测。因此，当前可以确认的是部署脚本包含上传前预检、备份、环境更新、安装、重启、详细 health、模型 smoke 和后半段异常回滚；文章不复述该文件位置和内容。当前旧片段如下，它具备 WebSocket 所需的 HTTP/1.1、Upgrade、Connection、Host 和长读超时，但 upst

设备每包解码后通常得到 1280 字节 PCM，10 包约 12800 字节，能形成三个完整 4096 字节块并留下尾段，既满足启动缓冲，又没有一开始就超过 OpenHarmony 路径的四槽队列。用户听到扬声器播出一句回答之前，项目里至少经过了五种不同的数据形态：LLM 返回的回答文本、Fish Audio 或离线 VITS 生成的 PCM、服务端编码出的 16 kHz Opus、WebSock

Provider 抽象落地时可以引入有限的错误类别，例如 configuration、authentication、rate_limit、timeout、invalid_response 和 unavailable，并保持面向设备的提示稳定。需要比较的指标不只是“有回答”：还包括首个模型响应耗时、总调用次数、超时回退、答案长度、TTS 是否收到完整句、同一设备历史是否隔离，以及切换 Provide