企业官网建设流程全解析

这两年我自己的厨房屋里，有三样东西最容易让人原地爆炸：生豆子没泡够、糖浆温度差了三度、以及热制皂的皂液突然“火山喷发”。前两样还能补救，第三样直接让人想摔盆。折腾过普通计时器、手机闹钟、甚至一张写着时间轴的便签之后，我决定做一台真正懂热制程的设备，就是标题里这个Saucier’s Sentinel - Hot Process Timer。

简单说，它是一台面向“热制程”的智能计时器，服务对象不是日常炒菜，而是焦糖、果酱、热制皂、低温慢煮这些温度曲线和阶段切换比总时长更重要的活儿。整套东西从硬件到软件基本都自己搭，前后改了四个版本，踩了不少坑，也积累了一些别处看不到的实操经验。这篇文章就当是一份完整的项目复盘，既讲清楚我是怎么设计的，也把那些文档里不会写的翻车细节一并交代。

1. 热制程的失控点：普通计时器和温度计分开用，问题到底出在哪

先说个反常识的结论：对热制程来说，只看“时间”或者只看“温度”都不够，真正危险的是两者之间的位置关系。普通厨房计时器只会在倒数到零时响铃，它根本不关心你在第5分钟就已经到了190度，还是第20分钟才刚过150度。而一支单独的探针温度计，最多就是给你一个实时读数，没人盯着的时候，温度悄无声息地冲过去，等你看屏幕往往已经晚了。

1.1 温度曲线比总时长更关键

热制皂的过程很有代表性，皂液要在特定温度范围内维持一段时间，让碱和油脂充分反应，但温度一高皂液容易“火山喷发”溢锅，一低又可能假稠。焦糖也是一样，干法熬糖时从琥珀色到焦苦只隔了大概8到10度，而这段窗口常常在几十秒内就滑过去了。热制程真正需要的，不是“在第30分钟提醒我”，而是“第18分钟时温度到118度了，下一阶段开始，目标升温速率是每分钟3度，超过4度就报警”。

这类需求天然需要把“时间轴”和“温度值”绑在一起看。普通厨房计时器没有温度输入，自然做不到；单纯的温度计又没有阶段概念，只能显示当前读数。我后来做设计时，把设备定义成一件事：以温度为驱动的多阶段计时器。每个阶段不是简单的“倒计时N分钟”，而是“等待温度到达某个阈值、然后保持N分钟、并且升温速率不能超过某个值”。这套任务模型，基本覆盖了我平时遇到的所有热制程场景。

1.2 现成方案的三个缺口

做之前我认真列了一个表，看看手头现成工具到底缺什么：

三个缺口很明显：第一，没有“阶段编排”能力，没法预设一串步骤让设备自动推进；第二，即使有的App能画曲线，报警逻辑还是“超温才响”，没有预警概念，等温度已经冲过头才发现；第三，大多数温度计探头防水防腐蚀能力差，热制皂这种强碱环境里用两次就废了。

1.3 从“做人肉哨兵”到“让机器当哨兵”

我真正动手是因为连续两次做热制皂翻车。第一次是皂液从85度突然窜到近120度，我刚好离开厨房接电话，回来的时候锅边全是溢出来的皂糊。第二次我吸取教训守在旁边，但连续40分钟盯着屏幕实在熬不住，低头回个消息的功夫温度又掉了5度，皂液开始假稠。事后我意识到，我需要一个“哨兵”，它要能同时盯温度和时间，还要能在坏事发生前用足够大的声音把我拉回锅边。于是就有了这台设备的雏形：一块小屏幕、一支探针、一个按键，和一套专门为热制程写的状态机。

2. 设计目标与整体方案：把“哨兵”拆成四层

一台专用计时器的设计，不是把一个普通计时器和一根温度计焊在一起就行。真正常用的功能其实只有几个，但要做好做可靠，需要分层设计。我把它拆成四层：传感层、任务层、交互层、告警层。

2.1 需求清单与优先级排序

我花了一晚上写了需求清单，然后按“没有它我会死”和“没有它我只是不爽”两堆排序：

