当前位置：首页 > news >正文

Python + OpenAI API 2026 入门：10行代码调用GPT，把AI能力嵌进你的产品

news 2026/8/5 22:09:47

我用 Ollama 在本地跑大模型没问题，模型随便换，流量不花钱，感觉挺好。但要做产品接入 AI 能力，API 是绕不过去的路——本地模型推理太慢，占内存，量化后精度打折扣，最重要的是没法稳定地产品化。

本文的目标很简单：让一个会 Python 的人，30 分钟内能写出第一个调用 GPT 的程序。代码能跑，理解到位，坑都给你标出来。

一、先搞懂几个基本概念

磨刀不误砍柴工，这几个概念搞不清楚，后面写代码会一直懵。

LLM API 是什么

LLM API 的全称是 Large Language Model Application Programming Interface。翻译成人话就是：你把一段文字（对话请求）发给云端的大模型，模型处理完后返回一段文字（回答），整个过程按 token 计费。

核心概念速览

Prompt（提示词）：你发给模型的那段文字。它决定了模型输出的质量上限。同样一个模型，Prompt 写得好不好，直接决定回答有没有用。

Token（计量单位）：模型不是按字数计费的，是按 token 计费。一个 token 大约等于 0.75 个英文单词，或者 1~2 个中文字符。你给模型发 1000 字的中文，大概消耗 500~700 个 token。模型返回 500 字，大概再消耗 200~300 个 token。

Temperature（随机性参数）：控制输出的随机程度，取值范围 0~1。设为 0，模型输出基本固定；设为 1，模型输出高度随机。大部分生产场景建议设在 0.7~0.9。

Max Tokens（输出上限）：限制单次回复的最大 token 数。这个很重要——不设上限，模型可能一口气吐出几千字，账单直接爆掉。

API 类比：就像点外卖

点外卖	调用 LLM API
你下单（选菜、填地址）	发请求（Prompt + 参数）
商家接单做菜	模型处理请求
骑手送餐上门	返回结果
按菜品计价	按 token 计费

区别在于：API 的"菜品"是文字，质量参差不齐，不满意也不能差评退款。所以写好 Prompt 比选菜重要多了。

API Key 是什么

API Key 是你的身份凭证，相当于账号密码。创建方式在下一节讲，这里先强调三个最重要的原则：

不要泄露给前端代码。JavaScript 直接调用 OpenAI API 存在严重的安全风险，你的 Key 会直接暴露在用户浏览器里。
不要提交到 GitHub。很多人吃过这个亏，GitHub 有机器人专门扫描代码库里的 API Key，发现即标记，资金被盗刷。
统一管理在环境变量或配置文件中，代码里只引用，不写死。

二、获取你的 API Key

OpenAI 官方

打开 platform.openai.com，注册/登录账号
进入 Dashboard，点击左侧API Keys
点击Create new secret key，复制生成的 Key（格式类似sk-xxxx...）

重要提醒：这个页面只显示一次 Key，关闭后无法再次查看，必须保存好。

国内用户注意：OpenAI 官方服务需要科学上网才能正常访问。如果你的网络无法访问 OpenAI 官网，这一步就会卡住。

国内可用的替代方案

如果你没有稳定的科学上网条件，或者觉得官方 API 贵，以下平台提供 OpenAI 兼容接口：

硅基流动（SiliconFlow）：国内厂商，接入多个开源和商业大模型，提供 OpenAI 兼容 API，用法和官方完全一样，只是 base URL 和 API Key 不同。免费额度对新用户比较友好。

阿里云百炼：阿里云的 AI 服务平台，接入通义千问等模型，同样提供兼容 OpenAI 的接口。

百度智能云：文心一言的 API 服务，接口设计类似，但不完全兼容 OpenAI 格式，迁移时需要调整代码。

本文使用OpenAI 官方接口进行演示，因为它的接口规范已经成为行业标准，其他平台的兼容接口用法基本一致，学会官方接口之后迁移成本很低。

三、Hello World：10行代码调用 GPT

先跑通一个最小可用的例子，感受一下整个流程。

fromopenaiimportOpenAI client=OpenAI(api_key="sk-xxxx")# 替换成你的 API Keyresponse=client.chat.completions.create(model="gpt-4o",messages=[{"role":"user","content":"用一句话解释量子计算"}])print(response.choices[0].message.content)

运行之前先安装官方 SDK：

