1. 内容整体设计与思路拆解

1.1 AI工程到底是什么，和算法岗有什么区别

聊到这个项目标题，我特别有共鸣。不少刚入门的朋友找我第一句话就是："我想学AI，是不是先把论文啃明白就行？"我的回答通常是：你要是想做研究，啃论文没错；但如果你要做AI工程，思路得换一下。

这个项目叫ai-engineering-from-scratch，从命名就能看出来，它强调的是"engineering"而非"research"。我在一线做AI落地这几年，最大的感触就是：算法模型只是工程项目里的一环，真正决定一个AI系统能否长期稳定运行的，反而是那些看起来不起眼的工程细节。

AI工程和算法岗的区别，我用一个类比讲清楚：算法工程师像是开发新药的人，做的是在实验室里证明某种化合物有效；而AI工程师更像是药剂师或医院药房的管理者，关心的是这个药怎么量产、怎么储存、怎么配伍、怎么安全地用到病人身上。落到具体工作内容上：

• 算法岗核心关注点：模型精度、Loss收敛曲线、网络结构创新
• AI工程核心关注点：数据管线稳定性、模型推理时延、资源成本控制、系统可维护性

很多人拿算法岗的面试题去准备AI工程岗，结果面试官问的全是"你的模型上线后遇到数据漂移怎么办""线上QPS从100涨到10000，你怎么扩"这类问题，直接懵了。这个项目的价值就在于：补齐从"会写训练脚本"到"能交付一个可用AI系统"之间的完整链路。

1.2 从零开始的核心技能栈，哪些该学哪些不该学

"from scratch"这个词容易让人误解，以为是让你去从反向传播推导到Transformer实现。说实话，如果你的目标是把AI落地产出价值，这条路是低效的。我做这个项目时给技能栈排了一个优先级，核心逻辑是：先会开车（用工具），再懂发动机原理（读源码），最后才是自己造车（写框架）。

优先级从高到低排列：

• 第一梯队（必须精通）：Python工程化能力（类型注解、单元测试、依赖管理）、Linux基本操作、Docker容器化、数据预处理与质量校验
• 第二梯队（熟练掌握）：PyTorch或TensorFlow之一（我推荐PyTorch）、模型部署方案（TorchServe/Triton/ONNX Runtime至少精通一种）、特征工程与数据管线
• 第三梯队（理解原理）：模型结构与训练原理、分布式训练基础、MLOps工具链（Airflow/Kubeflow/MLflow至少了解）

很多新手会把大量时间耗在"背诵模型结构"上，比如让我手写ResNet或者Transformer的多头注意力。我可以把话说得直接一点：如果你不做论文复现或者框架研发，这件事的ROI极低。你更需要练的是：拿到一批脏乱差的数据，能把它洗干净、做成特征、训练一个够用的模型、部署成接口、监控它的表现、出了问题能快速定位。这六步才是AI工程师的日常。

1.3 项目的路线图设计，为什么按阶段划分

这个项目整体上围绕一条主线：从一个纯业务问题出发，走完整套交付流程。这和我做项目的一个经验高度一致——编码能力可以零散学习，但工程思维必须通过完整闭环养成。

打个比方，你单独学劈柴、烧火、切菜、颠勺，每一项都练得很熟，但如果没有完整地做过一桌菜，你真到了开饭时间还是会手忙脚乱。AI工程也是一样的道理，你在教程里跑通一个MNIST手写数字识别，跟着视频里敲一遍代码，自以为会了，结果换个数据集、换个业务场景，立刻不知道怎么下手。为什么？因为教程帮你把所有脏活累活都干完了，你需要做的事情只有"点击运行"。

所以在设计这个项目的路线图时，我会刻意去掉那些"顺滑感"。它不是让你照着代码敲一遍就行，而是给你一个业务问题描述，让你自己决定怎么做数据处理、怎么设计特征、怎么评估结果。你不会被直接告诉"答案"，但每完成一阶段，底层逻辑都会配一份详细的复盘。

阶段划分大致是：

• 第一阶段：环境搭建与工程规范，解决"在哪写、怎么写、怎么保证质量"
• 第二阶段：数据处理与特征工程，解决"喂给模型的到底是什么"
• 第三阶段：模型训练与调优，解决"怎么训练出满足要求的模型"
• 第四阶段：上线部署与监控，解决"模型怎么稳定服务、怎么发现问题"

