请使用我最新的 Huawei Gallery Workflow V2.1.3 Stable Skill，快速开发并发布一个全的

前言

在开发大模型应用时，我们经常会遇到这样一种情况：

用户向 AI 提出一个问题，模型能够给出自然、流畅、看起来非常合理的回答。但当我们希望程序进一步处理这些回答时，却突然出现各种异常。

例如：

• 模型返回的 JSON 缺少必要字段。

• 原本应该是数字的字段变成了字符串。

• JSON 前后附带了 Markdown 代码块。

• 模型生成了程序没有定义的状态值。

• 输出格式正确，但业务数据本身不合理。

这些问题在聊天场景中可能并不明显，但一旦进入自动化工作流，就可能影响整个应用的稳定性。

于是，一个值得深入思考的问题出现了：

如何让大模型不仅能够理解用户需求，还能够稳定输出程序可以直接使用的数据？

本文将从实际开发角度出发，介绍大模型结构化输出的常见问题、JSON Schema 的作用，以及如何建立可靠的输出校验与异常恢复机制。

一、为什么大模型的自然语言输出不适合直接进入业务系统？

传统聊天应用主要面向人类阅读。

例如，用户提出：

“帮我整理今天的工作任务。”

模型可能回答：

“今天建议优先完成代码检查，其次整理开发文档，最后准备项目发布。”

这对于人类来说很容易理解。

但如果我们的应用需要自动创建待办任务，就希望模型返回结构化数据：

{
  "tasks": [
    {
      "title": "完成代码检查",
      "priority": "high"
    },
    {
      "title": "整理开发文档",
      "priority": "medium"
    },
    {
      "title": "准备项目发布",
      "priority": "low"
    }
  ]
}

这样，程序便可以遍历 tasks 数组，将对应任务展示到网页上。

问题在于：大模型本质上并不是传统意义上的确定性 JSON 生成函数。

即使提示词明确要求返回 JSON，也可能因为模型能力、上下文变化、输出截断或生成策略等原因，产生不符合预期的内容。

因此，不能简单地认为：

“我已经在提示词中写了返回 JSON，程序就一定能正常解析。”

可靠的应用需要在模型输出与业务逻辑之间增加验证层。

二、结构化输出最常见的四类问题

1. JSON 语法不合法

例如模型输出：

{
  "title": "学习 Python",
  "duration": 7,
}

最后一个字段存在多余逗号。

这在标准 JSON 中是不合法的。

程序使用 JSON.parse() 或 Python 的 json.loads() 解析时，就可能抛出异常。

2. JSON 合法，但字段不符合要求

例如：

{
  "task_name": "学习 Python",
  "days": "七天"
}

这段 JSON 在语法上没有问题。

但是，如果系统期待的字段是 title 和 duration，那么程序仍然无法直接使用它。

也就是说：

JSON 解析成功，不代表数据结构正确。

3. 数据类型错误

假设系统要求：

{
  "duration": 7
}

模型却返回：

{
  "duration": "7"
}

数字与字符串虽然在视觉上很接近，但在程序中属于不同类型。

当系统进一步执行计算、比较或数据存储操作时，可能出现意想不到的问题。

4. 结构正确，但业务语义错误

例如：

{
  "title": "学习 Python",
  "duration": -30,
  "priority": "urgent"
}

这段 JSON 完全可以被解析。

然而，负数学习天数显然不合理，urgent 也可能不是当前系统允许的优先级。

由此可以看出，模型输出至少需要经过三个层次的检查：

语法合法性 → 数据结构合法性 → 业务规则合法性。

三、使用 JSON Schema 约束模型输出

为了降低结构化输出的不确定性，可以使用 JSON Schema 描述业务系统需要的数据格式。

例如，我们希望模型生成学习任务：

{
  "type": "object",
  "properties": {
    "title": {
      "type": "string"
    },
    "duration": {
      "type": "integer",
      "minimum": 1,
      "maximum": 30
    },
    "priority": {
      "type": "string",
      "enum": ["high", "medium", "low"]
    }
  },
  "required": [
    "title",
    "duration",
    "priority"
  ],
  "additionalProperties": false
}

这里定义了几个重要约束：

1. title 必须是字符串。

2. duration 必须是 1 到 30 之间的整数。

3. priority 只能选择三个指定值。

4. 三个字段都必须存在。

5. 不允许输出额外字段。

与单纯在提示词中写“请严格返回 JSON”相比，Schema 能够更清晰地表达程序的数据契约。

部分模型服务支持基于 Schema 的结构化输出功能。

如果使用的模型接口支持这一能力，可以优先考虑通过接口参数提交 Schema，而不是完全依靠自然语言提示词。

需要注意，不同模型平台支持的 JSON Schema 特性可能不同，应当以实际接口文档为准。

另外，即使模型接口支持结构化输出，应用层仍然需要执行自己的数据校验。

因为格式正确与业务内容可信，是两个不同的问题。

四、实战：用 Python 构建一个简单的输出校验器

下面通过一个无需依赖大模型 API 的示例，演示如何验证模型返回的数据。

import json

ALLOWED_PRIORITIES = {
    "high",
    "medium",
    "low"
}

