用Claude Code构建n8n工作流

微信 ezpoda免费咨询：AI编程 | AI模型微调| AI私有化部署 | OpenClaw安装 | Claude/OpenAI/Gemini API

上周二晚上 11 点，我看着 Claude Code 从生产电子商务商店中删除了 140 个产品变体。不是恶意的。甚至在技术上也没有错误。

我要求它修复的工作流程向 PrestaShop 的 XML API 发送 PUT 请求，只有 4 个字段。PrestaShop 将其解释为"将其他所有内容设置为空"。引用消失了。条形码消失了。当我在另一个终端选项卡中比较执行日志时，140 个组合被静默清除。

TL;DR： n8n 没有死。手动工作流构建正在消亡。一个开源仓库（czlonkowski/n8n-mcp）将 Claude Code 变成了 n8n 架构师。我已经在实际的 55 节点生产管道上使用它，并分别禁用了自己的 AI agent，因为它白白消耗了令牌。下面：真正有效的东西、会破坏的东西，以及何时使用哪个工具的框架。

十五分钟后，Claude Code 诊断了根本原因，构建了修复（4 个新节点中的 GET-before-PUT 模式），在单个原子 API 调用中部署了所有 12 个更改，并通过在前后拉取 PrestaShop API 状态来验证修复。

在 n8n UI 中进行相同的调查将花费我一个多小时。我知道，因为我以前做过，点击 55 个节点，在浏览器选项卡之间切换，手动导出 JSON，盯着执行数据看。

两周前，我禁用了自己的 AI agent。拔掉了 OpenClaw 的插头，这是我数月来一直在构建和撰写的多模型系统。花费的令牌与产生的价值的比率是负的。agent 不断花费周期尝试更新自己，而不是做实际工作。

所以现在我在终端中坐着一个悖论：我自己构建的 AI agent 无法证明自己的电费是合理的，而一个 AI 辅助工作流系统在 15 分钟内拯救了生产数据库。

那个悖论基本上是整个 n8n 辩论现在的样子。

1、改变 n8n 工作描述的仓库

三个月前，我要求 Claude Code 为我构建一个 n8n 工作流。

它发明了一个名为 scheduleTrigger 的节点。该节点不存在。真正的一个叫 schedule。我花了 20 分钟调试一个 JSON 文件上的导入错误，该文件看起来完全有效，因为每个属性名称几乎都是正确的。足够导入，足够错误以破坏。Claude 对它也很有信心。峰值幻觉能量。"这是你的工作流"，JSON 看起来很美，直到你意识到一半的节点类型是同人小说。

从那以后，我停止要求 Claude Code 触摸 n8n。

然后一个名为 czlonkowski 的开发人员发布了一个开源 MCP 服务器。下一次我要求 Claude Code 构建工作流时，它知道每个节点名称、每个属性模式、每个 IF-分支连接语法。没有幻觉。没有猜测。

接下来在线上发生的争论是这样的：Claude Code 正在吃 n8n 的午餐。Google 趋势显示它在搜索兴趣上超越 n8n。在 n8n 教程上建立观众的 YouTube 创作者们看着他们的浏览量下降。标题为"n8n 死了吗？"的论坛线程每隔一周就出现一次。共识的看法总是相同的温和事物："它们是不同技能水平的互补工具。"

该共识是准确的，但完全没有帮助。

实际的变化更具体。czlonkowski 的 n8n-mcp 服务器（在 GitHub 上）给 Claude Code 提供对 1,084 个 n8n 节点的结构化访问、2,600+ 从模板中提取的真实配置，以及在部署前捕获错误的验证规则。一个伴随项目添加了 7 个 Claude Code 技能，涵盖表达式语法、架构模式和调试。

n8n 也发布了他们自己的官方 MCP（设置 > 实例级 MCP），但他们的故意更有限：触发和查询现有工作流，而不是构建新的。安全意识的选择，不是弱点。

所以实际发生的是，n8n 的可视化构建器没有死。它改变了工作。它曾经是构建工具。现在是监控仪表板。Claude Code 构建，n8n 运行。

但更快地构建工作流只是其中的一半。我的 n8n 实例上运行着 15 个工作流。上个月我打开了一个 3 个月没有触摸的工作流，不知道中间 20 个节点做了什么。一个 MCP 调用，Claude Code 在每个节点上粘贴便条，解释它做什么，它期望什么，如果你更改它会破坏什么。仅此一点就值得设置。但后来我意识到我可以在每次修改后都这样做。

编辑工作流的东西也记录更改并使用实际描述发生了什么的消息将其提交给 git。在我的三个调试会话中，这意味着 30 次提交，具有完全回滚能力，零手动导出/导入点击。尝试在 n8n UI 中这样做。

公平警告：此设置意味着你将 API 令牌交给一个 AI，该 AI 对你的 n8n 实例具有完全读/写访问权限。我在暂存和生产上都这样做了。我不会假装这是无风险的。在我的一个工作流上，Claude Code 可以看到以明文形式位于参数节点中的 PrestaShop API 密钥。对于直接 curl 验证很有用。对于凭据卫生状况很糟糕。阅读此文的安全人员刚刚感觉到原力中的扰动。抱歉。 MCP 层今天具有零凭据范围。