这条路线走完，你可以负责任地说自己具备了AI工程师的基本盘。不是说你变成了资深专家，但你已经能在真实项目中不犯方向性错误，对大多数业务问题能给出合理的AI方案。

2. 核心细节解析与实操要点

2.1 环境搭建的标准姿势，别一开始就栽跟头

环境搭建是"从零开始"的第一道坎，也是劝退率最高的一步。我见过太多人卡在CUDA版本不兼容、Python环境冲突、pip和conda混用导致包依赖错乱这些问题上，一折腾就是两三天，学习的热情全被耗光了。

我的建议是可以直接照搬一套成熟的环境配置方案，不要自己"创新"：

• Python版本选择3.10或3.11，太老或太新都可能遇到依赖包不兼容问题
• 使用Conda创建独立虚拟环境，不要直接装在base环境里，这是我踩过最痛的坑之一
• PyTorch的安装要严格参照官网的CUDA版本匹配表，先查清楚你的显卡驱动支持哪个CUDA版本再安装

为什么我不建议用最新版？因为AI生态的依赖链极其复杂。举个实际例子：某个版本的transformers库可能依赖的是特定范围的numpy版本，而你的PyTorch安装时自动带了另一个numpy版本，两者的版本要求冲突，跑起来就会出现一些莫名的报错。生产环境更是如此，很多团队还在用Python 3.8守着老项目，不是因为他们不愿意升级，而是升级整个依赖链的成本太高了。所以"求稳不求新"是AI工程的第一条铁律。

还有一个小细节：容器化。我强烈建议你在第一天就把Docker用起来，而不是等项目做完了再补课。原因很简单，Dockerfile是你环境的"源代码"，它让你的环境可以被版本管理、被复现、被分享。试想一下这个场景：你在本地把模型调通了，结果部署到服务器上却报错，一查发现是服务器上缺了一个系统库。如果有Docker，直接把镜像拉过去就能跑，这种问题根本不会发生。

2.2 数据处理与特征工程，决定模型上限的关键

我常说一句话：模型是上限，但数据是下限。数据质量不过关，再先进的模型也白搭，这不是玩笑话。有一次我在项目里处理用户行为日志，原始数据的缺失率大概15%，字段含义也没人说得清楚，就靠猜来补。后来上线后模型表现大幅度波动，排查了一周，最后定位到原因：补数据的方法在不同时间段不一致，导致特征分布发生了突变。

数据处理的实操要点，我整理成一份自检清单：

• 数据采集时就要考虑生命周期，多久更新一次、过期数据怎么归档
• 缺失值处理不能无脑填0或均值，要结合业务语义选择填充策略
• 异常值检测需要分业务场景，比如交易金额的"异常大"和点击时长的"异常大"完全是两回事
• 训练集和验证集的切分必须考虑时间顺序，在业务场景中随机切分往往会造成时间穿越问题

特征工程我觉得需要强调的是：不要贪多，要克制。基于我在一线项目中观察到的规律，很多初入职场的同学做特征工程时存在一种心态："多搞一些特征吧，反正模型能自动筛选。"实际上这样做副作用很明显：特征维度太高导致训练变慢、内存膨胀，更麻烦的是，没有业务含义的"垃圾特征"会引入噪声，白白拉低模型性能，白白增加线上服务的计算开销。

在实操上，你完全可以先把最容易拿分的基础特征做好，例如：数值特征的归一化与缺失处理、类别特征的编码方式选择、时间特征的周期性分解。这些做好之后，你的模型就已经有一个不错的基线了。那些"高大上"的复杂特征，等你确认基线无法满足需求时再做也不迟。

2.3 模型训练的完整流程，从配置到收敛

训练环节最容易让人焦虑的就是"明明照着教程写了，为什么Loss不降？"这类问题。我先给一个最核心的原则：模型训练是一个非常典型的重现性工程流程，它要求每一步都具备确定性。也就是说，每一步操作都应该有明确的输入和可预期的输出，彻底杜绝"玄学调参"。

需要重视的第一个细节是随机种子。PyTorch的random、numpy的random、Python的random，这三者必须同时设置固定种子，否则即使你调用了torch.manual_seed()，数据加载顺序和数据增强产生的随机性仍然可能导致每次跑出来的结果不一样。在模型开发阶段，"结果可复现"是第一原则，而种子就是复现的地基。

