用Claude Code打造定时天气提醒机器人：AI编程实践指南

前阵子我给自己做了个“今日天气提醒”机器人，每天早上8点准时把当天的温度、降水、风力，以及“要不要带伞、怎么穿衣服”的结论推送到工作群。这个项目本身不大，真正让我想写篇文章的，是背后那套开发方式：我几乎全程用Claude Code在命令行里完成了从需求梳理、代码编写、调试到部署的所有工作。整个过程让我直观体验到AI编程助手对开发工作流的重塑——不是说它替我写了多少行代码，而是它改变了我和代码之间的对话方式。如果你也好奇Claude Code怎么用、能干什么，或者只想快速做出一个有用的定时任务机器人，这篇文章都值得看完。

1. 先别急着写代码：把需求拆到能直接交给AI的程度

1.1 这个机器人到底要解决什么痛点

每天早上查天气这个动作，看起来很小，但累积起来非常耗时：打开天气App，看实时温度，再看预报，心里换算一下体感，想想要不要带伞，翻一下风力，最后还要纠结穿什么。这些信息分散在不同界面，查完基本一分钟就过去了。如果遇到天气突变，起晚了出门才发现下着雨，更是狼狈。

所以我的需求很明确：每天早上定时获取指定城市的天气数据，自动判断今天是否需要带伞、加衣、防风，然后把结论推到工作群。群推送的好处是手机一定会响，不需要额外装App，家人同事看到也能搭句话。需求里还可以配置多个城市，这样出差前看看目的地天气也方便。

1.2 需求清单与交付标准

在把任务交给AI之前，我习惯先写成一条条可验收的需求。这一步非常重要，因为无论你用的是Claude Code还是其他AI助手，输入的需求越具体，产出的代码越接近预期。我的清单是这样的：

• 支持通过环境变量配置城市、API Key、Webhook地址，不放散到代码里
• 每天执行一次，时间可配，默认早上8点
• 采集内容：当前温度、体感温度、天气现象、湿度、风速、最高/最低温
• 提醒规则：温度低于5度提醒保暖；天气现象含雨雪提醒带伞；风速大于8m/s提醒防风；昼夜温差大于10度提醒叠穿
• 推送渠道：企业微信群机器人Webhook，消息格式用纯文本
• 运行环境：Node.js，只使用底层原生能力，不引入重型框架

写完这份清单，我基本不需要再手动画流程图了，AI能根据这些规则直接脑补出完整逻辑。实际经验是：你给AI的任务描述越像“给新同事的交接文档”，它产出的东西越靠谱。

1.3 技术选型：为什么是这些而不是那些

天气数据源我对比过几个。OpenWeatherMap接口最简单，注册就能拿Key，免费额度对个人机器人完全够用，全球城市都覆盖；和风天气的中文文案和国内城市数据做得更细，但接口字段相对多一些；高德天气则适合本来就在用高德开放平台的场景。我最后选了OpenWeatherMap，理由很直接：个人项目最重要的是快速跑通，接口的URL短、字段稳定、文档清晰，让AI生成代码时也不容易出现歧义。

推送渠道的选择也讲究。邮件最简单，但手机推送不即时；Telegram Bot我直接放弃，因为要额外维护客户端，同事也不一定装了App；企业微信群机器人和钉钉机器人都是填一个Webhook地址就能推送，手机端必达，零部署成本。如果你不想用群，也可以考虑PushDeer或Server酱这类免费推送服务，原理都一样，就是给一个可POST的URL。

提示：如果只是“今天有没有雨”这种提醒，实时天气接口就够用；但如果想提前一晚知道明天天气，就需要用预报类接口，比如One Call API或5日预报，别用错了数据源。

2. Claude Code到底强在哪：我对它的理解

2.1 它不是一个聊天窗口，而是长在终端里的编程搭档

Claude Code是Anthropic推出的AI编程命令行工具，形式上就是一个终端命令claude。但它跟你在网页聊天框里让AI写段代码完全不一样：它默认就能读取当前目录下的整个项目，可以自己打开文件、修改代码、执行shell命令、跑测试，还能在Git提交前帮你过一遍改动。换句话说，它不只是“给代码建议”，而是可以直接把事情做完。

