做了三年 AI 工程，带过团队，也招过人，我越来越清楚一件事：绝大多数在这个领域卡住的人，缺的从来不是数学或者模型知识，而是一套能把想法稳稳当当变成产品的工程化能力。这个仓库标题“ai-engineering-from-scratch”听起来很宏大，但它想说的其实就一句话：别急着追最新的模型，先把从数据到部署的整条链路走通。这篇文章就是把这几年我从零搭建 AI 工程能力时踩过的坑、沉淀下来的方法、反复验证过的路线，一次讲清楚。

我不会给你画一个需要学三年的完美路线图，那玩意没人能执行完。我只会告诉你，哪些知识是真正会用到的，哪些工具是真正绕不开的，怎么在三个月内跑通第一个能上线、能迭代、能监控的 AI 项目。无论你刚入门、还是已经在算法岗想转型做工程，这套从零开始的打底思路都值得参考。

1. 先搞清楚 AI 工程和算法研究是两码事：很多人的起点就偏了

面试过不少候选人，简历上写着精通 TensorFlow，会调 ResNet，但对“模型怎么上线”“接口超时了怎么办”“训练数据和线上数据分布不一致如何发现”这些问题一问三不知。这不是他们笨，而是很多人把 AI 工程误当成了算法研究，从一开始就走错了方向。

1.1 从 notebook 到生产，中间隔着一整条流水线

算法研究的目标是证明某个方法在某个数据集上有效，评价标准是精度、召回率这类指标。但 AI 工程的目标是让模型在一个真实系统里持续稳定地产生价值，评价标准是可用性、可维护性、成本和风险。

打个比方：算法研究员像是研制新菜谱的厨师，重点是这道菜味道好不好；AI 工程师像是开连锁餐厅的运营，你要考虑的不只是菜好不好吃，还有食材供应稳不稳定、后厨出菜快不快、每个分店的出品能不能保持一致、食客投诉了怎么处理。菜谱可以很惊艳，但支撑不起一套连锁体系，照样白搭。

反映到具体技能上，AI 工程至少包含这么几块：

• 数据工程：数据获取、清洗、校验、版本管理、特征存储
• 模型工程：训练、调参、实验追踪、模型评估、模型注册
• 部署运维：容器化、API 服务、弹性伸缩、监控告警、日志采集
• 反馈闭环：线上预测结果回流、定期重训、异常检测、业务效果分析

你发现没有，真正花时间的反而是那些看起来“不性感”的部分。模型训练可能只占一个项目周期的两成时间，剩下的八成全在跟数据、跟环境、跟稳定性较劲。

1.2 AI 工程师的核心交付物不是模型，而是系统

我见过太多团队，算法工程师交出一个 95% 准确率的模型文件就觉得自己完成任务了。结果模型要嵌入业务系统时，发现几个要命的现实问题：

• 模型文件两个 G，线上服务加载要十几秒，用户根本等不了
• 训练时用的 pandas DataFrame 处理特征，上线时要改成实时计算，逻辑根本对不上
• 模型对某个用户群体表现很好，但对新用户效果奇差，因为训练数据里新用户占比太低
• 没有埋点、没有日志、没有监控，模型悄悄退化了一个月都没人发现

这些都是典型的“模型能跑，系统不能用”。AI 工程师的职责，就是把这些脏活累活扛下来，把模型放进一个可靠的系统容器里。

所以在“ai-engineering-from-scratch”这个项目里，第一个要建立的认知就是：你的交付物是一个端到端的系统，模型只是这个系统里的一个组件。这个转变得越早，你的成长速度越快。

2. 从零起步的地基：数学、Python 和数据基础到底学到什么程度才够

很多零基础的朋友一上来就问：要不要先把高数、线代、概率论系统学一遍？我的答案很直接：不用等学完再动手，但也不能完全跳过。你需要的是“够用”的数学直觉，而不是推导能力。

2.1 数学和 Python 的“够用”标准，比你想的简单

先说数学。90% 的日常 AI 工程工作用到的数学知识，没有超过这个范围：