第二个细节是学习率的设置。很多新手习惯直接把学习率设为0.001然后开始训练，发现Loss不降就束手无策。实际上学习率的选择范围非常宽：从头训练通常用1e-3到1e-4，微调预训练模型通常用1e-5到2e-5。如果你的模型完全不收敛，先检查两件事：一是数据预处理有没有问题，比如有没有归一化；二是学习率是不是太大导致Loss发散了。前者才是更常见的故障源，很多时候改数据比改模型更有效。

第三个细节是训练过程的监控。我看过不少同学的训练脚本，训练结束才打印一行验证集精度。这其实远远不够。你在培训过程中需要持续跟踪的是：训练集Loss和验证集Loss的同步变化，前者下降、后者不降，这是过拟合的早期信号；每个epoch以验证集上最好的那版参数为准记录checkpoint，而不是最后一次训练的模型；如果Loss曲线出现震荡或者突然跳变，大概率是数据顺序的问题，可以考虑设置shuffle保证数据随机性。

2.4 模型部署与服务化，上手变成可用系统

训练完成只是整个AI工程的一半，模型本质上是没有价值的，只有通过部署变成对外提供服务的接口，它才真正产生了业务价值。部署环节我遇到最常见的坑：把训练代码直接改成API来用。这里我要重点提醒：训练代码和推理代码的诉求完全不同，务必分开。

让我把区别说透：训练代码需要的就是灵活性，有利于你在Notebook里反复调试；而推理代码追求的是稳定、快、省资源。如果你复用训练代码作为推理服务，通常会发生这些问题：

• 模型加载的速度因为初始化了一些冗余组件而变慢
• 每次推理都会产生不必要的计算
• 单次推理的显存占用量虚高，直接影响服务的并发上限

正确的做法是：写一个独立的推理脚本，只保留模型加载、数据预处理和后处理这三部分逻辑，然后把模型导出成专门为推理优化的格式。以我常用的方案举例：PyTorch模型先转换为TorchScript或ONNX格式，再用ONNX Runtime作为推理引擎。这就好比做菜：训练/实验阶段是在开放式厨房里随心所欲地发挥，部署阶段则变成了快餐店的标准化操作流程，每一步都固定，追求的是稳定和速度。

在线部署会涉及到的几个关键参数：批量大小（batch size）与并发数需要区分清楚，GPU显存是硬约束，批量大小不能只看模型理论显存占用，还需要乘以实际输入的尺寸；推理时延的测量需要考虑P50/P95/P99三个分位数，P99才能反映最差情况下的体验。业务高峰期前需要提前压测，给服务预留30%到50%的裕量，这些经验都是从生产环境的教训中得来的。

3. 实操过程与核心环节实现

3.1 实操项目主线设计

为了让"从零到一"不只是虚无的概念，我在项目中设计了一个贯穿始终的具体场景：构建一个客户评论情感分析系统。选这个场景有三个原因：数据可以自己造、业务语义直白、技术栈覆盖面足够宽。

功能目标不复杂：输入一段客户对产品的文字评论，系统输出正面或负面的情感判断，并附带一个置信度分数。整个系统的完整链路包括：数据准备、模型选择、训练评估、模型导出、接口部署、容器化打包。

如果把这个项目完整做完，就等于把AI工程师核心技能栈的80%过了一遍。这比东做一个教程、西做一个Demo有效得多，因为你获得的是系统化的工程经验。

3.2 数据准备与预处理实操

先模拟一份真实业务里的原始数据，能看到它长什么样：

评论内容, 评分, 日期 "东西很好用，物流也快，五星好评", 5, 2024-03-01 "一般般吧，没有我想象中好", 3, 2024-03-01 "垃圾产品，用了三天就坏了，退款！", 1, 2024-03-02 "客服态度差，问什么都不回", 2, 2024-03-02 ...

这就是真实数据的典型形态：有噪声、有不规则信息、标签需要处理。首先要把评分转换为二分类标签，比如4分及以上算正面，2分及以下算负面，3分视为中性先剔除（很多业务在初期阶段会这么做，后续有必要再考虑三分类）。

