这两年陆陆续续有朋友问我同一个问题现在转行做AI大模型工程师还来得及吗我的回答一直是——2026年之前恰恰是最后一段能靠“动手能力”站稳脚跟的窗口期。我自己给自己起了个名字叫“码士”意思很简单写代码这件事本质上和古代工匠一样需要手脑并用。过去一年我从只有一张消费级显卡到把本地大模型部署、微调、Agent应用全部打通最大的感受是真正拉开差距的不是谁论文读得多而是谁能在自己的机器上跑通一个又一个真实的小项目。这篇内容就顺着我的实战路线把2026年AI大模型工程师需要掌握的核心内容串一遍。1. 2026年AI大模型工程师的能力模型从“做什么”说起1.1 这个岗位到底解决什么问题很多人一上来就盯着“大模型”三个字以为要啃一堆数学公式才能入行。我见过不少被Transformer论文劝退的朋友其实完全没必要。2026年这个节点上行业里真正稀缺的不是懂原理的人而是能把模型用起来、改起来、交付出去的人。AI大模型工程师日常做的事情拆开看无非四类第一把开源模型或商用API接到业务系统里设计Prompt和调用链路第二针对特定场景做RAG、Agent这样的应用架构让模型会“查资料”“用工具”第三在数据足够且场景特殊时做微调让模型学会专属领域的表达习惯第四搭建评估体系持续观察模型输出质量出现问题能定位是数据、参数还是工程链路的问题。这四类工作有一个共同特点——全部围绕“能跑”“好用”展开不会让你天天推导公式。所以我对新人的第一条建议是先别研究注意力机制的数学细节先想办法把模型在本地跑起来看到真实输出再往回学原理效率高得多。1.2 为什么“本地部署”是第一个门槛刚开始做这个方向时我习惯所有功能都调云端API省事是真省事但有一个致命问题很多公司的数据不能出内网尤其医疗、金融、政务场景模型必须私有化部署。就算不考虑数据边界想要深入理解模型行为也必须自己能掌控整个推理链路。这就把“本地部署”抬到了入门第一关的位置。本地部署的真正价值有三点一是数据可控所有请求都在自己机器上处理不担心API调用把敏感信息传出去二是调试自由可以随时改采样参数、换量化版本、加系统提示词还能看到模型原始的输入输出排查问题比黑盒API方便得多三是长期成本可控中小团队高频调用场景下自己部署一套7B/14B模型的成本通常比按Token付费低不少。当然本地部署也有代价你的显卡就是瓶颈。但2025年之后4bit量化让7B模型在8G显存的消费级显卡上跑得很流畅32G内存的MacBook也能跑14B模型门槛已经比你想象的低很多。这也是我把Ollama放在实操第一章的原因。1.3 三条典型发展路线应用开发、模型工程、Agent工具链进到这个领域越久越发现“AI大模型工程师”是个大筐筐里至少装着三种人各自技能栈有明显差异。搞清楚自己想走哪条路学习路径会完全不同。第一条是AI应用开发工程师核心技能是Prompt工程、RAG架构、API集成和前后端工程能力。这类岗位最多也最适合有传统开发经验的人转型不需要很强的算法背景。第二条是模型工程/算法工程师核心技能是微调、量化、分布式训练、模型评估需要理解训练和推理原理是三条路里技术密度最高的。第三条是Agent平台与工具链开发重点做模型与外部工具之间的编排层比如函数调用、记忆管理、多Agent协作强调的是系统设计能力和场景拆解能力。我个人的建议是如果你是新手先按第一条路线入门用应用开发积累项目经验再用业余时间往第二条或第三条延伸。因为应用开发是最快能出成果的路线正反馈非常强烈。等你把RAG、Agent都做熟了会发现后面两条路需要的知识已经在实战中攒下了一半。2. 实战环境搭建用Ollama把第一个私有模型跑起来2.1 Ollama部署私有模型的完整流程先说说为什么选Ollama。它把模型下载、量化、运行、API服务全封装好了一条命令就能起一个OpenAI风格兼容的本地接口对新手极其友好。我在好几台设备上都装过Windows、Linux、macOS都能覆盖实测下来属于“半小时上手后续不折腾”的工具。安装很简单去Ollama官网下载对应系统的安装包或Linux下用官方安装脚本直接装。装好后拉取模型开始跑# 拉取7B中文模型qwen2.5在中文场景表现很稳 ollama pull qwen2.5:7b # 直接命令行交互 ollama run qwen2.5:7b # 启动API服务默认监听11434端口 ollama serveOllama默认会绑定到127.0.0.1如果想让局域网内其他机器访问需要设置环境变量OLLAMA_HOST0.0.0.0:11434再重启服务。调用方式和OpenAI格式保持了一定的相似性请求体示例curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, messages: [ {role: system, content: 你是一名资深运维工程师}, {role: user, content: 帮我写一段清理磁盘日志的Shell脚本} ], temperature: 0.7 }关于模型选择我给一个实用建议入门先用7B这个档位。参数再大的模型对显存和内存要求苛刻推理速度也会明显下降容易把人劝退。7B模型在中文任务上已经能承担一半以上的日常工作先把它用透再考虑14B或更大尺寸。2.2 在VS Code里用Claude Code接入本地模型有了本地模型之后很多朋友问怎么把它接到日常编程工具里。最近社区里比较热的一个玩法是VS Code Claude Code插件接入本地Ollama等于让你在编辑器里直接和本地模型对话让它帮你写代码、改Bug。配置思路其实不复杂Claude Code允许通过环境变量指定它要连的模型服务地址。把API地址指向本地Ollama就能实现。我在Linux/Mac下一般这样配置export ANTHROPIC_BASE_URLhttp://localhost:11434/anthropic export ANTHROPIC_AUTH_TOKENlocal-dummy-token export ANTHROPIC_MODELqwen2.5:7b需要说明的是Ollama的Anthropic兼容端点对部分工具交互协议支持还不完整尤其是工具调用类功能不同版本表现有差异。我实际操作中发现纯文本对话、代码生成这种场景很稳定但遇到复杂的MCP工具调用时偶尔会有格式问题。如果你只是想让本地模型帮你写代码、解释报错这个方案完全够用。如果更追求稳定还有个替代思路用Continue插件或Cline这类开源编程助手它们对本地模型的支持更加成熟。我两个都试过日常开发顺手度排序是商用大模型API Claude Code接本地Ollama Continue接本地模型。但数据敏感或成本敏感时本地方案是不可替代的。2.3 显卡不够怎么办AirLLM的低显存运行思路很多人在“本地部署”面前卡住的原因是硬件。8G显存跑7B模型还行但如果想试试几十B参数级别的大模型一张专业显卡的价格确实劝退。AirLLM这个开源项目就是为解决这个问题出现的它能通过优化的混合量化与内存调度把超大模型的推理过程拆开让单张消费级显卡也能跑起大参数模型。AirLLM的使用方式对开发者很友好和HuggingFace的写法高度相似from airllm import AutoModel model AutoModel.from_pretrained(TheBloke/Llama-2-70B-GGUF) input_text 请介绍一下机器学习的核心概念 inputs tokenizer(input_text, return_tensorspt) output model.generate(inputs.input_ids, max_new_tokens100) print(tokenizer.decode(output[0], skip_special_tokensTrue))不过说实话AirLLM用CPU/内存换显存速度是有代价的。大模型在普通PC上生成的token速度可能只有每秒几个体验甚至不如云端API。我觉得它的价值更多在于验证模型效果和做原型真正上线服务还是要靠多卡服务器或API。这个经验我写在后面问题章节里避免大家产生误解。2.4 免费API与云资源怎么选本地部署不是唯一选择有些场景用免费API做前期验证反而更快。我一直保留几个稳定免费或低价的模型API渠道用来跑原型和自动化脚本。整理一下比较常用的几类服务特点适合场景Ollama本地服务完全免费、数据本地、无网络依赖隐私敏感、高频调试、离线环境OpenRouter聚合多家模型有免费额度多模型对比、快速体验不同模型Cloudflare Workers AI免费额度可观边缘部署轻量应用、边缘计算场景Groq推理速度快有免费档需要低延迟的对话与代码生成国内主流云厂商API稳定、有免费额度中文优化好生产环境、中文业务场景我踩过的坑是永远不要在产品初期把主链路绑死在某个平台的免费额度上万一额度变动整个应用就瘫了。正规做法是封装一层统一接口底层模型可以随时切换。这也是我在搭建应用时坚持用OpenAI兼容格式的原因——本地Ollama和云端API之间只需要改一个base_url就能切换迁移成本几乎为零。3. AI应用开发的核心环节从RAG到Agent3.1 为什么RAG比微调先做很多新人做完环境搭建就着急微调模型其实顺序反了。绝大多数业务场景先上RAG检索增强生成就够用。原理打个比方一个刚入职的实习生你不可能马上给他重新培训知识体系正确做法是让他随时翻公司文档遇到问题先查再答。RAG做的就是“先查文档再回答问题”这件事。RAG整体流程分四步文档加载与切分、向量化入库、查询时检索、把检索结果塞进Prompt让模型回答。其中最容易出问题的是“切分”和“检索”切分太碎会丢失上下文太大会塞爆上下文窗口检索策略选不对召回质量会直接影响答案。在知识抽取这个环节有个叫OneKE的开源框架很值得关注。它专门做中文知识抽取可以从非结构化文本里抽实体、关系、事件输出结构化JSON。我在构建企业知识库时先用OneKE把文档里的关键实体关系抽出来再和原文一起做向量化检索召回率明显比纯文本切分高。这种方式等于给RAG加了一层结构化索引尤其适合关系密集的场景比如流程制度、产品说明书。3.2 一个最小可用的企业知识库RAG实现接下来给一个可以直接抄作业的最小实现。我用LangChain或LlamaIndex都搭过但对新手来说反而建议先直接用向量数据库和少量胶水代码跑通一遍这样每一步都看得见。from openai import OpenAI import chromadb # 初始化本地向量库 client chromadb.PersistentClient(path./kb_store) collection client.get_or_create_collection(docs) # 用本地Ollama的embedding接口生成向量 llm OpenAI(base_urlhttp://localhost:11434/v1, api_keyollama) # 文档入库假设docs已经是切分好的段落 for i, chunk in enumerate(docs): vec llm.embeddings.create( modelbge-m3, inputchunk ).data[0].embedding collection.add(ids[str(i)], embeddings[vec], documents[chunk]) # 查询并生成回答 query 公司报销流程是什么 q_vec llm.embeddings.create(modelbge-m3, inputquery).data[0].embedding results collection.query(query_embeddings[q_vec], n_results3) context \n.join(results[documents][0]) response llm.chat.completions.create( modelqwen2.5:7b, messages[ {role: system, content: 只能依据资料回答资料没有就说不清楚}, {role: user, content: f资料{context}\n\n问题{query}} ] ) print(response.choices[0].message.content)这套代码我已经在实际项目里验证过单机环境下跑得很稳。几个关键参数请务必记住检索结果数量n_results建议先设3到5太多会把无关内容塞进Prompt上下文拼接时最好控制总长度避免超出模型窗口系统提示词里那句“资料没有就说不清楚”能有效降低模型编造答案的概率。RAG最核心的调优点恰好在这些细节上而不是模型本身。3.3 AI Agent实战让模型学会调用工具做完RAG下一个自然进阶方向是Agent。RAG是让模型“会查资料”Agent是让模型“会做事”。两者的区别在于Agent不仅能理解问题还能规划步骤、调用外部工具、观察结果并决定下一步行动。我最近做的一个练习是让Agent写Verilog代码并调用仿真工具验证。这个场景很典型因为硬件描述语言的代码对准确性要求很高模型单独生成往往有语法或逻辑错误必须让Agent自动运行仿真工具、获取报错信息、再迭代修改。思路拆开是这样的定义一个“写代码工具”和一个“跑仿真工具”Agent收到任务后先调用写代码工具生成Verilog文件再调用仿真工具执行把输出反馈给模型模型根据错误信息继续修改循环直到仿真通过。实现上现在主流框架都对这一套做了高度封装。我建议直接用支持函数调用的模型API流程会简单很多。需要注意的点是第一给Agent的每个工具都要写得像接口文档一样清晰描述清楚输入参数含义和返回结果结构第二设置最大迭代次数防止模型陷入死循环第三工具执行过程最好有日志否则出了问题根本没法排查。这些经验都是从惨痛教训里总结出来的——我第一版Agent就因为没有日志模型反复调用同一个失败工具白白烧了大量token。3.4 提示词工程Agent效果的底层支撑无论RAG还是Agent最终输出质量都取决于提示词设计。这块虽然人人都会写但质量差异极大。我的经验是提示词不是一段“咒语”而是一份“岗位说明书”要把角色、目标、输入格式、输出格式、边界条件都写清楚。一个实用的Prompt模板我可以分享出来你是[角色]负责[目标]。 输入内容如下 {输入} 请按以下要求处理 1. [具体要求一比如“先分析再回答”] 2. [具体要求二比如“输出JSON格式”] 3. [边界条件比如“不要编造资料外的信息”] 如果信息不足请明确说“信息不足”不要猜测。这套模板看起来简单但实操中能解决80%的输出不稳定问题。我特别想强调的是“信息不足就明说”这一条它看起来让模型变“笨”了实际上反而让系统更可靠——因为幻觉少了用户信任度会大幅提升。再有就是把输出的预期格式写死比如让模型必须返回JSON解析环节就能省掉大量的兼容处理。4. 微调不是万能的从LoRA实操到模型评估4.1 哪些场景需要微调哪些场景不需要经常被问到一个问题我已经用了提示词也做了RAG为什么还要微调我的判断标准很朴素只有两种情况下值得微调。第一种是模型的输出风格必须严格符合业务规范比如法律文书、医疗报告、特定格式的代码注释靠提示词约束不够稳定第二种是数据特征和通用语料差异极大比如企业内部术语、特殊符号体系模型理解不了上下文。反过来说如果只是想让模型知道一些事实性知识别微调那是RAG的职责。微调不等于“喂知识”它更多是改变模型的行为模式和表达能力。用错场景轻则浪费算力重则把模型原本的能力“洗坏”出现灾难性遗忘——模型学会了新任务却忘了基础能力那就得不偿失了。4.2 用LoRA做一次轻量化微调确定要微调之后从LoRA开始是最合理的选择。LoRA的本质是不动原始模型权重而是在旁边训练一个低秩矩阵作为“插件”训练成本低、显存占用小效果在多数场景下已经够用。配合4bit量化QLoRA消费级显卡也能完成7B模型微调。以下是一个可运行的训练脚本框架from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training from datasets import load_dataset import torch model_id Qwen/Qwen2.5-7B-Instruct model AutoModelForCausalLM.from_pretrained( model_id, load_in_4bitTrue, device_mapauto, torch_dtypetorch.float16 ) tokenizer AutoTokenizer.from_pretrained(model_id) # LoRA配置target_modules要按模型结构调整 lora_config LoraConfig( r8, lora_alpha16, target_modules[q_proj, k_proj, v_proj, o_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM ) model prepare_model_for_kbit_training(model) model get_peft_model(model, lora_config) dataset load_dataset(json, data_filestrain.jsonl)[train] training_args TrainingArguments( output_dir./lora_output, per_device_train_batch_size2, gradient_accumulation_steps8, num_train_epochs3, learning_rate2e-4, logging_steps20, save_steps200, fp16True, remove_unused_columnsFalse ) model.train() # 实际训练时补上trainer的构建步骤即可数据集格式我强烈建议用会话格式每条数据包含system、user、assistant三段这样微调后模型仍然保留指令跟随能力。数据量方面LoRA微调有个很有意思的现象几百条高质量样本往往比几万条低质量样本效果更好因为风格对齐需要的样本量远小于知识灌输。我做一个项目时人工精标500条对话就让模型输出风格达到了可用水平。4.3 微调后的评估与“投毒测试”思路微调完成不等于交付评估环节如果不做上线出问题才是噩梦。基础评估大家都会做看看Loss下降、跑几个样例确认效果。但如果这是一次严肃的交付我建议把评估做得更全面至少覆盖三个方面指标评估、对抗性输入测试、幻觉检测。指标评估用BLEU、ROUGE这些自动指标只能做个参考真正有价值的是人工评估和任务准确率。对抗性输入测试就是故意构造边界case去“攻击”模型观察它在异常输入、歧义问题、恶意引导下的表现这个环节社区里常叫“投毒测试”本质是压力测试。我在实践中的做法是维护一份边界case集每次微调后都跑一遍确认模型不会因为训练数据里的噪声而出现回答失控。幻觉检测更简单直接把模型答案里的数字、引用、专有名词抽出来和原始资料交叉验证凡是找不到出处的信息统统标记为可疑。这一步很能体现工程师的严谨度。模型效果好不好不是“看起来像那么回事”而是能不能通过一整套可重复的评估流程。我在项目里会把评估脚本沉淀下来每次方案调整后自动跑回归效果好不好一对比就知道。5. 常见问题与排查技巧实录5.1 显存不足与推理速度慢本地部署最常遇到的就是显存不足。以7B模型为例FP16精度大概需要14GB显存4bit量化后降到4GB到5GB所以8G显存的卡是能跑的。如果试了还爆显存第一步检查是不是用了非量化版本换成GGUF或GPTQ的4bit版第二步调整推理参数把max_tokens调小、关闭并发请求第三步才考虑用AirLLM做CPU offload作为兜底方案。推理速度慢是另一个高频问题。影响速度的因素依次是模型大小、量化等级、上下文长度、并发数。7B模型在消费级显卡上生成速度大约每秒15到30个token如果明显低于这个值大概率是量化等级不对或模型被调度到了CPU上。我踩过的坑是忘记在启动命令里指定GPU设备结果模型跑在核显上那速度根本没法用。5.2 模型回答质量不稳定的排查顺序模型回答忽好忽坏很多人第一反应是换更大模型但90%的情况下问题出在输入侧。我的排查顺序是先检查提示词是否清晰包括角色、输出格式、边界条件是否写全再检查上下文窗口是否塞入了过多无关信息导致模型注意力分散然后检查采样参数temperature设置过高会造成输出发散一般对话场景设在0.3到0.8之间比较合理最后才考虑模型本身能力不足。有一个容易被忽略的问题本地模型和API模型的同参数设置实际效果可能差异很大因为不同模型的校准机制不同。所以“网上推荐的参数”只能当参考最终要以自己场景的测试结果为准。每换一个模型都建议在固定测试集上重新对比一遍基础参数不要图省事直接沿用旧配置。5.3 工具联调与版本兼容问题接入的工具越多越容易遇到奇怪问题。我最常遇到的几类一是Ollama版本升级后API返回格式有细微变化代码里解析响应的地方报错二是Claude Code接本地模型时上下文长度设置不对导致频繁截断三是不同工具链对模型名称的识别规则不一致服务端叫qwen2.5:7b客户端却要求必须写成qwen2.5结果一直报模型不存在。这类问题没有一劳永逸的解法只能靠两个习惯来缓解第一把关键服务的版本号固定在某个稳定版本不要手痒乱升级产品和模型一样需要稳定第二写代码时统一封装API调用层解析返回值的逻辑集中管理这样底层服务变化时只需改一处。另外所有联调请求都要打日志哪怕是本地开发环境也一样。日志就是排查问题的眼睛没有日志的联调就像黑灯维修全靠运气。6. 学习路线与资源推荐6.1 五步动手路线梳理一下适合动手派的学习路径。第一步把本地部署跑通Ollama加一个7B模型完成命令行交互和API调用第二步做一个小型RAG项目比如给个人笔记搭一个问答机器人第三步学习提示词工程和Agent基础尝试让模型调用外部API第四步用LoRA做一个微调实验体会数据对模型风格的影响第五步搭建评估体系给前面所有项目加上评测脚本。每一步都不需要追求“大”关键是形成闭环。比如第一步的目标不是部署一个多大规模的模型而是让你亲眼看到“模型是怎么输出文字的”“API请求长什么样”“修改temperature对结果有什么影响”。这些体感知识是看教程永远得不到的只有亲手跑一遍才能内化成自己的判断力。我做项目时最值钱的能力其实都来自这些看似简单的小实验——一次次观察输入输出之间的因果关系慢慢就建立了对模型行为的直觉。6.2 我验证过的高效学习资源学习资源方面上海交大的《动手学大模型》开源课程我推荐过很多次整个课程直接从代码实践入手不是论文导读非常符合“动手派”的学习习惯。再配合Hugging Face的官方教程、几大开源模型的文档和社区项目源码基本足够。我的建议是不要囤课、不要只看每学一个章节必须落地成一个能跑的小项目哪怕很小也比泛泛看十篇教程有用。学习过程中遇到报错是常态反而是好事因为排查问题的过程能让你真正理解框架内部的机制。我自己最好的状态就是每天下班后花一小时坚持在本地模型上做一个小实验日积月累比突击学习扎实太多。最后再分享一个小技巧给自己准备一份“实验笔记”把每次改了什么参数、换了什么模型、得到了什么结果都记录下来。我后来很多项目的方案选型都是靠翻笔记里那些不起眼的实验记录才避开了大坑。这条习惯建议从你部署第一个Ollama模型那天就开始。