1. 先搞清楚LLM到底是个什么东西
1.1 从“输入一句话，吐出一段话”说起
很多人第一次接触LLM，脑子里冒出来的问题就是“它跟搜索引擎有什么区别”。搜索引擎是你给关键词，它给你一堆链接；LLM是你给一段话，它直接给你一段它“认为”你应该得到的回答。这个区别看着简单，但背后决定了你该怎么用它。
LLM的全称是Large Language Model，中文叫大语言模型。拆开看三个词：Large是规模大，参数量动辄几十亿到上万亿；Language是它只处理语言，或者说被语言表征的一切；Model是它本质上就是一个数学模型，一个超级复杂的函数。你给它一个输入序列，它输出下一个词的概率分布，然后根据某种策略挑一个词出来，再把这个词拼回输入里，继续预测下一个词。就这么一个循环，重复几百上千次，就生成了一整段回答。
我刚开始用的时候也觉得这玩意儿挺玄乎，后来想明白一件事就通透了：它不是在“思考”，它是在做概率续写。你给它“今天天气真”，它大概率续“好”，小概率续“差”，极小概率续“离谱”。它选哪个，取决于训练数据里哪种续写更常见，以及你给它的上下文里有没有额外的暗示。
这个认知特别重要，因为它直接决定了你该怎么写提示词。你写的每一句话，都是在给这个概率模型“调参”。你写得越具体、越有指向性，它续写出你想要的内容的概率就越高。
1.2 为什么同一个问题每次回答都不一样
这是新手最容易困惑的地方。你问同一个问题，今天问和明天问，答案可能完全不同；甚至同一分钟内问两次，答案也有差异。这不是bug，这是设计使然。
LLM在生成每个词的时候，并不是直接选概率最高的那个，而是从一个概率分布里“采样”。这个采样过程引入了随机性。有一个叫temperature的参数控制这个随机性的程度。temperature设成0，它就每次都选概率最高的词，输出完全确定；temperature设成1或者更高，它就更愿意选那些概率没那么高的词，输出就更多样。
这个机制的好处是让回答不那么死板，坏处是你没法保证每次得到一模一样的结果。对于需要稳定输出的场景，比如批量处理数据、生成结构化内容，你就得把temperature调低，甚至设成0。对于创意写作、头脑风暴这类场景，temperature可以适当调高，让它给你更多意想不到的组合。
我自己的习惯是：做数据提取、格式转换、代码生成的时候，temperature设0到0.3；做文案策划、起名字、想点子的时候，设0.7到1.0。这个区间不是死的，你可以根据实际效果微调。
1.3 上下文窗口：它的“短期记忆”有多大
LLM有一个叫上下文窗口的概念，指的是它一次能“看到”多少文字。这个窗口包括你给它的所有输入加上它自己生成的输出。比如一个模型标称上下文窗口是128K token，意思是你和它对话的总长度不能超过这个数。
token是啥？你可以粗略理解为“词片”。英文里一个单词可能被拆成一到多个token，中文里一个汉字通常是一到两个token。128K token大概相当于一本中等厚度的书。听起来很大，但如果你把一整份长文档丢进去让它分析，再加上多轮对话的历史记录，很快就会撑满。
撑满之后会发生什么？早期的模型会直接报错，现在的模型通常会采用某种策略“遗忘”最早的内容，或者对历史对话做摘要压缩。但不管哪种策略，都意味着它可能会丢掉一些关键信息。所以我在处理长文档的时候，习惯把最重要的指令放在输入的最前面和最后面，因为模型对开头和结尾的内容注意力更集中，中间部分容易被忽略。
还有一个坑：上下文窗口大不代表它真的能“记住”所有内容。有研究表明，当输入长度超过一定阈值后，模型对中间部分信息的提取能力会明显下降。所以别指望丢一本手册进去它就能回答任何细节问题，该分块处理就分块处理，该做检索增强就做检索增强。
2. 提示词到底该怎么写才管用
2.1 把LLM当成一个“非常聪明但完全不懂你业务的新人”
这是我最想分享的一个心态转变。很多人写提示词失败，是因为潜意识里觉得“它应该懂我的意思”。它不懂。它没有任何背景知识，不知道你的行业术语，不知道你的业务逻辑，不知道你想要的输出格式。你得像给一个刚入职的新人写操作手册一样，把每一步都写清楚。
我见过太多人写提示词就一句话：“帮我写个方案”。然后抱怨LLM输出的是废话。废话是必然的，因为你给的信息量太少了。你得告诉它：什么行业的方案、面向什么受众、方案要解决什么问题、大概多长、什么风格、有没有参考模板、必须包含哪些章节、哪些内容不能出现。
一个实用的技巧是“角色设定+任务描述+约束条件+输出格式”四段式。角色设定让它知道该用什么语气和知识范围；任务描述说清楚要做什么；约束条件划定边界；输出格式告诉它结果长什么样。这四段写全了，输出质量通常能提升一个档次。
2.2 少用否定句，多用肯定句
这是一个反直觉但实测有效的经验。你写“不要用专业术语”，模型可能反而会频繁使用专业术语。你写“用大白话解释”，效果就好很多。原因是语言模型在处理否定指令时，需要先理解“专业术语”这个概念，然后再去抑制它，这个抑制过程并不总是成功。而肯定指令直接告诉它“往哪个方向走”，路径更短。
同样的道理，“不要写得太长”不如“控制在300字以内”；“不要用markdown格式”不如“用纯文本段落输出”；“不要编造数据”不如“只使用我提供的数据，没有数据的地方写‘暂无’”。
我踩过的一个坑是让模型“不要重复我的问题”，结果它每次都在开头重复一遍我的问题。后来改成“直接给出答案，不要复述问题”，就正常了。否定句在提示词里就是个雷，能避就避。
2.3 给例子比给描述更有效
如果你想要一个特定的输出格式，最有效的方法不是描述这个格式，而是直接给一个例子。这叫“少样本提示”或者“few-shot prompting”。你给一两个输入输出的示例，模型就能模仿这个模式。
比如你想让模型从一段文本里提取人名、公司和职位，你直接给一个示例：
输入：“张三在字节跳动担任产品经理。” 输出：{"姓名": "张三", "公司": "字节跳动", "职位": "产品经理"}
然后再给真实输入，它就会按照这个JSON格式输出。比你写一堆“请以JSON格式输出，包含姓名、公司、职位三个字段”要可靠得多。
示例的数量也有讲究。一个示例通常就够了，复杂的任务可以给两到三个。但别给太多，一是浪费上下文窗口，二是示例太多可能让模型过度拟合示例的细节，反而在新输入上表现不好。
2.4 让模型“一步一步想”
对于需要推理的任务，比如数学题、逻辑题、多步决策，直接让它给答案往往容易出错。但如果你在提示词里加一句“让我们一步一步思考”，或者“请先分析问题，再给出结论”，准确率会明显提升。
这个技巧叫“思维链”。原理是模型在生成中间推理步骤的时候，相当于给了自己更多的计算空间。它不是在“想”，但它生成的每一个中间步骤都成为了后续生成的上下文，帮助它走向更合理的结论。
我实测下来，对于简单的分类任务，思维链帮助不大；但对于涉及计算、比较、多条件判断的任务，加了思维链之后准确率提升非常明显。你可以根据任务复杂度决定要不要加。
2.5 提示词的迭代比一次写好更重要
没有人能一次写出完美的提示词。我的习惯是：先写一个粗糙版本，跑几个测试用例，看哪里不对，然后针对性地修改。修改的时候一次只改一个地方，这样才能知道是哪个改动起了作用。
比如第一版输出太啰嗦，我加一句“控制在200字以内”；第二版输出格式不对，我加一个示例；第三版发现它漏掉了某个关键信息，我在任务描述里补上。这样迭代三五轮，提示词就基本可用了。
还有一个技巧是把提示词当成代码来管理。用版本控制工具存起来，每次修改记录改了什么、为什么改、效果如何。时间长了你就有一套自己的提示词库，遇到类似任务直接复用，效率提升非常明显。
3. 实际使用中绕不开的几个技术点
3.1 本地跑还是调API
这是每个人都会面临的选择。调API就是通过网络请求调用别人部署好的模型服务，按token计费。本地跑就是把模型下载到自己机器上，用显卡或者CPU推理。
调API的优势是省事，不用关心硬件、部署、维护，模型通常也是最新最强的。劣势是数据要传到别人服务器上，有隐私顾虑；按量计费，用得多成本不低；网络不稳定的时候会超时。
本地跑的优势是数据不出本地，隐私性好；一次部署长期使用，没有按量费用；可以离线运行。劣势是硬件门槛高，大模型需要大显存；部署和维护有技术门槛；模型能力通常比云端最新模型差一截。
我的建议是：如果是个人学习、实验、处理非敏感数据，调API最划算。如果是企业场景、涉及敏感数据、或者需要高频调用，可以考虑本地部署。本地部署的话，消费级显卡能跑的是7B到14B参数量的模型，量化之后显存占用可以压到8G以内。再大的模型就需要专业卡了。
3.2 量化：让大模型跑在小显存上
量化是本地部署的关键技术。简单说就是把模型参数的精度从16位浮点数降到8位、4位甚至更低，从而大幅减少显存占用和计算量。代价是模型能力会有一定损失，但通常损失可控。
常见的量化格式有GGUF、GPTQ、AWQ等。GGUF适合CPU推理和混合推理，对硬件要求最低；GPTQ和AWQ适合GPU推理，速度更快。如果你用的是消费级显卡，显存有限，优先考虑4位量化。如果显存充裕，8位量化的效果更接近原始模型。
我自己的经验是：7B模型4位量化后大概占4到5G显存，14B模型4位量化后大概占8到10G显存。你可以根据自己显卡的显存大小反推能跑多大的模型。留出1到2G显存给上下文和系统开销，剩下的才是模型能用的。
3.3 温度、top_p、top_k这些参数怎么调
除了temperature，还有几个采样参数会影响输出。top_p叫核采样，意思是只从概率累计达到p的那部分词里采样。top_k叫Top-K采样，意思是只从概率最高的k个词里采样。这两个参数和temperature配合使用，控制输出的多样性和质量。
我的调参习惯是这样的：需要确定性输出的时候，temperature设0，top_p设1，top_k设1，这样每次输出完全一样。需要平衡质量和多样性的时候，temperature设0.7，top_p设0.9，top_k设40。需要高多样性的时候，temperature设1.0以上，top_p设0.95，top_k设60以上。
这些参数没有绝对的最优值，不同模型的最佳参数也不一样。建议你拿一组固定的测试问题，在不同参数下跑一遍，对比输出质量，找到适合你任务的组合。
3.4 流式输出和批量处理
流式输出是指模型生成一个词就返回一个词，而不是等全部生成完再一次性返回。对于交互式应用，流式输出体验好很多，用户不用干等。对于批量处理任务，流式输出反而增加复杂度，不如等完整结果。
批量处理是指一次提交多个请求，让服务端并行处理。很多API都支持批量接口，价格比单次调用便宜，适合大规模数据处理。但批量处理通常有延迟，不适合实时交互场景。
我处理大批量数据的时候，习惯先用小样本测试提示词，确认效果稳定后再提交批量任务。批量任务的结果要抽样检查，因为一旦提示词有问题，错误会被放大到所有结果里。
4. 那些没人告诉你但迟早会踩的坑
4.1 幻觉：它编造起来比真的还真
幻觉是LLM最危险的问题。它会编造不存在的事实、引用不存在的文献、生成不存在的API。而且它编造的时候语气非常自信，格式非常规范，你如果不核实根本看不出来。
我踩过最惨的一次坑是让模型帮我查一个技术参数的取值范围，它给了一个非常具体的数字区间，还附上了“根据某某标准”。我去查那个标准，根本没有这个参数。后来我养成了一个习惯：凡是模型给出的具体数字、引用、链接、API名称，一律核实。宁可多花五分钟验证，也不要因为一个错误数据导致整个项目返工。
降低幻觉的方法有几个：一是要求模型“只使用我提供的信息回答，没有的信息说不知道”；二是让模型给出信息来源，然后你手动核实；三是对于关键事实，用多个模型交叉验证；四是把温度调低，减少随机性。
4.2 上下文污染：前面说错一句，后面全歪
多轮对话里有一个隐蔽的问题：如果模型在前面某一轮说错了，这个错误会留在上下文里，影响后续所有回答。它会把这个错误当成既定事实，在后面反复引用。
解决办法是发现错误立刻纠正，不要让它继续。你可以直接说“你刚才说的某某是错的，正确的是某某，请基于这个重新回答”。如果错误比较严重，干脆开一个新对话，把正确的背景信息重新给一遍。别舍不得那点上下文，带着错误信息继续聊只会越聊越偏。
4.3 格式不稳定：说好的JSON呢
让模型输出JSON格式，它有时候给你纯JSON，有时候给你包在代码块里，有时候前面加一句“好的，以下是JSON”，有时候字段名大小写不一致。这在程序化处理的时候非常头疼。
我的应对策略是：第一，在提示词里明确说“只输出JSON，不要任何其他文字”；第二，给一个严格的示例；第三，在代码里做容错处理，比如用正则提取JSON部分，或者用专门的解析库处理不规范的JSON；第四，如果模型支持，开启“JSON模式”或者“结构化输出”功能，这个功能会强制模型输出合法JSON。
即使做了这些，也还是要做校验。我习惯在解析之后检查关键字段是否存在、类型是否正确，不合法就重试或者报错。
4.4 长对话的“遗忘”
前面提到过上下文窗口的问题，这里再展开说一个实际场景：你和模型聊了很长一段，突然问它一个很早之前提到过的细节，它很可能答不上来。不是它“忘了”，而是那个细节已经不在它的上下文窗口里了，或者虽然在窗口里但注意力权重很低。
解决办法是定期做“上下文摘要”。你可以让模型把之前的对话总结成一段简短的背景信息，然后用这个摘要加上新的问题开始新一轮对话。这样既保留了关键信息，又释放了上下文空间。
还有一个技巧是把关键信息放在每轮对话的开头重复一遍。比如“背景：我们在做一个电商推荐系统，目标是提升点击率。问题：……”这样即使前面的对话被截断了，关键背景还在。
4.5 成本失控：token是钱
调API按token计费，输入和输出都算钱。如果你不注意，成本会悄悄涨上去。我见过有人把一整本书丢进去让模型总结，一次调用就花掉几十块。
控制成本的几个方法：一是精简提示词，去掉不必要的客套话和重复描述；二是控制输出长度，在提示词里明确字数上限；三是用更便宜的模型处理简单任务，复杂任务再用贵模型；四是缓存重复的输入，很多API支持提示词缓存，重复部分不计费或者打折；五是批量处理，比单次调用便宜。
我自己的习惯是每周看一下用量报表，看看哪些调用是必要的，哪些可以优化。时间长了就能摸清楚哪些任务用哪个模型最划算。
5. 从“会用”到“用好”的进阶思路
5.1 检索增强：让模型基于你的数据回答
LLM的训练数据是截止到某个时间点的，而且不包含你的私有数据。如果你问它关于你公司内部文档的问题，它要么说不知道，要么编一个答案。检索增强生成就是解决这个问题的。
RAG的思路很简单：先把你的文档切块、向量化、存到向量数据库里；用户提问的时候，先把问题向量化，在数据库里找最相似的几个文档块；然后把问题和这些文档块一起发给LLM，让它基于这些内容回答。
这个方案的好处是不需要重新训练模型，成本低，更新数据也方便。难点在于文档切块的策略、向量模型的选择、检索的召回率和准确率。我踩过的坑是切块太小导致上下文不完整，切块太大导致检索不精准。通常需要根据文档类型做实验，找到一个平衡点。
5.2 微调：什么时候值得做
微调是在预训练模型的基础上，用你的数据继续训练，让模型更适应你的特定任务。它适合的场景是：你有大量标注数据、任务格式非常固定、对输出风格有严格要求、而且提示词工程已经优化到瓶颈了。
微调的成本比RAG高得多，需要准备数据、租用算力、调参、评估。而且微调后的模型可能会“遗忘”一些通用能力，需要小心平衡。我的建议是先用提示词工程和RAG，实在解决不了再考虑微调。很多问题其实不需要微调就能解决。
5.3 智能体：让模型自己决定用什么工具
智能体是最近很热的方向。简单说就是让LLM不只是生成文本，而是能调用外部工具、执行多步任务。比如你让它“帮我查一下明天北京的天气，然后根据天气推荐穿什么”，它会先调用天气API查天气，再根据结果生成穿搭建议。
智能体的核心是“规划+工具调用+记忆”。规划是它把大任务拆成小步骤；工具调用是它知道什么时候该用什么工具；记忆是它记住之前的步骤和结果。这个方向潜力很大，但目前还不够稳定，复杂任务容易出错。适合从简单场景开始尝试，比如单工具调用、固定流程的任务。
5.4 评估：怎么知道模型输出好不好
没有评估就没有优化。你得有一套方法来衡量模型输出质量，才能知道改动提示词、换模型、加RAG之后是变好了还是变差了。
评估方法分两类：自动评估和人工评估。自动评估可以用另一个LLM来打分，或者用规则匹配关键信息。人工评估就是找人来看，通常更准但更贵。我通常先用自动评估做粗筛，再用人工评估做精评。
评估指标要看任务类型。分类任务看准确率和召回率；生成任务看流畅度、相关性、事实准确性；结构化输出看格式合规率和字段完整率。关键是定义清楚“好”的标准，然后持续测量。
6. 一些零散但实用的经验
6.1 模型选择没有银弹
不同模型有不同的擅长领域。有的擅长代码，有的擅长中文，有的擅长推理，有的响应速度快，有的价格便宜。不存在一个模型在所有任务上都最好。
我的做法是维护一个模型清单，记录每个模型的特点、价格、速度、擅长任务。接到新任务的时候，先根据任务特点选两三个候选模型，跑同一组测试用例，对比效果和成本，再决定用哪个。
6.2 提示词要跟着模型走
同一个提示词在不同模型上的效果可能差异很大。为一个模型调好的提示词，换到另一个模型上可能完全不能用。所以换模型的时候，提示词也要重新测试和调整。
我一般会为每个常用模型维护一套提示词模板，而不是指望一套提示词打天下。虽然麻烦一点，但效果有保障。
6.3 别把LLM当搜索引擎用
LLM的知识有截止日期，而且它不知道最新发生的事情。如果你问它今天的新闻、最新的股价、刚发布的软件版本，它要么说不知道，要么给你过时的信息。需要实时信息的时候，用搜索引擎或者专门的API，别为难LLM。
6.4 保存你的对话记录
和LLM的对话记录是宝贵的资产。好的提示词、好的输出示例、踩过的坑，都值得保存下来。我习惯用笔记软件建一个LLM使用日志，记录每次重要对话的提示词、输出、问题和改进思路。时间长了这就是你自己的知识库。
6.5 保持学习，但别追新追到焦虑
这个领域变化太快了，每周都有新模型、新工具、新论文。追是追不完的。我的策略是关注几个靠谱的信息源，定期扫一眼，遇到真正有用的再深入研究。大部分新东西其实只是微创新，核心原理没变。把基础打牢，比追每一个热点更重要。
我在实际使用中最大的体会是：LLM是一个放大器，它放大你的能力，也放大你的疏忽。你思路清晰，它帮你更快产出；你逻辑混乱，它帮你更快地产出混乱。所以与其花时间研究各种花哨的技巧，不如先把问题想清楚，把需求描述清楚。这个基本功练好了，用什么模型、什么工具都不会太差。
