处理AI项目这几年，我最常被问的一句话就是：“别人家的AI工程是怎么搭起来的？”说实话，网上的教程大多教你调参、跑通一个demo，但真正从零把一个AI项目做成能上线、能维护、能迭代的工程体系，中间隔着大量没人系统讲过的细节。这也是我想写“ai-engineering-from-scratch”这一个话题的原因——它不是某个具体模型的训练教程，而是一整套从零开始构建AI工程能力的思路、选型和实操路径。

这篇文章我会以“从零搭建AI工程链路”为主线，把我实操中积累的组件拆解、工具选型、踩坑记录和排查方法一次聊透。无论你是刚转AI工程方向的新人，还是已经在做算法但想补工程短板的开发者，这篇内容应该都能帮你把散落的知识点串成一条可落地的技术线。我会尽量少讲虚的，多给可以直接抄作业的步骤和参数。

1. 整体思路：为什么“从零搭建”比“套用框架”更值得做

先聊点理念层面的东西。现在AI技术栈已经很成熟，HuggingFace、LangChain、各类MLOps平台都能让你快速起步。那为什么还要讨论“ai-engineering-from-scratch”？我的看法是：框架给你的是“轮子”，但工程体系需要你自己设计“底盘”。你只有理解了每个组件在整个链路里为什么存在、解决什么问题，才能在遇到框架解决不了的问题时做出正确的取舍。

1.1 从零搭建的核心收益

很多人低估了“从零搭建”这三个字的含金量。我用一个类比来解释：如果你要开一家餐厅，直接买预制菜包当然快，但你要控制成本、保证菜品特色、应对食客的个性化需求，就必须懂食材采购、后厨动线、火候控制这些基本功。AI工程也一样，从零搭建的本质是让你掌握“食材”和“火候”。

具体来说，从零搭建有三个明确的收益：

• 完全可控的数据流：每条数据从采集、清洗、标注到进入模型，每一步都是你可审计、可回溯的，出了问题能精确到具体环节。
• 成本可预测：不用被动接受平台的高价API或锁定效应，你可以根据实际负载精确规划算力和存储资源。
• 能力可迁移：你积累的是底层方法论，而不是特定平台的操作技巧。换了工具链、换了云厂商，核心能力依然有效。

以我自己做个例子，我之前参与过一个文档智能解析项目，最初用了某个现成的文档处理平台，很快啊，准确率也确实可以。但后来业务要求支持私有化部署，还要在弱网环境下离线处理大批量文档，平台方案直接卡死。于是我们重新用开源的OCR、版面分析、表格识别组件，自己组装了一条处理流水线。虽然前期开发量大了不少，但最终的灵活度和性能表现完全不是一个量级。

1.2 工程链路全景图

从零搭建AI工程，首先要建立一张清晰的全景图。我习惯把整条链路切成五个核心环节：

1. 数据工程层：数据的采集、清洗、去重、标注、版本管理。这是整条链路里最脏最累但最重要的一环。
2. 特征与训练层：特征工程、模型选型、训练调度、超参调优、实验管理。这个环节决定了模型效果的上限。
3. 推理与部署层：模型序列化、推理服务、性能优化、灰度发布、版本回滚。模型上线只是开始，稳定服务才是关键。
4. 评测与反馈层：离线评测集构建、线上指标监控、badcase回流、自动重训。没有反馈闭环的AI系统，效果只会随时间衰减。
5. 基础设施层：算力管理、容器化、CI/CD、监控告警、成本治理。这层是大多数算法工程师容易忽略、但工程化程度高低全看它的部分。

我给很多团队分享过这五个环节，几乎每次都会被问到“哪一层最重要”。我的回答一直是：在项目初期，数据工程最重要；在项目中期，评测反馈最重要；在项目后期，基础设施最重要。这个回答听起来像废话，但实际踩过坑你就明白，AI工程的难点从来不在某一层，而在于每一层之间的衔接。

