最近看到一篇讲 n8n 的文章，我又把这类自动化工作流工具重新认真看了一遍。原因很简单：这两年大家都在聊 AI Agent、自动化、工作流，但真正能落地的方案，最后还是要回到“怎么把信息抓进来、怎么处理、怎么发布出去”这种很具体的链路上。

而 n8n 之所以一直被反复提起，不只是因为它火，而是它确实站在一个很实用的位置：足够可视化，足够灵活，也足够接近真实业务场景。

原文来源：https://zhuanlan.zhihu.com/p/1920982802221991385
项目地址：https://github.com/n8n-io/n8n

n8n 到底适合什么人？

如果只是看一句定义，n8n 是一个开源工作流自动化工具。但这个定义太平了，不足以说明它为什么值得关注。

我的理解是，n8n 最适合下面这几类人：

• 想把重复性流程自动化的开发者
• 想接 API、接数据库、接第三方服务，但又不想自己从零写一套调度系统的人
• 已经开始尝试用大模型做内容处理、摘要、路由、通知的人
• 希望把“采集 → 清洗 → 判断 → 生成 → 发布”串成完整链路的人

它和很多“自动化平台”最大的区别，不只是节点多，而是它允许你在低代码和可编程之间自由切换。简单的流程可以拖拽，复杂的逻辑可以直接塞代码节点，这个平衡点其实挺关键。

这篇文章里，最有价值的不是介绍，而是那个实际案例

原文用了一个很接地气的例子：

自动追踪 GitHub Trending 项目，并进一步做 AI 总结，再推送到邮件或博客。

这个案例比“发个通知”“同步个表单”更有代表性，因为它已经接近一条真正有价值的内容生产链路了。拆开来看，大概是这样：

1. 定时抓取 GitHub Trending 列表
2. 将项目基础信息存入数据库（文中用的是 Supabase）
3. 过滤掉已经处理过的项目
4. 拉取项目 README 等核心内容
5. 用 LLM 做总结和重写
6. 自动发邮件或发布到博客系统
7. 记录已发布状态，避免重复推送

这件事看起来不复杂，但其实已经把一个自动化系统的关键能力都串起来了：

• 定时触发
• 数据存储
• 状态去重
• 外部 API 调用
• 大模型处理
• 多渠道分发

如果一个工具能把这几件事比较顺地组合起来，它基本就不只是“玩具”了。

我觉得 n8n 最值得看的地方

1. 它不是只给“不会写代码的人”准备的

很多人一看可视化工作流，就会默认这是给非技术人员用的。但 n8n 真正有意思的地方，是它并没有把开发者挡在门外。

你既可以用现成节点去连 GitHub、Supabase、Webhook、邮件服务，也可以在代码节点里直接写 JavaScript 或 Python，把一些不规则的处理逻辑自己兜住。

这意味着它不是在替代开发，而是在替代那些重复、分散、胶水化的开发工作。

2. 开源和自托管，意味着边界更可控

这类系统一旦接入内部数据、业务通知、私有服务，大家最担心的通常不是“能不能用”，而是：

• 数据放在哪里
• 能不能自己部署
• 能不能按自己的规则改
• 后续会不会被平台能力限制住

n8n 的开源和自托管能力，给了它一个很现实的优势：你不一定非要把工作流托管在别人的平台上。

对很多团队来说，这不只是技术偏好，而是合规、成本和可维护性的考虑。

3. 它很适合做 AI 时代的“胶水层”

现在很多 AI 应用最大的问题不是模型不够强，而是上下游没接起来。

模型会总结、会分类、会抽取、会改写，但如果它前面接不到稳定数据源，后面接不上数据库、通知系统、发布系统，那结果就是 demo 很惊艳，落地很费劲。

n8n 恰好能补上这层：

• 前面接数据源
• 中间做规则和路由
• 把模型插进流程中间
• 后面接发布、归档、通知

从这个角度看，n8n 不只是自动化工具，也很像是 AI 工作流的基础设施之一。

这篇案例给我的几个实际启发

用数据库记状态，比“纯流程编排”更重要

原文里用 Supabase 存储 Trending 项目列表和已推送列表，这一点我很认同。

很多人刚开始做自动化时，容易把重点放在节点怎么连、提示词怎么写，但真正跑起来后最容易出问题的，其实是：

• 哪些数据已经处理过
• 哪些结果已经发过
• 哪些任务失败了需要重试
• 哪些内容需要二次更新

如果没有状态层，自动化流程就很容易变成一次性演示。加上数据库之后，才更像一个能长期运行的系统。

不是所有 API 都要等官方节点

文章里提到 GitHub 原生节点不支持直接获取 README，于是用 HTTP Request 节点自己调接口。这其实非常符合实际。

自动化平台真正好不好用，不在于“有没有 1000 个官方节点”，而在于当没有现成节点时，你能不能顺畅地自己补上去。

n8n 这里的思路是对的：

• 有现成节点就直接接
• 没有就用 HTTP Request 自定义
• 再配合表达式和代码节点做转换

这样灵活性就出来了。

AI 总结不是终点，发布链路才是

