企业官网建设流程全解析

我最近被问得最多的问题，不是“哪个模型最强”，而是“LLM到底该怎么用”。问的人有产品经理、后端开发、测试工程师，甚至连做数据分析的同事都来凑热闹。大家普遍卡在同一个地方：知道LLM很火，也照着示例调过几次API，但一遇到真实业务场景就不知道从哪下手。

这篇文章把这一年多折腾LLM的经验按一条线整理出来——从Token、Prompt、参数这些地基，到RAG、GraphRAG、LLM Wiki、LLM as Judge这些进阶玩法，再到ONNX部署和报错排查，全是我自己验证过、踩过坑之后留下的东西。不写空概念，只写能直接拿去用的方法和思路。不管你是第一次接触大模型，还是已经接了好几个API但总被输出质量折磨，都应该能从这里找到对应的答案。

1. 先把思维转过来：LLM不是搜索引擎，是“概率接龙机”

1.1 LLM到底是什么

LLM的全称是Large Language Model，大语言模型。很多人把它理解成“更聪明的搜索引擎”，这是第一个需要纠正的认知。

搜索引擎的逻辑是：根据你输入的关键词，从一个已有的索引库里找出匹配的网页，返回给你。它不产生新内容，它负责“找”。

LLM的逻辑完全不同：它把所有训练语料压缩成神经网络里的参数，你输入一串文本，它根据训练时学到的统计规律，逐个预测“下一个最有可能的Token是什么”，然后接龙一样地生成后续内容。它不负责“找”，它负责“造”——对，是“造”。今天我们说的“大模型llm”，本质上就是一个用海量文本喂出来的概率模型，底层架构是Transformer。

所以很多人第一次用LLM会有一个感觉：它什么都能聊，但聊着聊着就开始胡说。这不是Bug，这是概率模型的宿命。它并不知道“正确答案”，它只知道“这个位置最像样的说法是什么”。

那LLM是否属于深度学习？严格来说，是的。LLM是深度学习技术在自然语言处理领域的一个分支，Transformer、注意力机制、反向传播这些底子都在。但对使用者来说，你不需要会训练模型，也不需要理解梯度下降——你需要理解的是它的输入输出行为，把它当成一个“跟随指令的文本生成器”。

1.2 三种用法层次，先说清楚再动手

我接触过的团队，用LLM基本分成三个层次。搞明白自己在哪一层，比急着调代码重要。

第一个层次叫“Prompt直接调用”。完全不写复杂的代码，打开API文档调对话补全接口，靠提示词（Prompt）控制输出。适合验证想法、做内容辅助、写一些小工具。这个层次的门槛最低，但天花板也低：没有记忆、没有检索、复杂任务做不了。

第二个层次叫“API加逻辑编排”。这是大多数工程团队的起点。这时候你已经不是“发一句话就完事”，而是把LLM嵌进业务流程里，比如先让LLM把用户问题做意图识别，再决定调用哪个子模块；或者让LLM抽取出结构化信息，喂给下游系统。这个层次开始引入框架（langchain、llamaindex这类“llm框架”）、引入网关、引入RAG。

第三个层次叫“模型本地化部署与定制”。把开源模型部署在自己的服务器上，或者用ONNX等格式做推理优化，甚至做微调。这个层次解决的是数据隐私、成本、延迟的问题，但运维门槛一下子高很多。

我把话说透一点：90%的业务需求不需要第三层，大部分团队最高性价比的路径是“第一层做验证，第二层做交付”。第三方云模型已经足够强，私有化部署只有在数据出不去、或者调用量大到成本失控的时候才值得。

1.3 什么场景适合LLM，什么场景千万别用

我见过最典型的失败案例，是有人让LLM去做精确计算，结果模型把12345乘以67890算错了，然后项目被领导一票否决。这其实不是LLM的问题，是场景选错了。

