n8n 中文教程：情感分析 、信息提取与文本分类

n8n 零代码 AI 节点深度解析：情感分析、信息提取与文本分类实战教程

大家好，我是翔宇，n8n“翔宇工作流”的作者。在日常工作和自动化流程搭建中，我们经常会遇到处理大量文本信息的需求。比如，想知道客户对新产品的反馈是正面还是负面？想从一堆邮件中快速提取出关键的联系人信息和订单号？或者，想把雪片般飞来的工单自动分配给正确的处理部门？这些任务如果纯靠人工，不仅效率低下，还容易出错。幸运的是，n8n 提供了强大的 AI 节点，即使没有任何编程基础，我们也能轻松利用人工智能来解决这些问题。

在最新版的 n8n 中，有三个特别实用的 AI 节点，它们分别是：情感分析 (Sentiment Analysis) 节点、信息提取 (Information Extractor) 节点和文本分类 (Text Classifier) 节点。这三个节点就像是我们的智能助手，能够帮助我们理解文本的情感色彩、从非结构化文本中提取结构化数据，以及将文本自动归类。它们的价值在于，能够极大地提升我们处理文本信息的效率和准确性，把我们从繁琐的重复劳动中解放出来，去关注更有创造性的工作。

本教程将以我——翔宇的视角，结合我的实战经验，为零代码基础的读者详细解读这三个 AI 节点。我们将深入探讨每个节点的功能定位、核心价值、输入输出数据结构、各项参数配置的含义与实战理解、数据映射技巧、常用应用场景、常见报错及解决方案，以及使用中的注意事项。希望通过这篇深度教程，能帮助大家轻松掌握这些强大的 AI 工具，让你的 n8n 工作流如虎添翼，更加智能高效。

接下来，就让我们一起进入 n8n 的 AI 世界，逐一探索这三个神奇节点的奥秘吧！

第一章：n8n 中文教程：情感分析 (Sentiment Analysis)

情感分析节点，顾名思义，就是帮助我们分析文本中蕴含的情感色彩。在翔宇看来，这个节点就像一个“情感温度计”，能够感知文本是积极的、消极的还是中性的，甚至可以定义更细致的情感类别。

1.1 节点概览

1.1.1 节点功能定位与核心价值

情感分析节点的核心功能是利用语言模型来解读和判断输入文本的情感倾向 。想象一下，你收集了大量的用户评论或者社交媒体上关于你品牌的讨论，如果一条条去看用户的情绪，那简直是大海捞针。情感分析节点就能自动完成这项工作，快速告诉你整体的情感趋势，哪些是好评，哪些是抱怨。

它的核心价值在于：

• ​自动化情感洞察​：自动识别文本中的情感，无需人工阅读和判断，大大节省时间。
• ​快速响应与决策​：及时了解用户情绪，比如发现大量负面反馈时可以迅速介入处理，或者根据积极反馈调整营销策略。
• ​提升用户体验​：通过分析客户服务对话的情感，可以评估服务质量，发现改进点。
• ​市场趋势分析​：监控特定话题或品牌在公众中的情感走向，辅助市场决策。

对于零代码用户来说，这个节点提供了一个非常便捷的方式去利用先进的 AI 能力来理解文本背后的“喜怒哀乐”，而不需要关心复杂的算法实现。

1.1.2 输入 (Input) 与输出 (Output) 数据结构

在 n8n 中，节点之间的数据传递遵循特定的结构。通常，数据是以一个包含多个“项目 (item)”的数组形式存在的，每个“项目”都是一个对象，其核心数据存储在名为 json 的键对应的对象中 。情感分析节点也不例外。

• 输入数据结构 (Input Data Structure)
  情感分析节点期望接收的输入项目中，包含一个用于分析的文本字段。默认情况下，它会寻找名为 text 的字段。
  例如，如果你的工作流从一个 RSS 订阅源获取文章，然后想要分析每篇文章的情感，那么输入到情感分析节点的数据可能如下所示：
  JSON[ { "json": { "title": "n8n 新功能发布，自动化更强大！", "content": "今天 n8n 发布了令人激动的新版本，增加了许多强大的功能，用户体验大幅提升，社区反响热烈。", "link": "http://example.com/news/123" } }, { "json": { "title": "某产品更新引争议", "content": "最新更新后，不少用户抱怨操作变得复杂，性能似乎也有所下降，希望官方能听取用户意见。", "link": "http://example.com/news/124" } } ] ​在这个例子中，我们可能希望分析 content 字段的情感。我们会在节点的“Text to Analyze”参数中通过表达式 {{ $json.content }} 来指定它。
