企业官网建设流程全解析

1. 项目背景与核心思路：为什么偏偏用 Python 调大模型

做后端开发这些年，我接触过不少调用大模型（LLM）的项目。从最初拿几个请求试试水，到后来在真实业务里做智能客服、内容审核、文档抽取，绕来绕去，最后兜兜转转还是回到 Python。不是因为 Python 比其他语言高级，而是它在这个领域的生态实在太顺手了。

先说这个项目到底做什么。简单说，就是用 Python 写一套服务，让程序能主动调用大模型接口，输入提示词，拿到生成结果，再把它对接进自己的业务流程里。它解决的问题很直接：你不想让业务员复制粘贴去网页里问问题，你想让系统自动批量处理文本，或者让机器人能根据上下文给出像样的回答。这些需求，本质上都是“程序调用大模型”这一件事。

适合谁看？如果你刚接触大模型开发，想搞清楚从零开始怎么调用接口；或者你已经在用别人的封装工具，但想弄明白底层请求是怎么发的；再或者你想把大模型接进自己的项目，但不确定选 SDK 还是直接裸调 HTTP——这篇文章都能给你一个比较完整的参考。

实际动手之前，我建议你先想清楚两件事。第一，你的数据量大概多大，对响应延迟有多敏感。第二，你是想要稳定的服务，还是只是本地跑个验证。这两个问题直接决定后面选型：是走官方 SDK 走到底，还是自己封装 HTTP 请求加超时重试，甚至是直接部署本地模型。我在某公司做文本审核系统的时候，一开始图省事全用 SDK，后来发现并发一高，SDK 默认配置根本扛不住，才回过头自己封装请求层。所以，前期的思路整理，远比写代码重要。

从技术选型来看，Python 调用大模型主要有两条路：一是用各家平台提供的 SDK，二是直接用 HTTP 请求调接口。SDK 的好处是封装了签名、请求头、流式解析这些脏活，你只管传参数接返回值；缺点是多了一层依赖，有些 SDK 更新不及时，反而耽误事。自己写 HTTP 请求则更透明，出了任何问题你都能一查到底，而且不绑定某个平台的 SDK，换模型供应商时改动更小。

我在实际项目里通常的取舍是：快速验证和原型阶段，无脑用 SDK，节省时间；一旦进入生产环境，我更倾向自己封装一个轻量客户端，把鉴权、超时、重试、日志都掌握在自己手里。这个思路后面会展开细讲。

2. 环境准备与基础调用实现：从安装到第一次返回

2.1 先把环境和依赖搭起来

开发环境其实没什么特别，Python 版本建议 3.9 以上，太老版本的 3.6、3.7 在处理某些类型注解和异步支持上会有些别扭。我常年用的是 3.10，稳定省心。虚拟环境必须建，这不是可有可无的习惯，而是避免不同项目之间依赖冲突的底线操作。

装依赖建议直接用 pip，安装核心工具。以目前最通用的调用方式为例，你需要两个东西：一个是 HTTP 请求库，另一个是官方 SDK。

python -m venv venv source venv/bin/activate pip install requests openai

如果你用的是国内云厂商的模型平台，一样有对应的 SDK 可以装，但它们大多兼容 OpenAI 的接口格式，所以这个 openai 库其实有双重用途：既可以连 OpenAI 官方，也可以把 base_url 改一下，指向你的国内供应商。这是很多教程没点破的，但实际用起来非常方便。

2.2 获取 API Key 与鉴权配置

API Key 是大模型服务的通行证。你需要在模型服务商的开放平台创建一个账号，开通模型服务后拿到一串类似“sk-xxxx”的密钥。这一步看起来简单，实际操作中有两个坑。

第一个坑是：别把 Key 硬编码在代码里。很多人图省事直接在文件里写api_key = "sk-xxx"，结果一提交代码库，Key 就泄露了。正确做法是存到环境变量里，或者用配置中心管理。

export OPENAI_API_KEY="你的密钥"

第二个坑是：注意区分 API Key 和 Endpoint 的关系。有些平台除了 Key 还要配置资源 endpoint，比如某些云厂商的模型服务需要你先创建推理实例，拿到 endpoint 地址，再填到 base_url 里。这个地址相当于大模型服务的门牌号，填错了直接连接失败。

2.3 第一次调用：写一个最小的请求脚本