适合LLM的场景有三类特征：一是任务需要“理解语义”，比如总结、改写、分类、抽取、问答；二是任务没有唯一标准答案，比如写一段推广文案、生成一段代码注释；三是任务可以把判断标准描述清楚，让模型当“助理”而不是“执行者”。

不适合LLM的场景也有三个特征：一是要求100%精确，比如账务计算、ID匹配、版本比对；二是高频低延迟请求，单次推理动辄几百毫秒，并发一上来成本直接爆炸；三是数据必须留在本地的敏感场景，除非你自己部署。

记住一个简单的判断公式：这个任务如果“人看两眼就能做，但是量大做不过来”，那LLM大概率适合；如果“人做都可能出错，需要复核确认”，那LLM大概率要配合规则系统使用。

2. 理解Token和“三个点”：用LLM前必须想清楚的三件事

2.1 Token到底是什么

Token是LLM世界里的最小文本单位，可以粗略理解成“模型读文本时切出来的碎片”。英文里一个单词通常一个Token，中文里一个汉字大概对应1到1.5个Token（不同模型分词器有差异）。

这个单位太重要了，因为LLM的计费、上下文窗口限制、性能优化，全部围绕Token展开。你在API调用后的返回结果里会看到usage字段，里面写着prompt_tokens、completion_tokens、total_tokens，就是这次调用花了多少Token。

上下文窗口也是按Token算的。一个模型的上下文窗口如果是128K，意味着“输入Prompt的Token数 + 输出内容的Token数”加起来不能超过这个值。很多人第一次报错“context length exceeded”，就是忘了把输入输出算在一起。

你可能会问：Token跟我写Prompt有什么关系？关系太大了。我见过有人把一个8000字的PDF全文塞进Prompt，然后再问一个简单问题，结果模型说“上下文超限”。实际上他需要的是先把PDF的关键段落抽出来，只把相关的几百字塞进去。Token不是无限便宜的，每次调用都背着你花钱。

2.2 中文场景的Token估算和成本计算

做项目预算的时候，必须会估算Token。我们以常见的中文场景做一个粗糙估算：1个汉字约等于1.5个Token，附带标点和格式符号，取2.0更稳妥。也就是1000个汉字大约对应1500到2000个Token。

算账公式很简单：单次调用成本 =（输入Token × 输入单价 + 输出Token × 输出单价）。比如某个商用模型价格是输入0.01元/千Token、输出0.03元/千Token，一次典型的客服问答如果输入2000 Token、输出300 Token，单次成本大概就是0.02加0.009，约3分钱。听着不贵，但如果一天有10万次调用，那就是三千块。

我提供一个实用经验：在做成本评估时，把“输出Token总数”乘以2到3的安全系数。因为LLM在生成长文、带格式内容时，实际输出往往比预估多，而且重试和冗余调用也会吃钱。预算上宁可松一点，别到月底被账单吓一跳。

2.3 Key、Query、Value：写Prompt之前的三要素

网上有个说法我很认同，就是把Token相关的三个概念类比成：Key是“我是谁”、Query是“我在找什么”、Value是“我能提供什么”。这个三个点其实是注意力机制里的概念，但放到Prompt设计上反而成了一个极好用的框架。

我们在设计任何一个Prompt之前，先回答三个问题：

第一，Key（我是谁）。这个Prompt要模型扮演什么角色？是“资深编辑”“Python专家”还是“财务分析师”？角色定义了模型的说话口吻和知识侧重。实测下来，给模型一个清晰的角色设定，输出质量比“你是一个AI助手”高出不少。

第二，Query（我在找什么）。你要模型具体干什么，目标必须明确。不是“分析这段文本”，而是“从这段文本中抽取所有公司名称，并按出现次数降序输出列表”。Query越具体，模型越不容易跑偏。