2. 关键组件拆解：每一层具体做什么、怎么选型

说实话，这五个环节每一层展开都能写一本书。这里我就挑每个环节里头最容易翻车、也最能体现工程水平的关键组件来拆解。我会结合自己的选型经验和实际对比，尽量说清“为什么选它”以及“不选另一个”的理由。

2.1 数据版本管理：你的数据集也需要Git

先说数据工程层里最容易被人忽视的组件——数据版本管理。我见过太多团队的数据集就是一堆日期命名的文件夹：data_1023、data_final、data_final_v2……这种搞法一开始没什么，模型迭代两三轮之后，你就会发现“这个结果是用哪份数据跑出来的”完全对不上号，复现实验成了玄学。

解决办法是用专门的数据版本管理工具，比如DVC（Data Version Control）。它的工作逻辑很好理解：文件本身还是放在本地磁盘或对象存储里，但DVC会用一份轻量的元数据文件去追踪每个数据集的版本、依赖关系和生成过程。配合Git使用，你可以在代码里清晰记录“当前代码 + 当前数据版本 = 某个实验结果”。

具体操作上，你可以在项目里这样初始化：

# 初始化DVC环境 dvc init # 添加数据目录并远程存储 dvc remote add -d storage s3://your-bucket/dvc-store # 添加数据文件，生成 .dvc 元数据文件 dvc add data/raw/documents

之后每次数据更新，只需要重新执行dvc add和git commit，系统会自动记录新旧版本之间的差异。我常用的习惯是给数据版本加上语义化标签，类似data_2025Q1_v3，这样评审和复盘时一眼就能对上号。

还要提醒一点，数据版本管理不只是管文件，还要管数据血缘。也就是你要清楚每条样本从原始来源到最终进入训练集，经过了哪些处理步骤。工具层面可以用DVC的dvc.yaml定义pipeline，把清洗、去重、切分这些步骤固化成可重放的流程。

2.2 特征存储：模型效果的隐形地基

如果你做的是偏传统的机器学习或搜索推荐类项目，特征存储（Feature Store）是你绕不开的组件。它的核心作用是：让特征的定义、计算、存储和在线读取有一套统一的规范，避免训练时用的特征和线上推理时用的特征不一致——这是最坑的线上事故之一。

业内典型的开源方案是Feast，它支持你在本地或云端配置特征仓库，用类似下面这样的方式定义特征视图：

project: my_project entities: - name: user join_keys: [user_id] feature_views: - name: user_features entities: [user] features: - name: click_count type: int64 - name: avg_session_duration type: float

配置好之后，训练时你可以批量读取历史特征，线上推理时用SDK实时获取最新特征，两边共用同一套定义，从机制上保证线上线下一致性。

我个人的经验是，项目初期特征不多、逻辑简单的时候，不用急着上Feature Store，先用一套定义清晰的SQL或Python函数管理就够了。但如果你发现特征数量超过50个、开始有多个团队共享特征、或者线上和线下口径经常对不上，那就该认真考虑引入专门的组件了。

2.3 训练任务编排：把实验变成流水线

传统算法工程师的习惯是把训练脚本一跑，盯个三四小时看loss曲线。但在工程化的体系里，训练必须变成可编排、可调度的任务。我常用的方案是把训练流程拆成多个步骤，用流水线工具串起来。

这里要展开讲一下选型。如果你追求轻量、团队本来就以Python为主，那我推荐用Prefect或者Dagster，它们比Airflow轻很多，学习曲线也更平滑。但如果你所在的公司基础设施已经是Kubernetes为主，而且团队有较强的运维背景，那么Argo Workflows会是更好的选择——它天然和K8s生态集成，资源调度能力极强。

我自己在大多数中等规模项目里用的是Dagster，选它的理由是：数据资产的定义清晰、本地调试体验好、和DVC、MLflow都能很好地集成。一条典型的训练流水线长这样：