• 线代：矩阵乘法、转置、向量内积。理解特征向量最好，不理解也不影响调模型
• 概率统计：期望、方差、正态分布、条件概率。做 A/B 测试和评估时必须有直觉
• 微积分：导数、梯度。理解梯度下降是怎么回事就够了，链式法则只要知道有这回事
• 信息论：交叉熵、KL 散度。出现在损失函数里，理解一个大概即可

我的建议是：不要花三个月去啃教材，直接找一门讲得清楚、偏应用的课程刷一遍，把关键概念过一遍，然后立刻进入项目。做项目时碰到看不懂的公式再回头查，那个时刻的查漏补缺效率最高。

再说 Python。AI 工程对 Python 的要求有两层。第一层是基础语法，循环、函数、类、列表推导式，这个老老实实花一两周过一遍。第二层是工程习惯，这才是拉开差距的地方。我在团队里带新人时，最头疼的不是代码报错，而是：

• 不在虚拟环境里装包，结果不同项目互相污染依赖版本
• 写脚本不拆函数，全是一千行的面条代码，没法测试没法复用
• 不写单元测试，改了一行预处理逻辑，跑完训练才发现数据全错了
• 不用类型注解，数据接口的字段是整数还是浮点数全靠猜

说实话，很多有两年经验的工程师都栽在这些事上。所以零基础起步，Python 语法学完后，请立刻把虚拟环境、类型注解、pytest 单元测试、代码模块化这几样刻进肌肉记忆。

# 每个项目都该有的起点：独立虚拟环境 python -m venv .venv source .venv/bin/activate # Windows 下用 .venv\Scripts\activate pip install -r requirements.txt

2.2 数据敏感度：注定你天花板高度的隐性能力

AI 工程师和软件工程师最大的能力分水岭，在数据敏感度。软件工程师面对的是确定性的代码逻辑：输入这样的值，输出那样的值。AI 工程师面对的是统计性的数据分布：同样一个预测接口，今天的输入分布和昨天的就可能不一样，模型的效果就会悄悄变化。

所以从零开始培养数据敏感度特别重要。我建议所有入门者都认真练两件事：第一，拿到任何数据集，先做探索性数据分析（EDA），把缺失值比例、分布形态、异常值、特征相关性全部摸一遍，再看要不要开训练；第二，养成“数据校验强迫症”，每次跑训练之前，写一个数据验证脚本，检查字段是否齐全、类型是否正确、值域是否合理、新增值是否出现在训练分布之外。

这些习惯一开始看起来很繁琐，但它们是 AI 工程的核心能力。模型效果差，绝大多数时候问题出在数据质量上，而不是算法上。能一针见血指出数据问题的人，在团队里的价值比多调出两个点的精度高得多。

3. 跑通第一个端到端项目：三个月，请死磕这条完整链路

基础打底之后，最多花三个月，你必须跑通一个完整的 AI 项目。这里的关键词是“完整”，不是“先进”。我强烈建议第一个项目选表格型数据的预测任务，比如客户流失预测、房价估算、销量预测，而不是图像分类或者自然语言处理。

原因很现实：表格型任务的数据处理链路最典型，跟生产环境的 SQL 表、业务数据仓库贴得最近；模型选择不需要太花哨，XGBoost 或者 LightGBM 就够了；部署推理的延迟和资源开销都很友好。你得以把八成精力花在工程的完整度上，而不是被模型结构和算力卡住。

3.1 连滚带爬也要走完的七步闭环

第一步，定义问题。这不是废话。客户流失预测，你要先搞清楚“流失”怎么定义：是三个月没下单？还是取消了订阅？不同定义直接决定标签怎么打，模型学的东西完全不一样。我在项目开工标准文档里固定有这几项：业务目标、预测对象、正负样本定义、预测周期、评估指标。

第二步，建数据管道。别用网上下载好的 CSV 当玩具，最好直接连一个真实的业务数据库。用 SQL 把训练集提取出来：用户特征、行为特征、时间窗口、标签列。这一步非常关键，因为往后每次要重新训练，你都得重新跑这条管道。