第三，Value（我能提供什么）。你给模型什么素材和背景？是业务规则、参考文档，还是禁止事项？模型的输出上限，取决于你喂给它的信息质量。你只给一句话，它就凭空编；你给它一份完整的背景说明，它就很难乱来。

我在实际项目里，把所有Prompt模板都改成了“角色设定 + 任务目标 + 背景材料 + 输出格式”四段式。看起来多写了几行字，但模型的可用率从六成左右提到九成以上。这三个点，是写Prompt的第一步，也是最重要的一步。

3. 从第一个API到工程化：参数、结构化输出与LLM网关

3.1 一个标准的对话补全请求

先看最基础的调用。现在的云厂商API基本都是OpenAI兼容格式，结构是“是一个消息列表”，每条消息有role和content。role有system（系统设定，告诉模型它是什么角色）、user（用户输入）、assistant（模型的历史回复，多轮对话时要用）。

from openai import OpenAI client = OpenAI( api_key="your-key", base_url="https://your-endpoint/v1" ) resp = client.chat.completions.create( model="your-model-name", messages=[ {"role": "system", "content": "你是一个严谨的技术文档编辑。"}, {"role": "user", "content": "请把下面这段话改写成适合发布的形式：……"} ], temperature=0.3 ) print(resp.choices[0].message.content)

这个例子看起来简单，但有几个细节容易被坑。第一，system消息别留空，给模型一个稳定的行为底座。第二，多轮对话时，必须把之前的assistant消息一起传回去，否则模型没有记忆。第三，temperature这个参数，很多人不理解，直接默认，导致输出忽高忽低。

3.2 关键参数：温度、Top-P和最长输出

temperature控制随机性，取值0到2。我个人的经验法则：做抽取、分类、翻译这类“确定性任务”，temperature设0到0.3；做文案创作、头脑风暴这类“多样性任务”，设0.7到1.0。超过1.2基本就开始乱写，没什么项目用得上。

top_p是另一个随机性控制参数，表示只从累计概率前p的Token里采样。很多新人不明白temperature和top_p的关系。打个比方：temperature是“敢不敢冒险”，top_p是“限定只能在哪个小圈子里挑”。官方建议是：一次只调其中一个，别两个一起乱调。我一般只动temperature，top_p保持默认。

max_tokens（有的新版本叫max_completion_tokens）控制单次输出上限。这个参数也经常出错：有人设了很小的值，长文本输出到一半硬生生截断；有人设得太大，模型明明已经生成完事，却把剩余额度反复输出空行。一个好的实践是：先设一个中等值（比如城市级问答设1024），实测观察正常输出长度，再往下收紧。

另外，还有一类参数需要注意，比如top_k、frequency_penalty这类，不同厂商支持情况不一样。你发给OpenAI的参数，发给别的兼容接口不一定认，这就是后面网关要解决的问题。

3.3 结构化输出和工具调用

LLM返回的是自然文本，但业务系统要的是JSON、实体列表、可执行调用。于是有了两条路：一是用提示词让模型“输出JSON格式”，二是在API层开启JSON模式，三是用function calling（工具调用）。

我强烈建议：凡是做系统集成，直接走功能调用或JSON模式，别靠提示词“请用JSON格式输出”。因为提示词软约束很容易失效，模型会突然来一句“以下是您需要的JSON：”或者把JSON放进代码块里，解析直接崩。API原生支持的结构化输出，能强制模型返回完全合法的JSON，省掉这一堆麻烦。

function calling的设计思路是：你给模型声明一组函数（名字、参数描述、参数schema），模型根据用户问题判断“该调用哪个函数”，并返回参数内容，但真正执行函数的是你的代码，执行完再把结果回传给模型，让模型基于结果生成最终回复。

要声明工具，需要传tools参数，里面是一个个JSON Schema。这个过程的常见报错就是文章开头提到的“provider rejected the request schema or tool payload”，后面我专门写一节排查过程。

3.4 LLM网关：多模型接入的必经之路