很多人现在做 AI 工作流，做到“模型输出了一段还不错的总结”就结束了。但对真正想提高效率的人来说，这一步只是中间环节。

真正的闭环应该是：

• 内容抓取
• 信息筛选
• AI 处理
• 人工审核（可选）
• 自动分发
• 发布归档

原文把邮件发送和博客发布都纳入了工作流里，这比单纯做一个“AI 摘要 demo”更有价值，因为它已经在替代真实工作流中的一部分劳动了。

如果你也想用 n8n，我建议先从这类场景开始

与其一上来就做很大的 Agent 系统，不如先做一些小而完整的自动化闭环。比如：

• 每天抓取几个固定信息源，做摘要后发到飞书/邮件
• 监控 GitHub、RSS、论坛或社交平台的关键词变化
• 收集表单、工单或用户反馈后自动分类入库
• 从数据库里挑选内容，自动生成周报、日报、候选选题
• 把 AI 输出结果自动同步到博客、知识库或内部文档系统

这些事情的共同点是：

• 规则相对明确
• 上下游接口清晰
• 自动化收益很直接
• 即使模型偶尔不稳定，也可以靠人工兜底

n8n 的边界也要看清楚

当然，我并不觉得 n8n 是“万能解法”。

至少有几个边界要意识到：

• 如果业务逻辑极其复杂，最终还是要回到代码系统本身
• 如果任务量特别大、并发很高，工作流平台未必是最优承载层
• 如果你对工程化、版本管理、测试、可观测性要求很高，就得认真设计而不是一路堆节点
• 如果把所有判断都丢给 LLM，流程会变得不稳定，维护成本也会升高

所以更适合的思路是：把 n8n 当成编排层，而不是试图让它吞掉整个系统。

写在最后

我一直觉得，真正好用的自动化工具，不是让你“看起来像在搭系统”，而是它真的能把一段原本反复发生的工作，从手工变成稳定运行的流程。

n8n 之所以值得持续关注，就是因为它已经不只是“拖拽几个节点发通知”这么简单了。尤其在 AI 能力逐渐成为流程中间件的一部分之后，它这种能连数据、连模型、连发布渠道的工具，会越来越有现实价值。

如果你最近也在折腾：

• GitHub 信息追踪
• AI 自动摘要
• 自动写周报/日报
• 内容自动发布
• 数据采集到分发的完整链路

那 n8n 确实值得你亲自上手跑一遍。

额外放两张我从桌面随机翻到的图

你让我“在桌面上随机找几张图作为配图”，我顺手也挑了两张放在文章尾部，当成一个轻量的视觉收尾。它们和 n8n 本身没有直接对应关系，更像是博客排版上的补充。

（这里原本放了两张桌面随机配图，我先移除了，避免出现失效图片。）

原始参考

• 知乎原文：https://zhuanlan.zhihu.com/p/1920982802221991385
• n8n GitHub：https://github.com/n8n-io/n8n
• n8n 文档：https://docs.n8n.io/

标签建议： n8n, 自动化, AI工作流, GitHub, 效率工具

最近在做一个微信小程序项目，后台需要部署到云端，但是后端业务相对简单，购买服务器的话超出预算了。经过一番调研，发现 Vercel 是个不错的选择：免费、简单、速度快。今天就来分享一下具体的部署过程。

项目后台演示

为什么选择 Vercel

传统的服务器部署需要自己管理服务器、配置环境、处理运维问题。而 Vercel 这类 Serverless 平台的出现，让部署和API部署变得极其简单。

对于小程序后台来说，Vercel 有几个明显的优势：

1. 零配置部署：推送代码就能自动部署
2. 全球 CDN：访问速度快
3. 免费额度：个人项目完全够用
4. 自动 HTTPS：省去证书配置的麻烦

项目结构

我们的小程序后台是一个标准的 Node.js + Express 应用，主要文件结构如下：

backend/
├── app.js              # 主应用文件
├── package.json        # 依赖配置
├── vercel.json         # Vercel 配置文件
├── deploy.sh           # 部署脚本
├── .env                # 环境变量
└── admin/              # 管理后台静态文件

核心配置文件

1. vercel.json

这是 Vercel 的配置文件，告诉 Vercel 如何构建和运行我们的应用：

{
  "version": 2,
  "builds": [
    {
      "src": "app.js",
      "use": "@vercel/node"
    }
  ],
  "routes": [
    {
      "src": "/(.*)",
      "dest": "/app.js"
    }
  ],
  "env": {
    "NODE_ENV": "production",
    "VERCEL": "1"
  }
}

这个配置很简单：

• builds 指定构建规则，使用 @vercel/node 来处理 Node.js 应用
• routes 将所有请求都路由到 app.js
• env 设置环境变量

2. package.json

关键是要有正确的启动脚本：