环境就绪、密钥配置好之后，可以做第一次调用。目标只有一个：让大模型回一句话，验证全链路是通的。这是最朴素的 Hello World，但它的意义重大——后面所有的复杂功能，都是在这个基础上长出来的。

先看用官方 SDK 的最小版本：

from openai import OpenAI client = OpenAI( api_key="sk-xxx", # 实际开发请使用环境变量 base_url="https://你的服务地址/v1" ) response = client.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "system", "content": "你是一个乐于助人的助手。"}, {"role": "user", "content": "用一句话解释什么是面向对象编程。"} ], temperature=0.7 ) print(response.choices[0].message.content)

跑一下，通常几秒内就能看到模型生成的文本。如果报错，不用慌，绝大多数情况是鉴权问题或网络问题。先检查 Key 是不是真的传对了，再看 base_url 是不是填对了，还不行就打印出完整的异常信息看看是哪一步断的。

我习惯在第一次调用的时候把 response 整个打印出来翻一翻，不要只看内容字段。因为响应体里藏着很多重要信息：usage字段是 token 消耗，model字段确认是不是你要的模型版本，finish_reason告诉你生成是正常结束还是触发了长度限制。这些信息后面调优参数时全靠它们。

2.4 把裸调用升级成可重用的函数

第一次调用成功后，紧接着就该把调用逻辑封装成函数。不要每次都写一大坨请求代码，否则后面改一个超时参数要改十个地方，心态直接崩。

我做了一个相对通用的封装，分享一段核心代码：

import json import time from openai import OpenAI from typing import Dict, List, Optional class LLMClient: """一个简单的LLM客户端封装，提供基本的调用能力。""" def __init__(self, api_key: str, base_url: str, model: str = "gpt-4o-mini"): self.client = OpenAI(api_key=api_key, base_url=base_url) self.model = model self.default_temperature = 0.7 def chat( self, messages: List[Dict[str, str]], temperature: Optional[float] = None, max_tokens: Optional[int] = None, timeout: int = 60, retry_times: int = 3 ) -> str: """执行一次对话补全，返回模型生成的文本内容。""" current_temperature = temperature if temperature is not None else self.default_temperature last_error = None for attempt in range(retry_times): try: response = self.client.chat.completions.create( model=self.model, messages=messages, temperature=current_temperature, max_tokens=max_tokens, timeout=timeout ) return response.choices[0].message.content except Exception as e: last_error = e print(f"第{attempt + 1}次调用失败: {e}") if attempt < retry_times - 1: time.sleep(2 ** attempt) continue raise last_error # 使用示例 client = LLMClient( api_key="sk-xxx", base_url="https://你的服务地址/v1" ) result = client.chat( messages=[ {"role": "system", "content": "你是文本摘要专家。"}, {"role": "user", "content": "请为下面这段文字写一个50字的摘要：..."} ] ) print(result)

这个封装虽然简单，但已经把工程上最基本的要素都放进去了：可配置的模型名和温度、超时控制、错误重试。注意重试我用的是指数退避策略，也就是第一次失败等 2 秒，第二次失败等 4 秒，避免在服务端抖动的时候加重负载。

这里有一个很关键的经验：对大模型服务的调用，默认就要考虑失败的可能。网络闪断、服务端限流、超时，这都不是偶发问题，而是常态。所以任何一个进入生产环境的调用，都必须有重试机制，而且要限制重试次数和间隔，不能无限重试，否则系统会卡死在等待上。

3. 核心机制深度拆解：消息格式、流式输出与上下文管理

3.1 messages 参数与角色机制

大模型聊天接口的核心输入是messages，它是一个数组，里面每一项都有role和content两个字段。role一共有三类：system、user、assistant。这三者各有各的分工。

system消息用来设定模型的整体行为模式，比如“你是一个严谨的编辑”，或者“你只回答与编程相关的问题”。它在对话里只出现一次，放在最前面，作用是给整个对话定基调。实际业务里，系统提示词是你唯一可以完全控制模型行为的地方，重要性怎么强调都不过分。

user消息就是用户的输入，你问什么、传什么文本，都在这里。assistant消息则是模型之前的回答。为什么要手动传回 assistant 消息？因为大模型接口本身不维护对话状态，它是个无状态的服务。你如果想要多轮对话能力，就必须把历史对话全部塞进 messages 里发过去。

这个概念我多说两句，因为很多人第一次接触都懵。你把大模型想成一个记忆力很差的人，它只见面前的这张纸条，纸条上写着你给它的所有历史对话。你多写一轮，它就多想一层；你不写，它啥也不记得。所以多轮对话实现起来不复杂，就是每次请求都把历史记录拼接起来。

3.2 流式输出：大模型交互体验的关键

默认情况下，大模型接口会等生成完所有内容，一次性返回完整结果。这个等待时间在长文本生成时可能长达好几十秒，用户体验非常差。所以，在实际产品中，几乎清一色使用流式输出，也就是像打字机一样，一个 token 一个 token 地往外蹦。

现在我来拆解流式输出的代码实现。SDK 的stream=True参数打开后，返回的不再是完整响应，而是一个可迭代的生成器，每迭代一次就吐出一小片增量：

from openai import OpenAI client = OpenAI(api_key="sk-xxx", base_url="https://你的服务地址/v1") response = client.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "system", "content": "你是一个讲故事的高手。"}, {"role": "user", "content": "讲一个关于程序员的小故事，200字左右。"} ], stream=True ) collected_chunks = [] for chunk in response: # 每一次chunk都可能携带内容增量 delta = chunk.choices[0].delta if delta and delta.content: content_piece = delta.content print(content_piece, end="", flush=True) collected_chunks.append(content_piece) full_text = "".join(collected_chunks)

