天气机器人能回复一条温度，并不表示它查对了地点、时间和单位。对旅行群或日常查询工具来说，“查到了另一个同名城市”和“把昨天缓存的数据当成现在”都可能比明确报错更难发现。
真实委托也提出过这类可靠性问题。Freelancer 的 Optimize & Expand Telegram Weather Bot 希望改进一个读取 JSON 天气数据的群机器人，减少失败请求带来的问题；Customized Telegram Bot 则提到天气等外部 API、用户数据保存和后续修改。2026 年 11 月 9 日核查时，前者页面显示 In Progress 且已授标，后者显示 Completed；绝对发布日期均未核实。这些是历史需求证据，不是当前接单机会，也不是本站的交付案例。
下面将“可靠地查询天气”具体化。地点消歧、缓存期限与测试阈值是本文提出的设计建议，不是上述客户已经规定的全部验收条件。
先确认查的是哪个地点
第一版可以只接受城市名，不必一开始就收集精确位置。输入“Paris”后，若有多个匹配，先展示城市、行政区和国家供用户确认，不要直接把搜索结果第一项设为永久默认。没有结果时提示补充地区，不猜测一个看起来相近的城市。
Open-Meteo 地理编码文档说明，地点搜索可返回多个结果，包括坐标、国家、行政区及时间区域；还可按国家筛选。因此，显示名称应便于人辨认，而保存的地点需要足够明确，例如供应商地点标识及坐标，不能只有用户最初输入的字符串。该服务只是本文的文档示例，不代表任何被提及机器人采用它。
可以把流程写成：搜索地点 → 用户确认 → 查询天气 → 用户另外选择是否保存默认地点。临时查询别处不自动覆盖默认城市；取消选择也不写入记录。群中展示的地点应跟随当前请求，不能由最后一位发言者的偏好决定所有人的结果。
分开显示数据有效时间和查询时间
“刚刚回复”只能说明消息刚发出。建议给结果定义至少三个时间字段：
- 天气有效时间或预报时段：这条温度或降雨信息描述的时刻、小时或日期。
- 成功取回时间：机器人何时取得这份数据，用于判断本地缓存年龄。
- 本次回复时间：何时将结果发给用户，不能冒充上游数据的更新时间。
Open-Meteo 天气预报文档将 current.time 定义为数据有效时刻，当前条件来自天气模型数据。它不是对用户所在位置的现场测量保证；generationtime_ms 是生成响应的耗时，也不是数据时间戳。
当用户问“明天”时，先用所选地点的时间区域确定日期，并在答案中输出明确日期。不要沿用服务器日期或 Telegram 界面语言推断所在地。若扩展跨夏令时的逐小时预报，还应核查供应商返回时间的具体语义，避免用固定偏移假装所有小时都具有相同当地时间规则。
这与定时通知的发送时区是不同问题：这里要验收的是天气数据描述哪个时间，不是几点推送消息。
让单位、缺失值和缓存都有可观察的结果
先确定回复中的温度、风速和降水使用什么单位；切换单位后，数值与标签必须一起改变。Open-Meteo 文档提供温度、风速和降水单位选项，返回结果也包含单位信息。接入其他供应商时重新核对，不能沿用这份字段约定。
建议把结果区分为“成功”“暂用缓存”“没有可用结果”，并明确以下规则：
- 数字零是合法数值；字段缺失、空值或类型错误不能都转换为零。没有降雨信息不等于预报无雨。
- 缓存键至少区分地点、数据种类或预报时段、单位及数据源。查询另一个城市时，不能拿旧城市的结果填补失败。
- 分别规定缓存可复用多久、失败时是否允许返回旧值、超过多久必须拒绝展示。具体期限由用途和上游更新频率决定，没有通用的“实时”阈值。
- 使用旧值时标明缓存状态、天气有效时间和成功取回时间。失败请求不能刷新缓存的成功时间。
- 即使请求成功，也要检查数据是否覆盖所问的时刻或预报日期。先约定“当前条件”允许滞后多久；刚取回但有效时间已超限的数据，不能当成当前天气。缓存年龄与天气数据年龄要分别验收。
如果项目只想先确认交互，可以用明确标为模拟的数据测试这些分支。模拟结果通过不等于天气源已接通。
一段可以交给 AI 或外包开发者的需求
以下是可编辑的假设方案，指令名和数值不代表产品现成配置：
创建按城市查询天气的 Telegram 机器人。第一版只做按需查询，不做定时推送、摄像头接入或运行时 AI 建议。城市有多个匹配时先让用户确认国家和地区；临时查询不覆盖已保存默认地点。每条结果展示地点、数据种类、天气有效时间及时间区域、单位、来源和成功取回时间。将缺失值与零分开处理。测试版本可复用 10 分钟内的成功缓存；上游失败时，仅允许显示取回不超过 30 分钟且明确标为缓存的同地点同类型同单位结果，否则告知暂时不可用。失败不得更新成功时间。先使用带模拟标记的固定数据完成交互验收，再单独核验天气服务授权、网络请求、密钥保存和实际数据。发布前列出未支持项。
10 分钟和 30 分钟只是这份测试方案的约定，不是天气准确度保证或供应商更新承诺。若用途变成高频气象监测，应重新设计数据源、刷新与可靠性要求。
用具体输入和故障验收
不要只拿一个城市试一次。至少保留以下可重复样例：
- 同名与无匹配：两个同名城市的选择分别得到对应结果；无匹配时不保存猜测地点。
- 地点切换：用户 A 查询地点甲、用户 B 查询地点乙后，A 的结果和偏好仍指向甲。
- 跨午夜：查询地点已进入第二天、服务器尚未跨日时，“明天”对应地点当地的下一日期。
- 单位切换：同一测试数据改变展示单位后，数值转换、标签和缓存选择保持一致。
- 零与空值：模拟零度能正常展示；缺少温度时输出未知，不补成零度。
- 失败与过期：先成功取回，再分别注入超时、错误响应、缺字段和超过缓存期限，检查三个结果状态及时间字段。另测 HTTP 成功但天气有效时间超限、预报日期不符的响应。
- 恢复：上游恢复后新数据替换旧缓存，回复不再沿用过期标记；重复失败不会让旧值看起来更新。
这些样例是待执行的验收清单。本文没有部署机器人，也没有实测任何产品 Demo 的查询行为。
BotFatherV2 适合哪一步，哪些需要另外确认
BotFatherV2 可用 AI 对话创建和修改 Telegram 机器人，并提供版本发布、已有 Telegram Serverless 机器人导入及保留当前业务数据的代码回滚。其公开首页目前展示了天气查询作品，但作品展示不能证明某个天气供应商、授权套餐或任意外部集成都已支持。
直接相关的是把需求整理为交互、按用户保存偏好和可检查的版本；上面的方案可以作为讨论起点。完整天气查询仍部分匹配、需要逐项核验接入：天气供应商 API、当前 SDK 的网络调用能力、密钥管理、调用限制及运行成本。固定 SDK 范围不支持任意 npm 模块或 Node/Bun API；现有 Python 机器人与摄像头程序不能直接作为 Serverless 源码导入。AI 辅助开发也不表示上线机器人已有付费模型调用或自主气象分析能力。
选用 Open-Meteo 时，其价格与授权说明区分非商业免费 API 与具有商业使用许可的客户服务，数据还需适当署名。不要把“可查看公开文档”理解为“任何商业机器人都可免费运行”，外部服务费用也不能算进机器人构建套餐。
下一步可先提交范围有限的需求，要求 AI 列出当前不能验证的接入项；如果必须沿用 Python、私有 JSON 文件或摄像头，先评估定制开发。BotFatherV2 是独立产品，与 Telegram 官方 BotFather 无隶属关系。
来源与核查日期
统一核查日期：2026 年 11 月 9 日。文档未标注的发布日期不作推断；API 与产品能力后续以最新公开说明为准。
- Freelancer：Optimize & Expand Telegram Weather Bot，项目 38980643，英文历史委托，页面显示发布逾一年、In Progress、已授标。
- Freelancer：Customized Telegram Bot，项目 40293464，英文历史委托，页面显示发布约三个月、Completed。
- Open-Meteo：Geocoding API、Weather Forecast API、Pricing，方案事实和外部服务边界证据。
- BotFatherV2：产品页、使用 AI 开发、导入已有机器人，产品能力证据。