我上个月争辩说 CLI 仍然在大多数 AI agent 工具方面击败 MCP。对于通用 agents，我仍然认为这是正确的。但是对于像 n8n 这样特定的、文档齐全的平台？结构化 MCP 方法获胜。czlonkowski 证明了这一点。

2、来自真实生产调试的三个时刻

我为 redactedshop.com 运营电子商务管道，这是一个基于 PrestaShop 8.2.1 的欧洲户外零售网站。供应商通过 FTP 发送 CSV 目录。n8n 管道读取 CSV，将其解析为 Google Sheets（通过 AI 辅助变体检测使用 Gemini），然后在 PrestaShop 中创建和更新约 265 个产品，包括价格、库存、图像、类别和 3 种语言的翻译。两个主要工作流、六个子工作流、总共 55 个节点。

在两周内的三个调试会话中，Claude Code + n8n-MCP 的组合处理了从琐碎到"这如何工作"的问题。三个时刻脱颖而出，因为每个都证明了不同的点。

2.1 静默清除

update variants prix 节点向 /api/combinations/{id} 发送 PUT，只有 id、id_product、minimal_quantity 和 price。PrestaShop 的 API 将部分 PUT 视为"替换整个资源"。呃。你不发送的每个字段都会被清空。这静默地清除了 140 个产品变体上的引用代码和 EAN 条形码。第二个节点具有相同的模式并且设置为 executeOnce: true，意味着只有第一个产品被更新。其余的完全被跳过。

Claude Code 通过 MCP 拉取执行数据，提取特定的组合 ID，对 PrestaShop API 执行 GET 以查看损坏，构建了 4 个实现 GET-before-PUT 模式的新 Code 节点，在 IF 分支上重新连接 4 个连接，删除了 executeOnce 标志，并在一个 n8n_update_partial_workflow 调用中部署了所有 12 个更改。在 n8n UI 中，该序列意味着：创建节点、定位它、填充 6+ 配置字段、拖动连接线、重复四次，然后手动验证。实际上 20 分钟的小心点击。在一个 API 调用中完成，在 3 分钟内验证。

那是一个昂贵的错误。下一个便宜且令人沮丧。

2.2 不存在的类型

当单元格有内容时，Google Sheets 返回 product_id: 32210（一个数字），但 product_id: ""（一个空字符串）当它没有内容时。n8n IF 节点的 exists 操作符静默地传递空字符串，因为空字符串存在。它只是空的。

JavaScript 类型强制再次打击。[] == false* 但 [] ? true : false 返回 true 的语言。Google Sheets 只是让它更糟。

在会话中花了 4 次提交才收敛到工作的过滤器：第一个 exists 失败，然后 isNotEmpty 在数字上窒息，最后 gt 0 与 typeValidation: loose 工作。

MCP 执行检查器使这可诊断。它显示每个节点输出的确切数据结构，这立即揭示了混合类型问题。如果没有对执行数据的编程访问，我必须在 n8n UI 中逐个节点点击执行检查器节点，眯着眼看 JSON 输出面板。尽管如此，Claude Code 对 IF 节点配置的前三次尝试是错误的。来自 Google Sheets 的混合类型行为在任何地方都没有记录。必须通过经验发现。4 次提交来修复过滤器。那是真正的速度。

这两个错误都有干净的结局。第三个没有。

2.3 不是测试的测试

修复变体更新路径后，我需要也验证简单产品更新路径。问题：当前 Google Sheet 数据集中不存在简单产品。Claude Code 的解决方案是务实的：通过 node -e 在本地运行 Code 节点的 JavaScript，然后通过 curl 对已知产品执行手动 PUT 以验证 XML 转换保留了所有字段。

这验证了正则表达式和 XML 逻辑。它不验证 n8n 表达式引用、节点链接或 continueOnFail 行为。修复部分未测试地进入生产。我知道。Claude Code 标记了它。完整的端到端测试需要将简单产品行注入 Google Sheet，我还没有这样做。

我告诉你这个，因为关于 Claude Code + n8n 的每一篇文章都向你展示快乐路径。真实路径包括一个没有正确集成测试的修复和一个在第一次执行时崩溃的 Code 节点，因为 Claude Code 遵循了自己的技能文档（推荐数组包装返回），而 n8n 的运行时验证器在 runOnceForEachItem 模式下拒绝数组。

房间里最聪明的工具仍然需要失败的执行来学习房间的规则。

3、我为什么禁用自己的 AI Agent

最后一部分可能听起来我对组合持否定态度。我不是。我对版本持否定态度，其中每个演示都结束于快乐路径，没有人展示在第一次运行时崩溃的 Code 节点。当你进一步推进时，演示和生产之间的差距，正是杀死我的 agent 的东西。

