企业官网建设流程全解析

1. 从“会调”到“懂原理”的分水岭到底在哪

调 API 这件事，门槛已经低到不能再低了。一个刚学编程不到三个月的人，照着文档复制一段请求代码，把密钥填进去，改改提示词，就能让大模型吐出看起来像模像样的回答。我见过不少团队，招人时问“会不会用大模型”，对方说会，结果一上手，遇到超时、限流、输出格式不稳定、上下文超长被截断，整个人就卡住了，完全不知道从哪下手排查。

这就是标题里说的那个现象：会调 API 的人很多，懂原理的人极少。我自己带过几个项目，也跟不少同行聊过，发现一个很普遍的规律——大部分人把大模型当成一个“黑盒接口”在用，输入一段文字，输出一段文字，中间发生了什么完全不清楚。平时跑跑 demo 没问题，一旦要上生产、要控成本、要保证稳定性，问题就全暴露出来了。

这篇手记想做的事情很明确：把大模型 API 调用背后那些“看不见的机制”拆开讲清楚。不是讲论文里的数学推导，而是讲一个工程从业者在实际项目里必须理解的原理——为什么会有 token 这个概念、上下文窗口到底怎么算、温度参数改了之后模型内部发生了什么、流式输出和一次性输出在工程上有什么本质区别、限流和重试该怎么设计才合理。这些内容，文档里往往一笔带过，但恰恰是区分“会调”和“懂原理”的关键。

适合谁来读？如果你已经能跑通大模型 API 的基本调用，但总觉得心里没底，遇到问题只能靠猜和试，那这篇内容就是写给你的。如果你刚开始接触大模型工程，还没真正上手调过，也没关系，我会从最基础的概念讲起，用生活化的类比把原理说透，再落到具体的代码和参数上。读完你至少能做到两件事：第一，知道每次调用背后发生了什么；第二，遇到常见问题时能自己定位原因，而不是盲目改参数。

2. 大模型 API 调用的核心机制拆解

2.1 一次 API 调用到底经历了什么

很多人以为调 API 就是“把问题发给模型，模型想一下，把答案发回来”。这个理解在宏观上没错，但在工程上太粗糙了。真实的过程要复杂得多，我把它拆成几个阶段来讲。

第一阶段是请求组装。你写的提示词、系统指令、历史对话，全都会被拼接成一个完整的文本序列。这个序列不是随便拼的，它遵循模型训练时见过的特定格式。不同厂商的模型，拼接格式不一样，有的用特殊标记分隔角色，有的用固定模板。如果你自己手动拼，很容易拼错，导致模型表现异常。所以工程上一般用官方 SDK 或者封装好的消息结构，让 SDK 去处理拼接。

第二阶段是分词与编码。拼好的文本会被切分成 token，然后转成数字 ID 序列。这一步是很多人忽略的关键环节。模型不认识文字，它只认识数字。分词器决定了“一段文字对应多少个 token”，而 token 数量直接决定了你的成本和能不能塞进上下文窗口。

第三阶段是前向计算。数字序列进入模型，经过几十层网络的计算，最终输出下一个 token 的概率分布。注意，模型一次只预测一个 token。你看到的整段回答，是模型反复预测、每次追加一个 token、再重新计算得到的。这就是为什么流式输出能实现——因为模型本来就是一个个 token 往外吐的。

第四阶段是解码与后处理。根据你设置的温度、top_p 等参数，从概率分布里选出一个 token，转成文字，追加到已有序列后面，然后重复第三阶段，直到遇到结束标记或者达到最大长度。

理解了这个流程，很多现象就说得通了。比如为什么同样的提示词，两次回答不一样——因为解码阶段有随机性。为什么长对话越来越慢、越来越贵——因为每次都要把全部历史重新算一遍。为什么有时候模型“答非所问”——可能是分词阶段把关键信息切碎了，也可能是上下文太长导致前面的内容被挤掉了。

2.2 Token：大模型世界的“最小货币单位”

Token 这个概念，我觉得怎么强调都不为过。它既是计费单位，又是容量单位，还是性能单位。不理解 token，就没法真正理解大模型工程的成本结构和限制条件。

