gpt-6.1-sol 提示词配方：编码、推理、JSON 与工具调用（附真实输出）

gpt-6.1-sol 是 hiapi 上的推理级文本模型——对话、编码和逐步推理，均通过 Responses API（POST /v1/responses）提供服务。如果你已经知道如何调用它，本页就是下一步：一组可直接复制粘贴的提示词配方，覆盖人们实际最常用的四类任务——编码、推理、严格 JSON 和工具调用——每个配方都附上我们为本文实际运行它时得到的精确输出。有关鉴权、流式传输和 SSE 解析，请从设置指南开始；这里我们只关注提示词本身。

下面每个配方都是一个请求体，直接放进该设置里即可。提示词由两个字段承载：顶层的 instructions（角色设定与格式规则）和 input 数组（任务本身）。这里没有任何理论内容——输出都是从真实 response.completed 事件中原样粘贴的。

三个影响你如何向 gpt-6.1-sol 写提示词的杠杆

在进入配方之前，关于这个模型的三件事会塑造你写的每一条提示词。这三点都已对照 hiapi 上模型的实时契约确认。

1. 没有 temperature，也没有 top_p。 此执行配置会禁用这两者（以及 max_output_tokens）。你无法通过采样来调节确定性或创造性——唯一可调的旋钮是你的 instructions、你的 input 和 reasoning.effort。如果你想要简洁、感觉确定性的输出，就在 instructions 里说明；你无法设置 temperature: 0。
2. reasoning.effort 有五个级别： low、medium、high、xhigh、max（默认 medium）。更高的 effort 会消耗更多隐藏的推理 token——而这些按输出 token 计费。配方 2 展示了真实的曲线。
3. 上下文窗口约 1.05M token（最大输出 128K）。按 token 计费为阶梯式：一旦单次请求的输入超过 272K token，输入/输出费率大约翻倍。对于日常提示词，你远达不到这条线；对于长上下文任务（配方 5），了解这一点值得。

配方 1——编码：按规格生成一个函数

把工程角色和输出的形状放进 instructions，把规格放进 input。约束形状（“一个代码围栏块，然后一句话”）正是阻止推理模型用三段前言包裹代码的方法。

{
  "model": "gpt-6.1-sol",
  "instructions": "你是一名资深 Python 工程师。返回一个单独的 Python 围栏代码块，然后用一句话说明复杂度。不要前言。",
  "input": [
    { "type": "message", "role": "user", "content": [
      { "type": "input_text", "text": "编写 `merge_intervals(intervals: list[list[int]]) -> list[list[int]]`，合并重叠的闭区间并按起点排序返回。处理空列表。包含 docstring。" }
    ] }
  ],
  "reasoning": { "effort": "low" },
  "stream": true
}

它返回的内容（原样）：

def merge_intervals(intervals: list[list[int]]) -> list[list[int]]:
    """合并重叠的闭区间，按起点排序后返回。

    输入列表及其中的区间均不会被修改。
    """
    if not intervals:
        return []

    ordered = sorted(intervals, key=lambda interval: interval[0])
    merged = [ordered[0].copy()]

    for start, end in ordered[1:]:
        if start <= merged[-1][1]:
            merged[-1][1] = max(merged[-1][1], end)
        else:
            merged.append([start, end])

    return merged

时间复杂度为 O(n log n)，空间复杂度为 O(n)。

注意约束带来了什么：它正确处理了空列表的情况，在修改前复制了每个区间（ordered[0].copy()），因此调用方的数据未被改动，并且恰好只给了一句分析就停止。对于这种机械性编码，effort: low 就足够了——它使用了零个推理 token，仍然生成了正确、非原地修改的代码。

配方 2——推理：用 effort 控制思考预算

因为不能设置 temperature，reasoning.effort 就是你应对难题的主要旋钮。保持提示词不变，只改变 effort：

{
  "model": "gpt-6.1-sol",
  "instructions": "逐步思考，然后以一行 `Answer: <value>` 结尾。",
  "input": [
    { "type": "message", "role": "user", "content": [
      { "type": "input_text", "text": "一家面包店用 6 个装和 11 个装的盒子卖饼干。无法恰好买到的最大饼干数量是多少？展示推理过程。" }
    ] }
  ],
  "reasoning": { "effort": "medium" },
  "stream": true
}

我们在全部五个 effort 级别上运行了相同的提示词。每个级别都返回了正确答案 49。变化的是它为此花了多少思考：

reasoning.effort	推理 token	输出 token 总数	约计费用*
low	76	305	≈ $0.0008
medium	121	380	≈ $0.0010
high	209	427	≈ $0.0011
xhigh	626	845	≈ $0.0021
max	622	813	≈ $0.0021

*按基础档费率（$0.50 / 1M 输入，$2.50 / 1M 输出）；推理 token 按输出计费。数据来自本次运行，截至 2026-10。当前费率请查看定价页。