流式输出的几个注意点得拎出来讲清楚。

• 不是每个 chunk 都有内容，有些 chunk 只是携带一些状态信息，所以每次都要判断delta.content是否为空。
• 流式响应里拿不到usage信息，因为内容没生成完，token 消耗是最后才汇总的。如果你需要统计用量，可以自己数一下内容字符数量，粗略估算。
• 流式过程每条 chunk 可能恰好把一个字符劈成两半，所以如果需要累加完整结果，不能只在控制台打印，得把内容拼起来。

另外，可能有些读者会问：流式输出是不是一定会比非流式快？答案是否定的。模型的推理速度并没有变快，流式只是“边生成边返回”的体验优化，让用户感觉响应更快，但从总时长上看其实差不多。它真正解决的是“时间到出结果”之间的空白等待问题，属于感知层面的优化。

3.3 上下文管理与 Token 计算

多轮对话一旦跑起来，问题马上就会暴露：messages 越来越长，token 消耗越来越大，早晚碰到模型的上下文窗口上限。比如某模型的上下文窗口是 128K，你塞下 200 轮对话也没啥问题，但每轮请求都把全部历史发过去，费用和时间都在涨，最后业务根本撑不住。

常规做法是滑动窗口截断：只保留最近 N 轮对话，更早的丢掉或者做摘要压缩。这一块没有完美方案，我需要给一个实际能落地的参考做法。

from typing import List, Dict MAX_HISTORY_ROUNDS = 10 def build_messages_with_window( system_prompt: str, history: List[Dict[str, str]], user_input: str ) -> List[Dict[str, str]]: """构建带滑动窗口的messages，只保留最近MAX_HISTORY_ROUNDS轮历史。""" messages = [{"role": "system", "content": system_prompt}] # 取最近几轮历史 recent_history = history[-MAX_HISTORY_ROUNDS:] messages.extend(recent_history) # 加上当前用户输入 messages.append({"role": "user", "content": user_input}) return messages # 调用时维护一个外部的history列表 history = [] while True: user_text = input("你：") if user_text == "exit": break messages = build_messages_with_window( system_prompt="你是一个耐心可靠的助手。", history=history, user_input=user_text ) result = client.chat(messages=messages) history.append({"role": "user", "content": user_text}) history.append({"role": "assistant", "content": result}) print(f"助手：{result}")

这个窗口截断逻辑很简单，但有一个容易忽略的坑：截断后，如果最新几条历史里最后一条是 user 消息而不是 assistant 消息，下一轮把 user 消息又追加一次，就会出现连续两条 user 消息，触发模型行为异常。解决方法是，截断后检查最后一条的 role，如果是 user，就再往前留一条 assistant，或者干脆丢弃该条。

更进阶的做法是“历史摘要”：早期对话每隔一定轮次用模型生成一段摘要，然后以摘要文本的形式放回系统消息里，相当于模型忘记了细节，但记住了要点。这个方案效果最好，但实现成本也最贵，要根据业务场景权衡。