先说 token 是什么。你可以把它理解成“模型眼里的字”。对于英文，一个 token 大约对应 0.75 个单词，或者说 4 个字符左右。对于中文，情况复杂一些，一个汉字通常对应 1 到 2 个 token，取决于分词器的设计。我实测过几个主流模型，同样一段中文，不同模型算出来的 token 数能差出百分之二三十。

为什么会有这个差异？因为分词器的词表不一样。有的分词器对中文优化得好，常见词能合并成一个 token；有的分词器中文词表小，一个词被拆成好几个 token。这个差异直接影响你的成本。假设你的应用每天处理一百万次请求，每次平均多出 50 个 token，按某些模型的定价算下来，一个月就是一笔不小的开支。

再说 token 和上下文窗口的关系。上下文窗口指的是模型一次能处理的最大 token 数，包括输入和输出。比如一个 8K 窗口的模型，你的提示词加历史对话加模型回答，总共不能超过 8192 个 token。超了怎么办？要么截断，要么报错。截断的话，你得决定砍掉哪部分——通常是从最老的历史开始砍，但这可能导致模型丢失关键信息。

这里有个工程上很容易踩的坑：很多人只计算了用户当前输入的长度，忘了把系统提示词、历史对话、以及模型即将生成的输出预留空间算进去。结果就是请求发出去了，模型回答到一半被截断，返回一个不完整的答案。我的做法是，在组装请求前先估算总 token 数，给输出预留至少 500 到 1000 个 token 的空间，如果超了就主动压缩历史对话，而不是等模型报错。

提示：不同模型对 token 的计算方式不同，不要用一个模型的 token 数去估算另一个模型。工程上建议直接用对应模型的 tokenizer 做精确计算，或者调用厂商提供的 token 计数接口。

2.3 上下文窗口：模型的“工作记忆”及其工程约束

上下文窗口这个概念，我用一个类比来解释。想象你请了一位顾问来帮你分析问题，但他有个特点：每次只能记住有限的信息。你跟他聊得越多，他越容易忘记前面说过的话。上下文窗口就是这位顾问的“记忆容量”。

这个容量是硬限制，不是软限制。超过就是超过，模型不会“努力记一下”。所以工程上必须主动管理上下文。我见过一些项目，直接把用户的所有历史对话原封不动地塞进去，结果没聊几轮就超了，然后开始报错或者回答质量急剧下降。

管理上下文有几种常见策略。第一种是滑动窗口，只保留最近 N 轮对话，老的直接丢掉。简单粗暴，但可能丢失重要信息。第二种是摘要压缩，把老对话用模型总结成一段简短摘要，替代原文。这个策略效果好，但增加了一次额外的模型调用，有成本和延迟。第三种是关键信息提取，从历史里抽出实体、意图、约束条件等结构化信息，单独维护。这个最复杂，但效果最好，适合对准确性要求高的场景。

我自己的经验是，大部分场景用滑动窗口加摘要压缩的组合就够了。具体做法是：保留最近 5 到 10 轮完整对话，更早的对话每隔几轮做一次摘要，把摘要放在系统提示词里。这样既控制了 token 数，又保留了长期记忆的骨架。

还有一个容易被忽略的点：上下文窗口的“有效容量”往往小于标称容量。什么意思？就是虽然模型声称支持 32K 甚至 128K 的窗口，但在实际使用中，当输入接近上限时，模型对中间部分内容的注意力会下降。业内管这个叫“迷失在中间”现象。所以重要的信息尽量放在提示词的开头或结尾，中间部分放次要内容。

2.4 温度与采样：为什么同一个问题答案不一样

温度这个参数，文档里通常只说“控制随机性，值越大越随机”。但到底怎么个随机法，很多人说不清楚。我试着用工程视角解释一下。

模型在预测下一个 token 时，输出的其实是一个概率分布。比如词表里有五万个 token，每个 token 都有一个概率值，加起来等于一。温度的作用是调整这个分布的“陡峭程度”。温度趋近于零时，分布变得极其陡峭，概率最高的那个 token 几乎必然被选中，输出就变得确定。温度升高时，分布被“压平”，低概率的 token 也有机会被选中，输出就变得多样。

