技能使用指南

free-weather-data（免费天气数据获取）Skill 是什么？如何下载？

免费天气数据获取技能Skill 基于 Open-Meteo 与 wttr.in，无需 API 密钥即可获取当前天气、7-16 天预报与历史气候数据。本文详解安装步骤、五大核心能力、竞品对比与真实应用场景，帮你零成本替代每月数十美元的付费天气接口，立即上手为 AI 代理接入天气能力。

免费天气数据获取技能Skillfree-weather-data
8 个章节 约 17 分钟阅读 AI 智能生成

免费天气数据获取技能Skill：零成本、免 API 密钥，让 AI 代理随时拿到靠谱天气数据

  • 完全免费且无需密钥：技能基于 Open-Meteo 与 wttr.in 两个免费服务构建，不需要注册账号、不需要生成 API 密钥，也没有强制计费门槛。
  • 三类数据一次覆盖：当前天气、未来 7–16 天预报（含逐小时）、1940 年至今的历史档案数据，都能通过同一套调用方式拿到。
  • 速率额度足够慷慨：Open-Meteo 每天可发起约 1 万次请求，wttr.in 基本不限次；对绝大多数 AI 代理场景完全够用。
  • 开箱即用：技能内置 5 个可直接调用的能力（当前天气、预报、极简查询、历史数据、天气代码解码），外加一套天气告警与监控模板，复制即可嵌入工作流。
  • 成本替代效果明显：按“AI 代理每月查询 1000 次天气”的场景估算，用免费方案替代 OpenWeatherMap 等付费服务，一年可省下约 180–600 美元（实际金额以官方说明与真实用量为准）。

该技能叫什么？如何下载安装 AI 技能提升开发效率？

技能基本信息

项目 内容
中文名 免费天气数据获取技能Skill
英文名 free-weather-data
技能 ID 13122
底层依赖 Open-Meteo（当前/预报/历史）、wttr.in（快速查询）

它解决什么问题

做 AI 代理或自动化脚本时，"查天气"看似简单，实际落地却有三道坎：

  1. 成本门槛：主流商业天气 API 按调用量计费，免费额度一超就要付费；
  2. 密钥管理：注册、生成 Key、配置环境变量、担心泄露，多一层工程负担；
  3. 隐私顾虑：部分服务会记录调用行为与位置信息。

这个技能直接把调用地址固定为公开的免费接口，用坐标或城市名即可查询，把"接入天气能力"从一个小项目压缩成一次工具调用。

一键安装的思路与步骤

  1. 确认安装前提：运行环境能够访问外网（需连通 Open-Meteo 与 wttr.in 的接口），并且具备发起 HTTP 请求的能力——命令行环境下有 curl（可选配 jq 做格式化），Node.js 环境下需支持 fetch（Node.js 18 及以上版本原生可用）。
  2. 找到技能入口：在所用 AI 技能平台/技能市场的搜索框中输入英文名 free-weather-data 或技能 ID 13122，在结果中找到对应技能。若使用支持本地技能目录的 AI 编程工具，也可以按平台约定把技能文件放入技能目录（具体目录路径与安装命令以官方说明为准）。
  3. 执行安装：点击"安装/添加"按钮完成安装；本地方式则按平台文档放入或链接技能文件（以官方说明为准）。
  4. 验证是否生效：安装完成后，直接用自然语言向 AI 提问，例如"帮我查一下纽约现在的天气，用华氏度"。如果 AI 正确返回温度、体感温度、湿度、风速等字段，说明技能已被识别并调用。也可以手动执行一次接口请求做交叉验证。
  5. 补充可选配置：如果你希望默认使用华氏度、默认带时区、或固定告警阈值，可以在提问时或技能配置中说明，避免每次重复描述。

该技能的主要功能和特点