• 输出数据结构 (Output Data Structure)
  情感分析节点处理完输入数据后，会在每个项目的 json 对象中添加一个新的字段，通常名为 sentiment（或者由连接的语言模型决定，但一般会包含情感分类结果），其中包含了分析得到的情感类别。如果开启了“Include Detailed Results”选项，还会包含情感强度和置信度得分 。
  以上述输入为例，经过情感分析节点处理后（假设情感类别为 Positive, Neutral, Negative），输出可能如下：
  JSON[ { "json": { "title": "n8n 新功能发布，自动化更强大！", "content": "今天 n8n 发布了令人激动的新版本，增加了许多强大的功能，用户体验大幅提升，社区反响热烈。", "link": "http://example.com/news/123", "sentiment": { "category": "Positive" // 如果开启详细结果，可能还有 "strength" 和 "confidence" 字段 } } }, { "json": { "title": "某产品更新引争议", "content": "最新更新后，不少用户抱怨操作变得复杂，性能似乎也有所下降，希望官方能听取用户意见。", "link": "http://example.com/news/124", "sentiment": { "category": "Negative" } } } ] ​翔宇提示：输出的具体字段名称和结构可能因所连接的语言模型服务而略有差异，但核心的情感分类结果是会包含的。在实际使用中，最好执行一次节点，然后查看输出结果，以明确具体的字段名。

1.2 参数与配置

情感分析节点的参数配置直接影响其分析的准确性和适用性。下面我们逐一解析每个配置项的含义，并结合翔宇的实战理解。

• Text to Analyze (待分析文本)
  • ​含义​：这个参数用来指定输入数据中哪个字段包含了需要进行情感分析的文本内容。它需要一个表达式来引用该字段。
  • ​翔宇的实战理解​：“这是告诉节点‘你要分析哪段话’。比如，如果上一个节点传过来的数据里，客户评论放在 customer_review 字段，那你这里就要填 {{ $json.customer_review }}。如果你的文本在一个更深的层级，比如 {{ $json.details.comment }}，也要正确写出来。初学者最容易犯的错误就是这里引用的字段名和实际输入数据中的不一致，导致节点拿不到文本。”
  • ​默认值​：{{ $json.text }}。这意味着节点默认会尝试从输入数据的 json 对象下的 text 字段读取文本。
  • ​可选值​：任何能够正确指向包含文本字段的有效 n8n 表达式。
• Sentiment Categories (情感类别)
  • ​含义​：这里定义了你希望将文本情感划分成的类别。语言模型会基于这些类别来判断输入文本的情感归属。
  • ​翔宇的实战理解​：“这个很有意思，你可以自定义情感的‘标签’。比如，除了常见的‘正面’、‘中性’、‘负面’，你还可以根据业务需求设置成‘非常满意’、‘满意’、‘一般’、‘不满意’、‘非常不满意’，这样分析结果就更细致。或者，在分析产品反馈时，可以设置为‘喜爱’、‘期待’、‘困惑’、‘失望’、‘愤怒’等更具体的情绪。定义的类别越贴合你的分析目标，结果就越有价值。”
  • ​默认值​：Positive, Neutral, Negative (正面, 中性, 负面)。
  • ​可选值​：一个或多个自定义的类别名称，用逗号分隔。例如：开心,难过,平静 或 Urgent, Not Urgent。
• Include Detailed Results (包含详细结果)
  • ​含义​：开启此选项后，节点的输出除了基本的情感类别外，还会包含情感强度 (strength) 和置信度得分 (confidence scores)。
  • ​翔宇的实战理解​：“这些分数是语言模型给出的估计值，可以作为参考，但不要认为是绝对精确的测量。比如，一个‘Positive’的情感，强度可能是 0.8，置信度可能是 0.95。这能帮你判断情感的强烈程度和模型对判断的把握有多大。但对于初学者，可以先不开启，只关注基本的情感类别，避免信息过载。”
  • ​默认值​：关闭 (false)。
  • ​可选值​：开启 (true) 或关闭 (false)。
• System Prompt Template (系统提示模板)
  • ​含义​：允许你修改用于情感分析的系统提示。系统提示是给语言模型的指令，告诉它任务是什么。这个模板中使用 {categories} 作为占位符，n8n 会自动用你在“Sentiment Categories”中定义的类别替换它。
  • ​翔宇的实战理解​：“这是个高级选项，通常情况下用默认的提示就够了。但如果你发现分析结果不理想，比如模型总是把某些中性评论误判为负面，你可以尝试修改这个系统提示，给模型更明确的指导。比如，你可以强调‘请专注于文本的直接情感表达，忽略可能的讽刺语气’。修改这里需要一些对语言模型提示工程的理解，新手建议谨慎操作，或者先不修改。”
  • ​默认值​：n8n 内置一个默认的系统提示。
  • ​可选值​：自定义的提示文本字符串。
• Enable Auto-Fixing (启用自动修复)
  • ​含义​：如果启用，当语言模型的输出不符合预期的格式时，节点会尝试将格式错误信息反馈给模型，并要求模型修正其输出。
  • ​翔宇的实战理解​：“这个功能是为了提高输出的稳定性。有时 AI 模型可能返回一些格式不太对的结果，开启这个选项，n8n 会尝试让 AI ‘自我纠错’。不过，这也会增加一点点处理时间和潜在的 AI 调用成本。如果你的流程对输出格式要求非常严格，可以开启它。但通常，保证输入文本质量和清晰的类别定义更重要。”
  • ​默认值​：关闭 (false)。
  • ​可选值​：开启 (true) 或关闭 (false)。

除了以上节点自身的参数，还有一些与连接的语言模型相关的通用建议：

• 模型温度设置 (Model Temperature Setting)
  • ​翔宇的实战理解​：“强烈建议将你连接的语言模型（比如 OpenAI 节点）的‘Temperature’参数设置为 0 或非常接近 0 的值。Temperature 控制输出的随机性，值越高，输出越随机、越有创意；值越低，输出越确定、越一致。对于情感分析这类任务，我们通常希望结果是稳定和可复现的，所以低 Temperature 更合适。”
• 语言考虑 (Language Considerations)
  • ​翔宇的实战理解​：“情感分析的效果也取决于输入文本的语言和所选语言模型对该语言的支持程度。如果你的文本是中文，确保你连接的 AI 模型对中文情感的理解能力较好。有些模型可能在英文上表现优异，但在其他语言上效果会打折扣。”
• 处理大量数据 (Processing Large Volumes)
  • ​翔宇的实战理解​：“如果要分析非常大量的文本数据，比如成千上万条评论，一次性全部分析可能会很慢，甚至超出某些模型的处理限制。这时，可以考虑使用 n8n 的‘Split In Batches’节点，将数据分成小批量进行处理，这样更稳定高效。”
• 迭代优化 (Iterative Refinement)
  • ​翔宇的实战理解​：“对于复杂的情感分析任务，可能需要反复试验和调整。比如，你可能会发现最初定义的类别不够准确，或者系统提示需要优化。这是一个不断尝试、观察结果、然后改进配置的过程。不要期望一次就能完美，多动手尝试几次，就能找到最适合你场景的设置。”

1.3 数据映射与表达式

数据映射和表达式是 n8n 的核心功能之一，它们使得我们能够动态地处理和传递数据。对于情感分析节点，主要涉及两个方面：如何将需要分析的文本正确地输入到节点，以及如何使用节点输出的情感分析结果。

• 表达式写法基础
  在 n8n 中，表达式通常写在双花括号 {{ }} 内 。通过表达式，你可以访问来自前面节点的数据、当前节点的参数、工作流的元数据等。
  • ​访问上一个节点的输出数据​：最常用的是 $json 变量，它代表上一个节点输出的单个项目 (item) 中的 json 对象。例如，如果上一个节点输出的数据结构是 {"json": {"comment": "这段文本很棒"}}，那么可以用 {{ $json.comment }} 来获取 “这段文本很棒” 这段内容。
  • ​访问特定节点的输出数据​：如果你想引用不是紧邻上一个节点的某个特定节点的输出，可以使用 $('节点名称').item.json.字段名 的形式。例如 {{ $('读取邮件').item.json.body }}。
  • ​使用内置函数和方法​：n8n 表达式支持一些内置的 JavaScript 方法和 n8n 特有的辅助函数，比如处理日期、字符串操作等 。
• 将文本映射到“Text to Analyze”参数
  这是情感分析节点最关键的数据输入环节。你需要确保“Text to Analyze”参数中的表达式能够准确地指向包含待分析文本的字段。
  ​翔宇的映射技巧​：
  1. ​检查数据源​：在配置情感分析节点之前，先运行一次前面的节点，并查看其输出结果。仔细观察包含目标文本的字段名和它在 JSON 结构中的层级。
  2. ​使用变量选择器​：在 n8n 的表达式编辑器中，通常会有一个“Variables”或“输入数据”面板，它可以展示当前节点能访问到的数据结构。你可以直接从这个面板点击选择相应的字段，n8n 会自动生成正确的表达式。这对于初学者来说非常友好，可以减少手写表达式出错的概率。
  3. ​处理可能的空值​：有时，输入的文本字段可能是空的。如果直接传递一个空值给情感分析节点，可能会导致错误或不准确的结果。你可以使用表达式进行简单处理，例如：{{ $json.review_text | | "内容为空" }}。这里的 || "内容为空" 表示如果 review_text 字段不存在或为空，则使用 “内容为空” 作为替代。当然，更好的做法可能是在情感分析之前用一个 IF 节点判断文本是否为空。
• 使用情感分析节点的输出
  情感分析节点输出的情感类别（以及可能的详细得分）通常用于后续的逻辑判断和流程分支。
  ​翔宇的映射技巧​：
  1. ​定位情感结果字段​：如前所述，情感分析结果通常在输出项目的 json 对象下的某个字段里，比如 sentiment.category。你需要根据实际输出确定这个路径。
  2. ​在 IF 节点中使用​：最常见的用法是将情感分析结果传递给一个 IF 节点，根据不同的情感类别执行不同的操作。例如，IF 节点的条件可以设置为：
     • {{ $json.sentiment.category === "Positive" }} -> 执行发送感谢邮件的操作。
     • {{ $json.sentiment.category === "Negative" }} -> 执行创建紧急工单并通知客服的操作。
  3. ​在 Switch 节点中使用​：如果情感类别比较多，使用 Switch 节点（在 n8n 中可能通过多个 IF 节点或 Router 节点实现类似功能）会更清晰。每个分支对应一个情感类别。
  4. ​存储分析结果​：你可能希望将情感分析结果和原始文本一起存储到数据库或电子表格中。这时，可以在后续的数据库节点或 Google Sheets 节点中，将 {{ $json.sentiment.category }} 等字段映射到相应的列。
• 常见易错点
  1. ​字段名大小写错误​：JSON 中的字段名是区分大小写的。{{ $json.Text }} 和 {{ $json.text }} 是不同的。务必确保表达式中的字段名与实际数据中的完全一致。
  2. ​路径错误​：如果数据嵌套较深，例如 {{ $json.data.comment.text }}，少写或错写了任何一级路径都会导致无法获取数据。
  3. ​忘记双花括号​：所有的 n8n 表达式都必须用 {{ }} 包裹。
  4. ​对数组和对象的误解​：n8n 的数据项通常是对象。如果某个字段本身是一个数组或包含更复杂的结构，访问方式会有所不同。例如，如果是数组的第一个元素的某个属性，可能是 {{ $json.list_of_comments.text }}。
  5. “Can’t get data for expression”错误：这个错误提示 n8n 无法根据你的表达式找到数据。常见原因包括：引用的节点尚未执行、引用的节点名错误、表达式中的字段路径错误、或者上游节点确实没有输出该数据。翔宇建议从引用的节点开始逐步测试，检查每一步的输出是否符合预期。
  6. “Invalid syntax”错误：表达式本身的语法有问题，比如括号不匹配、操作符使用错误等。仔细检查表达式的拼写和结构。
  翔宇建议，对于初学者，多利用 n8n 界面右侧的“节点输入数据”和“节点输出数据”面板来观察和理解数据流，这对于编写正确的表达式非常有帮助。

1.4 应用场景

情感分析节点在各种自动化流程中都有广泛的应用。翔宇根据自己的经验，分享几个常用的场景，希望能给大家带来启发。

1.4.1 节点的翔宇常用应用场景

• 场景一：分析客户填写的反馈表或问卷调查
  • ​需求​：翔宇通过在线表单收集客户对产品或服务的反馈，希望快速了解客户的整体满意度和主要意见。
  • ​工作流设想​：
    1. ​触发器​：使用表单提交触发器 (如 Google Forms, Typeform 触发器) 或 Webhook 节点接收表单数据。
    2. ​数据提取​：从表单数据中提取出客户填写的开放式评论文本字段。
    3. ​情感分析​：将评论文本送入 Sentiment Analysis 节点，情感类别可以设置为“非常满意, 满意, 一般, 不满意, 非常不满意”。
    4. ​结果处理与通知​：
       • 将分析结果（原始评论、情感分类）存入 Google Sheets 或数据库，方便后续统计分析。
       • 如果出现“不满意”或“非常不满意”的反馈，通过 IF 节点判断，并自动发送邮件或 Slack 消息给客服团队，要求及时跟进。
  • ​翔宇的理解​：“这个流程能让我第一时间掌握客户的声音。特别是负面反馈，能快速响应，有助于提升客户关系。同时，定期的情感统计也能反映出产品或服务的改进方向。”
• 场景二：监控社交媒体上关于品牌或产品的评论
  • ​需求​：翔宇希望了解其品牌或某个新产品在社交媒体（如微博、Twitter、论坛）上的口碑和用户情绪。
  • ​工作流设想​：
    1. ​触发器与数据获取​：
       • 使用定时触发器 (Schedule Trigger) 定期执行。
       • 通过 HTTP Request 节点调用社交媒体平台的 API（如果平台提供）或使用第三方爬虫服务（需注意合规性）抓取相关的帖子或评论。
       • 也可以使用如 Twitter 节点的特定应用节点来获取提及 (mentions)。
    2. ​文本预处理​：可能需要对抓取到的文本进行一些清洗，如去除无关字符、链接等。
    3. ​情感分析​：将处理后的评论文本送入 Sentiment Analysis 节点，类别可设为“正面, 中性, 负面”。
    4. ​数据聚合与可视化​：
       • 将分析结果存入数据库。
       • 可以进一步将数据推送到数据可视化工具（如 Google Data Studio, Metabase）生成情感趋势图表。
       • 对于突发的集中负面评论，可以设置阈值，通过 IF 节点判断后发送警报给公关团队。
  • ​翔宇的理解​：“社交媒体是用户真实想法的聚集地。通过情感分析，可以及时发现潜在的品牌危机，或者捕捉到用户对某个营销活动的积极反响。这比人工刷评论效率高太多了。”
• 场景三：对客服邮件或聊天记录进行情感分类
  • ​需求​：翔宇希望评估客服团队的服务质量，并识别出哪些客户对话中存在不满情绪，以便重点关注和改进。
  • ​工作流设想​：
    1. ​数据源​：
       • 客服邮件：使用 Email Read IMAP 节点或 Gmail 节点读取客服邮箱中的邮件。
       • 聊天记录：如果客服系统支持 API，可以通过 HTTP Request 节点获取聊天记录；或者客服系统能通过 Webhook 推送记录。
    2. ​提取对话内容​：从邮件或聊天记录中提取客户的发言部分。
    3. ​情感分析​：对客户发言进行情感分析，类别可设为“满意, 一般, 不满”。
    4. ​分析与报告​：
       • 统计不同情感类别的对话数量，生成客服质量报告。
       • 将“不满”的对话标记出来，推送给主管进行复核或客户回访。
       • 结合 Twilio 等通信平台的集成，甚至可以根据情感分析结果触发不同的后续动作 。
  • ​翔宇的理解​：“客服对话的情感是服务质量的直接体现。通过自动化分析，不仅能减轻主管的抽查压力，还能更全面地了解客户的感受，找到服务中的痛点。”

这些只是情感分析节点应用的一部分。大家可以根据自己的具体业务需求，发挥想象力，将情感分析融入到各种自动化流程中，例如：对新闻文章进行情感倾向判断、分析员工匿名反馈的情绪、对产品评论进行细分打分等。核心在于，它提供了一种自动“解读”文本情感的能力，让机器也能理解字里行间的情绪。

1.5 常见报错及解决方案

在使用情感分析节点时，即使是零代码操作，也可能会遇到一些报错或不符合预期的情况。了解这些常见问题及其排查思路，能帮助我们更快地解决问题。

• 错误提示解析与排错思路
  1. 错误：“Input text is empty or invalid” (输入文本为空或无效)
     • ​解析​：这通常意味着传递给情感分析节点的“Text to Analyze”参数的文本内容是空的，或者不是有效的文本格式。
     • ​翔宇的排错思路​：
       • ​检查上游数据​：首先，回溯到情感分析节点的上一个节点，查看其输出。确保你希望分析的那个文本字段确实有内容。是不是上游节点就没有成功获取到数据？
       • ​检查表达式​：仔细核对“Text to Analyze”参数中的表达式是否正确指向了包含文本的字段。字段名、路径是否都准确无误？有没有大小写错误？
       • ​添加调试节点​：可以在情感分析节点前加一个 Set 节点或者 Function 节点，专门用来输出你将要分析的文本内容，看看它到底是什么。例如，在 Set 节点中创建一个新字段 debug_text，其值设置为你用于情感分析的那个表达式，然后运行到这个 Set 节点，查看 debug_text 的值。
  2. 错误：“Model connection error” 或类似 API 错误 (模型连接错误)
     • ​解析​：这表明 n8n 无法成功连接到你配置的语言模型服务（比如 OpenAI, Google Gemini 等）。
     • ​翔宇的排错思路​：
       • ​**检查凭证 (Credentials)**​：情感分析节点本身不直接处理凭证，但它依赖于连接到它的语言模型节点（例如 OpenAI 节点）。确保该语言模型节点中的 API 密钥等凭证是正确配置且有效的。是不是 API 密钥过期了？或者账户余额不足？
       • ​网络问题​：检查你的 n8n 实例是否有正常的网络连接，能够访问到语言模型服务的 API 地址。如果是自托管的 n8n，可能需要检查防火墙或代理设置。
       • ​模型服务状态​：偶尔，语言模型服务本身可能出现临时故障或维护。可以查看服务提供商的状态页面。
       • ​模型名称或参数错误​：在语言模型节点中，选择的模型名称是否正确？某些模型可能对特定区域或账户有限制。
  3. 错误：“Unexpected output format from model” (模型返回非预期格式)
     • ​解析​：语言模型返回的结果格式不是情感分析节点所期望的。
     • ​翔宇的排错思路​：
       • ​**检查“Enable Auto-Fixing”**​：尝试开启情感分析节点中的“Enable Auto-Fixing”选项，看是否能自动修正 。
       • ​简化情感类别​：如果自定义了非常复杂或模糊的情感类别，模型可能难以准确匹配，导致输出混乱。尝试简化类别定义。
       • ​调整系统提示​：如果熟悉提示工程，可以尝试修改“System Prompt Template”，更明确地指示模型输出期望的格式。
       • ​更换模型​：不同的语言模型在遵循格式指令方面的能力可能不同。如果持续遇到问题，可以尝试更换另一个模型。
  4. 错误：“Can’t get data for expression” (无法为表达式获取数据)
     • ​解析​：这个错误通常发生在后续节点引用情感分析节点的输出时，表示引用的路径或字段名不存在。
     • ​翔宇的排错思路​：
       • ​执行并检查输出​：先确保情感分析节点本身成功执行。然后，点击情感分析节点，查看其“Output Data”面板，仔细观察情感分析结果存储在哪个字段下（例如，是不是 sentiment.category，或者其他名称）。
       • ​核对后续节点的表达式​：在后续的 IF 节点或 Set 节点中，确保引用的表达式与情感分析节点的实际输出结构完全一致。
  5. AI 节点相关的通用错误
     • ​**“No prompt specified error”**​：虽然情感分析节点会自动构建大部分提示，但如果其依赖的语言模型节点本身配置不当（例如，期望从聊天触发器获取提示但实际没有），可能会间接影响。确保语言模型节点配置正确。
     • ​**“A Chat Model sub-node must be connected error”**​：情感分析节点需要一个语言模型节点（如 OpenAI Chat Model）连接到其“Language Model”输入端。如果没有连接，或者连接的是不兼容的节点，会出现此错误。
• 调试方法与日志定位技巧
  • ​分步执行与检查​：这是翔宇最常用的调试方法。从工作流的触发器开始，一步一步执行每个节点，每执行完一个节点，都立即查看该节点的输出数据。这样可以清晰地看到数据是如何变化的，问题出在哪一步就一目了然了。
  • ​利用“Pin Data”功能​：在节点上点击右键，选择“Pin Data”，可以将该节点的当前输出数据固定住。这样，即使你修改了前面的节点并重新执行，这个被固定的数据也不会改变，方便你针对特定的数据场景进行调试。
  • ​**查看执行日志 (Execution Log)**​：n8n 会记录每次工作流执行的详细日志。在 n8n 界面的“Executions”标签页，可以找到历史执行记录。点击某次执行，可以看到每个节点的执行状态（成功、失败）、输入输出数据、以及错误信息（如果有的话）。这是定位问题的关键信息来源。
  • ​简化工作流进行测试​：如果一个复杂的工作流出错了，可以尝试暂时禁用或删除一些非关键节点，构建一个只包含核心问题节点的简化版工作流进行测试。这样可以排除其他因素的干扰，更快定位问题。
  • ​使用 Set 节点进行中间值检查​：如前所述，可以在关键步骤之间插入 Set 节点，用它来输出你关心的中间变量的值。比如，在情感分析之前，用 Set 节点输出待分析的文本；在情感分析之后，用 Set 节点输出分析结果。
  • ​社区求助​：n8n 有一个非常活跃的社区论坛 。如果你尝试了以上方法仍然无法解决问题，可以将你的工作流 (JSON格式)、错误信息、以及你已经尝试过的排错步骤清晰地描述出来，到社区发帖求助。翔宇自己也经常在社区学习和帮助他人。
  翔宇提醒：对于 AI 节点，由于其行为不完全是确定性的（即使 temperature 设置为0，不同模型或版本也可能有细微差异），调试时更要关注输入数据的质量、参数配置的合理性，以及对 AI 能力的合理预期。

1.6 注意事项

在使用情感分析节点时，除了掌握配置和排错，还有一些重要的注意事项，能帮助你更好地利用它，并避免一些潜在的问题。

• 输入文本的质量至关重要
  • ​翔宇的经验​：“常言道‘垃圾进，垃圾出’。AI 模型再智能，如果给它的文本本身就含糊不清、充满错别字、或者上下文缺失，那么分析结果的准确性也会大打折扣。所以在将文本送入分析前，如果可能，进行一些预处理，比如纠正明显的拼写错误、去除无关的符号或标签，会有帮助。”
• 理解模型的局限性
  • ​翔宇的经验​：“当前的语言模型虽然强大，但并非完美。它们可能难以准确理解复杂的讽刺、反语、双关等。对于非常微妙或依赖深层文化背景的情感表达，AI 的判断可能会出错。所以，对分析结果要有一个合理的预期，特别是在关键决策场景，可以考虑结合人工复核。”
• 注意潜在的偏见 (Bias)
  • ​翔宇的经验​：“语言模型是在大量真实世界的文本数据上训练出来的，这些数据本身可能就带有一些社会偏见。因此，模型在进行情感分析时，可能会无意识地表现出这些偏见，比如对某些特定人群的言论更容易给出负面判断。在涉及敏感话题或人群时，要特别警惕这种可能性。”
• 成本和性能考虑
  • ​翔宇的经验​：“使用情感分析节点通常会调用外部的语言模型服务，这可能会产生费用，特别是处理大量文本时。你需要了解所选模型服务的计费方式。同时，分析文本也需要时间，如果实时性要求很高，需要选择响应速度快的模型，并考虑批量处理等优化方法。”
• Temperature 设置的一致性
  • ​翔宇的经验​：“再次强调，为了获得一致和可复现的情感分析结果，务必将连接的语言模型节点的 Temperature 参数设置为一个较低的值，比如 0 或 0.1。这样可以减少模型输出的随机性。”
• 语言支持的匹配
  • ​翔宇的经验​：“确保你选择的语言模型对你要分析的文本语言有良好的支持。如果用一个主要针对英文训练的模型去分析中文情感，效果可能不理想。查阅模型提供商的文档，了解其多语言能力。”
• 迭代优化你的类别和提示
  • ​翔宇的经验​：“不要期望一次配置就能达到完美效果。根据实际分析结果，不断回顾和优化你的‘Sentiment Categories’定义和（如有必要）‘System Prompt Template’。这是一个持续改进的过程。”
• 安全性考量：警惕提示注入 (Prompt Injection)
  • ​翔宇的经验​：“这是一个比较进阶但非常重要的安全点。如果你的输入文本来源于不受信任的外部用户（比如公开的评论区），那么需要警惕‘提示注入’的风险。恶意用户可能会在他们提交的文本中巧妙地插入一些指令，试图操纵语言模型的行为，让它做出一些非预期的判断或泄露信息。虽然情感分析节点本身可能风险较低，但如果你的工作流后续会基于AI的输出做一些敏感操作，就需要小心。对于这类场景，可以考虑对输入文本进行一些过滤，或者在系统提示中加入对抗提示注入的指令。”
• 数据隐私与合规 (GDPR 等)
  • ​翔宇的经验​：“如果你分析的文本中包含个人身份信息 (PII) 或其他敏感数据，务必遵守相关的数据隐私法规，如 GDPR。了解你的数据是如何被语言模型服务处理和存储的，是否会用于模型再训练等。在处理欧盟用户数据时尤其要注意数据是否会被传输到欧盟以外的地区。选择可信的、有明确数据处理协议 (DPA) 的模型服务商。”

遵循这些注意事项，可以帮助你更安全、更有效地使用情感分析节点，让 AI真正成为你工作流中的得力助手。

第二章：n8n 中文教程：信息提取 (Information Extractor)

信息提取 (Information Extractor) 节点是 n8n 中另一个强大的 AI 工具。翔宇把它比作一个“智能数据侦探”，它能从大段的非结构化文本（比如邮件内容、PDF文档、网页信息）中，按照你预设的规则，精准地找出并提取出你需要的结构化信息，比如姓名、邮箱、电话、订单号、产品名称、价格等等。

2.1 节点概览

2.1.1 节点功能定位与核心价值

信息提取节点的核心功能是利用语言模型，根据用户定义的输出数据结构（Schema），从输入文本中识别并抽取出特定的数据片段 。想象一下，每天要从几十上百封客户邮件中手动复制粘贴客户姓名、公司、联系方式到 CRM 系统，或者从一堆 PDF 合同中找出合同编号、签约日期、金额等关键信息，这些重复性的工作不仅耗时，还容易出错。信息提取节点正是为了解决这类问题而生。

它的核心价值在于：

• ​自动化数据录入​：从各种文本源自动提取关键信息，并将其转化为结构化的数据，免去人工复制粘贴的麻烦。
• ​提升数据处理效率​：大幅缩短从非结构化文本中获取特定数据的时间，加速后续的数据分析和业务流程。
• ​提高数据准确性​：相比人工提取，AI 在遵循明确规则的前提下，可以减少因疲劳或疏忽导致的错误。
• ​解锁非结构化数据的价值​：大量的商业信息隐藏在邮件、文档、报告等非结构化文本中，信息提取节点能帮助我们挖掘这些信息的价值。

对于零代码用户而言，这个节点最大的魅力在于，你不需要编写复杂的正则表达式或解析脚本，只需通过简单的配置告诉 AI 你想要什么信息，AI 就能帮你找到。

2.1.2 输入 (Input) 与输出 (Output) 数据结构

和 n8n 中的其他节点一样，信息提取节点也遵循标准的输入输出数据结构 。

• 输入数据结构 (Input Data Structure)
  信息提取节点期望的输入项目中，包含一个待提取信息的文本字段。这个文本可以是邮件正文、PDF 文件内容、网页文本等。
  例如，假设我们有一个工作流，当收到新的客户咨询邮件时触发，邮件内容如下：
  JSON ​在这个例子中，我们希望从 body_text 字段中提取出客户的姓名、邮箱、电话和公司名称。我们会在节点的“Text”参数中通过表达式 {{ $json.body_text }} 来指定它。
• 输出数据结构 (Output Data Structure)
  信息提取节点处理完输入数据后，会在每个项目的 json 对象中添加一个新的字段（通常是你自己定义，或者默认为 extracted_info 或类似名称，具体取决于节点版本和配置方式），这个字段的值是一个结构化的 JSON 对象，其内部的键值对就是根据你定义的 Schema 提取出来的信息 。
  以上述输入为例，如果我们定义 Schema 要求提取姓名 (name)、邮箱 (email)、电话 (phone) 和公司名 (company)，那么输出可能如下：
  JSON ​翔宇提示：这个输出结构最大的特点就是它的“形状”是由用户通过 Schema 定义的。这是它与情感分析节点（输出结构相对固定）的一个核心区别。定义一个好的 Schema 是用好这个节点的关键。社区中也有很多关于如何获取特定 JSON 结构的讨论，例如从 LLM 获取特定格式的 JSON 或 Markdown 。

2.2 参数与配置

信息提取节点的参数配置核心在于如何准确地告诉 AI 你想要提取什么信息，以及这些信息应该是什么样的。

• Text (待提取文本)
  • ​含义​：指定输入数据中哪个字段包含需要从中提取信息的文本内容。
  • ​翔宇的实战理解​：“和情感分析节点一样，这里要准确指定文本来源。比如 {{ $json.emailBody }} 如果邮件内容在 emailBody 字段，或者 {{ $json.product_description }} 如果是产品描述。如果文本来自上一个‘Extract from PDF’节点，那可能就是 {{ $json.text }}。”
  • ​默认值/可选值​：默认无，必须由用户通过表达式指定文本来源。
• Use Schema Type (使用模式类型)
  • ​含义​：这是配置信息提取规则的核心。它决定了你如何向 AI 描述你期望提取的数据的结构和含义。n8n 提供了三种方式来定义这个“模式” (Schema)。
  • ​翔宇的实战理解​：“这里是告诉节点‘你要帮我找哪些东西，找到了之后按什么格式放好’。有三种方法，你可以选一个你觉得最顺手、最能清晰表达你意图的方式。”
  • 选项 1: From Attribute Description (通过属性描述)
    • ​含义​：通过列出你想要提取的各个属性（即字段名），并为每个属性提供一段文字描述来定义模式。这段描述非常关键，它会指导 AI 去理解这个属性具体指的是文本中的哪部分信息。
    • ​翔宇的实战理解​：“这种方式比较直观，适合大多数场景，特别是当你对 JSON Schema 不太熟悉的时候。比如，我想从邮件中提取‘客户姓名’，我就会添加一个属性，名称可以叫 customer_name，然后在‘Description’（描述）里写：‘邮件中提到的客户的全名，通常在问候语或签名中可以找到，例如：李明、王小红女士’。描述写得越清晰、越具体，甚至给出一些例子，AI 提取得就越准确。我通常会在这里下点功夫，把每个想提取的字段都描述清楚。”
    • ​配置​：你需要点击“Add Attribute”来添加你想要提取的每一个信息点。对于每一个信息点，你需要填写：
      • ​**Name (名称)**​：你希望这个提取出来的信息在最终的 JSON 输出中叫什么名字（键名）。
      • ​**Description (描述)**​：详细描述这个信息是什么，它在原文中可能是什么样子的，有什么特征。
  • 选项 2: Generate From JSON Example (通过 JSON 示例生成)
    • ​含义​：如果你已经非常清楚你希望提取出来的数据最终应该是什么样的 JSON 结构，那么这种方式可以帮你快速生成模式。你只需要提供一个符合你期望结构的 JSON 示例，节点会自动分析这个示例的属性名和数据类型（比如是文本、数字还是布尔值），并据此生成内部的提取规则。注意，节点只关心你示例的“结构”（即有哪些字段，字段是什么类型），而不会关心你示例中填写的具体“值”。
    • ​翔宇的实战理解​：“这种方式适合目标明确、对 JSON 格式比较熟悉的用户。比如，我知道我最终想要一个包含姓名和订单数量的 JSON，像这样：{\"client_name\": \"示例姓名\", \"order_quantity\": 10}。我把这个示例粘贴进去，节点就能理解我要提取一个名为 client_name 的文本字段和一个名为 order_quantity 的数字字段。这比一个个添加属性描述要快一些。但记住，AI 只学习结构，不会真的去找‘示例姓名’这几个字。”
    • ​配置​：在提供的文本框中输入一个有效的 JSON 对象作为示例。
  • 选项 3: Define Below (在下方定义)
    • ​含义​：这是最灵活但也最复杂的方式。它允许你直接手动编写或粘贴一个完整的 JSON Schema 定义。JSON Schema 是一种用来描述 JSON 数据结构和约束的强大语言。通过它，你可以精确控制每个提取字段的数据类型 (string, number, boolean, array, object)、格式 (如 email, date-time)、是否必需 (required) 等等。
    • ​翔宇的实战理解​：“这个选项适合对 JSON Schema 规范有一定了解的高级用户。如果你需要非常精细地控制提取结果的结构和验证规则，那么这个选项是最佳选择。对于初学者，我通常建议先从前两种方式入手，等熟悉了再来挑战这个。如果你确实需要用到，可以搜索一些‘JSON Schema教程’来学习它的语法。n8n 官方文档也提到可以参考 JSON Schema 的指南和示例 。社区里有些讨论也涉及到具体的 Schema 结构，比如 和 展示了一些用户自定义或系统生成的 Schema 片段，可以作为参考。”
    • ​配置​：在提供的文本框中输入一个符合 JSON Schema 规范的有效 JSON Schema 定义。
• System Prompt Template (系统提示模板)
  • ​含义​：允许你自定义发送给语言模型的“系统级别”的指令。这个指令会在你的主要提取请求之前发送给 AI，用于设定 AI 的角色、任务目标或一些总体性的行为准则。n8n 会自动在这个系统提示的末尾附加一些关于如何遵循你所定义 Schema 的格式化指令。
  • ​翔宇的实战理解​：“和情感分析节点类似，这也是一个高级调整选项。大多数情况下，n8n 默认的系统提示已经足够好了，它会告诉 AI ‘你是一个专业的信息提取助手，请根据用户提供的 Schema 从文本中提取信息’之类的话。但如果你发现提取效果不佳，比如 AI 总是漏掉某些特定场景下的信息，或者对某些模糊表述理解有误，你可以尝试修改这里的系统提示，给 AI 更明确的、全局性的指导。例如，你可以补充一句：‘请特别注意识别文本中所有出现的人名和对应的公司名称，即使它们没有明确的标签。’ 不过，修改系统提示需要小心，要确保不会与 n8n 自动添加的格式化指令产生冲突。社区中曾有用户反馈，不当的系统提示或与自动附加指令的冲突，可能导致输出为空或行为异常 。所以，如果修改，一定要充分测试。”
  • ​默认值/可选值​：n8n 有一个内置的默认系统提示模板。用户可以输入自定义的文本字符串来覆盖默认模板。

选择哪种“Use Schema Type”方式，以及是否需要调整“System Prompt Template”，取决于你的具体需求和对这些概念的熟悉程度。翔宇建议初学者从“From Attribute Description”开始，它的配置最直观。当需求变得复杂或对输出格式有更精细的要求时，再考虑其他方式。

2.3 数据映射与表达式

信息提取节点的核心在于从非结构化文本中梳理出结构化数据。因此，数据映射的关键在于两点：一是如何把待分析的文本准确喂给节点，二是如何在后续流程中有效利用节点提取出来的结构化信息。

• 将文本映射到“Text”参数
  这一步与情感分析节点的“Text to Analyze”参数类似。你需要使用 n8n 的表达式功能，将包含源文本的字段准确地映射到信息提取节点的“Text”参数。
  ​翔宇的映射技巧​：
  1. ​确认源文本字段​：在配置信息提取节点前，务必运行其上游节点，并仔细查看输出数据。确定哪个字段包含了你需要提取信息的完整文本。例如，可能是 {{ $json.email_body }}，{{ $json.pdf_content }}，或者是通过 HTTP Request 节点获取的网页内容 {{ $json.html_response }}。
  2. ​利用表达式编辑器​：n8n 的表达式编辑器是你的好帮手。它可以列出当前节点可访问的所有上游数据字段。通过点击选择，可以自动生成正确的表达式，避免手动输入错误。
  3. ​处理长文本或特殊格式文本​：如果源文本非常长，或者包含很多 HTML 标签等“噪音”，直接提取可能会影响 AI 的效果和效率。可以考虑：
     • ​预处理​：在信息提取节点前，使用如 HTML Extract 节点去除 HTML 标签，或使用 Function 节点进行一些文本清洗。
     • ​分块提取​：对于过长的文本，可以考虑使用“Split In Batches”节点将其分割成小块，然后对每一块分别进行信息提取，最后再合并结果。社区中有用户遇到过因数据量大导致只提取部分数据的问题，分块处理是解决方案之一 。
• 使用信息提取节点的结构化输出
  信息提取节点最强大的地方在于它能输出一个结构化的 JSON 对象。这个对象内部的字段就是你通过 Schema 定义的那些属性。
  翔宇的映射技巧与常见用法：
  假设你在 Schema 中定义了要提取 name, email, 和 order_id，并且提取结果默认输出到名为 extracted_data 的字段中。那么，在一个典型的输出项目中，json 对象会变成类似这样：
  JSON{ "original_text_field": "...", // 原始文本字段 "extracted_data": { "name": "李小明", "email": "lixiaoming@example.com", "order_id": "ORD20240520001" } } ​在后续节点中，你可以这样访问这些提取出来的信息：
  1. ​访问单个提取字段​：
     • 获取姓名：{{ $json.extracted_data.name }}
     • 获取邮箱：{{ $json.extracted_data.email }}
     • 获取订单号：{{ $json.extracted_data.order_id }} 翔宇强调：“注意这个层级关系！提取出来的数据是在 extracted_data 这个对象下面的，所以引用的时候不能少了这一层。”
  2. 在 Set 节点中整理数据：你可能希望将提取出来的信息和原始数据中的其他字段组合成一个新的结构，或者重命名某些字段。这时 Set 节点非常有用。
     例如，创建一个 Set 节点，设置如下值：
     • customerName = {{ $json.extracted_data.name }}
     • contactEmail = {{ $json.extracted_data.email }}
     • orderNumber = {{ $json.extracted_data.order_id }}
     • originalSourceId = {{ $json.email_id }} (假设原始数据中有 email_id)
  3. ​在 IF 节点中进行条件判断​：根据提取到的信息做判断。
     • 例如，判断是否成功提取到邮箱：{{ $json.extracted_data.email!== undefined && $json.extracted_data.email!== "" }}
     • 例如，判断订单号是否为特定格式（这里只是简单示例，复杂验证可能需要 Code 节点）：{{ $json.extracted_data.order_id.startsWith("ORD") }}
  4. ​将数据写入 Google Sheets 或数据库​：在 Google Sheets 节点的“Columns”配置或数据库节点的字段映射中，可以直接使用上述表达式将提取到的各个字段分别填入对应的列。例如，在 Google Sheets 的“姓名”列填入 {{ $json.extracted_data.name }}。
• 常见易错点
  1. ​Schema 定义与实际文本内容不符​：如果你定义的 Schema 要求提取“发票号”，但输入的文本中根本没有类似信息，那么对应的字段很可能就是空的或者提取错误。AI 也不能无中生有。
  2. ​**Schema 描述不够清晰 (使用 From Attribute Description 时)**​：如果属性描述含糊不清，AI 可能无法准确理解你的意图，导致提取错误或遗漏。例如，只描述“日期”，AI 可能不知道是提取“订单日期”还是“发货日期”。
  3. ​**JSON 示例或 JSON Schema 语法错误 (使用 Generate From JSON Example 或 Define Below 时)**​：这两种方式对输入的 JSON 格式有严格要求。任何语法错误（如逗号用错、括号不匹配）都会导致节点配置失败或运行出错。务必使用 JSON 校验工具检查你的输入。
  4. ​引用输出字段时的路径错误​：这是初学者最常犯的错误之一。忘记了提取结果是嵌套在一个特定字段（如 extracted_data）下的，或者把字段名写错。再次强调，仔细查看信息提取节点的实际输出结构，是写对表达式的前提。
  5. ​对可选字段的处理​：Schema 中定义的某些字段可能在源文本中并不总是存在。如果你的后续流程强依赖某个提取字段，而该字段有时为空，就可能导致流程中断。需要在后续流程中考虑对空值的处理逻辑（例如，使用 IF 节点判断字段是否存在）。
  翔宇建议：“对于信息提取节点，‘试错和迭代’非常重要。先用一小段典型的文本测试你的 Schema 定义，看看提取结果是否符合预期。如果不符合，调整 Schema 或系统提示，再测试，直到满意为止。这个过程能让你更深刻地理解 AI 是如何根据你的指令工作的。”

2.4 应用场景

信息提取节点的应用场景非常广泛，几乎所有需要从非结构化文本中获取特定、结构化信息的任务都可以尝试使用它。翔宇结合自己的实践，分享几个常见的应用案例。

2.4.1 节点的翔宇常用应用场景

• 场景一：从客户邮件中自动提取联系人信息和关键业务数据
  • ​需求​：翔宇的公司每天都会收到很多来自潜在客户或现有客户的邮件，内容可能是咨询、报价请求、订单确认等。他希望能自动从这些邮件中提取出客户的姓名、公司名称、邮箱地址、电话号码，以及邮件中提到的产品型号、订单编号等关键信息，并自动录入到 CRM 系统或项目管理工具中。
  • ​工作流设想​：
    1. ​触发器​：使用 Email Read IMAP 节点或特定邮箱服务（如 Gmail）的触发器，监控新邮件。
    2. ​提取邮件正文​：从邮件数据中获取邮件正文内容。
    3. ​信息提取​：将邮件正文送入 Information Extractor 节点。
       • ​Schema Type​：可以使用“From Attribute Description”。
       • ​**Attributes (示例)**​：
         • contact_name (描述：邮件中提到的联系人姓名，可能是发件人或邮件中明确指出的其他人名)
         • company_name (描述：邮件中提到的公司名称)
         • email_address (描述：邮件中出现的有效邮箱地址，可能是发件人邮箱或正文中提及的其他邮箱)
         • phone_number (描述：邮件中出现的电话号码或手机号码)
         • product_model (描述：如果邮件提及特定产品型号，请提取出来)
         • order_id (描述：如果邮件包含订单编号，请提取，通常以ORD、SN等开头)
    4. ​数据处理与存储​：
       • 使用 Set 节点整理提取到的信息，并结合邮件主题、收件时间等元数据。
       • 将结构化数据通过相应的节点（如 HubSpot, Salesforce, Google Contacts, Airtable, Google Sheets）创建或更新联系人记录、销售线索或任务。例如，可以参考将数据写入 Google Sheets 或 Notion 的类似逻辑。
  • ​翔宇的理解​：“这个流程极大地解放了我的销售和客服团队。以前他们需要手动从邮件里复制这些信息，现在大部分都能自动完成。关键在于 Schema 的描述要写得足够好，让 AI 能准确识别。比如，对于‘电话号码’，描述里可以加上‘通常是11位手机号或包含区号的固定电话号码’这样的提示。”
• 场景二：从 PDF 格式的发票或合同中提取关键字段
  • ​需求​：翔宇需要处理大量的 PDF 发票和合同，从中提取出发票号、开票日期、供应商名称、总金额、合同有效期等信息，用于财务入账或合同管理。
  • ​工作流设想​：
    1. ​触发器​：可以使用 Watch Folder 节点监控特定文件夹中的新 PDF 文件，或者通过 Email Trigger 接收带附件的邮件。
    2. ​提取 PDF 文本​：使用 n8n 内置的“Extract from File”节点（选择 PDF 操作）将 PDF 文件内容转换为纯文本 。注意，扫描版的 PDF（图片格式）需要先进行 OCR 处理，n8n 本身不直接提供 OCR，但可以集成外部 OCR 服务。
    3. ​信息提取​：将从 PDF 提取出来的文本内容送入 Information Extractor 节点。
       • ​Schema Type​：根据发票或合同的复杂度，可以选择“From Attribute Description”或“Generate From JSON Example”。如果发票格式相对固定，提供一个 JSON 示例可能更高效。
       • ​**Attributes/JSON Example (示例 – 发票)**​：
         • invoice_number (发票号码)
         • issue_date (开票日期，格式如 YYYY-MM-DD)
         • vendor_name (销售方名称)
         • total_amount (价税合计金额，数字类型)
    4. ​数据存储与后续操作​：
       • 将提取到的结构化数据存入财务软件、ERP 系统（通过 API）或 Google Sheets 等电子表格中，用于记账或生成报告。社区中也有将提取数据存入 Google Sheets 的案例 。
  • ​翔宇的理解​：“处理 PDF 是个常见的痛点，特别是发票。这个流程能把关键信息自动抠出来，财务部门会非常感谢你。不过，PDF 文本提取的质量会直接影响信息提取的效果。如果 PDF 本身是机器生成的、文本可选的，那效果最好。如果是扫描件，那 OCR 的准确率就很重要了。”
• 场景三：从网页内容中抓取并结构化产品信息或新闻摘要
  • ​需求​：翔宇可能需要监控竞争对手网站上的产品价格和库存状态，或者定期从特定新闻网站抓取最新文章的标题、发布时间和摘要。
  • ​工作流设想​：
    1. ​获取网页内容​：使用 HTTP Request 节点，输入目标网页的 URL，获取网页的 HTML 源代码。
    2. ​**（可选）提取主要文本内容**​：如果 HTML 中包含大量导航、广告等无关信息，可以使用 HTML Extract 节点先粗略提取出正文部分，或者直接将完整 HTML 交给信息提取器（但效果可能受影响）。
    3. ​信息提取​：将网页文本（或 HTML）送入 Information Extractor 节点。
       • ​Schema Type​：“From Attribute Description” 通常比较适用。
       • ​**Attributes (示例 – 产品信息)**​：
         • product_name (产品标题或名称)
         • price (产品价格，数字类型，注意去除货币符号)
         • stock_status (库存状态，如“有货”、“缺货”、“预订”)
         • description_summary (产品描述的简短摘要)
    4. ​数据存储与通知​：
       • 将提取到的信息存入数据库或 Google Sheets，用于跟踪和分析。
       • 如果监控到价格变动或库存状态变化，可以通过 IF 节点判断并发送通知。
  • ​翔宇的理解​：“用这个节点做一些简单的网页信息抓取和结构化是可行的，比如监控少量关键信息。但要注意，网站结构可能会经常变化，这会导致提取规则失效，所以需要定期检查和维护。另外，抓取别人网站时一定要遵守对方的 robots.txt 规则，并且不要过于频繁地请求，以免给对方服务器造成不必要的负担。对于大规模或复杂的网页抓取，可能需要更专业的爬虫工具。”

这些场景展示了信息提取节点的多功能性。无论是处理内部文档、客户沟通，还是外部信息，只要你需要从文本中找出特定的、有结构的信息，都可以考虑使用它。核心在于设计一个清晰、准确的 Schema，并提供高质量的源文本。

2.5 常见报错及解决方案

信息提取节点由于其依赖 AI 对文本的理解和用户定义的 Schema，可能会出现一些特有的问题。了解这些常见报错及其排查方法，能让你在遇到问题时更加从容。

• 错误提示解析与排错思路
  1. 错误：输出为空，或关键字段缺失 (Output is empty or missing expected fields)
     • ​解析​：AI 未能按照你的 Schema 提取到任何信息，或者提取到的信息不完整，缺少了你期望的某些字段。
     • ​翔宇的排错思路​：
       • ​检查 Schema 定义的清晰度​：这是最常见的原因。
         • 如果使用“From Attribute Description”，你的描述是否太模糊，AI 无法理解？例如，你只写了“日期”，但文本中有多个日期，AI 不知道要哪个。尝试在描述中加入更多上下文，比如“订单提交日期”或“发货截止日期”，并给出示例格式。
         • 如果使用“Generate From JSON Example”，你的示例 JSON 结构是否能准确反映你想从文本中提取的所有信息类型？
         • 如果使用“Define Below”，你的 JSON Schema 是否编写正确，并且 required 字段等设置是否合理？
       • ​检查源文本​：你要提取的信息真的存在于输入的文本中吗？AI 也不能无中生有。可以手动阅读一下源文本，确认信息确实存在且可识别。
       • ​文本质量问题​：源文本是否包含大量噪音、格式混乱或 OCR 识别错误？这会严重干扰 AI 的提取。尝试在信息提取前进行文本清洗。
       • ​**系统提示模板 (System Prompt Template)**​：默认的系统提示通常能工作，但如果遇到顽固的提取问题，可以尝试微调系统提示，给 AI 更明确的指令，比如强调必须提取所有定义的字段，或者在找不到确切信息时如何处理。
       • ​翔宇的补充​：“我遇到过一种情况，就是文本太长了，AI 可能只处理了开头的一部分，导致后面的信息没提取到。社区里 Miquel 也提到过这个问题 。这时可以尝试用 n8n 的‘Split In Batches’节点把长文本切成小段，分批送给信息提取节点处理。”
  2. 错误：输出的 JSON 格式不正确，或不符合 Schema (Output format is incorrect / “JSON Output contains invalid JSON”)
     • ​解析​：AI 返回的结果不是一个有效的 JSON 字符串，或者虽然是 JSON，但其结构与你通过 Schema 定义的期望结构不符（比如字段名错误、数据类型不匹配等）。
     • ​翔宇的排错思路​：
       • ​严格检查 Schema 定义​：确保 Schema 定义（无论是属性描述、JSON 示例还是完整 JSON Schema）本身是准确无误的。字段名、期望的数据类型（字符串、数字、布尔等）是否都正确？
       • ​**查看 AI 模型的原始输出 (如果可能)**​：有些语言模型节点可能允许查看未经 n8n 解析的原始文本输出。如果发现原始输出就是有问题的 JSON（比如多了个逗号、括号不闭合），那说明 AI 在生成 JSON 时就出错了。
       • ​简化 Schema 测试​：尝试用一个非常简单的 Schema（比如只提取一个字段）来测试，如果成功，再逐步增加字段，看问题出在哪个字段的定义上。
       • ​**利用“Enable Auto-Fixing”**​：如果连接的语言模型节点或信息提取节点本身有“Enable Auto-Fixing”之类的选项，可以尝试开启它，n8n 会尝试让 AI 修复格式错误。
       • ​调整系统提示​：可以在系统提示中更强硬地要求 AI 严格遵守输出格式。例如，强调“输出必须是严格符合所提供 JSON Schema 的单个 JSON 对象，不能包含任何额外的解释性文字或 Markdown 标记。” 社区中曾有讨论指出，n8n 自动附加的格式指令有时可能与用户的自定义提示产生冲突，导致问题 。因此，如果自定义了系统提示，需要特别注意测试。
  3. 错误：“Information Extractor node only processing partial data” (信息提取节点只处理了部分数据)
     • ​解析​：节点接收了完整的输入文本，但输出结果只包含了从文本一部分提取出来的信息，另一部分似乎被忽略了。
     • ​翔宇的排错思路​：这个问题在 n8n 社区有过专门的讨论 。Miquel Colomer 总结了几个可能的原因及对策：
       • ​节点内部的批处理机制​：AI 模型或节点本身可能对一次处理的文本长度有限制，超过限制的部分可能被截断或分批但未完全处理。
         • ​解决方案​：在信息提取节点前使用“Split In Batches”节点，将长文本主动分割成更小的、可管理的块，然后分别处理。
       • ​Schema 定义与部分数据不匹配​：可能 Schema 的定义只适用于文本的某一部分特征，导致其他部分的数据因为不符合 Schema 而被跳过。
         • ​解决方案​：仔细检查并优化 Schema 定义，确保它能覆盖所有你期望提取信息部分的文本特征。
       • ​系统资源限制​：处理非常大的文本或极其复杂的 Schema 会消耗大量内存和计算资源。如果 n8n 实例资源不足，可能会导致处理中断或不完整。
         • ​解决方案​：优化工作流，减少不必要的资源消耗；如果可能，为 n8n 实例分配更多资源。
       • ​**静默错误 (Silent Failures)**​：节点在处理某些特定数据项时可能内部发生错误，但没有明确报错，而是直接停止了对后续数据的处理。
         • ​解决方案​：尝试在信息提取节点后添加“Error Trigger”节点，专门捕获可能发生的错误，即使这些错误没有在主流程中显现。查看详细的执行日志，寻找线索。
       • ​翔宇的补充​：“Mr_Lee 在那个帖子中提到他找不到‘Split In Batches’节点，而是找到了‘Loop Node (Split in Batches)’。这说明 n8n 的节点名称或实现方式可能随版本更新，大家要注意使用当前版本对应的节点。核心思想还是分块处理。”
  4. 错误：超时错误 (Timeout errors)
     • ​解析​：信息提取过程花费的时间超过了节点或 AI 模型服务的允许上限。
     • ​翔宇的排错思路​：
       • ​文本长度和 Schema 复杂度​：这是最主要的原因。输入的文本越长，或者你定义的 Schema 越复杂（需要提取的字段越多、描述越复杂），AI 需要的分析时间就越长。
       • ​解决方案​：
         • ​缩短输入文本​：只把包含关键信息的部分文本传给节点，而不是整个文档。
         • ​简化 Schema​：是不是有些字段不是必需的？能不能分多次、用更简单的 Schema 来提取？
         • ​选择更快的 AI 模型​：不同的 AI 模型在处理速度上有所差异。如果对实时性要求高，可以考虑更换模型。
         • ​分块处理​：同上一点，将长文本或复杂任务拆分成小块。
       • ​检查 AI 服务提供商的限制​：某些 API 调用可能有时间限制。
• 调试方法与日志定位技巧
  调试信息提取节点的方法与情感分析节点类似，但更侧重于对 Schema 和输入文本的匹配度进行分析。
  • ​分步执行与输出检查​：依然是王道。重点看输入到信息提取节点的文本是什么，以及信息提取节点输出的结构化数据是什么。
  • ​Schema 验证工具​：如果你手动编写 JSON Schema (使用“Define Below”选项)，强烈建议使用在线的 JSON Schema 验证工具来检查你的 Schema 是否符合规范，没有语法错误。
  • ​小规模测试​：用一小段典型的、包含你所有想提取信息的文本作为测试用例。先确保这个小用例能成功提取，再逐步扩展到更复杂、更多样的数据。
  • ​**查看 AI Agent 日志 (如果作为 AI Agent 的工具使用)**​：如果信息提取节点是被一个 AI Agent 节点调用的工具，那么可以在 AI Agent 节点的日志中看到传递给工具的输入和工具返回的输出，这有助于判断问题是在 Agent 的指令还是在信息提取工具本身 。
  • ​翔宇的技巧​：“我调试这类节点时，喜欢把 Schema 的复杂度逐步提高。先定义一两个最关键、最容易提取的字段，看能不能成功。成功了，再慢慢加其他字段。这样如果出错了，也容易定位是哪个字段的定义有问题。”

信息提取的准确性很大程度上依赖于你给 AI 的“说明书”（即 Schema 和系统提示）写得有多好。多花点时间打磨这份说明书，往往能事半功倍。

2.6 注意事项

信息提取节点虽然强大，但在使用过程中，翔宇提醒大家注意以下几点，以确保提取效果和流程的稳定性：

• Schema 定义的清晰度和准确性是成功的基石
  • ​翔宇的反复强调​：“这一点怎么强调都不过分。无论你选择哪种 Schema 定义方式，都要确保它能清晰、准确地告诉 AI 你要什么。属性描述要具体，JSON 示例要规范，JSON Schema 要严谨。模糊的指令只会得到模糊的结果。”
• 用多样化的真实数据进行充分测试
  • ​翔宇的方法​：“不要只用一两个‘完美’的示例文本测试就觉得万事大吉了。准备一些包含了各种情况的真实数据——比如信息不全的、表述方式略有不同的、甚至包含一些干扰信息的文本——来全面测试你的提取器。这样才能发现它在真实场景下的表现，并进行针对性优化。”
• 这是一个迭代优化的过程
  • ​翔宇的经验​：“很少有一蹴而就的完美提取规则。通常需要根据初步的提取结果，回头调整 Schema 定义或系统提示，再测试，再调整……如此反复几次，才能达到比较满意的效果。对 AI 多点耐心，也多给自己一点尝试的机会。”
• 平衡 Schema 的复杂性与 AI 的理解能力
  • ​翔宇的观察​：“过于复杂的 Schema（比如一次要提取几十个字段，且字段间关系复杂）可能会让 AI ‘晕头转向’，导致提取效果下降或速度变慢。如果可能，尝试将复杂的提取任务分解成几个步骤，或者用多个信息提取节点，每个节点负责一部分字段的提取。”
• 考虑成本和性能
  • ​翔宇的提醒​：“从非常长的文本中提取大量字段，或者使用能力超强的 AI 模型，都可能带来更高的时间成本和（如果是付费 API）金钱成本。在设计工作流时，要根据实际需求和预算，在提取的全面性、准确性与成本、效率之间找到平衡点。”
• 优雅处理信息缺失的情况
  • ​翔宇的建议​：“AI 不一定总能找到你 Schema 中定义的每一个字段，特别是当源文本中确实没有对应信息的时候（AI 被指示在找不到时可以省略该属性的值 ）。因此，你的后续工作流逻辑必须能够处理某些提取字段为空 (null 或 undefined) 或不存在的情况。例如，在将数据写入数据库之前，检查关键字段是否为空，如果为空则进行特殊标记或发送通知，而不是直接报错中断流程。”
• 警惕针对 AI 的安全风险，如提示注入
  • ​翔宇的安全提示​：“如果你的信息提取器处理的是来自用户自由输入、公开网页或其他不可信来源的文本，那么需要注意‘提示注入’(Prompt Injection) 的风险。恶意用户可能在文本中嵌入一些特殊指令，试图欺骗或操纵 AI，让它提取错误的信息，或者执行一些非预期的操作。虽然 n8n 节点本身会做一些防护，但保持警惕总是好的。对输入文本进行适当的清洗和过滤，或者在系统提示中加入对抗性指令，都是可以考虑的措施。”
• 关注数据隐私和合规性
  • ​翔宇的合规提醒​：“当你提取的信息中包含姓名、联系方式、身份证号等个人敏感信息时，务必严格遵守数据隐私保护法规（如 GDPR、CCPA 等）。确保你的数据处理方式、存储方式以及与第三方 AI 服务的交互都符合规定。了解数据在 AI 服务端的处理和存储策略，避免不必要的隐私风险。”

信息提取节点是一个强大的工具，它能将非结构化文本的潜力释放出来。但同时，它也需要用户更细致的配置和对 AI行为的理解。遵循这些注意事项，你就能更好地驾驭它，让它为你的自动化流程创造更大价值。

第三章：n8n 中文教程：文本分类器 (Text Classifier)

文本分类 (Text Classifier) 节点是 n8n AI 工具箱中的另一位得力干将。翔宇喜欢把它比作工作流里的“智能分拣员”。你给它一段文本，再预设一些“篮子”（也就是类别），它就能判断这段文本应该放进哪个（或哪些）篮子里。

3.1 节点概览

3.1.1 节点功能定位与核心价值

文本分类节点的核心功能是利用语言模型，根据用户预定义的类别及其描述，将输入的文本自动分配到一个或多个最合适的类别中 。与情感分析节点关注文本的“情感色彩”不同，文本分类器更侧重于文本的“内容主题”或“业务属性”。

它的核心价值在于：

• ​自动化内容归类​：自动将大量文本（如邮件、工单、文章、评论）按照预设标准进行分类，无需人工阅读和判断。
• ​提升流程效率​：例如，可以根据邮件内容自动将其分发给正确的部门或负责人，加快响应速度 。
• ​改善信息组织​：为内容（如博客文章、产品文档）自动打上标签，方便检索和管理。
• ​初步筛选与预警​：例如，自动识别垃圾邮件、恶意评论，或根据文本内容判断其紧急程度。

对于零代码用户来说，文本分类节点使得复杂的文本内容理解和归类任务变得简单直观。你只需要定义好你的“分类标准”（即类别和描述），剩下的交给 AI 就行了。

翔宇特别提醒，要区分文本分类和情感分析：

• ​情感分析​：判断文本表达的是正面、负面还是中性等情感。例如，“这产品太棒了！” -> 正面。
• ​文本分类​：判断文本属于哪个预定义的类别。例如，“这产品太棒了！”（如果类别是“产品反馈”、“营销文案”），它可能被分为“产品反馈”。 两者可以结合使用，比如先判断一段用户反馈是正面的，然后再把它分类到“功能建议”类别。

3.1.2 输入 (Input) 与输出 (Output) 数据结构

文本分类节点同样遵循 n8n 标准的输入输出数据格式 。

• 输入数据结构 (Input Data Structure)
  文本分类节点期望接收的输入项目中，应包含一个需要被分类的文本字段。默认情况下，节点会查找名为 text 的字段 26。
  例如，假设我们有一个工作流用于处理客户提交的工单，工单数据如下：
  JSON[ { "json": { "ticket_id": "t789", "user_email": "user1@example.com", "subject_line": "无法登录我的账户，提示密码错误", "description_text": "我尝试多次登录，都提示密码错误，但我确定密码是正确的。也尝试了找回密码，没有收到邮件。" } }, { "json": { "ticket_id": "t790", "user_email": "user2@example.com", "subject_line": "产品功能建议：希望能增加XX导出功能", "description_text": "目前的产品在使用中感觉很好，但如果能增加将数据导出为Excel格式的功能就更完美了。" } } ] ​在这个例子中，我们可能希望根据 subject_line 或 description_text (或者两者的组合) 来对工单进行分类。假设我们用 description_text，那么会在节点的“Input Prompt”参数中通过表达式 {{ $json.description_text }} 来指定。
• 输出数据结构 (Output Data Structure)
  文本分类节点处理完输入数据后，会在每个项目的 json 对象中添加一个名为 classification 的字段（此字段名是 n8n 标准，但也可能受具体连接的 LLM 影响，建议实际测试查看）。这个 classification 字段通常是一个数组，包含了该文本被归入的一个或多个类别对象。每个类别对象至少包含 name (类别名称) 和 description (你在配置时填写的类别描述) 这两个属性 。
  如果参数“Allow Multiple Classes To Be True”被开启，那么 classification 数组中就可能包含多个类别对象。
  如果参数“When No Clear Match”被设置为“Output on Extra, ‘Other’ Branch”，那么未能匹配任何预定义类别的项目会被路由到一个名为“Other”的独立输出分支上，而不会在主输出分支的 classification 字段中体现。
  以上述输入为例，假设我们定义的类别有：“Technical Issue (技术问题)”, “Feature Request (功能请求)”, “Billing Inquiry (账单咨询)”。
  输出可能如下（假设每个文本只匹配一个类别）：
  JSON// 主输出分支 (Main Output Branch) } }, { "json": { "ticket_id": "t790", "user_email": "user2@example.com", "subject_line": "产品功能建议：希望能增加XX导出功能", "description_text": "目前的产品在使用中感觉很好，但如果能增加将数据导出为Excel格式的功能就更完美了。", "classification": } } ] ​翔宇提示：输出的 classification 是一个数组，即使只匹配到一个类别，它通常也会被包裹在一个数组里。在后续节点引用时要注意这一点，例如，获取第一个匹配的类别名称可能是 {{ $json.classification.name }}。具体的输出结构最好还是通过实际运行一次节点来确认 。

3.2 参数与配置

文本分类节点的参数配置核心在于清晰地定义分类标准，即“类别 (Categories)”，以及处理一些特殊情况的策略。

• Input Prompt (输入提示)
  • ​含义​：指定输入数据中哪个字段包含了需要进行分类的文本内容。它需要一个表达式来引用该字段。
  • ​翔宇的实战理解​：“老规矩，告诉节点去哪里找那段需要分类的文字。比如，分析邮件主题就用 {{ $json.email_subject }}，分析用户评论就用 {{ $json.user_comment }}。确保这个表达式能准确拿到文本。”
  • ​默认值​：{{ $json.text }}。节点默认会尝试从输入数据的 json 对象下的 text 字段读取文本。
  • ​可选值​：任何能够正确指向包含文本字段的有效 n8n 表达式。
• Categories (类别)
  • ​含义​：这是文本分类节点最核心的配置项。在这里，你需要添加所有你希望将输入文本划分进去的类别。每个类别都包含两个部分：
    • ​**Name (名称)**​：类别的简短标识，例如“技术支持”、“销售咨询”、“产品缺陷”。
    • ​**Description (描述)**​：对这个类别的详细文字说明。这部分至关重要，因为 AI 模型主要依赖这个描述来理解每个类别的具体含义和判断标准，特别是当类别名称本身比较笼统或有歧义时。
  • ​翔宇的实战理解​：“‘描述’是灵魂！我再怎么强调它的重要性都不过分。比如，你定义一个类别叫‘紧急’，如果只给这个名字，AI 可能不太明白什么算‘紧急’。但如果你在描述里写：‘涉及资金安全、系统严重故障、或客户表示强烈不满需要立即处理的情况’，AI 的判断就会准确得多。好的描述应该清晰、具体，能够帮助 AI 区分不同类别之间的界限。社区和 GitHub 上都有讨论强调描述对于分类准确性的巨大影响 。早期 n8n 版本中，模型对描述的利用可能还不够充分，但现在这个问题已经得到了很大改善，所以一定要认真填写类别描述！”
  • ​默认值/可选值​：此项没有默认值，用户必须至少添加一个类别才能使节点工作。可以根据需求添加任意多个类别。点击“Add Category”按钮来逐个添加。
• Allow Multiple Classes To Be True (允许多个类别为真)
  • ​含义​：此选项决定了对于一个输入文本，分类器是只输出一个最匹配的类别（开关关闭时），还是可以输出所有匹配的多个类别（开关开启时）。
  • ​翔宇的实战理解​：“有些文本内容可能天然就属于多个范畴。比如一封客户邮件，可能既提到了‘产品使用问题’（技术支持类），又表达了对‘售后服务不及时’的不满（客户投诉类）。如果你的业务场景允许或需要识别这种情况，那就把这个开关打开。如果只想得到一个最主要的分类结果，那就保持关闭状态。默认是关闭的，即单类别输出。”
  • ​默认值​：关闭 (false)。
  • ​可选值​：开启 (true) 或关闭 (false)。
• When No Clear Match (当没有明确匹配时)
  • ​含义​：这个参数定义了当 AI 模型分析完一段文本后，觉得它不明确属于你所定义的任何一个类别时，节点应该如何处理这个文本项目。
  • ​翔宇的实战理解​：“这个选项非常实用，能让你的工作流更具鲁棒性。它有两个可选行为：
    1. ​**Discard Item (丢弃项目)**​：这是默认选项。如果文本不匹配任何类别，这个文本项目就会被直接丢弃，不会进入后续流程。
    2. ​**Output on Extra, ‘Other’ Branch (在额外的“其他”分支上输出)**​：选择这个选项后，节点会多出一个名为‘Other’的输出锚点（分支）。所有未能匹配任何预定义类别的文本项目，都会从这个‘Other’分支输出。 我个人非常推荐使用‘Output on Extra, ‘Other’ Branch’。因为总有些文本可能出乎你的意料，不属于你最初设想的任何类别。把它们导到‘Other’分支，你可以定期检查这些‘漏网之鱼’，看看是不是需要调整你的类别定义，或者对这些特殊情况进行人工处理。直接丢弃可能会丢失有价值的信息。”
  • ​默认值​：“Discard Item”。
  • ​可选值​：“Discard Item” 或 “Output on Extra, ‘Other’ Branch”。
• System Prompt Template (系统提示模板)
  • ​含义​：允许用户自定义在进行文本分类时发送给底层语言模型的系统级指令。这个模板中可以使用 {categories} 这个占位符，n8n 在实际调用 AI 时会将其替换为你定义的类别列表（包含名称和描述）。
  • ​翔宇的实战理解​：“这通常是高级用户才会用到的选项。n8n 默认的系统提示一般已经优化得不错了，它会告诉 AI ‘你是一个文本分类助手，请根据以下类别对文本进行分类……’。除非你对 AI 的分类逻辑有非常具体和深入的调整需求，比如你想强调某种分类的优先级，或者对分类的模糊度有特殊要求，否则不建议轻易修改。如果修改，务必保留 {categories} 占位符，并充分测试效果。”
  • ​默认值​：n8n 内置一个默认的系统提示。
  • ​可选值​：用户可以输入自定义的文本字符串。
• Enable Auto-Fixing (启用自动修复)
  • ​含义​：当启用此选项时，如果 AI 模型返回的输出格式不完全符合节点内部的预期（例如，返回的类别名称与你定义的不完全一致，或者格式稍有偏差），节点会尝试将这个格式问题反馈给 AI 模型，并请求它进行修正。
  • ​翔宇的实战理解​：“这个功能旨在提高输出结果的稳定性和规范性。AI 有时可能在细节上犯点小错误，比如类别名多了个空格。开启自动修复，n8n 会尝试让 AI ‘自己改改’。这在某些情况下能提升体验。但和情感分析节点一样，它也可能增加一点点处理时间和 AI 调用成本。我的建议是，优先通过清晰的类别定义（尤其是描述）来确保 AI 的理解，如果依然存在轻微的格式问题，再考虑开启此选项。”
  • ​默认值​：关闭 (false)。
  • ​可选值​：开启 (true) 或关闭 (false)。

翔宇认为，对于文本分类节点，最重要的配置就是“Categories”中的名称和描述。把这里定义清楚，分类的准确率就能得到基本保障。其他参数则提供了更灵活的控制和容错能力。

3.3 数据映射与表达式

要让文本分类节点有效工作，正确的数据映射至关重要。你需要确保将待分类的文本准确地输入到节点，并且能够有效地利用节点输出的分类结果来驱动后续的自动化流程。

• 将文本映射到“Input Prompt”参数
  与前面介绍的情感分析和信息提取节点类似，“Input Prompt”参数需要一个表达式，该表达式能够从上游节点传入的数据中定位到包含待分类文本的字段。
  ​翔宇的映射技巧​：
  1. ​明确文本来源​：首先，确定哪段文本是你想要分类的。是邮件的主题、正文的一部分、用户评论的全部内容，还是某个文档的摘要？
  2. ​检查上游输出​：运行文本分类节点的上游节点，查看其输出数据。找到包含目标文本的字段名及其在 JSON 结构中的完整路径。例如，如果文本在 {{ $json.data.comment_text }}，那么表达式就是这个。
  3. ​使用变量选择器​：n8n 表达式编辑器中的变量选择器是初学者的好朋友。它可以直观地展示可用的数据字段，点击即可生成表达式，大大减少了手动输入错误的风险。
  4. ​组合多个字段作为输入​：有时，单个字段可能不足以进行准确分类。你可以通过表达式将多个字段的内容拼接起来作为输入。例如，将邮件主题和正文的前100个字符合并：{{ $json.subject + " " + $json.body.slice(0, 100) }}。但要注意，输入文本不宜过长，以免影响 AI 效率和准确性。
• 使用文本分类节点的输出 (classification)
  文本分类节点的核心输出是 classification 字段，它通常是一个包含一个或多个分类结果对象的数组。每个分类结果对象至少有 name (类别名) 和 description (类别描述) 属性。
  翔宇的映射技巧与常见用法：
  假设分类结果如下：
  JSON{ "json": { //... 其他原始字段... "classification": } } ​
  1. ​获取第一个匹配的类别名称​：在大多数情况下，如果只允许单类别输出，或者你只关心最主要的类别，可以使用 {{ $json.classification.name }} 来获取类别名称。这里的 “ 表示取数组中的第一个元素。
  2. ​在 IF 节点中根据类别进行分支​：这是最常见的应用。你可以设置 IF 节点的条件来判断文本属于哪个类别，然后执行相应的操作。
     • 例如，条件1：{{ $json.classification.name === "Sales Inquiry" }} -> 转到销售处理流程。
     • 条件2：{{ $json.classification.name === "Technical Support" }} -> 创建技术支持工单。
     • 如果开启了“When No Clear Match”并使用了“Other”分支，那么 IF 节点可以直接连接到主输出分支和“Other”输出分支，分别处理已分类和未分类的情况。
  3. ​在 Switch 节点 (或多个 IF 节点/Router 节点) 中处理多个类别​：如果你有多个明确的类别，并且每个类别需要不同的处理路径，可以使用 Switch 节点（或其等效实现）。Switch 节点的输入就是 {{ $json.classification.name }}，然后为每个可能的类别名称设置一个输出分支。
  4. ​处理允许多个类别为真的情况​：如果“Allow Multiple Classes To Be True”开启，{{ $json.classification }} 数组中可能包含多个类别。你需要根据业务逻辑决定如何处理。
     • 你可以遍历这个数组（例如，在 Code 节点中，或使用 Loop Over Items 节点）。
     • 你可以检查是否包含某个特定类别：{{ $json.classification.some(cat => cat.name === "Urgent") }} (这个表达式会返回 true 或 false，表示是否包含名为 “Urgent” 的类别。注意：这种复杂表达式可能更适合在 Code 节点中使用，或者简化为检查第一个类别是否为 “Urgent”）。
     • 你可以将所有匹配到的类别名称组合起来作为标签：{{ $json.classification.map(cat => cat.name).join(", ") }} (输出类似 “Technical Issue, Urgent” 的字符串)。
  5. ​将分类结果存储或展示​：可以将 {{ $json.classification.name }} 或组合后的标签字符串，连同原始文本一起，保存到数据库、Google Sheets 、CRM 系统或发送到通知渠道。
• 常见易错点
  1. ​**Input Prompt 表达式错误**​：与前两个节点类似，如果指向源文本的表达式不正确，节点将无法获取待分类的内容。社区中曾有用户报告“Cannot read properties of undefined (reading ‘message’)”之类的错误 ，这通常就是因为输入表达式引用的字段（如 message）在实际传入的数据中不存在或为空。翔宇建议，仔细检查上游节点的输出，确保字段名和路径完全正确。使用 Tovia 在社区建议的 {{ $json.field1 | | $json.field2 | | "default text" }} 这样的回退机制，可以增加表达式的健壮性 。
  2. ​类别定义 (尤其是描述) 不清晰​：这是导致分类不准确的最主要原因。如果类别描述含糊、有歧义，或者不同类别之间的界限不分明，AI 就很难做出正确的判断 。
  3. ​错误地处理 classification 数组​：忘记 classification 是一个数组，直接用 {{ $json.classification.name }} 而不是 {{ $json.classification.name }} 来获取类别名，会导致错误。
  4. ​未考虑“Other”分支​：如果设置了“Output on Extra, ‘Other’ Branch”，但工作流中只处理了主输出分支，可能会遗漏那些未被成功分类的数据。
  5. ​**过度依赖 AI 的“智能”**​：期望 AI 能在类别定义非常少或非常糟糕的情况下依然表现出色是不现实的。文本分类器的效果很大程度上取决于用户提供的“训练信号”（即类别定义）。

翔宇建议：“在配置文本分类节点时，把你自己想象成 AI。如果只给你类别名称和描述，你能准确地把各种文本分到正确的篮子里吗？如果连你都觉得困难，那 AI 可能也会感到困惑。所以，花时间打磨你的类别定义，这是提升分类效果的关键。”

3.4 应用场景

文本分类器的应用非常广泛，它可以帮助我们自动化处理各种基于文本内容的归类和分发任务。翔宇将分享一些他常用的或认为非常有价值的应用场景。

3.4.1 节点的翔宇常用应用场景

• 场景一：智能路由客户支持邮件或工单
  • ​需求​：翔宇的公司通过邮件或在线表单接收客户的各类请求，如售前咨询、技术问题、账单疑问、功能建议等。他希望这些请求能自动被分类，并路由给相应的处理团队（如销售团队、技术支持团队、财务团队）。
  • ​工作流设想​：
    1. ​触发器​：使用 Email Read IMAP/Gmail 节点监控支持邮箱，或使用 Webhook/Form Trigger 接收工单系统推送的数据。
    2. ​提取关键文本​：从邮件主题、正文或工单描述中提取用于分类的文本。
    3. ​文本分类​：将提取的文本送入 Text Classifier 节点。
       • ​**Categories (示例)**​：
         • Sales Inquiry (描述：关于产品价格、折扣、购买方式、试用等的咨询)
         • Technical Issue (描述：报告产品使用中的错误、故障、兼容性问题或寻求技术帮助)
         • Billing Question (描述：关于发票、付款、订阅续费等的疑问)
         • Feature Request (描述：对产品提出新功能建议或改进意见)
         • General Feedback (描述：一般的用户反馈、表扬或中性评论)
       • ​When No Clear Match​：设置为 Output on Extra, 'Other' Branch，用于处理无法明确分类的请求。
    4. ​路由与通知​：
       • 使用 Router 节点或多个 IF 节点，根据 Text Classifier 输出的类别名称 ({{ $json.classification.name }})，将工单导向不同的路径。
       • 每个路径下，可以执行相应的操作，如：在 CRM (如 HubSpot, Salesforce) 中创建不同类型的任务，发送 Slack 消息给特定团队频道，或回复一封预设的邮件模板。
       • 对于“Other”分支的工单，可以统一标记为“待人工分配”，并通知管理员。
  • ​翔宇的理解​：“这个流程是提升客服效率的利器！n8n 社区有一个非常棒的电子商务邮件路由模板就用了这个思路 。它能确保每个请求都尽快到达正确的人手中，减少了人工分拣的延迟和错误。关键在于类别定义要能覆盖大部分常见请求，并且描述要清晰，帮助 AI 准确判断。” 可以结合 Google Sheets 或 Gmail 等节点完成后续的数据记录或通知。
• 场景二：自动为知识库文章或博客内容打标签
  • ​需求​：翔宇维护着一个包含大量 n8n 教程、AI 技术解读和工作流技巧的知识库或博客。他希望在发布新内容时，系统能根据文章内容自动为其打上相关的标签（如 “n8n入门”, “AI应用”, “API集成”, “错误处理”），方便用户检索和内容管理。
  • ​工作流设想​：
    1. ​触发器​：当在 Notion、WordPress 或其他内容管理系统 (CMS) 中创建或更新一篇文章时触发（例如，使用 Notion Trigger，或 CMS 的 Webhook 功能）。
    2. ​提取文章内容​：获取文章的标题和正文（或摘要）。
    3. ​文本分类​：将文章内容送入 Text Classifier 节点。
       • ​**Categories (示例)**​：预先定义好一系列常用的标签作为类别，并为每个标签提供清晰的描述，说明该标签适用于哪些主题的文章。
       • ​Allow Multiple Classes To Be True​：开启此选项，因为一篇文章可能同时属于多个标签。
    4. ​更新文章标签​：
       • 获取 Text Classifier 输出的所有匹配类别名称。
       • 通过相应的 CMS API 节点（如 Notion Update Page, WordPress Update Post）将这些类别名称作为标签更新回原文。
  • ​翔宇的理解​：“对于内容创作者来说，手动打标签是个挺繁琐的事。这个自动化流程能在我写完文章后自动完成大部分标签工作，非常省心。而且，AI 打的标签可能比我自己想到的更全面或有一些新的角度。”
• 场景三：初步筛选和标记论坛评论或社交媒体帖子
  • ​需求​：翔宇运营一个小型的在线社区或关注某些社交媒体话题。他希望能自动识别出评论或帖子中的垃圾信息、不当言论、用户提出的问题、有价值的反馈等，以便进行管理或重点关注。
  • ​工作流设想​：
    1. ​触发器​：通过 Webhook 接收论坛新评论的通知，或使用 Twitter/Facebook 等节点监控特定关键词或账户的帖子。
    2. ​文本分类​：将评论或帖子内容送入 Text Classifier 节点。
       • ​**Categories (示例)**​：
         • Spam/Advertisement (描述：明显的垃圾信息、广告推广)
         • Inappropriate Content (描述：包含辱骂、攻击性或违反社区规则的言论)
         • User Question (描述：用户提出的关于产品或服务的疑问)
         • Positive Feedback (描述：用户对产品或服务的正面评价和赞扬)
         • Negative Feedback/Complaint (描述：用户表达不满、抱怨或指出问题)
         • General Discussion (描述：普通的讨论或中性言论)
       • ​When No Clear Match​：可以输出到“Other”分支，进行人工判断。
    3. ​后续处理​：
       • 根据分类结果，使用 IF 节点或 Router 节点进行分流。
       • 对于“Spam”或“Inappropriate Content”，可以自动标记为待审核、发送通知给管理员，甚至在某些情况下自动删除（需谨慎）。
       • 对于“User Question”，可以创建待办任务，提醒社区管理员或客服回复。
       • 对于“Positive/Negative Feedback”，可以收集起来用于产品改进或市场分析。
  • ​翔宇的理解​：“社区管理中，快速响应和处理不当内容非常重要。文本分类器能帮我做第一道筛选，把明显的‘坏苹果’挑出来，或者把需要关注的‘好声音’高亮出来。虽然 AI 的判断不一定 100% 准确，但作为辅助工具，它能大大减轻人工审核的压力。”

这些应用场景只是冰山一角。文本分类器的潜力在于它能够理解文本的“意图”或“主题”，并据此进行自动化操作。你可以将它应用于任何需要根据文本内容进行归类、分发、标记或筛选的流程中。关键在于，你需要事先明确你的分类目标和标准，并将其准确地传达给 AI。

3.5 常见报错及解决方案

文本分类节点在实际使用中，也可能遇到一些问题。了解这些常见错误及其排查方法，可以帮助你更快地让工作流顺畅运行。

• 错误提示解析与排错思路
  1. 错误：“Cannot read properties of undefined (reading ‘message’)” 或类似的输入字段找不到错误
     • ​解析​：这个错误非常经典，它意味着文本分类节点在其“Input Prompt”参数中配置的表达式，无法从上游节点传入的数据中找到对应的字段，或者该字段的值是 undefined (未定义) 或 null (空)。例如，表达式是 {{ $json.message }}，但传入的数据中根本没有 message 这个键，或者 json.message 的值就是空的。
     • ​翔宇的排错思路​：
       • ​核对上游输出与表达式​：这是首要步骤。暂停工作流，执行到文本分类节点的上一个节点，然后仔细查看该节点的输出数据。确认包含待分类文本的字段究竟叫什么名字，以及它在 JSON 结构中的完整路径。然后，回到文本分类节点的“Input Prompt”参数，确保你的表达式与这个实际的字段名和路径完全一致，包括大小写。
       • ​使用表达式编辑器的变量选择器​：这是避免此类错误的最佳实践。在填写表达式时，打开表达式编辑器，从左侧的变量树中直接点击选择目标字段，让 n8n 自动生成表达式。
       • ​考虑数据源的多样性​：有时，上游数据来源可能不止一个，或者同一来源的数据结构也可能发生变化（比如，某些邮件有 textAsHtml 字段，有些只有 text 字段）。社区用户 Tovia 曾建议使用带有回退逻辑的表达式，例如：{{ $json.textAsHtml | | $json.text | | "No content available" }}。这样，如果第一个字段找不到，它会尝试第二个，如果都找不到，则提供一个默认文本，避免了直接传入 undefined 导致 AI 节点出错。
       • ​在前面节点进行数据校验或转换​：如果确定某些情况下输入文本可能为空，可以在文本分类节点前加一个 IF 节点，判断文本字段是否存在且不为空。如果为空，则可以走一个旁路，不执行分类，或者给一个默认分类。
  2. 错误：分类结果不准确，或与预期严重不符 (Classification is inaccurate or unexpected)
     • ​解析​：AI 模型给出的分类结果不是你想要的，比如把一个明显是技术问题的工单分到了销售咨询类。
     • ​翔宇的排错思路​：
       • ​重点检查“Categories (类别)”的定义​：这是影响分类准确性的核心因素。
         • 名称 (Name) 是否清晰、简洁且具有代表性？
         • 描述 (Description) 是否详尽、准确地解释了这个类别的含义、范围和判断标准？AI 主要依赖描述来理解你的分类意图。如果描述过于简单、模糊，或者与另一个类别的描述区分度不高，AI 就很容易混淆。GitHub 上曾有关于类别描述重要性的讨论 ，强调了高质量描述对模型性能的正面影响。
         • ​类别数量和覆盖度​：你定义的类别是否能覆盖大部分常见的输入文本情况？如果类别太少，或者定义的范围太窄，很多文本可能都找不到合适的归宿。
         • ​类别间的区分度​：不同类别之间的界限是否清晰？如果两个类别的定义非常相似，AI 可能难以抉择。
       • ​检查输入文本的质量​：待分类的文本本身是否清晰、主题明确？如果文本本身就含糊不清、充满歧义，AI 也难以准确分类。
       • ​调整“Allow Multiple Classes To Be True”选项​：如果一个文本可能属于多个类别，但你只允许单类别输出，AI 可能会选择一个它认为最匹配的，但这可能不是你最想要的。反之，如果只应属于单类别，但你允许多类别，可能会得到一些不相关的次要分类。
       • ​**微调“System Prompt Template”**​：如果上述方法都尝试过，效果仍不理想，可以考虑（谨慎地）修改系统提示，给 AI 更具体的分类指导原则。
       • ​更换语言模型​：不同的语言模型在理解能力和遵循指令方面有所差异。如果使用的是一个相对基础的模型，可以尝试更换一个更强大、更先进的模型，看看效果是否有改善。
  3. 错误：所有（或大部分）文本都被分到了“Other”分支 (All items go to the ‘Other’ branch)
     • ​解析​：当你启用了“When No Clear Match”的“Output on Extra, ‘Other’ Branch”选项后，发现几乎所有的数据都从这个“Other”分支出来了，主分支很少有数据。
     • ​翔宇的排错思路​：
       • ​类别定义与输入文本严重不匹配​：这通常意味着你定义的类别标准与实际输入的文本内容“格格不入”。AI 找不到任何一个类别能较好地匹配这些文本。
       • ​解决方案​：
         • ​重新审视类别定义​：是不是类别太少，覆盖面太窄？或者类别描述过于严格，导致大部分文本都被排除在外？
         • ​分析“Other”分支的文本​：仔细看看那些被分到“Other”分支的文本都有什么共同特征。它们是否应该属于某个现有类别（说明该类别的描述需要改进）？或者它们是否代表了一些你之前没有考虑到、但应该独立出来的新类别？
         • ​逐步放宽或调整描述​：尝试修改现有类别的描述，使其更具包容性，或者更贴合这些“Other”文本的特征。
         • ​增加新的类别​：如果发现“Other”文本中确实存在一些具有共性的、值得单独分类的内容，那就为它们创建新的类别。
  4. ​AI 节点通用错误​：如模型连接错误、API 密钥问题、超时等，排查方法与情感分析节点类似，主要检查语言模型节点的凭证、网络连接、模型选择以及 AI 服务本身的状态。
• 调试方法与日志定位技巧
  调试文本分类节点时，除了通用的 n8n 调试技巧（分步执行、检查输入输出、使用 Set 节点辅助观察等），翔宇还有一些针对性的建议：
  • ​从小处着手测试类别定义​：不要一开始就定义十几个非常复杂的类别。先从两三个核心类别开始，用典型的示例文本测试，确保这几个基本类别能被 AI 正确理解和区分。然后再逐步增加和细化类别。
  • ​**准备一个“黄金测试集”**​：挑选一批具有代表性的、你已经人工分类好的文本作为测试数据。每次调整完类别定义或参数后，都用这个测试集来跑一遍，看看 AI 的分类结果与你的期望有多大差异。这能帮你量化改进效果。
  • ​关注类别描述的措辞​：尝试用不同的方式来描述同一个类别，看看哪种措辞能让 AI 理解得更准确。有时，换一种说法，或者补充一些反例（比如“这个类别不包含XX情况”），效果可能会有显著提升。
  • ​利用社区经验​：n8n 社区 中可能有其他用户分享过类似的文本分类经验或遇到的问题。搜索一下，或者把你的具体场景和困惑发出来讨论，往往能获得有益的启发。
  翔宇总结：“调试文本分类节点，很多时候像是在和 AI ‘对话’和‘校准’。你通过类别定义告诉它你的标准，它通过分类结果反馈它的理解。你需要根据反馈不断调整你的指令，直到你们达成‘共识’。”

3.6 注意事项

文本分类器是一个非常实用的 AI 工具，但在使用过程中，翔宇提醒大家留意以下几个方面，以便更好地发挥其效用并避免潜在问题：

• 类别定义的质量是核心中的核心
  • ​翔宇的首要忠告​：“我必须再次强调，你的类别名称，特别是类别描述，写得有多好，直接决定了 AI 分类的准确度。请务必投入足够的时间和精力来打磨它们。描述要清晰、具体、无歧义，能够准确反映每个类别的本质特征和边界。”
• 确保类别之间具有足够的可区分性
  • ​翔宇的经验​：“如果你定义的两个或多个类别在含义上非常接近，或者它们的描述高度重叠，那么 AI 就很容易感到困惑，不知道该把文本分到哪一类，或者可能随意选择一个。尽量让每个类别都有其独特的、易于识别的特征。”
• 充分考虑并利用好“Other”分支
  • ​翔宇的建议​：“在现实世界的文本数据中，总会有一些‘意料之外’的内容，它们可能不完全符合你预设的任何类别。如果你选择了‘Output on Extra, ‘Other’ Branch’，一定要定期关注这个分支的输出。它不仅能帮你捕获那些未被分类的数据，还是一个宝贵的反馈来源，可以提示你是否需要调整现有类别或添加新的类别。”
• 进行充分的、多样化的迭代测试
  • ​翔宇的方法​：“不要只用少数几个‘标准’样本来测试。尽可能使用接近真实业务场景的、多样化的数据（包括一些边缘案例和可能引起混淆的文本）来对你的分类器进行测试。根据测试结果，不断迭代优化你的类别定义、参数设置，甚至调整工作流逻辑。”
• 语言模型选择的影响
  • ​翔宇的观察​：“不同的底层语言模型（如 GPT-3.5, GPT-4, Gemini 等）在文本理解能力、遵循指令的精确度以及处理特定领域知识方面可能存在差异。如果你发现当前连接的默认模型在你的分类任务上表现不佳，不妨尝试更换其他更高级或更适合你文本类型的模型，看看是否能提升效果。”
• 警惕 AI 偏见及其伦理影响
  • ​翔宇的提醒​：“AI 模型是在大量人类语言数据上训练的，这些数据可能包含了现实世界中存在的各种偏见（如性别、种族、地域偏见等）。因此，文本分类器在某些情况下也可能表现出这些偏见，导致对特定类型的文本或来自特定群体的文本产生不公平或不准确的分类。在将文本分类器应用于招聘筛选、内容审核、信贷评估等敏感场景时，务必高度警惕潜在的偏见问题，并采取措施进行缓解和监控，确保公平性。”
• 处理速度和成本
  • ​翔宇的考量​：“对大量文本进行分类，或者使用非常强大的 AI 模型，都可能需要一定的处理时间，并产生相应的 API 调用成本（如果使用的是付费模型）。在设计需要高吞吐量或低延迟的分类工作流时，需要评估所选方案的性能和成本效益。”
• 保持类别定义的动态更新
  • ​翔宇的远见​：“业务需求和文本内容特征可能会随着时间而变化。你最初定义的类别可能在一段时间后就不再完全适用。因此，建议定期回顾和更新你的类别定义，确保文本分类器能持续适应业务的发展。”

文本分类器为我们提供了一种强大的自动化手段来理解和组织文本信息。通过精心设计类别、细致调整参数，并关注上述注意事项，你就能让这个“智能分拣员”在你的 n8n 工作流中发挥出巨大的价值。

文章结尾

经过前面三个章节的详细介绍，相信大家对 n8n 中的情感分析 (Sentiment Analysis)、信息提取 (Information Extractor) 和文本分类 (Text Classifier) 这三个 AI 节点已经有了比较深入的理解。从翔宇的视角来看，这三个节点极大地拓展了 n8n 在处理和理解文本数据方面的能力，让我们这些即使没有深厚编程背景的用户，也能够轻松地将人工智能的强大功能融入到日常的自动化工作流中。

​情感分析节点​，像一个情感的捕手，帮助我们洞察文本背后是喜悦、是愤怒，还是平淡无奇，这对于理解客户心声、监控市场口碑至关重要。

​信息提取节点​，则像一位精明的数据侦探，能从杂乱无章的文本中精准地找出我们需要的结构化信息，无论是联系方式、订单详情还是关键条款，都能手到擒来，大大提升了数据录入和整理的效率。

而​文本分类节点​，更像一个高效的智能分拣中心，能将涌入的各类文本信息按照我们设定的规则自动归档到正确的类别，无论是邮件分发、工单路由还是内容打标，都能处理得井井有条。

回顾整个教程，翔宇希望大家能记住几个核心的使用技巧和理念：

1. ​数据流是王道​：在 n8n 中，一切皆数据。务必时刻关注数据在节点间的输入和输出是什么样的结构和内容。这是理解节点行为、排查问题的基础。在配置 AI 节点时，尤其要确保传递给它们的文本数据是准确和干净的。
2. ​从简单开始，逐步迭代​：特别是对于初学者，不要一开始就追求搭建极其复杂的工作流或配置非常精细的 AI 参数。先用默认设置或最简单的配置，把基本流程跑通，看到预期的结果。然后再根据实际需求，一步步调整参数，尝试高级功能，不断优化。
3. ​**清晰定义你的“AI指令”**​：无论是情感分析的情感类别、信息提取的 Schema，还是文本分类的类别及其描述，这些都是你给 AI 下达的“工作指令”。这些指令越清晰、越具体、越没有歧义，AI 就越能准确地理解你的意图，给出满意的结果。在 AI 的世界里，“精确的提问（配置）”往往是得到“精确答案（结果）”的前提。
4. ​善用 n8n 社区和官方文档​：n8n 拥有一个非常活跃和乐于助人的全球社区 ，以及内容详尽的官方文档 。当你遇到问题，或者对某个功能不理解时，不妨先去文档中查找答案，或者在社区论坛搜索和提问。很多时候，你遇到的问题，可能已经有其他用户分享过解决方案了。
5. ​实践出真知，动手最重要​：学习 n8n 和这些 AI 节点最好的方法，就是在你自己的实际工作场景中去动手搭建和测试工作流。把今天学到的知识点应用起来，解决一两个你身边的小问题，你会发现其中的乐趣和威力。

翔宇相信，只要你掌握了这三个 AI 节点，并结合 n8n 其他强大的节点和功能，你的自动化能力一定会提升到一个全新的水平。未来的工作，一定是人与 AI 协作的时代，而 n8n 正是这样一个能让我们轻松驾驭 AI 的优秀平台。

想要学习更多 n8n 实战案例和技巧吗？欢迎关注我的 YouTube 频道“翔宇工作流”，我会定期分享更多关于 n8n 的应用心得、案例解析以及最新的功能介绍。让我们一起在 n8n 的世界里，探索自动化和 AI 的无限可能，打造更智能、更高效的工作方式！期待与你在“翔宇工作流”相遇！