1. 数据校验（检查数据完整性、统计指标是否异常）
2. 特征计算（生成训练特征集）
3. 模型训练（跑训练脚本，自动记录参数和指标）
4. 模型评估（在验证集上计算指标，对比基线）
5. 模型注册（把满足条件的模型写入模型仓库并打标签）

用Dagster的代码结构也很直接，核心就是定义asset和job。比如：

from dagster import asset, OpExecutionContext @asset def cleaned_data(context: OpExecutionContext): # 读取原始数据并做清洗 ... return data_path @asset def trained_model(context: OpExecutionContext, cleaned_data): # 调用训练脚本 ... return model_path

这套机制的优点在于，每一步都有输入输出定义、每一步都可以单独复跑，不会因为中间某一步失败就得从头再来。

2.4 实验追踪：不要再用Excel记录超参数了

每次我在团队里说“不要用Excel记录实验”，都会有人觉得我在小题大做。直到有一天需要复现一个半月前的模型，当事人自己也说不清当时学习率设的是多少、用了哪个数据版本，大家才明白实验追踪的重要性。

实验追踪组件的标配是MLflow，它提供四块能力：实验记录（Tracking）、模型打包（Models）、模型仓库（Registry）、项目打包（Projects）。对我来讲，最常用的是前两块。

在训练脚本里，只需要简单的几行代码就能记录所有关键信息：

import mlflow with mlflow.start_run(run_name="bert_finetune_v3"): mlflow.log_param("learning_rate", 2e-5) mlflow.log_param("batch_size", 32) mlflow.log_metric("eval_f1", 0.872) mlflow.log_artifact("model/config.json") mlflow.pytorch.log_model(model, "model")

之后你可以在MLflow的UI界面里按指标排序、按参数过滤，所有实验一目了然。我习惯在每轮实验里把“代码commit号、数据版本、关键参数、核心指标”这四要素完整记录，缺一个都视为无效实验。

2.5 推理服务框架：从批量到在线的一步之遥

模型训练完之后，怎么把模型变成稳定的服务，是很多初学者最困惑的地方。市面上方案很多，Triton Inference Server、TorchServe、TensorFlow Serving、KServe各领风骚。

我的选型逻辑是这样的：如果模型类型单一（比如主要是深度学习CV模型），用TorchServe就够；如果需要同时服务多种框架的模型、对吞吐和延迟有很极致的要求，那就直接上NVIDIA Triton，它的动态批处理、并发模型执行、内存管理做得非常成熟。

Triton的核心概念是Model Repository，你只要把模型按约定目录结构放好，再写一个配置文件，服务就起来了：

model_repository/ └── text_cls/ ├── 1/ │ ├── model.onnx │ └── config.pbtxt

config.pbtxt里可以声明输入输出格式、动态批处理策略、GPU显存分配等。举个实际例子，我用Triton部署一个BERT分类模型，配置里设置max_batch_size为64，开启dynamic batching之后，吞吐量相比逐条请求提升了大约4倍，延迟只增加了30%左右。这个收益在业务量大的时候非常可观。

在线推理服务还需要配套的东西包括：负载均衡（一般用Nginx或K8s Service）、健康检查（/v2/health/ready接口）、以及优雅的上线/下线流程。这些虽然听起来像是运维该做的事，但AI工程师如果对这些没有一个基本认知，线上出问题时会非常被动。

2.6 监控与可观测性：模型也会“生病”

最后一块关键组件是模型监控。很多人以为模型上线之后就万事大吉，实际上模型在真实环境里会因为数据分布漂移、上游特征质量变化等原因，效果持续衰减。你如果不监控，就像开了一家餐厅但从来不检查食材是否过期——迟早出事。

监控的两大方向是性能监控和漂移检测。性能监控就是常规的延迟、错误率、GPU利用率这些指标；漂移检测则要关注输入数据分布和模型预测分布的变化。常用的工具包括Prometheus + Grafana做指标可视化，Evidently AI或者WhyLabs做数据漂移检测。