这个定位上的差异，对开发工作流的改变是根本性的。以前我写工具脚本，要自己在编辑器里折腾半天；现在在项目目录里敲一下claude，把需求说清楚，它会自己创建文件夹、初始化package.json、写代码、装依赖，甚至跑一遍给你看结果。我只需要在关键节点上叫停、review、修改需求。

2.2 和传统AI编程助手的区别

很多人用过IDE里的代码补全插件，或者网页端的AI对话。Claude Code和它们最大的区别有三点。

第一，它具备完整的Agent能力。它不只是生成一段代码片段，而是能像人一样做任务拆解：先读取项目结构，再逐个文件修改，遇到报错自己去看日志、查原因、修复。这个“能自己动手”的能力，让它从“代码生成器”变成了“可协作的工程师”。

第二，它拥有很长的上下文窗口。在一个规模不小的项目里，连续对话一两个小时，它依然记得之前的决定。我实测过，让Claude Code帮我重构一个小型服务，整个过程涉及十几个文件的修改，对话跨度很长，它始终没丢上下文。如果是普通聊天框，早就忘光前面的指令了。

第三，它支持规则与技能沉淀。项目根目录的CLAUDE.md相当于“团队协作规范”，Claude Code每次启动都会读取，你可以把代码风格、禁用第三方库、测试要求写进去。如果你经常做某类任务，还可以把经验做成Skills技能包，让AI在同类任务里自动调用。这些机制非常符合工程团队的长期协作逻辑。

2.3 谁适合用Claude Code

如果你已经有编程基础，尤其是习惯用终端的人，适应成本很低，装上就能用。如果你只是会写一点Python或脚本，Claude Code也能帮你完成很多脚手架工作，通过“提需求”代替“逐行写代码”。

但如果你完全没学过编程，连文件路径、环境变量、命令行这些概念都不清楚，我建议还是先补点基础，否则遇到报错时，你很难判断AI给出的修复方案是否合理。AI编程助手不是魔法，它帮你把“从0到1”的时间缩短，但“验证、决策、兜底”这件事，最后还是得靠人。

3. 安装配置实操：从零到能跑起来

3.1 前置依赖准备

安装Claude Code之前，机器上需要有Node.js。它目前是作为一个npm全局包来分发的，版本要求Node 18以上。我自己用的是Node 20 LTS，如果你之前装过旧版本，建议先升级。

在Ubuntu这类Linux系统上，我强烈建议用nvm来管理Node版本。直接用apt安装的Node版本往往偏旧，而且全局npm包装到系统目录时经常遇到权限问题。nvm装好之后，node、npm、npx都在用户目录里，后面安装全局包不容易踩EACCES的坑。Windows用户建议启用WSL，在WSL里走同样的流程，CLI体验会更稳定。

3.2 安装步骤与验证

安装命令只有一条：

npm install -g @anthropic-ai/claude-code

安装完成后先确认版本：

claude --version

能看到版本号，说明装好了。首次运行需要认证，推荐直接用环境变量设置API Key：

export ANTHROPIC_API_KEY=你的APIKey

然后运行：

claude

如果是第一次进入，它会要求你同意交互协议，之后就可以直接用自然语言下指令了。验证一下能不能正常工作，可以输入一句最简单的需求：

请用一句话说明你的身份和当前目录结构。

看到它正确回答，说明整个链路已经通了。这里有两个细节：第一，我习惯把API Key写入用户目录下的.bashrc或.zshrc，而不是每次手动export，省得终端一关就失效；第二，安装后的配置和日志默认存放在~/.claude目录，如果遇到异常，可以看看里面的日志来定位问题。如果你偏爱图形界面，也可以下载官方桌面版配合使用，但核心交互依然在CLI里。

3.3 VS Code集成配置

虽然Claude Code本身是命令行工具，但在VS Code里用顺手，效率会再上一个台阶。官方推荐的做法是安装VS Code的Claude Code扩展，直接在VS Code内置终端里启动claude。这样做的好处是，AI能直接看到你的工作区文件，你也能边看编辑器边和AI交互。

安装方式很简单：打开VS Code的扩展面板，搜索“Claude Code”，找到官方扩展安装即可。装完之后，在项目根目录打开VS Code，用快捷键调出内置终端，输入claude回车。这样每次对话都不用手动描述项目背景，Claude Code会自动读取工作区上下文。

