Weather 1.0.0

核心用法

wttr.in（主推）：基于 curl 的终端天气服务，无需注册或 API 密钥。支持多格式输出：

• 极简一行：?format=3 返回「城市: 图标+温度」
• 自定义模板：%c（天气状况）、%t（温度）、%h（湿度）、%w（风速）、%l（地点）、%m（月相）自由组合
• 完整预报：?T 输出 ASCII 艺术风格的多日预报
• 机场代码直查（如 JFK）、单位切换（?m 公制/?u 英制）、PNG 图片导出

Open-Meteo（备选）：结构化 JSON API，适合程序化解析。需先获取经纬度，返回包含温度、风速、天气代码的标准化数据。

显著优点

• 零配置成本：无需注册账号、申请密钥或处理配额限制
• 终端原生友好：wttr.in 的 ASCII 输出完美适配命令行工作流
• 灵活性高：格式字符串与单位参数满足多样化需求
• 双服务冗余：wttr.in 与 Open-Meteo 互为 fallback，提升可靠性

潜在缺点与局限性

• 网络依赖：完全依赖外部服务可用性，离线场景无法使用
• 精度限制：wttr.in 基于公开气象数据源，局部微气候（如山谷、高楼间）可能偏差
• Open-Meteo 前置步骤：需先解析城市坐标，无法像 wttr.in 直接用地名
• 无历史数据：仅支持当前及预报，不提供过去天气查询

适合人群

• 开发者/运维人员：快速集成至 CI/CD 通知、服务器状态脚本
• 终端重度用户：追求极简工作流，拒绝图形界面
• IoT/边缘设备：低资源占用，curl 即可运行
• 临时需求者：偶尔查天气，不愿为低频使用注册 API

常规风险

• 隐私泄露：查询时 IP 与位置信息暴露给第三方服务（wttr.in/Open-Meteo）
• 服务稳定性：免费服务无 SLA 保障，大规模生产环境建议监控并做好降级方案
• URL 注入：若动态拼接城市名，需确保对空格等特殊字符进行 URL 编码
• 依赖项：需预装 curl，部分精简容器环境可能缺失

核心用法

该Skill为纯文档型命令集合，提供两种免API密钥的天气查询方案：

方案一：wttr.in（推荐终端使用）

• 极简当前天气：curl -s "wttr.in/城市?format=3"
• 自定义字段：%c天气图标、%t温度、%h湿度、%w风速、%l地点、%m月相
• 完整预报：curl -s "wttr.in/城市?T"
• 支持机场代码（如JFK）、URL编码城市名（New+York）、单位切换（?m公制/?u英制）、PNG图片输出

方案二：Open-Meteo（推荐程序化调用）

• 返回结构化JSON，含温度、风速、天气代码
• 需先获取目标经纬度，适合脚本集成

显著优点

| 维度 | 亮点 |

|------|------|

| **零门槛** | 无需注册、无API密钥、无调用限额 |

| **全球覆盖** | wttr.in支持任意城市名+机场代码，Open-Meteo覆盖全球坐标 |

| **格式灵活** | 从1行极简到多格式PNG，适配终端/脚本/可视化 |

| **安全透明** | 纯文档无代码，S+认证，无数据收集无权限请求 |

| **生态成熟** | wttr.in为GitHub万星项目，Open-Meteo由瑞士气象专业团队维护 |

局限性与风险

| 类型 | 说明 |

|------|------|

| **可靠性** | 免费服务无SLA保障，高峰期可能延迟或限流 |

| **精度边界** | wttr.in基于开源气象数据，专业场景需对比权威源 |

| **网络依赖** | 必须联网，内网/离线环境不可用 |

| **坐标门槛** | Open-Meteo需手动查经纬度，城市名不友好 |

| **长期维护** | 来源T3级别，个人开发者维护，版本延续性无保障 |

适合人群

• 终端爱好者：快速在shell/PowerShell查看天气
• 脚本开发者：零成本为自动化流程添加天气节点
• 隐私敏感用户：拒绝安装APP、拒绝位置权限、拒绝账户体系
• 教育演示：展示curl/HTTP API/JSON解析的基础案例

常规风险提示

• 频繁请求可能被服务端限速，建议缓存结果
• 生产系统应准备降级方案（备用API或超时处理）
• 坐标查询建议使用独立地理位置服务补全