API (Application Programming Interface)：應用程序編程接口。

類比理解：API它不是一個具體的東西，而是一份“餐廳菜單”和一套“點餐規則”。大模型廠商（餐廳）把他們的AI能力（菜品 ）通過這份菜單開放出來，開發者（食客）只要按照規則點餐，就能享用到美味的AI大餐，而無需關心后廚是怎么運作的。

為什么需要：我們不可能在自己的電腦上運行一個像GPT-4那么龐大的模型。API讓我們能通過互聯網，遠程“租用”這些超級大腦的算力來構建自己的應用。（之前直接上手了mcp，總感覺自己不得要領，學習了API調用后對mcp的理解又加深了一些）

二、一個標準的API調用流程是怎樣的？

deepseek API調用示例

調用API就像是完成一次“跨國代購”，有固定的流程和“話術”。

1. 準備“代購訂單”（構建請求體）：

這是一個Python字典，里面寫清楚了所有要求，比如：

model: 要用哪個模型？（"deepseek-chat"）

messages: 我想問什么？（我的Prompt）

temperature: 我希望回答多有創意？

2. 準備“身份證明和郵寄方式”（構建Headers）：

這也是一個字典，告訴服務器“我是誰”以及“我寄的是什么”。

Authorization: Bearer {api_key}：我的“護照”，證明我是付費用戶。

Content-Type: application/json：告訴服務器，我的訂單是用JSON這種通用語言寫的。

3. 發起“郵寄”（發送請求）：

使用requests.post(url, headers=headers,data=payload)這個動作，把訂單和身份證明發到指定的服務器地址（url）。

三、openai庫到底是什么？它為我做了什么？
在調用大模型API時總看到它們說自己支持openai標準庫：

它是什么：它是一個官方提供的“智能代購助理”（SDK - 軟件開發工具包）。

它做了什么：它把上面第二步中所有繁瑣的細節（準備訂單、準備證明、發起郵寄）都封裝起來了。用戶不再需要手動 處理requests、headers和json轉換。

只需要做：

import OpenAI
client = OpenAI(api_key="...")
response = client.chat.completions.create(...)
AI寫代碼
這個“助理”在后臺完成了所有網絡通信的臟活累活，開發者則可以專注于業務邏輯。

四、調用請求體中，必須理解的3個核心參數
1. `model`: 指定要使用的模型。不同的模型能力、速度和價格都不同（如gpt-4o vs

gpt-3.5-turbo）。選對模型是控制成本和效果的第一步。

2. `messages`: 這是與模型對話的核心，一個由字典組成的列表，模擬了完整的對話歷史。

{"role": "system", "content":"..."}：系統提示詞。給AI設定的“人設”和“行為準則”，在對話開始前加載，影響全局。

{"role": "user", "content": "..."}：用戶提示詞。用戶每一次具體、即時的提問。

{"role": "assistant", "content": "..."}：AI的回答。把AI之前的回答也加入歷史，能讓它理解上下文，實現多輪對話。

3. `temperature`: 控制輸出的“隨機性”或“創意度”，取值通常在0到2之間。

`0.0` - `0.3`：輸出會非常穩定、確定，適合做代碼生成、事實問答、文本分類等嚴肅任務。

`0.7` - `1.0`：輸出會更有創意和多樣性，適合寫文章、市場文案、頭腦風暴等。

五、API-Key：我的“賬戶密碼”，如何安全管理？
原則：API Key絕對、絕對、絕對不能直接寫在代碼里！

最佳實踐：使用.env文件。

1. 在項目根目錄創建.env文件。

2. 在文件中寫入：OPENAI_API_KEY="sk-YourSecretKey"。

3. 在項目.gitignore文件中添加.env，防止上傳到代碼倉庫。

4. 在Python代碼中，使用python-dotenv庫加載。

from dotenv import load_dotenv
load_dotenv() # 自動加載.env文件
api_key = os.environ.get("OPENAI_API_KEY")
AI寫代碼
這樣做，代碼和密鑰完全分離，安全且專業。

六、結果藏在哪里？如何從復雜的響應中取出我想要的答案？
API返回的不是一個簡單的字符串，而是一個結構化的JSON對象。答案通常藏在好幾層里面。

路徑：response.choices[0].message.content

拆解：

response: 整個響應對象。

.choices: 一個列表，因為你可以要求API一次生成多個回答。

[0]: 我們通常只取第一個（也是最好的）回答。

.message: 回答的消息主體。

.content: 我們最終想要的、純文本的回答內容。

七、流式輸出 (stream=True) vs. 非流式輸出：核心區別是什么？
這是用戶體驗的巨大差異。

非流式（默認）：

行為：程序會一直等待，直到模型生成全部回答后，一次性返回一個完整的response對象。

優點：代碼處理簡單直接。

缺點：用戶需要面對較長時間的白屏等待。

流式 (`stream=True`)：

行為：程序立刻返回一個`Stream`對象（“水龍頭”），這個對象本身不包含答案。你需要用for循環去遍歷它，一小塊一小塊（chunk）地接收實時生成的內容。

優點：用戶在請求發出后幾乎立刻就能看到文字開始出現，體驗極佳。

缺點：代碼處理邏輯稍復雜，需要循環、拼接字符串

審核編輯 黃宇