def validate_ai_response(raw_text):
    # 第一层：JSON 语法解析
    try:
        data = json.loads(raw_text)
    except json.JSONDecodeError:
        return False, "JSON 格式不合法"

    # 第二层：整体结构验证
    if not isinstance(data, dict):
        return False, "输出必须是对象"

    required_fields = {
        "title",
        "duration",
        "priority"
    }

    if set(data.keys()) != required_fields:
        return False, "字段不符合要求"

    # 第三层：数据类型与业务规则
    if not isinstance(data["title"], str):
        return False, "标题必须是字符串"

    if not data["title"].strip():
        return False, "标题不能为空"

    if type(data["duration"]) is not int:
        return False, "时长必须是整数"

    if not 1 <= data["duration"] <= 30:
        return False, "时长必须在1到30天之间"

    if data["priority"] not in ALLOWED_PRIORITIES:
        return False, "优先级不合法"

    return True, data

这里有一个容易忽视的细节：

type(data["duration"]) is not int

为什么不简单使用 isinstance(value, int)？

因为在 Python 中，布尔类型是整数类型的子类。

也就是说：

isinstance(True, int)

结果为 True。

如果业务规则严格要求整数，就需要特别处理这种类型关系。

当然，生产环境中通常不需要为每个字段手写全部规则，可以使用 Pydantic、JSON Schema 验证库等成熟工具。

上述示例主要用于说明验证的基本思想。

五、校验失败后，应该让模型重新生成吗？

在实际系统中，模型偶尔生成不符合约束的数据，是需要提前考虑的情况。

一个常见的解决方法是重试。

例如：

第一次模型返回：

{
  "duration": "seven"
}

程序发现类型错误后，可以向模型反馈：

“上一次输出未通过校验。duration 必须是整数，请按照指定结构重新生成。”

但需要注意：

重试不是越多越好。

如果模型连续多次生成不正确的结果，可能意味着：

• 提示词本身存在歧义。

• Schema 定义过于复杂。

• 模型不支持当前约束。

• 输入内容存在冲突。

• 模型输出长度受到限制。

因此，更合理的做法是设置有限重试次数。

例如：

• 第一次：正常生成。

• 第二次：提供明确的字段错误信息，请求修正。

• 再次失败：停止自动执行，返回结构化错误。

对于创建任务、发送消息、修改文件等可能产生外部影响的操作，尤其不能在数据未经验证的情况下继续执行。

如果涉及支付、删除资源或其他高风险操作，还需要额外的权限控制与人工确认机制。

六、一个容易忽略的设计原则：模型负责建议，程序负责执行

在构建 AI Agent 或自动化应用时，一个很重要的问题是：

模型到底拥有多大控制权？

例如，我们希望 AI 根据用户输入决定任务优先级。

模型可以返回：

{
  "action": "create_task",
  "priority": "high"
}

但不能因为模型返回了这个 JSON，程序就无条件执行。

可靠的系统需要进一步确认：

• action 是否属于允许的操作？

• 用户是否授权创建任务？

• 参数是否满足约束？

• 是否存在重复操作？

• 操作是否需要确认？

• 执行失败后如何处理？

可以把整个过程设计为：

用户请求 → 模型生成建议 → 数据校验 → 权限检查 → 业务执行 → 结果验证。

在这个结构中，大模型主要负责理解和生成，程序负责边界约束与最终执行。

这样既能利用模型的语言理解能力，又能减少非确定性输出直接影响业务系统的风险。

七、结构化输出还能在哪些场景发挥作用？

除了待办任务生成，结构化输出还适用于很多 AI 应用场景。

其中，对于数据提取和自动化执行场景，结构化输出的价值尤其明显。

因为这些系统并不只是让用户阅读一段回答，而是希望后续程序能够进一步利用模型生成的信息。

因此，设计清晰的数据契约，往往比单纯优化回答的语言表达更加重要。

八、生产环境中还需要注意什么？

要让结构化输出真正应用于生产系统，还需要考虑以下几个细节。

第一，记录验证失败的原因。

不能只记录“模型调用失败”，还应该区分 JSON 语法错误、字段缺失、类型错误和业务规则错误。

第二，避免把敏感信息写入日志。

模型输入和输出可能包含用户的个人信息、内部业务数据或访问凭据。

日志记录应该遵守最小必要原则，必要时进行脱敏。

第三，为 Schema 建立版本管理。

如果应用新增或修改了字段，模型输出要求与后端程序的验证规则应该同步更新。

否则很容易出现模型按照新结构生成，而业务程序仍按旧结构解析的情况。

第四，不要依赖模型自动纠正所有问题。

某些错误可以通过重试修复，但模型无法代替数据库约束、权限管理和真实业务验证。

第五，设计明确的降级路径。

当模型持续无法返回有效结构时，可以提示用户修改输入、返回安全的默认结果，或者转交人工处理。

对于可能改变外部状态的操作，默认结果不应擅自触发执行。

九、总结

在大模型应用开发中，很多问题并不是模型完全不理解用户，而是模型生成的内容无法稳定满足程序的要求。

对于聊天应用来说，一个自然、完整的回答可能已经足够。

但对于 AI Agent、智能办公和自动化业务系统来说，仅仅“回答得像”远远不够。

系统还需要确保：

• 输出格式能够解析。

• 字段结构符合要求。

• 数据类型与业务规则正确。

• 异常情况能够安全处理。

• 外部操作具有明确的权限和执行边界。

通过 JSON Schema、应用层校验、有限重试和可靠的执行控制，可以让大模型与传统软件系统更稳定地协同工作。

大模型负责生成可能的答案，工程系统负责判断哪些答案可以被安全地使用。

这不仅是结构化输出技术的核心价值，也是构建可靠 AI 应用的一项重要原则。