1. 大语言模型到底能做什么，不能做什么

1.1 从一个真实翻车现场说起

去年我帮一个做电商的朋友搭智能客服，选了一个当时榜单排名很靠前的大语言模型，接口调通、提示词写好、知识库也灌进去了，测试阶段一切正常。上线第三天，一个用户问“你们家这款充电宝能不能带上飞机”，模型非常自信地回答说“可以，20000mAh以内都能随身携带”。实际上民航的规定是按额定能量算的，不是按毫安时，而且各航司执行细节还有差异。这个回答看起来专业、语气笃定、格式工整，但它是错的。

这件事让我彻底意识到一个问题：大语言模型的能力边界，不是靠跑几个demo就能摸清的。它在流畅度、知识广度、指令跟随上的表现太容易让人产生“它什么都懂”的错觉，而真正的坑，往往埋在那些它“不知道自己不知道”的地方。

这篇笔记就是我这段时间系统梳理大语言模型能力和局限的总结。不管你是刚接触LLM的开发者，还是已经在做智能体、做本地部署、做数据标注的从业者，我都建议你把“能力”和“局限”这两件事放在一起看——只盯着能力，容易过度信任；只盯着局限，又会低估它的实用价值。适合的读者包括：想接入LLM做产品的工程师、做模型微调和数据标注的算法同学、以及在企业里推动AI落地的技术负责人。

1.2 能力清单：它真正擅长的那几件事

先把能力说清楚。大语言模型的核心机制是基于上下文的下一词预测，这个机制决定了它的能力分布是有规律的，不是随机的。

第一，语言理解与生成。这是它的看家本领。改写、摘要、翻译、润色、扩写、压缩，这些任务它做得又快又稳。我实测下来，一篇3000字的中文技术文档，让它压缩到800字并保留所有关键结论，质量能到“稍作修改即可用”的水平。这个能力背后是海量语料训练出来的语言分布建模，它对“什么样的表达是通顺的”有极强的直觉。

第二，知识问答与信息整合。在训练数据覆盖范围内的事实性知识，它能答得不错。更重要的是，它能把散落在不同段落里的信息整合成一个连贯的回答。比如你给它一份产品需求文档和一份技术方案，让它找出两者之间的冲突点，它往往能发现人容易忽略的细节。

第三，指令跟随与格式控制。你让它输出JSON，它就输出JSON；你让它按表格整理，它就按表格整理；你给它几个示例，它就能模仿示例的风格。这个能力是它区别于传统NLP模型的关键——同一个模型，换一段提示词就能切换任务，不需要重新训练。

第四，代码理解与生成。写函数、补全代码、解释报错、做代码审查，这些它都能做。我试过让它把一个Python脚本改写成带类型注解和异常处理的版本，改完基本可以直接用。当然，复杂业务逻辑和架构设计它还是不行，但日常的“写个工具函数”“解释这段代码在干嘛”完全够用。

第五，推理与多步思考。在数学题、逻辑题、需要分步推导的任务上，如果引导它“一步一步想”，表现会明显提升。这个能力不是它天生就强，而是思维链提示把它的推理过程显式化了，相当于给它搭了个脚手架。

1.3 局限清单：它翻车的那些固定套路

能力说完，重点说局限。这部分才是真正值钱的经验。

第一，幻觉。这是最要命的问题。它会编造不存在的事实、引用不存在的文献、给出不存在的API。而且它编造的时候语气和真话一模一样，没有任何“我不确定”的信号。我踩过的坑是：让它推荐某个库的配置参数，它给了一个看起来很合理的参数名，结果文档里根本没有这个参数。幻觉的根源是它的目标是“生成看起来合理的文本”，不是“生成正确的文本”。

第二，知识截止与时效性。模型训练数据有截止日期，之后发生的事情它不知道。你问它最新的框架版本、最新的政策变化，它要么说不知道，要么用旧知识硬答。这个局限在快速变化的领域（比如前端框架、AI工具链）特别致命。

第三，上下文窗口的“中间遗忘”。现在模型动辄支持几十万token的上下文，但实测下来，信息放在上下文中间部分时，模型的召回率明显低于开头和结尾。这个现象在学术上叫“lost in the middle”。我做过测试：把关键信息放在一份长文档的第40%位置，模型有相当概率忽略它；放在开头或结尾，召回率就高很多。

