OpenAI Responses API 写作结果怎么做结构化检查

开始前准备

批量生成文章或提纲后，字段常常缺失或格式不一致：这一条有标题却没有正文，下一条把标签写成句子，还有一条在资料不足时给出了看似完整的结论。若程序直接把可见文本送入编辑器，后续每个环节都要猜测字段含义，人工审核也无法区分模型没有生成、解析程序漏取，还是业务规则拒绝了结果。

OpenAI Responses API 写作结果怎么做结构化检查，关键是把“模型返回了内容”与“内容可进入发布流程”分成两件事。前者是生成状态，后者至少包含语法、字段、业务规则和人工审核状态。资料包所示的 Python SDK 接口中，client.responses.create 接受 instructions、input 与 text 等参数，text 可用于普通文本或结构化 JSON 输出；具体格式配置仍应以项目当前 SDK、模型和接口文档为准。

先确定一份由应用维护的结果契约。契约不是提示词里的愿望清单，而是后端、编辑器和发布器共同使用的字段定义。若需要整理生成请求中的材料区、任务区与约束区，可参考OpenAI Responses API 写作输入怎么组织；本篇聚焦生成完成后的结果接收与检查。

• 任务标识：保留内部任务号、批次号、规则版本、资料版本和生成时间，用于定位同一篇内容来自哪次请求。

• 内容字段：按交付物选择 title、summary、sections、body、tags 等字段。提纲与成文文章应使用不同的内容类型，不要让一个字段同时承担两种结果。

• 证据与风险字段：为关键结论准备 source_refs、open_questions、risk_flags。没有材料支持时，应记录待补信息，而不是用空泛文字伪装完成。

• 校验状态：将 generated、parsed、blocked、ready_for_review、approved 分开保存。发布状态不能只由接口是否返回决定。

字段设计时，每个字段都要写清四项：是否必填、允许的数据类型、长度或数量边界、失败后的处理方式。例如标题必须是非空字符串，标签必须是去重后的字符串数组，章节必须是有序数组；而 open_questions 可以为空数组，却不能用缺失来代替。这样才有稳定的 Responses API 结构化输出边界。

分步操作

将检查拆成固定流水线，批处理任务就不会因为某一条异常结果拖慢整个发布队列。应用侧应始终保存原始响应和解析后的业务对象，不能只留下最终写入编辑器的正文。

1. 定义内容类型：先区分本轮交付的是提纲、文章初稿、标题候选还是审核报告。为每种类型建立独立的字段集和版本号，例如 outline.v1 与 article.v1。不要让“可能有正文”的万能结构流入发布环节。

2. 把约束同时写进请求和校验器：请求中明确要求只输出一个 JSON 对象、字段名称固定、数组字段不得改成字符串、资料不足时写入待确认字段。随后在程序中重复检查这些规则。模型的自检信息只能辅助排错，不能替代程序判断。

3. 保存原始结果：响应返回后先保存响应 ID、请求摘要、原始文本或原始对象、模型名和时间。解析失败时，这份记录能帮助判断是格式问题还是提取路径不匹配，也能避免无法复现的人工补录。

4. 执行语法和类型校验：先确认数据能解析为 JSON，再逐个检查必填键、字符串、布尔值、数组与对象类型。对未知字段可记录告警；对缺少发布必需字段的结果直接阻断，不要偷偷填入默认标题或空正文。

5. 执行内容规则校验：检查标题长度、摘要长度、章节数量、标签去重、正文是否为空、HTML 是否符合编辑器白名单，以及关键词和内容类型是否匹配。这一层是 AI 写作结果检查 的核心，因为 JSON 合法不代表稿件可用。

6. 执行资料边界检查：将关键结论和输入资料的引用标识对应起来。没有对应资料的结论标为待人工确认；不要因为字段完整就把它当成已核实事实。对价格、日期、功能、政策等高风险信息，保留人工审核门槛。

7. 按状态路由：通过结构和内容规则的结果进入 ready_for_review；有缺字段、类型错误或材料缺口的结果进入 blocked；只有人工批准的版本才进入发布队列。批次汇总应同时统计通过、阻断、待确认和重试数量。

建议将“解析成功”记录为一次独立事件，而不是直接覆盖生成事件。这样当编辑反馈某条内容不对时，可以从任务号追到原始响应、解析版本、校验规则版本和人工处理记录。文章字段校验 由此不再依赖某位运营人员的临时判断。

可复制模板

下面的对象可作为文章初稿的业务结果模板。它描述的是应用希望收到和保存的内容，不要求将整段原样作为接口参数。方括号内容由实际任务替换；没有资料支持的项目应放入 open_questions，不要写入正文结论。

{
  "schema_version": "article.v1",
  "task_id": "[内部任务号]",
  "content_type": "article",
  "status": "ready_for_review",
  "title": "[文章标题]",
  "summary": "[摘要]",
  "sections": [
    {
      "heading": "[章节标题]",
      "body": "[章节正文]"
    }
  ],
  "tags": ["[标签]"],
  "source_refs": ["[输入资料标识]"],
  "open_questions": [],
  "risk_flags": []
}

