大模型结构化输出实战：把订单意图解析做成可验收的小服务

客服把“上周买的耳机想改地址，别取消订单”丢给机器人后，真正容易出事故的地方往往不在回复文案，而在下游拿到的字段：有时只有 intent，有时把订单号塞进一句解释里，有时又多出一个没人认得的状态。订单服务不该猜模型的排版。把这一步收成固定 JSON 合同，再在自己的接口里验一次，后面的路由、工单和审计才有依据。

先把订单咨询压成一个小而明确的合同

先别急着接几十种售后动作。拿“查物流、改地址、退款”这三个高频意图做一个最小服务，输入是一段用户描述，输出只允许是 track、change_address、refund 或 need_more_info。订单号允许缺失，但缺失时不能伪造。

我会把模型输出和业务对象拆开：前者叫 order_intent，后者才是能进入订单系统的指令。这样一来，模型即使把“地址改到公司”判断成改地址，也仍要通过订单号、订单状态和收货节点这些业务检查。

用 JSON Schema 让模型只交付约定字段

支持结构化输出的模型接口可以接收 JSON Schema。这里的价值不是“得到一段看起来像 JSON 的文本”，而是把对象名、字段类型、枚举和必填项提前写清。官方接口资料也区分了 json_schema 与较早的 JSON mode；前者更适合把字段合同交给程序处理。

import OpenAI from "openai";

const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

const schema = {
  type: "object",
  additionalProperties: false,
  required: ["intent", "order_id", "reason", "confidence"],
  properties: {
    intent: {
      type: "string",
      enum: ["track", "change_address", "refund", "need_more_info"]
    },
    order_id: { type: ["string", "null"] },
    reason: { type: "string", maxLength: 60 },
    confidence: { type: "string", enum: ["high", "medium", "low"] }
  }
};

const response = await client.responses.create({
  model: "gpt-5",
  input: "订单 A202607190021 的地址要改到公司，包裹还没发货",
  text: {
    format: {
      type: "json_schema",
      name: "order_intent",
      strict: true,
      schema
    }
  }
});

const parsed = JSON.parse(response.output_text);
console.log(parsed);

这里有一个常见误会：strict: true 约束的是模型返回的形状，不等于订单系统已经认可这条指令。比如 A202607190021 可能根本不存在，或者订单已经出库；这些都只能由自己的业务服务判断。

在模型输出之后再设一道业务闸门

把 Schema 当成接口第一层。第二层是一个很普通的服务函数：检查字段、查询订单、确认可变更窗口，再给出可观察的结果码。这里别急着把 medium 当成失败；它更像“可以继续问一句”的信号。

type Intent = {
  intent: "track" | "change_address" | "refund" | "need_more_info";
  order_id: string | null;
  reason: string;
  confidence: "high" | "medium" | "low";
};

async function guardIntent(data: Intent) {
  if (data.intent === "need_more_info" || !data.order_id) {
    return { ok: false, code: "ASK_ORDER_ID" };
  }

  const order = await orderRepo.findByOrderId(data.order_id);
  if (!order) return { ok: false, code: "ORDER_NOT_FOUND" };

  if (data.intent === "change_address" && order.shipped_at) {
    return { ok: false, code: "ADDRESS_LOCKED" };
  }

  if (data.confidence === "low") {
    return { ok: false, code: "MANUAL_CONFIRM" };
  }

  return { ok: true, code: "ROUTE_READY", intent: data.intent };
}

日志建议同时记录 request_id、脱敏后的用户句子、order_intent 和 code。不要只记最终路由结果。一次“地址锁定”到底是模型误判、订单状态变化，还是用户没给订单号，复查时需要的是这条完整链路。

本地跑通时，先故意喂三类难输入

别只拿一条标准句子验收。下面三类输入更能暴露合同缺口：

• 信息不全：“快递到哪了？”应返回 need_more_info 或空订单号，而不是猜一个订单。
• 动作冲突：“退款但别取消”应保留简短原因，进入人工确认，不该直接发起退款。
• 边界状态：“刚刚发货还能改地址吗？”即便识别到改地址，也必须由 shipped_at 决定是否拦截。

验收时我更看重结果码是否稳定：同一类缺订单号的输入都落到 ASK_ORDER_ID，已出库改地址都落到 ADDRESS_LOCKED。模型偶尔换一种说法没关系，业务系统不能因此换一种处理方式。

常见问题

有了 JSON Schema，还需要在服务端做校验吗？

需要。Schema 保证字段形状和枚举范围，订单是否存在、能否退款、地址是否还能修改仍是业务事实，必须由自己的数据和规则决定。

模型拒答或没给订单号时要不要重试？

先把它当作正常分支。对于订单号缺失，追问用户通常比重复调用模型更可靠；对网络或限流故障，再走有限次数重试。

为什么不直接让模型调用退款接口？

退款和改址都有状态、权限和金额边界。先生成受限意图，再由业务服务完成鉴权和规则判断，审计链也更清楚。

结构化输出适合哪些场景？

适合分类、字段提取、工单分流、表单预填和规则触发。需要长篇解释或开放式创作时，保留自然语言输出会更合适。

把模型接进业务前，先让接口可验收

这个小服务的关键不在提示词写得多漂亮，而在每一层都能说清“下一步由谁决定”。模型负责把用户意图压进有限字段，Schema 负责收住形状，订单服务负责确认事实，结果码负责让人和监控看懂结局。先用三种意图跑稳，再逐步加入取消、催发货和发票；扩展枚举时同步补测试样本和业务闸门即可。