企业官网建设流程全解析

坦白说，现在搜“ai-engineering”，出来的内容十有八九是“用AI写代码”或者“调API跑个demo”，真正讲工程化落地的少得可怜。你点进这个标题，大概率是和我当年一样的处境：Python 能写，模型能训，论文里的 Trick 也能复现，但真要把一个东西从 Notebook 里搬到线上，让其他人能稳定调用，心里是完全没底的。

ai-engineering-from-scratch 这个项目，核心解决的就是这个问题。它不教你发明新算法，不带你刷论文，而是把 AI 应用落地的那条完整链路——数据获取、特征工程、模型训练、评估验证、服务化部署、线上监控——当成一个系统工程来学。这条路适合两类人：一类是算法出身、想补工程能力的；另一类是后端或全栈出身、想往 AI 方向转的。无论哪类，目标都一样：做出一个能真正跑在线上、能被别人用的 AI 系统，而不是一个躺在 Jupyter 里的 ipynb 文件。

接下来这篇文章，我把自己做这个项目时踩过的坑和沉淀下来的方法全部拆开讲。不搞那种“三十天精通”的鸡血路线，只讲怎么一步步从零把工程能力补起来。

1. 先搞清楚：AI 工程到底在解决什么问题

1.1 算法工程师和 AI 工程师的差别在哪

很多人对 AI 工程有个误解，觉得它就是“用框架把模型跑起来”。真不是。算法工程师和 AI 工程师的日常工作重心完全不同，你自己对号入座一下就知道缺哪块了。

算法工程师的考核指标是模型精度：AUC 涨了多少、BLEU 涨了多少、错误率降了几个点。他们的战场在数据集、特征、模型结构、损失函数这些地方，交付物是“一个效果更优的模型”以及对应的实验记录。

AI 工程师的考核指标是系统的可用性：接口延迟 P99 是多少、服务能不能扛住流量、模型上线后指标有没有掉、数据分布漂移能不能及时发现。他们关心的是“模型产出怎么变成业务价值”，交付物是“一个稳定运行、可观测、可迭代的服务”。

我见过不少算法很强的人，到了工程环节就抓瞎。那个模型确实好，但你要他把它做成一个 HTTP 接口，他不知道怎么加载模型、怎么写预处理逻辑、怎么处理并发请求；你要他在线上出问题的时候排查，他不知道该看日志还是看监控。反过来，很多工程能力很强的人，对模型怎么调参、特征怎么处理又没有感觉。AI 工程要补的，就是这条裂缝。

打个比方。算法工程师像研发新菜的厨师，锅气、火候、摆盘都在行；AI 工程师像开餐厅的老板兼主厨——你不仅要会做菜，还得管供应链、算翻台率、处理差评、培训后厨。菜品研发只是餐厅运营的一个环节，而不是全部。

1.2 从零开始，你需要练成哪些底层能力

既然标题是 from scratch，我们就先把“零基础”到底指什么说清楚。我默认你至少会 Python，知道什么是类、什么是函数、能写点数据处理脚本。如果连这个都不太熟，第一优先级是补 Python，不用学成专家，但至少要能流畅地把想法写成代码。

具体来说，以下几项能力是 AI 工程的地基：

• Python 语言本身：不是会写 for 循环就算会，要理解装饰器（写中间件、做限流的时候会用到）、生成器（处理流式数据）、类型提示（让别人能维护你的代码）、虚拟环境管理（搞过环境冲突的都懂这里有多痛）。
• Linux 基本功：AI 工程几乎不可能完全脱离 Linux。文件权限、进程管理、查看 GPU 状态、写 Shell 脚本跑批处理任务，这些是日常操作。不需要背命令，但要达到“打开终端不慌”的程度。
• SQL 和数据访问：线上系统的数据百分之七八十存在数据库或数据仓库里，只会 Pandas 不够。至少能写多表 JOIN、GROUP BY、子查询，能在几千万行表里把要的数据捞出来。
• 基础的数学直觉：我后面会细讲，这里先提一句——不需要会证明定理，但得看懂损失函数的公式、知道梯度下降在干嘛、明白正则化为什么能防过拟合。