提纲任务不应硬塞入长正文。可以把 content_type 改为 outline，并将每一节改成 heading、points 与 source_refs。解析器先根据 content_type 选择对应规则，再判断字段完整性，避免把提纲误送到文章发布器。

下面是可放入稳定规则或本次输入中的输出约束模板。它只约束结果结构，不替代事实材料、受众说明和写作任务本身。

输出约束：
1. 只返回一个 JSON 对象，不使用 Markdown 围栏，不添加字段外说明。
2. schema_version 固定为 [版本号]；content_type 只能为 [允许类型]。
3. 必填字段为 task_id、content_type、title、summary、sections、tags、source_refs、open_questions、risk_flags。
4. title、summary 和每个 section 的 heading、body 必须是字符串；sections、tags、source_refs、open_questions、risk_flags 必须是数组。
5. tags 使用短词，去重后输出；没有标签时输出空数组。
6. 资料无法支持的结论不得写成事实，应写入 open_questions，并在 risk_flags 标记材料不足。
7. 不得新增未定义字段；不得省略必填字段；无法完成时仍返回完整对象，并将 status 设为 blocked。

程序校验器可按“存在性、类型、范围、关联性”组织。存在性检查键是否出现；类型检查数组与字符串是否被替换；范围检查标题长度、章节数量和标签数量；关联性检查每个高风险结论是否有资料标识。对于正文语义、事实准确性和品牌口径，不要假装能仅靠 JSON Schema 自动解决，应另设规则或人工审核。

翻车修正

结果前后混入解释文字：不要尝试从整段自然语言中用脆弱规则截取花括号后直接发布。先将原始结果标为解析失败，保存响应 ID和原文，再使用更明确的“只输出一个对象”约束重新生成。若需要修复，也只能在隔离的修复任务中完成，并重新走完整校验。

必填字段被遗漏：缺少标题、章节或资料标识时，将该记录置为 blocked。不要由程序凭正文第一句自动补标题，也不要把 null 转成空字符串后伪装通过。默认值只适用于业务明确允许的字段，并应留下填充值来源。

字段类型漂移：常见情况是模型把 tags 写成逗号分隔文本，或把 sections 写成单个对象。校验器应返回具体路径，例如 sections[1].body 类型错误。重试时只附上错误路径和原有契约，避免加入新的写作要求造成内容范围变化。

JSON 合法但内容不能发布：标题与正文不一致、章节重复、正文只有模板话术、关键结论超出资料，均属于内容规则失败。将其与解析失败分开统计，才能知道问题应该修改输出约束、资料供给还是审核规则。

输出被截断：发现字符串未闭合、最后一个章节不完整或字段突然结束时，不要拼接猜测内容。记录为未完成结果，检查本轮允许的输出量与任务规模，并将长文拆成提纲、分节草稿、整合检查等步骤。重新生成时保留相同的资料版本和任务号关联。

批量重试产生重复稿：为每条任务使用稳定的内部任务号和幂等键。相同任务的重试应创建新的尝试记录，而不是覆盖已经通过人工审核的版本。发布器只读取已批准的指定版本，不能只取数据库中时间最新的一条。

模型自报通过却有事实风险：不要把返回的 status 当成最终审核结论。模型可以说明它认为没有问题，但应用仍要依据资料标识、风险词规则和人工复核更新状态。特别是没有证据记录的内容，不应使用“已验证”或类似表述。

完成前检查

在把结果送入编辑器、审核台或发布队列前，逐项核对下面清单。任何一项无法确认，都应保留在待处理状态，而不是为了提高批次完成率强行放行。

• 本轮任务是否有稳定的内部任务号、批次号、资料版本和规则版本，且原始响应已被保留。

• 结果是否能被完整解析为 JSON，没有围栏、额外说明、截断内容或无法识别的字符。

• schema_version 与 content_type 是否属于当前允许的组合，提纲与文章没有混用同一套字段。

• 所有必填字段是否存在，字段类型是否正确，数组字段没有被写成单行文本或单个对象。

• 标题、摘要、章节、正文和标签是否符合各自的长度、数量、去重和非空规则。

• 未知字段、缺失字段和类型错误是否已记录具体路径，并已阻断不合格结果进入发布流程。

• 关键结论是否能关联到输入资料标识；资料不足的部分是否进入 open_questions 或 risk_flags。

• 结果状态是否区分生成完成、解析完成、规则阻断、待人工审核和人工批准，没有把接口成功等同于可发布。

• 重试记录是否保留尝试次数和失败原因，没有覆盖已经审核通过的版本。

• 人工审核者是否能通过任务号追到请求摘要、原始结果、解析结果和校验记录。

• 最终交付物是否仍服务于文章或提纲进入编辑发布流程，而不是偏移成泛泛的接口介绍。

稳定的写作自动化不是要求每次生成都完美，而是让每个异常都有明确去向：格式问题回到解析与输出约束，字段问题回到结果契约，内容问题回到资料与审核，发布问题回到状态路由。把这些边界固化后，批量生成的文章和提纲才能成为可检查、可回退、可协作的内容资产。