文本清洗这一步很容易被低估。我见过有人只是把空格去了、转小写，就当作预处理完毕。实际上中文场景还需要处理全角半角符号统一、特殊字符过滤（比如表情符号、URL链接）、繁体转简体，以及一些行业专属的短语。在评论场景中，"给力""绝绝子""YYDS"这类网络用语都可能对模型有影响，是否需要纳入词典需要结合业务考虑。

特征化的方式，考虑到这是一个典型且基础的场景，我选择用词频向量化。具体实现中需要做好两个参数的控制：max_features（特征数量上限）和ngram_range（词组合范围）。我把这两个参数的意义解释一下：max_features设5000和10000的差距不仅是维度大小，还影响模型训练速度、内存占用和泛化能力；ngram_range=(1,2)表示同时使用单个词和相邻词组合作为特征，对于情感分析类任务，它能捕捉诸如"不好"这类否定修饰的语义，效果会比只用单个词好得多。

这一份代码是常见的数据预处理+向量化流程，在所有项目中基本可以开箱复用：

import jieba from sklearn.feature_extraction.text import TfidfVectorizer import pandas as pd def load_and_clean_data(filepath): df = pd.read_csv(filepath) df = df[df['评分'] != 3] df['标签'] = (df['评分'] >= 4).astype(int) def clean_text(text): text = str(text).lower() # 去除URL、表情符号等噪声 text = re.sub(r'http\S+|www\.\S+', '', text) text = re.sub(r'[\U0001F300-\U0001F9FF]', '', text) return text.strip() df['评论内容'] = df['评论内容'].apply(clean_text) return df def tokenize_and_vectorize(texts, max_features=5000): # 中文需要先分词，英文场景可以省略这一行 texts = [' '.join(jieba.cut(t)) for t in texts] vectorizer = TfidfVectorizer(max_features=max_features) X = vectorizer.fit_transform(texts) return X, vectorizer

3.3 模型训练与评估实操

对于这种小规模文本分类场景，不需要一开始就用大模型，先把Logistic回归或朴素贝叶斯这类传统机器学习方法作为基线，是性价比最高的选择。这里同样涉及很多行业内的"老话"，线性模型在干净的特征空间里往往能跑出不错的成绩，而且训练速度快、可解释性强，特别适合作为第一个可用版本。

下面演示一个训练过程的标准结构：

from sklearn.model_selection import train_test_split from sklearn.linear_model import LogisticRegression from sklearn.metrics import classification_report X_train, X_test, y_train, y_test = train_test_split( X, df['标签'], test_size=0.2, random_state=42, stratify=df['标签'] ) model = LogisticRegression(C=1.0, max_iter=1000, class_weight='balanced') model.fit(X_train, y_train) y_pred = model.predict(X_test) print(classification_report(y_test, y_pred))

作为对照，换一个LightGBM模型试试看：

import lightgbm as lgb lgb_model = lgb.LGBMClassifier( n_estimators=200, learning_rate=0.1, num_leaves=31, random_state=42 ) lgb_model.fit(X_train, y_train) y_pred_lgb = lgb_model.predict(X_test) print(classification_report(y_test, y_pred_lgb))

注意一点：class_weight='balanced'这个参数在样本类别不平衡时很关键。比如真实业务场景中，好评数量通常远多于差评，如果不处理类别不平衡，模型会学成一个"无脑好评分类器"——因为全预测好评的准确率就已经有90%了，但这样的模型毫无价值。这一点请务必牢记。

评估指标的选择也要结合业务来看：如果你的目标是筛出所有"差评"来改进产品，那Recall（召回率）比Accuracy（准确率）更重要；如果你的目标是自动回复好评客户，那Precision（精确率）更重要。千万别死抱着准确率一个指标不撒手。

3.4 模型导出与服务化实操

模型训练完成后，接下来就是把它变成可调用的服务。我给出的完整链路是：模型序列化 → 编写推理脚本 → 用FastAPI封装成HTTP接口 → 用Docker容器化 → 本地做简单压测。

模型导出的常规方法是使用pickle或joblib：

import joblib # 需要同时保存模型和tokenizer/vectorizer，它们是推理密不可分的两部分 joblib.dump(model, 'sentiment_model.pkl') joblib.dump(vectorizer, 'tfidf_vectorizer.pkl')

