自制热制程智能计时器:温度驱动多阶段控制与预警实践
这两年我自己的厨房屋里有三样东西最容易让人原地爆炸生豆子没泡够、糖浆温度差了三度、以及热制皂的皂液突然“火山喷发”。前两样还能补救第三样直接让人想摔盆。折腾过普通计时器、手机闹钟、甚至一张写着时间轴的便签之后我决定做一台真正懂热制程的设备就是标题里这个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蓝牙温度计能看到温度曲线依赖手机屏幕常亮耗电蒸煮环境里操作不便烤箱/灶台自带定时烤箱腔体控温不适用于明火、电磁炉上的锅具三个缺口很明显第一没有“阶段编排”能力没法预设一串步骤让设备自动推进第二即使有的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文件方便后期复盘和调整配方。但无论怎么扩展我会坚持一个底线核心功能必须在无手机、无网络的环境下独立完成因为厨房里最需要的是“烫手时刻立刻报警”而不是“云端曲线同步成功”。

相关新闻

从决策参数到像素密度:圆与椭圆光栅化的工程实现

从决策参数到像素密度:圆与椭圆光栅化的工程实现

1. 从直线到曲线:为什么画圆不能直接硬算坐标在软件渲染这条路上走到“画圆”这一步的,大概都经历过一个看似简单、动手就翻车的时刻。直线光栅化只要处理一个斜率,稍微花点心思就能把 Bresenham 写得又快又漂亮;可一旦换成圆&…

2026/10/14 16:29:40 阅读更多 →
BP神经网络实战:从零手写MNIST手写数字识别分类器

BP神经网络实战:从零手写MNIST手写数字识别分类器

简介:BP神经网络手写数字识别是机器学习入门的经典实践,这份Python实现资源专门面向正在学习神经网络原理、希望动手操作MNIST数据集的开发者和计算机视觉初学者。压缩包共2000个文件,以图片样本为主体,同时提供Python源码、Matla…

2026/10/14 16:29:40 阅读更多 →
Semantic Router 投影(Projections)完全指南:从信号协调到命名路由档位的三层架构实战

Semantic Router 投影(Projections)完全指南:从信号协调到命名路由档位的三层架构实战

后端API网关模型推理服务AI Agent 【免费下载链接】semantic-router An open, programmable decision layer for models and compute. 项目地址: https://gitcode.com/gh_mirrors/sem/semantic-router 点击查看 免费下载 routing.projections 是 semantic-router 位…

2026/10/14 16:29:40 阅读更多 →

最新新闻

重放攻击与数据完整性:区别、原理与工程防护方案

重放攻击与数据完整性:区别、原理与工程防护方案

1. 先从一次“事故”说起:重放攻击与数据完整性的日常场景做后端开发和系统设计的朋友,大概率都遇到过这样的场景:接口文档上写着“防重放”“防篡改”几个字,然后群里就开始争论——加了签名是不是就能防重放?用 HTTP…

2026/10/14 17:14:39 阅读更多 →
非线性SVM与核技巧:从低维映射到高维的实战指南

非线性SVM与核技巧:从低维映射到高维的实战指南

1. 从一条直线搞不定说起:为什么需要非线性SVM 很多人第一次接触支持向量机(SVM)的时候,都是从二维平面上画一条直线把红点和蓝点分开开始的。那个阶段确实很爽,因为数据线性可分,一条直线或者一个超平面就…

2026/10/14 17:14:39 阅读更多 →
C#模拟电梯控制源码:从状态机到调度算法全解析

C#模拟电梯控制源码:从状态机到调度算法全解析

简介:C# 模拟电梯控制是一套基于 Windows Forms 的完整 Visual Studio 工程,面向初学 C# 的桌面应用开发者,也适合准备课程设计或希望理解对象建模、事件驱动与多线程调度等机制的读者。源码通过电梯、楼层、乘客对象抽象还原核心逻辑&#x…

2026/10/14 17:14:38 阅读更多 →
OpenClaw人人养虾:Chrome扩展实现浏览器内轻量养成玩法全解析

OpenClaw人人养虾:Chrome扩展实现浏览器内轻量养成玩法全解析

