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 常见问题速查表现象可能原因快速排查解决方向输出随机温度高/提示歧义看温度参数降温、加示例编造内容幻觉/无约束查提示词约束加“不知道就说不知道”长文丢信息中间遗忘定位信息位置摘取、分段、摘要多轮跑偏上下文稀释看轮次重贴约束、开新会话算术出错机制限制复算外接计算工具格式不对指令模糊看输出格式要求给JSON示例4.6 几条踩坑换来的经验经验一不要用模型验证模型。我试过让一个模型生成、另一个模型审核结果两个模型一起幻觉互相“确认”了错误答案。验证必须用外部工具或人工。经验二提示词里的否定句要小心。“不要输出markdown”这种否定指令模型有时候会理解反。更好的做法是正面描述你要什么“输出纯文本不要任何格式符号”。经验三示例比形容词管用。你说“输出要专业”模型不知道什么叫专业你给一个专业输出的例子它立刻就能模仿。写提示词的时间一半花在找好例子上。经验四关键任务做双跑对比。同一个任务跑两次对比输出差异。差异大的地方就是模型不确定的地方重点核查。经验五记录失败案例。我有个文档专门记模型翻车的案例定期回顾。这些案例比成功案例更有价值它们标出了能力边界的具体位置。5. 把LLM放进系统里工程视角的补充5.1 智能体不是万能药热词里“LLM智能体自主容错控制”很火我说点冷静的。智能体的本质是让模型在循环里调用工具、观察结果、决定下一步。它能处理一些需要多步操作的任务但它的可靠性受限于底层模型的能力边界。模型会幻觉智能体就会调用错误的工具模型会遗忘智能体就会在长流程里跑偏。我的建议是智能体适合任务边界清晰、工具返回值明确、失败可回滚的场景。比如“查天气然后发邮件”这种失败了重来就行。但“自主控制生产系统”这种容错设计必须做在模型之外不能指望模型自己容错。5.2 数据标注的质量决定微调上限“LLM怎么数据标注”也是高频问题。我的经验是微调的效果七分看数据三分看参数。标注数据要满足几个条件任务定义清晰、标注标准一致、覆盖边界情况、有负样本。特别提醒不要用模型自动标注的数据直接微调除非你做了严格的人工抽检。模型标注会引入它自己的偏差和幻觉微调之后这些偏差会被放大。我见过用模型标注数据微调结果模型学会了“自信地胡说”的案例。5.3 配置管理别用YAML硬扛“大语言模型是不是主流用yaml提供配置参数”这个问题我的看法是YAML适合简单配置但LLM应用的配置往往很复杂——提示词模板、模型参数、工具定义、检索策略、路由规则。全塞YAML里维护起来很痛苦。我的做法是简单参数用YAML复杂逻辑用代码。提示词模板单独放文件版本化管理模型参数用配置类管理工具定义用代码注册。这样改起来清晰也方便做测试。6. 最后聊几句个人体会我用LLM做开发辅助、文档处理、知识问答有一段时间了最大的体会是把它当成一个能力很强但需要监督的实习生而不是一个可以完全托付的专家。它能在几秒内给你一个80分的初稿但最后那20分——事实核查、逻辑校验、边界处理——必须你自己来。另一个体会是理解局限比掌握技巧更重要。技巧会过时模型会更新但“下一词预测”这个底层机制带来的局限是结构性的不会因为模型变大就消失。你越清楚它在哪里会翻车就越能设计出可靠的系统。最后一个实用建议建一个自己的测试集。收集二三十个你业务场景里的典型问题每次换模型、改提示词、调参数都跑一遍这个测试集对比结果。这比看任何榜单都靠谱因为它是你自己的场景、你自己的标准。