企业官网建设流程全解析

很多人用 OpenAI 的 API 做应用，第一个被吓退的不是技术难度，而是账单。我见过不少开发者，刚把 Demo 跑起来就发现一天烧掉几百块，然后开始怀疑人生。其实问题不在于模型本身贵，而在于你不会省着用。我最近把几个项目从老的 Chat Completions 接口迁到了 Responses API，配合缓存、结构化输出和模型路由，同样的业务量，成本降到了原来的三分之一以下，说“比官方便宜一半以上”一点不夸张。

这篇文章我不会跟你念文档，我会直接把我踩过的坑、实测过的方案、能用得上的代码全部写出来。适合正在用 API 做应用、被账单困扰、或者准备从 Chat Completions 迁过来的开发者参考。

1. 先搞清楚：Responses API 到底是什么，为什么大家都在换

1.1 Responses API 和传统 Chat Completions 的差异

Responses API 是 OpenAI 推出的新一代接口，官方定位是取代 Chat Completions 成为推荐首选。它不是一个简单的改名，而是把过去散落在各个参数里的能力收拢到一个统一的调用规范里。用生活类比来说，以前你要给客服、售后、技术支持分别打电话，现在只要打一个前台总机，它帮你转接。

具体到技术层面，几个最关键的变化：

• 输入格式统一成input数组，不再区分messages和functions两套体系。
• 工具调用变成了顶层参数tools，返回结果直接带调用参数，省去自己拼解析逻辑。
• 内置了结构化输出text.format，支持 JSON Schema 严格模式，比老的response_format更稳。
• 原生支持 prompt 缓存，只要你把固定前缀写在前面，重复部分自动按缓存价格计费。
• 新增了持续状态管理的能力（比如记忆），不过这个现阶段普通项目用到的不多，我先不展开。

我实际迁移下来的感受是：接口确实更清晰了，但真正让我惊喜的是，它把很多原先需要自己手写的“省钱配置”变成了内置参数。

1.2 “比官方便宜一半”的实现路径有哪些

很多人一听说“Responses API 比官方便宜一半”，第一反应是不是有什么特殊渠道。真不是。它的计费标准和 Chat Completions 是一样的，便宜完全取决于你怎么用。我总结了三条核心路径，后面会逐一实操演示：

第一，模型路由。不是所有请求都值得用最贵的模型。同一个任务，简单的问询用 mini 系列就能做到 90% 的效果，成本却是旗舰模型的几十分之一。

第二，提示词缓存。把系统提示词、工具定义、Few-shot 示例这些固定内容放在 prompt 的最前面，命中缓存后，这部分 token 单价直接打五折左右。Responses API 对这一点支持得非常到位，只要前缀稳定，基本不用额外配置。

第三，结构化输出 + 工具调用。让模型用 JSON Schema 严格模式输出，格式校验由 API 自己做，不会再出现“JSON 解析失败然后整段重试”的惨剧。一次调用搞定，比多次失败重试省钱太多。

这三板斧叠加起来，同样业务量成本砍一半完全不是问题，很多时候还能砍更多。

2. 核心细节解析：真正决定成本高低的几个关键点

2.1 模型选型：不是所有任务都需要顶配模型

先说价格。以写作时的常见公开价格为例，做一个粗对比：

看清楚这个差距：gpt-4o 和 gpt-4o-mini 的输入价格差了 16 倍多，输出差了 16 倍多。如果你做的是一个知识库问答机器人，90% 的请求其实用 mini 系列就够了，没必要每次都上 gpt-4o。

实操心得：我给项目加了最简单的路由规则——请求里如果只是“查商品参数”“翻译一句话”这类任务，直接走 gpt-4o-mini；只有遇到多步推理、代码生成这类复杂任务才升级到 gpt-4o。加一个 if 判断的事，成本直接下来一大截。

2.2 提示词缓存：把重复的前缀变成折扣价

缓存是成本优化里最容易忽略、又最见效的一环。Responses API 会自动检测请求里是否有相同前缀，如果有，就对命中的部分按缓存价计费。以 gpt-4o-mini 为例，正常输入是 $0.15/1M，缓存输入大约 $0.075/1M，差不多打了五折。

要实现高命中率，只需要一个习惯：把固定的东西写前面，把变的东西写后面。系统提示词、工具定义、角色设定、几个固定的示例，都属于“固定前缀”；用户的动态问题、临时的上下文，必须放在这些内容之后。

我见过很多人把用户输入硬塞到系统提示词里，导致前缀每天都在变，缓存完全失效。这是个很隐蔽的坑，后面我会在排查部分详细讲。

2.3 结构化输出与工具调用：少一次解析失败，就少一次重试

很多应用让模型输出 JSON，然后在客户端解析。问题是模型自由发挥时，偶尔会多一个换行、少一个引号，或者把字段名改了。你的代码一看解析失败，只能重新请求，一次任务烧两次钱。

Responses API 的 JSON Schema 严格模式就是为此设计的。你只要在text.format里声明 schema 和 required 字段，API 就会保证输出符合你定义的 JSON Schema，解析失败率基本降到零。工具调用同理，让模型直接返回结构化的函数参数，省去了多轮对话确认的过程，token 消耗明显下降。

3. 实操过程：从零接入 Responses API 并完成成本优化

3.1 环境准备与基础调用

第一步，安装官方 SDK。我用的是 Python 版本，其他语言流程差不多：

pip install openai

第二步，初始化客户端。注意新版 SDK 的用法已经跟老版本不太一样了，建议直接看当前版本文档。接下来是最基础的调用示例：

