一个硬件原型真正跑顺不是看某一张页面截图也不是看某一次串口日志。它更像一条路传感器能稳定读数开发板能显示状态WiFi 能连上网页能看到数据接口能区分来源算法能解释为什么触发或不触发。每一段都不复杂但串起来以后才像一个可以继续做下去的项目。这个环境感知原型从 ESP32-S3-LCD-1.47、BME690、LVGL 屏幕、WiFi 后台、实时网页一路做下来最大的收获不是某个单点功能而是知道后面该按什么顺序补短板。顺序很重要。顺序错了就会在不稳定的基础上堆功能。先看硬件有没有真的稳定硬件稳定不是“能亮”这么简单。对这个原型来说至少要看几件事。传感器能不能连续输出数据读数会不会突然中断I2C 地址是否固定芯片 ID 是否能稳定读到供电是否可靠杜邦线是否容易松设备重启后能不能自动恢复采集。如果这些都没确认后面做网页、算法和外壳都会被底层问题拖住。很多时候页面状态异常不是前端写错而是底层采样本身就不稳定。所以我会把第一阶段的重点放在连续运行。不是看一条日志而是让它跑一段时间观察读数、时间戳、WiFi 和上传状态。再看数据有没有足够透明很多传感器项目的问题不是没有数据而是只有一个最终状态。比如页面显示“异常”但不知道是原始值变了基线变了还是持续时间累计了。这样很难调。我更希望页面里能看到这些字段textgas_rawgas_smoothgas_baselinedeviationduration_secondsscorewarmupsourcetimestamp字段多一点页面会没那么简洁但对调试很有价值。等算法稳定以后可以把部分字段折叠起来早期不要急着隐藏。网页可信比网页漂亮更重要网页做出来以后最容易被界面效果吸引。卡片、颜色、动画都可以后面再说第一版要先可信。可信包括几件事- 显示数据来源- 显示更新时间- 能判断数据是否过期- 能区分模拟数据和真实硬件数据- 异常评分有中间依据- 接口失败时给出明确提示。如果页面只显示漂亮状态不显示来源和时间戳读者很难判断它是不是实时硬件。尤其是网络断开以后页面如果继续显示旧数据就会误导判断。别在数据不稳时急着做复杂算法算法当然重要但算法应该建立在稳定数据上。早期最该避免的是传感器还没稳定外壳进气还没验证就开始调复杂模型。这样最后不知道模型是在识别环境变化还是在拟合硬件噪声。我会先用简单可解释的方法平滑、基线、相对偏离、持续时间。等积累到更多真实数据再考虑更复杂的分类。这里有个判断标准如果你不能解释一次异常为什么出现就不要急着让算法更复杂。复杂算法可能让页面看起来更高级但排查难度会成倍增加。外壳和结构要用数据说话开发台架跑通以后下一步往往是外壳。但外壳不是简单包装它会改变空气流动。随身夹扣、家庭底座、桌面摆放每种方式都会影响读数。我会用同一套页面记录几组数据text裸板状态临时外壳状态随身夹扣状态家庭底座状态不同摆放位置不同通风条件每组都看原始值、基线和持续偏离。这样才能判断外壳是不是影响太大。如果外壳一装上响应变慢很多就要先改结构不要靠算法硬补。功耗和联网频率迟早要面对只要开始考虑随身形态功耗就绕不开。ESP32-S3、屏幕、WiFi、传感器、震动提醒都会耗电。开发板插 USB 时感受不到换成电池就会很明显。后续需要逐步回答这些问题- 屏幕是否需要常亮- WiFi 是否需要持续在线- 上传频率能不能降低- 传感器采样频率多少合适- 震动提醒持续多久- 低功耗模式会不会影响响应。这些问题不要在第一天就全部解决但要提前留意识。否则等外壳做小了、电池塞进去了才发现续航不够会很被动。恢复能力比一次成功更重要硬件项目不能只看一次成功。真正使用时网络会断设备会重启接口会超时传感器会预热。系统要能恢复。我会检查这些情况text断电重启后能否恢复采集WiFi 断开后能否重连接口失败后是否会继续重试清除 WiFi 后能否重新配网传感器读数失败后是否有错误状态网页是否能提示数据过期。这些功能不一定显眼但它们决定项目能不能持续跑。只在桌面上成功一次不代表后面稳定。后续改进我会按这个顺序来如果继续往下做我会按这个顺序补短板text1. 先做更长时间的数据记录2. 固定几种安全样本和场景3. 调整平滑、基线和持续时间参数4. 做随身夹扣和底座的粗糙结构5. 观察外壳对进气和响应速度的影响6. 优化功耗和上传频率7. 再考虑小型化和更完整的提醒方式。这个顺序不花哨但比较稳。先把数据跑顺再谈形态先把误判看清再谈提醒先把粗糙结构验证清楚再做漂亮外壳。如果给读者一个最短路线如果读者只是想跟着做一个类似原型我建议不要从最复杂的版本开始。最短路线可以是这样text先用空工程确认 ESP-IDF再跑板厂屏幕 Demo接 BME690 并打印第一条日志把读数显示到屏幕上做一个局域网状态页再把数据接到前端页面最后才做基线和异常评分。这个路线的好处是每一步都有可见结果。屏幕亮了、日志出了、网页打开了、接口返回了读者能一步步确认自己没有走偏。不要一开始就把固件、网页、算法、外壳同时做出错时会不知道先查哪里。还有一个建议每完成一步都保留一份能运行的版本。哪怕只是复制目录或打一个压缩包也比后面出问题时完全回不去强。硬件项目里的“昨天还能跑今天不知道为什么坏了”很常见版本留得越清楚排查越轻松。每次改动后都要有一个小检查硬件项目里很多问题不是一次大改造成的而是几次小改叠出来的。今天改了 WiFi明天改了屏幕后天改了算法最后发现传感器状态不对却不知道是哪一步引入的。所以每次改动后我会做一个很小的检查text能否编译能否烧录屏幕是否正常显示串口是否有传感器日志网页后台是否能打开latest 接口是否有新时间戳。这些检查每次只花几分钟但能避免问题积累。尤其是准备继续做外壳和小型化时软件基线必须先稳定否则结构问题和代码问题会混在一起。哪些东西可以晚一点做有些功能看起来很有吸引力但可以晚一点。比如复杂动画、多设备管理、漂亮外壳、更多提醒方式、完整历史曲线。这些不是不重要而是不应该压在数据还不稳定的时候做。我会先推迟这些内容text完整商品外观多房间组网复杂气味分类自动联动家电长期账号系统过度精美的前端动画。先把单设备跑稳把数据讲清楚把误判边界写明白。等单点稳定以后再扩展多设备和更复杂的体验。这样项目往前走时每一步都有依据。真正能复用的是方法不是某个文件做完这一轮以后代码当然重要但更值得复用的是方法。比如遇到问题先分层工具链、板级示例、传感器、屏幕、WiFi、接口、前端。每一层都能单独确认就不会所有问题混在一起。同样的思路也适合别的传感器项目。换成光照、噪声、温湿度或其他环境传感器底层器件不同但排查顺序类似先确认数据真实再确认页面可信最后再谈算法和外壳。这也是我觉得这一轮开发有价值的地方。它不只是做出一个页面而是把一个硬件小项目从“能读数”推进到“能解释、能排查、能继续迭代”。后续无论换更小的板子还是换别的传感器这套顺序都还能用。先让底层可信再让页面可信最后再谈体验和外观。如果一开始就跳到外观或复杂功能短期看起来进展快长期反而更容易返工。硬件项目里的很多时间都是花在把不确定性一层层拆开的过程里。把顺序守住项目不一定最快但会更稳。对个人硬件原型来说这比一次性堆功能更重要。能稳定复现才有继续优化的意义。否则今天能跑、明天不能跑后面所有改进都会变成猜。这一点比多加几个功能更重要。稳定是后面所有优化的前提和底座。写到最后最值得保留的是排查顺序这个 ESP32-S3 环境感知原型现在还不是成熟产品但它已经把最重要的路径跑了一遍传感器采集、屏幕显示、WiFi 后台、实时网页、数据来源和异常评分。如果你也在做类似硬件项目最值得参考的不是某一段代码而是排查顺序。先确认工具链再确认板厂 Demo先确认传感器再确认网页先显示原始数据再谈异常评分先做开发台架再谈小型外壳。这样做慢一点但每一步都能解释。硬件项目最怕的不是慢而是看起来做了很多出了问题却不知道从哪里查。阅读顺序这一组文章建议按标题前面的序号阅读01 → 02 → 03 → 04 → 05 → 06 → 07 → 08 → 09 → 10。当前这篇是 10把一个 ESP32-S3 环境感知原型跑顺从硬件、网页到后续改进。下一篇这一组文章到这里先收住。如果想从头看可以回到 01从想法到硬件原型用 ESP32-S3 做一个环境异常感知模块