核心功能

  • 获取当前天气（get_current_weather_open_meteo）：一次请求即可返回温度、体感温度、相对湿度、降水量、风速、风向、天气代码、观测时间与单位，是准确性与字段完整度最高的一路。
  • 获取天气预报（get_weather_forecast）：支持未来 7–16 天的日级预报（最高/最低温、降水量、降水概率、最大风速、天气代码），也支持未来 24 小时的逐小时预报。
  • 极简快速查询（get_weather_wttr_simple）：直接传城市名或"纬度,经度"，一行文本就能返回"城市：天气图标 + 温度"；需要结构化数据时加 ?format=j1 拿 JSON。
  • 历史天气查询（get_historical_weather）：按日期区间查询历史最高/最低温、降水量与天气代码，可用于气候分析、同期对比、平均值计算。
  • 天气代码解码（decode_weather_code）：把 Open-Meteo 返回的数字代码翻译成人类可读描述，如 0=晴朗、61=小雨、71=雪、95=雷暴。
  • 天气告警与监控（weather_alerts_and_monitoring）：内置阈值判断模板——最高温、最低温、最大风速、最大降水量四类条件，同时检查当前状况与未来 3 天预报，输出结构化告警列表。

差异化特点

  • 零密钥：这是它与绝大多数商业天气 API 最本质的区别，省去注册与密钥轮换的全部工程。
  • 开源可自托管：Open-Meteo 完全开源，对稳定性要求高的关键业务可以自行部署，摆脱对公共实例的依赖。
  • 隐私优先：官方描述为无跟踪、无数据收集，适合对位置数据敏感的团队。
  • 双源互补：需要精度与字段时用 Open-Meteo，需要"一句话播报"时用 wttr.in，一个技能覆盖两种典型用法。
  • 支持单位与时区：请求参数中加 temperature_unit=fahrenheit 即可切换华氏度（默认摄氏度）；指定 timezone 可让返回时间落在本地时区。
  • 输入方式灵活：既支持精确坐标，也支持城市名，方便在"有地理编码"和"没有地理编码"两种条件下都能跑通。

如何使用该技能？

第 1 步：确定查询方式

优先使用坐标（纬度、经度），比城市名更精确、歧义更少；如果拿不到坐标，wttr.in 支持直接传城市名。坐标合法性要求：纬度在 -90 到 90 之间，经度在 -180 到 180 之间。

第 2 步：查询当前天气

LAT=40.7128
LON=-74.0060

curl -s "https://api.open-meteo.com/v1/forecast?latitude=${LAT}&longitude=${LON}&current=temperature_2m,relative_humidity_2m,apparent_temperature,precipitation,weather_code,wind_speed_10m&temperature_unit=fahrenheit" \
  | jq '{temperature: .current.temperature_2m, feels_like: .current.apparent_temperature, humidity: .current.relative_humidity_2m, wind_speed: .current.wind_speed_10m, precipitation: .current.precipitation, weather_code: .current.weather_code}'

输入是坐标与所需字段，输出是一组扁平化的结构化数据，可直接喂给后续逻辑或直接念给人听。

第 3 步：查询预报

日级 7 天预报：把参数改为 daily=temperature_2m_max,temperature_2m_min,precipitation_sum,weather_code，并指定 timezone。逐小时预报则用 hourly=temperature_2m,precipitation,weather_code 搭配 forecast_days=1，返回当天 24 小时的温度与降水序列。

第 4 步：用 wttr.in 做极速查询

curl -s "https://wttr.in/London?format=3"
# 输出示例：London: ☀️ +22°C

curl -s "https://wttr.in/Tokyo?format=j1" | jq '.current_condition[0] | {temp_f: .temp_F, humidity: .humidity, description: .weatherDesc[0].value, wind_mph: .windspeedMiles}'

一行文本适合直接播报；JSON 格式适合要字段的场景，注意必须带 ?format=j1，否则会返回 HTML 页面。

第 5 步：查询历史数据

curl -s "https://archive-api.open-meteo.com/v1/archive?latitude=51.5074&longitude=-0.1278&start_date=2024-01-01&end_date=2024-01-31&daily=temperature_2m_max,temperature_2m_min,precipitation_sum"

日期格式必须是 YYYY-MM-DD，档案数据自 1940 年起可查。若想算某月均温，把返回的日均温数组求和再除以长度即可。