很多人一上来就急着学 PyTorch、学 Transformer，这其实是本末倒置。工程化的核心是先有“把整个链路走通”的骨架，再往里填模型和算法的血肉。地基没打牢，后面补起来会非常痛苦，我见过太多人在部署环节被环境问题折磨得怀疑人生，本质就是 Linux 和虚拟环境这块基础没打扎实。

2. 学习路线怎么搭：把“全链路”拆成可执行的阶段

2.1 基础知识不是万能，但够用就好

AI 工程涉及的知识面很广，如果你试图什么都学会再动手，那你永远动不了手。正确的策略是：够用就好，按需学习。

数学就是一个典型。学 AI 相关的东西，线性代数、概率论、微积分都有用，但用处不一样。工程实践里，你不用手推反向传播，也不必证明收敛性，但你得知道学习率太大会震荡、太小会慢到怀疑人生，得知道过拟合是什么现象、正则化是怎么抑制它的，得理解为什么归一化特征能让训练更稳。这些直觉，在调参和排查问题的时候直接决定你的效率。

机器学习经典模型也要过一遍。逻辑回归、决策树、GBDT 家族（XGBoost / LightGBM）、K-Means 这些，在表格类数据场景里依然是工业界的主力，很多深度学习模型不好解决的业务问题，一个调好参数的 GBDT 就搞定了。深度学习方面，CNN、RNN、Transformer 的基本结构要清楚，尤其是注意力机制到底在干什么，这是理解现在一切大模型的基础。

我的建议是：数学不用啃大部头教材，找一个讲机器学习的公开课，跟着把公式推导过一遍，碰到不懂的再回去查，效率远高于先学三个月数学再回来学 AI。做工程的人不需要当数学家，但需要能跟数学家对话。

2.2 一个可以直接抄走的六个月路线

如果你问我从零开始到具备基本的 AI 工程能力要多久，我的答案是六个月，而且这六个月是按照每周投入十小时以上来算的。这条路线我自己带人走过，也调整过好几轮，可以直接照着做。

第一阶段的目标不是学会所有模型，而是熟悉“数据怎么处理、模型怎么训练、结果怎么评估”这一套流程。第二阶段开始接触深度学习框架，理解张量、自动求导、DataLoader 这些核心概念。很多人死在第三阶段，因为这里的问题不再是“模型准确率不够”，而是“为什么我本地能跑的服务放进 Docker 就崩了”“为什么接口一并发就超时”——这才是真正的工程问题。

2.3 为什么项目驱动比看课重要

我见过太多“看了三个月课，一问全不会”的人。看课是最容易产生学习幻觉的方式：视频里老师一行行敲代码，你跟着看，觉得自己都懂了，合上电脑什么都不会。

项目驱动刚好相反。它逼着你面对真实问题，而真实问题永远比教程复杂。举个例子：你学完 ImageNet 分类，打算做一个“图片里有没有猫”的接口。你以为难的是模型？错了。难的是你发现用户上传的图片五花八门——有人传了 PDF 截图、有人传了 3MB 的超大图、有人传了个动图。你的预处理代码要处理这些情况，模型才能正常工作。这些问题，教程里是不会告诉你的。

所以我的路线里，每个阶段都强制配一个“能拿出来演示的项目”。这个项目不需要大，不需要创新，甚至可以是网上抄的改的，但你必须把整个链路跑通。跑通一次完整链路，比看十遍教程都有用。因为只有真正跑通了，你才知道哪一环是薄弱的、哪一环是会出问题的、哪一环需要补充知识。

3. 实操核心环节：从数据清洗到模型上线的完整闭环

3.1 环境搭建：从 Conda 到 Docker 的一步到位

环境管理是 AI 工程的第一课，也是最容易翻车的一课。我见过太多人把包装到全局环境里，然后某一天某个库升级，整个项目跑不起来了。这里我把一套稳妥的实践完整写出来。

本地开发环境，我推荐 Miniconda 而不是 Anaconda。Anaconda 预装的东西太多，看着方便，实际上大部分你用不上，还会占用大量磁盘空间。装完 Miniconda 后，为你的项目建一个独立环境：

conda create -n ai-eng python=3.10 conda activate ai-eng