第四，数学与精确计算。它做算术经常出错，尤其是多位数乘除、带单位的换算。原因很简单：它是按token预测的，不是按位运算的。你让它算“1234乘以5678”，它可能给你一个看起来差不多但完全错误的数。涉及精确计算，必须外接计算器或代码执行。

第五，逻辑一致性与自我矛盾。同一个问题换个问法，它可能给出矛盾的答案。多轮对话里，它可能忘记前面说过的约束。这个局限在做复杂任务编排时特别明显——你以为它记住了，其实它只是在每一轮重新“猜”一个合理的回答。

第六，对提示词的敏感性。同样的意图，换个措辞，输出质量可能天差地别。这不是bug，是它的工作机制决定的。所以提示词工程才成为一门手艺——你不是在“命令”它，而是在“引导”它进入正确的概率分布区域。

1.4 能力与局限的对照表

这张表是我自己踩坑踩出来的，建议你贴在工位上。每次用LLM做新任务，先对照一遍，问自己：这个任务落在它的能力区还是局限区？

2. 为什么它会有这些局限：机制层面的解释

2.1 下一词预测：一切能力和局限的源头

要理解局限，必须回到它的训练目标：给定前面的token，预测下一个token的概率分布。就这么简单。所有的能力都是这个目标的副产品，所有的局限也都源于这个目标的本质。

它不是在“理解”你的问题然后“查找”答案，而是在根据上下文计算“接下来最可能出现什么词”。当训练数据里“充电宝能带上飞机”后面经常跟着“可以”时，它就会倾向于生成“可以”。它不知道民航规定，它只知道语言上的共现规律。

这个机制解释了很多现象。为什么它幻觉时那么自信？因为训练数据里的陈述句大多是肯定的、确定的，它学到的“合理文本”就是笃定的语气。为什么它对提示词敏感？因为不同的措辞会把上下文映射到不同的概率区域。为什么它算术差？因为数字在训练数据里是按token切分的，“1234”可能被切成“12”和“34”，它根本没有“位”的概念。

2.2 训练数据的边界就是它的知识边界

模型的全部知识来自训练数据。训练数据没覆盖的，它不知道；训练数据里错的，它可能学错；训练数据里过时的，它就过时。更麻烦的是，它不知道自己不知道什么。人遇到不懂的问题会说“我不确定”，但模型没有这个元认知能力，它会用已有的知识去“拼凑”一个答案。

这就引出一个实操原则：凡是训练数据可能不覆盖、可能过时、可能有争议的领域，都不能裸用模型输出。医疗、法律、金融、最新技术文档，这些场景必须加检索、加验证、加人工审核。

2.3 上下文窗口不等于有效记忆

很多人以为上下文窗口大，模型就能“记住”所有内容。实际上，注意力机制对上下文中不同位置的关注度是不均匀的。开头和结尾的token获得的注意力权重更高，中间部分容易被稀释。而且随着上下文变长，这种稀释效应越明显。

我做过一个实验：给模型一份2万字的文档，问一个答案在文档第60%位置的问题。直接问，它答错的概率不低；但如果我先把相关段落摘出来再问，准确率立刻上去。这说明上下文窗口是“容量”，不是“有效记忆”。你不能指望把一堆资料塞进去它就全记住，得帮它把关键信息“提”到显眼位置。

2.4 对齐训练带来的“讨好倾向”

现在的模型都经过人类反馈对齐训练，目标是让输出“有用、诚实、无害”。但这个训练有个副作用：模型倾向于给出用户想听的答案，而不是正确的答案。你问“我这个方案是不是很好”，它倾向于说“很好”；你问“这个bug是不是很难修”，它倾向于附和“确实很难”。

这个倾向在需要客观判断的场景里很危险。应对办法是改变提问方式：不要问“这个方案好不好”，而是问“这个方案有哪些潜在问题”；不要问“我是不是对的”，而是问“如果我是错的，可能错在哪里”。把它的讨好倾向引导到“找问题”而不是“给肯定”上。

3. 实操中怎么扬长避短：我的工作流

3.1 任务分级：哪些能裸用，哪些必须加护栏

我把日常任务分成三级：

