1. 先搞清楚LLM到底是个什么东西1.1 从输入一句话吐出一段话说起很多人第一次接触LLM脑子里冒出来的问题就是llm是什么。说白了LLM就是Large Language Model大语言模型。你可以把它想象成一个读了海量文本的超级自动补全器——你给它一段话它根据训练时见过的海量模式预测接下来最可能出现的词是什么一个词一个词往外蹦最后拼成一段完整的回答。但这里有个关键点很多人没意识到LLM本质上做的不是检索而是生成。它不是在数据库里查一条现成的答案给你而是根据你的输入实时编出一段话来。这就解释了为什么同一个问题问两遍答案可能不一样也解释了为什么它会一本正经地胡说八道——因为它追求的是像那么回事而不是一定对。理解这一点后面所有的使用方法、调优技巧、避坑经验才有落脚点。你把它当成一个知识渊博但偶尔会记混的朋友而不是一本权威字典心态就对了。1.2 为什么现在人人都在聊LLMLLM真正出圈是因为它把用自然语言指挥计算机这件事的门槛降到了几乎为零。以前你想让电脑帮你干活得学编程、学命令、学各种软件操作现在你只要会打字、会说人话就能让LLM帮你写文案、改代码、做翻译、理思路、查资料。从热搜词也能看出来大家关心的方向非常分散有人问llm模型怎么选有人研究llm框架怎么搭有人琢磨llm as judge怎么用模型来打分评估还有人折腾安卓本地运行gguf格式llm软件。这说明LLM已经不是一个单一工具而是一个生态——从底层模型到上层应用从云端调用到本地部署从个人玩票到工程实践全都有文章可做。我自己的判断是未来几年会不会用LLM会像今天会不会用搜索引擎一样成为一项基础生存技能。所以现在花时间把使用方法摸透绝对不亏。1.3 这篇内容适合谁看如果你是完全没碰过LLM的新手这篇能帮你建立一套完整的认知框架知道从哪儿下手、怎么少走弯路。如果你已经用过一些聊天类产品但总觉得效果时好时坏这篇会告诉你问题出在哪儿怎么把它的能力稳定地榨出来。如果你是想把LLM集成到自己项目里的开发者里面关于框架选型、本地部署、评估方法的讨论也能给你一些参考。我不打算写成一份官方说明书而是按一个实际用过、踩过坑的人的视角把LLM的使用方法掰开揉碎讲清楚。2. 使用LLM前必须建立的三个核心认知2.1 认知一提示词的质量决定输出的上限很多人用LLM的方式是脑子里想到什么就打什么一句话丢过去然后抱怨它答得不好。这就好比你去找一个专业顾问咨询只说帮我看看这个怎么办对方当然只能给你泛泛而谈。提示词Prompt的质量直接决定了LLM能发挥出多少能力。一个高质量的提示词通常包含几个要素明确的角色设定、清晰的任务描述、必要的背景信息、期望的输出格式、以及适当的约束条件。举个例子你想让LLM帮你写一封辞职信。低质量提示是帮我写封辞职信。高质量提示是你是一位有十年HR经验的职场顾问。我需要写一封辞职信给直属领导原因是个人职业发展调整希望保持良好关系。语气要诚恳但不卑不亢篇幅控制在300字以内结尾表达对团队的感谢。请用正式书面语。后者给出的信息量是前者的几十倍输出质量自然天差地别。我实测下来同一个模型提示词优化前后输出可用率能从三成提到八成以上。提示不要指望一句话就让LLM产出完美结果。把提示词当成需求文档来写信息越充分返工越少。2.2 认知二上下文窗口是有限资源LLM有一个叫上下文窗口的概念简单说就是它一次能记住多少内容。这个窗口包括你输入的所有文字加上它输出的所有文字。窗口满了最早的内容就会被挤出去模型就忘了。这带来两个实际影响。第一长对话到后面模型可能忘记前面说过的关键信息你需要主动提醒或重新粘贴。第二如果你要让它处理一份很长的文档得考虑分段处理或者用支持超长上下文的模型。我踩过的一个坑是跟LLM聊了很长一段让它基于前面某段内容做修改结果它改出来的东西完全跑偏因为它已经把那段内容挤出记忆了。后来我养成的习惯是重要信息在关键节点重新贴一遍或者干脆开新对话、把必要背景一次性给足。2.3 认知三LLM会自信地犯错这是最需要警惕的一点。LLM生成内容时语气永远是那么笃定哪怕它在胡说。它会编造不存在的参考文献、虚构的数据、张冠李戴的事实而且说得有鼻子有眼。业内管这叫幻觉。应对幻觉的办法有几个。一是对关键事实做交叉验证尤其是数据、引用、法律条款这类不能出错的内容。二是让LLM在不确定时明确说我不确定这需要在提示词里明确要求。三是对于需要精确计算或查询的任务不要依赖LLM的记忆而是给它提供准确的原始材料让它基于材料回答。我个人的经验是把LLM当成一个初稿生成器和思路激发器而不是最终答案提供者。它产出的东西尤其是涉及事实的部分必须经过人工审核才能用。3. 从零上手LLM的四种主流使用方式3.1 方式一直接用现成的聊天产品这是门槛最低的方式。打开网页或App注册账号直接开聊。适合绝大多数普通用户不需要任何技术背景。这类产品的优势是开箱即用、模型持续更新、通常有免费额度。劣势是定制化程度低、数据隐私取决于平台政策、高峰期可能限流。使用这类产品时我建议养成几个习惯。第一重要对话及时保存或导出避免丢失。第二涉及敏感信息时谨慎输入想想这些内容是否适合上传。第三善用新对话功能不同任务分开聊避免上下文互相干扰。3.2 方式二通过API调用如果你想把LLM集成到自己的程序里或者需要批量处理任务就得走API。API的本质是你用代码发一个请求给模型服务商把提示词传过去它把结果传回来。一个典型的API调用流程是这样的准备API密钥、构造请求包含模型名称、提示词、参数、发送请求、解析返回结果。不同服务商的接口格式略有差异但核心逻辑一致。# 以常见的API调用为例伪代码示意 import requests headers { Authorization: Bearer YOUR_API_KEY, Content-Type: application/json } payload { model: your-model-name, messages: [ {role: system, content: 你是一位专业助手}, {role: user, content: 请解释什么是LLM} ], temperature: 0.7 } response requests.post(API_ENDPOINT, headersheaders, jsonpayload) result response.json() print(result[choices][0][message][content])这里有几个参数值得注意。temperature控制输出的随机性值越低越稳定保守值越高越有创造性。max_tokens限制输出长度。top_p是另一种控制随机性的方式通常和temperature二选一调整。注意API调用会产生费用务必设置好用量监控和预算上限避免意外超支。我见过有人忘了设限一晚上跑掉不少额度。3.3 方式三本地部署运行热搜里提到安卓本地运行gguf格式llm软件这属于本地部署的范畴。本地部署的好处是数据不出本机、隐私性好、不依赖网络、没有按次计费。代价是需要一定的硬件资源且模型能力通常不如云端大模型。GGUF是一种常见的模型文件格式配合相应的推理软件可以在消费级设备上运行。在安卓上跑LLM通常需要选择参数量较小的模型比如几B级别的并且对手机内存有一定要求。本地部署的典型流程是下载模型文件、安装推理软件、加载模型、调整参数、开始对话。参数方面量化等级影响模型大小和效果等级越高效果越好但占用越大上下文长度影响能记住多少内容但也会吃内存。我实测下来本地小模型适合做简单的文本处理、翻译、摘要这类任务复杂推理还是得靠云端大模型。但它的隐私优势和离线可用性在特定场景下非常香。3.4 方式四借助LLM框架搭建应用llm框架是进阶玩法。框架帮你封装了模型调用、上下文管理、工具调用、记忆存储等通用能力让你能更快地搭建复杂应用。常见的框架思路包括链式调用把多个步骤串起来、智能体让模型自主决定调用哪些工具、检索增强先查资料再回答。热搜里的识的llm智能体自主容错控制就属于智能体方向的工程实践核心是让AI系统在出错时能自己发现并纠正从而构建更可靠的系统。用框架的好处是省去大量重复造轮子的工作坏处是增加了学习成本和抽象层出问题时排查更麻烦。我的建议是先用原生API把基本流程跑通理解每一步在干什么再上框架。4. 提示词工程把LLM能力榨出来的实操方法4.1 结构化提示词的四个模块我把一个好用的提示词拆成四个模块角色、任务、约束、格式。角色模块告诉LLM你是谁比如你是一位资深财务分析师。这能激活模型在相关领域的知识让输出更专业。任务模块说清楚要做什么越具体越好。约束模块划定边界比如不要使用专业术语控制在500字以内。格式模块规定输出长什么样比如用表格呈现分三点说明。这四个模块不必每次都写全但心里要有这根弦。缺哪个模块输出就容易在哪个维度出问题。4.2 少样本示例的威力有时候你光用文字描述任务LLM理解得不够准。这时候给它几个输入-输出的示例效果会立竿见影。这叫少样本提示Few-shot Prompting。比如你想让LLM把用户反馈分类与其描述请把反馈分为正面、负面、中性不如直接给例子输入这个功能太好用了 → 输出正面输入等了半小时还没反应 → 输出负面输入今天更新了版本 → 输出中性给了两三个例子之后模型对任务的理解会精准很多。我实测下来对于分类、抽取、格式转换这类任务少样本提示比纯文字描述的效果提升非常明显。4.3 让LLM一步步想对于需要推理的任务直接问答案往往容易错。让LLM先把思考过程写出来再给结论准确率会高不少。这就是思维链Chain of Thought的思路。具体做法是在提示词里加一句请一步步分析或者先说明你的推理过程再给出最终答案。模型把中间步骤展开后相当于给了自己更多计算空间复杂问题的正确率会提升。不过要注意有些场景下你只想要结果不想要过程那就别加这句否则输出会变得冗长。4.4 迭代优化没有一次到位的提示词提示词不是写一次就完事的。我的习惯是先写一版看输出找出不满意的地方针对性修改提示词再看输出循环几轮。常见的修改方向包括补充缺失的背景信息、增加具体的约束条件、调整示例、改变输出格式要求、换一种任务描述方式。有时候只是把总结一下改成用三句话总结每句不超过20字输出就完全不一样了。这个过程有点像调音得反复试。但一旦调好那个提示词就可以复用一劳永逸。5. 进阶玩法让LLM干更复杂的活5.1 用LLM做评估LLM as Judgellm as judge是这两年很火的一个方向。核心思路是让一个LLM来给另一个LLM的输出打分或评判。这在没有标准答案、需要主观判断的场景下特别有用比如评估文案质量、判断回答是否有害、比较两个方案的优劣。做法通常是设计一套评分标准把标准、待评估内容、参考信息一起给评判模型让它输出分数和理由。为了提高可靠性可以多个模型交叉评判或者让同一个模型多次评判取平均。我试过用这个方法来筛选批量生成的文案效率比人工高很多。但要注意评判模型本身也有偏见标准设计不好会导致评分失真。所以评分标准要尽量具体、可操作避免模糊表述。5.2 检索增强生成RAGLLM的知识有截止日期而且不知道你的私有资料。RAG的思路是先从你的资料库里检索出相关内容再把内容和问题一起给LLM让它基于这些内容回答。这样做的好处是答案有据可依、能引用私有知识、减少幻觉。实现上需要一套检索系统通常是向量数据库加相似度搜索和一个LLM。实操中容易踩的坑是检索出来的内容不相关导致LLM被误导。所以检索质量是关键需要调优切分策略、嵌入模型、召回数量等参数。5.3 智能体与工具调用智能体Agent是让LLM不仅能说还能做。你给它配备一些工具比如搜索、计算器、代码执行、文件操作它自己决定什么时候调用哪个工具来完成任务。热搜里的识的llm智能体自主容错控制讲的就是这个方向——让智能体在执行过程中能发现错误、自我纠正从而构建更可靠的系统。这在工程上是个难点因为LLM的决策不一定靠谱需要设计好容错机制和人工兜底。我的经验是智能体适合任务边界清晰、工具定义明确的场景。如果任务太开放智能体容易跑偏反而不如固定流程可靠。5.4 模型微调如果你有大量特定领域的数据想让模型更懂你的业务可以考虑微调。微调是在预训练模型的基础上用你的数据再训练一下让模型适应特定任务或风格。热搜里使用聊天记录模型精调llm就是这个思路——用真实的对话数据让模型学会特定的说话方式。微调的好处是效果针对性强坏处是需要数据、算力和技术门槛而且可能过拟合。对于大多数应用场景我建议先试提示词工程和RAG这两样搞不定再考虑微调。微调是重武器别轻易上。6. 常见问题与排查技巧实录6.1 输出质量不稳定的排查思路输出时好时坏是最常见的问题。排查顺序我一般是这样先看提示词是否足够明确模糊的提示词必然导致飘忽的输出再看temperature是否设得太高高随机性会让输出波动大然后看上下文是否太长导致关键信息被挤掉最后考虑模型本身的能力边界有些任务它确实做不好。一个实用技巧是把temperature调低比如0.2输出会稳定很多。如果任务需要创造性再适当调高。6.2 模型不听话怎么办有时候你明确要求了格式或约束模型就是不听。这时候可以试试几个办法把要求放在提示词的最后模型对末尾内容更敏感、用更强烈的措辞必须务必、给出符合要求的示例、或者分两步走——先让它生成内容再单独让它按格式整理。如果还是不行可能是模型能力不够换个更强的模型试试。6.3 处理长文档的策略长文档超出上下文窗口时常见策略有分段处理再汇总、先做摘要再基于摘要回答、用RAG只检索相关片段。分段处理时要注意段与段之间的衔接避免信息割裂。我处理长文档的习惯是先让模型生成一个整体摘要和结构大纲然后针对具体问题定位到相关章节只把那部分内容给它。这样既省token又提高准确率。6.4 常见问题速查表问题现象可能原因解决方向回答太笼统提示词信息不足补充背景、约束、示例回答跑偏任务描述模糊明确任务边界和输出要求事实错误模型幻觉提供准确材料、要求标注不确定格式不对格式要求不明确给出格式示例、分步处理输出太长/太短长度未约束明确字数或要点数量前后矛盾上下文过长精简上下文、关键信息重述拒绝回答触发安全策略调整表述方式、确认内容合规6.5 几个我踩过的坑第一个坑是过度信任。早期我把LLM给的数据直接用在报告里结果被指出数据有误非常尴尬。从那以后凡是事实性内容我都交叉验证。第二个坑是提示词太随意。有段时间我图省事提示词写得很短结果输出质量很差还以为是模型不行。后来认真写提示词同一个模型效果天差地别。第三个坑是忽略成本。API调用是按量计费的我有次跑批量任务没设上限账单出来吓了一跳。现在我都设好预算告警。第四个坑是上下文污染。在一个对话里聊了好几个不相关的任务结果模型把前面的内容串进来了。现在我坚持一个任务一个对话。7. 关于模型选型和生态的一些个人观察7.1 没有最好的模型只有最合适的市面上模型很多各有侧重。有的擅长推理有的擅长写作有的响应快有的上下文长有的便宜有的贵。选型时不要盲目追新追大而是看你的具体需求。我的建议是先用几个主流模型各跑一遍你的典型任务对比效果和成本再决定主力用哪个。很多时候一个中等模型加上好的提示词效果不输顶级模型成本却低很多。7.2 本地与云端的取舍本地部署和云端调用不是非此即彼而是可以组合。敏感数据本地处理复杂任务云端处理离线场景本地在线场景云端。这种混合模式在实际项目中很常见。7.3 关注工程实践而非追热点热搜词里有很多新概念但真正落地时决定成败的往往是那些朴素的工程问题提示词管理、错误处理、成本控制、效果评估、数据安全。这些不性感但很重要。我见过太多项目概念很炫但因为没处理好这些基础问题而失败。所以我的建议是先把基础打牢再考虑花活。8. 我个人的一些使用心得用LLM这几年最大的体会是它是个放大器放大你的能力也放大你的懒惰。你认真思考、精心设计它就给你惊喜你敷衍了事、指望它包办它就给你一堆看似像样实则没用的东西。我现在的工作流基本是用LLM做初稿和头脑风暴自己做判断和打磨。它帮我省掉了大量重复劳动但最终的决策和质量把控还是在我手里。这个分工我觉得挺健康。另外别把LLM当搜索引擎用。搜索是找现成的信息LLM是生成新的内容。需要准确信息时该搜还是得搜LLM更适合做信息的加工和再创造。最后分享一个小技巧给LLM设定一个人设让它用特定身份、特定语气说话输出会生动很多。比如让它用给小学生讲课的方式解释复杂概念立马变得好懂。这个技巧我用了无数次屡试不爽。
