自然语言生成工作流：n8n、OpenAI与AI Code的演进之战

在10月6日召开的OpenAI DevDay 2025上，OpenAI出乎意料地推出了一款名为AgentKit的产品。该产品旨在帮助开发者以更少的时间和精力，完成从原型设计到生产部署的全过程。简而言之，OpenAI打造了一套工作流编排工具，其本质是一个低代码平台。

随后，LangChain创始人直接表示，可视化工作流构建器用处不大，谁愿意做就去做。原因有很多，核心在于 “拖拽式操作不利于复杂工程” 。更直白地说，就是门槛太高：专业程序员可能看不上，而普通用户又用不习惯，导致两边都不看好。

然而，凭借OpenAI巨大的行业影响力，其 “直接竞品n8n” 受到了不小的冲击。因为没过两天（10月9日），n8n就宣布完成了1.8亿美元的融资。因此，在n8n的融资关键期，AgentKit这个 “竞品” 横空出世了。虽然OpenAI自身可能并不认为AgentKit是n8n的对手，但我认为n8n确实被OpenAI的这次发布打了个措手不及。毕竟，风险投资人未必都精通技术细节，在那个节骨眼上，n8n团队必定准备了大量的说辞，最终才如释重负地拿下了融资。

紧接着，在10月13日，n8n似乎按捺不住，将可能“压箱底”的新功能AI Workflow Builder公之于众，继续**“回应OpenAI”** 。他们传递的核心信息是：别再卷工作流的拖拽操作了，以后甚至不用再手动梳理工作流，直接用自然语言描述，就能自动生成n8n工作流！

那么，这是否意味着竞争的重点已经转向了“自然语言生成工作流”这条新赛道呢？

自然语言 → 工作流

事实上，AI Workflow Builder并非首个提出用自然语言生成工作流的玩家。Zapier在更早的10月3日已经上线了AI生成工作流大纲的功能。在Zapier的控制台中，用户可以用自然语言描述“当X事件发生 → 执行Y操作 → 再做Z处理”。系统会据此产出一个包含触发器与若干动作的草稿大纲，之后用户可以进入编辑器进一步细化。

Make也在其公开的产品路线图中强调了AI辅助构建，目标是通过一句描述目标的语句，让AI助手为你搭建一个场景（Scenario）的基本骨架，并且能够解释该场景如何运作，甚至帮助你排查错误。

离国内用户更近的一个例子是8月25日钉钉提出的AI表格助理，其背后目的同样是大幅降低搭建工作流的难度。钉钉AI表格助理正式上线后，用户只需通过自然语言对话描述想法，它就能按要求自动生成AI表格、自动化工作流以及数据分析仪表盘，从而创造出一个个真正可用的AI应用。这极大地降低了AI表格的使用门槛，让每个人都有可能成为AI应用的创造者。

Image

上述案例都应归属于同一种思路：在积累足够数据的前提下（例如已经拥有大量HR招聘工作流的提示词或编排数据），采用智能体（Agent）的思路来降低专业知识的转化成本。不过，从各方面的评测和反馈来看，整体效果目前还比较初级。这紧接着引出一个问题：为什么“AI Workflow Builder”这类工具会存在？

AI Workflow 的意义

先说结论，对于普通用户而言，核心痛点在于：工作流太难搭建了！ 像n8n这样的工具更偏向程序员使用，对产品经理都不算友好。而像Coze这样的平台对产品经理友好了，但对于医生、律师等非互联网行业的专业人士来说，依然存在障碍。这里的难点主要有两个：

第一，工具本身的使用繁琐。就我个人体验而言，掌握Coze、n8n并不算难，但也花了近两周时间熟悉它们的各种功能和组件。在完全熟悉之前，虽然没有遇到无法解决的技术卡点，但整个过程确实非常耗时。例如，为了弄懂Coze中的循环逻辑，我就花费了大约两个小时。

第二，梳理标准作业程序（SOP）极其麻烦，这才是真正的难点。只要是工作流类的AI应用，其价值核心往往取决于工作流的数量和质量。而这又带来两个挑战：一是需要对相关工种业务有基本理解；二是团队在实际沟通过程中往往需要反复磨合，非常耗费精力。下图是我们梳理的一个HR工作流示例，可以直观感受其复杂性： Image Image

接下来，让我们集中注意力，一起推演一个更深入的演进逻辑。这部分内容通常在我的AI培训课中作为付费内容讲解，为了便于大家理解，这里以医生为例进行说明（律师、教师等其他专业领域的逻辑是相通的）。

AI数字分身的演进逻辑

假设你是一名拥有十年经验的心内科医生，大学期间的专业是计算机科学（并且水平相当不错，这些年偶尔接点技术副业）。于是，你同时具备了深厚的医学专业知识与扎实的工程技术能力。

