核心用法
本技能提供两套互补的天气查询方案，均无需注册或API密钥：
wttr.in（主要方案）：专为终端设计的可视化天气服务，支持多种输出格式。基础用法为 curl wttr.in/城市名，可通过URL参数精确控制输出内容——?format=3 返回极简单行结果（如"London: ⛅️ +8°C"），?T 输出ASCII艺术风格的多日预报。支持机场代码（如JFK）、空格转义（New+York）、单位切换（metric/USCS）及PNG图片导出。
Open-Meteo（备用方案）：面向程序化使用的JSON API，需先获取城市经纬度坐标，返回包含温度、风速、天气代码的结构化数据，适合需要解析处理的自动化场景。
显著优点
- 零配置成本：无需注册、无API额度限制、无密钥管理负担
- 终端原生体验：wttr.in的ASCII艺术输出专为命令行优化，信息密度高
- 灵活性极强：从极简单行到完整预报，从文本到图片，覆盖多样需求
- 全球覆盖：支持城市名、机场代码、坐标三种定位方式
- 开源可审计：服务代码公开，数据流向透明
潜在缺点与局限性
- 服务依赖性：wttr.in为个人维护项目（igor.chubin），虽运行多年但无SLA保障；Open-Meteo为学术/社区项目，稳定性同样受限
- 无商业支持：故障时无客服渠道，依赖社区修复
- 精度边界：数据来源为公开气象模型，局部微气候（如山谷、城市热岛）可能偏差
- 频率限制：虽未明示，但高频批量请求可能触发隐性限流
- 坐标查找成本：Open-Meteo方案需前置步骤获取经纬度
适合人群
- 开发者/DevOps工程师：服务器状态监控、CI/CD流水线环境检查
- 效率工具爱好者：快速终端查询，无需打开浏览器或手机App
- 自动化脚本编写者：无密钥设计大幅降低脚本维护复杂度
- 隐私敏感用户：无需向商业服务提交个人信息或位置授权
常规风险
- 网络层风险：curl请求暴露源IP至第三方服务（wttr.in/Open-Meteo服务器）
- 注入风险：城市名若来自不可信输入，需确保URL编码（如空格转+），否则可能引发参数篡改
- 可用性风险：服务单方面变更接口或停止运营时，依赖该技能的脚本将失效
- 数据时效性：预报数据非实时观测，极端天气场景下更新延迟可能影响决策