做硬件原型时，选开发板经常会被两个方向拉扯。一个方向是尽量小，最好一开始就像最终产品；另一个方向是尽量好调，屏幕、接口、供电、示例代码都要方便。真开始动手以后，我更倾向于后者。早期原型不是为了证明外壳有多小，而是为了尽快确认传感器能不能读、数据显示是否稳定、网络是否能连、页面能不能看到真实数据。 这

刚开始做这个环境传感器原型时，最容易犯的错误就是把目标写得太满：想识别燃气，想识别烟味，想判断食物变质，还想做成随身小配件，最好再接一个手机提醒和家庭设备联动。听起来都合理，但真正把开发板摆到桌面上以后，会发现问题反而变得很简单：第一块板子到底要先证明什么？ 我最后把目标压回到一句话：先做一个能采集

一个硬件原型真正跑顺，不是看某一张页面截图，也不是看某一次串口日志。它更像一条路：传感器能稳定读数，开发板能显示状态，WiFi 能连上，网页能看到数据，接口能区分来源，算法能解释为什么触发或不触发。每一段都不复杂，但串起来以后，才像一个可以继续做下去的项目。 这个环境感知原型从 ESP32S3LCD

下一步继续扩展功能前，最值得先补的是端到端可观测性：为每个 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