第三步，EDA 和特征工程。画出目标变量的分布，处理缺失值，构造跟业务强相关的特征。比如做流失预测，最近一次下单距离今天的天数、近三个月下单频率的变化趋势，这类特征往往比一堆原始字段拼接起来有效得多。

第四步，建模和实验追踪。用一个公共的评估集，保证每一次实验都在同样的数据上比较。每跑一次实验，把参数、指标、特征列表完整记录下来。这一步养成习惯，后面迟早救你的命。

import xgboost as xgb dtrain = xgb.DMatrix(X_train, label=y_train) dvalid = xgb.DMatrix(X_val, label=y_val) params = { "objective": "binary:logistic", "max_depth": 6, "eta": 0.03, "subsample": 0.8, } model = xgb.train(params, dtrain, num_boost_round=500, evals=[(dvalid, "valid")])

第五步，模型评估和解释。别只盯 AUC，打开预测分布看：阈值取多少的时候精确率和召回率分别什么样？模型对哪类用户分不清？用 SHAP 之类的工具看一眼特征重要性，确认模型学到的逻辑跟业务直觉对得上。模型学出“下单金额越高的客户越可能流失”这种反直觉规律时，别急着相信数据，先看看是不是特征没有处理好。

第六步，包装成服务。写一个 FastAPI 应用，加载模型文件，接收特征输入，返回预测概率。注意把所有预处理逻辑封装在同一个类里，训练时怎么处理特征，线上就怎么处理，绝对不要在接口里临时写一套新的转换代码。

from fastapi import FastAPI from pydantic import BaseModel import joblib import pandas as pd app = FastAPI() model = joblib.load("model.joblib") class Features(BaseModel): recency_days: float order_freq: float amount_avg: float @app.post("/predict") def predict(features: Features): df = pd.DataFrame([features.model_dump()]) prob = model.predict_proba(df)[0, 1] return {"probability": round(float(prob), 4)}

第七步，上线和监控。先用 Docker 把服务包起来，用日志记录每一次请求的特征、预测结果、响应耗时，再设几个监控指标：请求量、平均延迟、预测概率分布。预测概率分布这个指标特别重要，如果某天线上请求的预测结果普遍偏高或偏低，大概率是输入分布变了，或者上游特征数据出错，这是模型开始退化的第一信号。

3.2 第一个项目最容易翻车的地方，提前给你踩掉

第一个项目，你大概率会在三个地方摔跟头，我先说出来让你有心理准备。

第一，训练集和线上请求的数据口径不一致。典型情况是训练时用了未来信息，比如用包含当天的特征去预测当天是否流失，这在离线评测里看不出问题，上线后效果就会崩。解决办法就是非常严格地切割时间窗口：只能用预测时刻之前的数据构造特征。

第二，预处理逻辑不统一。标准化、缺失值填充、类别编码这些操作，训练和推理必须共用同一套代码。我团队现在强制要求把特征工程写成一个类，训练时调用一次，部署时加载同一个类，不允许复制粘贴两份相同的逻辑放到不同位置。

第三，模型的输入输出没有契约。线上服务要接业务系统，但业务系统传过来的字段名跟训练数据对不上，类型也对不上。所以接口要做好字段校验，宁可报错也不能让脏数据悄悄进入模型。

4. 工程化的五个核心环节：模型调参之外的真正分水岭

第一个项目跑通之后，恭喜你，你已经是个能交付单体 AI 服务的工程师了。接下来要攻的方向，是把这些流程固化下来，让 AI 系统具备“工程级”的稳定性。这一节我认为是整个项目里含金量最高的部分。

4.1 实验管理：没有记录就等于没有做过

很多人的实验管理方式是用文件名：model_v2_final_final2.pkl。跑了几十轮实验之后，想搞清楚哪一个版本的准确率最高、当时用了什么参数，结果根本无从查起。这个习惯必须尽早改掉。

现在业界最通用的方案是 MLflow，它把实验追踪、模型注册、模型服务三件事整合在一起。我个人的使用方式是：每个项目建一个 experiment，每次运行自动记录代码版本、git commit、参数、评价指标、模型文件路径；训练结束后把效果最好的模型注册到 Model Registry，打上 production 标签，部署时直接从注册表拉。