4. 工程化实战：参数调优、结构化输出与集成模式

4.1 核心参数详解：temperature、top_p、max_tokens

调用大模型时，除了 messages，还有几个参数直接影响生成质量。很多人对这些参数的理解停留在“抄别人配置”的层面，这不行，你得搞清楚每个参数在控制什么。

temperature控制创造性，取值范围一般是 0 到 2。值越低，输出越保守、稳定、可预测；值越高，输出越发散、多样、有创造性。我做一个业务上的参考：抽取结构化数据时用 0.1 到 0.3，写营销文案时用 0.8 到 1.0。注意 temperature 不是一个“创意开关”，它改变的是 token 采样的概率分布，值高的时候模型更愿意选择概率稍低的候选词，输出自然就更多样。

top_p是另一种采样策略，也叫核采样。它设定一个概率累积阈值，比如 0.9，那么模型只从累积概率达到 90% 的候选词里选词。简单理解就是控制“考虑范围”：范围大，多样性高；范围小，输出更集中。实际使用建议：temperature 和 top_p 二选一进行调优，不要同时大幅调整，不然效果很难预期。

max_tokens限制生成的最大 token 数。设太短会被截断，设太长会浪费钱和时间。我的经验是：先估算你期望的答案长度，再换算成 token 数。中文一个大字大约对应 1 到 2 个 token，英文一个单词大约 1 到 2 个 token，具体因分词器而异。

有一个经常被新手忽略的点：finish_reason字段。当它返回"length"时，意味着生成是因为达到 max_tokens 上限被强制截断的，你需要调大 max_tokens 或者优化提示词让输出更精简。如果返回"stop"，才是正常完成。

4.2 结构化输出：把模型结果变成 JSON

在真实项目里，你很少会让大模型只回一段话完事。更多时候，你希望它从一段文本里抽取姓名、时间、金额，然后以 JSON 格式返回，直接供下游程序解析。这就是结构化输出。

方法其实不复杂，核心就是：在 system 消息里明确定义输出格式，并且在 user 消息里强调“只输出 JSON，不要多余内容”。但这样做有几个坑：模型偶尔会在 JSON 前后加 Markdown 代码块标记，或者把解释文字混进去。所以拿到模型输出后，需要做一次清洗和容错解析。

我提供了一个相对健壮的 JSON 解析函数：

import json import re from typing import Any, Dict def parse_model_json(raw_output: str) -> Dict[str, Any]: """从模型输出中提取JSON对象，容忍代码块标记和冗余内容。""" if not raw_output: raise ValueError("模型输出为空") # 去掉可能的代码块标记 cleaned = raw_output.strip() if cleaned.startswith("```"): # 去掉开头的 ```json 或 ``` 标记 lines = cleaned.split("\n") if lines and lines[0].startswith("```"): lines = lines[1:] if lines and lines[-1].strip() == "```": lines = lines[:-1] cleaned = "\n".join(lines) # 尝试直接解析 try: return json.loads(cleaned) except json.JSONDecodeError: pass # 从字符串中提取JSON对象子串 pattern = r"\{.*\}" match = re.search(pattern, cleaned, re.DOTALL) if match: try: return json.loads(match.group(0)) except json.JSONDecodeError: pass raise ValueError(f"无法从模型输出中解析JSON: {raw_output[:200]}")

配合前面的 LLMClient 使用，就组成了一个非常实用的信息抽取流程：

messages = [ {"role": "system", "content": "你是一个信息抽取助手。请从用户文本中抽取指定字段，以JSON格式输出，字段包括：人名、日期、金额。"}, {"role": "user", "content": "2025年3月15日张三报销了1275.5元的差旅费。"} ] raw = client.chat(messages=messages, temperature=0.1) data = parse_model_json(raw) print(data) # 预期输出: {"人名": "张三", "日期": "2025年3月15日", "金额": 1275.5}

除了手工提示词约束，现在有的模型服务商支持响应格式参数，比如response_format={"type": "json_object"}，能从接口层面保证输出是合法 JSON。有就尽量用，比提示词约束稳定得多。

4.3 接入业务系统：异步化与缓存策略

当大模型调用要接进真正的业务系统时，有两个性能问题绕不开：慢和贵。慢，是因为模型推理本身耗时；贵，是因为每个 token 都在花钱。针对这两点，我的策略就是异步化和缓存。