{
  "name": "backend",
  "version": "1.0.0",
  "main": "app.js",
  "scripts": {
    "start": "node app.js",
    "dev": "nodemon app.js",
    "vercel-build": "echo \"Vercel build completed\""
  },
  "dependencies": {
    "express": "^5.1.0",
    "cors": "^2.8.5",
    "mysql2": "^3.14.3",
    "jsonwebtoken": "^9.0.2",
    "bcryptjs": "^3.0.2",
    "dotenv": "^17.2.1",
    "axios": "^1.11.0",
    "multer": "^2.0.2",
    "sharp": "^0.34.3",
    "sqlite3": "^5.1.7"
  }
}

3. 应用入口文件

app.js 是我们的主应用文件，需要注意几个关键点：

const express = require('express');
const cors = require('cors');
const mysql = require('mysql2/promise');
require('dotenv').config();

const app = express();
const PORT = process.env.PORT || 3000;

// CORS 配置 - 重要！
app.use(cors({
  origin: true,
  credentials: true,
  methods: ['GET', 'POST', 'PUT', 'DELETE', 'OPTIONS'],
  allowedHeaders: ['Content-Type', 'Authorization', 'X-Requested-With']
}));

// 静态文件服务
app.use('/admin', express.static(path.join(__dirname, './admin')));

// 数据库配置
const dbConfig = {
  host: process.env.DB_HOST || 'localhost',
  port: process.env.DB_PORT || 3306,
  user: process.env.DB_USER || 'root',
  password: process.env.DB_PASSWORD || '',
  database: process.env.DB_NAME || 'zhaoyimei_db'
};

// 重要：Vercel 环境下不启动监听
if (process.env.NODE_ENV !== 'production' || !process.env.VERCEL) {
  const server = app.listen(PORT, '0.0.0.0', () => {
    console.log(`服务器运行在端口 ${PORT}`);
  });
}

// 导出 app 供 Vercel 使用
module.exports = app;

最后两行很关键。在 Vercel 环境下，我们不需要启动 HTTP 服务器，只需要导出 Express 应用实例即可。

部署脚本

为了简化部署流程，我写了一个自动化脚本：

#!/bin/bash

echo "🚀 开始部署到 Vercel..."

# 检查是否安装了 Vercel CLI
if ! command -v vercel &> /dev/null; then
    echo "❌ Vercel CLI 未安装，正在安装..."
    npm install -g vercel
fi

# 检查是否已登录
echo "🔐 检查 Vercel 登录状态..."
if ! vercel whoami &> /dev/null; then
    echo "📝 请先登录 Vercel:"
    vercel login
fi

# 部署到生产环境
echo "📦 部署到生产环境..."
vercel --prod

echo "✅ 部署完成！"
echo "📋 请记住在 Vercel Dashboard 中配置环境变量"

环境变量配置

部署完成后，需要在 Vercel Dashboard 中配置环境变量。我们的项目需要这些变量：

• DB_HOST - 数据库主机
• DB_PORT - 数据库端口
• DB_USER - 数据库用户名
• DB_PASSWORD - 数据库密码
• DB_NAME - 数据库名称
• JWT_SECRET - JWT 密钥
• WECHAT_APPID - 微信小程序 AppID
• WECHAT_SECRET - 微信小程序密钥

在 Vercel Dashboard 的项目设置页面，找到 "Environment Variables" 选项，逐一添加这些变量。

数据库选择

我用的sqlpub的开发版数据库，数据库版本是mysql8.4.0，一年9元，1G容量。也有免费版的500M容量，如果测试用可以免费申请使用这个版本的

网址：https://sqlpub.com/

部署步骤

整个部署过程非常简单：
直接运行我们的部署脚本：

chmod +x deploy.sh && ./deploy.sh

常见问题

1. CORS 问题

小程序访问后台 API 时，经常遇到跨域问题。解决方案是在 Express 中正确配置 CORS：

app.use(cors({
  origin: true, // 允许所有来源
  credentials: true,
  methods: ['GET', 'POST', 'PUT', 'DELETE', 'OPTIONS']
}));

2. 静态文件服务

如果你的后台包含管理界面等静态文件，需要正确配置静态文件服务：

app.use('/admin', express.static(path.join(__dirname, './admin')));

3. 数据库连接

建议使用连接池来管理数据库连接，避免连接数过多的问题：

const pool = mysql.createPool(dbConfig);

访问优化

自定义域名

部署成功后vercel会免费分配一个域名，但是国内访问效果不佳，需要自定义域名

服务器位置选择

系统默认部署到其他洲的服务器，这就让我们的访问速度比较慢，需要手动更改地区为亚洲的HongKong

总结

Vercel 让小程序后台的部署变得非常简单。整个过程只需要几个配置文件和一条命令，就能把本地开发的应用部署到全球 CDN 上。

相比传统的服务器部署，Vercel 的优势很明显：

• 不需要管理服务器
• 自动扩容
• 全球加速
• 免费 HTTPS
• 与 Git 集成，推送即部署

对于个人开发者和小团队来说，这种 Serverless 的部署方式确实是个不错的选择。

当然，Vercel 也有一些限制，比如函数执行时间限制、冷启动问题等。但对于大多数小程序后台来说，这些限制都不是问题。

我之前还写过一篇关于把小程序后台部署的cloudflare workers的教程，大家感兴趣也可以参考一下。