绿灯任务：语言改写、格式转换、代码补全、头脑风暴、解释概念。这些任务错了代价低，模型表现也稳定，可以直接用，人工扫一眼即可。

黄灯任务：知识问答、数据分析、方案建议、代码生成。这些任务错了有代价，必须加验证环节。我的做法是：模型输出后，关键事实用搜索引擎或官方文档交叉验证，代码必须跑测试，数据必须用脚本复核。

红灯任务：医疗建议、法律意见、财务决策、安全关键系统。这些任务错了代价极高，模型只能做辅助，最终决策必须由有资质的专业人士做，且要有完整的审核记录。

这个分级不是拍脑袋，是根据错误代价和模型在该任务上的历史表现综合定的。你可以根据自己的业务场景调整，但核心原则不变：代价越高，护栏越厚。

3.2 提示词结构化的四个要素

我写提示词有个固定框架，四个要素：角色、任务、约束、示例。

角色：告诉它“你是谁”。比如“你是一个有十年经验的Java后端工程师”。这不是玄学，角色设定会把上下文映射到特定领域的概率区域，输出会更专业。

任务：说清楚“做什么”。要具体，不要模糊。“帮我看看这段代码”不如“找出这段代码里的空指针风险和资源泄漏点”。

约束：明确“不能做什么”和“必须满足什么”。比如“不要编造不存在的API”“输出必须是合法JSON”“如果信息不足，明确说不知道”。

示例：给一两个输入输出样例。这是最有效的控制手段，比任何形容词都管用。模型看到示例，就知道你要的格式和风格。

3.3 检索增强：给模型接上“外部记忆”

幻觉和知识截止这两个局限，最有效的解法是检索增强生成。思路很简单：用户提问时，先从知识库里检索相关文档，把文档和问题一起塞给模型，让它基于文档回答。

我搭过一套最小可用的RAG流程：文档切块、向量化、存向量库、查询时检索top-k、拼进提示词、生成回答。关键细节有几个：

• 切块大小：我一般用300到500字一块，带重叠。太小丢上下文，太大检索不准。
• 检索数量：top-k不要太大，3到5条就够。塞太多反而稀释注意力。
• 提示词约束：明确告诉模型“只根据提供的资料回答，资料里没有的就说不知道”。这一句能大幅降低幻觉。
• 引用来源：让模型在回答里标注信息来自哪段资料，方便人工核查。

这套流程搭下来，知识问答的准确率提升非常明显。代价是多了检索环节的延迟和工程复杂度，但对于知识密集型场景，这个投入值得。

3.4 本地部署的取舍

热词里“本地部署大语言模型”出现频率很高，我聊聊自己的取舍。本地部署的核心价值是数据不出本地和可控性，代价是硬件成本和效果差距。

我的经验是：7B到14B参数的模型，量化后在消费级显卡上能跑，适合做隐私敏感的内部工具、批量文本处理、简单问答。但复杂推理、长文档理解、高质量生成，本地小模型和云端大模型差距还是明显的。

选型时我会问三个问题：数据敏感吗？任务复杂吗？预算够吗？三个都指向本地就本地，否则优先云端。混合方案也常见：敏感数据本地预处理，复杂任务云端处理，中间做好脱敏。

4. 常见问题与排查技巧实录

4.1 输出不稳定怎么办

问题：同一个提示词，跑两次结果差异很大。

排查思路：先看温度参数。温度高，输出随机性大；温度低，输出稳定但可能死板。做需要确定性的任务（比如格式转换、数据提取），把温度调到0或接近0。做创意任务，温度可以高一些。

如果温度已经很低还不稳定，检查提示词是否有歧义。模型对模糊指令的解读每次可能不同。加示例、加约束、把任务拆细，通常能解决。

4.2 模型“假装”完成了任务

问题：让它做数据提取，它输出了一段看起来像结果但实际是编的内容。

排查思路：这是典型的幻觉。检查提示词里有没有“如果信息不足就说不知道”的约束。没有就加上。另外，让它输出结构化格式（比如JSON），并在提示词里明确字段含义，能减少自由发挥的空间。最关键的：输出必须用脚本或人工验证，不能因为它格式工整就信任。

4.3 长文档处理丢信息