有经验的工程师都知道，模型文件和数据预处理对象必须打包在一起保存，这是我线上部署踩过坑换来的教训。我曾经只保存了模型，没有保存对应的向量化器，结果上线后接口报错，挖了半天才发现是预处理对象和训练时不一致了。

接着用FastAPI封装推理接口，一个简洁的示例如下：

from fastapi import FastAPI from pydantic import BaseModel import joblib import jieba app = FastAPI() model = joblib.load('sentiment_model.pkl') vectorizer = joblib.load('tfidf_vectorizer.pkl') class ReviewRequest(BaseModel): text: str @app.post("/predict") def predict(request: ReviewRequest): text = ' '.join(jieba.cut(request.text)) features = vectorizer.transform([text]) proba = model.predict_proba(features)[0] sentiment = '正面' if proba[1] > 0.5 else '负面' confidence = float(max(proba)) return {"sentiment": sentiment, "confidence": confidence}

在这个流程里，还有几个隐藏的细节值得讲一讲：

• 为什么建议用predict_proba而不是直接predict？直接预测只会给出标签，但业务上我们往往需要一个置信度阈值来实现更精确的过滤，比如confidence低于0.6的评论交给人工处理而不是自动回复。
• 业务阈值的选择也需要数据支撑。通过观察P-R曲线来平衡精确率和召回率是最规范的方法，而不是拍脑袋设一个0.5的置信度阈值。
• 并发量的控制：FastAPI虽然性能不错，但说明白了它只是一个轻量级的Web框架，生产环境中更推荐把它跑在Gunicorn这样的生产级WSGI服务器后面来管理连接和进程。

Docker化的总结范本如下，考虑到镜像体积和启动速度通常用python:3.10-slim：

FROM python:3.10-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . EXPOSE 8000 CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

这里的--no-cache-dir是为了缩小镜像体积，slim版本也是同一目的。如果发现镜像太大，还可以使用--from=...的多阶段构建策略，进一步精简最终产物。这些细节对于后续上生产环境很有帮助。

3.5 监控与优化闭环

模型部署上线后，真正的挑战才刚开始。我见过大量团队是"上线上线，再也不管"，直到模型效果已经差到影响业务了才发现问题。这绝对是不合格的AI工程实践。

我建议模型上线第一天就搭建三个层面的监控：

• 健康度监控：接口的QPS、时延、错误率，通常用Prometheus + Grafana这一套方案实现
• 性能漂移监控：定期评估线上预测结果的分布是否偏离训练时的分布，比如正负样本比例是否发生了明显变化
• 数据漂移监控：输入特征的分布是否发生了显著变化，背后原因可能是客群结构变化、优惠活动影响等业务因素的改变

数据漂移还有一个比较容易忽视的方向：语义漂移。比如早期训练数据里用户说"牛"大部分是正面的"牛"，可能是在夸"牛排很牛"。但后来因为某个社会热点，评论区开始大量出现"牛"来表达无奈，那么模型预测的置信度和结果就都不对了。这些情况模型自己是无法感知的，必须靠线上指标和人工抽检及时发现。

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

4.1 环境与依赖的疑难杂症

这个项目自建路径从环境搭建开始，自然绕不开各种依赖问题。我整理了一张非常高频出现的问题排查表，直接按表排查：

一个重要的操作习惯：永远不要在全局环境里用pip install乱装包，我现在开始所有项目都先用conda建独立环境再开始操作。不要怕麻烦省这一步，它未来会替你抵挡掉数不清的问题。

4.2 模型训练状态异常与排查

训练不收敛是每个AI工程人都遇到过的"老朋友"。我总结一套排查思路，属于放在记事本里的老经验：

Loss一直不降，先查数据的标签有没有泄漏或错标，这种情况比模型问题的概率高得多。具体做法是随机抽20条训练数据人工检查特征和标签是否匹配。

Loss快速下降后验证集不涨，多半是特征工程出问题了，比如模型过于依赖某个强特征，而这个特征在测试时分布变了。可以试着去掉几个特征测试，看是否影响验证集表现。

Loss开始下降很快，中途出现NaN或爆炸式增长，大概率是学习率过大，或者是数据预处理出现了除以0的情况。用初始的1e-4作为基础学习率，通常能避开大多数梯度爆炸的问题。

