温度为什么被 AI 改了？

InkFeed 的一轮天气调试里，屏幕上的大字温度、当天温度区间和生活提醒没有对齐：有的数字不一致，第三行又重复了温度。电子纸已经把它们画出来，问题却不一定发生在绘制时。要找到原因，得从显示结果往回追到每个字段的来源。

2026 年 6 月 9 日的开发日志留下了这次处理。工程从 Open-Meteo 获取天气数值，再让 DeepSeek 整理摘要。两路结果写入同一份天气结构，生成响应中的 today_high / today_low 曾覆盖已取得的温度，today_summary 也带回了重复数字。

先找到谁写过这个字段。

最初看见不一致，很容易先改布局或提示词。但布局只决定文字出现在哪里，提示词也不能构成可靠的写入约束。真正需要明确的是：哪一路负责温度，哪一路负责措辞，以及后到达的响应是否有权改掉前面的结果。

当前 parse_weather 在 Open-Meteo 数据有效时保存温度，只接受生成摘要，过滤摘要里的温度片段，再恢复原有数值。它把一次覆盖问题收束到解析边界，UI 不必再猜屏幕里两组数字应该相信哪一组。

让写入边界出现在代码里。

下面把关键关系压缩成一个函数。它是根据问题整理的 JavaScript 教学示意，不是原样固件，也不能直接烧录；摘要清理、网络错误与存储流程都省略了。示例只说明有效来源存在时，生成文本不应拥有数值字段的覆盖权。

// 整理示意，非原样固件；不访问设备或网络。
function mergeWeather(provider, generated) {
  if (!provider.valid) return { state: 'needs-fallback' };
  return {
    state: 'ready',
    high: provider.high,
    low: provider.low,
    summary: generated.cleanedSummary ?? provider.summary,
  };
}

先给字段分配可信来源，再给句子安排表达空间。

写给实践时的自己

相似的画面，可能来自不同的错误。

同一轮还出现了“9 看起来像 0”。日志指向 gui_paint.c：数字 9 的字体位图与 0 重复。这个问题属于字形资源，和天气字段覆盖是两回事。若把所有异常都归到模型响应上，修好数据后仍会留下错误画面。

UI_WEATHER 与 LINE2 日志帮助比较绘制前的数据：如果进入 UI 的数值已经不对，就继续查解析与合并；如果数值正确但字形不对，就检查排版和字体。日志最有用的位置，往往是两个模块交接的地方，而不是每个循环都重复打印最终一句话。

• 数据层：记录来源、有效状态与数值。
• 解析层：记录哪些字段被接受、哪些保留。
• UI 层：比较收到的数值与最终文字。
• 资源层：用固定数字样例检查字形。

修复之后，还要读清回退分支。

当前源码在 Open-Meteo 失败时仍有生成天气数据的回退分支，因此不能把这次修正写成“模型永远无法提供温度”。已有处理解决的是有效来源被覆盖；来源失败后的可信度、标记和展示方式，仍值得继续完善。

这篇记录依据现有源码与历史日志整理，没有重新运行天气请求或刷新测试。它留下的方法是把现象拆开：先核对数据，再核对显示，最后把来源和错误状态交代给读者。屏幕只容纳几行文字，背后的责任边界反而要更清楚。