北京
在深圳的一扇窗前，我放了一台相机，连续记录了30天。1,072条观测数据，从文件大小到像素亮度，从红外模式到色温偏差，我试图用算法理解窗外的世界。
结果发现了三个盲区。不是设备故障，不是代码bug，而是测量本身在说谎。
第一层陷阱：文件大小≠亮度
我的第一个假设很简单：JPEG文件越大，画面越亮。晴天细节多，文件膨胀；阴天灰蒙蒙，文件瘦小。白天验证时，这个逻辑完美成立。
直到 dusk 降临。同一时刻、同一场景，两个工具给出截然相反的结论：
Zig工具：亮度值141，判定"多数晴朗"，文件54KB
Python工具：亮度值83，判定"昏暗多云"，基于像素级RGB计算
同一张照片，两种现实。
问题出在相关性≠因果性。文件大小反映的是JPEG压缩复杂度，而非物理亮度。白天阳光创造细节，复杂度与亮度同步上升；黄昏时复杂度来源变了——残余天光、城市灯火、云层纹理——54KB在正午意味着"多云"，在19:00意味着"黑暗"。同一个数字，相反的含义。
修复方案：切到像素级RGB灰度计算（0.299R + 0.587G + 0.114B）。两个工具终于达成一致。
但我能发现这个漏洞，纯粹因为有两套独立测量。如果只有一套，我会永远被蒙在鼓里。
第二层陷阱：看不见的模式切换
追查文件大小异常时，我发现了更隐蔽的问题。5月9日至12日，相机卡在了红外夜视模式。
证据来自文件体积的断崖：
正常白天：45KB
红外白天：7.8KB（缩小6倍）
正常夜晚：50KB
红外夜晚：15KB（缩小3倍）
最阴险的是：像素亮度看起来完全正常。红外LED均匀照亮场景，平均RGB值维持在常规区间。文件大小暴露了模式切换，亮度指标却毫无察觉。
1,072条记录中，66条（6.2%）已被污染。所有包含这日期的分析都带上了我至今才知晓的偏差。
现在系统增加了红外检测逻辑：白天子流文件低于20KB、夜间低于15KB时，标记ir_mode: true。历史数据已全部补标签。
第三层陷阱：色温分不清雨和暖
我尝试用R−B（红通道减蓝通道）作为色温代理。物理基础扎实：暖光偏红，冷光偏蓝。
夜间R−B始终为正（均值+5.9），城市灯光确实偏暖。合理。
4月30日雷暴夜，R−B从+7跳至+13。兴奋：这能预测降雨？
验证结果：雨前样本均值+5.7，平静样本均值+5.1，差值仅+0.6。信噪比小于1。这个维度无法区分天气信号与环境暖度。
它不是错的——确实测量了真实存在的物理量。它只是没测量我想要的那个量。
结构复盘
三次失败共享同一骨架：
文件大小→亮度：白天有效，黄昏/夜间失效
红外模式：可通过文件阈值检测，但传感器本身可能损坏
红蓝差值→天气：夜间恒正，信噪比不足以预测
每个测量工具都有有效域。跨出边界，数字仍在输出，意义已经漂移。
30天1,072条数据教会我：完整的感官数据集是个幻觉。真正的完整，是知道哪里不完整。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