第 6 步：解码天气代码并设置告警

拿到天气代码后，用技能内置的映射表翻译成中文/英文描述再展示给用户。告警场景下，按"最高温 90°F、最低温 32°F、最大风速 25 mph、最大降水 1.5 英寸"这类阈值调用检查函数，返回结果会包含当前天气、未来 3 天预报、告警数组和 hasAlerts 布尔值，前端只需判断是否有告警即可。

第 7 步：做好缓存

官方建议缓存 15–30 分钟。天气本身每小时才更新一次，连续轮询既浪费额度也没有意义；同时建议给请求设置约 10 秒超时，避免接口抖动拖慢整个代理链路。

同类型竞品对比分析

方案名称 定位 核心功能 安装/使用门槛 适用场景 优势与不足
Open-Meteo（本技能主力） 开源免费天气数据接口 当前天气、逐小时与 7–16 天预报、1940 年起历史档案、多种气象参数 无需密钥，会用 curl 或 fetch 即可；每天约 1 万次请求 AI 代理决策、数据分析、批量查询、气候研究 优势：免费、无密钥、开源可自托管、字段全面；不足：天气代码需自行解码，告警逻辑要自己写阈值
wttr.in（本技能备用） 面向人类的极简天气服务 一行文本天气、详细文本报告、JSON 输出 一条 curl 即可，支持城市名 终端速查、聊天机器人播报、演示场景 优势：速度极快、零配置、基本不限次；不足：字段相对少、无历史数据、属社区服务，稳定性无正式 SLA
OpenWeatherMap 成熟商业天气 API 平台 当前天气、预报、历史、地图图层、官方告警 需注册账号并生成 API 密钥，免费额度约每分钟 60 次 生产级商业应用、需要官方告警能力的系统 优势：生态成熟、文档完善；不足：需密钥管理、免费额度有限、官方说明中存在调用跟踪，且高用量场景成本可达每月数十美元
WeatherAPI 商业天气 API 服务 当前天气、预报、天文与空气质量等扩展数据 需注册并配置密钥，免费额度约每月 100 万次 中小型应用、需要扩展气象字段的项目 优势：免费调用量较大、字段丰富；不足：仍需密钥与账号体系，隐私策略依赖服务方

一句话选择建议：只要不是必须依赖商业 SLA 或官方告警推送，Open-Meteo + wttr.in 的组合能覆盖 90% 以上的日常天气需求，且成本为零。

该技能的典型应用场景与实际体验情况

场景一：AI 代理的"出行前决策"

角色是行程规划助手或私人助理，痛点是用户在对话里问"明天下午去户外开会合适吗"，代理需要真实天气而不是幻觉。使用方式是先用地理编码或用户提供的坐标调用当前天气与预报，再把降水概率、体感温度、风速翻译成自然语言建议。实际体验：接口返回快、字段结构稳定，把数字代码解码后回复可读性很好。需要注意坐标必须合法，否则接口会直接报错；城市名建议先用地理编码转成坐标再查，准确度会明显提升。

场景二：农业、物联网与设施运维的天气监控

角色是运维工程师或农场管理者，痛点是"高温、大风、暴雨"这类事件需要提前预警，而商业告警服务要额外付费。使用方式是复用技能自带的告警模板，设定最高温、最低温、最大风速、最大降水量阈值，定时检查并输出告警数组，再配合邮件或即时通讯工具推送。实际体验：告警逻辑开箱即用，改造空间大；但一定要控制轮询频率——天气每小时才更新，按分钟级轮询纯属浪费额度。

场景三：数据分析师的气候与同期对比分析

角色是数据分析师或研究人员，痛点是想要某地某月的温度、降水趋势，商业 API 的历史数据往往要单独付费。使用方式是调用历史档案接口，指定起止日期与需要的日级字段，返回数组后直接做均值、极值、同比分析。实际体验：历史数据从 1940 年起可查，覆盖度好；需要注意的是格式必须严格为 YYYY-MM-DD，且个别坐标可能因气象站覆盖不足而返回空值，此时可换用附近坐标重试。