你医术高超，一天能接诊100名病人。但由于名声在外，实际想找你看病的患者超过1000人。其中，超过900名患者的问题非常基础，根本不需要你亲自处理。

于是，你拿起技术的武器，为自己的日常工作搭建了一套工作流AI系统，并为其设计了专用的数据结构（或者说运用了上下文工程），将自己心内科的专业知识结构化地融入了进去。

这个心内科数字分身上线后广受好评，它出色地解决了你90%的患者咨询。随后，你的妻子（一名眼科医生）、你的小舅子（一名神经内科医生）甚至你的朋友（一名心理科医生）都希望使用这套系统。

于是，你开始进行抽象化工作：将你的工作流逻辑与具体的心内科数据进行剥离，只保留一个基本的智能体（Agent）框架，用于承载工作流代码（通常是JSON结构）和新的数据。最终，你实现了一个类似于Coze的系统，交给了他们使用。

然而，你的妻子、小舅子和朋友并不买账。他们认为你这个想法太“技术直男”了——那种复杂的拖拽式工作流编排，他们哪有能力完成？更何况还要整理那么多结构化的数据，这简直是要命的工作。

在他们的不断督促下，你不得不对系统进行进一步的简化，核心目标有两点：

第一，让普通人能够通过更自然的语言描述来生成工作流。 但大语言模型并没有那么聪明。无奈之下，你不得不为每个科室预先创建了数十套常见的工作流模板。这样，当你妻子这样的非技术用户用自然语言描述需求时，模型就能根据这些模板，尽可能准确地生成对应的工作流JSON配置。

第二，让普通医生能够上传他们容易获取的数据（如医患对话记录、病历信息），然后系统自动生成AI所需的结构化专业数据。 为了实现这一点，你至少又做了两方面工作：首先，想办法利用自己积累的医患对话和病历数据，生成与你历史沉淀的数据格式相同的内容；然后，按照这套逻辑，为其他各个科室也生成基础的数据集模板，但允许医生在此基础上进行最简单的修改。

完成这两项改进耗费了你大量的精力。最终，当新系统交付给妻子他们使用时，你终于获得了一个“点赞”。这时你才深刻意识到：他们真的是一点多余的操作都不想有！

以上就是AI数字分身的演进逻辑，事实上，这也是从n8n式的工作流拖拽编排，演进到AI Workflow自然语言生成的底层逻辑。接下来，让我们看看n8n的实际情况。

AI Workflow 实测

在 n8n Cloud 界面中进入 AI Workflow Builder，用户可以在对话框中输入需求，系统会提供实时生成进度反馈，并且允许用户追加指令对已生成的工作流进行迭代优化。

注：当前 AI Workflow Builder 处于 Beta 测试阶段，使用自然语言指令会消耗一定的平台积分。

总体体验下来，该功能的定位似乎是帮助具有一定技术背景但非专业开发人员的用户，快速将领域知识（Know-How）转化为可运行的 n8n 工作流。

这里有一个关键问题：n8n生成的工作流是AI完全原创的全新流程，还是系统内部通过检索和组合已有工作流模板实现的？

n8n 官方维护着一个庞大的工作流模板库，公开的社区模板数量超过 6000 个。如此丰富的现有流程，理论上完全可以作为“范例”供AI重用。这个问题的答案，关系到AI生成流程的独创性与可靠性。

如果是完全原创生成，流程可能更灵活，但也更容易出现错误配置或产生不符合逻辑的“幻觉”节点；如果是基于现有模板的复用与组装，输出质量可能会更稳定，但创新性可能不足。

推论实现策略

n8n 的工作流本质上是由 JSON 格式定义的，包括节点列表、连接关系以及各节点的参数等。我们获取了一份由 AI Workflow Builder 生成的示例工作流 JSON，下面截取其中的关键结构片段：

{
  "name": "AI Generated Workflow",
  "nodes": [
    {
      "id": "1",
      "name": "Gmail Trigger",
      "type": "n8n-nodes-base.gmailTrigger",
      "parameters": { ... }
    },
    {
      "id": "2",
      "name": "AI Agent",
      "type": "@n8n/nodes-base.openai",
      "parameters": { ... }
    },
    {
      "id": "3",
      "name": "Slack",
      "type": "n8n-nodes-base.slack",
      "parameters": { ... }
    }
  ],
  "connections": {
    "Gmail Trigger": {
      "main": [[ { "node": "AI Agent", "type": "main", "index": 0 } ]]
    },
    "AI Agent": {
      "main": [[ { "node": "Slack", "type": "main", "index": 0 } ]]
    }
  }
}

示例说明：假设用户提示“监控Gmail新邮件，用AI总结内容后发送Slack通知”，AI生成了上述包含Gmail触发器 → AI总结节点 → Slack发送节点的流程结构。