当一个项目真正跑起来，你会发现自己不可能只绑一家模型。今天这个模型中文好，明天那个模型便宜，后天还要在多个地区用不同供应商。如果每个业务模块都直接对接各自的SDK，密钥散落、调用审计缺失、模型切换要改代码，这日子没法过。

所以工程上需要一个“llm网关”，也就是所有LLM调用的统一入口。我参与过的项目里，网关至少承担四件事：一是统一协议，把各家API差异屏蔽掉，业务方只对接一个标准接口；二是密钥管理，密钥只存在网关，业务方通过网关鉴权；三是路由与负载均衡，主模型挂了自动降级到备选模型；四是配额与审计，每个部门、每个应用用了多少Token一目了然。

市面上有开源的方案，比如LiteLLM这类中间件，也可以自己基于OpenAI兼容协议包一层。我的建议是：三五个人的小项目没必要上网关，先直连API；但一旦超过三个应用在调模型，立刻补上网关，否则后面治理成本远超你想象的数。

4. 告别幻觉：RAG、GraphRAG和LLM Wiki的落地细节

4.1 为什么RAG是LLM落地的最短路径

所有人都会遇到一个问题：模型虽然强，但不知道你公司的业务细节，也不知道最新的数据。你要么把知识全部塞进模型参数里（微调，贵且不灵活），要么在每次提问时把相关知识临时找出来拼进Prompt里，让模型先看资料再回答。后者就是RAG（Retrieval-Augmented Generation，检索增强生成）。

RAG的价值在“幻觉治理”上体现得尤其明显。模型默认是“根据训练数据里的统计规律猜”，而RAG是“先给你一段确定的参考资料，你再基于这个资料回答”。当资料里明确写着“本产品保修期为一年”，模型就很难再说成“三年”。这不是模型变得更聪明了，而是它有了可以依赖的上下文。

我在给团队讲RAG时用的类比是：模型像一个新来的实习生，不懂业务很正常。RAG等于你在每次布置任务前，先递给他一份和任务相关的文档。你给的文档越准，他的活儿越好；你不给文档，他就只能瞎编。

4.2 文档切分、向量化与召回

RAG的核心流程五步：加载文档、切分成块、向量化、存入向量库、查询时召回。

第一步加载文档，PDF、Word、网页、数据库各种来源都有对应解析器，不必多讲。第二步切分是个技术活：把文档切得太碎，单个块没有完整语义；切得太大，向量检索的精度会下降，而且塞进Prompt时占用大量Token。我的经验值：通用知识文档按400到800字符切块，块之间留50到100字符的重叠，避免一句话被从中间截断。

第三步向量化，用embedding模型把文本块变成高维向量。这一步要选对模型，中文场景优先选中文语料训练过的模型，比如bge系列。向量维度不必追求极致，一般1024或768足够。

第四步存入向量数据库，像FAISS、Milvus、Qdrant、Chroma都是常用选择。到了这一步，很多项目就卡住了，因为只做了“相似度检索”。第五步才是关键：把“用户的问题向量化，召回Top-K最相似的文段，和原始问题一起组装进Prompt”。这里有个容易被忽略的调节项：召回Top-K不宜过大。有些人设K=20，把两万字塞进去，模型反而被大量无关内容干扰，回答质量直线下降。我一般K取4到6，召回的必须是“强相关”的段落，不够再考虑混合检索、重排序模型。

4.3 GraphRAG和本体：让模型理解实体关系

纯向量检索有一个明显的天花板：它按语义相似度找文本，但找不到“跨段落的多跳推理”。比如用户问“A公司的供应商中，哪些出现过质量问题？”，答案可能散落在三个文档里，向量召回里单看哪一段都不匹配。这就是GraphRAG出现的理由。

