OpenAI Responses API 写作输入怎么组织：文章与提纲的结构模板

用 Responses API 生成文章或提纲时，最常见的卡点不是不会调用接口，而是把主题、资料、写作风格、格式要求和验收标准塞进一段模糊输入。结果往往是模型写得看似完整，却遗漏关键信息、混入未确认事实，或者无法直接交给后续程序处理。解决办法不是无限加长提示词，而是把输入拆成稳定规则、本次资料、交付目标和检查条件四层。

开始前准备

先定义本轮任务的唯一交付物。文章初稿和提纲虽然都属于写作任务，但验收方式不同：提纲重点检查层级、覆盖范围和每部分要点；文章重点检查事实边界、读者对象、篇幅和段落结构。一次请求尽量只选一种交付物，避免同时要求“先给提纲，再写全文，再列标题”，使输出边界失去焦点。

• 写清任务模式：只能是文章初稿、文章提纲、标题候选或内容改写中的一种。
• 整理可用事实：把已经确认的资料、原始链接标识、产品信息或采访笔记单独放入材料区；不确定的信息明确标为待核实。
• 定义读者和用途：例如面向开发者的 API 接入说明，或面向运营人员的内容需求表。读者不同，术语密度和交付格式也不同。
• 列出必须保留项：包括主题、关键词、专有名词、事实边界、字数范围和需要出现的字段。
• 列出禁止项：例如不编造数据、不补充未给出的案例、不输出 Markdown 围栏、不加入与任务无关的推广语。

Responses API 的创建请求可接收文本、图像或文件作为输入；写作流程通常以文本材料为主。接口还提供 instructions，用于插入系统或开发者级规则。实际组织时，可以把长期稳定的写作规则放进 instructions，把每篇文章变化的主题、资料和交付要求放进 input。这样改选题时不必改动整套规范，也便于记录版本。

若流程使用 previous_response_id 继续上一轮结果，要特别注意：新的请求不会自动继承前一轮的 instructions。需要持续生效的写作边界应在新请求中再次传入。若改用 conversation 保存会话状态，则不要同时传入 previous_response_id，两者不能组合使用。

分步操作

下面的顺序适合把写作任务接入内容后台、表单工具或批量工作流。重点是每一层只负责一种信息，后续出现错误时才能定位是资料、规则还是结果检查出了问题。

1. 确定输出形态：先固定为提纲或文章。提纲可要求返回标题、读者问题、段落顺序和每段要点；文章可要求返回标题、摘要、正文和自检说明。不要用“写一篇高质量文章”代替可检查的输出定义。
2. 编排事实材料：按“已确认事实、可引用原文、待核实信息”分组。模型只应根据已确认内容写作；待核实内容可以提示它提出问题或留出标记，不能改写成确定结论。
3. 写入稳定规则：在 instructions 中放入语言、受众、事实边界、语气和输出禁令。例如要求中文写作、不得编造事实、资料不足时说明缺口、不得扩展到无关主题。
4. 写入本次任务：在 input 中按目标、读者、材料、必须包含项、禁止项、输出格式的顺序写。变量信息集中在这里，方便由表单或数据库字段替换。
5. 设置生成边界：使用 max_output_tokens 控制单次响应的最大输出量。这个上限包含可见输出和推理 token，不能把它简单等同于最终中文字符数。需要稳定、集中输出时，可调整 temperature 或 top_p 中的一项，不要同时依赖两项进行采样控制。
6. 保存请求记录：将主题、规则版本、材料版本、模型、输出 token 上限和返回 ID 写入自己的任务记录。metadata 可附加键值信息，但接口对键值对数量、键长度和值长度均有约束，因此只保存便于检索的短标识，不把整篇资料塞进该字段。
7. 分两层检查结果：先由程序判断字段是否齐全、长度是否超限、JSON 是否可解析；再由人工核对主题是否跑偏、事实是否超出材料、语言是否适合读者。接口的 text 配置可用于普通文本或结构化 JSON 输出，但结构化结果仍应在应用侧验证。

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="YOUR_MODEL",
    instructions="你是内容写作助手。只使用用户提供的已确认资料；资料不足时明确指出缺口；不得编造事实。",
    input="任务：生成文章提纲。
读者：准备接入 AI 写作流程的开发者。
主题：如何组织写作输入。
已确认资料：［粘贴资料］
必须包含：读者问题、5 个章节、每章 2 个要点。
禁止：未确认的数据、无关产品推荐。
输出：只返回提纲。",
    max_output_tokens=1200,
    temperature=0.2,
)

print(response)

示例中的模型名应替换为当前项目可用且已验证的模型。调用完成后，不要因为接口返回了内容就立即发布。对写作场景而言，响应成功只代表生成流程完成，不代表事实、结构和读者适配性已经通过验收。

可复制模板

可以先在自己的程序中用一个任务对象收集字段，再将它渲染成 input 文本。这个对象是应用侧组织方式，不是要求直接按原样传给接口；它的作用是让表单、内容库和队列任务使用一致的字段。