有一点要提醒：如果你需要Claude Code读写工作区里的文件，必须在项目目录下启动它，而不是在任意目录下启动。在错误位置启动，它会读不到项目文件，生成的代码也容易放错地方。

3.4 在Ubuntu下的安装要点

Ubuntu的安装流程和上面基本一致，但有三个坑值得单独说出来。

第一，不要用sudo npm install -g。很多教程让你加sudo，但Claude Code安装后会尝试写配置文件，sudo安装的包权限不足时反而会在运行时出现各种奇怪问题。正确做法是先用nvm装Node，再正常全局安装。

第二，终端里command not found: claude大概率是npm的bin目录不在PATH里。用nvm装node后，把nvm初始化脚本写入.bashrc，重新打开终端即可。

第三，如果你所在网络环境下安装npm包速度很慢，可以给npm配置镜像源，比如：

npm config set registry https://registry.npmmirror.com

改完镜像源后重新安装，速度会有明显改善。如果你在公司内网环境，也可以用内部npm镜像，原理一样。

4. 天气机器人完整开发过程：每一个关键决策

4.1 天气数据源与API Key申请

最终选用OpenWeatherMap后，第一步是注册账号并创建API Key。打开官网注册，登录后在API Keys页面新建一个Key，免费版就够用。个人机器人每天才调用两三次，配额完全不是瓶颈。Key创建后建议立即复制存好，放到环境变量里，不要写进代码。

申请完可以先在终端里用一条curl验证接口是否通：

curl "https://api.openweathermap.org/data/2.5/weather?q=Shanghai&appid=你的KEY&units=metric&lang=zh_cn"

能返回JSON就说明数据源没问题。这个习惯建议保留：先把外部依赖验证通过，再让AI写业务代码，否则后面排查时容易分不清到底是代码bug还是接口key的问题。

4.2 用Claude Code生成核心代码

首先创建项目目录：

mkdir weather-bot && cd weather-bot

然后启动claude，把需求粘贴进去。这里给出我的完整prompt模板：

帮我在当前目录创建一个天气提醒机器人项目，使用Node.js原生能力。 要求： 1. 通过环境变量读取 WEATHER_API_KEY、CITY、WEBHOOK_URL 2. 调用OpenWeatherMap的实时天气接口，返回城市当前温度、体感温度、天气现象、湿度、风速、最高最低温 3. 根据以下规则生成提醒建议：温度低于5度提醒保暖；天气现象含雨或雪提醒带伞；风速大于8m/s提醒防风；昼夜温差大于10度提醒叠穿 4. 将提醒文案通过POST JSON的方式发送到WEBHOOK_URL，使用企业微信群机器人文本消息格式 5. 只输出核心代码文件index.js和README.md 先给出你的实现方案，等我确认后再写代码。

这里有个操作心得：我特意加了“先给出实现方案，等我确认后再写代码”这句话。因为对于这种需求，AI直接开写通常会选它自己最熟悉的依赖和结构，不一定符合你的预期。先让它出方案，我确认数据源、推送格式、目录结构都没问题，再放行写代码，省得后期大改。

Claude Code收到指令后会先列出方案，确认后很快就把index.js写出来了。核心逻辑大致是这样的：

const apiKey = process.env.WEATHER_API_KEY; const city = process.env.CITY || 'Shanghai'; const webhookUrl = process.env.WEBHOOK_URL; async function getWeather() { const url = `https://api.openweathermap.org/data/2.5/weather?q=${encodeURIComponent(city)}&appid=${apiKey}&units=metric&lang=zh_cn`; const res = await fetch(url); if (!res.ok) throw new Error(`天气接口请求失败：HTTP ${res.status}`); return res.json(); } function buildAdvice(data) { const tips = []; if (data.main.temp < 5) tips.push('气温较低，注意保暖'); if (data.weather[0].description.includes('雨') || data.weather[0].description.includes('雪')) tips.push('有降水，记得带伞'); if (data.wind.speed > 8) tips.push('风力较大，注意防风'); if (data.main.temp_max - data.main.temp_min > 10) tips.push('昼夜温差大，建议叠穿'); return tips.length ? tips.join('；') : '天气不错，正常出门'; } async function sendMessage(text) { const body = { msgtype: 'text', text: { content: text } }; const res = await fetch(webhookUrl, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(body), }); if (!res.ok) throw new Error(`消息推送失败：HTTP ${res.status}`); } (async () => { try { const data = await getWeather(); const text = [ `【今日天气】${city}`, `当前温度：${data.main.temp.toFixed(1)}°C（体感 ${data.main.feels_like.toFixed(1)}°C）`, `天气：${data.weather[0].description}`, `湿度：${data.main.humidity}%`, `风力：${data.wind.speed}m/s`, `建议：${buildAdvice(data)}`, ].join('\n'); await sendMessage(text); console.log('推送成功'); } catch (err) { console.error('执行失败：', err.message); process.exit(1); } })();