• 必须要有：多点温度采样的稳定读数、按阶段编排的任务、可自定义的温升速率上限、能穿透厨房噪音的告警、至少4小时的续航。
• 最好能有：记录温度曲线用于复盘、USB充电、屏幕在强光下可读、防水溅。
• 优先级最低的：连接手机、云同步、云端配方库。这些属于“以后再说”，一开始就加只会拖慢进度。

这个排序直接决定了我后续所有选型。比如我坚持用本机按键和屏幕，而不是做成纯App控制。原因是热制程场景里，手往往沾着油、糖、皂液，去掏手机摸屏幕根本不现实；而且厨房蒸汽会让手机指纹识别失灵。实体按键和一块大字体屏幕，才是这个场景里最可靠的东西。

2.2 系统拓扑：设备内部到底有哪些角色

我用文字描述一下整体结构，不用画图也能说清楚：

• 主控板负责跑状态机和算法，是决策大脑；
• 两路温度采集接口，一路接锅内液体探针，另一路可以接环境或锅壁温度，方便做参考校验；
• 一块2.4寸段码屏加背光，主要显示当前阶段、剩余时间、实时温度、升温速率；
• 一个编码器旋钮加两个实体按键，用于选择任务和调整参数；
• 蜂鸣器加一个高亮LED灯条，报警时声音和光同时输出；
• 内置一节18650电池，通过USB-C口充电。

这套拓扑的好处是，即使没有任何手机和网络，也能独立完成从开始到结束的所有操作。缺点是屏幕显示信息有限，温度曲线得事后把数据导出来看。这个我接受了，毕竟可靠性优先。

2.3 两路温度输入的取舍

一开始我只打算用一路探针，后来在实验中发现，热制皂时锅内液体温度和锅壁温度可以相差20度以上，如果只测液体，无法判断糊底的前兆。所以我给设备留了第二路输入，默认接一支锅壁贴片热敏电阻，两路数据都参与告警判断。锅壁温度异常升高，哪怕液体温度还没到，也能提前预警。

这个设计在后来的实测里救了一次锅，下面会细说。

3. 硬件选型与探头改造：精度、响应速度和蒸煮环境的平衡

硬件部分是整个项目迭代最多的区域。市面上现成的温度模块不少，但真正适合热制程长期浸泡、反复加热、强碱接触的成品探头很少，最后我基本是买核心传感元件自己做封装。

3.1 测温元件：热电偶还是NTC热敏电阻

这是第一个纠结的问题。热电偶测温范围广、响应快，但冷端补偿麻烦，信号小，需要专门的放大芯片；NTC热敏电阻便宜、灵敏度高，在-20到250度范围内表现很好，电路也简单，用分压加查表就能做到正负0.5度以内。热制程的常见温度区间是40到180度，正好落在NTC舒适区。

我最终选了100K NTC热敏电阻，B值3950，配合单片机内置ADC和查表法。选它不是因为热电偶不好，而是因为这个场景不需要上千度的量程，NTC的灵敏度和低成本更划算。查表间隔取1度一个点，中间用线性插值，实测在沸水校准后，20到150度区间误差能控制在正负0.3度左右。

3.2 探头封装：决定寿命的关键

直接买到的防水NTC探头大多是不锈钢圆头，配硅胶线，这种用在液体里问题不大，但热制皂的强碱环境会慢慢腐蚀硅胶，线芯进水后电阻漂移很离谱。我做了一个改动：把NTC元件塞进4毫米直径的316不锈钢护套里，用导热硅脂填充，尾端用压缩接头加PTFE密封圈锁死，线材换成铁氟龙镀银线。

这个改动明显提升了探头的寿命。普通硅胶线探头我在皂液里用三次就开始读数漂移，改装之后连续用了大半年，定期用沸水校验还是很准。另外，护套尖端要做成尖头，插入液体时热传导更快，响应时间能缩短到2秒以内。这比圆头钝头在测量糖浆的时候好用得多，圆头插进浓糖浆容易挂料，尖头则比较干净。

3.3 主控与显示选型

主控我用了一块常见的低功耗开发板，芯片带双ADC通道、足够多的GPIO，跑状态机绰绰有余。显示部分一开始用过0.96寸OLED，后来换成了2.4寸段码屏，原因很简单：OLED在厨房强光和蒸汽里反光严重，段码屏黑白底大字符反而怎么都能看清。字库不需要，段码屏本身是固定笔画，用数码管那套驱动方式就行。