pipinstallopenai

逐行解释

fromopenaiimportOpenAI

导入 OpenAI 官方 Python SDK，这是目前最广泛使用的调用方式。

client=OpenAI(api_key="sk-xxxx")

创建一个客户端实例，填入你的 API Key。这里建议把 Key 放在环境变量里，而不是直接写死在代码里：

importos client=OpenAI(api_key=os.environ.get("OPENAI_API_KEY"))

client.chat.completions.create(...)

这是调用 chat completions 接口的方法，即对话补全接口。OpenAI 提供了多个接口（completions、chat/completions、embeddings、images 等），对话场景用chat.completions。

model="gpt-4o"

指定使用的模型。gpt-4o是 OpenAI 目前的旗舰多模态模型，支持文本和图像输入。如果想省钱，可以用gpt-4o-mini，效果接近但价格低很多，后面成本控制部分会细讲。

messages=[{"role":"user","content":"用一句话解释量子计算"}]

messages是一个数组，每个元素是一个消息对象。role表示说话的角色：

user：用户（你）发送的消息
assistant：AI 模型的回复
system：系统指令，用来给模型设定角色或行为规则

这里只有一个 user 消息，是最简单的单轮对话。

print(response.choices[0].message.content)

response是一个对象，.choices是返回的选项列表（通常只有一个），.message是消息对象，.content是消息的文本内容。这就是从 API 返回结果中取值的标准路径。

踩坑点：早期版本的 OpenAI 库（v0.x）返回的是字典格式，新版本（v1.0+）改成了对象格式。本文的代码基于 v1.0+ 版本。如果你的代码报错AttributeError，先检查一下openai的版本：pip show openai。

四、进阶：传入参数控制输出

上面的代码能跑了，但生产环境里你需要对输出有更多控制。以下是几个最常用的参数。

Temperature：控制随机性

