这个教程解决什么问题
装好 n8n 之后卡住大多数人的不是界面，是”到底能拿它干什么”。这篇直接给 5 个高频自动化场景，每个都给出节点组合、关键配置和代码，照着搭就能跑。5 个场景覆盖 n8n 最核心的四类能力：定时取数、接口调用、事件接收、AI 处理——这四类拼起来，日常大部分重复劳动都有解。
| # | 场景 | 核心节点 | 产出 |
|---|---|---|---|
| 1 | 每日资讯摘要推送到邮箱 | Schedule Trigger + HTTP Request + AI | 每天一封摘要邮件 |
| 2 | 网站与接口可用性监控告警 | Schedule Trigger + HTTP Request + IF | 挂了立刻收到通知 |
| 3 | Webhook 接收业务回调并分发 | Webhook + Edit Fields + IF | 回调自动入库加通知 |
| 4 | 定时同步 CSV 数据入库 | Schedule Trigger + Code + Postgres | 数据表自动更新 |
| 5 | AI 内容生产流水线 | AI Agent + 数据库 + 通知 | 自动生成初稿 |
环境与版本
复用已有的 Docker 实例即可，没部署的先看文末的部署教程：
# 确认实例在跑
docker ps | grep n8n
# 看版本号
docker exec n8n n8n --version版本号与部署参数【待补：记录你的 n8n 版本、服务器配置】。下文所有定时类场景都要求容器带了 GENERIC_TIMEZONE=Asia/Shanghai 环境变量，没带的先补上再继续，否则场景一和场景二的触发时间会差 8 小时。
场景一：每日资讯摘要推送
解决”每天要看好几个信息源”的问题。流程：早上 8 点半触发，拉取 RSS 或热榜接口，AI 汇总成一段摘要，发到邮箱。
节点串联：
- Schedule Trigger：Cron 模式，表达式
30 8 * * *（每天 8:30）； - HTTP Request：GET 你的 RSS 源或资讯接口，拿到列表数据；
- Code 节点：压平列表、截取前 20 条；
- AI 节点（或 HTTP Request 调 LLM API）：把条目拼进提示词，要求输出 200 字以内摘要；
- Send Email 或 IM 通知节点：把摘要发出去。
Code 节点选 “Run Once for All Items” 模式，写法：
// 把接口返回的列表压平成逐条 item，只保留标题和链接
const rows = $input.first().json.data?.list ?? [];
return rows.slice(0, 20).map((row) => ({
json: { title: row.title, url: row.url },
}));两个要点：LLM 的提示词里明确”只输出摘要正文，不要复述输入”，否则它会把整个列表读一遍；邮件主题里用表达式拼日期（表达式编辑器里用 $now 变量做格式化），方便以后按天归档检索。
场景二：接口可用性监控告警
解决”服务挂了半天没人发现”。流程：每 5 分钟探测一次，状态异常就告警。
- Schedule Trigger：间隔模式，每 5 分钟；
- HTTP Request：GET 你的服务健康检查地址（如
/health），Options 里设 Timeout 10000 ms； - HTTP Request 的 Settings 里开启 Continue On Fail，让请求失败也往下走；
- IF：条件选 Expression，判断
$json.statusCode不等于 200（或字段为空）； - 告警分支接通知节点（邮件、企业微信、钉钉机器人均可）。
重试设置在节点 Options 里：Retry On Fail 开启，Max Tries 3，Wait Between Tries 5000 ms，能滤掉网络抖动的误报。再进一步可以配”连续两次失败才告警”的逻辑（用工作流静态数据记上次状态），降噪效果明显，进阶写法到排障篇再展开。
场景三：Webhook 接收回调并分发
解决”外部系统的事件要人工搬运”。以订单回调为例，先用 curl 模拟一次外部请求：
curl -X POST https://你的域名/webhook/order-notify \
-H "Content-Type: application/json" \
-d '{"order_id":"A1024","channel":"app","status":"paid"}'- Webhook 节点：Method 选 POST，路径
order-notify。注意 Test URL 用于调试，Production URL 才是长期生效地址，且必须激活工作流； - Edit Fields：只保留
order_id、status等业务字段； - IF：按
status分支——paid走”发通知写入库”，其他走”仅记录”； - 分支末端各接通知节点与数据库节点。
调试技巧：先点 Webhook 节点的 Listen for test event，再执行上面的 curl，节点输出面板就能看到完整请求体，字段映射照着真实结构配，不用猜。
场景四：定时同步 CSV 数据入库
解决”每周手动导表导库”。流程：定时下载 CSV，解析，写入 Postgres。
- Schedule Trigger：每周一 9 点，
0 9 * * 1； - HTTP Request：下载 CSV 文件（Response Format 选 File）；
- Extract From File：CSV 转 JSON，分隔符与编码按实际文件调；
- Postgres 节点：Operation 选 Insert or Update，字段自动映射。
表结构示例：
CREATE TABLE IF NOT EXISTS daily_stats (
id SERIAL PRIMARY KEY,
stat_date DATE NOT NULL,
pv INTEGER DEFAULT 0,
uv INTEGER DEFAULT 0,
created_at TIMESTAMP DEFAULT NOW()
);两个细节：CSV 里的日期是字符串，在 Extract From File 后面加一个 Edit Fields 用表达式转成日期格式；重复执行会重复插行，给 stat_date 建唯一约束，配合 Insert or Update 模式最省心。
场景五：AI 内容生产流水线
解决”写东西的冷启动”。流程：从选题表取一条待写选题，LLM 生成大纲或初稿，存档并通知人工接手。
- 触发：手动跑（写作按需触发）或每周定时批量；
- Postgres / Google Sheets 节点：取出状态为”待写”的一行选题；
- AI Agent 节点：配好系统提示词，接模型——本地 Ollama 或云端 API 都可以，接法见相关阅读；
- 通知节点：把生成结果推给作者，并把该行状态改成”已写”。
AI Agent 节点可以挂工具（联网搜索、HTTP Request），让它先查资料再动笔，初稿质量比裸生成高一截。人工始终在环上：这条流水线的定位是”把空白页变成草稿”，不是”替你写完”。
常见坑与解法
坑 1：定时任务触发时间不对
容器默认 UTC 时区，北京时间 8 点的 cron 会在 16 点触发。解法：启动时加 -e GENERIC_TIMEZONE=Asia/Shanghai 并重建容器；验证方法是建一个每分钟触发的工作流看执行记录时间。注意改环境变量必须重建容器，docker restart 不生效。
坑 2：手动执行正常，上线后不跑
没开 Active 开关，或者 Webhook 场景里复制的是 Test URL。手动 Execute 只验证逻辑，Save 之后打开 Active 才进入生产。通知类场景再检查凭据（Credentials）在生产环境是否可用——导出的工作流 JSON 不含凭据，从别人那里导入的模板必须重配一遍凭据。
坑 3：节点偶发失败导致整条断掉
对方接口抖动、限流都会让单次执行失败。三个手段按需叠加：节点 Options 开 Retry On Fail；节点 Settings 开 Continue On Fail 让失败走错误分支；工作流级别配 Error Workflow 统一兜底告警。Executions 页能看到每次失败的具体输入输出，排错先看它。
坑 4：执行记录把数据库撑大
每次执行默认保存完整的输入输出数据，高频监控类场景一天就能积累上千条记录。工作流 Settings 里把执行数据保存调成只存失败（Save production failure data only），或在环境变量层面配执行数据自动清理（EXECUTIONS_DATA_PRUNE 相关变量【待补：按当前版本文档确认变量名与默认值】）。
最终效果与验证
5 条工作流全部激活后，Executions 页应该呈现这样的节奏：每天 8:30 一条摘要执行、每 5 分钟一条监控执行、周一一早一条入库执行，全部绿色；业务回调随事件出现；AI 流水线按需手动触发。
【待补：5 条工作流的画布截图与执行记录截图】
验收标准三条：定时类连续一周无漏触发；监控类做过一次人工断网演练且告警送达；回调类用 curl 打过生产 URL 并成功入库。三条都过，这套自动化才算真正上线。