我给大家一个实用的兜底方案：即便不上专门的ML监控平台，也至少要做到两条——第一条，线上请求的输入、输出全部落日志，定期抽样做人工审计；第二条，每周自动计算线上预测分布的统计指标，和训练时的基准对比，超过阈值就告警。这两条做到了，大部分模型衰减问题都能及时发现。

3. 实操过程：从零到一搭建完整链路的过程记录

前面把组件都串起来了，这一节我想用“假设我们要从零构建一个文本分类系统”的完整场景，带你把整条链路过一遍。这套流程是真实可复现的，所有选型和步骤都是我验证过的组合。

3.1 环境初始化：先把基础打牢

整个实操流程的第一步是把基础环境搭好。我习惯统一用Docker做环境隔离，避免“在我机器上能跑”的经典尴尬。下面这个组合是目前我用着最顺手的：

• Ubuntu 22.04作为基础镜像
• Python 3.10+
• CUDA 12.x（如果你用GPU训练）
• Poetry管理Python依赖
• Docker Compose编排本地依赖服务

一个标准的开发环境docker-compose.yml大概长这样（省略了一些细节）:

version: "3.9" services: mlflow: image: ghcr.io/mlflow/mlflow:latest ports: - "5000:5000" command: mlflow server --host 0.0.0.0 --backend-store-uri sqlite:///mlflow.db volumes: - ./mlflow_artifacts:/mlflow_artifacts postgres: image: postgres:15 environment: POSTGRES_USER: mlflow POSTGRES_PASSWORD: mlflow POSTGRES_DB: mlflow ports: - "5432:5432"

这样本地一下就把MLflow的追踪服务和它的元数据库同时拉起来了，开发时随时记录实验不需要额外依赖远程环境。

3.2 数据接入与清洗链路实现

进入正题之后，第一步是数据接入与清洗。我还是以文本分类项目为例，原始数据可能来自多个渠道：业务数据库导出的Excel、爬虫抓取的网页正文、用户反馈的工单文本。第一件事是统一schema，把所有数据源映射到同一个标准格式：

@dataclass class RawSample: sample_id: str text: str source: str created_at: datetime label: Optional[str]

然后建立一个清洗pipeline，按顺序执行这些步骤：

1. 文本去重（用MinHash算法处理大规模近似去重）
2. HTML标签剥除与特殊符号清洗
3. 语言识别过滤（业务只处理中文数据时，把其他语言样本剔除）
4. 长度过滤（过短或过长的样本往往质量差或无意义）
5. PII信息脱敏（手机号、身份证号、邮箱等替换为占位符）

这个pipeline我建议用DVC固化，这样每一步的输出都有记录，后面排查问题能精确到环节。不要小看这个环节，我在实际项目中遇到过因为清洗步骤顺序不当，导致脱敏后的文本被下一步误判为异常符号删除，白白丢掉了20%的有效训练数据。

3.3 训练实验与效果验证的关键细节

数据准备好之后，进入训练实验环节。这里的核心方法论是：不要一开始就上复杂模型，先做基线。我会先用简单的TF-IDF + 逻辑回归跑一版结果，同时用BERT类的预训练模型跑一版，两相对比，才能判断复杂模型带来的增益是否值得额外的计算和部署成本。

以中文文本分类为例，代码层面你需要关注几个关键点。比如用HuggingFace的datasets库做数据切分时，要保证分布一致性：

from datasets import Dataset, DatasetDict import pandas as pd df = pd.read_parquet("data/processed/train.parquet") dataset = Dataset.from_pandas(df) split = dataset.train_test_split(test_size=0.2, seed=42, stratify_by_column="label") dataset_dict = DatasetDict({ "train": split["train"], "validation": split["test"], }) # 确保每个类别的样本量不低于阈值 min_count = 100 label_counts = df["label"].value_counts() assert label_counts.min() >= min_count, f"类别样本过少: {label_counts.min()}"