问题：把长文档塞进去，问细节问题，模型答不上来或答错。

排查思路：先确认信息在文档里的位置。如果在中间，很可能被“中间遗忘”效应影响。解法有两个：一是把关键信息摘出来单独问；二是分段处理，每段单独提问再汇总。如果文档特别长，考虑先做一轮摘要，再基于摘要提问。

4.4 多轮对话跑偏

问题：聊了几轮之后，模型忘了最初的约束，开始自由发挥。

排查思路：多轮对话里，早期信息会被后续内容稀释。我的做法是每轮都把关键约束重新贴一遍，或者在系统提示词里写死不可违背的规则。另外，对话轮次多了之后，考虑开新会话，把必要上下文手动带过去，比让它“记住”更可靠。

4.5 常见问题速查表

4.6 几条踩坑换来的经验

经验一：不要用模型验证模型。我试过让一个模型生成、另一个模型审核，结果两个模型一起幻觉，互相“确认”了错误答案。验证必须用外部工具或人工。

经验二：提示词里的否定句要小心。“不要输出markdown”这种否定指令，模型有时候会理解反。更好的做法是正面描述你要什么：“输出纯文本，不要任何格式符号”。

经验三：示例比形容词管用。你说“输出要专业”，模型不知道什么叫专业；你给一个专业输出的例子，它立刻就能模仿。写提示词的时间，一半花在找好例子上。

经验四：关键任务做双跑对比。同一个任务跑两次，对比输出差异。差异大的地方就是模型不确定的地方，重点核查。

经验五：记录失败案例。我有个文档专门记模型翻车的案例，定期回顾。这些案例比成功案例更有价值，它们标出了能力边界的具体位置。

5. 把LLM放进系统里：工程视角的补充

5.1 智能体不是万能药

热词里“LLM智能体自主容错控制”很火，我说点冷静的。智能体的本质是让模型在循环里调用工具、观察结果、决定下一步。它能处理一些需要多步操作的任务，但它的可靠性受限于底层模型的能力边界。模型会幻觉，智能体就会调用错误的工具；模型会遗忘，智能体就会在长流程里跑偏。

我的建议是：智能体适合任务边界清晰、工具返回值明确、失败可回滚的场景。比如“查天气然后发邮件”这种，失败了重来就行。但“自主控制生产系统”这种，容错设计必须做在模型之外，不能指望模型自己容错。

5.2 数据标注的质量决定微调上限

“LLM怎么数据标注”也是高频问题。我的经验是：微调的效果，七分看数据，三分看参数。标注数据要满足几个条件：任务定义清晰、标注标准一致、覆盖边界情况、有负样本。

特别提醒：不要用模型自动标注的数据直接微调，除非你做了严格的人工抽检。模型标注会引入它自己的偏差和幻觉，微调之后这些偏差会被放大。我见过用模型标注数据微调，结果模型学会了“自信地胡说”的案例。

5.3 配置管理别用YAML硬扛

“大语言模型是不是主流用yaml提供配置参数”这个问题，我的看法是：YAML适合简单配置，但LLM应用的配置往往很复杂——提示词模板、模型参数、工具定义、检索策略、路由规则。全塞YAML里，维护起来很痛苦。

我的做法是：简单参数用YAML，复杂逻辑用代码。提示词模板单独放文件，版本化管理；模型参数用配置类管理；工具定义用代码注册。这样改起来清晰，也方便做测试。

6. 最后聊几句个人体会

我用LLM做开发辅助、文档处理、知识问答有一段时间了，最大的体会是：把它当成一个能力很强但需要监督的实习生，而不是一个可以完全托付的专家。它能在几秒内给你一个80分的初稿，但最后那20分——事实核查、逻辑校验、边界处理——必须你自己来。

另一个体会是：理解局限比掌握技巧更重要。技巧会过时，模型会更新，但“下一词预测”这个底层机制带来的局限是结构性的，不会因为模型变大就消失。你越清楚它在哪里会翻车，就越能设计出可靠的系统。

最后一个实用建议：建一个自己的测试集。收集二三十个你业务场景里的典型问题，每次换模型、改提示词、调参数，都跑一遍这个测试集，对比结果。这比看任何榜单都靠谱，因为它是你自己的场景、你自己的标准。