注意这里指定了 Python 版本，这是很多人会忽略的细节。不同项目依赖的 Python 版本可能不同，如果你不指定，conda 会用默认版本，后面很可能出兼容性问题。装依赖的时候，尽量用 conda 或 pip 都行，但不要混着乱装，尤其是不要用 sudo pip 往系统环境里装东西——这几乎是环境崩溃的头号原因。

requirements.txt一定要锁版本。我之前接手过一个项目，requirements.txt里全是numpy、pandas这种不带版本号的写法，结果换一台机器依赖解析出的版本完全不同，模型推理结果都有了细微差异。正确做法是用pip freeze > requirements.txt把所有依赖的精确版本记录下来，或者更进一步用pip-tools之类的工具管理。

然后就是 Docker。环境管理只到 Conda 这层是不够的，因为 Conda 管的是 Python 环境和包，管不了系统依赖。你的模型可能需要特定版本的 CUDA、特定版本的 gcc 运行时，这些 Conda 管不了，Docker 能管。把整个运行环境打成一个镜像，推到哪都能跑，这才是工程化的起点。

一个比较稳的 Dockerfile 写法是这样的：

# 第一层：依赖缓存层 FROM python:3.10-slim as builder COPY requirements.txt . RUN pip install --prefix=/install -r requirements.txt # 第二层：运行层 FROM python:3.10-slim COPY --from=builder /install /usr/local COPY ./app /app WORKDIR /app CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

依赖层单独放一个构建阶段，是为了利用 Docker 的层缓存机制。你改代码之后重新构建，只要 requirements.txt 没变，依赖层就不会重新安装，构建速度会快非常多。这个技巧在频繁迭代模型和代码的时候特别好用。

3.2 第一个端到端项目怎么做

环境搭好了，就该做那个真正打通全链路的项目了。我的建议是选一个简单但完整的方向：文本情感分类，或者图像分类。原因很简单：数据集公开好拿、模型结构不复杂、效果验收直观。你不需要在这个阶段追求 SOTA，能把链路跑通就是胜利。

以文本情感分类为例，完整流程是这样的：

1. 数据获取：用现成的公开数据集，比如 IMDB 影评、Kaggle 上的情感分析数据集。中文场景可以用一些开源的中文评论数据集。不要在这个阶段纠结数据量，几万条足够用了。
2. 数据清洗与预处理：去掉 HTML 标签、处理特殊字符、统一小写。做 NLP 的都知道，文本清洗直接影响效果，这个环节要仔细。
3. 划分数据集：训练集 / 验证集 / 测试集，按 8:1:1 或 7:2:1。注意要保证标签分布一致，别让某个标签在测试集里缺了。
4. 建模与训练：用 HuggingFace 的transformers库加载一个预训练语言模型（比如 BERT -base），在它的基础上做微调，不要自己从头训练。在单卡 GPU 上跑二十到三十分钟就能出不错的效果。
5. 模型保存：把模型权重和分词器都保存下来，同时记录训练时的超参数和最终评估指标。推荐都放在同一个目录下：

model_dir/ ├── config.json ├── model.safetensors ├── tokenizer.json └── metrics.json

6. 服务化封装：用 FastAPI 写一个推理接口，接受文本输入，返回情感类别和置信度。核心逻辑是把模型加载、预处理、推理、后处理封装成清晰的类或函数。

写 API 的时候有个容易忽略的细节：模型要全局加载一次，而不是每个请求加载一次。在全局初始化模型对象，处理请求时就只做推理，不重新加载权重。这个错误我踩过，加载 BERT 模型每次差不多要两秒，如果每次请求都加载，接口延迟直接爆炸。

一个最小可用的推理服务长这样：

from fastapi import FastAPI from pydantic import BaseModel import torch from transformers import AutoTokenizer, AutoModelForSequenceClassification app = FastAPI() device = torch.device("cuda" if torch.cuda.is_available() else "cpu") tokenizer = AutoTokenizer.from_pretrained("./model_dir") model = AutoModelForSequenceClassification.from_pretrained("./model_dir").to(device) model.eval() class Item(BaseModel): text: str @app.post("/predict") def predict(item: Item): inputs = tokenizer(item.text, truncation=True, max_length=128, return_tensors="pt").to(device) with torch.no_grad(): logits = model(**inputs).logits prob = torch.softmax(logits, dim=-1) label = torch.argmax(prob).item() return {"label": label, "confidence": float(prob[0][label])}