这份代码生成得相当干净：没有引入axios、dotenv之类的外部包，只用Node 18以上的原生fetch，直接跑就能用。这里提醒一下，如果环境变量没配置，脚本不会报错而是直接取默认值，容易在刚部署时误以为“机器人不工作”。最好在代码开头加一行校验：

if (!apiKey || !webhookUrl) { throw new Error('缺少必要的环境变量：WEATHER_API_KEY 或 WEBHOOK_URL'); }

这种细节我一般不会主动提，但可以让Claude Code顺手补上，它完全听得懂。

4.3 提醒逻辑与参数调优

提醒规则看起来简单，但阈值的选择其实有讲究。5度、8m/s、10度温差这些数字不是拍脑袋定的，要结合城市气候来调。我在上海，5度以下确实感觉冻手，但如果你在东北，可能零下10度才是“需要保暖”的信号。这些规则写成常量放到文件顶部，后续改起来就方便。

还要考虑数据的准确性。OpenWeatherMap实时接口返回的是“当前观测值”，不是整日预报。早晨8点运行时，拿到的温度和“今天最高/最低温”可能差别不小。所以我在提醒文案里会把当前温度和建议分开，让读到消息的人自己有判断。如果你的场景是“昨晚提前通知明天天气”，那就必须换预报接口，规则也要按整日最高最低温来写。

4.4 定时任务配置

本地定时我选择crontab，最简单也最稳定。编辑当前用户的定时任务：

crontab -e

加入一行：

5 8 * * * cd /home/你的用户名/weather-bot && /usr/bin/node index.js >> run.log 2>&1

四个值得注意的地方：第一，cron执行环境和你终端环境不一样，PATH经常不带node路径，所以node要用绝对路径，可以用which node查出来；第二，环境变量在cron里默认不加载，所以API Key这些要么写成全局环境变量，要么建议在脚本里读取一个.env文件；第三，日志重定向一定要加，否则出错了你根本不知道；第四，用分钟偏移5而不是整点，避开大家的整点并发，不是必需的，但实践下来更稳。

如果你不想依赖家里的电脑一直开机，也可以把同样的代码部署到云服务器或云函数，用定时触发器调用。比如放在云函数上，每月成本几乎可以忽略，机器人就能7x24稳定运行。原理完全一样，只是运行宿主不同。

4.5 用Claude Code调试和迭代

这个机器人从写完到跑顺，其实还经历了一轮调试。第一次手动执行时，推送消息迟迟没到，我把报错信息复制给Claude Code，它一眼看出是企业微信机器人的内容格式问题：群机器人要求text字段内容不能被过滤规则拦截。调整文案后，再执行就收到了。

后续改需求也很简单，比如我说“再加一个功能：每天下午6点再推一次，改成下午的短文案”，Claude Code会直接在现有代码上改，不会推倒重来。这就是长上下文带来的好处，你不用反复解释项目背景。

5. 我踩过的那些坑：问题排查实录

5.1 安装与启动类问题

我整理了一个速查表，基本上能覆盖本地开发阶段遇到的大多数问题。

这里我想多说一句：不要一上来就怀疑工具坏了。Claude Code报错信息通常很具体，把信息原样贴回去问它，比自己在网上乱搜效率高得多。

5.2 运行与API问题

天气机器人在实际运行中最常见的两类问题，一类是天气接口返回非200，另一类是推送收不到。

天气接口返回401，基本就是API Key无效，检查是否复制了完整字符串，注意别把空格带进去。返回404，通常是城市名拼写问题，比如St Petersburg和Saint Petersburg就差很多。返回429，是超出免费额度，OpenWeatherMap免费版每分钟有频率限制，个人机器人不会触发，但如果调试时循环请求就容易撞上。

