最近不少朋友问我LLM到底怎么用这里的“怎么用”不是去某个聊天网页上问几个问题而是真正把大语言模型Large Language Model接入到自己的工作流、产品甚至业务流程里。同样是“用大模型”让它帮你写一封邮件和让它当一个自主智能体去编排工具、执行任务链难度差了一个数量级。这篇文章我没打算写成面面俱到的教科书而是想把这几年在LLM落地项目里摸出来的方法、踩过的坑、以及那些常规文档里不会交代的经验一次性倒出来。适合谁看对LLM有基本概念至少知道GPT、ChatGPT这些词但开始动手时不知道从哪里下手的开发者也包括想评估“要不要把业务接上LLM”的技术负责人。我会按一条从易到难的主线来讲先搞清楚LLM适合干什么再选接入方式接着聊Prompt工程、用LLM做评估然后讲函数调用和智能体以及可靠性问题最后覆盖本地部署、微调和单元测试这些进阶玩法。每条经验背后我都会解释“为什么”方便你举一反三。1. LLM到底能干什么先厘清能力边界1.1 生成、理解、推理三个基本盘大语言模型的本质是一个用海量文本训练出来的概率模型给它一串文字它预测下一段最合理的输出。但在实际工程里我们不需要关心底层的概率计算只需要把它抽象成三种能力来用。第一是生成能力续写、改写、扩写、翻译、文案生成。这是最直接、最不容易翻车的场景。你给它一段核心信息它能在保留意思的前提下换一种说法或者帮你把零散要点展开成完整段落。第二是理解能力抽取关键信息、做摘要、分类、判断情感倾向。比如给一堆客服会话记录让模型把“客户抱怨点”和“紧急程度”抽取出来。这类任务对结果的确定性要求不高只要抽取规则清楚效果会比较稳定。第三是推理能力多步逻辑推导、代码生成、数学题求解、流程规划。这是LLM上限最高的能力但也最容易出错——因为推理链越长中间某一步算错的概率就越高。现在的多模态和空间LLM还在处理图像、3D环境等更复杂的信息形态本质也还是“理解推理生成”的组合。理解这三个基本盘有个实际用处帮你在立项阶段判断“这个需求到底能不能用LLM做”。如果任务能拆成上述三类能力大概率可行如果任务需要精确计算、实时数据库查询或严格的规则校验那LLM只能当配角必须配合传统代码实现。1.2 别把LLM当数据库使用场景选型我见过最多的翻车案例是把LLM当成数据库或搜索引擎来用。比如问它“2024年第三季度某公司营收是多少”模型一本正经地编了一个数字——这在行业里叫幻觉Hallucination。原因不难理解LLM的知识来自训练数据它没有实时访问外部数据库的能力也无法保证记住每一个具体数字。对于事实性、时效性强的需求应该交给RAG检索增强生成先把答案从数据库或文档库里检索出来再让LLM基于检索结果组织语言。LLM在这里的角色是“表达层”不是“存储层”。我的场景选型建议很简单直接对照这张表看任务类型适合直接用LLM推荐方案摘要、改写、翻译、润色适合直接调API或本地模型信息抽取、分类、情感判断适合结构化输出定义好标签集合代码生成、SQL生成部分适合配上schema约束和少量示例实时事实问答不适合裸用RAG检索 LLM生成精确数值计算不适合让LLM生成代码用计算器执行长期多轮记忆不适合裸用外部记忆库 向量检索如果你一上来就纠结“到底用哪个模型”说明需求还没有拆到底。把任务类型定清楚模型选型反而是后面举手之劳的事。2. 接入LLM的几种主流方式与选型2.1 API调用最快上手的路子对绝大多数团队来说接入LLM最省事的方式就是调用云API。你不用管显卡、驱动、模型部署注册一个账号拿到API Key几分钟就能跑通第一个请求。我这里给一个通用的调用示例它兼容市面上大部分OpenAI风格的接口from openai import OpenAI client OpenAI( api_keyyour_api_key, base_urlhttps://your.provider.example/v1 # 替换为实际服务地址 ) resp client.chat.completions.create( modelyour-model-name, messages[ {role: system, content: 你是一名资深技术编辑回答简洁专业。}, {role: user, content: 用三句话解释什么是RAG。} ], temperature0.3 ) print(resp.choices[0].message.content)这段代码里最值得留意的不是messages结构而是base_url。把接口统一成OpenAI风格后你切换服务商时只需要改base_url和模型名业务代码完全不用动。这个抽象在真实项目里能省下大量重构时间。调用API有几个容易被忽略的细节第一是超时和重试模型推理耗时可能从几百毫秒到几十秒不等必须设置合理的超时建议至少30秒并实现指数退避重试第二是token计费提示词输入和生成内容输出都计费长文本场景要控制上下文长度第三是并发限制服务商通常有每分钟请求数RPM限制你需要做个简单的限流客户端或者在脚本里加延时。2.2 本地部署数据敏感时的选择什么时候需要本地部署三个关键词数据敏感、合规要求、离线环境。比如医疗数据、企业内部文档、金融交易信息很多公司不允许这些内容出网。再比如运维人员在隔离网络里排查问题根本连不上公网服务本地模型就是唯一选择。本地部署主流工具是Ollama和LM Studio二者都支持GGUF格式模型一条命令就能跑起来ollama run qwen2.5:7b实际用起来你会发现本地部署真正的问题不是装环境而是硬件资源。跑7B模型至少需要8GB内存量化后效果尚可14B或32B模型则建议16GB以上内存或一块中高端显卡。速度上的差距尤其明显同一台机器上用API可能1秒出结果本地模型可能要5到10秒甚至更久。所以在非必要场景下别为了“自主可控”而强行本地化成本和体验都要权衡。如果你是新手我的建议是从Ollama开始。它的模型管理、端口服务和兼容OpenAI的接口都很成熟想进一步做二次开发也不难。2.3 框架与工具链用LangChain之前先想清楚提到LLM开发绕不开LangChain、LlamaIndex这类框架。它们确实解决了几个真问题把Prompt组装、记忆管理、工具调用、向量检索这些环节抽象成统一接口让你能用几十行代码搭建一个原型应用。但我在实际项目里越来越克制地使用框架原因是抽象层越厚排查问题越难。框架帮你把代码“串”起来了可一旦响应格式不对、工具调用失败、上下文异常你得翻好几层源码才能定位问题。网上有大把项目代码量不到500行却引入了LangChain全家桶最后维护成本远远超过手写方案。我的习惯是分阶段决策原型阶段可以用框架快速验证业务逻辑进入生产阶段则逐个替换成更轻量的实现。比如工具调用直接用OpenAI的function calling原生接口向量检索直接调用数据库的embedding接口中间层能省则省。记住一个原则能用curl调通的API就不要急着上框架。3. Prompt不是玄学写提示词的实操方法3.1 结构化提示词的基本要素很多新手写的Prompt就一句话“帮我写个周报。”模型确实能写但写出来的东西空泛、跑题、格式五花八门。你以为是模型笨其实是你没把需求讲清楚。一个合格的Prompt至少要包含五要素目标、背景、输入数据、输出格式、约束条件。我常用的模板结构是这样【目标】 基于下面的会议记录生成一份周报中的“本周进展”段落。 【背景】 这份周报需要向部门负责人汇报强调结果而非过程不要出现技术黑话。 【输入数据】 这里粘贴会议记录原文 【输出格式】 - 用不超过200字的中文输出 - 用无序列表列出三个关键进展 - 每行以“已完成”开头 【约束条件】 不要虚构或推测会议中没有提到的信息。为什么结构化有效因为LLM对指令的敏感度远超你的想象。你把“怎么做”写清楚它输出的结构稳定性立刻上一个台阶。尤其是输出格式这一项能直接决定下游程序好不好解析。做应用开发时我通常会让模型输出JSON而不是自然语言段落。3.2 角色、指令与示例三段式对话的威力聊天补全接口里的messages数组看起来只是简单交互实际上藏着大量工程技巧。标准的三段式是system放角色和全局约束user放用户问题assistant放对话历史或者“参考答案”。messages [ {role: system, content: 你是一个严谨的代码审查助手。只指出严重问题忽略风格偏好。}, {role: user, content: 请审查下面这段Python代码的安全风险\n code}, ]角色设定的意义在于给模型一个明确的“立场”。同样一段代码让“资深安全工程师”审查和让“初学者”审查模型给出的关注点完全不同。这是成本近乎为零的行为调整手段。比角色设定更进一步的是少样本示例Few-shot。在很多分类、抽取任务里模型不需要你长篇大论解释什么是“意图”你只要给出三组输入输出对照它就能模仿出你要的格式。比如你要做客服工单分类直接提供几个真实案例作为示例效果往往比写十条规则更可靠。3.3 思维链与温度参数控制模型“怎么想”对于复杂的逻辑推理问题直接问“这道题答案是多少”容易出错但如果你引导模型“一步一步思考再给出答案”正确率会显著提升。这就是思维链Chain-of-Thought的核心思想。实际测试中我发现一个细节思维链不一定要写“请一步一步思考”更自然的做法是要求模型“先列出已知条件再推导最后给结论”并明确指定中间过程输出格式。这样既保留了推理引导又方便你在代码里截取最终答案。温度参数temperature是另一个关键的旋钮。它控制输出的随机性温度趋近0时模型倾向于确定性的答案温度调高时输出更发散、更“有创意”。做事实问答、代码生成、抽取任务我通常设为0或0.2做文案创意、头脑风暴再调到0.7以上。有时候同一个模型换一个温度效果差异比换一个大模型还明显。4. LLM as Judge用大模型评估大模型的工程实践4.1 为什么需要LLM做裁判模型效果好不好靠什么判断传统NLP评测用BLEU、ROUGE这类指标比的是“候选文本和参考文本的字面重合度”但LLM生成的内容往往措辞不同但意思相同字面重合度根本反映不出真实质量。人工评估准确但要花大量人力而且不同标注者标准还不一致。于是“用LLM当裁判”的方法逐渐普及英文叫LLM as Judge。思路很简单构造一个评估Prompt把待评答案和评分标准一起丢给一个强大的模型让它打出分数或者给出排序。优点是扩展性好、成本低一个模型就可以对成千上万条结果打分而且标准可以完全复用。但这个方案有个前提裁判模型的判断力要优于被测模型。通常会让更强或等价的模型来当裁判如果裁判和被评测对象是同一个模型容易出现“看谁都是好学生”的问题。4.2 设计一份靠谱的评判协议我见过不少团队拿着“LLM as Judge”就去跑评测结果打出来的分数毫无区分度。原因往往是评分Prompt写得过于随意。这里是我的一个基础评判模板供你参考你是严格的AI输出质量评估专家。请从相关性、忠实度、有用性三个维度评估下面的模型回答。 【评估标准】 - 相关性(0-5分)回答是否切题是否抓错了重点。 - 忠实度(0-5分)回答是否基于给定材料是否出现幻觉。 - 有用性(0-5分)回答是否解决了用户问题是否提供可操作信息。 【待评估回答】 粘贴模型输出 【格式要求】 以JSON格式输出{relevance: n, faithfulness: n, usefulness: n, reason: 一句话理由} 先输出JSON不要解释。这个协议里有两个容易被忽略的工程点一是给模型一个“拒绝评估”的出口——如果回答完全离题裁判应该打低分而不是强行找合理性二是要求裁判写理由理由能帮你定位模型具体哪些维度有问题方便后面做Prompt迭代。再次强调裁判输出的JSON格式要固定。我们后续会用程序批量解析分数做回归对比如果格式不固定解析成本会让你崩溃。4.3 评分偏见与校准别让裁判有立场LLM as Judge不是银弹它会带偏见。最常见的三类一是位置偏见。你要它从两个回答里选更好的它往往会偏好排在前面的那一个。解决办法是交换顺序跑两遍或者让模型先分别打分再对比。二是冗长偏见。模型倾向于给更长的回答更高分哪怕长回答信息密度很低。解决办法是在评分标准里明确“长度不代表质量冗余信息应扣分”。三是自偏好。模型通常更认可与自己风格相似的输出。如果被测模型和裁判模型是同一个这会显著抬高得分。实践中可以引入多个不同模型作为裁判取平均值或做投票降低单一裁判的立场影响。这其实也是“红队”思想在评估环节的体现——你不仅要测模型“答得好不好”还要测它在对抗性输入下会不会崩。后面讲智能体时我们还会回到这个话题。5. 让LLM干活函数调用与智能体5.1 Function Calling让模型拿到真实世界的数据纯文本对话式LLM有个天然缺陷它无法访问实时数据也无法执行真正的操作。你想要它查天气、查订单、操作数据库只靠嘴说是不行的。**Function Calling函数调用**解决了这个问题。它的工作方式可以用一句话概括让模型决定“该调用哪个工具”但实际的工具执行由你的代码完成。模型并不真正执行函数它只是根据用户问题输出一个结构化的“调用意图”包括函数名、参数等。你的程序拿到这个意图后去真实环境里执行函数再把执行结果返回给模型模型基于结果继续生成回答。下面是一个简化示例演示给模型暴露一个“查询天气”工具的过程tools [ { type: function, function: { name: get_weather, description: 查询指定城市的实时天气, parameters: { type: object, properties: { city: {type: string, description: 城市名如北京} }, required: [city] } } } ] resp client.chat.completions.create( modelyour-model, messages[{role: user, content: 北京今天适合跑步吗?}], toolstools ) # 模型会返回一个tool_call它的name是get_weather参数是{city:北京}你需要注意函数描述description写得越清楚模型选函数越准。参数名和类型也要严格遵循JSON Schema否则模型可能生成无法解析的参数。在后面接智能体时工具定义就是整个系统暴露给模型的“能力面”工具定得多、定得杂模型就越容易选错。5.2 自主智能体的可靠性设计有了Function Calling再配上循环控制逻辑就可以做出“自主智能体”模型自己制定计划、调用多个工具、观察结果、调整下一步动作。但真正把智能体投入生产环境的人会告诉你自主是相对的可靠性才是硬指标。我在项目里见过太多“看起来能跑”的Agent一旦进入真实场景就不断出错调工具顺序反了、拿到中间结果就下结论、多轮循环退化成一问一答。原因在于模型每一步都有概率出错链条越长错误累积得越严重。提高可靠性的工程手段核心思路是给Agent加约束和反馈闭环。我通常这么设计用状态机约束流程不是让模型完全自由发挥而是定义好“收集信息—执行动作—确认结果—输出结论”几个阶段模型只能在这些阶段中切换不能跳到未定义的流程。加入人工确认节点涉及资金、数据删除、对外发布等高风险操作Agent不能直接执行必须生成“待确认指令”由人来批准后才真正落地。设置迭代上限Agent循环超过N次就停止并上报防止死循环烧token。做好Log审计每一步“模型要调什么工具、为什么调、返回了什么”全部留日志出了问题可以复盘定位。“自主容错控制”听起来高大上本质上就是把这些约束和兜底措施都实现好。一个可靠的Agent系统中模型只是决策器真正保障系统稳定的是外部的状态管理、超时控制和审计逻辑。5.3 对Agent做红队测试与报错排查Agent暴露出比你预想更多的工具接口后攻击面也变大了。学术圈提出过AgentPoison这类思路核心是通过污染外部记忆库、知识库或者工具描述诱导智能体在某个环节做出错误决策。这提醒我们Agent的可靠性不只是“能不能完成任务”还包括“在被诱导时会不会做危险动作”。常规的防御手段主要有几个方向一是意图验证在Agent执行敏感操作前单独用一个模型判断“该操作是否符合用户原始意图”二是输出过滤用白名单约束工具参数的取值范围三是行为审计记录并检测异常调用序列比如同一Agent短时间内反复调用删除接口就要触发告警。这些都应该是Agent上生产的必选项而不是后续补丁。另一个常碰到的实际问题就是那句报错LLM request failed: provider rejected the request schema or tool payload.这是请求被服务端拒绝常见原因不外乎以下几种可能原因排查方法tools参数格式不符合OpenAI规范检查工具定义是否是合法的JSON Schema尤其是parameters必须是一个“对象类型”不能直接写字符串工具参数里的字段类型写错比如把required放错层级或者类型用了String而不是string大小写错误消息历史中包含残缺的tool消息检查对话历史中role:tool的消息是不是都对应了完整的tool_call_id服务商不支持tools参数换一个兼容接口或去掉tools再试用于快速定位遇到这个报错我通用的排查顺序是先去掉tools发一次请求。如果通了说明问题在工具定义如果还是失败再把消息历史简化到只剩一条user消息逐步加内容直到复现为止。这种二分法定位比瞎猜快得多也是排查LLM类问题最值的技巧。6. 本地运行LLM从量化到安卓部署6.1 GGUF与量化理解内存和速度的关系在本地部署语境里GGUF是一个你很可能会天天打交道的格式。它是llama.cpp生态提出的模型存储格式把模型权重、分词器、配置信息打包到一起并且支持各种量化等级。为什么要量化因为模型训练和原始推理用的通常是16位浮点FP16一个70亿参数模型在FP16下需要约14GB内存而把每个权重从16位压缩到4位体积就降到4GB左右普通电脑和手机才带得动。常见的量化级别有Q4_K_M、Q5_K_M、Q8_0等。我的个人建议是日常使用优先选Q4_K_M它在显存占用和效果损失之间比较平衡如果内存充足且需要更好效果再上Q5或Q8内存紧张时可以用Q3但会明显感觉到回答质量下降尤其是推理类任务。用Ollama导入一个GGUF模型文件时你可以手动指定量化版本。不过对新手我更推荐直接拉取官方仓库里已经做好的量化模型免去自己量化踩坑。6.2 安卓本地运行GGUF的配置方案手机性能越来越强手机上跑大模型也不再是噱头。目前安卓平台运行GGUF格式的主流方案是PocketPal AI、LLM Farm这类专门支持本地推理的应用。它们的用法大同小异下载GGUF文件到手机应用内指定模型路径和上下文长度然后就能离线对话。但我必须提醒几个实际限制。第一是内存7B模型的Q4量化约4~5GB手机系统本身还要占用2~3GB所以8GB内存的手机跑7B会非常吃力12GB以上才比较从容。第二是发热和耗电纯CPU推理会让手机迅速升温长时间使用体验很差这只能靠硬件改善软件层面很难优化。第三是速度中端手机实测7B Q4大约每秒只有3到6个token简单聊几句还可以指望它做复杂推理会很磨人。另外建议只从可信渠道下载模型文件并且确认模型授权适合你的使用场景。开源模型生态里有大量不同授权协议的开源模型选择时要看清楚条款。6.3 实测取舍笔记本与手机上的性能表现为了让你有个直观概念我整理一份我自己实测过的参考数据同一模型在不同设备上的表现差异非常大设备模型与量化内存要求实测生成速度(约)32GB内存台式机(纯CPU)14B Q4_K_M约9GB10~15 token/s16GB内存笔记本(纯CPU)7B Q4_K_M约5GB8~12 token/s8GB内存笔记本3B Q4_K_M约2GB15~20 token/s12GB内存安卓手机7B Q4_K_M约5GB3~6 token/s24GB显存显卡14B Q5_K_M约11GB80 token/s结论很简单如果要在本地跑优先把内存或显存堆到位。CPU推理能接受但别抱太高期望有显卡的话体验是质的飞跃。如果你只是想在手机上学着玩玩建议从3B、7B模型入手量级定低一点把工具流程跑通再考虑更大模型。7. 进阶玩法微调、评测与单元测试7.1 用聊天记录微调先处理数据再动手当Prompt怎么调都不够好或者你希望模型稳定复现某一种对话风格时就可以考虑微调了。一个常见做法是基于真实的聊天记录精调模型把历史会话整理成标准的训练样本。数据格式通常是这样一份JSONL文件{messages: [{role: system, content: 你是XX平台的客服助手。}, {role: user, content: 我的订单一直显示发货中怎么回事}, {role: assistant, content: 您好请您提供一下订单号我为您查询物流状态。}]} {messages: [{role: system, content: 你是XX平台的客服助手。}, {role: user, content: 订单号是123456。}, {role: assistant, content: 您好已查询到该订单处于出库阶段预计明天送达。}]}微调的价值不是“让模型学到新知识”而是规范行为让它学会客服的口吻、特殊术语、固定流程。真正的新知识还得靠RAG或工具调用。实操中有几个坑必须提醒聊天记录往往含个人信息、脏数据、情绪化表达进入训练集之前必须清洗脱敏同时要控制各Token角色比例的均衡不能让“系统消息”的指令被训练数据稀释样本量上几千条高质量对话比几万条垃圾数据更有用。微调不是数据堆得越多效果越好质量差的数据反而会让模型学歪。另外对大多数团队先别上全参数微调从LoRA/QLoRA这类参数高效微调方法开始用一张消费级显卡就能跑成本低、迭代快。如果数据量不大甚至可以把微调和“完全不用微调”做个对比测试用事实数据说服自己该不该走这条路。7.2 让LLM写单元测试真能省时间你没看错LLM在软件开发里一个很实用的落地场景是单元测试生成。让模型阅读函数源码按你定义的约束生成测试用例再结合覆盖率工具和编译运行反馈就能形成一个自动化循环。我常用的Prompt思路是明确定义被测函数要求输入“正常值、边界值、异常输入”三类用例并指定不能mock掉核心逻辑。实际跑下来模型生成的“主路径测试”质量很高但在“边界条件”上经常漏检。所以一个很关键的工程动作是把测试框架自己先写好让模型来填用例而不是让它从零搭一整套测试工程。代码示例就不展开了核心经验是“分而治之”函数越短、依赖越少、描述越清楚生成的测试质量越高。如果你拿一个几百行、一堆副作用的巨型函数去喂模型得到的测试基本是废的。好的方向是先把代码重构得可测试再让LLM去补测试用例效率远高于直接丢原始代码。7.3 别跳进这些坑微调与测试的五个误区回到LLM落地这个话题这些年我见过太多团队在同一个地方反复跌倒这里整理五个高频误区方便你自查误区一事情还没做清楚就微调。其实80%的场景靠Prompt、RAG或工具调用就能解决微调是最后的手段不是第一反应。误区二只关心模型选型忽略评测方法。没有评测标准你换什么模型都像是在猜有了评测集哪怕用LLM as Judge快速打分模型迭代也立刻有方向。误区三让Agent随便打电话、发邮件。哪怕再高级的模型一旦拥有执行权限却没有人工确认、没有操作白名单那就是在给系统埋雷。误区四忽略token成本。长上下文反复调用、多轮重试都会让成本快速飙升上线前一定要做成本预估把Prompt长度、重试上限写清楚。误区五本地部署只看模型大小不看内存速度。很多人一开始就惦记着32B大模型结果下载完发现集成模型不出来的下文只能被迫回退到7B半天时间就耗进去了。这些坑的对应解法在前面的章节里已经分别讲过。如果你只记住一件事那就是一切以可验证的评测为准一切以工程可控为底线。我个人在实际操作中最深的体会是LLM项目翻车从来不是因为模型不够聪明而是因为需求拆解不清、缺少评测闭环、工程护栏没跟上。建议你从最小的场景切进去先跑通一个API调用用固定的评测集判断效果把约束条件加好再逐步放开模型的能力。这样你踩的每一个坑都能变成下一个版本优化的依据。