一个硬件原型真正跑顺，不是看某一张页面截图，也不是看某一次串口日志。它更像一条路：传感器能稳定读数，开发板能显示状态，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 做一个环境异常感知模块