但这里有个细节：温度不是简单地“加噪声”，它是在 softmax 之前对 logits 做除法。logits 是模型输出的原始分数，除以温度后再做 softmax。温度小于 1 时，分数差距被放大，分布更陡；温度大于 1 时，分数差距被缩小，分布更平。理解这一点，你就知道为什么温度不能随便设——设得太高，模型可能选出完全不相关的 token，输出变得胡言乱语；设得太低，输出又过于死板，缺乏灵活性。

除了温度，还有 top_p 和 top_k 两个采样参数。top_k 是只从概率最高的 K 个 token 里选，top_p 是只从累积概率达到 P 的最小 token 集合里选。这两个参数和温度配合使用，可以更精细地控制输出。我的经验是，做事实性问答时温度设 0 到 0.3，做创意写作时设 0.7 到 1.0，做代码生成时设 0.2 左右比较稳。top_p 一般设 0.9 到 0.95，top_k 用默认值就行，不用太纠结。

注意：温度设为 0 并不保证完全确定性的输出。由于浮点运算的精度问题、并行计算的顺序差异，以及不同硬件上的实现细节，即使温度为零，两次调用也可能有微小差异。如果你的业务要求严格可复现，需要在应用层做缓存或去重。

3. 工程实践中的关键参数与调用策略

3.1 超时、重试与退避：别让一次网络抖动毁掉整个请求

大模型 API 调用本质上是网络请求，网络请求就会失败。超时、连接重置、服务端临时不可用，这些都是常态。我见过不少项目，调用代码里连个 try-catch 都没有，一旦网络抖动，整个流程就崩了。

先说超时设置。大模型推理的延迟波动很大，短则几百毫秒，长则几十秒。超时设太短，正常请求也被掐断；设太长，失败请求会拖垮整个系统。我的做法是分两段设置：连接超时设 5 到 10 秒，读取超时根据模型和任务设 30 到 120 秒。对于流式输出，读取超时可以设得更长，因为 token 是陆续返回的，只要还在返回数据就不算超时。

再说重试。不是所有失败都值得重试。网络超时、服务端 5xx 错误，这些可以重试；参数错误、认证失败、配额耗尽，重试也没用，只会浪费时间和配额。重试次数一般设 2 到 3 次，再多就说明服务本身有问题，应该走降级逻辑。

重试的间隔很关键。固定间隔重试容易造成“惊群效应”——大量请求同时失败，同时重试，再次把服务打垮。正确的做法是指数退避加随机抖动。第一次重试等 1 秒，第二次等 2 秒，第三次等 4 秒，每次再加一个随机的小偏移。这样能把重试请求分散开，给服务恢复的时间。

import time import random import requests def call_with_retry(url, payload, headers, max_retries=3): for attempt in range(max_retries + 1): try: resp = requests.post(url, json=payload, headers=headers, timeout=(10, 60)) if resp.status_code == 200: return resp.json() elif resp.status_code >= 500: raise Exception(f"Server error: {resp.status_code}") else: raise Exception(f"Client error: {resp.status_code}, no retry") except Exception as e: if attempt == max_retries: raise wait = (2 ** attempt) + random.uniform(0, 1) time.sleep(wait)

这段代码是我在多个项目里用过的简化版，核心就是指数退避加抖动。实际使用时还要根据具体 SDK 调整，但思路是一样的。

3.2 流式输出：不只是体验优化，更是工程必需

流式输出，就是模型生成一个 token 就返回一个 token，而不是等全部生成完再一次性返回。很多人觉得这只是为了用户体验——让用户看到文字一个个蹦出来，感觉更快。但实际上，流式输出在工程上有更重要的意义。

第一，它降低了首字节延迟。对于长回答，一次性输出可能要等十几秒甚至几十秒，用户早就失去耐心了。流式输出能让用户在几百毫秒内看到第一个字，感知上的等待时间大幅缩短。

第二，它让超时控制更灵活。一次性输出时，如果模型卡住了，你只能等超时。流式输出时，你可以设置“如果超过 N 秒没有新 token 返回就中断”，更精细地控制。

第三，它支持提前终止。有时候模型开始胡言乱语，或者用户已经看到了想要的答案，你可以直接断开连接，节省后续的 token 消耗。