异步化的具体做法是：把大模型调用封装成异步函数，放到消息队列里慢慢消费，然后把任务状态返回给调用方。业务代码可以定期来查状态，拿到结果后再继续处理。这样即使用户一下子提交了 100 个任务，系统也不会把请求线程全部占满等大模型慢慢推理。

缓存策略更直接：相同的输入直接返回上次的结果，不用再调用模型。实际能用的缓存时机有三个。一是对话级别的缓存，用户问的完全相同问题短时间内再问一遍，直接命中缓存；二是场景化的 Prompt 缓存，如果 system prompt 是固定的长文本，直接存下来重用；三是语义缓存，把用户输入做 embedding 向量化，在向量库里找相似问题，找到就直接复用答案。

缓存是一把双刃剑，我在实际使用中有两个血泪教训。第一个，启用语义缓存时相似度阈值别设太低，否则两个意思相近但实际需求完全不同的问题会拿到同一个答案。第二个，涉及价格、库存、政策类信息，绝对不能长期缓存，这类数据变化极快，最好带一个较短的过期时间，比如五分钟。

5. 本地模型方案与选择建议：能不能不花接口费

5.1 本地模型的价值与局限性

很多人做了一段时间 API 调用之后会开始想：能不能用本地模型？原因无非两种：一是隐私敏感，数据不能出内网；二是调用费用太高，想省点钱。

本地模型的价值在这两个场景下是实实在在的，但代价也不小。本地推理需要 GPU 资源，一张入门级的消费级显卡跑不太大的模型，生成速度可能只有 API 的十分之一。而且模型的本地部署、依赖管理、运维调优，都是额外成本。你省下的 API 费用，可能都搭进服务器租金和运维时间里了。

所以我一般不建议一上来就本地化，而是先用 API 把业务逻辑跑通，验证价值，再评估迁移成本。只有当你确认模型调用量足够大、隐私要求足够严格这两个条件至少满足一个时，本地化才值得认真考虑。

5.2 本地模型的 Python 调用路径

主流方案是跑一套兼容 OpenAI 接口协议的推理服务，比如用 vLLM 或 llama.cpp 把模型加载起来，暴露一个本地 HTTP 服务，然后在 Python 代码里用一样的 OpenAI SDK 去调，只是把 base_url 指向http://localhost:8000/v1。

这样一来，你的业务代码完全不用改，只改一个环境变量就切换到本地模型了。这个兼容设计的价值非常大，它让迁移成本降到了最低。

pip install vllm python -m vllm.entrypoints.openai.api_server \ --model 你的本地模型路径 \ --port 8000 \ --gpu-memory-utilization 0.9

启动成功后，原来的 Python 调用代码里把 base_url 改成http://localhost:8000/v1，模型名改成你本地模型的名字，其他都不用动。

本地模型和 API 模型在参数调优上有一些差异。本地的小模型能力弱一些，对提示词更敏感，同一个 prompt 在 API 上效果不错，换到本地可能就答非所问。这时候你需要针对本地模型重新打磨提示词，同时把 temperature 调低一点，因为小模型本身随机性就大，温度再高就完全放飞了。

6. 常见问题排查与性能优化：那些年我踩过的坑

6.1 高频报错排查速查表

用 Python 调大模型，遇到报错是家常便饭。我把最常遇到的问题整理成一张表，按现象、原因、解决三步走，方便直接查阅。

这些报错里，429 是我遇到最多的。大部分模型服务商都有 RPM（每分钟请求数）和 TPM（每分钟 token 数）的限制，你用免费额度或者基础套餐时特别容易触发。应对办法除了重试，更有效的做法是控制并发。用一个信号量限制并发数，比触发了限流再做退避要省心得多。

6.2 流式输出的性能优化：分块处理

流式输出虽然解决了等待问题，但如果你的下游业务需要完整结果才能继续处理，流式的意义就打了折扣。这种情况我一般把完整输出缓存到内存或临时文件里，同时把末尾的部分内容边收边解析，实现“边生成边处理”的效果。

比如做文本翻译，模型一次翻译五段文本，你可以约定用换行符分隔，流式收到一个完整段落后立刻送去后续的处理流程，而不是等全文生成完才动手。这段场景里，对模型的输出块做局部分段解析即可。