7. 容器化并自测：写完接口先本地跑起来，用 curl 或 Python 发几个测试请求确认结果正确，再写 Dockerfile 打包。测试请求时注意边界情况：空字符串、超长文本、非 UTF-8 编码，这些你都应该在代码里处理掉。

这一整套流程下来，你不仅有了一个能演示的项目，更重要的是把 AI 应用的完整闭环体验了一遍。之后再接任何新项目，流程都是通的，剩下的只是把每一环做得更深入而已。

3.3 模型部署与线上服务的常见姿势

项目跑通后，就该讨论“上线”这件事了。很多人对部署的理解就是“把接口放到服务器上”，但对工程化的部署来说，要回答的问题多得多：请求量大了怎么办、模型版本怎么更新、线上效果怎么监控。

部署方式上，我按复杂度从低到高给你排一下：

• 原型级部署：模型和 Web 服务跑在同一个进程里，适合 demo 和内部工具。优点是好写好跑，缺点是模型加载和 Web 服务耦合在一起，出问题不容易隔离。
• 独立服务部署：模型推理做成独立服务，通过 HTTP 或 gRPC 对外提供，Web 服务和模型服务分开。这是最主流的形态，扩展灵活、职责清晰，也是我推荐你重点掌握的方式。
• 平台化部署：用 Kubernetes 这类平台编排多实例服务，自动扩缩容、滚动更新、灰度发布。这是大厂的标准做法，但你个人学习阶段不用急着上。

部署环境有几个细节特别重要。一个是 GPU 版 Docker 的配置，在宿主机上要装好 nvidia-container-toolkit，然后在docker run时加--gpus all参数，容器里才能看到 GPU。这个步骤网上教程很多，但实操起来还是容易踩坑，尤其是宿主机驱动和容器内 CUDA 版本不匹配的问题。我自己的经验是：宿主机驱动尽量新，镜像内 CUDA 版本别追新，用主流稳定版本就行。

线上服务的监控是很多人会忽略的。部署上线不是终点，而是起点。你需要知道接口的延迟、错误率、请求量，还需要知道模型产出的分布有没有变化。比如你做了一个情感分析服务，上线后突然大量请求被分类为“负面”，这时候你要能判断是线上数据分布变了，还是模型本身出了问题。至少要记录每个请求的输入文本、预测结果、置信度，以及模型服务的响应时间，有了这些日志和指标，线上问题排查才有依据。

4. 工具链选型：哪些现在学，哪些以后再补

4.1 训练与建模环节怎么选

AI 工程的工具链非常碎，如果你什么都想学，会被淹没在工具的海洋里。我按自己的经验帮你分清主次：有些工具现在必须学，有些等你在真实项目里遇到问题再学也不迟。

模型训练框架，现阶段直接选 PyTorch。TensorFlow 仍然在不少存量项目里存在，而且 Keras 的简洁性确实让人怀念，但 PyTorch 的生态优势太明显了：HuggingFace 的模型基本都是 PyTorch 权重、论文复现都是 PyTorch 代码、社区提问大多能得到 PyTorch 回答。你选 PyTorch，等于在跟随整个领域的主流方向。

在 PyTorch 之上，transformers库是必学的。你基本不会自己从零设计一个 BERT 或 GPT，而是加载预训练权重做微调。这套体系里，AutoModel、AutoTokenizer、Trainer这些 API 要混熟，它们能帮你省下大量模板代码。

表格类数据场景，XGBoost 或 LightGBM 仍然值得学。很多人一提起 AI 就只看深度学习，但工业界的真实情况是：大量风控、推荐、营销场景的数据是结构化表格数据，GBDT 家族的效果好、可解释性强、训练快，依然是业务侧的常青树。我自己的习惯是“先跑 GBDT，再跑深度学习，谁效果好上谁”。