实用的教训在最后两行：effort 从 low 到 high 平稳上升，然后进入平台期——xhigh 和 max 都落在约 620 个推理 token，因为这个问题根本不够难，不需要更多思考。把简单提示词的 effort 拉满并不会换来更好的答案；它只是为同样的“49”多花约 2.5 倍的输出 token。让 effort 与难度匹配：大多数提示词用 low/medium，只有任务确实需要更深搜索时才用 high 及以上。

以下是 medium 的输出，让你看看提示词产生了什么形状：

最大的数是 49 块饼干。

1. 证明 49 无法恰好买到。 假设 49 = 6a + 11b，其中 a、b 为非负整数。两边对 6 取模得 5b ≡ 1 (mod 6)，因此 b ≡ 5 (mod 6)。所以 b 至少为 5，但五盒 11 个装已经包含 55 块饼干。这不可能。

2. 证明 49 以上的每个数都能买到。 ……每个至少为 50 的整数，都是六个连续可达总数之一加上 6 的非负倍数。

Answer: 49

instructions 里的 Answer: <value> 这一行确实在起作用：它让你可以简单地解析最后一行（text.rsplit("Answer:", 1)[-1].strip()），而不必强迫模型丢掉它的推理过程。

配方 3——带 schema 的严格 JSON

不要在用散文里要求 JSON 然后祈祷。gpt-6.1-sol 支持严格结构化输出：传入带 json_schema 的 text.format，模型就会被约束为输出符合要求的 JSON——没有代码围栏，没有多余的散文。

{
  "model": "gpt-6.1-sol",
  "instructions": "对支持工单进行分类。只回复该 JSON 对象。",
  "input": [
    { "type": "message", "role": "user", "content": [
      { "type": "input_text", "text": "工单：'自从今天早上以来，4K 超分端点每次调用都返回 500。我们明天要发布，这把我们卡住了。'" }
    ] }
  ],
  "text": {
    "format": {
      "type": "json_schema",
      "name": "ticket",
      "strict": true,
      "schema": {
        "type": "object",
        "properties": {
          "sentiment": { "type": "string", "enum": ["positive", "neutral", "negative"] },
          "topics": { "type": "array", "items": { "type": "string" } },
          "action_required": { "type": "boolean" }
        },
        "required": ["sentiment", "topics", "action_required"],
        "additionalProperties": false
      }
    }
  },
  "reasoning": { "effort": "low" },
  "stream": true
}

它返回的内容（原样，单行）：

{"action_required":true,"sentiment":"negative","topics":["4K upscale endpoint","HTTP 500 errors","Service outage","Launch blocker","Urgent support"]}

有两点需要内化。第一，strict: true 保证类型和必需键，但不保证键顺序——注意 action_required 最先出现，尽管 schema 中它列在最后，所以按键解析，绝不要按位置解析。第二，你仍然要像处理其他响应一样，从 response.output_text.delta 块中累积答案；schema 塑造的是内容，而不是传输方式。

配方 4——工具调用与结果续接

gpt-6.1-sol 可以调用函数，并且——重要的是——在你返回结果后继续。声明一个 tools 数组；当模型决定调用时，它会发出一个 function_call 项而不是文本。

{
  "model": "gpt-6.1-sol",
  "instructions": "你可以调用工具。当用户询问某个任务时，调用 get_task_status。",
  "input": [
    { "type": "message", "role": "user", "content": [
      { "type": "input_text", "text": "你能查一下 task_abc123 怎么了吗？它已经 pending 很久了。" }
    ] }
  ],
  "tools": [
    {
      "type": "function",
      "name": "get_task_status",
      "description": "根据 id 查询异步图像/视频生成任务的状态。",
      "parameters": {
        "type": "object",
        "properties": { "task_id": { "type": "string", "description": "任务 id，例如 'task_abc123'。" } },
        "required": ["task_id"],
        "additionalProperties": false
      }
    }
  ],
  "reasoning": { "effort": "low" },
  "stream": true
}

响应没有携带文本——只有一个工具调用，作为最终事件中的 function_call 项传递（其参数以 response.function_call_arguments.delta 块流式传入）：

{
  "type": "function_call",
  "call_id": "call_e4a8a52c6db04cafb6a744f3727c456b",
  "name": "get_task_status",
  "arguments": "{\"task_id\":\"task_abc123\"}"
}

现在是基础设置未覆盖的后半部分：运行你的函数，然后把结果交回——将模型的 function_call 和你的 function_call_output（用相同的 call_id 关联）追加到 input 数组，然后再次调用：

{
  "model": "gpt-6.1-sol",
  "instructions": "你可以调用工具。用一到两句话为用户总结工具结果。",
  "input": [
    { "type": "message", "role": "user", "content": [ { "type": "input_text", "text": "你能查一下 task_abc123 怎么了吗？它已经 pending 很久了。" } ] },
    { "type": "function_call", "call_id": "call_e4a8a52c6db04cafb6a744f3727c456b", "name": "get_task_status", "arguments": "{\"task_id\":\"task_abc123\"}" },
    { "type": "function_call_output", "call_id": "call_e4a8a52c6db04cafb6a744f3727c456b", "output": "{\"status\":\"failed\",\"error\":\"INVALID_REQUEST: image url could not be downloaded\",\"created_at\":\"2026-10-17T06:12:00Z\"}" }
  ],
  "tools": [ { "type": "function", "name": "get_task_status", "description": "根据 id 查询异步生成任务的状态。", "parameters": { "type": "object", "properties": { "task_id": { "type": "string" } }, "required": ["task_id"], "additionalProperties": false } } ],
  "reasoning": { "effort": "low" },
  "stream": true
}

