gpt-6.1-sol 是 hiapi 上的推理级文本模型，走 Responses API（POST /v1/responses）对外服务，聊天、编码、分步推理都拿手。如果你已经会调它了，这一篇就是下一步：四个大家最常找它干的活——编码、推理、严格 JSON、工具调用——每个都给出一份复制即用的提示词配方，以及我们实测时它返回的原始输出。鉴权、流式传输、SSE 解析先去看接入指南，这里只讲提示词。
下面每个配方都是一段可以直接放进接入指南请求体里的 JSON。承载提示词的有两个字段：顶层 instructions（人设和格式规则）和 input 数组（任务本体）。全部内容来自真实运行，response.completed 事件里的输出原样贴出。
gpt-6.1-sol 已在 HiAPI 上线，打开模型页 在线试玩，新用户注册送 200 积分。
动手前先知道的三个开关
写提示词之前，有三件事直接决定你怎么写，三点都已对照 hiapi 上 gpt-6.1-sol 的实时模型契约确认。
- 没有
temperature，也没有top_p。 这个执行档把两者（以及max_output_tokens）都关掉了。你调不了采样，输出风格的唯一旋钮是instructions、input和reasoning.effort。想要简洁、确定性的输出，就在instructions里明说，设不了temperature: 0。 reasoning.effort共五档：low、medium、high、xhigh、max（默认medium）。档位越高，模型烧的隐藏推理 token 越多，而这些 token 按输出计费。配方 2 里有实测曲线。- 上下文窗口约 1.05M token（最大输出 128K）。按 token 计费分档：单请求输入超过 272K token 后，输入输出单价约翻倍。日常提示词离这条线很远；做长上下文任务（配方 5）时要心里有数。
配方 1：编码，按规格生成函数
工程人设和输出形态写进 instructions，具体规格放进 input。约束形态（“一个代码块，再加一句话”）能防止推理模型在代码外面包三层前言。
{
"model": "gpt-6.1-sol",
"instructions": "You are a senior Python engineer. Return a single fenced Python code block, then one sentence on complexity. No preamble.",
"input": [
{ "type": "message", "role": "user", "content": [
{ "type": "input_text", "text": "Write `merge_intervals(intervals: list[list[int]]) -> list[list[int]]` that merges overlapping closed intervals and returns them sorted by start. Handle the empty list. Include a docstring." }
] }
],
"reasoning": { "effort": "low" },
"stream": true
}
它的返回（原文照录）：
def merge_intervals(intervals: list[list[int]]) -> list[list[int]]:
"""Merge overlapping closed intervals, returning them sorted by start.
The input list and its intervals are not modified.
"""
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
Time complexity is O(n log n), and space complexity is O(n).
看看这条约束买到了什么：它处理了空列表，修改前先拷贝了每个区间（ordered[0].copy()），调用方的数据原封不动，分析也只给一句话就停。对这种机械编码，effort: low 足够，它用了零推理 token，照样产出正确且不改动入参的代码。
配方 2：推理，用 effort 控制思考预算
调不了 temperature，reasoning.effort 就成了难题面前的主旋钮。提示词不动，只改 effort：
{
"model": "gpt-6.1-sol",
"instructions": "Think step by step, then end with a line `Answer: <value>`.",
"input": [
{ "type": "message", "role": "user", "content": [
{ "type": "input_text", "text": "A bakery sells cookies in boxes of 6 and 11. What is the largest number of cookies that CANNOT be bought exactly? Show the reasoning." }
] }
],
"reasoning": { "effort": "medium" },
"stream": true
}
同一道提示词我们在全部五档上各跑了一次。每一档都返回了正确答案 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 |
<small>*按基础档费率（输入 $0.50 / 1M，输出 $2.50 / 1M）计算，推理 token 按输出计费。数据来自本次实测，截至 2026-10。最新价格见价格页。</small>
实用结论就在最后两行：low 到 high 思考量稳步上升，xhigh 和 max 却封顶在 620 个推理 token 左右，因为这道题根本不需要更多思考。给简单的题拉满档位，买不到更好的答案，只买到同样一个“49”的两倍多输出 token。按难度配档：大部分提示词用 low/medium，任务真的需要更深搜索时才上 high 及以上。
这是 medium 档的输出，可以看看提示词产出的形态：
The largest number is 49 cookies.
1. Show that 49 cannot be bought exactly. Suppose 49 = 6a + 11b, where a, b are nonnegative integers. Taking both sides modulo 6 gives 5b ≡ 1 (mod 6), so b ≡ 5 (mod 6). Thus b must be at least 5, but five boxes of 11 already contain 55 cookies. This is impossible.
2. Show that every number above 49 can be bought. … Every integer at least 50 is one of six consecutive reachable totals plus a nonnegative multiple of 6.
Answer: 49
instructions 里的 Answer: <value> 这行很起作用：它让你能用一行代码解析末行（text.rsplit("Answer:", 1)[-1].strip()），又不用强迫模型丢掉推理过程。
配方 3：按 schema 输出严格 JSON
用散文“请输出 JSON”然后听天由命，是最不可靠的写法。gpt-6.1-sol 支持严格结构化输出：传 text.format 加 json_schema，模型被约束只能产出符合 schema 的 JSON，没有围栏、没有多余文字。
{
"model": "gpt-6.1-sol",
"instructions": "Classify the support ticket. Respond only with the JSON object.",
"input": [
{ "type": "message", "role": "user", "content": [
{ "type": "input_text", "text": "Ticket: 'The 4K upscale endpoint returns a 500 every time since this morning. We have a launch tomorrow and this is blocking us.'" }
] }
],
"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": "You can call tools. When the user asks about a task, call get_task_status.",
"input": [
{ "type": "message", "role": "user", "content": [
{ "type": "input_text", "text": "Can you check what's going on with task_abc123? It's been pending for ages." }
] }
],
"tools": [
{
"type": "function",
"name": "get_task_status",
"description": "Look up the status of an async image/video generation task by its id.",
"parameters": {
"type": "object",
"properties": { "task_id": { "type": "string", "description": "The task id, e.g. '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": "You can call tools. Summarize tool results for the user in one or two sentences.",
"input": [
{ "type": "message", "role": "user", "content": [ { "type": "input_text", "text": "Can you check what's going on with task_abc123? It's been pending for ages." } ] },
{ "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": "Look up the status of an async generation task by id.", "parameters": { "type": "object", "properties": { "task_id": { "type": "string" } }, "required": ["task_id"], "additionalProperties": false } } ],
"reasoning": { "effort": "low" },
"stream": true
}
拿到结果后，它用自然语言做了回答（原文照录）：
Task
task_abc123is no longer pending—it failed because the image URL could not be downloaded (INVALID_REQUEST). Check that the image URL is publicly accessible, then resubmit the task.
call_id 是把两轮换在一起的粘合剂：你的 function_call_output 必须原样回填模型 function_call 里的 call_id，后续轮次才挂得上。
配方 5：长上下文上做有据可查的回答
1.05M token 的窗口，是用来喂真实材料的：日志、changelog、规格文档，然后要求答案出自这些材料。让模型老实回答的模式写在 instructions 里：只允许依据所给文本作答，每条事实都要标注出处。
{
"model": "gpt-6.1-sol",
"instructions": "Answer strictly from the provided CHANGELOG. If a fact is not present, say 'not in the changelog'. Cite the date of each fact you use.",
"input": [
{ "type": "message", "role": "user", "content": [
{ "type": "input_text", "text": "<CHANGELOG pasted here>\nQuestion: A video task's output URL returned my file yesterday but 404s today, and separately my image calls just started returning 402. What two changelog entries explain this, and what should I change?" }
] }
],
"reasoning": { "effort": "medium" },
"stream": true
}
给它一份很短的平台 changelog，它准确捞出了相关的两条，标了日期，还把“发生了什么”和“该改什么”分开讲（原文照录）：
Two entries explain the issues:
1. 2026-10-02 — Temporary output URLs expire. Output URLs on
temp.hiapi.ailive for 7 days, then return 404 … Change: Download the bytes immediately and store your own copy; do not hotlink. UseexpireAtto track expiration.2. 2026-09-20 — Empty balances trigger image-model 402s. An account with a fully empty balance now receives HTTP 402 on all image models … Change: Check whether your account balance is fully empty and replenish it if so.
“标注日期”这条指令是便宜的防幻觉技巧：一条没有日期可指的事实，就是它编出来的事实，答案也因此可以逐条审计。记得分档计费这回事：输入一旦超过 272K token，整条请求就按长上下文的高档费率算。
这次实测踩到的一个坑：流要按 UTF-8 解码
推理模型偏爱 em-dash 和弯引号。写这篇文章时，我们的第一个 SSE 读取器把一个多字节 UTF-8 字符劈到了两个网络分片里，好好的 em-dash（“—”）变成了乱码（“â”）。模型的输出没问题，是客户端逐行解码太急。正确做法是缓冲原始字节，按换行切分，每拿到完整一行再按 UTF-8 解码，不要对半截分片解码。如果你的 gpt-6.1-sol 输出里冒出零散的 Ã/â，原因在这里，不是模型。
FAQ
这篇和 gpt-6.1-sol 接入指南有什么区别？
接入指南讲怎么调这个模型：鉴权、为什么必须流式、怎么解析 SSE。这篇讲怎么提示它：instructions/input/effort 在各类任务上的用法，以及它们产出的真实输出。
把 reasoning.effort 拉到 max 能拿到最好的答案吗？
不免费，也常常不会更好。在我们的测试题上，xhigh 和 max 都在 620 个推理 token 附近封顶，返回的答案和 high 相同。推理 token 按输出计费，给简单题拉满档位只是花更多钱买同一个结果。high 及以上留给真正难的推理任务。
怎么强制模型输出合法 JSON，而不是在提示词里求它？
传 text.format 加 strict 的 json_schema（配方 3）。模型被约束在 schema 的类型和必填键之内。按键名解析，因为 strict 不固定键的顺序。
为什么设不了 temperature 和 top_p？
这个执行档把两者（以及 max_output_tokens）都禁用了。改用 instructions、input 和 reasoning.effort 来塑造输出。
工具调用和聊天模型上的一样吗？
契约稍有不同：工具声明在顶层 tools 数组里，模型用 function_call 条目（而不是 message）回复，你通过追加带相同 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 key 能调 gpt-6.1-sol，也能调平台上所有其他模型。新用户注册送 200 积分，够把上面的配方挨个跑一遍。