场景四：聊天机器人与群内的"一句话天气播报"

角色是社群运营或客服机器人开发者，痛点是播报要快、要短、要好看。使用方式是调用 wttr.in 的 format=3，直接拿到"城市：图标 + 温度"的一行结果，塞进消息模板即可。实际体验：上手难度几乎为零，开发到上线只需几分钟；注意必须加 ?format=j1 才返回 JSON，不加会拿到 HTML 页面导致解析失败。

该技能能为用户带来的价值

直接的效率提升：原本接入一个天气 API 需要"选服务商 → 注册 → 生成密钥 → 配环境变量 → 写请求 → 处理错误码"六个步骤，现在压缩为"安装技能 → 直接提问或调用"两步。对个人开发者，从想法到跑通的时间可以缩短到分钟级。

明确的成本节约：按官方给出的参考场景——AI 代理每月查询 1000 次天气——使用 OpenWeatherMap 这类服务可能产生每月 15–50 美元的支出，而本技能的成本为 0，一年可省下约 180–600 美元；用量越大，差距越明显。

降低的技术门槛：无需密钥管理意味着没有"密钥泄露"和"密钥到期"这两类常见线上事故；无跟踪、无数据收集的定位，也让对位置隐私敏感的项目可以放心接入。

长期可维护性：Open-Meteo 完全开源且支持自托管，意味着这条链路不会被单一商业服务的涨价或限量策略绑架；关键业务需要更强稳定性时，平滑迁移到自建实例即可，接口风格保持一致，改造成本低。

能力边界的延展：技能文档中还给出了与地理编码、邮件通知、Telegram 机器人等技能的组合用法——先用地理编码把地址转成坐标，查完天气后通过邮件或 Telegram 推送告警，就能在几乎零成本的前提下搭出一条完整的"位置 → 天气 → 通知"自动化流水线。

常见问题 FAQ

Q1：这个技能怎么安装？需要在代码里写什么吗？

在 AI 技能平台搜索英文名 free-weather-data 或技能 ID 13122 即可找到并安装（具体入口与本地安装路径以官方说明为准）。安装后通常不需要写代码——直接用自然语言提问即可触发；如果需要精确控制单位、时区或字段，可以在提问中说明，或按文档中的请求示例手动调用接口。

Q2：真的完全免费吗？会不会有隐藏收费？

技能本身依赖的是 Open-Meteo 与 wttr.in 两个免费服务，官方描述为无需 API 密钥、100% 免费。使用时仍建议遵守合理使用原则：Open-Meteo 每天约 1 万次请求，wttr.in 作为社区服务不限次但需合理调用。具体条款与额度变化请以官方说明为准。

Q3：它和 OpenWeatherMap 这类商业 API 该怎么选？

如果你只需要"拿到天气、拿到预报、拿到历史数据"并自己控制业务逻辑，免费方案完全够用，还省掉密钥与费用；如果你依赖服务商提供的官方气象告警推送、地图图层或带 SLA 的商业支持，那么商业 API 仍有价值。很多团队的做法是：日常查询走免费方案，只有极端天气官方告警这类强合规需求才接入商业服务。

Q4：适合谁用？

最适合三类人：一是构建 AI 代理/自动化工作流的开发者，需要让代理基于真实天气做决策；二是做数据分析和气候研究的同学，需要低成本拉取历史天气序列；三是个人开发者与小团队，希望用零成本方案快速验证产品想法。完全不懂编程的用户也能通过自然语言提问的方式使用基础查询能力。

Q5：查不到数据或结果异常怎么办？

常见原因有四种：坐标超出合法范围（纬度应在 -90 到 90，经度应在 -180 到 180）；该位置气象站覆盖不足导致返回空值，可换附近坐标重试；历史查询日期格式不是 YYYY-MM-DD，或日期早于 1940 年；温度单位混淆——Open-Meteo 默认摄氏度，要华氏度需显式加 temperature_unit=fahrenheit。另外，wttr.in 如果返回的是 HTML 而不是 JSON，通常是漏了 ?format=j1 参数。