GPT-6 Luna 结构化输出：JSON 格式对了，数据就对了吗？

GPT-6 Luna 支持结构化输出，但 JSON 符合格式，不等于字段符合原文。 本文面向需要从客服文本提取数据的开发者，提供三个字段的请求、合成工单和本地校验器，先把验收逻辑跑通，再开展真实模型评估。

2026 年 9 月 24 日核对了 Luna 文档与结构化输出说明。这里的期望答案为预先设定的教学标签，实际运行的是解析和校验代码，没有调用 Luna，也不报告其准确率或延迟。

先定业务规则，再写 Schema

练习包有四条合成工单：重复扣款、登录失败、外观修改，以及夹带“忽略 Schema”指令的普通消息。最后一条中的指令属于待处理数据，不能成为应用要执行的命令。

输出三个字段：category 只能是 billing、access 或 other；order_id 没有信息时为 null；evidence 必须是从原文复制的短片段。先写清分类规则，例如本练习把未提出求助的到货通知归入 other。真实客服团队如果另有物流分类，应重新定义标签，不能照搬这个教学规则。

保留原文与结果的对应关系。否则字段虽然格式正确，复核者仍无法判断工单为什么被分给某个团队。尤其不要把提取出的类别直接当成退款或账号变更授权。

构建完整的 Responses 请求

下载复现包，查看 request.json。示例使用精确 ID gpt-6-luna，并显式设置 reasoning.effort 为 none。这是便于复现的起点，不是“所有提取任务都该关闭推理”的结论。

配置位于 text.format，类型为 json_schema，设置 strict: true。三个字段都列入 required，订单号允许字符串或 null，additionalProperties 为 false。开发者消息规定处理规则，用户消息只承载工单数据。

请使用完整请求和完整 Schema，不要把带省略号的说明片段当可执行请求。真实发送需使用你已获授权的 API 账号，可能产生费用；本文没有执行这一步。协议差异见 Sol/Luna 工具调用迁移教程。

分开看传输、格式和业务判断

HTTP 成功只是第一步。先检查响应是否完成、是否包含拒答，再提取正文。包内 extract_text 遍历消息内容，不假定 output 第一项就是答案；对合成的未完成和拒答响应不返回可接收正文。

本地 validate 只实现狭窄的教学约束，不是通用 JSON Schema 引擎。它允许 null，即使原文实际有订单号，因此完整性还需要额外业务检查。解析器也假定输入是官方响应结构，不能处理任意损坏的 JSON。

生产应用应先用 JSON 解析器，再用维护中的 Schema 校验库，最后执行业务规则。认证、超时、限流、持久化和重试由客户端另行处理。

跑通校验，再看故意保留的反例

解压后，在文件所在目录运行：

python3 lab.py test

只需 Python 3，没有额外依赖，也不联网。11 个断言覆盖虚构订单号、虚构引用、多余字段、未完成响应和拒答分支等情况。

其中一个反例把重复扣款工单改成 access，却保留真实引用。它通过结构与字面证据检查，但与预设的期望类别不符。这个例子说明“格式有效”和“语义正确”是两件事。11 个断言通过不是 Luna 的 11 题全对成绩。

真实评估要保留失败样本

准备独立标注的数据，包含缺失 ID、重复文本、矛盾信息、多语言和歧义案例。开发集与保留测试集分开，模糊标签先由第二位复核者确认，避免拿不稳定答案作为标准。

逐条保存模型 ID、供应商、effort、请求 ID、状态、原始结果、用量和人工判定。分别统计格式通过、类别正确、ID 有依据、无依据声明、拒答和未解决任务。失败调用既计入分母，也计入成本；重试不能抹去第一次失败。

验收门槛应在看结果之前确定。账单问题被错误分流的代价较高时，要单列该类别，并按语言检查错误，不能只看整体平均值。Luna 费用说明用于解释账单；Luna 转 Sol 路由教程则用同一批教学数据说明何时升级、怎样检查被直接放行的错误。