我构建了 OpenClaw，一个在 $5 VPS 上运行的多模型 AI agent。Kimi K2.5 作为主要模型，MiniMax M2.5 作为后备。原始版本在 Claude 的 OAuth 上运行，Anthropic 杀死了它并迫使每个人都使用付费 API 密钥。那是经济学从"廉价实验"转变为"真正的预算决定"的时候。

Peter Steinberger 争辩说你应该使用前沿模型或什么都不用。他在技术方面可能是正确的，OpenClaw 的大部分问题来自不够聪明、无法可靠自我更新和自我修复的模型。前沿模型可能会解决那个问题。但 Steinberger 在这样说后不久加入了 OpenAI，无监督 agent 的前沿 API 价格可能达到 $200/天。对于我们其余在真实预算上运行真实工作负载的人来说，正确并不使其负担得起。

我在更便宜的模型上部署了 OpenClaw 数月。然后我关闭了它。就像拔掉一个不断撞到同一墙但带有 API 成本的扫地机器人。

比率是诚实和残酷的：花费的令牌除以产生的价值是负的。agent 不断消耗周期尝试更新自己、修复自己的工具、重启失败的过程。修复存在，更聪明的模型。价格标签不存在。空间实际需要的是一个智能 CRON 系统和真正的自工具能力，无需烧毁前沿层令牌即可工作。我正在考虑自己构建那个。但那是另一篇文章。

与此同时，我的 n8n 工作流已经运行数月。Webhooks 触发。CRONs 执行。产品更新。库存同步。通知发送。零干预。除初始构建外零令牌成本。执行日志可审计、错误处理是确定性的、托管是稳定的。

80% 的业务自动化是无聊的，"AI agents 将取代一切"阵营中的没有人想听到这个。它是早上 6 点触发的 CRON 作业、捕获 Stripe 事件的 webhooks、将数据路由到正确端点的 IF/ELSE 分支。你不需要"推理"这个的 agent。你需要一个可靠执行且运行成本为零的管道。

n8n 做到这一点。

Claude Code + MCP 使构建它戏剧性地更快。实际上，让我在"戏剧性地"上放一个数字：将花费我一个下午的 PrestaShop 调试在 15 分钟内完成。我的堆栈在 Claude Max 订阅和 $5 VPS 上自托管的 n8n 实例上运行。不便宜，但与 24/7 运行的无监督 agent 的前沿 API 成本相比，它是一个舍入误差。该组合涵盖了人们认为他们需要 autonomous agents 的 90% 用例。

Agents 并非无用。它们只是罕见。当你真正需要无法简化为决策树的动态推理时，那是 agent 领域。其他一切都是带有额外步骤和更大账单的工作流。

我构建了一个 agent。我撰写了文章。我拔掉了插头。

4、框架：何时使用什么

在两者生产中运行并杀死其中一个之后，这是我决定的方式。

仅 n8n 处理比你想象的更多。稳定、重复的过程。Webhooks、计划的 CRONs、两个 API 之间的数据同步、通知管道。当非技术人员需要了解正在运行的东西时。当你需要审计跟踪和执行日志时。当正常运行时间比灵活性更重要时。我的 5 个 SaaS 产品单独在 n8n 上运行约 80% 的自动化。

仅 Claude Code 在事情不重复时是正确的工具。转换数据集的快速脚本。你下周会抛弃的原型。如此特定的自定义逻辑，将其连接到 n8n 将是过度工程。探索模式，而非部署模式。

现在有趣的部分。如果你即将在 n8n UI 中拖动节点 45 分钟来构建你脑海中已经映射的工作流，停止。那是 Claude Code + 通过 MCP 的 n8n 领域。调试复杂管道，你需要交叉引用执行数据与外部 API 状态。迁移或重构现有工作流。自动记录你数月未触摸的十几个工作流。并且越来越多地，使用 n8n 作为后端构建真实应用程序，而不是将 Airtable 和 Google Sheets 用胶带粘在一起假装是界面的东西。我还没有以这种方式发布完整的前端，但架构是明显的：Claude Code 搭建一个与 n8n webhooks 通信的真实 UI。带有适当后端的正确应用程序。那是我列表上的下一个。

然后有自主 AI agents。当任务确实无法减少为 IF/ELSE 的推理时，这是正确的调用。当输入足够不可预测，以至于你无法预先映射决策树时。当令牌成本由输出价值证明是合理的时候。根据我在 5 个 SaaS 产品中的经验，这可能涵盖 10% 的自动化任务。其他 90% 是穿着 agent 服装的工作流 💀 我这样说作为给他的 agent 穿上最奇特服装的人。它仍然不会跳舞。

同样的纪律适用于这里以及其他任何地方：在让 AI 执行之前定义合约。无论是 Claude Code 的提示合约还是 n8n 的工作流规范，模式是相同的。前期清晰，执行之后。

最后一件事。czlonkowski 针对每个新的 n8n 发布维护 n8n-mcp。开源、MIT 许可、无付费墙。一个人构建了使整篇文章成为可能的东西。去 star 这个仓库。这是我们欠他的最少。

原文链接: One Open-Source Repo Turned Claude Code Into an n8n Architect — And n8n Has Never Been More Useful

汇智网翻译整理，转载请标明出处