但流式输出也带来新的工程挑战。首先是拼接问题。流式返回的 token 可能把一个词切成两半，你需要正确处理边界。其次是错误处理。流到一半连接断了，你得决定是重试整个请求还是从断点继续。重试整个请求会导致重复输出，从断点继续则需要模型支持，大部分 API 不支持。

我的做法是，对于短回答用一次性输出，简单可靠；对于长回答用流式输出，但在应用层做缓冲，每积累一定长度或遇到标点符号再展示给用户，避免 token 边界问题。同时记录已经输出的内容，如果连接中断，至少能把已生成的部分展示出来，而不是全部丢弃。

3.3 并发控制与限流：别把配额当无限资源

大模型 API 通常有速率限制，按每分钟请求数或每分钟 token 数来算。很多开发者一开始不注意，等到线上流量上来，请求被大量拒绝，才发现问题。

限流策略的核心是“知道自己有多少配额，然后按配额来安排请求”。我一般会在应用层做一个令牌桶或者漏桶，控制请求发出的速率。令牌桶允许一定程度的突发，漏桶则更平滑。对于大模型调用，我倾向于用漏桶，因为服务端通常不喜欢突发流量。

具体实现上，可以用信号量控制并发数，用队列控制排队。比如设置最大并发 10，超出的请求进入队列等待。队列满了就拒绝，返回一个友好的提示，而不是让请求无限堆积。

还有一个容易被忽略的点：不同模型的限流是独立的。如果你同时调用多个模型，需要分别控制。另外，输入 token 和输出 token 可能分别计算限流，要仔细看文档。

提示：限流被触发时，API 通常会返回 429 状态码，并在响应头里带上重试等待时间。一定要读取这个头信息，按它建议的时间等待，而不是自己瞎猜。

3.4 成本控制：从 token 账单反推优化点

大模型调用的成本，最终都体现在 token 账单上。想控制成本，就得从 token 入手。我一般从三个维度来优化。

第一个维度是减少输入 token。系统提示词能精简就精简，不要写一大堆废话。历史对话能摘要就摘要，不要原封不动地塞。少样本示例能少放就少放，放最关键的几个就行。我见过一个项目，系统提示词写了三千多字，里面一大半是重复的说明和客套话，砍掉之后成本直接降了四成。

第二个维度是控制输出 token。在提示词里明确要求模型“简洁回答”“不超过 N 个字”，能有效减少输出长度。设置 max_tokens 参数作为硬限制，防止模型跑偏写一大堆。但要注意，max_tokens 设得太小可能导致回答被截断，需要根据任务类型调整。

第三个维度是选择合适的模型。不是所有任务都需要最贵的模型。简单的分类、抽取、改写任务，用便宜的小模型就够了。复杂的推理、创作任务，再用大模型。我通常会在应用里做一个路由层，根据任务复杂度动态选择模型，成本能降一半以上。

下面这张表是我总结的常见优化手段和预期效果，供参考。

4. 常见问题排查与实战避坑指南

4.1 输出格式不稳定：从“求它”到“约束它”

让模型输出 JSON，结果它给你返回一段带解释的文字，JSON 藏在中间。这个问题几乎每个做结构化输出的人都会遇到。早期我的做法是在提示词里反复强调“只输出 JSON，不要其他内容”，但效果不稳定，模型有时候听有时候不听。

后来我总结了一套组合拳。第一，在提示词里给出明确的格式示例，让模型模仿。第二，使用 API 提供的结构化输出功能，如果厂商支持的话，直接约束输出格式。第三，在应用层做解析容错，用正则表达式从返回文本里提取 JSON 部分，而不是假设整个返回就是 JSON。第四，如果解析失败，把错误信息反馈给模型，让它重新生成。

这套组合拳下来，格式稳定性从大概七成提升到了九成五以上。剩下的百分之几，用重试兜底就够了。

还有一个技巧：把 JSON 的 schema 写进提示词，包括每个字段的类型、是否必填、取值范围。模型看到明确的约束，遵守的概率会高很多。

4.2 模型“胡言乱语”：幻觉的成因与缓解

幻觉这个词听起来很玄，但成因其实很工程化。模型本质上是在做“下一个 token 预测”，它没有事实核查机制。当训练数据里没有相关信息，或者提示词里的信息模糊不清时，模型会倾向于“编一个看起来合理的答案”，而不是说“我不知道”。