1. 项目概述:从一次“云养虾”的冲动到浏览器角落的小管家第一次听到“人人养虾”这个名字,我以为是哪个水产养殖厂商做的营销插件。直到我打开项目文档,才发现它其实是某个开源社区里一个非常有趣的轻量级养成玩法:你不需要真的去…

2026/10/14 17:14:38 阅读更多 →
Windows上运行Linux程序指南:WSL2搭建、示例代码与性能调优

Windows上运行Linux程序指南:WSL2搭建、示例代码与性能调优

最近有个朋友跟我倒苦水:他手头的小项目必须在Linux环境下编译,可主力机是Windows,每次都得先折腾半天环境。这个场景其实太常见了——很多开源工具链只发布了Linux版本,日常脚本依赖Linux的命令行习惯,或者部署目标是…

2026/10/14 17:14:38 阅读更多 →
rp-engine变量绑定深度解析:5种绑定语法与死路径检测,根治条件分支收敛难题

rp-engine变量绑定深度解析:5种绑定语法与死路径检测,根治条件分支收敛难题

【免费下载链接】rp-engine YAML-native agent workflow execution engine, written in Rust 项目地址: https://gitcode.com/gh_mirrors/rp/rp-engine 点击查看 免费下载 rp-engine 是一个用 Rust 编写的 YAML 原生 Agent 工作流执行引擎。本文拆解它的变量绑定&a…

2026/10/14 17:13:38 阅读更多 →

日新闻

AnyPS5通用适配层设计:兼容性与性能的工程取舍

AnyPS5通用适配层设计:兼容性与性能的工程取舍

1. 从"AnyPS5"这个名字说起:它到底想解决什么问题第一次看到"AnyPS5"这个标题,我脑子里冒出来的第一个念头是:这大概率是一个围绕"跨平台运行"或者"通用适配"做文章的项目。名字里的"Any"…

2026/10/14 0:00:41 阅读更多 →
Flutter跨平台开发实战:二手交易应用与HarmonyOS适配

Flutter跨平台开发实战:二手交易应用与HarmonyOS适配

1. 项目概述:Flutter跨平台二手交易应用开发作为一名长期从事移动应用开发的工程师,我最近完成了一个基于Flutter框架的二手物品交易平台项目。这个项目最吸引我的地方在于它完美结合了Flutter的跨平台优势与HarmonyOS的生态特性,实现了"…

2026/10/14 0:00:41 阅读更多 →
DFS算法解决飞机降落调度问题实战

DFS算法解决飞机降落调度问题实战

1. 项目背景与核心思路飞机降落问题是一个经典的调度优化场景,也是算法竞赛和面试中的高频题目。这个题目要求我们合理安排多架飞机的降落顺序和时间,确保所有飞机都能安全着陆而不发生冲突。在实际航空管制中,这类问题直接关系到飞行安全和机…

2026/10/14 0:00:41 阅读更多 →

周新闻

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

简介:基于 ARIMA、LSTM、Transformer 等模型的流感时间序列预测 Python 源码,面向计算机相关专业课程设计与期末大作业学生,以及项目实战学习者。内容覆盖预处理、平稳性检验、定阶、残差分析、多模型对比预测的完整时序建模流程,…

2026/10/14 3:30:28 阅读更多 →
影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别 做影刀RPA自动化,十个新手有八个栽在"往输入框里填东西"这件事上:要么填不进去,要么填了一半,要么直接把原来内容追加在后面。这背后的根因&…

2026/10/14 16:30:29 阅读更多 →
影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容 1. 认识影刀:什么场景该用RPA采小说数据 起点中文网的页面结构相对稳定——分类榜单、书籍详情、章节内容三块独立页面,跳转链路清晰。这种场景非常适合影刀自动化&#x…

2026/10/14 3:29:58 阅读更多 →

月新闻

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/13 22:01:27 阅读更多 →
Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/13 14:57:39 阅读更多 →
黑夜航拍船只数据集训练YOLOV5模型全流程解析

黑夜航拍船只数据集训练YOLOV5模型全流程解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/14 7:53:34 阅读更多 →