我们进行了多组测试，使用描述相近但略有差异的自动化需求，让 AI Workflow Builder 分别生成工作流，并比对它们的节点构成与连接结构。结果发现，一些功能类似的工作流确实呈现出高度相似的模式。

此外，来自社区的信息也提供了佐证。有第三方开发者构建了一个理念类似于官方AI Builder的n8nBuilder AI工具，并公开了其用于指导底层大语言模型的系统提示词（System Prompt）片段。其中明确要求模型：“将这些范例用作类似用例的模板；复制示例中的节点结构、参数格式和连接模式。”

因此，n8n的AI Builder很可能采用的是 “模板检索 + 微调” 的工作模式。

这并非坏事，甚至对于追求稳定性的工作流AI项目来说，这反而是更愿意看到的实现方式。

AI Builder 的真正意义

正如在“AI数字分身演进”部分所描述的，AI Builder 的核心意义仍然在于降低使用门槛。只不过，我认为其目标用户可能并非完全不懂技术的“小白”。

单就使用门槛而言，对于普通用户，n8n绝对高于Coze、Dify、FastGPT等更偏重应用层的平台。因此，即便AI生成了大部分工作流框架，仍然有许多参数需要手动配置，如下图所示： Image

请相信，对于像前文例子中“你妻子和小舅子”那样的用户，他们依然可能玩不转这些配置，并且多一步操作都不想进行！

所以，我认为AI Builder更大的意义在于证明了一种可行性：基于海量成熟的工作流模板，n8n可以快速生成一个符合你80%需求的算法（工作流）框架！

举个例子，如果我想实现一个HR场景的降本增效方案，但又希望实现“无痛零启动”，那么此时利用AI Builder快速生成一个基础框架，体验就会非常顺畅。

AI Workflow 与 AI Code

这场由OpenAI AgentKit点燃的 “工作流拖拽之王” 争夺战，在不知不觉中被引向了 “低代码”与“自然语言生成”两种技术路径的竞争。事实上，这并非偶然，从前段时间钉钉发布会力推AI表格助理就可见端倪。

这一切背后指向的是一个更根本的问题：我们究竟需要将门槛降低到什么程度，才能让每一个垂直领域的专家，都成为AI应用的生产者？

从拖拽编排到自然语言生成，n8n清晰地勾勒出一条技术普惠的演进路径。它不再强求AI从零开始去“创造”或“猜测”，而是转向基于海量模板库的 “检索-组装-微调” 模式。

这看似是对大模型当前能力不足的一种妥协，实则是AI项目实践心态的成熟：AI的目标不是生成一个完美无缺、充满创意的代码或流程，而是要准确理解用户的意图，并调用那些已被大量实践验证过的可靠模块，快速组装出一个稳定、可用的解决方案。

然而，n8n真正的对手或许并非AgentKit（Coze或许可以努力成为对手之一），所有工作流类低代码平台实际上都应该警惕的是**AI Code（AI代码生成）**的发展。

我们不得不重视一个正在发生的趋势：AI Code 与 各类Agent平台，可能正在完成功能高度重叠的事情。

虽然，AI Workflow更擅长处理流程类、集成类的“流水线”工作，而AI代码生成则擅长“从无到有”地编写定制化业务逻辑。

但是，我看这个界限未来可能会逐渐模糊。因为GitHub等平台上有太多优质的开源代码，尤其是在前端开发领域，几乎不存在AI“没见过”的页面实现（前端代码）！

注：比如近期Manus 1.5模型发布，其在前端编程方面就表现出了特别强大的能力。

让我们回归主题。这场 “将专业知识通过自然语言直接翻译成可执行方案”的混战，究竟是低代码平台通过集成AI实现真正的自然语言编程（走向无代码），还是AI代码生成能力一统天下，目前都还为时过早。简单来说：

无所谓，谁能稳定地把“可复用的高质量范式”这件事搞明白，我们就用谁。

而且从实现底层来看，AI Workflow 和 AI Code 的相似度其实很高：AI Workflow 是通过学习大量JSON配置来生成目标JSON；AI Code 是通过学习大量源代码来生成目标代码。只是它们的执行环境不同罢了。相较而言，AI Code触及的层次更为底层。

更进一步说，AI Workflow的目标不是取代工程师，而是让工程师能把精力集中在真正需要人类智慧的那20%的工作上。只不过，它未来可能需要变得更加智能。因为根据我的研究体验，它目前并不能节省我梳理SOP（标准作业程序）的时间，它所节约的，恰恰是那些我擅长但觉得重复、不关注的部分。

最后，我们必须注意一件事：无论是AI Workflow还是AI Code，它们想要变得更智能，背后一定需要“吞食”更多的生产案例和数据。那么，你的业务知识和数据安全，在某种程度上可能就难以得到绝对保障了。