缓解幻觉，我从几个方面入手。第一，在提示词里明确允许模型说“不知道”。很多人写提示词时默认模型必须回答，结果模型被逼着编。加上一句“如果信息不足，请直接说明”，能减少很多胡编。

第二，提供参考资料。把相关的文档、数据放在提示词里，让模型基于给定材料回答，而不是靠记忆。这就是常说的检索增强生成思路。实测下来，有参考资料的情况下，事实准确率能提升一大截。

第三，降低温度。温度越低，模型越倾向于选择高概率的 token，也就是更“保守”的回答，幻觉相对少一些。但温度太低会导致回答死板，需要平衡。

第四，做后验证。对于关键信息，用规则或另一个模型做交叉检查。比如模型说了一个日期，你用正则提取出来，跟原始资料比对。不一致就标记出来人工复核。

注意：幻觉不可能完全消除，只能缓解。对于高风险场景，比如医疗、法律、金融，一定要有人工审核环节，不能完全信任模型输出。

4.3 长对话“失忆”：上下文管理的实战技巧

长对话中模型忘记前面说过的内容，这个问题的根源是上下文窗口有限，加上“迷失在中间”效应。我的实战经验是，不要指望模型自己记住，要在工程上主动管理。

具体做法：维护一个结构化的对话状态，包括用户意图、已确认的事实、待解决的问题、约束条件。每轮对话后更新这个状态。组装请求时，把状态摘要放在系统提示词里，把最近几轮原始对话放在后面。这样模型每次都能看到关键信息，不受窗口限制。

另外，对于特别长的文档分析任务，不要一次性塞进去。我的做法是分段处理，每段生成摘要，最后把摘要汇总再让模型分析。虽然多调用了几次，但准确率比一次性塞进去高得多。

还有一个细节：把最重要的信息放在提示词的开头和结尾。开头是系统指令和关键约束，结尾是当前问题和最近对话。中间部分放次要的历史信息。这样即使模型对中间部分注意力下降，关键信息也不容易丢。

4.4 排查速查表：从现象到原因的快速定位

下面这张表是我在实际项目中整理的常见问题速查表，遇到问题时可以按图索骥。

这张表我放在项目文档里，新同事上手时先看这个，能解决八成常见问题。剩下的两成，再具体分析。

4.5 几个我踩过的坑和总结的经验

第一个坑：以为温度为零就是确定性的。前面提过，浮点运算和并行计算会导致微小差异。我早期做测试时，以为温度设零就能复现，结果两次结果不一样，排查了半天才发现是这个原因。后来做需要复现的测试时，我会在应用层做缓存，相同输入直接返回缓存结果。

第二个坑：忽略 token 计数的差异。不同模型、不同版本的分词器算出来的 token 数不一样。我曾经用 A 模型的 token 数去估算 B 模型的成本，结果偏差很大。后来学乖了，每个模型都用对应的 tokenizer 单独算。

第三个坑：重试没有退避。早期写重试逻辑时，失败后立即重试，结果把服务端打得更惨，触发更严格的限流。后来改成指数退避加抖动，问题就解决了。

第四个坑：流式输出没做缓冲。直接把 token 推给前端，结果一个词被切成两半，前端显示得乱七八糟。后来在应用层加了一个小缓冲，遇到标点或积累到一定长度再推送，体验就好多了。

第五个坑：系统提示词写太长。一开始觉得提示词越详细越好，把各种规则、示例、约束全塞进去，结果 token 成本高不说，模型还经常忽略后面的内容。后来精简到只保留最关键的几条，效果反而更好。

这些坑说到底都指向同一个道理：大模型工程不是“调个接口就完事”，它需要你理解背后的机制，然后在工程上做针对性的设计。会调 API 的人很多，但愿意花时间搞懂原理、踩坑总结的人少。希望这篇手记能帮你少走一些弯路。

后续我还会继续写这个系列，下一篇打算聊提示词工程的工程化实践——怎么把提示词当成代码来管理、测试和迭代。如果你在实际项目里遇到过什么奇葩问题，或者有自己的一套排查方法，欢迎交流。