推送收不到，先手动跑一次脚本看输出。如果脚本显示推送成功但群里没消息，大概率是消息内容触发了群的过滤规则。企业微信机器人还有一个限制：每个机器人每分钟最多20条消息。调试时不要高频连发，否则会被限流一段时间。

5.3 使用效率与成本类问题

用Claude Code这类工具，还要留意token消耗。一次大型任务的对话可能产生很多往返，上下文越长费用越高。我的做法有两个：一是把简单琐碎的小任务交给它时，明确要求“不要解释，直接改”；二是在需要深入思考的任务前使用思考等级命令，比如/think xhigh，让它在复杂问题上多花推理，简单问题上不浪费。如果对话太长，也可以使用上下文压缩功能，把历史对话摘要后再继续，能显著降低后续token消耗。

另外，Claude Code还支持通过环境变量开启提示词缓存，比如设置enable_prompt_caching_1h相关的开关，长期运行同一项目时能明显降低重复输入带来的费用开销。这个功能官方文档里有详细说明，建议长期使用者配置一下。

如果你自己维护了多个模型端点，还可以通过环境变量ANTHROPIC_BASE_URL和ANTHROPIC_AUTH_TOKEN指向兼容的API服务。市场上也有ccswitch这类工具用来切换不同端点，本质就是改环境变量。这个机制很适合团队内部做模型路由，但配置前务必确认服务端点本身是合规可用的。

6. 它如何重塑了我的日常开发工作流

6.1 从“写代码”到“表达需求”

开发工作流这个词，做流程引擎的同事可能第一反应是Camunda那种工作流引擎：节点、网关、流程编排。但Claude Code带来的“工作流重塑”是另一条线——它改变的是开发者每天“想清楚、做出来、改对”这个过程本身的方式。

过去写一个工具脚本，我要自己定义函数、查API文档、处理边界。现在多数时候我只需要把需求表达清楚，Claude Code负责把需求翻译成代码。表达需求也是一种能力：能准确描述输入输出、约束条件、异常处理的人，用AI的效率远高于只会说“帮我写个机器人”的人。这段时间我明显感觉到，自己花在“需求建模”上的时间变多了，但花在“敲代码”上的时间变少了。

6.2 人机协作的最佳节奏

我不建议把整个项目扔给Claude Code然后去睡觉，尤其业务逻辑复杂时。我的节奏是：大目标拆成多个可验证的小任务，每完成一个就自己review一遍，确认没有偏离需求后再继续。这种“小步快跑+人工验收”的节奏，能兼顾效率和安全。

还有一个细节：让Claude Code主动解释它做了哪些改动。每次大改后，我会让它用git diff总结差异。它给我列出的改动清单，往往比我自己翻diff更快看到风险点。代码提交前，我也会让它帮忙检查一遍是否存在明显的边界遗漏，比如空值、非法输入、超时等。

6.3 技能沉淀：把经验变成团队资产

Claude Code的Skills机制是我最近用得最多的地方。你可以把某个领域的经验写成一个技能文件，放在.claude/skills目录下，AI在遇到相关任务时会自动加载。比如我写了一个“Node服务脚手架”技能，它包含了项目结构规范、日志规范、环境变量约定。之后再让我搭新服务，AI会自动按这套规范执行，而我只需要检查输出。手动安装GitHub上的技能包也很简单，把仓库里的技能目录复制到项目的.claude/skills下，重启claude即生效。

这种做法特别适合团队：项目根目录的CLAUDE.md相当于AI版的团队Wiki，每个人都能在AI协作时共享统一的规范。甚至有朋友用Claude Code辅助STM32这类嵌入式开发，把芯片手册要点写进技能包，让AI直接生成驱动代码。工具的边界远比我们想象中宽。

这套配置我现在已经跑了好几个月，群里的天气提醒一天都没断过。我个人在使用Claude Code时最大的体会是：它不会取代你写代码，但真的会逼你把需求想得更清楚，也会把你从大量重复劳动里解放出来。如果你也要做类似的定时提醒机器人，建议先从小需求开始，把Claude Code当成一个能看懂项目的老同事，而不是一个自动写码机。最后一个小技巧：把巡检命令加进crontab时，记得配上日志轮转，不然run.log长年累月会越来越大。这个项目扩展空间也很大，比如接入多城市切换、对接日历、甚至用预报模型做穿衣指数，都是很好的后续方向。