做AI工程两年，从零开始摸爬滚打，踩过无数坑，今天把这些真实经验写出来。很多教程都在讲Python、TensorFlow、模型调参，却没人告诉你从“写业务代码”到“搞定一个AI项目落地”中间到底要经历什么。这篇文章不是教科书，更像是我自己的工作笔记：先弄清楚AI工程到底在解决什么问题，再把一个完整项目从选题、数据、模型、部署到监控全部走一遍，最后告诉你哪些坑可以提前避开。如果你有编程基础，但对机器学习一知半解，又想真正做出一个能用的AI系统，这篇内容应该能帮你省下至少三个月的摸索时间。
1. 起步之前必须先想清楚：AI工程到底解决什么问题
1.1 我最初理解的AI工程 vs 实际面对的AI工程
我最早以为AI工程就是训练模型——把数据喂进去，调参，等准确率上去，完事。真正上手之后才发现，训练模型只是整个链条里的一小段，甚至不是最耗时的一段。一个AI项目要落地，通常包含数据获取与清洗、模型选择与训练、服务封装、接口设计、部署上线、效果评估、持续监控与迭代，这一整套闭环才叫AI工程。单独一个模型，哪怕准确率99%，放不进业务里就是废的。
刚开始我接手第一个任务时，老板说“把用户的工单自动分类”。听起来不难，无非是文本分类。但我当时连数据长什么样都没看过。后来才知道，真实工单里充斥着错别字、行业黑话、图片截图和Excel粘贴的乱表格，光清理数据就花了一周。那一刻我才真正意识到，AI工程的核心不是模型，而是构建一个让模型能在真实环境里稳定运行的系统。
1.2 一个AI系统的构成部件
如果你从零开始自己搭一个AI系统，哪怕是最简单的，也要面对以下六个部件：
- 数据源与存储：原始数据从哪里来？存在数据库、日志文件还是第三方接口？
- 预处理流水线：去重、清洗、格式化、标注，让原始数据变成模型能吃的输入。
- 模型服务：你选择的模型怎么跑起来？是用API调用还是自己部署推理服务？
- 业务接入层：模型输出的结果怎么返回给业务方？是JSON接口、消息队列还是直接写库？
- 评估与监控：你凭什么说模型效果好？线上效果掉了你知不知道？怎么定位是数据问题还是模型回归？
- 反馈与迭代：模型错了怎么办？用户的反馈怎么回收用来重训？
很多人把“AI工程”约等于“模型训练”，实际上它是一门系统性的软件工程。理解这个全局，比多学几个模型算法重要得多。
1.3 谁适合从零开始搞AI工程
我的判断标准很简单：你不需要先成为算法专家，但你一定要有写工程代码的能力。真正落地时，写数据预处理脚本、调接口、修并发冲突、容器化部署这些能力，几乎决定了项目能不能上线。当然，你得有耐心反复看数据，还得能接受“效果不好是常态”。
如果你只是想调个Demo，或者想发论文，这篇内容并不适合你。但如果你想做一个面向真实用户的AI应用，不管你是后端转AI、前端转AI，还是测试转AI，这条路是走得通的，只是需要把“工程”二字放在“算法”前面。
2. 从零到一的完整路线：我给自己的三步走
2.1 第一步：把AI原理当黑盒，先跑通一个最小闭环
我当时犯的最大错误是花了三周看理论，正儿八经啃《深度学习》里的大量数学，结果连一个模型都没跑通过。后来我调整了策略：不管原理，先老老实实把一个流程跑通。比如做文本分类，我用一个开源的BERT模型，加载预训练权重，用现成的库把文本转成向量，再训练一个分类头，能跑通就行。
这一步的目标只有一个：让你亲眼看到数据是怎么流进模型、模型又是怎么吐出结果的。这个最小闭环会帮你建立直觉，知道哪一步该用什么工具。跑完之后你会发现，理论里的“前向传播”“损失函数”都会变成调试时的具体输出数字，抽象概念会落地。
2.2 第二步：再回头补基础，重点是数学和数据处理
跑通第一个Demo之后，我开始有目的地补基础。补什么最值钱？不是高等数学，而是两个东西：概率统计和数据处理思维。
概率统计是为了看懂评估指标——准确率、召回率、AUC、置信区间，这些东西在你优化模型时会反复用到。数据处理思维则更偏实践，像是缺失值怎么处理、类别不平衡怎么办、数据分布漂移意味着什么。这些知识不需要你从头啃完一本厚厚的教材，而是遇到具体问题再去查、去补，效率最高。
2.3 第三步：系统化工程化，补上测试、版本、自动化
当模型效果差不多能看了，接下来所有的精力都应该放在工程化上。这里说的工程化包括：
- 代码版本管理：数据清洗的脚本、训练代码、推理服务代码，全部用Git管理，甚至数据集也需要版本管理，否则一个不小心改了数据，所有历史实验全部作废。
- 模型版本管理：模型文件要带版本号，记录训练时间、数据版本、评价指标。否则你根本说不清线上那个模型到底是用哪批数据训出来的。
- 自动化测试：给数据清洗代码写单元测试，给接口写自动化测试，防止改一处代码把整个流程带崩。
- 部署流水线：用Docker打包模型服务，用CI/CD自动构建和部署，简化上线过程。
这三步的顺序是我实际踩坑后总结出来的。很多人一上来就教程式编程、学深度学习原理，结果三个月过去了还在“准备学习”。从零开始搞AI工程，就应该先动手、见效果，再倒回去补理论基础，最后用工程标准来严格要求自己。
3. 第一个AI工程项目的完整拆解
3.1 项目背景：挑一个什么都能用上的任务
我的第一个完整项目是一个“智能工单分类系统”。业务方每天收到几百条用户反馈，需要把它们分成“故障报修”“业务咨询”“投诉建议”等七八个类别。这是一个典型的短文本分类任务，难度适中，而且能覆盖数据清洗、模型训练、服务部署、效果评估所有环节。
为了让你能照着做，我尽量把流程写具体。哪怕你对业务场景不感兴趣，里面的方法论是通用的。
3.2 数据准备：从爬虫到标注坐标
数据是项目的起点。我们当时从客服系统导出了近一年的工单，大概两万多条。乱得要命：有的字段是乱的，有的把对话全塞在一起，还有的完全是广告垃圾。我花了两天写了清洗脚本：
# 简单示例：清洗文本 import re import pandas as pd def clean_text(text): text = text.replace('\u3000', '') # 去全角空格 text = re.sub(r'\d{4}-\d{2}-\d{2}', '', text) # 去日期 text = re.sub(r'[^\u4e00-\u9fa5A-Za-z0-9，。！？、""]', '', text) # 去特殊符号 text = re.sub(r'(客服|您好|谢谢|感谢)', '', text) # 去客套话 return text清洗完还剩一万七千多条。接下来是标注。我本来想用现成的标注团队，但预算不够，就自己标了三千条，每条花十几秒，连续搞了小一周。这个过程非常枯燥，但好处是你会非常清楚每条数据为什么会被分成这个类，这对后来的调优帮助极大。
标注规范一定要在动手前定好。比如“退款”和“退货”之间的边界是什么？“投诉”和“咨询”怎么区分？如果不定义清楚，两个人标出来的结果天差地别。我当时给每个类都写了几个典型示例，标注时有拿不准的案例就建一个讨论清单，攒够一起商量。
3.3 基座模型选型与微调：我为什么选了开源模型而不是闭源API
一开始我想调用某个商业API，省事，但后来发现两个问题：一是数据安全，工单里包含用户手机号和地址，公司不允许把数据送到外部；二是费用，每天几千次调用，按照当时的报价一年下来是一笔不小的开销。所以我转向了开源模型。
针对短文本分类，我选了一个中文预训练BERT系列模型。为什么是BERT而不是GPT或者更大规模的模型？因为分类任务不需要生成文本，用一个具有双向编码能力的预训练模型，在顶部加一个分类层就够了。模型体积不算大，一块普通的GPU就能微调，推理速度也快。
以下是微调的大致步骤：
# 使用transformers库进行微调 from transformers import AutoTokenizer, AutoModelForSequenceClassification, Trainer, TrainingArguments tokenizer = AutoTokenizer.from_pretrained("bert-base-chinese") model = AutoModelForSequenceClassification.from_pretrained("bert-base-chinese", num_labels=8) def tokenize_function(examples): return tokenizer(examples["text"], truncation=True, max_length=128) dataset = dataset.map(tokenize_function, batched=True) training_args = TrainingArguments( output_dir="./results", num_train_epochs=3, per_device_train_batch_size=16, per_device_eval_batch_size=32, evaluation_strategy="epoch", save_strategy="epoch", logging_dir="./logs", ) trainer = Trainer( model=model, args=training_args, train_dataset=train_dataset, eval_dataset=eval_dataset, ) trainer.train()整个过程看起来简单，但坑很多。比如max_length不能设得太长，否则训练速度很慢；学习率设得太大，Loss直接吹飞。这些经验只能靠一遍遍实跑来积累。
3.4 Prompt工程实战：让模型按我的格式输出
微调完成之后，我又遇到了新的需求：同一个分类系统还要能从工单里提取“设备型号”“故障代码”“期望售后时间”这些关键信息。使用纯BERT做序列标注也能实现，但灵活性不够。后来我尝试用一个大一点的生成式模型，通过设计Prompt来完成。
Prompt工程的核心是“把模型的输出格式管住”。我写了一个模板：
你是工单信息提取助手。请从下面的工单文本中抽取字段： - 设备型号：___（若无填写“无”） - 故障代码：___（若无填写“无”） - 期望时间：___（若无填写“无”） 工单内容： {text} 请严格按照上述格式输出JSON。一开始模型输出乱七八糟，会多出注释、解释甚至反引号。后来我在每个Prompt后面加上“只输出JSON，不要输出其他内容”，并把温度调到0，输出才稳定。再往后我甚至用正则把JSON从输出里抓出来，防止意外文字干扰。
Prompt工程并不是“翻译几句话”那么简单，它涉及到格式约束、指令清晰度、强效示例。最有效的提升方式是准备好few-shot示例，把三个不同情况的真实工单放进Prompt里，模型理解准确率会高出一截。
3.5 部署与性能优化：FastAPI + Docker + 并发
模型训练好只是开始，真正折磨人的是部署。我用FastAPI写了一个极简的推理服务：
from fastapi import FastAPI from pydantic import BaseModel import torch from transformers import AutoTokenizer, AutoModelForSequenceClassification app = FastAPI() tokenizer = AutoTokenizer.from_pretrained("model_dir") model = AutoModelForSequenceClassification.from_pretrained("model_dir") model.eval() class Item(BaseModel): text: str @app.post("/classify") def classify(item: Item): inputs = tokenizer(item.text, return_tensors="pt", truncation=True, max_length=128) with torch.no_grad(): outputs = model(**inputs) probs = torch.softmax(outputs.logits, dim=-1).tolist()[0] label_id = probs.index(max(probs)) return {"label": label_id, "confidence": max(probs)}这样跑起来没问题，但单进程扛不住流量。我用了gunicorn起多worker，并提前把模型加载进内存，避免每个请求都重新加载。模型推理会占用CPU和GPU资源，还要加一层缓存，把相同文本的结果缓存起来，减少重复计算。
Docker打包也踩了坑。模型的torch和transformer版本、CUDA版本、显卡驱动必须匹配，否则容器里根本调不动GPU。后来我干脆把基础镜像固定为一个经过验证的PyTorch镜像，所有依赖都锁死版本，才彻底解决。
3.6 上线后的监控：不盯着Loss，盯业务指标
部署上线后，我最大的心理落差在于：模型在测试集上的准确率有92%，但到了线上怎么感觉处处出错？后来我才意识到，离线指标只能代表历史数据环境，线上数据分布跟训练时完全不一样。
我搭了一个简单的监控看板，统计每天的预测分布、置信度均值、人工反馈后的纠错数量。关注点从“Loss降了多少”变成了“有多少预测结果被业务方打回”。一旦发现某类别的预测占比异常升高，赶紧去查是不是数据发生了变化。这一个习惯救了我很多次，避免了好几次“模型偷偷变坏”而没人发现的危机。
4. 这些坑我替你踩过了，别再犯
4.1 环境依赖地狱
这是我遇到的第一个大坑。Python版本、CUDA版本、PyTorch、TorchVision、Transformer库，每一个版本之间都有隐藏的兼容性问题。有一次我按教程装了最新版PyTorch，结果和旧的CUDA驱动冲突，训练时直接报undefined symbol。后来我学会了每次新建项目都用虚拟环境，并且把所有依赖版本写死在requirements.txt里。做AI项目，稳定比新版本更重要。
4.2 训练数据泄漏：我如何发现我的评估指标虚高
我在做分类任务时，发现验证集准确率奇高，接近98%，但到小批量人工抽检时表现却一般。排查了很久，最后发现是数据清洗时删掉了日期，但预处理脚本在切分训练/验证集之前就做了去重，导致同一条工单可能既在训练集又在验证集里。数据泄漏会让模型“背答案”，看起来效果好，一到真实世界就露馅。
正确的做法是先切分数据集，再分别清洗和去重。这个顺序不能乱。另外，要保证训练集和验证集来自不同的时间窗口，否则可能把时间相关性当作分类依据，长期失效。
4.3 盲目用大模型导致推理成本爆炸
有一段时间，所有同事都觉得用大模型效果好。我也尝试把分类任务换成大模型调用，Prompt写得很爽，但线上推理耗时从几十毫秒变成了几秒，成本暴涨，高峰期限流。后来我改用蒸馏的方式：用小模型在线推理，大模型作为“离线老师”生成标注样本，用小模型学习大模型的输出。这样既保证了效果，又把单次推理成本压低了两个数量级。
4.4 只重视模型不重视数据，模型上线就废
很多初学者的常见心理是：模型效果不行就换模型、调参数。其实大部分问题都出在数据上。我遇到过分类混淆严重的类别，点开原始数据一看，两条工单文本长度差了几十倍，短的一条信息严重缺失，模型根本无从判断。这时候再不进步，靠人工补充同类样本，加规则前置处理，效果立刻改善。数据质量决定效果上限，模型只是逼近这个上限。
4.5 忽略人工反馈闭环
模型上线前，我漏了一个关键环节：怎么收集“模型错了”的证据。业务方每天会人工修正一些分类结果，但当时这些修正只是滞留在业务系统里，没人回流给我。等于把高质量标注数据白白扔掉。后来我加了一个表，专门记录“用户修正记录”，每半个月导出来重训一次模型，效果提升非常明显。做AI工程，反馈闭环就是造血机制，没有闭环的模型只会越来越偏离真实。
5. 给新入坑的人：如果现在重新开始，我会怎么做
5.1 按周拆解的学习计划
如果有人让我重新从零开始，我会给自己定一个八周计划：
- 第1周：熟悉Python数据处理，学会用pandas清洗结构化数据，掌握简单的正则和文本处理。
- 第2周：跑通一个开源的完整AI Demo，例如用Hugging Face的分类模型，理解数据输入到输出的调用过程。
- 第3周：学习评估指标。找一批真实分类样例，用不同指标观察模型表现，搞懂准确率、精确率、召回率的区别。
- 第4周：学习数据增强与重采样。自己动手处理类别不平衡的问题。
- 第5周：用FastAPI写一个模型服务接口，叠加Docker部署，知道怎么把模型包进容器。
- 第6周：学习模型监控知识，比如记录预测分布、置信度、错误样本分析。
- 第7周：完成一个小项目，端到端走一遍，从数据准备到线上监控。
- 第8周：复盘和总结，把踩过的坑整理成自己的检查清单。
这八周不追求深度，但一定要完整。比起“把模型训到99%”，我更建议领先跑通全流程。
5.2 必备工具清单
我用得最顺手的工具都有明确的定位：
- LangChain：编排AI工作流、调用模型和工具时用，尤其是做Agent或者复杂链条时，能把代码写得更整洁。
- FastAPI：封装推理服务。比Flask更现代，自带API文档，维护起来轻松。
- Docker：管理模型和环境依赖。一个容器打遍所有环境，避免“在我电脑上是好的”。
- WandB或MLflow：实验跟踪。跑几十次实验后，光靠文件名根本分不清哪个模型是什么版本。
- PostgreSQL或MySQL：存业务数据和标注反馈，给模型闭环提供数据支撑。
工具不在多，能解决实际问题就好。很多人一先列一堆工具列表，结果一个都没深度使用。我的建议是一轮只上一种，用熟之后再加。
5.3 我的最后一条建议
做AI工程，拼的是耐心和排查能力，不是智商。你会遇到大量“看起来无从下手”的问题，比如模型输出突然全变成一类，或者接口延迟时高时低。大多数时候，问题不在算法，而在数据、代码和环境。多问自己一句：如果这个现象是数据错误导致的，凭据是什么？如果是代码bug导致的，怎么验证？
如果让我只保留一种能力，我会选“快速定位问题的能力”。这种能力不在课本里，只能靠一次次线上排障练出来。哪怕你只是从零开始跑通了一个很小的AI工具，也已经在成为一个AI工程师的路上了。把我踩过的坑当作警示牌，然后放心大胆地去踩你自己那条路上的新坑吧。
