做AI工程这行也有几年了，经常有人问"我想从零开始学AI工程，该从哪里下手"。说实话，这个问题背后藏着不少误区——有人以为从机器学习公开课开始啃，有人上来就刷论文复现模型，还有人直接去调大模型API觉得这就完事了。这些路径不是不对，而是离"AI工程"三个字真正的含义差了很远。
"ai-engineering-from-scratch"这个标题其实点破了一件事：AI工程本身就是从零构建一套能稳定交付AI能力的方法论，它既不是算法研究，也不是写几个Python脚本调接口那么简单。它需要你理解模型怎么选、数据怎么管、推理成本怎么控、评估怎么做、上线之后怎么维护，这一整条链路里的每个环节都有自己的坑。
这篇文章就把我自己的学习路径和实操经验拆开来讲，适合那些有一定编程基础、想系统建立AI工程能力，但不想一头扎进数学推导或刷论文的开发者。我会尽量把每一个选择背后的理由讲明白，而不是只给一份"照着抄就能跑"的清单。
1. 先搞清楚：AI工程和AI研究到底差在哪
很多人从零开始学AI，第一反应是去补数学、看论文、复现模型。但AI工程这条路线的主线任务根本不是这些。工程和研究的核心区别在于：研究关心"模型能不能做到"，工程关心"系统能不能稳定做到、可控成本地做到、持续迭代地做到"。
1.1 研究对象不同：模型vs系统
在研究视角下，一个模型跑通了、指标刷上去了，工作就算完成了。但在工程视角下，模型只是整个系统里的一环。一个生产级的AI应用，背后是数据管道、特征服务、推理服务、缓存层、评估模块、监控告警、回滚机制这些东西的组合。
我举个例子你就明白了。假设你想给公司的工单系统做一个自动分类功能。研究思路可能是拿开源模型微调一下，在测试集上跑出一个不错的F1分数，然后写个技术报告。工程思路是：工单数据怎么抽出来并且保证脱敏、新旧模型分类结果怎么对比、线上误判怎么及时发现和纠正、高峰期推理延迟能不能扛住、模型一个月后漂移了怎么办。
这就解释了为什么很多习惯了纯研究思路的人，做出来的demo很漂亮，一上生产就崩溃——因为根本没有把"系统"当作一个整体来设计。
1.2 工程的核心约束：成本、延迟、稳定性
研究环境里你只需要一块甚至是几块GPU，数据在本地吃不吃得下也无所谓。但到了工程环节，你需要直面三件事：
- 成本：一次推理调用多少钱、自建GPU集群要摊多少折旧、微调一次要烧多少算力。这直接决定了你的方案选型，比如一个小流量场景用API调用就行，但高吞吐的内部场景可能就必须上自部署。
- 延迟：用户不能等十秒钟才知道"这条工单被分到了技术组"。从模型推理时间、网络传输、预处理耗时都要卡进一个预算里，有时候还需要做缓存、做并发控制、做批处理。
- 稳定性：LLM的输出天然带有随机性，同一个问题换一种问法结果可能完全不一样。工程上需要一套机制来约束这种不确定性——比如结构化输出、温度参数控制、后处理校验。更麻烦的是，模型升级之后行为会变化，这在工程上叫"回归风险"，必须有评估兜底。
1.3 为什么"from scratch"这条路要先建工程骨架
市面上大多数教学资源，要么从底层数学讲起（这就劝退了90%的人），要么只给一个预制好的Notebook让你填API Key跑通就算完事。前者离工程太远，后者又跳过了太多关键环节。
我自己的体会是，真正有效的"从零开始"，是先建立工程骨架，再往骨架里填充模型知识。什么意思？就是你先学会怎么搭一个包含API调用、数据处理、结果评估、服务部署的最小闭环，然后再在这个闭环里迭代和深化。骨架对了，后续学什么都快；骨架乱了，你学再多模型细节也落不了地。
2. 环境搭建：决定你整个学习节奏的底层配置
AI工程和普通后端开发对环境的要求完全不是一个量级。CPU不是问题，GPU才是。数据不是问题，数据规模才是。你在本地写一个普通的CRUD服务，一台笔记本完全可以应付，但要在本地搞AI工程，很快就会撞上算力墙。
2.1 本地方案：能用和够用的区别
本地开发一定绕不开这几样东西：Python环境管理、GPU驱动、容器运行时。我的建议是这三样分别用三套工具管好，各司其职。
Python环境管理我强烈推荐用uv而不是直接pip。uv比pip快一个数量级，而且对虚拟环境的处理更干净。以前的常见组合是conda加requirements.txt，但conda管理包依赖时经常出现莫名其妙的冲突，换到uv之后这个问题几乎消失了。你可以理解成一个高性能的包管理和虚拟环境二合一工具。
GPU驱动和CUDA这套东西是最容易劝退新手的。很多人装完PyTorch之后一读torch.cuda.is_available()返回False就懵了。其实这里要注意一个版本锁定的问题：你安装的PyTorch版本、CUDA Toolkit版本、GPU驱动版本三者是有对应关系的，不是一个装上就能通。我建议直接用uv安装带CUDA后缀的PyTorch发行版，同时用nvidia-smi查看驱动支持的CUDA版本上限。驱动版本只要不低于PyTorch要求的CUDA版本就行，不需要盲目装最新的。
容器化我用的是Docker加docker compose。这个几乎是AI工程的标准姿势，好处在于你可以把模型服务、数据库、向量存储、应用后端全部编排起来，别人拿到你的仓库一条docker compose up就能复现整个环境。做过几年工程的人一定懂"在我机器上明明能跑"这种痛，容器化就是为了彻底消灭这句话。
2.2 云上算力的选择逻辑
本地GPU终归有限。如果你要跑微调，哪怕是最低参数的LoRA，一张消费级显卡也撑不了太大的模型。这时候云上算力就是绕不开的选择。
云GPU这块有三条路：一是主流的云厂商直接开GPU实例，二是专门的GPU算力租赁平台，三是海外主流的Serverless GPU平台。我的建议是日常学习和跑小模型用第二类，按小时付费，性价比最高；做正式项目的原型验证可以混用厂商的竞价实例，比自己买卡灵活太多了。
这里有个容易踩的坑：你在本地写的代码，上传到云上之后很可能跑不起来。原因通常是路径写死、依赖版本不一致、缺少系统库。所以云上环境管理一定要从一开始就容器化，不要指望手动在云主机上装依赖。我的习惯是本地用Docker调试，确认无误之后直接打包镜像推到云端跑，这样环境一致性基本是100%。
2.3 开发工作流：从Notebook到真正的工程化
很多教程让新手直接用Jupyter Notebook，这也是这个领域最普遍的"工程毒瘤"之一。Notebook适合做数据分析或快速试验，但一旦代码量变大，它就会变成一个巨大的、不可维护的、运行顺序完全不可控的脚本聚合物。
工程化的开发工作流应该是这样：代码以Python模块的方式组织在项目里，数据以明确的方式管理，配置用环境变量或配置文件注入，测试是必要的环节。我是从一次惨痛的教训中改变这个习惯的——当时我在Notebook里写了一个数据处理流程，隔了三天再打开，发现所有变量都还记得，但那个Notebook已经膨胀到了好几千行，完全没法调试。
如果你想要一个即能快实验又能工程化的中间状态，我的建议是：Notebook只用来做探索性分析，一旦某个环节逻辑确定了，立刻把它重构进项目里对应的模块。宁可多花十分钟迁移，也不要让Notebook成为唯一的代码载体。
3. 核心技能地图：模型调用、RAG、微调和评估怎么分层练
环境搞完之后，真正的AI工程能力建设才开始。很多人的学习计划是线性的：学完机器学习再学深度学习，然后NLP，然后LLM。这个路线不是不行，但对AI工程来说太慢了，而且大量内容在实际工作中根本用不上。我的建议是围绕AI应用的四块核心技能来建立能力地图，一边用一边学。
3.1 模型调用：不只是填API Key
模型API调用看起来很简单，client.chat.completions.create往那一放就完事。但实际上模型调用是AI工程里最需要基本功的环节，因为它直接决定了你的应用质量。
首先是提示词的结构化处理。不要在一个字符串里把系统提示、上下文、用户问题全部塞进去，你要按照模型接口的语义把角色、功能描述、例子、对话历史分开。这是后续所有工程化的基础。我在场景里习惯用函数来管理不同类型的消息构造，每个业务场景一个独立函数，不要在世界里裸拼字符串，不然需求的回调另一条线上做调整时，代码就变成一堆难以阅读的字符串拼接了。
其次是结构化输出。现代模型API基本都支持response_format或json_schema参数。你可以在API层面强制模型输出JSON。但要记住一点：参数层面强制执行并不等于逻辑上完全可靠。模型可能在JSON结构内给出完全不合法的枚举值，所以返回之后还要用Pydantic或JSON Schema校验一把，不合规就让模型重试一次。从一开始就养成"API返回结果不可信，必须校验"的习惯，会替你省掉生产环境里无数个紧急修复。
还有一个很容易被忽略的是模型参数对成本和行为的巨大影响。temperature设成0.7和0.2输出结果的稳定性完全不一样；max_tokens设得太小直接切断后半段输出；top_p设定的变化会影响输出的多样性。这每一项在实践中都有讲究，不是教科书式的"参数解释"就够的。
3.2 RAG：填补模型的知识空白
RAG（检索增强生成）是AI工程里最重要的应用模式之一。模型训练数据是有截止时间的，而且通用模型对特定领域的内部知识一无所知。RAG的解决思路就是：在模型回答之前，先从知识库中检索出相关内容，作为上下文拼进提示词里。
我理解RAG的关键节点是四个环节：文档加载与解析、文本切分、向量化与存储、检索与重排。其中坑最多的就是文本切分。按固定字符数切看起来最省事，但会把完整语义切得支离破碎。按段落和标题层级切效果更好，但对PDF这类无结构化文档就不适用了。我的做法是先用文档解析器把PDF转成Markdown结构的文本，再按标题层级做切分，切完每一块保留源文档的元信息（文件名、页码、章节标题），为后续溯源做准备。
向量化与存储方面，现在主流的方案是Embedding模型加向量数据库。选Embedding模型要关注一个容易被忽略的点：你的领域语言和模型预训练语料是否匹配。中文场景下很多英文Embedding模型效果会打折扣，应该用专门的中文Embedding模型。
RAG建设还有一块被严重低估的工作：评测自己的检索质量。很多RAG项目跑起来后发现回答得不准，问题往往出在检索阶段——查到的根本不是需要的材料，模型自然给不出好答案。要解决这个，需要建一套带标准答案的评测集，去量测"检索命中率"和"生成准确率"。这个工作没有捷径，但它是RAG工程质量的分水岭。
3.3 微调：不是所有问题都要走的路
微调是很多新手最感兴趣、也最容易被带偏的地方。你上网一搜全是"三分钟微调你的专属大模型"，好像微调是什么灵丹妙药。事实完全相反：绝大多数垂直场景靠RAG和提示词工程就能解决，没有必要微调。
微调的真正适用场景是：你的任务对模型的输出格式有特殊结构要求，且很难通过提示词约束清楚；或者你需要在特定任务上把效果推到Prompt无法达到的水平；或者你希望在保持效果的同时压缩上下文长度来降本。判断要不要微调有一个很简单粗暴的方法：先拿优质提示词加RAG使劲调，调不出来再考虑微调。
如果确实要微调，LoRA几乎是唯一适合中小团队的选择。它的原理是通过冻结原模型权重、只训练一小部分低秩参数矩阵，把训练成本降到全参数微调的零头，同时效果逼近全量微调。我在实践中发现，LoRA微调的效果高度依赖数据集质量，几十条高质量数据可能好过几千条低质量数据。而且微调完的模型一定要和基础模型放在同一套评估体系里对比，不要光看训练集loss降了就兴奋——你可能只是过拟合了训练数据。
3.4 评估：AI工程的立身之本
做AI工程最怕的就是"看起来能用"和"真的能用"分不清。评估体系就是这两者之间的裁判。可以说，AI工程里所有的稳定性和可信度，最终都落在评估上。
评估分两层：离线评估和在线评估。离线评估就是在部署之前，用一套固定测试集跑一遍模型，量出指标好坏。这套测试集要覆盖主流程和关键的边界场景，并且和微调数据严格隔离，否则你是在自欺欺人。在线评估则是灰度上线后，用真实流量抽样评估模型表现，这是离线评估覆盖不到的盲区。
评估指标这件事也要说清楚：对LLM应用来说，"准确率"往往不够用。你需要把评估拆成多个维度，比如回答相关性、事实一致性、格式合规性、指令遵循度。现在工程上流行"LLM as a judge"——让一个更强的模型来当裁判，给目标模型的回答打分。这招好用，但要注意裁判模型自身的偏见，例如它可能会偏爱更长的答案。工程上我会使用多个裁判维度独立打分，和上下文长度做交叉分析，避免单一评价维度的偏差。
任何评估体系，都要从一开始就建立好跑批脚本和报告机制。不要"手动测试一下觉得不错就上线"，那不是工程，那是赌博。
4. 我的翻车现场：版本地狱、评估玄学与提示词幻觉
这一节算是我个人最想写的内容。因为AI工程里真正的学习效率，都藏在踩坑和修复的过程中。文档不会告诉你这些，官方教程更不会。我把自己踩过最典型的四个坑写出来，每个都对应一个工程教训。
4.1 版本地狱：一个依赖让整个服务起不来
我第一次做完整的AI应用时，在本地用了最新版的某个向量数据库客户端，服务跑得好好的。结果部署到服务器上，pip install -r requirements.txt之后，服务怎么都启动不了。查了半天才发现是那个向量数据库客户端升级了，接口参数变了，API签名不兼容。
这个问题的根源不是某个库，而是AI生态的版本迭代速度太快了。解决办法其实很简单，但也最容易被忽略：锁定依赖版本。不要写宽泛的版本范围，直接精确锁定到具体版本号。每升级一个关键依赖，就要在本地完整跑一遍集成测试。后来我养成了一个习惯，每次新项目都是先确定一个技术栈的"黄金版本组合"，然后所有模块都围绕这个组合来开发，稳定之后再统一升级。
4.2 微调效果"看起来很好"，上生产就现原形
我做过一次客服对话摘要的微调，离线评估指标很好，BLEU和ROUGE分数都挺漂亮，于是高高兴兴上了生产。过了两周接到反馈，说摘要质量"时好时坏"。一查才发现，离线测试集里大多是结构规整的短对话，而真实工单里的对话长度动辄几十轮，中间还夹杂着各种语音转写错误和无关闲聊，模型在长对话上严重退化。
这个坑的本质是训练和评估数据分布与现实数据分布不一致。后来我建立了一条铁律：任何微调项目，第一步不是准备训练集，而是先抽样分析真实线上数据分布。训练集、验证集、测试集的构造全部基于真实分布来分层采样，不能图省事拿公开数据集或手工拼凑几条就算数。你的评估分数高，也许只是因为测试题太简单了。
4.3 提示词幻觉：加了"不要编造"它还是编
还有一次，我给一个知识问答系统设计提示词，非常详细地写了"如果不知道答案，请明确说不知道，不要编造"。但实测中模型依然会一本正经地给出错误答案。原因很简单：模型的语言建模目标是"预测下一个最合理的token"，而不是"遵循你的指令去检索并确认事实"。提示词里的"不要编造"在强大的续写惯性面前，约束力有限。
解决这个问题不能靠咒语，要靠机制。我重构了系统的管道：先强制检索，再强制参考检索内容才能回答，最后做一次事实一致性比对，让一个裁判模型判断回答里的关键信息是否都能在检索内容里找到，找不到就拒绝回答。改了机制之后，无中生有的比例大幅下降。提示词是让模型表现得更好，但不能替代系统机制来保证它不出错——这个认知关系到你的系统设计思路。
4.4 评估指标互相矛盾：LLM裁判自己也不稳定
还有一次问题出现在评估环节本身。我用一个裁判模型给两个候选模型打分，本以为能客观比较谁更好，结果发现分数忽高忽低，同一条测试数据跑两次分数完全不一样。查发现是裁判模型的温度参数没有归零，导致裁判自身输出具有随机性。这听起来像低级错误，但在AI工程里这类"评估工具自身不稳定导致结论不可靠"的问题非常常见。
从那次之后，我的评估脚本统一了三个原则：裁判模型温度设为0；每条样本至少用不同模板的提示词测三轮取均值；对"相关性"和"忠实度"这类主观维度，分开问而不是合成一个笼统的总分。这三个原则用上之后，评估结果的可复现性和可信度才算真正立住了。
5. 前12周实践路线：用三个项目串起完整闭环
前面讲了那么多"为什么"和"怎么做"，但如果没有一个具体的时间线，很多人还是会陷入"什么都想学、什么都没学成"的困境。下面我列一条自己验证过的12周路线，以三个递进项目为引擎，每个阶段都产出可见成果。
5.1 第一阶段（第1-4周）：搭出你的第一个RAG问答系统
第一段我建议不要碰微调、不要碰复杂部署，先做一个RAG问答系统——从零开始搭一个能用的、能评估的、能讲清楚内部机制的知识问答服务。
具体任务拆解如下：
- 找一批你自己的领域文档（比如技术文档、产品手册），用解析器转成Markdown格式文本
- 按标题层级做文本切分，设计切分策略并人工验证若干样本
- 选择Embedding模型，把切分后的文本向量化并存入向量数据库
- 做一个带基础检索的问答接口，支持输入问题并返回带引用的答案
- 建立一套人工验证的问答评测集（至少30条），每天跑一遍，记录检索命中率和答案准确率
这个阶段的验收标准不是"能聊"而是"可验证"。你能明确说出当前检索的准确率是多少、失败案例长什么样、问题出在哪个环节，那就是学到位了。
5.2 第二阶段（第5-8周）：给系统加上评估闭环和工程化升级
第二阶段的目标是把"能做Demo"升级成"可迭代的项目"。领域和阶段一相同，所以你有明确的问题列表和已知短板，这会让你清晰看到评估的反馈机制如何运作。
这个阶段的核心动作：
- 把第一阶段的手工评测脚本化，你做一套自动化评估流水线，批量跑测试集并生成报告
- 接入LLM裁判评估，对相关性、忠实度、格式合规性三个维度分别打分
- 围绕已发现的问题做针对性优化——比如切分策略调整、检索重排引入、提示词重写，每改动一个环节必须用评估数据验证效果
- 用Docker把整个系统打包，提供一键启动的编排配置
- 给接口加上简单的输入输出日志和异常处理
这个阶段你会真切感受到一件事：有了评估闭环之后，每一次改动都能用数据说话，那种"靠感觉调参"的状态彻底结束。这也是AI工程和AI调包最本质的区别之一。
5.3 第三阶段（第9-12周）：基于开源模型做微调和完整部署
到了第三阶段，你可以尝试一个微调项目，来加深对"模型能力边界"的感知。这个阶段的建议是找一个小参数模型（参数量在7B到13B之间），用LoRA做一次指令微调。怎么找到好数据呢？把你前两个阶段积累的问答评测集扩充，或者用模型自身生成再人工修正都可以，重点是要控制规模但保证质量。
具体的落地动作：
- 准备训练和验证数据，做格式转换和清洗
- 用LoRA训练脚本跑通一次微调，掌握关键参数（学习率、LoRA秩、训练轮数）与效果的关系
- 用统一评估集对比基础模型和微调后模型的表现，验证微调是否真的带来了提升
- 用推理优化工具做一次模型部署（量化、推理加速），接入你已有的RAG系统
- 对比微调前后服务在延迟和吞吐量上的差异
这个阶段之后，你对AI工程的一个完整链路——数据、模型、评估、优化、部署——就都有实际手感了，后面再学更复杂的架构（多智能体、大规模分布式推理）就有了扎实的锚点。
6. 进阶方向：往哪个深度继续挖
12周路线跑完之后，你就建立了自己的AI工程骨架，后续深挖的方向很多，取决于你的工作和兴趣方向。这里提三个我认为最有价值的进阶主题，每个都对应一个真实的能力瓶颈。
第一个是推理优化与成本治理。模型越来越大，推理成本也随之膨胀。当你需要服务高并发流量时，需要接触到连续批处理、投机采样、量化推理、KV Cache优化这些技术。这里有一个认知，就是你从关注"模型有多聪明"转变成关注"服务够不够快、够不够省"。这是工程思维的又一次跃迁。
第二个是多智能体系统的设计与控制。多个模型各司其职，通过规划、编排、工具调用来协同完成任务，是AI应用前沿最活跃的领域。但多智能体不是"多放几个模型让它自己商量"这么简单。你真正要解决的问题是如何控制每个智能体的边界、如何设计它们之间的通信协议、如何兜底和降级。前面打的稳定性和评估基本功，在这里就是你最宝贵的武器。
第三个是持续学习与模型更新机制。业务会变，数据会变，模型会漂移，你需要设计一套机制让系统能够感知这种变化并且持续自我改进。这里面包括数据收集、增量微调、线上回放、新旧模型对比切换这些工程细节。能把这条流水线跑通，说明你已经把AI系统当作一个活的物种在运营，而不再是一个一次性的部署物。
走到这个深度的人其实已经很少了。而这一切的起点，不过是一台开发机、一个认真设计的最小闭环项目、和每周固定的迭代节奏。方向比速度重要，你自己的完整闭环比收藏别人的清单重要——希望这篇文章能帮你少走那些我走弯过的路。