训练时，我用的是HuggingFace的Trainer接口，它的好处是封装了梯度累积、混合精度、断点续训等一堆细节。但即便有封装，我还是会手动控制几个参数：

• learning_rate：一般在2e-5到5e-5之间，从大到小试
• weight_decay：0.01是一个不错的起点
• gradient_accumulation_steps：在显存不足时通过它等效增大batch size
• warmup_ratio：0.1是安全值，可以确保训练初期稳定

训练完成后，评估不能只看准确率。我至少会看每个类别的精确率、召回率、F1，以及混淆矩阵。因为这些能告诉你的信息远多于单一指标：某个类别样本少导致被牺牲了？还是某两个类别本身存在语义重叠？这些都是模型迭代方向的重要线索。

3.4 模型上线与灰度发布

实验跑通后，真正的工程考验才刚刚开始。模型上线要做的事情远比“把模型文件放到服务器上”复杂。一个标准的上线流程应该是：

1. 把模型注册到MLflow Model Registry，标记为Staging
2. 使用Triton部署新模型到一个独立的服务端口
3. 在预发环境用小流量（比如1%）验证功能和延迟
4. 对比新旧模型的线上指标，确认无回退后逐步放量
5. 全量后观察一段时间，稳定则标记为Production

这个流程里最容易出问题的是新旧模型的切换。我的建议是：新老模型并行部署，用网关层动态切流，而不是直接替换文件。这样可以随时秒级回滚，不至于因为一个上线操作引发大面积线上事故。

关于模型格式，我强烈建议在部署前把PyTorch模型转成ONNX或TensorRT格式，原因很简单——推理性能差距巨大。一个BERT模型在PyTorch下如果单次推理需要15ms，ONNX优化后有可能到8ms，用TensorRT还能进一步压缩。这个过程需要安装onnx和onnxruntime-gpu，转换脚本的大致逻辑是：

import torch from transformers import BertModel model = BertModel.from_pretrained("bert-base-chinese") model.eval() dummy_input = torch.randint(0, 1000, (1, 128)) torch.onnx.export( model, dummy_input, "bert_base_chinese.onnx", input_names=["input_ids"], output_names=["last_hidden_state"], dynamic_axes={"input_ids": {0: "batch_size", 1: "seq_len"}}, opset_version=14, )

转换后务必做精度对比验证：随机取100条样本，分别用原始模型和ONNX模型推理，确认输出差异在可接受范围（比如最大误差小于1e-3–1e-4）。这一步省略的后果，你一定会后悔。

3.5 评测反馈闭环搭建

模型上线只是开始。为了让系统能持续演进，我每次都会搭建一个完整的评测反馈闭环。这个闭环至少包含两条线：

一条是离线评测线：持续积累一份高质量的人工标注评测集，每次新模型训练完都要在这份评测集上跑分。这份评测集要覆盖线上遇到的长尾case和badcase，不然评测指标会失真。

另一条是线上反馈线：线上用户的弱反馈信号（点击、停留时长、后续操作）和强反馈信号（用户主动纠错、屏蔽）必须被回收。技术实现上可以这样落地：

# 记录线上样本及预测结果的日志 log_payload = { "request_id": req_id, "input_text": text, "predicted_label": pred_label, "predicted_score": pred_score, "user_feedback": None # 由后续用户行为异步更新 }

日志进入Kafka后，经过一个定时任务汇总成“待标注池”，定期抽样让人工标注，持续回流到训练集。没有这个机制，你的模型就是开环的——它永远学不会处理那些新出现的case，最终只能靠频繁的手工重训来维持效果。

4. 典型问题与排查技巧实录

