1. 先把从零的定义搞清楚AI工程和 AI 研究不是一回事有朋友在评论区问我你那个ai-engineering-from-scratch到底是从哪个零开始是数学零基础还是编程零基础还是完全没接触过大模型我特别想回答这个问题因为大多数人学 AI 半途而废问题不在能力而在没有定义清楚自己的起点和终点。先亮个观点AI Engineering 和 AI Research 是两个方向。研究岗每天在琢磨模型能力的天花板琢磨论文里的新机制训练更大的模型工程岗每天在琢磨怎么把别人训练好的模型稳定地跑起来怎么跟现有系统对接怎么在真实的数据和真实的用户反馈里把它调得越来越好用。从这个角度说AI 工程的零不是数学的零不是算法的零而是**能不能把一个能用的AI系统交付出去这个能力上的零**。你不需要自己发明 Transformer你不需要手写反向传播但你需要知道模型输入输出长什么样需要知道怎么把文档切碎灌进向量库需要知道用户问了一个问题模型答错了要往哪个环节查。所以这份从零开始的内容本质上是一个能力清单和路线图让一个有一定编程基础、想进入 AI 应用开发领域的人用尽可能短的时间走完会用模型到能交付AI功能的这段路。这篇内容是我把自己过去几年带人、做项目的思路整理出来的产物。适合几类人看刚转行的前端/后端工程师想把 LLM 接到业务里的产品技术负责人以及在读学生想绕过论文式学习、直接上手做 AI 应用的人。看完之后你可以照着章节顺序一步步操作也可以挑自己缺的模块跳着看东西都是互相独立的。2. 奠基期编程、数据处理与数学到底要学到什么程度AI 工程的地基不是数学公式是你处理数据的能力。这里我按实操倒推说说真正够用的标准。2.1 Python 与工程习惯不是会写就行Python 语法谁都能在两周内上手但很多人写的 Python 只能自己跑通换个环境就崩。AI 工程是团队协作和长期演进的事情从第一天起就要养成几个习惯用虚拟环境管依赖而不是一股脑 pip install 到全局从第一个脚本开始就用 Git 管理每次改动附带清晰 commit 信息代码优先做到模块化数据加载、特征处理、模型调用、结果输出各自独立成函数我自己现在统一用 uv 来管理 Python 环境和依赖它比传统 pip venv 的组合快得多锁文件机制也能保证不同机器上复现出同一套环境。项目里固定放一个requirements.txt或者pyproject.toml标注核心依赖的版本范围这比什么都重要。工程习惯还包括不依赖 notebook 写业务代码。Jupyter 适合做探索性分析和可视化但真正进入开发阶段请把逻辑迁移到.py文件中保留 Notebook 作为实验记录。2.2 数据处理日常AI 工程师的 80% 时间在这里很多人被AI两个字吸引结果真正做起来发现自己整天在洗数据。这不是异常这是常态。所谓工程化的数据处理核心就四件事获取、清洗、转换、验证。以最常见的表格数据为例你需要能用 pandas 做这些操作读入 CSV、Excel、JSON 等不同格式并处理编码问题识别缺失值、异常值、重复行并决定是删除还是填充做特征工程分箱、编码、标准化、构造交叉特征用assert或专门的校验函数确认数据质量比如数量匹配、数值范围合理到文本和图片场景则是解析 PDF/HTML、去除噪声页眉页脚、广告、脚本标签、映射到统一 schema。这些能力没法靠看书获得只能靠大量的实际数据喂出来。我建议新手第一个月的训练材料直接上真实场景数据比如自己积累的日志、公开的政府数据集、Kaggle 里的经典表格赛题。不要嫌数据脏脏数据才是真实的过干净的数据集反而学不到该学的本事。2.3 数学到底要不要补补多少关于数学我给的是够用主义标准如果你的目标不是研究岗以下程度就可以开始做项目了线性代数理解矩阵乘法代表一组线性变换理解向量的点积跟相似度的关系。这足够让你看懂嵌入模型embedding model的基本逻辑。概率统计理解均值、方差、概率分布的概念知道什么是采样能够读懂准确率、召回率、AUC 这些指标的含义。微积分不用会求复杂积分知道梯度下降的方向来自导数/偏导能看懂损失函数在某个点下降这句话就够了。更深入的部分比如矩阵分解的证明、随机过程的推导等你在项目中真的碰到再回来补。太早陷入数学会彻底消磨掉动手的兴趣这是我在无数人身上看到的真实教训。数学知识的作用不是让你推导模型而是让你在模型表现不佳时有一个能判断问题大概率出在哪个环节的逻辑框架。3. 模型层实践从经典机器学习到深度学习的过渡逻辑很多人一上来就抱着 PyTorch 啃看完了整本《动手学深度学习》却还是不知道从哪里开始写自己的训练代码。我在整理内容时特意把经典机器学习放在前面这不是复古是给后续一切模型能力建立直觉。3.1 先用经典模型建立基线思维基线baseline是我认为整个 AI 工程里最重要的概念。任何项目动手之前先做一版能跑通的最简单方案记录它的效果然后在它的基础上逐步改进。没有基线你后续做的所有优化都无法回答到底变好了没有这个问题。以分类任务为例逻辑回归和随机森林就是完美的基线工具from sklearn.ensemble import RandomForestClassifier from sklearn.model_selection import cross_val_score model RandomForestClassifier(n_estimators200, random_state42) scores cross_val_score(model, X_train, y_train, cv5) print(f基线准确率: {scores.mean():.4f} (/- {scores.std() * 2:.4f}))这段代码五秒钟跑完但是它会告诉你一个关键信息**在不做任何花哨处理的情况下一个通用模型的底线在哪里。**如果之后你上了深度网络、上了大模型但是效果提升不超过两三个点你就得认真考虑是不是数据或特征出了问题而不是模型的锅。交叉验证的使用习惯也建议从这时建立起来。它比单一 train/test split 更可靠地反映模型泛化能力尤其是数据量不大的时候。新手最常犯的错误是反复用同一份测试集调参最后骄傲地报出一个完美指标放到真实场景却立刻崩掉就是因为过拟合到了测试集上。3.2 深度学习的最小可运行闭环从经典 ML 跨到深度学习核心是理解神经网络怎么对数据自动找特征。PyTorch 里一个训练闭环通常就五个步骤构建 Dataset 和 DataLoader把数据批量喂给模型定义网络结构哪怕是最简单的多层感知机选择损失函数和优化器前向传播算预测、算损失反向传播算梯度按固定 epoch 数迭代并在每次迭代后评估验证集import torch import torch.nn as nn model nn.Sequential( nn.Linear(20, 64), nn.ReLU(), nn.Linear(64, 1) ) loss_fn nn.BCEWithLogitsLoss() optimizer torch.optim.Adam(model.parameters(), lr1e-3) for epoch in range(30): for x_batch, y_batch in train_loader: optimizer.zero_grad() pred model(x_batch).squeeze() loss loss_fn(pred, y_batch) loss.backward() optimizer.step()这个闭环本身不难难在出现问题的排查能力loss 变成 NaN 了怎么办收敛太慢是学习率问题还是特征缩放问题过拟合在哪一个 epoch 开始出现这些都需要在真实项目里磨。我强调最小可运行闭环的另一个原因是它给出了调试的边界。很多人在配置环境、装 CUDA、解决版本冲突上花的时间比写代码还多而一旦你掌握了一套能跑起来的最小流程剩下的事情都变得可以迭代。3.3 为什么我建议用小型数据集而非玩具项目练手学习深度学习时选择一个合适的数据集非常重要。MNIST 手写数字这类数据集太干净了每个图都是 28x28 像素、中心对齐、背景纯净你在这个数据集上怎么做都能得到不错的结果根本练不出处理真实噪声的能力。我推荐用中小型但真实的数据集比如图像CIFAR-10/100图像尺寸适中且包含真实物体的形变和背景文本IMDB 影评涉及变长序列、停用词、情感极性等真实问题表格贷款违约预测类赛题特征间高度混杂且有缺失需要做很多预处理你在这些数据集上会遇到的第一个坎通常是为什么验证集表现远低于训练集然后你开始研究正则化、数据增强、早停、调学习率。这些恰恰是网上千篇一律的教程不会教你的、真正决定模型能否落地的部分。注意一点这阶段不是要你把 SOTA 刷到多高而是要完整地走过一遍加载数据 → 建立基线 → 尝试改进 → 记录实验 → 得出教训的过程。一个跑完整流程、效果一般的项目比一个直接用别人调好权重、效果华丽但不知其所以然的项目有价值得多。4. LLM 时代AI 工程的重心转移到了哪里如果说经典 ML 和深度学习解决的是从数据中学会规律的问题那么 LLM 时代 AI 工程的核心则是如何优雅地把一个预训练好的强大模型嵌入到业务流程中。你不需要训练它但你需要知道在什么场景下用什么方式让它发挥最大价值。4.1 RAG 和 Agent把 LLM 变成产品能力的两种主流形态RAG检索增强生成是目前企业落地 LLM 性价比最高的范式。它的工作流非常清晰离线阶段把知识文档解析成文本切分成合理大小的片段chunk用嵌入模型转成向量并存入向量数据库在线阶段用户提问 → 同样转成向量 → 在向量库中检索最相关的若干片段 → 把这些片段和用户问题一起发送给大模型 → 模型基于检索内容生成答案这一套看起来简单真正别扭的地方全在细节。我踩过的坑包括PDF 表格解析后文本乱序、切分粒度太大导致召回不精准、嵌入模型与检索文本的语言不匹配、知识库更新后旧向量没有及时清理。Agent智能体是更进阶的形态。本质上是让模型具备调用外部工具的能力查数据库、调用 API、执行代码、访问网页。实现上通常采取 ReAct 模式让模型基于用户目标思考接下来该调哪个工具观察工具返回结果再决定下一步动作直到达成目标。# Agent 工具调用的核心循环伪代码 while not task_finished: thought llm.reason(history, available_tools) if thought.action call_tool: result tools[thought.tool_name].run(thought.tool_args) history.append(result) elif thought.action respond: return thought.answer诚实地讲Agent 的可靠性问题至今仍然棘手——模型可能在工具调用格式上出错可能陷入循环可能被错误反馈误导。工程化的应对是三个做好校验和重试机制、设定最大迭代次数兜底、关键路径上用人工审核收口。4.2 提示工程只是一半评估才是另一半我从大量项目里悟出一个道理可评估才能可优化。很多团队把精力全放在设计提示词上结果改来改去全凭感觉——这版好像好一点换一版又好像差一点最后没法判断谁是对的。正确的做法是先建评估集。你准备 50200 个有代表性的真实问题每个问题标注期望的答案要点形成一个 golden set。每次修改 prompt、换模型、改 RAG 参数都跑一遍这个评估集观察通过率的变化。评估落地有两条路规则评估检查答案中是否包含关键实体、关键短语适合答案比较确定的场景LLM-as-Judge用另一个能力较强的模型按你给定的评分标准给答案打分适合开放式问答LLM-as-judge 不是完全可靠的它也存在偏好偏差、对事实错误不够敏感的问题。我的做法是两者结合规则先筛一遍明显不合格的大模型再对通过的项目做质量评级。另外定期从线上用户反馈中抽一份新样本加入评估集防止评估集跟真实场景逐渐脱节。4.3 上下文工程与模型选型Prompt、RAG 参数、工具调用这些都属于一个更大的概念——上下文工程context engineering。简单说你决定让模型看到什么几乎决定了它输出的质量上限。实践中要注意的几个点把用户问题包装成结构化指令时系统提示词应明确角色、任务边界、输出格式、知识盲区时该怎么办检索出的文档片段要按相关性排序并在提示模板中明确只能基于以下资料回答资料不足以回答时直接说明上下文长度不是越多越好垃圾进垃圾出检索结果超过 5 条以后边际效益会急剧下降模型选型现在也很有讲究。不是最贵的模型就适合所有场景模型类型适用场景注意事项超大参数旗舰模型复杂推理、代码生成、多语言成本高、延迟高适合关键链路中等规模模型日常问答、分类、信息抽取成本和效果平衡较好小型本地模型私有化部署、离线环境能力有限需要精心调优和更大上下文管理嵌入模型RAG 向量化与主模型独立选型关注语言和领域匹配选型没有绝对标准最好的办法是拿着你的评估集在候选模型上跑一遍看效果和成本交叉点在哪里。这个过程会逼你养成一套自己的模型评估习惯也是工程量感的重要来源。5. 工程化落地从本地脚本到可靠系统的四道坎项目原型跑通了是第一步要成为可交付的系统还差得远。我总结为四道坎可复现性、测试、可观测性、部署。5.1 依赖与可复现性管理AI 项目最大的特点就是结果受环境影响Python 版本不同、CUDA 版本不同、依赖库版本漂移都可能导致结果变化。甚至同一个模型文件在不同架构的机器上推理结果都可能有一丁点差异。工程上的对策是用锁文件锁定依赖精确版本记录实验相关的所有元数据数据版本、模型版本、代码 commit hash、关键参数、运行环境输出目录按实验命名规范归档这里说实话很多团队一上来就整 MLflow、Kubeflow 这类重型平台结果运维成本比实验本身还大。我更推荐渐进式方案先用一个 CSV 记录每次实验的参数和结果再配合目录命名规范当项目发展到需要多人协作、大量对比实验时再引入专门的实验追踪工具。工具永远是为流程服务的流程不清晰之前工具只会添乱。5.2 测试你的 AI 代码不只是单元测试传统软件的单元测试在 AI 项目里当然要做——工具函数、数据解析、API 封装都需要确认逻辑正确。但 AI 项目额外需要两类特殊测试数据质量测试写入一个校验数据的函数比如列数量、缺失率、数值范围、类别取值集合。数据源头一变测试第一时间报警。模型回归测试拿固定评估集给新旧模型各跑一遍保证新模型没有把老的能力搞退化。这跟传统开发的回归测试一个道理只是这里的用例是问题-答案对。还有一类更贴近用户的测试叫影子测试把新模型部署在线上但只记录输出、不对用户生效与当前生产模型做 A/B 对比。这是我心中最符合工程精神的验证方式因为它用的是真实流量。5.3 可观测性日志、追踪与评估一体化AI 应用是典型的不确定系统模型偶尔说错话是常态所以你不能只靠监控系统是否崩溃来判断健康状况你必须观察到每一次请求的质量。我建议至少给每个 AI 请求记录以下信息输入参数用户问题、检索到的上下文片段ID、所用的提示词版本输出结果生成的答案、命中的工具、推理耗时性能指标延迟、Token 消耗、成本结果评价规则评分、人工反馈标记拥有这些数据之后你才能回答最近准确率为什么下降了这类灵魂拷问。像 Langfuse、LangSmith 这类工具提供了现成的追踪和标注面板项目早期就能接上成本不高收益巨大。如果你不想引入额外服务也可以用结构化日志和定时任务做评估报表效果差不多只是可视化差一些。5.4 部署模式批处理、在线推理与流式输出不同的业务场景对应不同的部署模式让我用几句话分别说清楚离线批处理适合数据分析、报表生成、定时摘要等任务。特点是数据一次性灌入任务串行或并行跑完结果落库。实现最简单直接用 Python 脚本加定时调度。在线推理用户请求实时到达需要低延迟响应。通常用 FastAPI 包一层 HTTP 服务路由到推理逻辑。要注意模型加载一次常驻内存、请求队列和超时策略、并发上限保护。流式输出让模型一个字一个字或一段一段输出体验更好。实现上需要把流式接口如 SSEServer-Sent Events从后端一路透传到前端。# FastAPI 流式输出示例片段 from fastapi import FastAPI from fastapi.responses import StreamingResponse app FastAPI() app.post(/chat) async def chat(request: dict): def generate(): for token in llm.stream(request[message]): yield fdata: {token}\n\n return StreamingResponse(generate(), media_typetext/event-stream)部署层还有一个最容易忽略的点提示词和模型参数的配置化管理。我见过太多团队把 prompt 硬编码在代码里产品经理想调一句话都得发版。正确做法是把 prompt 模板放在配置文件或数据库里线上支持热更新发布代码和调 prompt 解耦。这样可以快速迭代优化出错时也方便回溯版本。6. 我给自己排的一条可执行的实战路线附避坑清单理论讲再多不如动手下面这条路线是我在设计这份内容时结合实际经验梳理出来的。如果你拿到这份专栏不知道从哪下手直接照着走。6.1 三个月阶段划分与项目建议第一阶段约第 1 个月夯实数据与基线能力每天保证 1~2 小时写代码。动作包括用 pandas 处理一份真实数据如某城市的共享单车骑行记录完成清洗、统计、可视化训练逻辑回归和随机森林两个模型用交叉验证对比效果写一份实验记录文档。第二阶段约第 2 个月打通一个深度学习闭环选一个中等规模的数据集上面推荐的三个任选其一用 PyTorch 实现数据加载→训练→评估→调参完整流程尝试至少三种优化手段调整学习率、增加层宽层深、加入丢弃层或正则化并把每次实验的效果记录在表格中。第三阶段约第 3 个月完成 2~3 个 LLM 应用原型第一个做 RAG 问答用自己的资料库比如个人博客文章、公司产品文档搭一个知识问答服务第二个做一个具备工具调用能力的最小 Agent让模型能查询 SQLite 里的数据并回答相关问题第三个可以根据前两个遇到的问题自选方向比如重排序优化、多轮对话记忆。每个原型都按评估集 部署接口 记录日志的工程标准来做不要只停留在 notebook 演示。6.2 阶段目标与心态调整这里我想多说两句因为实操中最容易崩溃的恰恰不是技术点而是心态。你会发现 RAG 检索回来的片段明明是对的模型还是答非所问你会遇到调了一下午学习率效果反而更差你会遇到部署时环境报错网上搜到的解决方案又与其他库冲突。所有这些都是正常现象。我观察到一个规律能在 AI 工程这条路上走远的人不是学得最快的人而是把问题拆小、一次只解一个、并且坚持记录的人。每次遇到报错把报错信息、当时的环境、尝试过的方案都记在笔记里三个月后你就有了一份属于自己的排错手册这份手册的实用价值远高于任何付费课程。6.3 资源筛选原则最后分享一个重要判断标准官方文档 教程文章不会过时、准确、有例子。建议把官方文档当第一资源。一个领域只选一本书或一门课学透网上信息太多容易陷入收藏了许多内容但什么都没学会的状态。写代码时以开源项目的源码和 README 为参照比看转述的评价文章更直观、更真实。远离包装味浓厚的营销性课程和刷屏短视频它们往往把复杂问题过度简化学习后遇到实际问题依然毫无头绪。我平时也会定期去 GitHub 刷一些高星的 AI 工程相关项目观察它们怎么组织代码、怎么写 README、怎么处理测试和部署这比任何速成班都有用。7. 每天都值得做的三件小事如果要在众多建议里再提炼几条我建议你从今天开始养成这三个习惯。第一每天跑一段最小代码。无论多忙保持手感和对工具链的熟悉。AI 工程的上手门槛不算高但生疏得非常快尤其工具链更新频繁。第二每天记录一个错误和它的解法。不用写长篇把报错关键词、环境信息、解法链接存下来就行。我亲测这个习惯让第二年的排错效率提升了一倍以上那些当年折腾一下午的问题后来往往扫一眼笔记就能定位。第三每周用真实项目向自己提问一次。比如这个 RAG 方案在 1000 篇文档时没问题到 10 万篇文档时检索延迟会不会崩这个 Agent 如果用户输入了恶意指令尝试连调用内部 API 怎么办模型的输出如果被截断了系统能不能感知并自动重试这些问题没有标准答案但逼自己去想一遍能力增长比读十篇文章都有效。我在整理这份ai-engineering-from-scratch路线时最大的体会是这条路不缺资料缺的是结构化的路线和持续动手的习惯。希望这篇内容提供的框架刚好够你迈出第一步。你在跟着实践的时候碰到具体报错或者拿不准的选型欢迎在评论区留言我看到之后会尽量回复。