import mlflow mlflow.set_experiment("customer_churn") with mlflow.start_run(): mlflow.log_params(params) mlflow.log_metric("val_auc", 0.86) mlflow.log_artifact("feature_list.json") mlflow.xgboost.log_model(model, "model")

这个工具的好处是：你可以随时回答三个问题。当前线上的模型是哪个版本？它的训练数据是什么？它和上一版相比指标发生了什么变化？回答不出来任何一个，都不配叫一个成熟的 AI 系统。

4.2 数据版本和特征存储：花钱花时间最多的地方

模型依赖数据，数据一直在变。如果你不把数据版本管起来，三个月后想复现当时的效果，可能连数据都找不到了。DVC（Data Version Control）是这领域最常见的工具，底层用 Git 管理小文件，用对象存储管理大文件，你可以在任意一个 commit 上找到当时对应的数据快照。

特征存储也值得认真对待。一个成熟点的系统，线上线下的特征计算逻辑完全一致，特征结果集中管理、缓存复用。现在很多团队用 Feast 来处理这块，不过如果你刚起步，我建议别急着上重工具。先把特征定义统一成一份可继承的配置文件，训练和线上复用同样的 schema，效果也不差。复杂工具解决的是大规模协作问题，一个人跑项目用不上。

4.3 模型评估与鲁棒性：线上和线下唯一的交汇点

离线评估和线上真实效果之间存在一条永远填不平的鸿沟。你离线考了 99 分，上线上被打得满地找牙，这种经历几乎人人都有。原因无非是离线评估集和线上数据分布不同，或者评估指标和业务目标不一致。

我现在的做法是评测集一定要留出跨时间段的数据，模拟未来预测场景；评测指标除了常规准确率，一定要加业务指标。做推荐系统的拿 CTR 做指标，那离线评估就看预测结果排序后的 TopK 命中率；做风控的，那指标就是坏账率和拦截率，精度只是一个中间量，真正该盯的是最终业务结果。

鲁棒性测试也值得做：给输入特征加一点微小扰动，看输出会不会剧烈抖动；把某些特征设成缺失，看模型是否还能给出合理结果；换一批新用户，看模型输出是否分布异常。这些测试技术含量不高，但能提前暴露大量上线隐患。

4.4 推理优化：别让好模型死在延迟上

模型准确率再高，如果接口响应 2 秒，业务方照样会把你打死。推理性优化是 AI 工程里非常现实的问题，几个常用手段按性价比排序：

我给团队最常见的方案是：先用 profiling 工具找出耗时瓶颈，如果瓶颈在特征计算，优先做特征缓存；如果确实在模型推理本身，再上模型优化。永远不要为了优化去优化，先确认瓶颈在哪。这里有个很多年资深工程师都会犯的错：一上来就觉得模型太慢，结果查完发现 70% 的时间花在特征拼接和网络传输上，模型推理只占 30%。

4.5 模型监控：模型需要喂养，需要体检

模型不是上线就完事的资源，它需要喂养，需要日常体检。需要监控的维度至少有三个。数据漂移：对线上输入特征做分布统计，和训练分布对比，比如训练数据里用户年龄中位数是 35 岁，上线一段时间变成 42 岁，模型的表现会自然退化；概念漂移：数据分布没变，但输入和标签的关系变了，比如消费习惯变了之后，“高消费”的定义和流失的关系彻底改变；性能指标：每天算一遍真实业务指标，比如预测准确率、覆盖率、转化率，低于阈值就自动告警。

我见过太多业务团队的悲伤故事都是这样的：模型跑得好好的，连续一个月没出问题，然后突然有一天业务方过来说效果变差了。一查原因，原来是运营调整了产品策略，界面上多了一个引导按钮，老用户的特征分布全部变了。没有监控，这种问题至少要半个月之后才会被人发现，而修复损失已经不可估量。

5. 进入生产环境：从单人项目到团队系统，需要跨越的四个台阶