GraphRAG的思路是：先用LLM从文档里自动抽取实体（公司、人名、产品、时间）和关系（投资、合作、导致），构建成一个知识图谱，然后基于图谱做社区发现和聚合，最后在回答时结合图谱子图和原始文本。相当于在“文本检索仓库”之外，又搭了一层“关系地图”。

再往上就是本体（ontology）。你可以把本体理解成“对领域概念和关系的正式定义”——设备是什么、故障是什么、设备与故障之间是什么关系。没有本体，LLM抽取实体时会把“苹果”当成水果还是公司傻傻分不清；有了本体约束，抽取结果才稳定。这也是为什么“llm ontology”会成为一个热门词：领域化的LLM应用要想可落地，本体约束几乎是必经之路。

4.4 LLM Wiki和知识库的关系

“LLM Wiki”听起来像是大模型的百科，实际上它更接近一种“结合了知识库管理、图谱和问答入口的实践”。我在项目里就是这么干的：把团队维基、产品文档、FAQ聚合到一个统一知识库，文档经过切分和向量化形成检索层，再抽取关系形成图谱层，上层通过RAG接口对外提供问答。

这样做的收益是“一处更新，处处生效”。传统微调模型，知识更新一次得重新训练一轮；而LLM Wiki这种形态，只需要更新源文档，重新切分更新向量库即可，周期从几周缩到几分钟。

不过也要提醒一句：LLM Wiki建得再好，也只是检索的辅助层，底层仍然需要模型有不错的零样本能力。知识库质量决定了回答质量的上限，而模型本身决定了下限。先把你自己的知识库整理干净，再去选工具，顺序别搞反。

5. 质量怎么保证：LLM as Judge

5.1 为什么不能只用“肉眼评估”

LLM输出是概率性的，同一个Prompt跑十次，可能有八次很好、两次很烂。如果你靠人肉一条条看，有两个致命问题：一是标准不统一，不同人觉得“好”的定义不一样；二是效率太低，一天几千条生成结果，根本看不过来。

所以想要把LLM用进生产环境，“评估”必须成为工程的一等公民。这时就轮到LLM as Judge了，翻译过来就是“让大模型当裁判”，用另一个LLM去评价目标LLM的输出质量。

5.2 LLM as Judge的搭建方法

搭建一个可靠的自动评估器，核心不在模型选择，而在“评估标准设计”。我踩过一个大坑：一开始只让裁判模型“给这个回答打分，1到10分”，结果分数普遍虚高且不稳定。后来改成结构化评估，效果立刻不一样。

我的做法是把评估拆成一个标准Prompt，裁判模型按固定维度打分，每个维度给明确的评分锚点：

你是一个严格的质量评审。请对下面的回答按三个维度打分（1-5分）：准确性：是否与参考材料冲突或存在事实错误；完整性：是否遗漏用户问题中的关键点；清晰性：是否存在表述混乱或逻辑断裂。给出每个维度的分数和一句理由。

这个Prompt跑起来后，我再抽了100条样本让两个人工评审也打一遍分。结果显示裁判模型的评分和人工评审的相关系数能达到可接受范围，而且能自动跑全量批次。

还要注意三个偏差：位置偏差（把好的回答放在前面它就觉得前面好），自我偏好（它更偏爱跟自己风格一致的输出），长度偏差（长回答容易得分偏高）。应对方法是：交替排序两两对比、评估模型尽量不用被评测的同一款模型、在评分标准里明文约束“禁止因长度评分，只评估内容本身”。

5.3 公开榜单Open LLM Leaderboard怎么看

很多人在选模型时疯狂刷Open LLM Leaderboard之类的公开榜单，以为分数高就是王道。这个做法我劝你修正一下。

公开榜单评测的大多是通用能力基准，比如推理、知识问答、代码生成。这些分数只能回答“这个模型在通用任务上强不强”，回答不了“这个模型在你特定业务上好不好用”。我在实际项目里见过一个榜单排名很高的模型，处理特定领域的古文翻译一塌糊涂；反而一个总榜没那么出挑的模型，在本领域表现极其稳定。

