全部教程

原创专题

n8n 结构化输出：从 JSON 示例到字段检查

配置 Structured Output Parser，检查必填字段、JSON Schema 与多条输入表达式的边界。

AI Nav City撰写 / 更新 资料核验

把模型回答用于后续节点时，需要确定字段形状。Structured Output Parser 根据 JSON Schema 返回字段；这解决格式约束，不证明分类内容一定正确。本文预期产物是一个两字段的消息分类结构，以及可重复的字段与语义检查表。前提是已有支持输出解析器的 n8n AI 工作流。

操作与检查顺序

  1. 定义字段

    先写消费节点实际需要的 category 与 reason。[1]

  2. 选择 Schema

    根据必填与类型要求选择示例生成或手写 JSON Schema。[1]

  3. 分层检查

    先查字段与类型，再查分类理由是否符合输入。[1]

每步分别核对输入、操作与结果，执行范围见末节。

用一个最小 JSON 示例

原创练习输入：“任务执行失败，请帮忙查看错误原因。”预期对象写成 {"category":"support","reason":"请求排查失败原因"}。在 Structured Output Parser 的 Schema Type 选择 Generate from JSON Example 后，输入对象。官方说明节点使用属性名和类型，忽略具体值，并将示例中每个字段都视为必填。因此它不会仅凭示例把 category 限制为 support。[1]

什么时候改用手写 Schema

若你需要明确列出类别，可选 Define using JSON Schema，按自己的数据合同填写 enum、required 等字段。例如 category 只允许 support、feedback、other，reason 是字符串。官方说明不支持 $ref，因此把当前所需字段定义在这一份 schema 中。不要把无法解析的复杂引用交给后续节点“补救”。[1]

多条输入时注意子节点表达式

官方特别指出：根节点表达式可逐条解析，子节点表达式总是解析到第一条输入。若 schema 或其他子节点参数使用 {{ $json.name }}，不能假定会为每条消息分别取值。先用两条明显不同的练习输入验证实际数据路径；需要每条不同规则时，把规则选择放在能逐条处理的上游逻辑，并核对连接方式。[1]

格式和语义分开验收

  • 结构检查：对象是否存在 category 和 reason，类型是否符合约定，额外字段如何处理。
  • 语义检查：失败排查归 support；单纯建议归 feedback；不能判断时使用你定义的兜底类别。
  • 异常检查：缺字段、非法类别与空输入分别记录，不把 schema 通过当成业务准确率。

[1]

本页 JSON 示例已在本地解析，字段设计与官方参数说明已核对；没有登录 n8n、运行节点、调用模型或测量分类准确率。类别和练习期望是本站原创验收设计，采用前应按自己的消息类型修改。[1]

本文来源

本站原创整理；官方说明与编辑建议分别标注。

  1. n8n · 核验来源
    查看资料

文中工具

工具目录

n8n

通过节点和工作流连接外部服务、处理数据并加入 AI 步骤，用于业务流程自动化。