到这里，你已经能把一个数据管道、模型服务、监控告警组成的“微型系统”跑起来了。但如果要把它变成多团队协作、持续迭代的生产级系统，还需要再往上跨几个台阶。这一节的四个内容，是我建议所有“从零开始”的人至少要知道、最好能动手搭一遍的。

5.1 CI/CD for ML：机器学习和软件工程的正式握手

传统的软件 CI/CD 关注的是代码集成和部署，ML 系统还要多管两层：数据和模型。ML 流水线的 CI 阶段要跑数据校验、特征逻辑的单测和模型评估；CD 阶段要把模型部署到 staging 环境，自动做一次冒烟测试，确认接口输入输出正常后，再推送到生产。

现在比较主流的落地方式是 GitHub Actions 加上自定义脚本，或者用 Kubeflow、Airflow、飞中的 Pipeline 做编排。对初学者，我不建议一开始就上重型编排工具，而是先自己写一套 Python 脚本加 shell 的流程，把训练、评估、打包、部署串联起来。跑通一遍之后，你才会知道每一步真正依赖什么，这时候再去学流水线工具，理解会完全不一样。

# 一个极简单的 ML CI 流程示意（GitHub Actions） name: train-and-evaluate on: pull_request: paths: - "data_checks/**" - "features/**" - "models/**" jobs: run-pipeline: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Set up Python uses: actions/setup-python@v5 with: python-version: "3.11" - name: Install dependencies run: pip install -r requirements.txt - name: Run data checks run: python -m pytest tests/test_data_checks.py - name: Run training pipeline run: python pipelines/train.py --config configs/baseline.yaml

很多算法工程师第一次看到这套东西会觉得很繁琐，但当你需要每周更新一次模型、并且不能影响线上稳定的时候，这套流水线的价值就会成倍放大。

5.2 用容器和资源管理兜住服务的底线

AI 服务的资源需求比一般 Web 服务高得多。模型加载吃内存，批量推理吃 CPU/GPU，训练吃显存。不加以管理，一个内存泄漏的模型服务能拖垮整个节点。

我的最低标准是：所有 AI 服务必须容器化，Dockerfile 里明确指定基础镜像和依赖；在 Kubernetes 集群里为每个模型服务声明 CPU、内存、显存请求，加上自动扩容规则；如果单个模型服务没有 GPU 需求，就不要让它申请 GPU 资源，把 GPU 节约给真正需要训练的任务。

这里还有个经验：模型服务的内存占用是动态的。加载一个 500MB 的模型，初始只占一点内存，但一次请求可能触发预处理缓存、特征拼接，内存峰值能翻一倍。所以给容器设置资源上限时，一定要压测出真实峰值，再乘以 1.5 留出安全余量。

5.3 从预测到决策：给业务方一个可解释的输出

生产级 AI 系统跟业务系统协作时，一个经常被忽略的点是：业务方需要的不是一个概率数字，而是一个能指导他们行动的决策。你跟运营说“这个用户流失概率 0.87”，运营只会愣住。你跟运营说“该用户今年以来订单量下降了 40%，最近一次下单在 60 天前，建议优先发送召回优惠券”，运营立刻就知道下一步做什么。

所以工程上要把模型输出包装成决策信息：预测结果加解释文本，说明是哪些特征触发了这个预测；预测结果加置信区间，让业务方知道哪些预测可以放心执行；预测结果加建议动作，由规则引擎根据预测结果和执行成本自动推荐。

做到这一步，AI 系统才算真正嵌入业务闭环，而不是一个没人看的“技术玩具”。

5.4 大模型时代的 AI 工程：Prompt 和评估的版本管理

这几年 LLM 爆发，把 AI 工程的热度又推向一个新的高点。很多人觉得大模型时代不需要传统的 AI 工程了，反正调个 API 就行。这是非常错误的想法。大模型应用一样需要工程化，甚至更依赖工程化。