我的用法是：榜单用来初筛，筛出三五个候选；然后用你自己业务的真实样本，做成固定测试集，配合前面说的LLM as Judge做批量对比；最后还要看一个榜单上看不到的指标——成本和延迟。综合下来再定主模型。

5.4 基于LLM的单元测试：把评估自动化

把LLM as Judge和测试思维结合起来，可以做成“基于LLM的单元测试”。我去年带着团队在一个内容审核项目里建立了一套自动化回归集：把典型的用户输入（包含正常请求、边界输入、攻击性输入）固化成测试用例，每次模型或Prompt模板有变更，就自动跑一遍测试集，用裁判模型判断输出是否合规。

这一步的投资回报率极高。没有这套机制之前，改一次Prompt就像拆炸弹，不知道哪个历史用例会翻车。有了自动化评估之后，Pormpt迭代可以大胆地做，因为每改一次都有回归数据兜底。你甚至可以把它接进CI流水线，每次提交代码自动触发LLM评估任务，把结果回写到测试报告里。

6. 部署选型：云API、私有化和ONNX这条路

6.1 什么时候必须私有化部署

我判断“要不要私有化部署”主要看三个条件，满足任何一个都值得认真考虑：第一，数据出不去，业务数据涉及敏感信息或合规要求，不能发给外部API；第二，量非常大，按Token计费的成本已经高于自购GPU固定资产摊销；第三，可用性要求高，外部API的波动和限流影响核心业务。

但私有化部署不是万能药。GPU采购、运维、模型迭代、推理优化，每一项都是投入。我见过一个团队为了“自主可控”硬上私有化，结果模型选小了，业务效果远不如云上大模型，最后骑虎难下。务实的选择是：先用云API把业务验证通过，再在有余力时用开源模型做降级兜底。

6.2 ONNX部署LLM的基本流程

ONNX（Open Neural Network Exchange）是一个开放的模型交换格式，它的吸引力在于统一格式加推理优化。把模型转成ONNX后，可以用ONNX Runtime加速推理，也方便在不同硬件上迁移。

ONNX部署LLM的基本流程是：从Hugging Face拉原始模型，用optimum-cli把模型转为ONNX格式，然后基于ONNX Runtime或ONNX Runtime GenAI加载推理。代码骨架大致是这样：

import onnxruntime_genai as og model = og.Model("path/to/onnx_model") tokenizer = og.Tokenizer(model) prompt = "用一句话解释什么是RAG" input_ids = tokenizer.encode(prompt) params = og.GeneratorParams(model) params.input_ids = input_ids params.set_search_options(max_length=512, temperature=0.2) generator = og.Generator(model, params) while not generator.is_done(): generator.compute_logits() generator.generate_next_token() text = tokenizer.decode(generator.get_sequence(0)) print(text)

这段代码看起来简单，但真正跑起来你会遇到一堆前置问题：模型不是所有结构都能直接转ONNX，需要看架构支持情况；转换时需要指定推理精度；加载会话时的provider（CPU、CUDA、TensorRT）选择也会影响性能。我的建议是：先找一个官方已经转好的ONNX模型跑通全流程，再尝试自己转换，减少挫败感。

6.3 量化与推理性能调优

模型部署的性能瓶颈主要在显存和推理速度。常规做法是量化——把权重从FP16压到INT8甚至INT4，模型体积和显存占用可以压缩到原来的四分之一到八分之一，代价是精度轻微下降。

在中文问答这类生成任务里，INT8量化的质量损失通常可接受，INT4则要实测评估。有一个容易被忽略的事实：模型参数量只是第一层，KV Cache也会占大量显存，上下文越长越明显。跑7B模型，如果不注意限制上下文长度和并发，几路请求就能把一张24G显卡打满。

