1. 2026年大模型工程师的真实工作画像
先说个我自己观察到的现象：这两年“AI大模型工程师”这个头衔，从猎头朋友圈里的稀缺物种，慢慢变成了各家公司都在挂的岗位。但很多人对这个岗位的理解还是模糊的——以为会调个API、跑个开源模型就算入行了。真到了2026年，这个岗位的门槛和职责范围，已经和两三年前完全是两码事。
我这两年带了几个转岗过来的同事，也面试过不少自称“大模型工程师”的候选人，最大的感受是：这个岗位的核心竞争力根本不是“会用哪个模型”，而是“能不能在真实业务场景里把模型用出价值”。换句话说，你要能回答清楚三个问题：业务要什么、模型能给什么、中间差的这段路怎么补。
先说这个岗位每天到底在干什么。很多人以为大模型工程师是纯算法岗，每天都在调模型、跑实验。实际上在我接触的项目里，工作内容大致是三七开：三成时间在研究模型和算法，七成时间在解决工程问题——数据怎么清洗、推理服务怎么部署、显存不够怎么办、接口响应慢了怎么优化、线上效果波动怎么排查。尤其是2025年下半年之后，很多企业对大模型的需求从“尝鲜”转向“稳定生产”，这个趋势越来越明显。
再一个变化是，大模型工程师的职责边界正在从“单点技术”扩展到“全链路交付”。举几个我实际做过的项目类型：给企业内部知识库做一个基于本地部署模型的问答系统；把一个开源模型微调成某个垂直行业（比如法律文书、医疗客服）的专用模型；把大模型接入现有业务系统，做成能调用工具的智能体；甚至还有做模型安全评估、内容风控、效果回归测试的。每一样都不是单纯的“训练模型”能覆盖的。
这篇文章就是想把我在实际项目里积累的经验整理出来，从技能栈、学习路线、部署实战、微调实践，到应用开发和踩坑记录，给准备入行或者已经在做这个方向的朋友一个参考。我尽量不写那些“报个班就能学会”的空话，只讲真实项目里被验证过的思路和方案。
2. 这个岗位需要什么样的技能栈
2.1 从“会调用”到“能部署”再到“会优化”
2026年的大模型工程师，技能栈是分层的。底层是通用的工程能力，中间是模型相关的专项能力，顶层才是业务落地的综合能力。
底层的工程能力包括：Python编程（这个没有商量余地，大模型生态几乎全在Python上）、Linux操作、Docker容器化、基础的数据处理。这一层是地基，也是很多科班出身的人反而容易忽略的。我见过不止一个算法背景很扎实的候选人，代码写得很漂亮，模型原理讲得头头是道，结果到了服务器上不会看nvidia-smi，不会用docker exec进容器排查问题，部署的时候一个依赖冲突能折腾半小时。这种人在真实项目里会很痛苦。
中间层是模型相关的专项能力。这里面又分几个方向：模型推理部署（用vLLM、Ollama、TensorRT-LLM这些工具把模型跑起来）、模型微调（LoRA、QLoRA、全参数微调）、Prompt工程与上下文管理、RAG（检索增强生成）架构、Agent（智能体）开发。这一层是决定你能不能独立搞定一个需求的关键。
顶层是业务落地能力：需求分析、方案选型、效果评估、成本控制、性能优化。这一层不体现在具体的工具使用上，而是体现在你做决策的时候。比如遇到一个“让模型自动回复客户咨询”的需求，你要能判断：直接调API行不行？还是需要本地部署？用开源模型还是商业模型？需不需要微调？RAG够不够？这一系列决策，才是真正拉开初级和高级工程师差距的地方。
2.2 再聊几个2026年特别吃香的方向
根据我这两年的观察，有几项技能在招聘市场上特别吃香，也代表了大模型工程师的发展方向。
第一个是本地化部署与私有化交付。很多企业（银行、医疗、政企）对数据安全要求极高，模型必须跑在自己的机房或私有云里。这要求工程师熟悉开源模型的部署链路，会处理GPU资源调度、模型量化、推理加速这些事。热词里“本地部署大模型”“ollama部署私有大模型”“大模型部署”这几个方向，对应的就是这个需求。
第二个是AI Agent开发。2025年之后，Agent这个词已经从概念炒作出了实际落地场景。举个例子，我做过一个订单异常处理的Agent，它会接收客服系统中的异常订单告警，自己判断属于哪类问题，调用对应的业务系统API查询订单状态，然后生成处理建议和话术，整个流程不需要人参与。这类开发的核心不在模型本身，而在于怎么设计工具的调用逻辑、怎么管理Agent的多轮上下文、怎么在出错时优雅降级。
第三个是AI应用开发中偏“数据工程”的部分。这里包括知识抽取、数据标注管道、高质量指令数据的构造。热词里的“大模型知识抽取框架”，本质上就是这么个东西——把非结构化的文档内容抽成结构化知识，再灌给RAG系统或者微调用。很多人低估了这部分工作的重要性，实际上一个RAG系统的效果好坏，七成取决于底层的知识库和检索质量，模型本身反而只占三成。
第四个是模型效果评估与安全测试。随着大模型越来越多进入关键业务，企业开始重视“怎么证明这个模型靠谱”。这包括功能评估（回答对不对）、鲁棒性评估（换个问法效果会不会崩）、安全评估（有没有输出违规内容）、性能评估（并发和延迟能不能扛住生产压力）。热词里的“大模型投毒测试”，其实可以归到这一类里。这项工作在正规企业里越来越重要，也是大模型工程师里相对没那么卷、但技术要求不低的方向。
3. 一条可复制的大模型学习路线
3.1 基础阶段：原理补齐到能看懂论文实现
很多想转行的人问我，是不是必须把数学补得很深才能做大模型？我的答案是：如果你是做应用开发和工程化方向的，高中数学加上线代和概率论的基础就够用了，不需要去啃那些证明细节；但如果你是做模型训练和微调优化的，至少得把矩阵运算、梯度下降、注意力机制的原理啃下来。
我自己推荐的路线是这样的：先用大概两周到一个月的时间，把Python基础语法、常用库（Numpy、Pandas、PyTorch）过一遍，能看懂官方教程里的例子就行。然后集中精力搞懂Transformer架构——《Attention Is All You Need》这篇论文值得精读，但更效率的做法是配合PyTorch实现一起看，照着网上那些开源实现敲一遍，理解了多头注意力、位置编码、残差连接这些模块的作用，后面再看其他模型就有种“原来都是套壳”的感觉。
再往后就是看大模型从业者的“标准动作”了：把GPT系列、LLaMA、Qwen这些主流模型的架构差异搞清楚，理解Decode-only结构、KV Cache的作用、上下文窗口的概念。这个阶段不用所有源码都细读，但至少要能画出一个大模型推理时的数据流程图。
3.2 实战阶段：用本地部署撬动整个技术栈
基础理论补完，最好的进阶方式不是继续啃书，而是动手部署一个开源模型。我强烈建议从这个环节切入，因为它会逼着你把整个技术栈都过一遍：装环境、配GPU驱动、拉模型、写请求脚本、调试性能。
我自己在带人的时候，给的第一个任务都是同一个：在本地机器上用一个开源模型（比如Qwen2.5系列的小尺寸版本，InterLM，或者DeepSeek的蒸馏版），跑起一个能聊天的服务。步骤大致是这样：
# 安装 Ollama（一个非常省心的本地模型管理工具） curl -fsSL https://ollama.com/install.sh | sh # 拉取并运行一个轻量模型 ollama pull qwen2.5:7b ollama run qwen2.5:7b跑通之后，紧接着做三件事：第一，把Ollama的模型换成一个更大尺寸的，或者换一个不同架构的模型，感受不同模型在显存占用、生成速度、回答质量上的差异；第二，用Ollama提供的OpenAI兼容API，写一小段Python代码调用模型，实现流式输出和参数控制（temperature、max_tokens、top_p这些）；第三，把服务暴露到局域网里，让另一台机器也能访问，这就算是一个最简的“模型服务”了。
这一步做完，你对“模型是怎么跑起来的”会有非常直观的感知，也对后面理解生产环境里的推理优化打了底。
3.3 进阶阶段：按项目需求补技术短板
基础部署跑通之后，大部分人面临的问题是：不知道下一步学什么。这时候我的建议是“以项目带学习”，找一个你真实感兴趣的小需求，做成一个闭环项目。
比如你对“本地知识库问答”感兴趣，就做一个基于RAG的问答机器人；你对“自动化办公”感兴趣，就做一个能操作Excel、生成周报的Agent；你对“内容创作”感兴趣，就做一个特定风格的写作助手。做这些项目的时候，你会自然而然地用到向量数据库、Embedding模型、LangChain或LlamaIndex、甚至一些Agent框架。过程中会遇到各种问题，解决这些问题的过程就是进步的过程。
另外一个很推荐的进阶路径是去读优质开源项目的源码。我常推荐的有：Qwen和DeepSeek的技术报告、vLLM的推理代码、LlamaIndex的RAG链路代码。不求看懂每一行，但要把核心链路捋清楚——比如vLLM为什么比原生HuggingFace的推理快那么多（核心好在PagedAttention和Continuous Batching），这个问题搞懂了，你对推理优化的理解就超过90%的调包侠了。
4. 大模型部署实战：从选型到上线
4.1 模型选型：先算清楚你手里的牌
部署是每个大模型工程师的基本功。但部署之前，第一件事是选模型——选错了，后面做的都是无用功。我的经验是，选型不要先看“哪个模型最强”，而要先看“你能用什么硬件跑”。
这里有一个简单的显存估算公式：模型推理时需要的显存约等于参数量乘以字节数，再加上KV Cache和激活值的开销。具体来说，如果以FP16精度（每个参数占2字节）跑一个7B模型，光权重就要约14GB显存。再加上KV Cache、PyTorch框架本身的开销，实际需要的显存会在20GB左右。这就是为什么消费级显卡（比如4090有24GB显存）跑7B模型是可行的，但14B模型就很吃力了。
量化可以显著降低这个门槛。4bit量化之后，7B模型的权重只占约3.5GB，加上其他开销，一张12GB显存的显卡也能轻松跑起来。代价是生成的文字质量会有小幅下降，但如果你的业务对语气、格式、创造力要求没那么高，量化后的模型完全够用。
我自己的项目经验是：32GB以内显存优先考虑Qwen2.5-7B/14B或同等规模模型，量化后跑；64GB以上显存可以考虑32B级别的模型（比如Qwen2.5-32B），效果提升明显；企业里有A100/H100这种80GB级别的卡，才可以考虑70B级别的模型。推理能力（数学、代码、复杂逻辑）越强的任务，越依赖大模型，这种提升不是靠调Prompt能弥补的。
4.2 部署工具对比：什么时候用Ollama，什么时候用vLLM
工具选型直接影响后期的运维体验。我主要用的部署工具是这三个，各有各的适用场景。
Ollama适合开发测试和轻量生产。它的最大优势是省心——一条命令装好，一条命令拉模型，自动处理依赖和环境隔离。我带的实习生经常第一天就能把模型跑起来，几乎没有挫败感。但Ollama的并发能力和高级控制较弱，不适合高并发生产场景。
vLLM是生产环境的标配。它的吞吐量比原生HuggingFace推理高出好几倍，而且支持OpenAI兼容的API接口，方便对接业务系统。缺点是配置复杂度高一些，需要自己管理模型文件、处理依赖环境。我这边生产环境的模型服务基本都用vLLM。
如果你想在项目里更深度地定制推理逻辑——比如自己写采样策略、自己管理KV Cache、追求极致性能——那可以直接用HuggingFace的Transformers库写推理脚本。灵活性最高，但代码量和工程成本也最高。
下面给一个vLLM的启动示例，我实际生产里就是这么跑的：
# 安装 vLLM pip install vllm # 启动一个OpenAI兼容的推理服务 python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2.5-7B-Instruct \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --served-model-name qwen \ --port 8000关键参数解释一下：--tensor-parallel-size是多卡并行数，一般等于GPU卡数；--gpu-memory-utilization是允许vLLM使用的显存比例，默认0.9，如果机器上还有其他服务，记得调低；--max-model-len决定最大上下文长度（也就是KV Cache上限），设置得越大，显存占用越高，这也是ChatGPT类产品常常限制上下文长短的原因。
4.3 推理性能调优的几个实用参数
部署完不等于结束，真正的工程挑战在性能调优。这里我分享几个真实项目里验证过的调优点。
第一个是Batch Size和并发控制。vLLM的Continuous Batching机制允许动态批处理，但不是并发越高越好。并发提高会显著增加KV Cache显存占用，而且会让单个请求的响应延迟变高。我一般建议先以最小并发做压测，逐步往上加，找到“吞吐量和延迟的甜蜜点”。
第二个是输入输出长度控制。很多业务场景用户的输入可以很长，但输出长度往往很短（比如分类结果、结构化抽取），这时候调整max-model-len和max-output-tokens能省下大量显存和延时。举个例子，一个做信息抽取的服务，如果把最大输出从4096改成512，显存占用可能下降20%到30%。
第三个是Prompt缓存。很多业务里，系统给模型传入的上下文有很大一部分是固定不变的（比如系统提示词、知识库内容、固定格式要求）。vLLM这类工具支持前缀缓存（prefix caching），命中缓存后能大幅减少重复计算。说得直白点，前后两个请求如果Prompt前缀相同，直接复用之前的推理中间状态，响应能快好几倍。
5. 大模型微调实战：什么时候需要，怎么做
5.1 先判断要不要微调，别一上来就训
微调是热词里出现频率很高的内容，但我必须说句实话：大部分业务场景根本不需要微调。我见过太多团队花几个星期微调模型，最后效果还不如把Prompt设计好一点、把RAG链路做好一点的方案。
什么情况下才需要微调？我的经验是这三类：第一，模型的输出格式有极其严格的约束，且通过Prompt都难以稳定满足（比如要求输出固定JSON schema，且不能有多余内容）；第二，业务有大量私有领域知识，比如企业内部的规则、术语、产品特性，而这些知识很难用几十条Prompt覆盖；第三，希望通过SFT（监督微调）来塑造模型的风格和语气，比如让模型扮演特定角色的客服。
反过来，如果只是希望模型回答得更准确，那大概率应该优化RAG而不是微调。RAG能实时更新知识，成本低、见效快；微调则把知识“写”进了模型的参数里，优点是回答自然，但更新知识要重新训练，成本高，还容易引入灾难性遗忘（新知识学会了，老知识忘了一半）。
5.2 用LoRA做高效微调的关键参数
确定要微调之后，我强烈建议先用LoRA（Low-Rank Adaptation）这类参数高效微调方法跑一轮。它的核心思路是：不改动原始模型的权重，而是在每一层上额外加一个小规模的低秩矩阵来学新任务。相比全参微调，显存占用小至少一个数量级，而且训练速度快好几倍。
我平时习惯用LLaMA-Factory（一个很成熟的开源微调工具）来处理微调任务。一个经典的操作流程长这样：
# 以 LLaMA-Factory 为例，LoRA微调一个对话模型 llamafactory-cli train \ --model_name_or_path /data/models/Qwen2.5-7B-Instruct \ --stage sft \ --dataset alpaca_zh_demo \ --finetuning_type lora \ --lora_rank 32 \ --lora_alpha 64 \ --learning_rate 1e-4 \ --num_train_epochs 3 \ --per_device_train_batch_size 4 \ --gradient_accumulation_steps 4 \ --output_dir ./output/lora_ckpt几个关键参数这里展开讲一下。lora_rank（r）控制低秩矩阵的维度，通俗理解就是“这次微调的容量有多大”。rank太小（比如8）学到的内容少，rank太大（比如128）显存和过拟合风险都会上升。我的经验是，通用对话能力微调用32起步，垂直领域任务微调用16到32，具体可以根据验证集效果调。lora_alpha（α）是缩放系数，它和rank一起决定LoRA权重在最终推理时的影响强度，一般设成rank的2倍问题不大。学习率用1e-4到2e-4，比全参微调的1e-5要高一个量级，因为LoRA只更新一小部分参数，需要更大的学习率才能在有限步数内收敛。
5.3 数据质量决定微调效果的天花板
微调项目里最常踩的坑，不是参数没调好，而是训练数据没做好。我个人的体会是：当微调效果不理想时，90%的概率是数据问题，而不是模型问题。
好的微调数据要满足三个条件。第一，数量不在多而在精。几百条高质量、格式规范的指令数据，效果往往好过几万条从网上随便扒来的对话。第二，数据要和推理时遇到的数据分布一致。如果你部署后的用户问法和训练数据的长相差别很大，模型表现会明显变差。第三，必须有正例也要有负例。模型不仅需要学会“遇到这种情况怎么回答”，还需要学会“遇到那种情况该怎么拒绝或不处理”，否则模型会把所有问题都强行回答。
我自己的一个习惯是，微调前会先人工抽查20%左右的数据，确保格式统一、答案准确。然后先用一个小模型（比如0.5B的）跑一个mini版本，验证数据管道跑得通、loss能降下来，再上大模型正式训练。这样能省下大量因为数据格式错误导致的返工时间。
6. AI Agent与RAG应用开发
6.1 RAG系统：让模型学会“查资料再回答”
RAG（Retrieval-Augmented Generation，检索增强生成）是目前落地率最高的企业级大模型应用模式。它解决的问题非常直接：大模型训练时没见过你公司的内部资料，你要让它基于这些资料回答问题，就得先把相关资料检索出来，再喂给模型。
一个完整的RAG链路通常包括几个环节：文档解析与切分、向量化（Embedding）、向量检索、答案生成。看起来简单，但每个环节都有很多坑。文档切分这里就有讲究——切太碎会丢失上下文，切太长会超出模型窗口或检索不精准。我常用的是“按章节结构切分 + 滑动窗口重叠”的策略，比如每个chunk控制在500到1000个token，前后重叠50到100个token，保证跨段落的语义能衔接上。
向量化是另一个容易忽视的环节。很多人直接用大模型的Embedding能力，但效果不一定好。我会先在一个小的测试集上对比几个Embedding模型的检索召回率，再选一个合适的。同时，中文场景下，建议优先选对中文支持好的Embedding模型（比如BGE系列或ACELite），效果差别很大。
至于向量数据库，用开源方案其实就够了。Milvus适合数据量大的场景，Chroma和Qdrant适合轻量应用。如果只是几百上千条文档，直接用内存向量库甚至用pandas做向量检索也行，没必要为了KPI硬上一套分布式数据库。
6.2 Agent开发：从“会聊天”到“会干活”
2026年做Agent已经不只是技术活，更是产品工程。一个Agent系统要能真正帮用户干活，关键不在于模型多聪明，而在于工具设计得巧不巧、流程设计得稳不稳。
我搭Agent的基本套路是：先定义清楚“它能调用哪些工具”，再设计“它怎么决定调哪个工具”。工具的本质是给模型暴露一组函数，模型通过Function Calling机制，在需要时输出一个结构化的调用指令。比如一个电商客服Agent，我会给它暴露“查看订单状态”“查询物流轨迹”“申请退款”这几个工具。用户问“我昨天买的手机到哪了”，模型先决定调用“查询物流轨迹”，把传参“订单号”填上，然后系统去查物流接口，把结果返回给模型，模型再基于查询结果组织自然语言回答。
这里面有一个实际开发中很容易踩的坑：Agent返回给模型的工具执行结果，不能一股脑全倒给模型。如果返回的是个大JSON，光上下文就占掉千把个token，既浪费窗口又影响模型判断。正确做法是，在工具层就对结果做摘要和结构化，只把最关键的信息发给模型。
另外，Agent的安全性也值得专门说。两个重点：一是工具的权限控制，Agent能调什么工具、不能调什么，必须在代码层面做死限制，不能只靠模型的自律去约束；二是超时和重试机制，任何外部工具都可能慢或者挂，Agent系统必须设计超时断开和降级策略，不能因为一个工具异常就让整个Agent卡死。
6.3 从RAG到Agent的架构演进
我在项目里经常遇到一个场景：刚开始只想做一个“知识库问答”，做着做着，客户就说“能不能让它顺便帮我生成周报摘要”“能不能让它在没答案的时候帮我转人工”。“知识库问答”就这样一步步演变成了Agent。
这里有个架构上的建议：在系统设计之初，就把“检索”“推理”“行动”这三层解耦。检索层负责从知识库中取得候选内容；推理层（也就是大模型本身）负责理解用户意图、组织回答；行动层负责执行具体的工具调用、权限校验、外部系统对接。这样的分层设计，让每一层都能独立升级和排查。比如检索效果不好，可以只替换Embedding模型或者优化切分策略，不用动Agent的流程代码；某个工具出了问题，也只需要改工具层，不会影响整个系统。
7. 常见问题与避坑记录
7.1 部署与运行环节的经典坑
部署环节我觉得最值得说的事，大概是依赖环境。跑大模型常见的痛点是：conda环境装了半小时，一运行就报torch.cuda.OutOfMemoryError或者undefined symbol。这类问题五花八门，其实多数是同源：CUDA版本和PyTorch版本不匹配。
我踩过坑之后总结的排查顺序是这样：先看nvidia-smi里的CUDA版本，再查PyTorch要求的CUDA版本，两者要能对应；然后看GPU占用是不是被别人占满了；最后再看代码是不是偷偷把整个模型加载了两次。90%的部署启动报错，走完这三步都能找到原因。
还有一个显存相关的坑是：即使是Ollama，看起来像“一条命令搞定”，在显存不足的机器上也会默默降级。比如你在8GB显存的卡上跑一个10GB的模型，Ollama会自动把部分层放到CPU上算，速度会断崖式下降，但不会报错。所以跑起来不代表能生产，一定要留意日志里的设备分配信息，确认模型是完整加载在GPU上的。
7.2 应用调试与效果优化的几则心得
调试大模型应用，最忌讳的是“靠感觉”。同一个Prompt，多跑几次就会观察到每次输出都不一样，如果只凭一两次的结果就判断方法行不行，容易把自己往错误方向带。
我的做法是：每次都固定一个相对完整的评估集，上面至少有几十条覆盖不同情况的输入。修改方案后，在这个评估集上跑一遍，统计通过率。通过率上升，才说明修改真的有帮助，否则就只是“这次运气好”。
另外一个经验是：在调整Prompt或系统设定时，先改一个变量，对比一次结果。如果你同时改了提示词、换了模型、又加了RAG，效果变好了，你根本不知道是哪个改动起了作用。保持“变量唯一”，才能在迭代中真正积累有效经验。
7.3 效果评估与安全：无可回避的基本功
大模型的输出天然存在不确定性，所以要上线进行业务应用，你就要有严谨的评估体系。我的基础方案是三层评估：第一层是离线自动评估，用测试集跑分，关注格式正确率、关键信息提取准确率、答案与标准答案的相似度等；第二层是离线人工评估，请业务同事对一批典型case打分，关注“答得对不对、够不够自然”这类主观维度；第三层是在线回归评估，灰度上线后持续监测线上日志，关注用户反馈和异常率。
至于模型安全，这块很难一劳永逸。业界通行做法是：在模型推理层加一个内容安全检测模块，对大模型的输出做一次筛查；在应用层做敏感操作和工具调用的权限控制。尤其是RAG和Agent场景，模型会接触到大量企业敏感数据和外部工具，安全边界必须在架构层面就定义清楚，不能指望模型自己“懂事”。
7.4 关于工具生态：哪些值得长期投入
2026年的工具生态已经比较丰富了。我个人会长期关注和维护的工具清单大概是这样的：
- 模型服务与部署：Ollama、vLLM、TensorRT-LLM（按场景选，不是越多越好）
- 微调工具：LLaMA-Factory、Unsloth（后者在效率和显存控制上非常有优势）
- 向量检索与RAG：LangChain/LlamaIndex（掌握其一就够了）、Qdrant/Milvus
- Agent框架：LangGraph或OpenAI Swarm这类流程编排工具
- 可观测与监控：OpenTelemetry加日志系统，模型的推理日志和调用指标一定要有留存
很多人会焦虑“新框架每天冒出来，学不完怎么办”。我的建议是：框架只是手段，核心还是理解和掌握底层原理——数据怎么流转、上下文怎么管理、工具怎么被调用——搞懂这些，哪怕某天生态换了新框架，你上手也很快。
8. 最后说点自己的体会
我带了这么多人转行做大模型工程师，最大的感慨是：这个行业确实缺人，但缺的是能沉下心解决问题的人，而不是会追逐热词的人。大模型变化很快，今天的新框架可能半年后就过时了，但解决问题的底层能力——会把一个模糊的业务需求拆解成明确的技术方案，会在模型效果差的时候冷静地找到原因，会在部署环境出问题时一步步排查——这些能力不会过时。
如果你现在正在准备入行，我的建议是别急着报课，先自己动手。跑一个开源模型，搭一个最小的RAG，写一个最简单的Agent，这几件事做完，你对这个领域的了解，大概率已经超过那些只会背概念的人了。
最后再分享一个小技巧：关注开源社区，尤其是在GitHub上多看大模型的源码实现。2026年了，大模型的很多核心代码都是开源的，这是这个行业对新人最友好的地方——你不需要闭门造车，全世界最优秀的工程师都在把他们的工作方式和技术取舍摊开给你看。你要做的，就是打开电脑，把它们跑起来。
