90行代码掀桌：监控工具集体被用户骂了3年的盲区

你盯着任务管理器，CPU飙到87%。正常吗？该关哪个进程？什么时候开始的？

任务管理器不说话。HWMonitor不说话。MSI Afterburner也不说话。

它们只告诉你「发生了什么」，从不解释「为什么」。这个盲区，有人用90行Python填上了。

800小时烧出来的顿悟：用户要的不是数据，是上下文

开发者PC_Workman在笔记本上硬扛了800小时开发，机器峰值94°C。他发现问题本质：现有工具都在用同一套阈值审判所有人。

游戏PC待机30% CPU？正常。轻薄本待机30% CPU？绝对有问题。

「你的正常」和「我的正常」根本不是一回事。这个认知差，让无数用户被误报折磨，或更糟——真正的问题被「正常」阈值掩盖。

PC_Workman的解法粗暴直接：放弃硬编码阈值，让系统学会「你」。

EventDetector的核心逻辑只有三步：记录你过去10分钟的平均值作为基线，对比当前数值算出差值，超过阈值才触发警报。

代码里这个函数 `_get_baseline` 只干一件事：从 `minute_stats` 表拉取最近10分钟的平均数据，缓存60秒避免频繁查询。没有机器学习，没有云端同步，就是最简单的SQL平均值。

但效果致命——基线是你自己，不是别人。

从数学到产品：30行代码解决两个老毛病

有了个人基线，检测异常变成小学算术：当前值减基线值，差值超过阈值就是异常。

PC_Workman贴出的 `_check_metric` 函数里，这行判断 `delta = current_val - baseline_val` 后面跟着一个朴素的不等式。没有神经网络，没有概率分布，就是减法。

但早期版本栽在另一个坑里：Chrome每隔30秒 spike 一下CPU，用户一小时收120条警报。警报疲劳比没警报更可怕。

解法同样朴素——`self._last_event_time` 字典记录每条指标上次触发时间，到点再响。rate limiting 的代码不超过10行，把骚扰式推送变成有意义的对话。

最终形态叫「hck_GPT insights」：系统用自然语言告诉你「CPU温度比你的日常高15°C，始于打开Photoshop后3分钟」。不是原始数据，是带时间戳的因果链。

为什么大厂不做这个？

HWMonitor有20年历史，MSI Afterburner装机量以亿计。它们不是技术落后，是产品逻辑锁死：监控工具卖的是「专业感」，密密麻麻的数字面板让用户觉得自己很懂行。

PC_Workman反着来——把专业感撕碎，换成一句人话。

这个选择有代价。个人基线需要本地存储历史数据，10分钟窗口意味着新用户前10分钟没有检测能力，rate limiting 调太松漏报、调太严延迟。

但PC_Workman的GitHub仓库显示，1.6.8版本发布后issue区最热的反馈是：「终于知道为什么我的风扇突然狂转了。」

没有用户问「能不能多加几行代码检测别人」，都在问「能不能把窗口延长到30分钟」——他们想要更懂自己的系统，不是更懂平均值的系统。

90行代码的启示或许在于：有些产品缺口不需要新技术，只需要承认「正常」是个动词，不是名词。

你的任务管理器上次给你讲清楚原因，是什么时候？