这一节我想把实操过程中积累的、几乎每个项目都会踩一遍的问题整理成排查手册。格式不用太正式，就当是朋友之间交流经验，但每条都是我掏真金白银换来的教训。

4.1 数据类问题：模型效果差的头号元凶

问题现象：训练跑了好几个epoch，效果一直上不去，调参也没用。

排查思路，先别急着调模型，先查数据：

1. 打印一条训练样本和对应label，用肉眼确认是否合理。很多时候是label错位——标注时行没对上，导致模型学的全是错的东西。
2. 检查训练集和验证集是否有重叠。我踩过一次很大的坑：用train_test_split时忘了设random_state，结果线上badcase刚好来自验证集里的重复样本，评估指标虚高。
3. 检查数据分布。比如训练集中A类占90%，B类占10%，模型直接全预测A类就能刷到90%准确率。这时候必须用分层切分，或者引入类别权重。

经验法则：数据问题导致的模型异常，占比远高于算法和参数问题。每当你觉得模型“不听使唤”时，先把数据样本翻出来看看。

4.2 推理性能问题：延迟高得离谱

问题现象：离线测试时模型推理速度还不错，一到线上服务，TP99延迟高到用户受不了。

这里面常见的坑有三个：

第一个是没有开启动态批处理。大量用户请求同时到达时，GPU是完全可以一次处理多条的，但如果你的服务配置是一次一请求，GPU利用率极低，表现为延迟高且吞吐低。Triton里开启dynamic batching，能看到立竿见影的效果。

第二个是没有做输入截断。文本类模型的输入长度是决定计算量的关键因素，BERT的时间复杂度是O(n²)，n是序列长度。如果线上输入文本没有长度限制，有些超长文本会把单次推理延迟拉到几十甚至上百毫秒。我的做法是统一截断到512token，超过的做摘要或者分段处理。

第三个是没有做并发压测就上线。我强烈建议大家上线前用locust或wrk之类的工具做一轮压测，看看服务在预期峰值吞吐下表现如何，而不是等线上告警了才手忙脚乱。压测可以顺带探测出线程池太小、数据库连接不够这种隐藏问题。

4.3 线上线下效果不一致

问题现象：离线评测F1有0.9，上线之后却只有0.7，用户反馈经常出错。

这里面最经典的根因是特征不一致。如果你在训练时使用了某个特征，但线上推理时该特征的获取逻辑没有完全对齐，模型看到的分布就会和训练时不一样，效果自然回退。这种问题光看代码很难发现，需要逐字段比对线上实际取到的特征值和训练时的特征值。

其次是环境不一致。训练用的库版本是旧的，部署时升级了一个大版本，某个预处理函数的行为发生了变化，就可能导致预测结果不一致。所以我在部署时强烈建议锁定依赖版本，最好把整个训练环境打包成镜像作为部署基线。

最后是数据滞后。比如线上特征实时计算的内容和训练时批量计算的时效性不同，导致线上看到的分布和训练时不完全一致。这就是我之前提到的Feature Store要解决的根本问题。

给一个快速自检的checklist：

• 确认训练和验证用的是同一份数据切片逻辑
• 在线推理走一遍完整的预处理代码，和训练时的输出对比
• 用线上实际请求喂给离线模型，看结果是否一致
• 检查所有特征是否有默认值策略，线上可能取到空值

4.4 GPU资源利用率低

问题现象：GPU利用率只有30%左右，跑一个训练要两三天，成本高得离谱。

排查的过程中，按优先级检查和调整下面几个点：

第一，数据加载是不是成了瓶颈。如果DataLoader的num_workers太少，GPU会一直在空转等数据。我之前遇到过num_workers=2导致GPU利用率只有20%的情况，调到8之后直接翻倍。

第二，批大小是否合适。batch size太小导致计算无法充分利用GPU并行能力，但也不宜太大，要结合显存和模型收敛特性平衡。多试几个值（16/32/64），从指标曲线上能找到最优解。