模型在训练集上表现完美、验证集一塌糊涂，这属于"教科书级"过拟合，解决手段在数据层面不行时，就要上正则化和数据增强。

一个小建议：养成为每次训练记录日志的习惯，包括超参数、随机种子、数据版本、耗时、最终指标。这些零散信息在将来排查模型退化原因时会发挥巨大的作用。

4.3 部署过程中的常见坑

部署环节的问题，与其说"模型代码写得对不对"，不如说"流程和配套工程有没有做全"：

使用本地训练时正常、容器中推理报错的情况，先排查构建时有没有遗漏模型文件。Dockerfile里的COPY . .路径如果不对，经常导致运行起来才发现模型文件根本没有打进镜像。

更隐蔽的问题是模型文件路径写死，例如model.load('/home/user/models/model.pkl')。项目换到容器里，路径完全对不上。正确做法是使用相对路径，或者在启动时通过环境变量传入模型路径。

还有一个非常容易被新手忽略的问题：HTTP接口对单条文本和批量文本的处理能力差异。测试时一次请求一条数据，但上线后业务方会频繁地用批量接口请求几十条文本，这时如果代码里没有处理好循环与异常隔离，单个坏样本就可能拖垮整个请求。因此，批量请求的异常隔离是一项必备的设计，一段样本出错不应该影响其他样本的预测。

4.4 业务效果不达预期，如何在工程侧解决

最后聊一个很多人都掉过的坑：业务方反馈"模型效果不行"，结果你一测，离线指标也很正常。出现这种情况，背后大多数是工程链路出现了问题。

数据口径不一致是最常见的元凶。训练时用的标签定义与线上实时推断时用的规则不一致，离线验证的结果自然无法反映线上行为。排查方法非常简单：随机抽取线上50条数据，人工判断正负例，再和模型预测结果做对比，基本就能定位问题。

特征可用性的差异也值得一提。你在离线训练时可能用了"未来信息"，比如这个用户的后续行为特征，但线上预测时根本拿不到这个特征。这种特征泄漏问题如果不在工程侧把好关，模型训练时指标再漂亮也是假的。如何发现？对比离线特征表是否允许用"当前时间"之后的数据。

线上feedback循环分摊到工程上，我建议每两周做一次模型效果人工评估，每一到三个月做一次全面的模型迭代追踪。模型不是一成不变的，它也需要"保养"。

5. 工具选型解析与学习资源推荐

5.1 核心工具链清单及理由

我尽量挑每个环节最成熟、社区活跃度最高且学习曲线相对平缓的方案：

这些选型大多是默认选项，我个人不建议在这个阶段去追求"新奇"工具。原因很简单：你和你的团队未来可能需要长期维护这些代码和流程，主流稳定的技术选型在招聘、排错、资料获取等所有环节都能给你节约大量的成本。

5.2 学习顺序和精力分配建议

如果你准备认真以这个项目为主线来学习，我强烈建议你给学习阶段的精力分配做一个明确规划，我自己的建议比例是：数据处理与特征工程占35%，工程规范与部署占25%，模型训练与调优占25%，理论原理占15%。这个比例可能和很多人的直觉相悖——"我学AI当然应该多学模型啊"，但现实是：业务数据往往不理想、模型基本原理相对有限，真正拉开你和初级工程师差距的正是数据与工程环节。

给所有想入行AI工程（不只是做实验）的朋友一个最大忠告：在这个领域里，实践经验远超理论。你花了一个月去精读一篇顶会论文，价值可能在工作中很小；但如果你花一个月把数据管线和模型推理服务的稳定性打磨得很出色，你会成为团队里"不可或缺"的那个角色。

做ai-engineering-from-scratch这个项目，我个人最想传递的经验是：不要用做学术研究的心态来学AI工程，而要用做产品的心态。学术研究的产出是论文，证明"我可以"；而AI工程的产出是系统，证明"它能用"。如果你能把一个模型真实地跑起来、稳定地服务着、持续地迭代着，那么你在AI领域的专业度已经远超大多数停留在"调包跑模型"阶段的人。踩过那些坑之后回头看，最快的路其实就是那条看起来"弯"的路——数据、工程、部署、监控，每一步都亲自踩一遍，你才有资格说自己真的懂了AI工程。