response=client.chat.completions.create(model="gpt-4o",messages=[{"role":"user","content":"给我写一个 Python 快速排序"}],temperature=0.7# 0~1，越高越随机)

实际建议：

写代码、回答事实性问题：0~0.3。这类场景需要确定性，输出稳定可复现。
写文案、头脑风暴：0.7~0.9。需要一些变化和创意。
0.9 以上：基本就是开盲盒，同一个 Prompt 跑三遍可能出来三个完全不同的答案。

Max Tokens：限制输出长度

response=client.chat.completions.create(model="gpt-4o",messages=[{"role":"user","content":"解释一下什么是 RESTful API"}],max_tokens=500# 限制最多返回 500 个 token)

这个参数是必设的。我自己的习惯是：任何面向用户的请求都设置max_tokens，上限设为预期长度的 1.5 倍，留一点余量。

踩坑点：max_tokens并不是保证输出恰好这么多，而是告诉模型"不要超过这个数字"。如果设置为 10，模型可能只输出 5 个 token 就停了。

Top_p：另一种控制随机性的方式

Top_p 和 Temperature 通常二选一使用，不要同时调。Top_p 的含义是：模型只从概率累加达到 top_p 阈值的词里选择。设为 0.1 表示模型只在最可能的 10% 词汇中选择，设为 1 表示用全部词汇。

对于大多数场景，固定用temperature就够了，理解成本更低。

Stream：流式输出

流式输出的核心好处是：用户能实时看到模型"打字"，而不是等几秒后突然看到完整答案。体验差距很大，特别是输出较长内容时。

fromopenaiimportOpenAI client=OpenAI(api_key=os.environ.get("OPENAI_API_KEY"))stream=client.chat.completions.create(model="gpt-4o",messages=[{"role":"user","content":"用 500 字介绍 Python 的历史"}],stream=True# 开启流式输出)forchunkinstream:ifchunk.choices[0].delta.content:print(chunk.choices[0].delta.content,end="",flush=True)print()

注意：流式输出时，chunk.choices[0].delta.content的内容是增量追加的，所以用end=""避免换行，用flush=True确保实时打印。

流式输出的响应对象不是choices[0].message.content，而是choices[0].delta.content，取值方式完全不同。

五、多轮对话：让 GPT 记住上下文

多轮对话是 AI 应用的基石。单轮对话只能一问一答，多轮对话才能实现真正的交互——用户追问、模型理解上下文、给出连贯回答。

核心机制：messages 数组积累上下文

fromopenaiimportOpenAI client=OpenAI(api_key=os.environ.get("OPENAI_API_KEY"))messages=[{"role":"system","content":"你是一个 Python 助教，用简洁的语言解释概念，不超过 100 字"},{"role":"user","content":"什么是装饰器？"},{"role":"assistant","content":"装饰器是 Python 中一种简洁的函数式编程技巧。"},{"role":"user","content":"能举个代码例子吗？"},]response=client.chat.completions.create(model="gpt-4o",messages=messages)print(response.choices[0].message.content)

这个例子里，messages 数组里有四条消息：

system：设定角色和行为约束（这里限制了回答长度）
user：第一次提问
assistant：模型之前的回答（这很关键——告诉模型"我之前是这样回答的"）
user：追问

最后一条 user 消息发出时，模型已经"看到"了之前的所有对话，因此能理解"举个代码例子"是在接着前面的"装饰器"话题往下问。

实践中的坑：不要无限制追加消息

messages 数组不是越长越好，原因有两个：

成本问题：每次请求都会把整个 messages 数组传给 API，token 数直接决定费用。100 条消息的对话，每次请求都要传这 100 条的 token 消耗，比 10 条消息的对话贵 10 倍。

注意力衰减：大模型的上下文窗口虽然很长（GPT-4o 是 128K tokens），但模型对"远处"信息的关注度会衰减。就像人读一篇超长文章，前面的内容读到后面早就忘了。

推荐的实践方案：保留最近 N 轮对话（建议 10~20 轮），以及第一条 system 消息，超出部分直接丢弃。以下是一个简单的上下文窗口管理函数：

deftrim_messages(messages,keep_recent=20):"""保留最近 N 条消息 + system 消息"""system_msg=[mforminmessagesifm["role"]=="system"]others=[mforminmessagesifm["role"]!="system"]returnsystem_msg+others[-keep_recent:]

这个函数把 system 消息放在最前面（因为模型对开头的内容注意力最强），然后追加最近 N 条消息。

六、Function Calling：让 GPT 做实事

这是 GPT 能真正落地到产品里的关键能力。

Function Calling 的工作原理是：GPT 识别到你需要执行某个具体操作（比如查天气、查数据库、发邮件），不是在文本里编造答案，而是返回一个结构化的"函数调用请求"，告诉你的代码"请调用 get_weather 函数，参数是 city=‘北京’"。你的代码执行完函数，再把结果传回去，GPT 结合结果生成最终回答。

完整示例：查天气

fromopenaiimportOpenAI client=OpenAI(api_key=os.environ.get("OPENAI_API_KEY"))# 第一步：定义可用的工具tools=[{"type":"function","function":{"name":"get_weather","description":"获取指定城市的当前天气","parameters":{"type":"object","properties":{"city":{"type":"string","description":"城市名，如北京、上海、东京"}},"required":["city"]}}}]# 第二步：发请求，告诉 GPT 有这些工具可用response=client.chat.completions.create(model="gpt-4o",messages=[{"role":"user","content":"北京今天天气怎么样？适合穿什么？"}],tools=tools)# 第三步：解析 GPT 返回的工具调用请求tool_calls=response.choices[0].message.tool_callsiftool_calls:forcallintool_calls:func_name=call.function.name args=call.function.arguments# JSON 字符串print(f"GPT 请求调用:{func_name}, 参数:{args}")# 在这里执行真实的 get_weather("北京") 调用# weather_result = get_weather("北京")# ...

当你运行这段代码时，GPT 不会输出"北京今天是晴天…"这样的文字，而是返回一个 tool_call，包含get_weather函数名和{"city": "北京"}参数。

你的代码负责：

解析 tool_calls
执行对应的真实函数（这里需要你自己实现 get_weather，可以用真实天气 API）
把执行结果再传回 GPT

# 第四步：把函数执行结果传回模型，获取最终回答# 假设 get_weather 返回了真实数据weather_result="北京今天晴，气温 26 度，湿度 40%，空气质量良好"# 把结果作为 tool 类型消息追加到 messages 中messages=[{"role":"user","content":"北京今天天气怎么样？适合穿什么？"},{"role":"assistant","content":None,"tool_calls":tool_calls},{"role":"tool","tool_call_id":tool_calls[0].id,"content":weather_result}]final_response=client.chat.completions.create(model="gpt-4o",messages=messages,tools=tools# 还需要再传一次，告诉模型可以继续调用工具)print(final_response.choices[0].message.content)

实际应用场景

Function Calling 的典型应用场景：

AI 客服机器人：识别用户意图后调用订单查询、退换货处理、地址修改等真实业务接口
自动化助手：帮用户查日历、查天气、发邮件、定闹钟，每一步都有真实的副作用
数据查询工具：用户用自然语言提问，GPT 解析成 SQL 或 API 参数，执行查询后返回结果
智能文档助手：用户上传文档后问问题，GPT 调用搜索或摘要函数返回准确答案

本质上，Function Calling 让 GPT 从"一个会说话的语言模型"变成了"一个有行动能力的智能代理"——它能感知、能决策、能操作。

七、常见错误与处理

写代码的人没有不踩坑的，把我见过最多的几个列出来。

401 Unauthorized

AuthenticationError: Incorrect API key provided

API Key 填错了，或者 Key 失效了。检查三件事：

Key 是否完整复制（有没有漏掉开头或结尾的字符）
Key 是否过期或被撤销（去 platform.openai.com 查看状态）
环境变量是否正确设置（os.environ.get("OPENAI_API_KEY")是否真的是你的 Key）

429 Rate Limit

RateLimitError: That model is currently overloaded with requests

请求太快，被限流了。解决方法：

在请求之间加延迟：time.sleep(1)
看一下你的套餐等级，免费账号的 QPS（每秒请求数）很低
如果是高频调用场景，考虑申请更高的 rate limit

500 Server Error

InternalServerError: The server had an error while processing your request

OpenAI 那边出问题了，和你这边代码无关。去 status.openai.com 看一下服务状态，等着就行。生产环境建议加上重试逻辑，用tenacity库实现指数退避重试：

fromtenacityimportretry,stop_after_attempt,wait_exponential@retry(stop=stop_after_attempt(3),wait=wait_exponential(multiplier=1,min=2,max=10))defcall_gpt(messages):returnclient.chat.completions.create(model="gpt-4o",messages=messages)

400 Invalid Request Error

通常是你的请求格式有问题，比如：

messages 数组格式写错了
temperature 超过 2（新版支持到 2，但旧版只支持 0~1）
model 名称拼写错误

看错误信息里的param字段，那里会指出具体哪个参数出了问题。

Context Length Exceeded

BadRequestError: This model's maximum context length is 128000 tokens

对话太长了，超出模型的上下文窗口。GPT-4o 的上下文窗口是 128K tokens，足够长但不是无限的。解决办法就是第五章讲的消息窗口管理——定期清理旧消息，不要无限追加。

Timeout

请求超时，模型响应太慢或者网络有问题。可以单独设置 timeout（单位是秒）：

response=client.chat.completions.create(model="gpt-4o",messages=messages,timeout=30.0# 30 秒超时)

八、成本控制：别让 API 账单爆了

这是很多人在生产环境里最关心的问题。

Token 计费规则

OpenAI 的计费模型是输入和输出分开计费，单位是每千 token 多少钱。以下是本文撰写时的大致参考价格（实际价格以官方定价页为准）：

模型	输入 $/1M tokens	输出 $/1M tokens
gpt-4o	$2.5	$10
gpt-4o-mini	$0.15	$0.6

gpt-4o-mini 比 gpt-4o 便宜约 16 倍。对于大多数场景（客服对话、代码生成、文案撰写），gpt-4o-mini 的效果差异普通用户几乎感知不到。

中文 Token 消耗特别说明

英文按 token 计费时，每个 token 大约对应 0.75 个单词。但中文是字符级别的，一个汉字往往就是一个 token。换句话说，同样字数的文本，中文的 token 消耗量通常是英文的 1.5~2 倍。

OpenAI 官方提供了一个 tokenizer 工具：platform.openai.com/tokenizer，输入任何文字就能看到实际消耗了多少 token。

控制成本的具体方法

方法一：用 gpt-4o-mini 代替 gpt-4o

这是最直接有效的降本手段。大多数产品场景下，mini 模型完全够用。我自己在做的几个项目，能用 mini 的全换成了 mini，API 账单直接降了一个数量级。

什么时候必须用 gpt-4o：需要更强推理能力的时候，比如复杂的多步骤推理、要求长输出的创意写作、需要更精确的代码生成。普通对话和简单任务，mini 够用了。

方法二：设置 max_tokens 上限

每个请求都设一个合理的上限，避免模型"刹不住车"吐出太多内容。这个上限应该略高于你期望的最大长度，比如你希望回答不超过 300 字，就设max_tokens=500左右。

方法三：精简 system prompt

system prompt 也是要消耗 token 的。很多人把 system prompt 写得又臭又长，既浪费钱又容易让模型产生混乱。好的 system prompt 应该简洁有力，几句话说明角色和约束就够了。

方法四：定期清理对话历史

不要让对话无限增长。每次对话开始时传入一个精简的 context，或者定期对历史消息做摘要归档。这不只省钱，还能提高模型输出的质量。

九、Python 生态工具推荐

除了 OpenAI 官方 SDK，Python 生态里还有几个值得了解的库。

LiteLLM：一个接口调用 100+ 模型

fromlitellmimportcompletion response=completion(model="gpt-4o",messages=[{"role":"user","content":"你好"}])

LiteLLM 的核心价值是统一接口。不管你要调用 OpenAI、Anthropic、Google、Azure，还是本地的 Ollama 模型，接口都是一样的。换模型只需要改一个参数，不动业务逻辑代码。

对于需要对比多个模型效果、或者需要灵活切换模型的团队，LiteLLM 很有价值。

LangChain：构建复杂 AI 应用

LangChain 是目前最流行的 AI 应用开发框架，核心概念包括：

Chain：把多个步骤串联起来，比如"查数据库 → 拼 prompt → 调用 API → 解析结果"
Agent：让模型自主决定调用哪些工具
Memory：管理对话历史和上下文

LangChain 很强大，但上手曲线比较陡。我的建议是：先用官方 SDK 学会基础调用，理解 API 的本质之后，再用 LangChain 来组织复杂逻辑。不要一上来就上框架，否则容易变成"用 LangChain 的方式调用 API"而不是"理解 API 的方式来用 LangChain"。

Instructor：结构化输出

有时候你不需要 GPT 生成自然语言，而是需要它返回结构化的 JSON。比如"从简历文本中提取姓名、邮箱、工作年限这三个字段"。

Instructor 就是一个专门解决这个问题的库：

importinstructorfrompydanticimportBaseModelclassResumeInfo(BaseModel):name:stremail:stryears_exp:intresponse=client.chat.completions.create(model="gpt-4o-mini",messages=[{"role":"user","content":resume_text}],response_model=ResumeInfo# 直接指定输出结构)

比 Function Calling 更轻量，适合简单且确定的结构化提取场景。

我的建议：先打好基础

本教程全程使用 OpenAI 官方 SDK，原因很简单——官方 SDK 是理解 API 本质的最佳路径。你理解了 requests/response 的完整结构，再去看 LangChain 的封装，就能明白它在做什么，而不是被框架带着跑。

学完这十行代码之后，按需引入其他工具。工具是手段，不是目的。

十、我的判断

最后说几句观点，不保证全对，但是我踩过很多坑之后的真实想法。

API 调用 vs 本地模型：真正产品用 API

本地模型（Ollama、vLLM、llama.cpp）适合：学习实验、离线场景、数据隐私敏感场景。产品级应用，API 还是更稳定的选择。本地模型的问题是：推理速度受硬件限制，GPU 成本也不低，而且部署运维有额外复杂度。对于大多数团队，用 API 的性价比更高。

GPT-4o mini 解决了"贵"这个问题

之前很多人觉得 GPT API 太贵，不敢在产品里用。mini 模型的出现把成本降了十几倍，这个顾虑基本消除了。我的判断是：大多数面向用户的 AI 产品，用 mini 就够了。省下来的钱可以多做几次 A/B 测试，多迭代几个功能。

最值钱的 AI 编程能力不是调用 API

学会 10 行代码调用 GPT，这不是护城河，这是起点。真正的门槛在于：

设计好的 Prompt：知道怎么写能让模型稳定输出你想要的结果，怎么拆解任务让模型更容易理解，怎么给约束条件让输出可控。
判断什么适合用 AI 自动化：不是所有问题都适合用 LLM 来解决。有些任务用规则引擎更简单、更稳定、更便宜。知道什么时候用 AI、什么时候不用，比会用 AI 重要得多。
系统集成能力：把 AI 能力嵌入真实产品里，涉及错误处理、日志、监控、降级方案、安全防护……这些工程能力决定了 AI 功能的可靠性。