第三，检查是否使用混合精度。对大部分深度学习模型，自动混合精度（AMP）能在几乎不损失精度的情况下提升训练速度。PyTorch里开启方式很简单：

from torch.cuda.amp import autocast, GradScaler scaler = GradScaler() with autocast(): loss = model(batch) scaler.scale(loss).backward() scaler.step(optimizer) scaler.update()

另外一个隐蔽但常见的坑是把模型留在了CPU上而不自知。排查时随手执行nvidia-smi看看当前进程是否真的在GPU上，往往能省下大量排查时间。

4.5 实验管理混乱

问题现象：每个人都在用自己的方式记录实验，代码、数据、参数对不上号，无法复现。

这个问题的根源是缺少“强制规范”。工具只是辅助，关键是流程。我推荐的最小规范是：

• 必选：实验记录里锁定Git commit号
• 必选：记录数据版本（DVC版本号或文件哈希）
• 必选：记录全部关键超参，不只是改了的那几个
• 必选：对每个模型归档训练日志文件和评估结果
• 强烈建议：把“成功实验的完整复现步骤”写成文档

在MLflow里，这些都可以通过tag和description来组织。一个好的实践是：每个正式实验都写一行简短描述，说明这次实验的动机和结论。你会感谢当初那个愿意多写一行字的自己。

5. 一些可能对你有用的补充建议

聊到这儿，整个“ai-engineering-from-scratch”的核心链路和实操方法都过了一遍。工程落地这件事，本质上不是“会不会某个框架”的问题，而是一个“如何把散点串成线、把线织成网”的系统工程。我最后再分享几个从项目里总结出来的原则和做法，希望能给你一些参考。

5.1 用小项目练手，不要一上来就搞大系统

如果你现在还没有完整走通过一条AI工程链路，我最实在的建议是：找一个小到不能再小的项目，比如一个二分类文本分类器，从数据版本管理到模型上线，完整走一遍。规模小没关系，关键是让“数据-训练-部署-监控-反馈”这个闭环在你手里真实转动一遍。

为什么要这么大费周折？因为大部分纸面上的理解，只有落到真实流程中才会暴露出缺口。比如你觉得自己会部署模型，但第一次做灰度发布、第一次画监控大盘、第一次回滚版本之后，你才真正理解“模型上线”这四个字的重量。

5.2 标准化优先于优化

项目初期，花太多时间优化推理性能或调参，往往得不偿失。我的经验是：先用标准做法把全链路跑通，再针对瓶颈做优化。所谓“标准做法”是指不出来花活、用社区验证过次数最多的方案。当整条链路是稳定可复现的，你后续做的每一个优化才有衡量的基准。

比如推理性能优化，不要一上来就上TensorRT，先用ONNX跑通，确认线上收益再进一步。每次只改变一个变量，确保你能判断变量的真实影响。这在实验阶段和优化阶段都适用。

5.3 自动化一切可以自动化的流程

当你的项目进入稳定期后，把精力花在自动化上是ROI最高的投入。我现在不管什么新项目，都会尽早搭好CI/CD的架子：

• 代码提交触发单元测试和代码检查
• 数据变更触发数据校验
• 训练完成自动在评测集上跑分并更新看板
• 模型注册后自动触发预发环境部署和烟雾测试

这套东西一旦搭好，每次迭代的时间成本会大幅下降。而且更关键的是，自动化把“人忘记”这个最大的风险消灭了。

回顾我自己这几年做AI项目的过程，最大的感受是：AI工程能力的提升，不是靠读多少篇论文、跑多少场比赛，而是靠一次次完整的项目闭环积累出来的肌肉记忆。希望这篇围绕“ai-engineering-from-scratch”的梳理，能帮你少走一些弯路。如果你正好也在搭建自己的AI工程体系，不妨从小闭环开始试起来——做完第一版，你再回头看这篇文章的很多细节，就会有完全不同的感受。