电池用了两节18650并联，实测连续运行12小时还有余量，撑过最长的一次低温慢煮实验完全没问题。充电用TP4056模块加USB-C口，电流设成1A，充电时候设备还能正常工作，只是告警音量和背光亮度会略微受限。

4. 软件核心：阶梯状态机与温升速率预警算法

硬件只是骨架，真正让这台设备称得上“哨兵”的是软件。如果把整个系统比作一个流程控制单元，那么它需要能按预设的“阶段阶梯”往下走：阶段之间有关联、有跳转条件、有超时兜底。

4.1 任务模型：阶段、阈值、保持时间、速率约束

我先定义了一个通用的任务结构，每个任务由若干阶段组成，每个阶段包括：

• 阶段名称（字符串，用于屏幕显示）；
• 目标温度，以及允许的温度上下限；
• 保持时间，单位为分钟；
• 目标升温速率，以及允许的最大升温速率；
• 跳转条件：是温度到达后进入下一阶段，还是保持时间满足后进入下一阶段，或者两者都满足才跳转；
• 兜底超时：每个阶段设一个最大时长，超时没有到达目标温度，则报警并暂停，防止“一直等不到温度”造成糊锅。

举个例子，我做低温慢煮牛排时用的阶段序列是：第一阶段，60度无保持，速率不限，用于把水温从常温拉起来；第二阶段，60度保持45分钟，速率上限设为每分钟2度，防止加热过猛水温冲过65度。这套模型基本够用了。

4.2 状态机伪代码与实现要点

状态机本身不复杂，但有几个细节必须处理好。核心逻辑如下：