实验管理工具的引入时机需要注意。大多数人刚开始做项目时，直接开一个 Jupyter Notebook 往下写就完了，我也这么干过。但当你实验次数多起来，比如同一个模型跑了二十几次，改了不同的学习率、不同的特征组合，你会发现你根本记不清哪次实验用了什么参数、效果怎么样。这时候就该引入 MLflow 或 Weights & Biases。我建议你从 MLflow 开始，它开源、自托管、功能覆盖实验跟踪、模型注册、模型服务，一个人玩和团队协作都够用。

4.2 部署与交付环节怎么选

部署服务这一层，FastAPI 是当前最主流的选项之一。它轻量、自带 OpenAPI 文档、支持异步处理、类型校验用 Pydantic 做得很干净。你不需要学两个框架，FastAPI 一个搞定。如果你之后需要和 Java 技术栈协作，那可能是 gRPC 或别的方案，但对个人项目和中小团队来说，FastAPI 是效率最高的选择。

模型部署格式上，我建议你了解一下 ONNX 和torch.compile。PyTorch 的原生推理用起来没问题，但在推理性能和跨平台移植方面，ONNX Runtime 有优势。你训练好一个 PyTorch 模型，导出成 ONNX 格式，然后使用 ONNX Runtime 跑推理，延迟通常能降低不少。这个优化在需要部署到 CPU 环境的时候特别实用。

容器的学习是绕不开的，Docker 是必选项。Kubernetes 我建议你暂缓一缓，不是它不好，而是个人项目阶段直接上 K8s 很容易被复杂的概念淹没——Pod、Deployment、Service、Ingress 一套下来，还没解决模型问题，先被运维问题劝退了。先把 Docker 用熟，等服务的请求量确实大到单机扛不住了，再考虑 K8s 也不迟。

4.3 MLOps 工具什么时候引进来

MLOps 是这两年很热的概念，但我对它的态度比较务实：先把基础链路跑通，再按需引入工具。一个只有两三个模型、每天几十次调用的服务，你给它上一套完整的 MLOps 平台，纯属杀鸡用牛刀。

当你的项目出现这些信号时，就说明该引入 MLOps 工具了：

• 模型和实验数量变多，手工记录已经管不过来了——上 MLflow；
• 数据管线的步骤复杂，每天要定时跑数据清洗和特征加工的任务——上 Airflow 或 Prefect；
• 线上服务需要精细化监控，包括自定义指标和告警——上 Prometheus 和 Grafana；
• 多个模型需要统一管理版本和发布流程——上模型注册中心。

但有一点我想提醒你：这些工具都是为解决特定复杂问题而生的，不要为了用而用。我见过一个人做项目，非要搭一个包含 K8s + Airflow + MLflow + Prometheus 全家桶的环境，结果折腾了两周，还没跑通一个模型推理接口。工程化的本质是把事情做简单，而不是把工具堆出仪式感。

5. 常见问题与排查技巧实录

5.1 环境冲突与依赖地狱

环境问题几乎是每个做 AI 工程的人都遇到过的噩梦。症状表现为：ModuleNotFoundError、ImportError、版本不兼容导致某个函数行为异常，或者一种更隐蔽的情况——同一份代码在两台机器上跑出不同的结果。

这里给你一个系统的排查思路：

1. 先搞清楚当前环境有什么。用pip list和conda list查看已安装的包和版本，确认你实际用的 Python 是哪个解释器。我遇到过一种情况：在终端里明明conda activate了，但python命令指向的却是系统自带的 Python，导致装包装到了别的环境里。
2. 关键依赖的版本一旦变了，立刻锁定。排查问题时先确认这几个：torch、transformers、numpy、pandas，以及你的 CUDA 环境。很多时候报错信息根本没有提示是哪个包引起的，用二分法逐一排查成本又太高，所以优先怀疑重量级依赖基本不会错。
3. 环境坏了不要修，直接重建。这是我折腾过几次之后的经验教训——维护一个坏环境的成本远超直接新建一个。把requirements.txt或者environment.yml留着，conda create -n ai-eng-fresh python=3.10重建环境，重装依赖，十分钟就恢复，比自己跟报错信息搏斗一小时高效太多。

5.2 训练不收敛和指标不升的排查思路

模型训练不收敛，是新手阶段最打击信心的问题。但大多数时候，原因无非那么几个，一个一个排查就好。