from openai import OpenAI client = OpenAI(api_key="你的密钥") response = client.responses.create( model="gpt-4o-mini", input="用一句话介绍你自己", max_output_tokens=100, ) print(response.output_text)

这跟原来的 Chat Completions 相比，少了很多需要手动拼的参数，整个调用清爽很多。跑通这一步，思路就基本理顺了。

3.2 我的成本优化三板斧（代码示例）

第一板斧，模型路由。我封装了一个get_model函数，根据任务难度决定用哪个模型：

def get_model(request_type: str) -> str: # 简单任务走 mini，复杂任务走旗舰 if request_type in {"simple_query", "translation", "keyword_extract"}: return "gpt-4o-mini" return "gpt-4o" # 调用时 model = get_model(req.request_type) response = client.responses.create(model=model, input=...)

第二板斧，prompt 分层设计加缓存。看这个示例：

SYSTEM_PROMPT = ( "你是一个商品客服助手。\n" "回答要求：\n" "1. 必须使用简体中文。\n" "2. 只回答与商品相关的问题。\n" "3. 如果用户询问价格，必须引用下方商品信息。\n" ) def build_input(user_query: str): return [ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": f"商品信息：{product_info}\n用户问题：{user_query}"}, ]

注意，SYSTEM_PROMPT永远不变，product_info如果一天内也不变，那它也可以作为稳定前缀的一部分。只要前缀稳定，缓存就会命中，输入成本自动降一半。

第三板斧，结构化输出。商品信息抽取的例子：

response = client.responses.create( model="gpt-4o-mini", input=build_input("这款手机保修几年？"), text={ "format": { "type": "json_schema", "name": "product_answer", "schema": { "type": "object", "properties": { "answer": {"type": "string"}, "price": { "anyOf": [{"type": "number"}, {"type": "null"}] }, }, "required": ["answer", "price"], "additionalProperties": False, }, "strict": True, } }, )

加了strict=True和additionalProperties: False之后，模型输出的结构非常稳定，我几乎不再需要写额外的 JSON 修复代码。

这里提一个容易踩的坑：JSON Schema 里表达“字段可以为空”，不要写"type": ["number", "null"]这种数组形式，要像我上面这样用anyOf包裹，否则部分版本在严格模式下会直接校验失败。

3.3 实测成本对比：用数据说话

拿我一个客服问答项目举例。业务量是每天 5000 次用户请求，每次输入约 1500 token（其中系统提示词和商品信息占 1200 token，动态的用户问题占 300 token），输出约 200 token。两种方案对比如下：

算一下就明白，单纯换模型和打开缓存，就能把成本压到原来的 1/24。即使你的场景必须用 gpt-4o 不能降级，加上缓存和结构化输出，重试率从 10% 降到 2%，每天也能省下 25%-30% 的费用。而如果你优化前就在用 gpt-4o-mini 但没开缓存，加了缓存后按这个场景换算，每日成本大约还能再降 40% 左右。

所以说“比官方便宜一半以上”不是口号，是真的能落地的结果。前提是别按官方文档照抄就跑，要按套路优化。

4. 常见问题与排查技巧实录

4.1 请求超时与流式输出

接入后第一个容易遇到的问题就是超时。Responses API 在模型需要调用工具或输出较长内容时，耗时会明显增加。如果不设置超时，默认连接很容易断。

解决方案有两个：一是把 stream 打开，让内容流式返回，用户体验好很多；二是显式设置 timeout 参数。我的实际配置是在客户端初始化时加上timeout=60，同时在调用时用stream=True。实测下来，流式模式不仅不超时，token 计费也没差别，值得优先采用。

4.2 缓存命中率上不去怎么办

这是最让我头疼的问题。一开始我以为只要把 system 提示词写固定就行，结果账单显示缓存命中率只有 20%。后来排查发现，我把一个时间戳动态塞进了系统提示词，而且用户输入被拼在了前缀里。缓存的设计逻辑是：只有请求的前缀完全一致，才算命中。哪怕你在中间插入一个变化的值，也会导致后面所有内容都无法命中。

解决方案是把所有动态内容移到 prompt 末尾，固定内容保持在头部，且不要带无意义的变化值。调整之后，命中率直接冲到 85% 以上。这个经验真的建议人手一份。

4.3 结构化输出校验失败排查

开启 JSON Schema 严格模式后，偶尔还会报 validation 错误。我的经验是先检查 schema 是否符合 JSON Schema 规范，比如type只能是单个字符串，表达可空字段要用anyOf而不是数组形式。另外 required 字段必须全部出现在 schema 的 properties 里，否则也会报错。

还有一种情况是模型输出内容超出了语义约束，比如你要求它只输出 JSON，它却在前缀加了“好的，我来回答”。这时可以考虑把additionalProperties: False打开，或者用 instructions 把输出边界写清楚。

4.4 踩坑清单速查表

最后再分享一个小技巧

我在实际项目中最后做了一件很受益的事：把成本监控接上了告警。每天凌晨统计前一天的 token 消耗和费用，如果单日费用超过阈值就推送提醒。这样做的好处是，任何一次代码改动导致缓存失效、模型升级，你都能在第一时间发现，而不是等月底账单出来才肉疼。成本优化不是一次性的事，而是一个持续关注的过程。

如果你正准备接入 Responses API，我的建议是先从模型路由和缓存做起，这两个改动成本最低、见效最快。跑稳之后再加结构化输出，最后再考虑更复杂的特性。按这个节奏来，你的 API 账单大概率能降到你满意的水平。