{
  "mode": "outline",
  "topic": "［本次主题］",
  "audience": "［目标读者］",
  "primary_goal": "［读者读完后能完成什么］",
  "confirmed_material": "［已确认事实或资料摘录］",
  "unverified_items": "［待核实内容，没有则留空］",
  "must_include": ["［必须出现项］"],
  "must_avoid": ["［禁止项］"],
  "output_rules": "［字段、层级、字数和语言要求］"
}

将这些字段代入下面的模板。稳定规则建议放在 instructions，任务模板放在 input。只有明确要求机器读取结果时，才将输出约束设计成固定字段；只用于人工阅读的文章，过度限制字段反而会降低可读性。

instructions：
你是［内容角色］。使用简体中文。只根据已确认资料写作，不把待核实内容写成事实。主题必须围绕用户指定问题，不扩展成泛泛介绍。遇到资料缺口时，明确写出缺口。遵守输出规则，不输出额外说明。

input：
任务模式：［文章初稿/文章提纲］
主题：［主题］
读者：［读者］
交付目标：［读者需要获得的结果］
已确认资料：［资料］
待核实内容：［内容或无］
必须包含：［列表］
禁止事项：［列表］
输出约束：［例如只返回 title、summary、sections；sections 必须按顺序排列；每项使用短句；不得加入材料外的事实］

例如生成提纲时，可以把输出约束写成“只返回标题、读者问题、五个章节和每章两条要点；每条要点必须能从已确认资料追溯；没有资料支持的部分写待补资料”。这比“写一个专业提纲”更容易由程序和人工共同验收。若需要 JSON，先确认当前 SDK 与模型的结构化 JSON 配置，再在应用侧检查必填字段、字段类型和数组长度。

翻车修正

内容跑成泛泛科普：通常是主题只有名词，没有读者问题和交付目标。把“介绍 Responses API”改为“为开发者提供文章提纲输入结构、输出约束和错误处理步骤”，并在禁止事项中写明不得扩展到未要求的模型评测、价格比较或产品宣传。

模型补充了材料外事实：不要只追加“准确一点”。应把材料分成已确认和待核实两区，并在 instructions 中要求只使用已确认区。结果检查时，将每个关键结论回查到输入材料；无法对应的句子应删除、改为待核实，或补入可靠资料后再生成。

输出太短或中途不完整：先检查 max_output_tokens 是否与任务规模匹配。该参数限制的不只是最终可见文字，因此长文任务可拆为提纲、分段草稿、整合校对三步。不要一边要求完整长文，一边给出很低的输出上限。

JSON 无法解析：将机器读取和自然语言写作分成两个阶段。第一阶段要求固定字段和结构化 JSON，第二阶段再把字段内容渲染成文章。接口支持通过 text 配置请求普通文本或结构化 JSON，但无论使用哪种方式，应用仍应捕获解析错误、校验字段并保留原始响应，不能假设每次结果都可直接入库。

长上下文请求返回 400：检查输入是否超过所选模型的上下文窗口。truncation 默认是 disabled，输入过长时请求会失败；设为 auto 时，接口会通过丢弃会话开头的项目来适配窗口。写作任务若依赖早期资料，不应盲目启用自动截断，应先压缩重复材料、保留关键事实，并记录删减规则。

续写时突然丢失语气或边界：使用 previous_response_id 时重新传入需要持续生效的 instructions。把“沿用上一轮要求”留给模型自行推断不够稳妥，特别是在需要严格事实边界、固定字段或合规检查的任务中。

一次修改后不知道哪里变了：每轮只调整一个变量，例如只改读者、只改输出规则或只改材料长度。保留请求版本和结果版本，才能判断问题是来自提示词、采样参数、材料质量还是后处理校验。

完成前检查

• 任务模式是否唯一，已明确区分文章初稿、提纲或改写任务。
• instructions 是否只保存长期稳定的角色、事实边界和输出规则，避免混入本次临时资料。
• input 是否包含主题、读者、交付目标、已确认资料、必须包含项和禁止项。
• 所有关键结论是否能回查到输入中的已确认材料，待核实内容没有被写成确定事实。
• max_output_tokens 是否足以覆盖本轮任务，并已考虑其包含可见输出和推理 token。
• 是否只调整了 temperature 或 top_p 中的一项，而非同时用两项制造难以复现的变化。
• 需要结构化结果时，应用侧是否验证了 JSON 可解析性、必填字段、字段类型和长度。
• 使用 previous_response_id 时，是否重新传入必须持续生效的 instructions，且没有同时使用 conversation。
• 长输入是否评估过上下文窗口和 truncation 策略，没有让关键早期材料被无意丢弃。
• 是否保存了任务标识、资料版本、规则版本、模型、参数和原始响应，便于复现与排错。
• 最终内容是否真正解决了最初的写作问题，而不是从具体交付物偏移成泛泛介绍。

把 Responses API 写作输入组织成可替换的字段后，文章和提纲就不再依赖一次性的长提示词。稳定规则负责守住边界，本次材料负责提供事实，输出约束负责让结果可验收，错误处理则负责在流程出错时找到具体环节。这样的结构更适合接入自己的编辑器、选题库或内容审核流程。