第一，检查数据是否归一化。图像数据有没有缩放到[0, 1]或者标准化？文本数据有没有做 padding？数值型特征的量纲是否差别过大？这些看起来不起眼的细节，直接影响梯度传播的稳定性。第二，检查标签是否正确。多分类的标签如果是混合了字符串和数字的类型，你有机会让模型学得一头雾水。第三，检查数据泄漏。训练集和测试集有没有按照时间或其他逻辑正确切分？有没有某些特征在预测时根本拿不到？

模型侧还要注意输出层和损失函数的匹配。二分类用 sigmoid + BCEWithLogitsLoss，多分类用 softmax + CrossEntropyLoss，这些配对不要搞混。

这里分享一个排查利器：先让模型过拟合一个 batch。如果你训练十步之后模型连训练集的单个 batch 都无法拟合，那大概率是你的模型结构或者数据预处理有 bug；如果单 batch 能拟合，多 batch 就不收敛，那才需要怀疑学习率、特征分布这些问题。这个技巧我几乎每次调试模型都会用，省掉了大量瞎猜的时间。

如果模型能拟合训练集但验证集不涨，那就是过拟合或数据分布不一致的问题，从正则化、数据增强、交叉验证这几个方向入手。

5.3 显存不够和推理太慢怎么办

“CUDA out of memory”是每个人都见过的报错。遇到这个不用慌，先按顺序走这几步：

• 把 batch size 调小。这是最朴素也最有效的办法，batch 减半，显存占用基本也随之减半。
• 用梯度累积来弥补 batch size 缩小的损失。本质上是“小批量多次累积梯度再更新参数”，相当于保持了和原来大 batch 接近的训练效果：

# 梯度累积伪代码 accumulation_steps = 4 loss = loss / accumulation_steps loss.backward() if (step + 1) % accumulation_steps == 0: optimizer.step() optimizer.zero_grad()

• 使用混合精度训练（fp16）。现代 GPU 上这几乎是无脑收益，训练速度和显存占用都有明显改善，PyTorch 里用torch.cuda.amp就可以实现。
• 检查是不是有进程占用了 GPU。nvidia-smi看一眼，如果之前跑过的训练进程没结束，显存被占着，新任务自然 OOM。

推理太慢的问题，思路就更多了。模型量化是最直接的——把 fp16 或 fp32 的权重压缩到 int8，显存占用和推理延迟都能大幅下降，精度损失通常在可接受范围内。还有一个容易被忽略的点：如果你的模型一次只能推理一个请求，但线上有大量请求排队，可以尝试批量推理。把多个请求攒在一起，一次 model 调用处理多条数据，GPU 的利用率立刻就不一样了。

最后，如果你在用 FastAPI 做服务，注意async def和普通def的差异。FastAPI 中，同步的def函数会自动放到线程池执行，但如果你的推理函数是 CPU 密集的，多个线程可能会互相抢占资源；如果是 I/O 密集的（比如从远程读数据），反而要写成async def才能利用异步的优势。这个细节看似小，但对接口性能的影响非常大。

6. 一些个人操作层面的体会

看到这里，你应该已经对“从零开始学 AI 工程”这条路有了比较完整的概念：先练底层能力，再搭学习路线，用项目驱动把数据、模型、部署、监控整条链路跑通，过程中按需引入工具，踩坑时用系统化方法排查。

我在实际带人做 ai-engineering-from-scratch 的过程中，最深的体会是：不要试图一下子搭一个完美的学习计划，也不要等自己“准备好”再开始。我的做法是，先选一个极其简单的项目，比如用 BERT 微调一个句子分类器，然后把每一个环节——哪怕是“如何把一个目录挂载进容器”这种细节——都亲自动手操作一遍。第一次跑通全链路之后，后面所有新项目都只是在同样的骨架上换不同的模型和数据。

最后再分享一个我自己坚持了很久的小习惯：每完成一个项目，就写一份复盘文档，记录三件事——踩过的坑、排查过程、最终解决方案。三个月之后回头看，这份文档的价值远高于你当时花钱买的技术课程，因为它是你自己的避坑手册，是 AI 工程这条路上最量身定制的学习资料。