OpenAI Responses API 文本生成：入门教程

已经装好 OpenAI Python SDK，却还在旧接口、返回数组和提示词角色之间来回试，最容易出现的结果是：请求能发出，代码却取不到正文，或者业务规则被普通输入覆盖。完成这套最小流程后，脚本会通过 Responses API 生成一段文本，并用 response.output_text 稳定读取结果。

开始前需要一个可调用 OpenAI API 的项目、已经配置好的 API 密钥、Python 环境和当前版 openai 包。示例采用 OpenAI 文本生成页面当前展示的 gpt-5.6；如果项目没有该模型的访问权限，应改用项目实际可用的文本模型，不能只靠重复提交解决模型权限错误。

先跑通一条最小文本请求

1. 主要动作：创建 text_demo.py，写入一条只包含模型与输入的 Responses API 请求。入口位置：本地代码编辑器和已经配置 OPENAI_API_KEY 的项目目录。代码如下：

   from openai import OpenAI
   client = OpenAI()
   response = client.responses.create(
       model="gpt-5.6",
       input="用一句话说明为什么要给 API 请求设置超时。"
   )
   print(response.output_text)

   成功标志：运行 python text_demo.py 后，终端打印一段模型生成的文本，没有 Python traceback。失败处理：出现模块缺失时，用运行脚本的同一个 Python 安装 openai；出现认证错误时检查环境变量是否对当前终端生效；出现模型不可用提示时，换成项目可访问的模型后再试。

官方页面把 Responses API 作为直接文本生成请求的推荐入口。下图只看四处：OpenAI() 创建客户端，client.responses.create 发出请求，model 与 input 提供本次参数，随后由 output_text 打印文本。少了其中任何一处，都应先核对代码而不是继续叠加参数。

读取文本时不要固定猜数组位置

1. 主要动作：把业务代码中的固定下标读取改为 response.output_text。入口位置：处理 client.responses.create 返回值的 Python 代码段。成功标志：文本请求能直接得到聚合后的字符串，代码不依赖 output 数组中某一项的固定位置。失败处理：如果确实要分析工具调用、推理信息或其他输出项目，再逐项检查 response.output 的类型和内容；不要先假设文本一定位于 output[0].content[0].text。

下图展示的是官方示例中的 output 数组：当前这一项是 message，内部的内容类型是 output_text。真实请求可能同时返回其他项目，所以这张图证明的是响应层级，不代表所有请求都只有这一种结构。普通文本展示优先使用 SDK 提供的聚合属性，需要解析完整响应时再遍历数组。

用 instructions 固定本次请求的行为

1. 主要动作：把语气、目标和回答规则放进 instructions，把本次问题保留在 input。入口位置：client.responses.create 的参数列表。代码可以改成：

   response = client.responses.create(
       model="gpt-5.6",
       instructions="回答控制在三句话内，先给结论，再给原因。",
       input="为什么生产环境要记录请求 ID？"
   )
   print(response.output_text)

   成功标志：输出遵守三句话和先结论后原因的约束，同时回答 input 中的问题。失败处理：规则没有生效时，先确认 instructions 与 input 没有写反，也没有把互相冲突的要求分散在两个参数里；多轮请求还要注意，上一轮的 instructions 不会自动进入下一轮。

官方说明明确指出，instructions 的优先级高于普通 input，并且只作用于当前响应请求。下图中的两个参数同时出现，适合核对职责是否分开：前者写应用规则，后者写这次要处理的问题。画面与代码不一致时，先回到参数层级检查。

复杂输入改用 developer 与 user 角色

1. 主要动作：需要把应用规则与最终输入拆成多条消息时，将 input 改为角色数组。入口位置：Responses API 请求的 input 参数。代码如下：

   response = client.responses.create(
       model="gpt-5.6",
       input=[
           {
               "role": "developer",
               "content": "回答控制在三句话内，先给结论，再给原因。"
           },
           {
               "role": "user",
               "content": "为什么生产环境要记录请求 ID？"
           }
       ]
   )
   print(response.output_text)

   成功标志：developer 消息提供的应用规则约束了 user 消息的回答，返回文本仍能通过 output_text 读取。失败处理：角色写错或内容结构不完整时，应先检查每项是否同时具有 role 和 content；业务规则被输入改变时，确认规则位于 developer，终端输入位于 user。

下图把两种角色放在同一个 input 数组里。developer 承载应用提供的规则，优先于 user；user 承载最终输入；模型生成的消息使用 assistant 角色。画面中的数组层级与本地代码对不上时，先修正括号和字段位置。

用一次可重复请求确认结果

• 同一个终端能读取 API 密钥，运行脚本时达到“能打印正文”的结果，不再出现认证错误。
• 代码调用 client.responses.create，并使用项目实际可访问的文本模型。
• 普通文本通过 response.output_text 读取，没有依赖固定数组下标。
• 行为规则放在 instructions 或 developer 消息中，实际问题放在 input 或 user 消息中。
• 相同脚本连续运行两次都能打印文本；失败时能区分模块、认证、模型权限、网络与响应解析问题。
• 四张官方截图均可打开，并分别对应最小请求、响应结构、指令优先级和消息角色。

最小请求稳定后，再加入流式输出、结构化数据、工具调用或会话状态。每增加一种能力就保留一条独立验收信号，这样遇到异常时能立即判断问题出在输入规则、返回结构还是新加入的功能。