LLM 应用工程的核心挑战不是训练模型，而是围绕 Prompt 构建可控的系统。你的业务逻辑片段分散在 Prompt 词句里，Prompt 改了，效果就变；模型版本换了，行为也变。没有一套工程体系去管理，这个系统就是一团乱麻。我的建议是三类东西必须纳入版本管理：一是 Prompt 模板，保存每个版本的内容、变更人和变更原因；二是模型参数配置，temperature、max_tokens、top_p 这些值必须和 Prompt 配套记录；三是评估集，LLM 应用的评估比传统模型更主观，更需要一个固定的评估集来跑分回归。

RAG 架构里还要多管一个环节：知识库的版本和切分策略。文档改了，向量库要重建；切分粒度变了，检索结果的命中率就会大变。所以向量库的更新也要纳入流水线，不能拍脑袋手跑。

我自己现在的团队，LLM 项目的实践日志、Prompt 版本、评估报告全部进同一个平台，跟传统模型的实验管理放在一起。只有这样，才能回答老板的灵魂拷问：上礼拜那个对话效果为什么变差了？答案会是：因为运营周五改了产品话术，Prompt 版本 2.7 的评估分掉了 8 分，但还没走审批。规范化的工程体系，让所有问题都可以被追溯和回答。

6. 从零开始时最容易踩的六个坑，我替你一个个踩过了

这个项目做到后期，沉淀下来的最有价值的东西其实就是这些坑。我差不多每条都栽过，这里全拿出来。

第一个坑，是过早追求复杂。刚开始总想用最先进的模型、最深的结构去解决最简单的问题。用 XGBoost 就能稳的其他，非要上一个深层模型，结果一个没有显卡的半夜，模型训练到一半 OOM，第二天人还在救火。事实是：对绝大多数结构化数据任务，GBDT 体系统仍然是最可靠的第一选择；对图像、文本、音频这些非结构化数据，也别一开始就刷最大模型，先把能用的预训练模型跑通，再逐步提升。

第二个坑，是忽略数据质量直接调参。我见过一个团队花了一周时间调模型的超参数，准确率死活上不去，最后发现训练数据里有一列是未来数据，整个标签被污染了。先做数据体检，再谈优化，这个顺序不能反。

第三个坑，是不做评估集直接上线。有一次我把一个模型改了一点特征，结果评测集里没有覆盖到新特征的关键业务场景，上线后这类场景的效果暴跌。从那以后，我的评估集一定会按业务场景分层抽样，确保每个重要场景都有足够的样本，并且在模型更新之前必跑一遍回归对比。

第四个坑，是手动复制模型当版本管理。一个模型文件全靠文件名区分版本，一天改了 20 次，文件名从 v1 一路膨胀到 v_final_8_newest_really。换用 MLflow 之后，我才意识到之前那种方式浪费了太多不必要的力气。任何手动流程都不可靠，实验管理工具不是负担，是救命绳。

第五个坑，是不做上线后的监控。我一直认为最贵的错误就是上线之后没人管的错误。又一个模型上线后没人盯，三个月后业务方反馈效果差到不行，查下来发现输入特征里的一列从月份改成日期格式，模型直接用排后的数字做了预测，整条链路都歪了。上线标配三个监控项：接口健康检查、特征分布漂移检测、业务效果日报，缺一项都不行。

第六个坑，是忽略可解释性。模型越复杂，业务方越不敢用。你做出来的东西很准，但如果没法告诉他们“为什么这个用户被打上高风险标签”，他们就只能把你的预测当参考意见，而不是可以依赖的决策依据。所以从一开始就要把特征重要性和样本解释纳入交付物，让每一个预测都能讲出一个让业务方点头的故事。

说实话，做 AI 工程这些年，我最大的体会是：技术更新换代的节奏很快，今天热门的东西过两年可能就过时了，但工程化的底层方法反而是稳定的——对数据保持敬畏，对系统保持严谨，对业务保持好奇。从零开始从来不是一个一蹴而就的口号，它是一条每一步都要踩实的路。每次跑通一个新的工程环节，回头看看已经被自己驯服的系统，那种踏实感，比刷多少个榜单成绩都让人上瘾。希望这篇梳理能让你在这条路上少走弯路，更希望你能在一次次的完整性交付里，找到属于自己的工程直觉。