1. 先想清楚一件事你学大模型是为了“会用”还是“会造”2026年的技术社区你随便打开一个学习平台满屏都是大模型相关的教程讲Prompt的、讲RAG的、讲Agent的还有讲微调、讲私有化部署、讲知识库选型的。看起来极其繁荣但繁荣背后有一个特别现实的问题——大多数人其实没想清楚自己为什么要学就开始跟着热门榜单往下刷。我见过太多这样的案例一个做运营的同学听说Prompt Engineering很火花了三周把各种提示词技巧背了一遍结果发现工作中根本用不上几个一个做后端开发的同事一上来就啃Agent框架源码连大模型API的token计费逻辑都没搞明白最后卡在工具调用的鉴权上进退两难。这些问题的根源不是教程不好而是学习路线跟个人目标错配了。所以在聊“先学什么”之前我建议你先回答一个问题你学大模型到底是为了“会用”还是为了“会造”“会用”的人目标是把大模型嵌入到自己的工作流里比如用Prompt提升写作效率、用RAG搭建一个公司内部的知识库问答机器人、用现成的Agent框架做一个自动化流程助手。这类人不需要从底层数学原理学起核心是把“怎么调模型、怎么搭链路、怎么评估效果”搞清楚。“会造”的人目标是自己能做产品、做系统甚至是要在大模型相关岗位上就业。这类人除了会调还得理解大模型的推理机制、RAG的检索链路为什么这样设计、Agent的规划与工具调用之间怎么协作以及上下文长度、微调、部署这些底层问题。这两个方向的学习顺序其实是相反的。前者我会建议从Prompt入手快速见效建立正反馈后者我会建议先补大模型基础理论和API调用的基本功然后再往RAG和Agent纵深走。这篇盘点我就是按这个逻辑来拆的。1.1 教程爆炸时代的典型误区学完Prompt就去投简历热搜词里那个“prompt闪退”很有意思。很多人以为Prompt就是写几句“请帮我……”的指令结果在实际调用大模型API时稍微复杂一点的prompt就会触发“invalid prompt: your prompt was flagged as potentially violating our usage p…”这类报错。这不是模型坏了而是你的prompt触发了内容安全过滤或者格式不符合API的输入要求。这说明一个很扎心的事实网上大量Prompt教程教的“万能公式”放到真实业务场景里根本不够用。因为它没告诉你token怎么算、上下文窗口怎么管理、API的system/user/assistant角色怎么设计、流式输出怎么处理报错。学Prompt不是学话术是学“和模型打交道的系统工程”。我见过简历上写着“精通Prompt Engineering”的候选人结果面试官问了一个很基础的问题“你的prompt里temperature和top_p分别控制什么如果我想让模型输出更稳定该调哪个”对方沉默了。这就是典型的“会背公式但不理解本质”。1.2 用“目标倒推路线”代替“从兴趣出发”我自己的经验是学习大模型最有效的方式不是按技术栈从前到后学而是拿一个真实项目倒推需要学什么。举个例子你想给团队做一个“内部文档问答机器人”。这个需求拆下来你需要掌握的是怎么调用大模型API免费的或付费的至少要知道怎么发请求、怎么处理返回怎么把文档切分、向量化这是RAG的起点怎么搭一个简单的检索链路向量检索加关键字检索怎么把检索结果和Prompt拼起来让模型基于文档回答这又回到Prompt了怎么评估回答质量引用是否准确、幻觉多不多你看一个“小项目”就把Prompt、RAG、API调用、评估串起来了而且学习动机非常明确——每个环节都是解决当前问题所必需的。反过来如果你只是照着教程把RAG跑通一遍很可能跑完就忘因为你不理解每一步为什么要这么做。1.3 三条路线的适用人群对照为了让你更清楚自己该走哪条线我把Prompt、RAG、Agent三条路线的学习目标和适用人群先列个对照表。后面每个章节再展开讲。方向核心解决什么问题适合谁先学学习周期参考最终产出示例Prompt让模型输出更符合预期所有人尤其是非技术背景同学2-4周可上手写作助手、数据分析Prompt模板RAG让模型基于你的私有知识回答有文档管理需求的职场人、后端/算法工程师4-8周可上手知识库问答机器人、客服辅助系统Agent让模型自主完成任务、调用工具有一定编程基础、想做自动化产品的人8周以上自动化流程助手、智能客服Agent表里的周期只是参考不是绝对。但有一点很确定别跳级。我见过太多人连RAG检索质量都没调明白就冲去学Agent最后做出来的东西看着很炫一问细节就漏洞百出。2. Prompt Engineering入门最友好但要清醒看待它的天花板先说结论Prompt是所有人的第一课但它只是第一课不是终点。2026年这个时间点上关于Prompt的讨论已经从“怎么写指令”进化到了“怎么设计一套可复用、可评估的提示词系统”这一课的价值比你想象的大但也比很多人以为的小。2.1 为什么 Prompt 是所有人的第一课理由很简单这是你和大模型交互的唯一接口其他所有技术——RAG、Agent、微调——最终都要通过Prompt把信息送给模型。哪怕你用现成的框架里面也全是Prompt模板。我见过一个做RAG项目的同学检索链路做得极其漂亮向量库召回率90%以上结果问答效果一塌糊涂。排查到最后问题出在Prompt上——他把检索到的内容原封不动塞进上下文既没告诉模型“请只基于以下文档回答”也没给“如果文档中没有答案就直接说不知道”的边界指令。模型被一堆无关信息干扰自然就胡说八道。这就是Prompt的底层逻辑它本质是“上下文管理”。你不是在“跟模型说话”而是在“给模型搭一个工作环境”。这个环境里要包含角色、任务、背景、约束、示例、输出格式还要预留好“模型答不上来时怎么办”的退路。理解了这一点你会发现网上那些“三句话让AI帮你写周报”的教程确实有用的但天花板也很明显——它只教了“搭环境”的第一层。2.2 从 prompt token 到 invalid prompt我在实际使用中踩过的两个坑热搜词里那个“invalid prompt”报错值得单独拿出来说。我最早在项目里也遇到过当时还以为是自己代码写错了后来排查才发现这类报错主要有三个触发原因内容安全策略prompt里包含了一些被标记为敏感的内容哪怕只是测试数据也会被拒绝。解决方法是先本地测一下哪部分内容触发的或者调整请求参数里的安全设置有些API支持调节安全阈值。格式问题少部分API对prompt的编码、特殊字符、超长文本有额外限制。中文字符在传递时如果没做正确的编码处理也偶尔会出问题。上下文超限prompt加上检索到的文档内容超过了模型上下文长度这时API会直接报错。要养成计算token的习惯别等报错了才回头查。说到token很多人对“prompt token”有个误解以为token数就等于字数。其实一个英文单词大约是1.3个token一个汉字大概是1.5到2个token但不同模型的分词器又不一样。我自己常用的估算方法是英文按“词数×1.3”估中文按“字数×1.6”估然后留出20%的余量。这样可以避免很多“对话到一半突然报错”的尴尬。2.3 Prompt 优化器的使用逻辑热搜词里还有“prompt optimizer使用教程”说明大家已经不满足于手写prompt了。市面上确实有一些prompt优化工具可以帮你自动改进提示词但我用了大半年后的感受是工具能帮你但不能替你思考。prompt优化器的核心逻辑通常是“给模型看你现在写的prompt让它自己提改进建议”本质是让一个更强的模型帮你重构语言表达。它擅长的是把模糊的描述变具体、把缺失的示例补上、把输出格式写清楚。但真正决定效果的是你提供的“业务背景”和“期望行为”。如果这两点你都没想清楚优化器怎么帮你都是白搭。所以我的建议是先用优化器帮你把表达理清楚但最终判断权一定要留给自己。每次修改完prompt之后跑5-10个测试用例对比输出是否符合预期。这不是玄学是工程习惯。3. RAG从“查资料”到“知识治理”瓶颈往往不在模型而在数据如果说Prompt是大模型入门的第一课那RAG检索增强生成就是从“玩具”走向“产品”的必经之路。2026年你还只会调Prompt做点个人效率工具没问题但想给企业做知识库问答、客服辅助、内部文档检索那RAG是绕不开的。但你千万别把RAG想得太简单——它不是“把文档丢进向量库问一句搜一下”。真正投入做RAG之后你会发现最难的往往不是模型不够强而是你的数据根本喂不进去或者喂进去了但检不出来。这也是热搜词里“rag瓶颈”被频繁提起的原因。3.1 RAG 到底解决什么问题为什么它不是简单“把文档塞进向量库”RAG解决的核心痛点是让大模型基于你指定的知识来回答而不是凭它自己的记忆瞎编。举个生活化的例子大模型就像一个知识面很广但对你们公司一无所知的实习生RAG就是把公司的规章制度、产品手册塞给他并规定“回答问题时必须先翻资料没翻到就不许乱说”。但“塞给他”这个动作远比听起来复杂。原始文档的格式五花八门有PDF、Word、Markdown、HTML还有扫码转出来的图片型PDF。你首先要把这些文档解析成纯文本然后切成合适的片段——这一步叫分块Chunking切得好不好直接决定后面能不能被检索到。分块不是按固定字符数硬切。我见过很多新手项目把文档按500字一段切完就完事结果检索效果很差。原因是语义被切断了——一个完整的技术方案可能横跨三四个块提问的时候只搜到其中一部分回答自然不完整。合理的做法是按标题层级、段落结构来切同时保留上下文关联信息。这一步是RAG项目里最琐碎、最不性感、但最影响效果的部分。3.2 rag瓶颈检索质量、上下文窗口与结果重排把“rag瓶颈”拆开看主要卡在三个环节第一是检索质量。向量检索的“语义相似度”并不可靠尤其是遇到专业术语、同义词、多轮问答场景时召回的内容经常跑偏。我在企业项目里就遇到过员工问“报销流程”向量检索召回的结果里居然有“旅费补贴标准”——这两个事有关联但根本不是一回事。解决思路是引入混合检索向量检索加BM25关键字检索两个结果做权重合并能明显提升召回准确率。第二是上下文窗口的限制。即便2026年主流模型的上下文窗口已经很长但把所有检索结果都塞进上下文的做法依然是不可取的——一方面token成本直线上升另一方面模型真的会被“长而无用”的信息干扰。正确做法是给检索结果做重排Re-ranking第一阶段粗召回取出top 20到50条第二阶段用重排模型精挑细选只留最相关的5到8条进入最终上下文。第三是“模型到底有没有用上检索到的内容”。这个问题我是在实际评估中发现的——有时候检索结果明明很准确但模型回答时根本没参考还是凭自己的训练记忆在答。这就要靠Prompt端的约束了也就是我在第二章讲的“上下文管理”。RAG和Prompt不是两个独立的知识点而是同一个链路的两端。3.3 知识库选型KG知识库、RAG知识库和结构化知识库的真实差别热搜词里有“kg知识库、rag知识库和结构知识库区分以及应用场景”这个问题问得很专业也确实是很多人在选型时最纠结的。我用一张表帮你理清楚类型核心存储方式回答问题的逻辑最擅长场景最大的坑RAG知识库向量嵌入语义相似先检索相似片段再让模型生成非结构化文档问答、FAQ、文本类知识检索不准时会答非所问KG知识库知识图谱实体、关系、属性的三元组先查图谱路径再推理“谁和谁什么关系”“哪个零件属于哪套系统”这类多跳关系问题构建图谱成本极高维护困难结构化知识库表格、数据库、Schema约束通过SQL或API精确查询数据统计、精确查询、指标口径写查询逻辑需要工程投入且不支持模糊语义我经常用一个类比来解释三者RAG知识库像一个读书很多的助理你问他什么他翻笔记本回答KG知识库像一个情报分析员他脑子里是人和人、事和事之间的网结构化知识库像一个数据库管理员你问什么他帮你写SQL查表。真实项目里这三者经常要组合用。比如一个企业客服机器人用户问题先走RAG检索产品文档涉及“某型号设备兼容什么接口”这种关系型问题就走KG补链路涉及到价格、库存这类数字直接查结构化数据库最准。2026年的主流实践不是选一个而是多路召回加统一重排。3.4 一个容易被问倒的问题RAG 知识库能存图片吗热搜词里有个很具体的问题——“rag知识库能存储图片嘛”我估计是有人想在知识库里放产品截图和流程图。这个问题的答案分两层第一层从技术上图片本身不能直接塞进常规的向量检索链路。向量模型大多是文本模型它没办法直接对图片做语义嵌入。如果你硬要存得先把图片转成文字描述用多模态模型做图片理解生成描述文字再把描述文字向量化。这样用户提问“图里那个按钮在哪”检索系统找到的是“描述文字”回答时再引用原图展示。这条路可行但图片理解的准确度会直接拖累检索效果。第二层从产品设计上RAG知识库的“图片”通常不是用来检索的而是用来展示的。更靠谱的做法是把图片作为文档的一部分检索时命中对应的文字内容然后把关联的图片作为证据一起输出。比如用户问“怎么导出数据”系统检索到一段说明文字同时把文末的“导出操作截图”一起返回。所以我的建议是别指望RAG直接理解图片但一定要让RAG的输出能携带图片。文本检索是骨架图片是证据展示两者配合才是知识库问答的正确姿势。4. Agent最热也最容易被高估的方向2026年的大模型技术热榜上Agent智能体绝对是最耀眼的那个词。打开招聘网站Agent开发岗位的薪资高得吓人打开技术社区每个人都在聊“让AI自动搞定一切”。但作为一个踩过坑的人我必须先泼一盆冷水Agent是这三条路线里门槛最高、坑最深、最容易被高估的方向。热搜词里那些“agent安全”“harness和agent区别”“agent anywhere”关键词无一不在提醒你这不是一个轻松的方向。4.1 大模型 Agent 的架构真相规划、工具调用、记忆、安全先说清楚Agent是什么。我还是用类比Prompt像是你给实习生单独交代一件事RAG像是你给实习生配了一堆资料Agent则是你给了实习生一套“自主工作权限”——他能自己拆解任务、决定先干什么后干什么、调用各种工具并在过程中不断调整方向。一个完整的Agent架构至少包含四层规划Planning把大任务拆成小步骤。比如“帮我写一份季度总结”Agent要先拆成“收集数据—梳理重点—搭框架—填充内容—润色”等子任务。这一层考验的是模型的推理能力也是Prompt工程最深的延伸。工具调用Tool UseAgent需要访问外部世界包括调用API、查询数据库、执行代码、访问网页。工具调用的工程实现是整个Agent里最复杂的部分——你要定义工具的参数格式、处理调用失败、控制调用次数。记忆MemoryAgent在完成任务过程中需要记住中间状态。短期记忆对话上下文和长期记忆把重要信息存入外部存储的配合决定了Agent能不能在复杂任务中保持一致性。安全与边界Safety这是最容易被新手忽略但上线时最致命的一层。Agent有了“行动能力”之后一旦规划出错或工具调用失控后果比普通问答严重得多。热搜词里“agent安全”的搜索量高说明大家已经开始在真实项目中吃到教训了。我在实际项目里就栽过一回一个自动化运维Agent因为Prompt里的边界条件写得不够死它在处理异常时居然自己给自己下了个“重启服务器”的指令差点酿成事故。从那以后我在Agent里强制加上“只读优先、变更需二次确认”的安全铁律再也没出过同类问题。4.2 harness 和 agent 的区别为什么如此重要热搜词里“harness和agent区别”是个很精细但也非常关键的问题。简单理解Agent是“大脑加手”Harness是“给大脑和手用的操作台和安全笼子”。更准确地说Harness指的是承载Agent运行的框架层它负责管理Agent的生命周期、工具注册、上下文注入、安全策略、日志追踪。你用LangChain、LlamaIndex这类框架开发Agent时你写的那些配置、回调、工具定义、错误处理——这些东西共同组成了Harness。“Agent”是你设计出来的“决策逻辑”“Harness”是让这些逻辑能安全、稳定、可观测地跑起来的“运行环境”。为什么这个区别重要因为很多新手把“搭了个Agent”理解为“写了个Prompt让模型决定下一步干什么”完全忽略了运行环境的复杂度。结果就是本地Demo跑起来很酷一到线上就各种超时、工具调用错乱、日志一片混乱根本没办法维护。真正做Agent项目一半以上的工程时间都花在Harness上而不是Agent本身的“聪明程度”上。4.3 agent安全你不得不在上线前解决的问题我给“agent安全”这个词条补充几个2026年依然有效的实操建议都是我自己做项目时的硬性要求权限最小化Agent能调用的工具权限必须比你自己操作时的权限更小。比如它能查数据库但不能删表它能调用支付接口但不能超过单笔限额。人工确认机制涉及写操作、外部通知、费用产生等动作强制走“人工审批”流程。系统架构上就阻断而不是靠Agent自己判断。预算限制给Agent的API调用设置token上限或费用上限。我见过Agent在一个死循环里反复调用大模型半小时烧掉几百块的案例——预算护栏一定得有。全程日志Agent每一步的决策、每次工具调用的入参和出参全部留痕。否则出了问题根本没法追溯是哪个环节判断错了。你想做Agent项目的心情我特别理解这种“让AI自动干活”的感觉确实上瘾。但请一定把安全设计放在功能开发之前。功能上线出bug可以修安全出问题可能要背处分的。5. 三条路线的学习资源盘点与六步路线图聊完三条路线各自的核心知识点和坑我们来回答那个最初的问题2026年到底该先学什么我的答案很直接按“Prompt → RAG → Agent”的顺序走但每一步都卡着“目标”来学而不是卡着“教程热度”来学。为什么是这个顺序因为这三件事本质上是层层递进的关系。Prompt是你和模型对话的底层能力RAG是让对话“有据可依”的工程化能力Agent是让对话“可行动”的自主能力。跳过底层上高层就像没学会走就跑迟早要摔跟头。5.1 我眼中值得看的教程类型而不是具体链接2026年的教程生态已经非常庞杂我不推荐具体链接因为内容更新太快。我按“值得看”的类型给你筛一遍你按这个标准去挑教程基本不会踩坑学习阶段值得看的教程类型容易踩坑的教程类型怎么分辨Prompt结合具体API文档的实战教程、带错误排查案例的教程只讲“万能公式”的模板教程看有没有真实的输入输出样例有没有报错处理RAG从数据处理讲到检索评估的完整项目教程只演示“跑通demo”就完事的教程看有没有讲分块策略、召回率评估、bad case分析Agent讲清楚架构设计和安全设计的教程只展示“Agent很酷”的成果演示类视频看有没有涉及工具调用失败处理、日志追踪、权限控制通识基础大模型原理科普、token计费、上下文管理类教程过于数学化的学术论文逐篇精读类内容初期别陷入“看不懂”的挫败感里有一个判断标准特别好用看教程有没有讲“失败了怎么办”。只讲成功路径的教程多半是理想化的录制环境讲了报错、讲了坑、讲了解法才是真实项目里沉淀出来的经验。这也是我写这篇盘点时特别刻意坚持的一件事。5.2 按岗位/目标给出的具体学习顺序光说大方向还不够我给三类典型目标分别排一个更具体的学习顺序目标一做个人效率工具比如写作助手、信息整理机器人学习顺序Prompt基础 → API调用与token管理 → 上下文管理 → 简单的文档检索轻量RAG→ 用现成Agent框架做个人自动化。这一类目标其实不需要深入学Agent开发。你甚至不一定需要搭一个RAG系统——很多场景用“Prompt里塞少量上下文”就能解决。目标二给企业做知识库问答比如客服辅助、内部文档检索学习顺序Prompt基础 → API调用 → 文档解析与分块 → 向量库选型 → 混合检索 → 重排与评估 → RAG的瓶颈排查 → 多模态知识库拓展。这一类目标是2026年企业落地最密集的场景学完RAG链路基本就够用了。Agent不是必须但如果要做成“自动回答主动追问”的形态可以再往Agent方向延伸。目标三做Agent产品比如自动化流程助手、智能体应用学习顺序Prompt基础 → API调用 → RAG基础因为Agent经常需要检索知识→ 工具调用原理与实现 → 框架选型LangChain/LlamaIndex等→ Harness设计 → 安全与权限控制 → 多Agent协作。这条路最难但也是2026年最稀缺的能力。你可以先走完前两步再做一两个RAG项目练手最后全力冲Agent。5.3 大模型基础理论、微调与部署放到哪里学热搜词里还有“ai大模型基础理论”“大模型微调”“企业大模型私有化部署”“ollma部署大模型”这些也是2026年大家关注的方向。我在这个章节里针对性地给两条建议第一基础理论值得补但别掉进数学深渊。你不需要从Transformer的注意力机制公式推导开始学也能做好Prompt和RAG项目。真正对你日常有用的基础理论是token与分词逻辑、上下文窗口、temperature/top_p这类采样参数、幻觉产生的原因、模型能力边界什么它能做什么它不能做。这些知识点可以在做项目的过程中按需补比单纯啃书效率高很多。第二微调和部署是“进阶选修课”不是“新手必修课”。尤其是2026年开源模型的API化已经很成熟90%以上的场景用API加RAG就能解决不必自己去微调。判断标准就一条API模型在你的业务数据上表现不够好且Prompt和RAG怎么调都不行这时候才考虑微调。同理私有化部署也看需求——如果你的数据合规要求严、必须内网运行再学部署否则用现成API是性价比更高的选择。6. 最后再聊几个热点话题与常见问题这部分算是我根据自己项目经验和观察把一些热搜词里的高频问题集中回答一遍。如果你时间有限可以直接看自己关心的那几条。6.1 企业大模型私有化部署与免费大模型API的选择问题不少同学私信问过中小企业想做AI功能到底是掏钱买大模型API还是搞一套私有化部署我的看法很务实先用免费或低价API跑通流程再按需升级不建议一上来就搞私有化部署。免费大模型API在2026年已经具备不错的文本能力用来做Prompt练习、RAG原型验证完全够用。但注意几个坑免费接口的速率限制很严、上下文长度通常较短、敏感数据不能走外部服务。当你验证完毕、要上生产时再根据合规要求决定是买商用API还是私有化部署。“ollma部署大模型”这个热搜词对应的Ollama等本地部署工具我也玩过体验确实友好适合在本地做开发调试。但本地跑小模型和线上用大模型效果差距还是很明显的。把Ollama当开发调试工具没问题当生产主力方案的话建议先评估模型能力是否满足业务要求。6.2 “大模型微调”和“RAG”是不是二选一这个问题几乎每周都有人问。我的回答就一句不是二选一多数情况下先RAG不够再微调两者可以共存。两者解决的问题不同RAG是给模型“外挂知识”对“事实类问答、文档引用类场景”效果立竿见影微调是改变模型的“行为风格、输出结构、领域语言习惯”对“让模型用你们家的口吻说话、按固定格式出报告、识别特定领域的行话”更有效。我做过一个法律咨询项目最初只做RAG结果模型回答内容能引用对法条但语气像“教科书”不像“律师”用户接受度不高。后面做了微调让模型模仿律师的措辞和推理风格再加上RAG做事实供给效果才真正达标。RAG管事实准确性微调管表达风格组合拳才是大模型落地的常态。6.3 适合新手的三个“第一次”项目练习你要是看完前面内容还是不知道从哪里下手我直接给你三个可以照着练的“第一次”项目难度递增每个都能覆盖到前面讲的核心知识点项目一个人周报生成器练Prompt和API调用输入一周的工作记录。输出结构化周报。要求用system prompt设定“周报撰写专家”角色用few-shot示例规范格式摸清temperature对输出稳定性的影响。项目二团队文档问答机器人练完整RAG链路选一个自己团队的文档库比如产品说明、FAQ走完“解析—分块—向量化—检索—重排—Prompt生成—评估”全流程。目标不是“跑通”而是让回答能做到“引用原文出处”。项目三带工具调用的个人助理Agent练Agent和Harness给Agent挂两个工具查天气API和查待办列表。让Agent根据用户指令自主决定调用哪个工具。练的重点不是功能多复杂而是搞清楚“Agent怎么拆解任务、工具调用失败怎么处理、日志怎么追踪”。这三个项目做完你对大模型的基础理解和工程手感应该比90%的“教程收藏家”强了。最后再分享一个我自己的体会大模型这个领域2025年大家还在聊“技术有多强”2026年基本都在聊“怎么落地、怎么稳定、怎么不出错”。这其实是整个行业走向成熟的标志。你学习的时候也别忘了切换心态——不要追求会多少花哨的技术名词而是要能把一条链路从Prompt写到安全边界端到端跑通、跑稳。那些收藏了几十个教程却一个项目没做完的人六个月后依然在收藏把一个小项目反复打磨三遍的人六个月后已经在产出真实价值了。你是哪种自己选。
1. 先想清楚一件事你学大模型是为了“会用”还是“会造”2026年的技术社区你随便打开一个学习平台满屏都是大模型相关的教程讲Prompt的、讲RAG的、讲Agent的还有讲微调、讲私有化部署、讲知识库选型的。看起来极其繁荣但繁荣背后有一个特别现实的问题——大多数人其实没想清楚自己为什么要学就开始跟着热门榜单往下刷。我见过太多这样的案例一个做运营的同学听说Prompt Engineering很火花了三周把各种提示词技巧背了一遍结果发现工作中根本用不上几个一个做后端开发的同事一上来就啃Agent框架源码连大模型API的token计费逻辑都没搞明白最后卡在工具调用的鉴权上进退两难。这些问题的根源不是教程不好而是学习路线跟个人目标错配了。所以在聊“先学什么”之前我建议你先回答一个问题你学大模型到底是为了“会用”还是为了“会造”“会用”的人目标是把大模型嵌入到自己的工作流里比如用Prompt提升写作效率、用RAG搭建一个公司内部的知识库问答机器人、用现成的Agent框架做一个自动化流程助手。这类人不需要从底层数学原理学起核心是把“怎么调模型、怎么搭链路、怎么评估效果”搞清楚。“会造”的人目标是自己能做产品、做系统甚至是要在大模型相关岗位上就业。这类人除了会调还得理解大模型的推理机制、RAG的检索链路为什么这样设计、Agent的规划与工具调用之间怎么协作以及上下文长度、微调、部署这些底层问题。这两个方向的学习顺序其实是相反的。前者我会建议从Prompt入手快速见效建立正反馈后者我会建议先补大模型基础理论和API调用的基本功然后再往RAG和Agent纵深走。这篇盘点我就是按这个逻辑来拆的。1.1 教程爆炸时代的典型误区学完Prompt就去投简历热搜词里那个“prompt闪退”很有意思。很多人以为Prompt就是写几句“请帮我……”的指令结果在实际调用大模型API时稍微复杂一点的prompt就会触发“invalid prompt: your prompt was flagged as potentially violating our usage p…”这类报错。这不是模型坏了而是你的prompt触发了内容安全过滤或者格式不符合API的输入要求。这说明一个很扎心的事实网上大量Prompt教程教的“万能公式”放到真实业务场景里根本不够用。因为它没告诉你token怎么算、上下文窗口怎么管理、API的system/user/assistant角色怎么设计、流式输出怎么处理报错。学Prompt不是学话术是学“和模型打交道的系统工程”。我见过简历上写着“精通Prompt Engineering”的候选人结果面试官问了一个很基础的问题“你的prompt里temperature和top_p分别控制什么如果我想让模型输出更稳定该调哪个”对方沉默了。这就是典型的“会背公式但不理解本质”。1.2 用“目标倒推路线”代替“从兴趣出发”我自己的经验是学习大模型最有效的方式不是按技术栈从前到后学而是拿一个真实项目倒推需要学什么。举个例子你想给团队做一个“内部文档问答机器人”。这个需求拆下来你需要掌握的是怎么调用大模型API免费的或付费的至少要知道怎么发请求、怎么处理返回怎么把文档切分、向量化这是RAG的起点怎么搭一个简单的检索链路向量检索加关键字检索怎么把检索结果和Prompt拼起来让模型基于文档回答这又回到Prompt了怎么评估回答质量引用是否准确、幻觉多不多你看一个“小项目”就把Prompt、RAG、API调用、评估串起来了而且学习动机非常明确——每个环节都是解决当前问题所必需的。反过来如果你只是照着教程把RAG跑通一遍很可能跑完就忘因为你不理解每一步为什么要这么做。1.3 三条路线的适用人群对照为了让你更清楚自己该走哪条线我把Prompt、RAG、Agent三条路线的学习目标和适用人群先列个对照表。后面每个章节再展开讲。方向核心解决什么问题适合谁先学学习周期参考最终产出示例Prompt让模型输出更符合预期所有人尤其是非技术背景同学2-4周可上手写作助手、数据分析Prompt模板RAG让模型基于你的私有知识回答有文档管理需求的职场人、后端/算法工程师4-8周可上手知识库问答机器人、客服辅助系统Agent让模型自主完成任务、调用工具有一定编程基础、想做自动化产品的人8周以上自动化流程助手、智能客服Agent表里的周期只是参考不是绝对。但有一点很确定别跳级。我见过太多人连RAG检索质量都没调明白就冲去学Agent最后做出来的东西看着很炫一问细节就漏洞百出。2. Prompt Engineering入门最友好但要清醒看待它的天花板先说结论Prompt是所有人的第一课但它只是第一课不是终点。2026年这个时间点上关于Prompt的讨论已经从“怎么写指令”进化到了“怎么设计一套可复用、可评估的提示词系统”这一课的价值比你想象的大但也比很多人以为的小。2.1 为什么 Prompt 是所有人的第一课理由很简单这是你和大模型交互的唯一接口其他所有技术——RAG、Agent、微调——最终都要通过Prompt把信息送给模型。哪怕你用现成的框架里面也全是Prompt模板。我见过一个做RAG项目的同学检索链路做得极其漂亮向量库召回率90%以上结果问答效果一塌糊涂。排查到最后问题出在Prompt上——他把检索到的内容原封不动塞进上下文既没告诉模型“请只基于以下文档回答”也没给“如果文档中没有答案就直接说不知道”的边界指令。模型被一堆无关信息干扰自然就胡说八道。这就是Prompt的底层逻辑它本质是“上下文管理”。你不是在“跟模型说话”而是在“给模型搭一个工作环境”。这个环境里要包含角色、任务、背景、约束、示例、输出格式还要预留好“模型答不上来时怎么办”的退路。理解了这一点你会发现网上那些“三句话让AI帮你写周报”的教程确实有用的但天花板也很明显——它只教了“搭环境”的第一层。2.2 从 prompt token 到 invalid prompt我在实际使用中踩过的两个坑热搜词里那个“invalid prompt”报错值得单独拿出来说。我最早在项目里也遇到过当时还以为是自己代码写错了后来排查才发现这类报错主要有三个触发原因内容安全策略prompt里包含了一些被标记为敏感的内容哪怕只是测试数据也会被拒绝。解决方法是先本地测一下哪部分内容触发的或者调整请求参数里的安全设置有些API支持调节安全阈值。格式问题少部分API对prompt的编码、特殊字符、超长文本有额外限制。中文字符在传递时如果没做正确的编码处理也偶尔会出问题。上下文超限prompt加上检索到的文档内容超过了模型上下文长度这时API会直接报错。要养成计算token的习惯别等报错了才回头查。说到token很多人对“prompt token”有个误解以为token数就等于字数。其实一个英文单词大约是1.3个token一个汉字大概是1.5到2个token但不同模型的分词器又不一样。我自己常用的估算方法是英文按“词数×1.3”估中文按“字数×1.6”估然后留出20%的余量。这样可以避免很多“对话到一半突然报错”的尴尬。2.3 Prompt 优化器的使用逻辑热搜词里还有“prompt optimizer使用教程”说明大家已经不满足于手写prompt了。市面上确实有一些prompt优化工具可以帮你自动改进提示词但我用了大半年后的感受是工具能帮你但不能替你思考。prompt优化器的核心逻辑通常是“给模型看你现在写的prompt让它自己提改进建议”本质是让一个更强的模型帮你重构语言表达。它擅长的是把模糊的描述变具体、把缺失的示例补上、把输出格式写清楚。但真正决定效果的是你提供的“业务背景”和“期望行为”。如果这两点你都没想清楚优化器怎么帮你都是白搭。所以我的建议是先用优化器帮你把表达理清楚但最终判断权一定要留给自己。每次修改完prompt之后跑5-10个测试用例对比输出是否符合预期。这不是玄学是工程习惯。3. RAG从“查资料”到“知识治理”瓶颈往往不在模型而在数据如果说Prompt是大模型入门的第一课那RAG检索增强生成就是从“玩具”走向“产品”的必经之路。2026年你还只会调Prompt做点个人效率工具没问题但想给企业做知识库问答、客服辅助、内部文档检索那RAG是绕不开的。但你千万别把RAG想得太简单——它不是“把文档丢进向量库问一句搜一下”。真正投入做RAG之后你会发现最难的往往不是模型不够强而是你的数据根本喂不进去或者喂进去了但检不出来。这也是热搜词里“rag瓶颈”被频繁提起的原因。3.1 RAG 到底解决什么问题为什么它不是简单“把文档塞进向量库”RAG解决的核心痛点是让大模型基于你指定的知识来回答而不是凭它自己的记忆瞎编。举个生活化的例子大模型就像一个知识面很广但对你们公司一无所知的实习生RAG就是把公司的规章制度、产品手册塞给他并规定“回答问题时必须先翻资料没翻到就不许乱说”。但“塞给他”这个动作远比听起来复杂。原始文档的格式五花八门有PDF、Word、Markdown、HTML还有扫码转出来的图片型PDF。你首先要把这些文档解析成纯文本然后切成合适的片段——这一步叫分块Chunking切得好不好直接决定后面能不能被检索到。分块不是按固定字符数硬切。我见过很多新手项目把文档按500字一段切完就完事结果检索效果很差。原因是语义被切断了——一个完整的技术方案可能横跨三四个块提问的时候只搜到其中一部分回答自然不完整。合理的做法是按标题层级、段落结构来切同时保留上下文关联信息。这一步是RAG项目里最琐碎、最不性感、但最影响效果的部分。3.2 rag瓶颈检索质量、上下文窗口与结果重排把“rag瓶颈”拆开看主要卡在三个环节第一是检索质量。向量检索的“语义相似度”并不可靠尤其是遇到专业术语、同义词、多轮问答场景时召回的内容经常跑偏。我在企业项目里就遇到过员工问“报销流程”向量检索召回的结果里居然有“旅费补贴标准”——这两个事有关联但根本不是一回事。解决思路是引入混合检索向量检索加BM25关键字检索两个结果做权重合并能明显提升召回准确率。第二是上下文窗口的限制。即便2026年主流模型的上下文窗口已经很长但把所有检索结果都塞进上下文的做法依然是不可取的——一方面token成本直线上升另一方面模型真的会被“长而无用”的信息干扰。正确做法是给检索结果做重排Re-ranking第一阶段粗召回取出top 20到50条第二阶段用重排模型精挑细选只留最相关的5到8条进入最终上下文。第三是“模型到底有没有用上检索到的内容”。这个问题我是在实际评估中发现的——有时候检索结果明明很准确但模型回答时根本没参考还是凭自己的训练记忆在答。这就要靠Prompt端的约束了也就是我在第二章讲的“上下文管理”。RAG和Prompt不是两个独立的知识点而是同一个链路的两端。3.3 知识库选型KG知识库、RAG知识库和结构化知识库的真实差别热搜词里有“kg知识库、rag知识库和结构知识库区分以及应用场景”这个问题问得很专业也确实是很多人在选型时最纠结的。我用一张表帮你理清楚类型核心存储方式回答问题的逻辑最擅长场景最大的坑RAG知识库向量嵌入语义相似先检索相似片段再让模型生成非结构化文档问答、FAQ、文本类知识检索不准时会答非所问KG知识库知识图谱实体、关系、属性的三元组先查图谱路径再推理“谁和谁什么关系”“哪个零件属于哪套系统”这类多跳关系问题构建图谱成本极高维护困难结构化知识库表格、数据库、Schema约束通过SQL或API精确查询数据统计、精确查询、指标口径写查询逻辑需要工程投入且不支持模糊语义我经常用一个类比来解释三者RAG知识库像一个读书很多的助理你问他什么他翻笔记本回答KG知识库像一个情报分析员他脑子里是人和人、事和事之间的网结构化知识库像一个数据库管理员你问什么他帮你写SQL查表。真实项目里这三者经常要组合用。比如一个企业客服机器人用户问题先走RAG检索产品文档涉及“某型号设备兼容什么接口”这种关系型问题就走KG补链路涉及到价格、库存这类数字直接查结构化数据库最准。2026年的主流实践不是选一个而是多路召回加统一重排。3.4 一个容易被问倒的问题RAG 知识库能存图片吗热搜词里有个很具体的问题——“rag知识库能存储图片嘛”我估计是有人想在知识库里放产品截图和流程图。这个问题的答案分两层第一层从技术上图片本身不能直接塞进常规的向量检索链路。向量模型大多是文本模型它没办法直接对图片做语义嵌入。如果你硬要存得先把图片转成文字描述用多模态模型做图片理解生成描述文字再把描述文字向量化。这样用户提问“图里那个按钮在哪”检索系统找到的是“描述文字”回答时再引用原图展示。这条路可行但图片理解的准确度会直接拖累检索效果。第二层从产品设计上RAG知识库的“图片”通常不是用来检索的而是用来展示的。更靠谱的做法是把图片作为文档的一部分检索时命中对应的文字内容然后把关联的图片作为证据一起输出。比如用户问“怎么导出数据”系统检索到一段说明文字同时把文末的“导出操作截图”一起返回。所以我的建议是别指望RAG直接理解图片但一定要让RAG的输出能携带图片。文本检索是骨架图片是证据展示两者配合才是知识库问答的正确姿势。4. Agent最热也最容易被高估的方向2026年的大模型技术热榜上Agent智能体绝对是最耀眼的那个词。打开招聘网站Agent开发岗位的薪资高得吓人打开技术社区每个人都在聊“让AI自动搞定一切”。但作为一个踩过坑的人我必须先泼一盆冷水Agent是这三条路线里门槛最高、坑最深、最容易被高估的方向。热搜词里那些“agent安全”“harness和agent区别”“agent anywhere”关键词无一不在提醒你这不是一个轻松的方向。4.1 大模型 Agent 的架构真相规划、工具调用、记忆、安全先说清楚Agent是什么。我还是用类比Prompt像是你给实习生单独交代一件事RAG像是你给实习生配了一堆资料Agent则是你给了实习生一套“自主工作权限”——他能自己拆解任务、决定先干什么后干什么、调用各种工具并在过程中不断调整方向。一个完整的Agent架构至少包含四层规划Planning把大任务拆成小步骤。比如“帮我写一份季度总结”Agent要先拆成“收集数据—梳理重点—搭框架—填充内容—润色”等子任务。这一层考验的是模型的推理能力也是Prompt工程最深的延伸。工具调用Tool UseAgent需要访问外部世界包括调用API、查询数据库、执行代码、访问网页。工具调用的工程实现是整个Agent里最复杂的部分——你要定义工具的参数格式、处理调用失败、控制调用次数。记忆MemoryAgent在完成任务过程中需要记住中间状态。短期记忆对话上下文和长期记忆把重要信息存入外部存储的配合决定了Agent能不能在复杂任务中保持一致性。安全与边界Safety这是最容易被新手忽略但上线时最致命的一层。Agent有了“行动能力”之后一旦规划出错或工具调用失控后果比普通问答严重得多。热搜词里“agent安全”的搜索量高说明大家已经开始在真实项目中吃到教训了。我在实际项目里就栽过一回一个自动化运维Agent因为Prompt里的边界条件写得不够死它在处理异常时居然自己给自己下了个“重启服务器”的指令差点酿成事故。从那以后我在Agent里强制加上“只读优先、变更需二次确认”的安全铁律再也没出过同类问题。4.2 harness 和 agent 的区别为什么如此重要热搜词里“harness和agent区别”是个很精细但也非常关键的问题。简单理解Agent是“大脑加手”Harness是“给大脑和手用的操作台和安全笼子”。更准确地说Harness指的是承载Agent运行的框架层它负责管理Agent的生命周期、工具注册、上下文注入、安全策略、日志追踪。你用LangChain、LlamaIndex这类框架开发Agent时你写的那些配置、回调、工具定义、错误处理——这些东西共同组成了Harness。“Agent”是你设计出来的“决策逻辑”“Harness”是让这些逻辑能安全、稳定、可观测地跑起来的“运行环境”。为什么这个区别重要因为很多新手把“搭了个Agent”理解为“写了个Prompt让模型决定下一步干什么”完全忽略了运行环境的复杂度。结果就是本地Demo跑起来很酷一到线上就各种超时、工具调用错乱、日志一片混乱根本没办法维护。真正做Agent项目一半以上的工程时间都花在Harness上而不是Agent本身的“聪明程度”上。4.3 agent安全你不得不在上线前解决的问题我给“agent安全”这个词条补充几个2026年依然有效的实操建议都是我自己做项目时的硬性要求权限最小化Agent能调用的工具权限必须比你自己操作时的权限更小。比如它能查数据库但不能删表它能调用支付接口但不能超过单笔限额。人工确认机制涉及写操作、外部通知、费用产生等动作强制走“人工审批”流程。系统架构上就阻断而不是靠Agent自己判断。预算限制给Agent的API调用设置token上限或费用上限。我见过Agent在一个死循环里反复调用大模型半小时烧掉几百块的案例——预算护栏一定得有。全程日志Agent每一步的决策、每次工具调用的入参和出参全部留痕。否则出了问题根本没法追溯是哪个环节判断错了。你想做Agent项目的心情我特别理解这种“让AI自动干活”的感觉确实上瘾。但请一定把安全设计放在功能开发之前。功能上线出bug可以修安全出问题可能要背处分的。5. 三条路线的学习资源盘点与六步路线图聊完三条路线各自的核心知识点和坑我们来回答那个最初的问题2026年到底该先学什么我的答案很直接按“Prompt → RAG → Agent”的顺序走但每一步都卡着“目标”来学而不是卡着“教程热度”来学。为什么是这个顺序因为这三件事本质上是层层递进的关系。Prompt是你和模型对话的底层能力RAG是让对话“有据可依”的工程化能力Agent是让对话“可行动”的自主能力。跳过底层上高层就像没学会走就跑迟早要摔跟头。5.1 我眼中值得看的教程类型而不是具体链接2026年的教程生态已经非常庞杂我不推荐具体链接因为内容更新太快。我按“值得看”的类型给你筛一遍你按这个标准去挑教程基本不会踩坑学习阶段值得看的教程类型容易踩坑的教程类型怎么分辨Prompt结合具体API文档的实战教程、带错误排查案例的教程只讲“万能公式”的模板教程看有没有真实的输入输出样例有没有报错处理RAG从数据处理讲到检索评估的完整项目教程只演示“跑通demo”就完事的教程看有没有讲分块策略、召回率评估、bad case分析Agent讲清楚架构设计和安全设计的教程只展示“Agent很酷”的成果演示类视频看有没有涉及工具调用失败处理、日志追踪、权限控制通识基础大模型原理科普、token计费、上下文管理类教程过于数学化的学术论文逐篇精读类内容初期别陷入“看不懂”的挫败感里有一个判断标准特别好用看教程有没有讲“失败了怎么办”。只讲成功路径的教程多半是理想化的录制环境讲了报错、讲了坑、讲了解法才是真实项目里沉淀出来的经验。这也是我写这篇盘点时特别刻意坚持的一件事。5.2 按岗位/目标给出的具体学习顺序光说大方向还不够我给三类典型目标分别排一个更具体的学习顺序目标一做个人效率工具比如写作助手、信息整理机器人学习顺序Prompt基础 → API调用与token管理 → 上下文管理 → 简单的文档检索轻量RAG→ 用现成Agent框架做个人自动化。这一类目标其实不需要深入学Agent开发。你甚至不一定需要搭一个RAG系统——很多场景用“Prompt里塞少量上下文”就能解决。目标二给企业做知识库问答比如客服辅助、内部文档检索学习顺序Prompt基础 → API调用 → 文档解析与分块 → 向量库选型 → 混合检索 → 重排与评估 → RAG的瓶颈排查 → 多模态知识库拓展。这一类目标是2026年企业落地最密集的场景学完RAG链路基本就够用了。Agent不是必须但如果要做成“自动回答主动追问”的形态可以再往Agent方向延伸。目标三做Agent产品比如自动化流程助手、智能体应用学习顺序Prompt基础 → API调用 → RAG基础因为Agent经常需要检索知识→ 工具调用原理与实现 → 框架选型LangChain/LlamaIndex等→ Harness设计 → 安全与权限控制 → 多Agent协作。这条路最难但也是2026年最稀缺的能力。你可以先走完前两步再做一两个RAG项目练手最后全力冲Agent。5.3 大模型基础理论、微调与部署放到哪里学热搜词里还有“ai大模型基础理论”“大模型微调”“企业大模型私有化部署”“ollma部署大模型”这些也是2026年大家关注的方向。我在这个章节里针对性地给两条建议第一基础理论值得补但别掉进数学深渊。你不需要从Transformer的注意力机制公式推导开始学也能做好Prompt和RAG项目。真正对你日常有用的基础理论是token与分词逻辑、上下文窗口、temperature/top_p这类采样参数、幻觉产生的原因、模型能力边界什么它能做什么它不能做。这些知识点可以在做项目的过程中按需补比单纯啃书效率高很多。第二微调和部署是“进阶选修课”不是“新手必修课”。尤其是2026年开源模型的API化已经很成熟90%以上的场景用API加RAG就能解决不必自己去微调。判断标准就一条API模型在你的业务数据上表现不够好且Prompt和RAG怎么调都不行这时候才考虑微调。同理私有化部署也看需求——如果你的数据合规要求严、必须内网运行再学部署否则用现成API是性价比更高的选择。6. 最后再聊几个热点话题与常见问题这部分算是我根据自己项目经验和观察把一些热搜词里的高频问题集中回答一遍。如果你时间有限可以直接看自己关心的那几条。6.1 企业大模型私有化部署与免费大模型API的选择问题不少同学私信问过中小企业想做AI功能到底是掏钱买大模型API还是搞一套私有化部署我的看法很务实先用免费或低价API跑通流程再按需升级不建议一上来就搞私有化部署。免费大模型API在2026年已经具备不错的文本能力用来做Prompt练习、RAG原型验证完全够用。但注意几个坑免费接口的速率限制很严、上下文长度通常较短、敏感数据不能走外部服务。当你验证完毕、要上生产时再根据合规要求决定是买商用API还是私有化部署。“ollma部署大模型”这个热搜词对应的Ollama等本地部署工具我也玩过体验确实友好适合在本地做开发调试。但本地跑小模型和线上用大模型效果差距还是很明显的。把Ollama当开发调试工具没问题当生产主力方案的话建议先评估模型能力是否满足业务要求。6.2 “大模型微调”和“RAG”是不是二选一这个问题几乎每周都有人问。我的回答就一句不是二选一多数情况下先RAG不够再微调两者可以共存。两者解决的问题不同RAG是给模型“外挂知识”对“事实类问答、文档引用类场景”效果立竿见影微调是改变模型的“行为风格、输出结构、领域语言习惯”对“让模型用你们家的口吻说话、按固定格式出报告、识别特定领域的行话”更有效。我做过一个法律咨询项目最初只做RAG结果模型回答内容能引用对法条但语气像“教科书”不像“律师”用户接受度不高。后面做了微调让模型模仿律师的措辞和推理风格再加上RAG做事实供给效果才真正达标。RAG管事实准确性微调管表达风格组合拳才是大模型落地的常态。6.3 适合新手的三个“第一次”项目练习你要是看完前面内容还是不知道从哪里下手我直接给你三个可以照着练的“第一次”项目难度递增每个都能覆盖到前面讲的核心知识点项目一个人周报生成器练Prompt和API调用输入一周的工作记录。输出结构化周报。要求用system prompt设定“周报撰写专家”角色用few-shot示例规范格式摸清temperature对输出稳定性的影响。项目二团队文档问答机器人练完整RAG链路选一个自己团队的文档库比如产品说明、FAQ走完“解析—分块—向量化—检索—重排—Prompt生成—评估”全流程。目标不是“跑通”而是让回答能做到“引用原文出处”。项目三带工具调用的个人助理Agent练Agent和Harness给Agent挂两个工具查天气API和查待办列表。让Agent根据用户指令自主决定调用哪个工具。练的重点不是功能多复杂而是搞清楚“Agent怎么拆解任务、工具调用失败怎么处理、日志怎么追踪”。这三个项目做完你对大模型的基础理解和工程手感应该比90%的“教程收藏家”强了。最后再分享一个我自己的体会大模型这个领域2025年大家还在聊“技术有多强”2026年基本都在聊“怎么落地、怎么稳定、怎么不出错”。这其实是整个行业走向成熟的标志。你学习的时候也别忘了切换心态——不要追求会多少花哨的技术名词而是要能把一条链路从Prompt写到安全边界端到端跑通、跑稳。那些收藏了几十个教程却一个项目没做完的人六个月后依然在收藏把一个小项目反复打磨三遍的人六个月后已经在产出真实价值了。你是哪种自己选。