真部署调优时，我建议按这个顺序检查：第一，确认量化精度和任务匹配；第二，确认provider用的GPU执行引擎（Windows上注意DirectML和CUDA的选择）；第三，限制单请求最大Token数和并发数；第四，用预热避开首次推理冷启动。这些全部调完，再谈其他的花活。

7. 报错排查实录：从schema rejected到成本失控

7.1 provider rejected the request schema or tool payload

先聊这个最让开发者头疼的报错：“llm request failed: provider rejected the request schema or tool payload.”。表面意思是“提供商拒绝了你的schema或工具载荷”，但真实原因往往有四五种可能，我一个个说。

最常见的原因是tools参数里的JSON Schema不合法。比如少写了function的description，或者properties写成了数组而不是对象，或者required字段里的名字在properties里根本不存在。我建议每次报这个错，第一步不是看API文档，而是把你传的tools参数单独转成JSON，放到JSON Schema校验工具里过一遍。

第二个原因是模型不支持某些参数。同一个工具定义，A厂商可能接受，B厂商可能严格拒绝。尤其是一些字段如“strict”、“additionalProperties: false”并非所有兼容接口都支持。解决办法是先简化工具定义，把带的参数一个一个去掉，做二分排查。

第三个原因是工具名或参数名超长、包含非法字符。有些平台对函数名有正则限制，比如只能包含字母数字下划线和连字符，你起了个中文名或者含空格的名字，直接会被拒。

第四个原因是参数值类型不匹配。模型按你的schema填参数，但填进去的值可能是null、空字符串，或者数字传成了字符串。如果是JSON模式严格校验，这类也会报“rejected”。

我的排查顺序是：校验schema合法性 → 确认模型支持的工具调用规格 → 逐一精简参数 → 打印出实际请求payload检查值类型。按这个顺序，基本能在十五分钟内定位。

7.2 其他四个高频问题

除了上面那个报错，我另外整理了一份高频问题速查表，都是项目里真实撞见过的：

其中一个容易被忽视的“历史消息裁剪”，做多轮对话的团队一定要重视。很多项目把全部对话历史原封不动传给模型，聊到二十轮时Prompt可能已经有上万Token，既贵又慢。我的做法是：只保留最近几轮完整对话，更早的用LLM生成的“对话摘要”代替，能在质量问题不大幅劣化的前提下，把Token消耗降一半以上。

7.3 成本失控的三道防线

最后聊成本，这是每个把LLM上线的人都会迎头撞上的墙。我总结了三道防线：

第一道防线是“入口限流”。在网关层给每个应用设每日Token配额和并发上限，配额用尽直接返回提示，不要再往里灌请求。没有这道防线，一次线上异常可能导致调用量暴增，月底账单直接翻几倍。

第二道防线是“Token预算审计”。每个请求的Prompt里装了哪些内容，是否符合预期，定期抽查。我见过案例：某个模块不小心把整份知识库文档每次都塞进Prompt，单次调用成本是预期的几十倍，但业务方完全没察觉。没有审计，它就会悄悄漏钱。

第三道防线是“响应缓存”。相同或高度相似的问题，把上次的回答缓存命中。客服问答场景里，重复问题占比往往很高，缓存能直接省掉一大批重复调用的费用。缓存命中率做到10%到20%，都是赚的。

我建议每个LLM项目上线第一天就把这三道防线搭好，别等出问题再补。成本失控跟线上事故一样，处理起来都是手忙脚乱的。

最后分享一个习惯：我每接一个新项目，都会先准备一个包含20条固定测试样本的评估集，把“用LLM”变成“用LLM并用一套可重复的评估体系去验收它”。这个习惯帮我避开了无数次“感觉效果好”和“实际上线翻车”之间的落差。你如果只能从这篇文章带走一个建议，我希望是这一条——LLM是个好工具，但把它用好的，从来不是运气，而是你有没有一套能持续度量、持续修正的方法。