还有一个容易被忽略的调优点：提示词本身。同一个任务，提示词写得清晰明确，模型的 token 消耗会显著降低，响应速度也更快。这不是玄学，是因为模型不需要“猜测”你的意图，注意力集中在关键信息上，乱发挥的概率小了，无效输出自然就少了。

我举个直观例子。早期做文章分类时，我用的提示词是“请对下面这篇文章进行分类”，模型经常给出文章摘要或者主观评论。后来改成“请判断下面这篇文章属于【科技】【财经】【娱乐】【体育】【其他】五类中的哪一类，只输出分类名称，不要输出其他内容”，效果立刻变好，返回结果既短又准确。

6.3 并发控制与 Token 预算管理

生产环境的并发控制不能靠“差不多”。你要精确知道自己的调用频率和 token 消耗速率。做法也不复杂：给每个请求记录开始时间、结束时间、input_tokens、output_tokens，然后积累到日志系统里。

我分享一个简单的并发控制模型。假设你的平台限制是 RPM=60，即每分钟最多 60 个请求。那么你的客户端平均请求间隔就是 1 秒，但这只是平均，突发情况下你仍可能被限流。更安全的方式是使用令牌桶算法，每个请求前先去桶里拿一个令牌，拿到就执行，拿不到就等待。

用 Python 的threading.Semaphore可以做一个非常简单的并发限制：

import threading import time from concurrent.futures import ThreadPoolExecutor class RateLimiter: """一个简单的令牌桶限流器。""" def __init__(self, rate: float, capacity: int): self.capacity = capacity self.tokens = capacity self.rate = rate self.lock = threading.Lock() self.last_refill = time.time() def acquire(self): while True: with self.lock: now = time.time() elapsed = now - self.last_refill self.tokens = min(self.capacity, self.tokens + elapsed * self.rate) self.last_refill = now if self.tokens >= 1: self.tokens -= 1 return time.sleep(0.1) # 假设每分钟允许60个请求，突发容量10 limiter = RateLimiter(rate=60/60, capacity=10) def call_with_rate_limit(client, messages): limiter.acquire() return client.chat(messages=messages) # 使用线程池并发执行，但每个请求前都过限流器 with ThreadPoolExecutor(max_workers=5) as executor: futures = [executor.submit(call_with_rate_limit, client, [{"role": "user", "content": f"第{i}个问题"}]) for i in range(10)] results = [f.result() for f in futures]

这个限流器的核心思路是让令牌桶以恒定的速率“补货”，突发请求消耗桶里的存量令牌，存量耗尽后，只能等待每次补货。它比单纯休眠固定秒数要灵活得多，既能承载突发流量，又能守住平均速率。

Token 预算管理则是从钱和性能两个维度卡控：每轮对话的 token 消耗、每个任务的 token 消耗、每天的总消耗。控制好这三级预算，生产环境才不至于失控。我一般在调用前估算输入 token，生成后记录实际消耗，定期跑报表，看看是哪些场景在烧钱，再针对性优化。

7. 调用大模型的工程化体会

前前后后做了好几个大模型落地的项目之后，我最大的感受是：调用大模型的代码本身不难，难的是把它当作一个不稳定的外部依赖来设计系统。它不像本地数据库那样可靠，它有网络延迟、有超时、会限流、会抽风，而且每次调用都在烧钱。

所以我的经验是，围绕每一次调用，都必须建立好四件事：超时、重试、监控、降级。超时保证系统不会被卡死；重试保证偶发失败能自动恢复；监控保证你能及时发现异常趋势；降级保证大模型挂了业务还能有兜底方案。这四个支柱立住了，大模型调用才算真正接进生产环境，而不只是写个脚本自己玩。

如果你刚起步，我建议不要一上来就追求复杂的封装和高性能架构。先把最朴素的调用跑通，感受一下返回速度和 token 消耗，再逐步加流式、加缓存、加并发控制。每一步都理解为什么需要它，而不是像我早期那样，把别人项目里的重试和限流代码复制过来，看半天也不知道保护的是什么。

最后再分享一个我在实际项目中反复使用的小技巧：每次调模型前，先把输入输出连同参数一起打一条结构化日志，存起来。出了问题，你不是靠回忆排查，而是直接翻日志看当时发了什么、模型回了什么、耗时多少、花了多少 token。就凭这个习惯，我在排查和优化上省下的时间，足以支撑我把这个技巧推荐给每一个做大模型集成的开发者。