typedef struct { const char* name; // 阶段名称 int16_t target_temp; // 目标温度，单位 0.1 度 int16_t temp_low; // 允许的下限 int16_t temp_high; // 允许的上限 uint16_t hold_minutes; // 保持时间 uint8_t rate_max; // 最大升温速率，单位 0.1度/秒 uint8_t timeout_min; // 兜底超时 uint8_t next_on_temp; // 是否温度到达跳转 uint8_t next_on_time; // 是否时间到达跳转 } Phase; void run_task(void) { for (uint8_t i = 0; i < phase_count; i++) { phase_start(&phases[i]); while (1) { float t = read_temp_channel(0); float rate = calc_rate(&avg_filter); if (rate > phases[i].rate_max) { alarm(ALARM_RATE_TOO_FAST); pause_until_user_confirm(); } if (t > phases[i].temp_high) { alarm(ALARM_TEMP_HIGH); pause_until_user_confirm(); } if (phase_time_exceeded(&phases[i])) { alarm(ALARM_TIMEOUT); pause_until_user_confirm(); } if (phase_complete(&phases[i], t)) { beep_ok(); break; } } } beep_finish(); }

有几个点必须注意。第一，温度采样不能直接拿单次ADC值算斜率，否则轻微的读数抖动就会被放大成吓人的升温速率。我用滑动窗口取最近15个采样点做线性拟合，窗口约3秒，斜率值就稳了很多。第二，当处于“保持温度”阶段时，升温速率上限依然有效，因为很多意外都是发生在保温阶段，比如热制皂反应放热导致温度二次飙升，这时速率预警比单纯的超温报警快得多。

4.3 升温速率预警：为什么只看温度不够

这一点是整套设备最核心的设计思想。只做超温报警就像“看到水开了才关火”，往往已经晚了。比如热制皂的反应放热阶段，皂液可能在一分钟内从80度窜到120度，如果你等到温度超过设定值才发现，沸腾溢锅已经发生。而升温速率预警能提前40到60秒告诉你：“现在这个升温速度不正常”，这时候还有时间把锅移开或者关小火。

实际实现时，我设了三级预警：速率超过目标值但小于临界值，蜂鸣器短响两声提示；超过临界值，持续报警且屏幕闪烁；温度超过上一阶段目标值的1.2倍，语音级告警。三档里最常用的是第二档，因为它既不会因为正常波动误报，又能给出足够的反应时间。

4.4 温度数据的平滑滤波与校准

NTC查表之后的数据，我还会做一次中值滤波加滑动平均。中值滤波去掉偶发的尖刺信号，滑动平均让读数曲线变得平滑，计算斜率也更稳。中值窗口取5个采样点，滑动平均窗口取10个采样点，采样周期200毫秒一次，这样整体延迟不到1秒，既能保持响应速度，又不会让显示数字跳来跳去。

校准方面，设备启动后如果温度大于30度、小于90度，会提示用户是否进行沸水校准。沸水校准就是记录当前读数与100度的差值，存到EEPROM里作为偏移量。这个方法虽然土，但在100度附近精度足够用，而且每次用之前花两分钟校准一下，长期漂移问题就解决了。

5. 实测：焦糖、热制皂、低温慢煮三场“救场”记录

样机装好后，我连着做了三个月的实灶测试。特意挑了三类有代表性的热制程：焦糖（温度窗口窄、变化快）、热制皂（放热反应、容易失控）、低温慢煮（长时间恒温）。每一类都让这台设备在“即将翻车”的边缘拉了不止一次。

5.1 焦糖实验：干法熬糖的精准控温

干法熬糖是最考验温度响应速度的场景。白砂糖下锅后温度攀升非常快，尤其在130度以上，几乎每10秒就升高3到4度。普通做法是按经验看颜色，但“颜色”对色弱的人实在不友好，而且室内光线不同视觉效果差很多。

我设了一个三阶段任务：第一段，升温到140度，不限速率；第二段，从140度升温到175度，速率上限设为每分钟4度；第三段，达到175度后立即提醒，蜂鸣器长响，因为焦糖化已经到位，不需要保持。实测跑下来，温度到174.7度时蜂鸣器响起，我关火后余温又冲了约3度，最终稳定在177度左右，正好落在中等焦糖色区间，没有焦苦味。这个结果说明，应该给目标温度设定值留出“余温冲量”，也就是在预设目标时低3到5度，靠关火余温抵达最终目标。

5.2 热制皂实验：放热反应的“火山”预警

热制皂最危险的不是刚开始加热那一段，而是皂化反应进行到一半时大量放热。我曾经有一锅皂液从70度开始，在不到一分钟内升到110度，锅边直接起泡。有了这台设备后，我专门做了对照测试。

任务设置为：先升温到75度，保持15分钟，升温速率上限为每分钟1.5度。结果在保持阶段，第9分钟时皂液开始反应放热，升温速率瞬间跳到每分钟6度，设备在温度还没到80度时就响起了二级预警。我立刻把锅离火，并且用刮刀搅拌散热，大约30秒后温升停止，最后皂液稳定在82度完成皂化。这次救场让我彻底信服：保温阶段的速率预警比超温报警有用得多，因为它能捕捉到“反应开始”的早期信号，而不是等温度已经冲到脸上。

5.3 低温慢煮：长时间稳态维持能力

低温慢煮烤牛里脊那次我用了五小时，设备连续运行，第二路锅壁贴片探头全程监测锅底温度。中间有两次锅底局部温度超过85度，而液体主体还在60度，这是锅底水分不足、热量积聚的信号。如果是普通单探头温度计，只会看到液体温度没变，根本不知道锅底快糊了。

第二路探针的预警在第三次差点出现时响起，我把火调小并且补了点水，锅底温度降回安全范围。全程液体温度维持在59.8到61.2度之间，成品切面很漂亮，温度控制误差基本在正负1度内。这个实验也验证了设备长时间运行的稳定性：电池在实验结束后还剩两格电，没有死机，也没有出现温度曲线漂移。

5.4 失败一次：探针位置错误导致升温速率虚高

不是所有测试都顺利。第一次做热制皂时，我把液体探针插得太靠近锅壁，结果锅壁局部过热造成读数跳动剧烈，升温速率每次都在临界值附近反复触发报警。当时我以为是传感器问题，折腾了很久才发现是探针位置不对——它贴在锅壁热区，测到的是“锅壁温度”而非“液体温度”。

后来我把探针固定到锅中心位置，用一个小夹子让它悬浮在液体中部，读数立刻稳定下来。这个教训让我在设备说明里专门加了一句：探针必须插在液体中心偏下、离开锅底和锅壁至少2到3厘米处。特别是浓稠物料，搅拌时会有漩涡，探针要避开中心涡流区，否则会跟着物料旋转导致线缆缠绕。

6. 复盘与改进：批次间差异、UI交互、供电续航这些“看不见”的功夫

硬件的坑可以靠选型绕开，软件逻辑的问题可以通过算法优化，但真正影响长期使用的往往是那些“看不见”的细节。这一章把我在改进过程中遇到过的几个实际问题集中复盘一下。

6.1 探针漂移与校准周期

NTC热敏电阻长期使用后会有一定漂移，尤其是反复经受温度冲击后。我在第四版样机上做了一个统计：连续使用两个月、大约每天开机一次，沸水校准后的偏移量从初始的0.1度增加到0.5度左右。这个幅度在大多数热制程里还能接受，但对于焦糖这类窗口只有几度的场景，0.5度误差就可能决定口感。

我的对策是固定校准节奏：每隔两周做一次沸水校准；每次做低温慢煮和热制皂之前也做一次，反正只需要三分钟。设备在提示校准的时候，屏幕上会显示“沸水校准并保存偏移量”，保存后下一次测量会自动应用这个偏移。这里有个细节，沸水校准一定要用纯净水，自来水里的矿物质吸附在探头表面反而会引入另一个误差源。

6.2 蒸汽环境下的接口保护

厨房蒸汽是电子设备的大敌，尤其是我把USB充电口和探针接口都放在机身侧面的版本，蒸汽冷凝水直接顺着线材流进接口，导致接触不良。第四版我把所有接口都做了两类处理：探针接口改成防水航空插座，USB口加了硅胶塞；机身内部在接口位置涂了一层三防漆。

还有一个容易被忽略的地方：探针线本身的寿命。铁氟龙外皮确实耐温耐腐蚀，但反复弯折后还是会从根部断裂。后来我在线材根部加了一段热缩管弹簧护套，弯折半径变大，断线问题基本消失。这个改造很简单，但对于长期使用非常关键。

6.3 交互细节：几个让人抓狂的按钮逻辑问题

界面交互的坑，说起来都是小问题，但每次用都让人抓狂。比如最早的版本里，按“开始”按钮就会立即进入任务第一段，但是如果在第一段还没开始计时的时候按“暂停”，再按“继续”，计时器会从头开始，而不是从暂停的位置继续。这个问题在实验里被反复折磨后，我重新修改了状态机的暂停逻辑：暂停时冻结所有计时器和斜率计算，继续时再恢复，而不是重置。

另一个问题是编码器旋钮和按键共用同一个事件端口，误触率很高。后来我把编码器的按下事件改为长按确认，短按只负责切换显示内容，误触问题大幅减少。这些都是文档里不会写的东西，但直接决定一台设备好不好用。

6.4 续航与充电管理

两节18650电池的容量对于这种低功耗设备其实很够用，但有一个隐患：电池充满后如果一直插着充电线，充电管理模块的浮充可能会让电池长期处于满电状态，影响寿命。我在软件里做了一版“充电完成提醒”，充满后蜂鸣器短响三声，屏幕显示“拔掉电源”，这样就不会长时间浮充。

另外一个更实际的问题是低温环境下电池性能下降。冬天放在厨房窗边，室温接近零度时，电池电压跌落很快，屏幕上显示的电量会瞬间掉两格。后来我在设备说明里建议冬天尽量把设备放在灶台附近的温暖区域，不要靠窗，或者干脆使用的时候插着充电线，实测在0度以上环境正常使用没问题。

写在最后：这个项目还能往哪儿走

目前这台 Sentinel 已经稳定使用了近一年，做焦糖、热制皂和低温慢煮的成功率明显提升。我个人的体会是，热制程的核心矛盾从来不是“温度准不准”，而是“在正确的时间知道温度在发生什么变化”，所以设备才叫“哨兵”，而不叫“温度计”。

如果还想继续玩，我有三个方向：一是增加第二路独立温度探头，用来同时监测两个锅，但这样系统复杂度会提高不少；二是加入红外测温模块做锅壁非接触监测，减少探头接触问题；三是把温度曲线导出为CSV文件，方便后期复盘和调整配方。但无论怎么扩展，我会坚持一个底线：核心功能必须在无手机、无网络的环境下独立完成，因为厨房里最需要的是“烫手时刻立刻报警”，而不是“云端曲线同步成功”。