拿到结果后，它用平实的语言回答（原样）：

任务 task_abc123 不再处于 pending 状态——它失败了，因为图像 URL 无法下载（INVALID_REQUEST）。请检查图像 URL 是否可公开访问，然后重新提交任务。

call_id 是粘合剂：你的 function_call_output 必须回显模型 function_call 中精确的 call_id，否则后续回合不会绑定到它。

配方 5——长上下文上的有据回答

1.05M token 的窗口是用来喂真实材料——日志、变更日志、规格文档——并根据它回答问题的。让它保持诚实的提示词模式位于 instructions 中：强制它只根据提供的文本回答，并引用每个事实的来源。

{
  "model": "gpt-6.1-sol",
  "instructions": "严格根据提供的 CHANGELOG 回答。如果某个事实不存在，就说 'not in the changelog'。引用你使用的每个事实的日期。",
  "input": [
    { "type": "message", "role": "user", "content": [
      { "type": "input_text", "text": "<此处粘贴 CHANGELOG>\n问题：一个视频任务的输出 URL 昨天返回了我的文件，但今天 404 了，另外我的图像调用刚开始返回 402。哪两条变更日志条目解释了这一点，我应该改什么？" }
    ] }
  ],
  "reasoning": { "effort": "medium" },
  "stream": true
}

给定一份简短平台变更日志，它准确提取了两条相关条目，引用了它们的日期，并将“发生了什么”与“该改什么”分开（原样）：

两条条目解释了这些问题：

1. 2026-10-02——临时输出 URL 会过期。 temp.hiapi.ai 上的输出 URL 有效期为 7 天，之后返回 404……改动：立即下载字节并存储你自己的副本；不要热链接。使用 expireAt 跟踪过期时间。

2. 2026-09-20——余额为空会触发图像模型 402。 余额完全为空的账户现在在所有图像模型上收到 HTTP 402……改动：检查你的账户余额是否完全为空，如果是，请充值。

“引用日期”这一指令是廉价的有据技巧：它让幻觉可见（一个没有日期可指的事实就是它编造的事实），并使答案可审计。请记住阶梯定价——输入超过 272K token 的提示词按更高的长上下文费率计费。

本次运行的一个坑：将流解码为 UTF-8

推理模型喜欢长破折号和弯引号。在撰写本文时，我们的第一个 SSE 读取器将多字节 UTF-8 字符拆到了两个网络块中，把一个干净的长破折号（“—”）变成了乱码（“â”）。模型的输出没问题；是客户端过于急切地按行解码。修复方法是缓冲原始字节，按换行符拆分，并将每个完整的行解码为 UTF-8——不要解码不完整的块。如果你的 gpt-6.1-sol 输出出现零星的 Ã/â 字符，原因就在这里，而不是模型。

常见问题

这和 gpt-6.1-sol 设置指南有什么区别？ 设置指南讲的是调用模型——鉴权、为什么必须流式传输、解析 SSE。本页讲的是提示它——针对具体任务的 instructions/input/effort 模式，以及它们产生的输出。

我能不能直接把 reasoning.effort 提到 max 来获得最佳答案？ 不是免费的，而且常常也不是为了更好。在我们的测试问题上，xhigh 和 max 都进入了平台期，约 620 个推理 token，返回的答案与 high 相同。推理 token 按输出计费，所以把简单提示词拉满，会为相同的结果花更多钱。把 high+ 留给真正困难的推理。

如何强制获得有效 JSON，而不是在提示词里要求它？ 传入带 strict json_schema 的 text.format（配方 3）。模型会被约束为符合 schema 的类型和必需键。按键名解析，因为 strict 不固定键顺序。

为什么我不能设置 temperature 或 top_p？ 此执行配置会禁用这两者（以及 max_output_tokens）。请改为通过 instructions、你的 input 和 reasoning.effort 来塑造输出。

工具调用和聊天模型上的工作方式一样吗？ 契约略有不同：工具在顶层 tools 数组中声明，模型回复一个 function_call 项（不是消息），你通过追加带匹配 call_id 的 function_call_output 来继续（配方 4）。

gpt-6.1-sol 和 gpt-5.6-sol 一样吗？ 它们同属 Sol 家族，共享这套 Responses-API、仅流式的契约；gpt-6.1-sol 是更新的一代。参见 gpt-6 Astra 与 gpt-5.6 Sol 对比了解各代之间如何对应。

从这里开始

把上面的任何配方复制到设置指南的请求体中，换成你自己的任务，并根据难度调整 reasoning.effort。能力介绍和在线试用框在 gpt-6.1-sol 模型页；端点和共享请求格式在 API 文档中；每 token 费率在定价页。一个 hiapi 密钥即可访问 gpt-6.1-sol 以及平台上的所有其他模型。