我做AI工程这几年最大的感受是模型能力决定天花板工程能力决定你能不能摸到那块天花板。很多人背着AI工程师的头衔其实每天都在写Prompt、调参数、跟跑不动的推理服务搏斗。真正从零开始做AI工程不是说要你从线性代数重新学起而是要把AI从能跑变成好用、可维护、可迭代。这篇文章写给想转行做AI应用开发的同学、刚带AI项目但心里没底的技术负责人以及所有被模型能跑但产品不稳折磨过的朋友。我会从概念边界讲起给出一条完整的技术路线再用一个客服工单分类的小系统作为案例把数据、模型、部署、评测这几个环节逐一走一遍。里面的代码都是直接可以拿去改的最小实现参数我也尽量给到可复现。1. 先搞清边界AI工程不是调模型1.1 从Notebook到稳定服务中间隔着一条河打开Jupyter Notebook跑一个分类模型输出准确率很漂亮这不算AI工程。AI工程是从你决定把这个模型放到线上每天服务上千次请求那一刻开始的。线上环境不会像Notebook那样给你重来的机会请求会乱序到达输入会带脏数据模型会偶发抖动第三方依赖说挂就挂。你还要考虑日志、监控、告警、回滚、灰度发布这些东西没有一个是AI算法能解决的但缺了任何一个模型再强也撑不住一个真正的产品。我见过太多团队离线指标97%上线第一个星期就被用户骂智障。为什么因为离线数据集是清洗干净、分布均匀的线上输入五花八门。举一个真实例子我们的客服工单分类模型在测试集上准确率93%上线后却发现所有退款类工单都被分到了咨询。排查了很久才明白线上系统传入的工单描述里多了很多表格排版符号模型之前没见过这种格式注意力全被符号带跑了。这是典型的训练/线上数据分布不一致问题属于工程问题而不是算法问题。顺带说一句AI工程和算法研究是两码事。算法岗的重心是怎么让模型更准比如改进网络结构、优化损失函数AI工程的重心是怎么让模型在真实环境里稳定地准。在我的团队里算法研究和AI工程是两种岗位前者可以长期在一堆实验里折腾后者则必须对线上系统负责。从零开始学AI工程没必要先啃论文先把工程闭环跑通再回头补理论会更有方向感。1.2 AI工程的四个核心能力域如果让我用一个简单的框架来拆解AI工程可以分成四块数据工程、模型工程、推理部署工程、评测观测工程。下面这张对照表把每一块的核心任务和常见工具体现出来也方便你对照着检查自己的短板。能力域核心要解决的问题常用工具/手段数据工程数据从哪来、怎么清洗、怎么验收、怎么版本化Pandas、SQL、dbt、DVC模型工程模型选型、微调、量化、压缩保证效果达标Transformers、PEFT/LoRA、ONNX推理部署工程把模型变成高可用、低延迟、可伸缩的在线服务FastAPI、Docker、K8s、vLLM评测观测工程效果怎么衡量、线上表现如何追踪、问题如何定位评测集、MLflow、Prometheus/Grafana这四块不是按时间顺序执行的而是滚动迭代的。你从最小可用的数据管线开始做一版模型部署上线然后在观测中发现数据问题再回来改数据。走通一轮之后才算真正入门。我强调一点大多数教程只教第二块也就是模型工程甚至只教到调用模型API就停了。但实际上一个AI产品80%的坑都出在数据、部署、评测这三块。你在实际工作中遇到瓶颈先不要急着换模型先检查是不是数据或评估环节出了问题。1.3 与普通软件工程的差异AI工程和普通后端工程最大的不同在于普通软件的输入输出是确定的同一个输入永远得到同一个输出而AI模型的输入输出是概率性的同一个Prompt今天和明天可能给出完全不同的答案。这意味着你需要额外加一层结构化兜底限制输出格式、加规则校验、对低置信度结果做人工兜底。这些手段里我最看重的是规则校验。比如分类任务里我要求模型必须返回JSON解析失败就重试一次如果重试还失败就返回待人工处理而不是把模型输出的乱码直接抛给用户。再比如做摘要我会检查摘要里是否包含工单号、金额这类关键实体缺少就触发补充逻辑。尤其是涉及钱、订单、法务等场景必须有兜底逻辑不能直接信任模型输出。这不是对模型不信任而是对概率性的基本尊重。2. 从零起步路线图与最小技术栈从零开始最怕两件事一是不知道学什么什么都学最后什么都没学会二是被框架和工具淹没今天看LangChain明天学Dify后天又被Agent热潮带走。我的建议是先跑通一条极简链路再往两边扩展。先讲技术栈再讲路线。2.1 编程基础把Python工程习惯练好做AI工程Python是必须的但重点不是语法而是工程习惯。你至少要熟练这些使用虚拟环境管理依赖venv、conda、uv避免一套环境跑多个项目互相污染掌握requirements.txt或pyproject.toml依赖锁定让别人能一键复现会写简单的单元测试至少会assert输入输出的关键分支能读懂异常堆栈看到KeyError、TypeError时能快速定位。我见过很多从算法转工程的同学模型写得不错但代码里全是全局变量跑完一个脚本还要手动清理内存部署时连路径都写死。这些习惯不改后面做服务化、多人协作会很痛苦。关于环境管理我补充一个实操心得项目刚起步时直接用venv加上一个requirements.txt就够了没必要上太重的工具。等团队超过三个人、项目超过两个再迁移到uv或Poetry。过早引入复杂工具代价比收益大。2.2 数据、模型、部署三层的入门组合从零开始技术栈真不需要多每个方向选一件趁手的工具就行数据处理Python自带的csv/json库加Pandas最多加SQL足够。不要一开始就上Spark模型调用先学会调用一个大模型API或者用HuggingFace Transformers加载一个小规模开源模型模型服务化FastAPI加Uvicorn一个轻量HTTP服务就能搞定不需要一上来就上K8s容器化Docker把服务连同依赖打包保证本地和线上环境一致。我培训新人的时候会要求他们完成一个最小依赖练习不给requirements.txt只给一个空环境让他们用pip逐个把依赖装起来把服务跑通。这个练习看起来蠢但能逼你理解每个包是干嘛的而不是复制粘贴一个成熟项目。实测效果不错能过滤掉一大批只会复制的人。工具的选用也一样Pain点没出现之前别提前用重型方案。2.3 从Prompt到Agent的能力演进很多新人一上来就追Agent其实顺序反了。我的建议是先玩熟单轮Prompt再学多轮对话再学RAG最后才是Agent和工具调用。为什么因为Agent的本质是模型加循环加工具模型负责决策循环负责反复执行工具负责和外部世界交互。如果你不理解模型在什么情况下会出错不理解Prompt的约束边界那你做出来的Agent就只是在不断循环一个糟糕的决策。单论Prompt Engineering也有一个从零开始的基本功怎么写系统提示词怎么给示例few-shot怎么限定输出格式怎么处理模型不遵守格式的情况。我在实际项目中发现大多数Prompt问题都能靠把约束写具体、把示例给足、把输出校验加上这三板斧解决。调Prompt不是玄学而是工程。举个例子SYSTEM_PROMPT 你是一个工单分类助手。请将用户工单分类到以下类别之一咨询、退款、投诉、其他。 只输出JSON不要输出任何附加说明。 格式{category: 类别, reason: 一句话原因}这一段提示词看上去简单但它包含了三件事角色定义、任务边界、输出格式。新人写Prompt最常见的问题就是角色和任务都模糊模型只能靠猜。把这三件事在系统提示词里说清楚很多问题就消失了。3. 实操用客服工单系统走通最小AI工程闭环前面讲了很多概念这一章我们落地。我建议所有人都应该从自己手头最痛的问题开始而不是搭一个模范项目。为了讲清楚我这里拿客服工单分类摘要当案例。业务需求很简单客服每天收到上千条工单需要人工判断是咨询、退款、投诉还是其他还要人工写一句摘要。我们要做一个服务输入工单文本输出分类标签和一句话摘要。这个项目的好处是数据容易获取哪怕自己模拟几十条、效果容易判断、部署也不复杂但麻雀虽小五脏俱全。3.1 选一个足够小、足够真实的问题第一步是定义清楚输入和输出。输入是一条工单文本可能很长可能带错别字可能混入表格符号输出是三个字段分类、理由、摘要。这一步看起来简单但你必须跟业务方对清楚——分类到底分成几类、摘要写多长、理由要不要展示给用户。很多时候项目翻车不是模型不行而是需求里的模糊地带太多。我的建议是第一版把范围压到最小。比如分类只做四类咨询、退款、投诉、其他。摘要限制在30字以内。先做出一版用户能用的东西再考虑多分类、情感分析、自动回复这些扩展。从零开始的项目最忌讳一口吃成胖子你半年做不出来一个大而全的系统但两周一定做得出一个小而有用的服务。用这个小服务去和业务方建立信任后面所有资源都好谈了。3.2 数据准备与评估集设计数据是AI工程的起点。第一步是收集原始数据。如果公司有历史工单直接导出前三个月的如果没有自己写20条种子数据再人工变体生成到100条左右注意覆盖不同渠道、不同语气、不同表达习惯。第二步是清洗。把空值、乱码、纯符号文本处理掉统一编码为UTF-8把换行符处理好。很多人会忽略这一步但线上数据往往就是脏的所以必须在入口做一层清洗函数后面部署时复用它。第三步是构建评估集这一步比训练集还重要。我会单独留出50条人工标注好的黄金样本这些样本不会被用于任何训练或提示词优化过程只在模型迭代时用来算准确率。如果发现改了一版Prompt后这50条上的准确率掉下来那就不该上线。这相当于给模型迭代加了一个回归测试。我习惯把评估集的标注标准写成文档哪怕只有三页纸也要写清楚边界情况比如既提到退款又骂人的工单算投诉还是退款。3.3 模型选型与调用策略模型选型一句话在效果、成本、延迟之间找平衡点。起步阶段可以直接调用一个大模型API用Prompt做分类和摘要等量上来了、成本压力大了再考虑蒸馏到一个小模型上做微调。市面上大多数提供大模型API的服务商都兼容OpenAI的调用格式代码结构大同小异。下面是一个最小实现import json import os from openai import OpenAI client OpenAI(base_url你的API地址, api_keyos.getenv(LLM_API_KEY)) def classify_ticket(text: str): resp client.chat.completions.create( model你的模型名, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: text} ], temperature0.1, response_format{type: json_object} ) content resp.choices[0].message.content return json.loads(content)注意三处细节temperature调低让输出稳定response_format限定JSON解析时用try/except兜底因为再强的模型也可能突然输出不合法JSON。另外不要把API Key写在代码里而是用环境变量。部署时如果你发现日志里打印了密钥那基本等于裸奔。这些是最基本的工程习惯但很多从零开始的项目都栽在这里。3.4 部署与API化模型链路在本地跑通后下一步就是封装成服务。我用FastAPI来写代码大概长这样from fastapi import FastAPI, Request from pydantic import BaseModel app FastAPI() class TicketRequest(BaseModel): text: str app.post(/classify) async def classify(req: TicketRequest): try: result classify_ticket(req.text) return {ok: True, data: result} except Exception as e: return {ok: False, error: str(e)}这里有三个关键点用Pydantic做输入校验保证接口不会收到空字符串或者超级大的恶意输入返回结构统一成ok/data/error三字段客户端逻辑会简单很多异步接口里不要阻塞CPU密集操作如果单次调用模型耗时较长后续要引入队列或任务系统。本地验证后写一个Dockerfile打包。Dockerfile的关键是镜像分层先把依赖装好再拷代码这样代码变了只需要重新构建最后一层。我见过把整个项目塞到一个镜像里的构建一次要十几分钟改一行代码也要全部重来。稍微注意一下分层的顺序体验能好很多。FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD [uvicorn, main:app, --host, 0.0.0.0, --port, 80]3.5 评测、上线与迭代闭环上线之前先跑一遍流程拿评估集50条样本跑一遍推理算分类准确率和摘要的ROUGE分数如果分类准确率低于90%先回去调Prompt或清洗规则达到标准后小流量灰度。我自己常用的及格线是分类任务准确率90%起步涉及投诉类的召回率不低于85%。达不到就继续迭代不要硬上。上线之后真正的比赛才开始。我会每天拉日志统计接口请求量、耗时、成功率以及抽样看结果质量。重点看两类样本模型低置信度的样本、用户明确反馈处理不对的样本。这些样本积累一周构建成新的补充评估集每一到两周做一次版本更新。至此一个最小AI工程链路已经完整跑通。你回头看数据、模型、部署、评测每一环都碰过了。有了这个骨架后面加RAG、加Agent、加多模型协作都是在骨架上填肉。4. 再往前走性能、版本与工作流编排如果只是做Demo第三部分已经够了。但真实项目要往前走一步把工程深度补上。这一部分挑三个高频主题推理性能、版本管理、工作流编排。4.1 推理性能优化别让模型拖垮系统模型推理慢、贵是AI工程最常见的痛点。优化手段按性价比排序缓存、请求合并batching、量化、换硬件。先说缓存。用户重复发同一类工单的概率很高比如我想退款这类常见问题。可以做一个语义缓存把请求文本做哈希或嵌入向量检索如果和历史请求相似直接返回之前的结果省一次模型调用。这个优化在客服场景实测能省30%-50%的调用量。再说batching。如果你用的是自部署模型单条请求单独推理很浪费GPU。可以在服务层把N个请求攒成一个批次一起送入模型。参数上我常用动态batch设置最大batch大小为8等待窗口为0.2秒意思就是0.2秒内到的请求攒一批凑不够8条也发出去。这样吞吐能提升好几倍但响应延迟会略有上升需要取舍。量化是另一个方向把模型从fp16压到int8速度提升明显显存减半效果损失一般可以接受。我测试过不少开源模型int8量化在大多数任务上准确率下降不到1%。要注意的是量化工具链选错了会非常折腾先认准ONNX Runtime或你所在推理框架官方支持的量化路径。4.2 版本管理与实验追踪模型不是代码不能用Git简单管理。模型会变数据会变Prompt会变评测结果也会变。如果不做版本管理一个项目三个月后没人说得清线上跑的是哪一版模型的哪个量化版本。工具方面我日常用MLflow做实验追踪记录每次实验的模型、参数、指标用DVC管理数据版本对模型文件本身会打上标签比如v3_0715_acc0.93_int8。这样任何时候线上出问题都能直接回溯到是哪个版本引入的回归。这里分享一个从实战中得来的习惯每次改Prompt或者换模型都要记录这次改动的动机、预期的效果变化、实际的效果变化。哪怕只是记在一个Markdown表里也能省下大量后悔时间。AI工程项目最大的隐性成本是想不起来当时为什么这么做。举一个例子日期改动内容动机效果0715Prompt增加few-shot示例提高退款类召回率退款召回率从72%升到86%整体准确率降1%0720换用int8量化降低延迟P99从1.8s降到0.9s准确率降0.4%这样的记录看起来简陋但关键时刻能救命。线上效果回退了翻这张表就知道哪个开关该回滚。4.3 从单模型到Agent与工作流当你需要多个模型协作或者一个任务需要多步处理时就开始接触Agent和工作流编排了。从工程角度我会把Agent拆成三个环节决策模型、执行循环、工具集。决策模型负责判断下一步做什么执行循环负责让模型和工具不断交替执行直到完成目标工具集是模型能调用的外部能力比如查订单、发邮件、调用内部API。在这个结构里工程核心不是怎么让模型聪明而是控制循环的边界最大迭代次数、超时时间、工具调用的权限校验、中途失败的恢复策略。这些控制项没有一个是算法问题但每一个都决定Agent在生产环境是可用还是翻车。工具调用本身的编排有很多框架LangGraph、Coze、Dify等但如果团队能力有限我建议先自己用JSON格式手工实现几轮工具调用理解状态流转之后再选用框架。框架帮你省时间的前提是你能看懂它在做什么否则出问题的时候你只能在黑盒外面干着急。5. 常见问题与避坑实录这部分都是我在真实项目里踩过的坑我尽量按症状-原因-解法来写。5.1 数据坑标注不一致与分布偏移第一个坑是标注不一致。两个人标同样的工单一个标投诉一个标退款模型学到的就是噪音。解决办法写标注规范、试标50条计算标注一致性、不一致的样本由第三人仲裁。我在项目里用三个字母衡量数据质量A完全一致、B可接受分歧、C必须清洗定期去看分布。如果C类超过10%标注规范一定有问题不要急着训模型。第二个坑是分布偏移。训练数据里咨询占70%模型学到的先验概率就是什么都像咨询。线上分布变化时你会看到准确率跳水。我的做法是在评估集里刻意做一个分层抽样让每个类别占比和线上接近而不是均匀分布这样更贴近真实情况。如果你发现线上真实分布和评估集差异很大那就该重新采样本了。5.2 效果坑别只盯着准确率分类模型只看总体准确率不够还要看混淆矩阵特别是关键类别的召回率。比如投诉如果被分到咨询用户会非常不爽这个错误的代价远高于两类咨询互相混淆。所以我会给每个类别设置单独的召回率目标上线前卡这个指标而不只是一个平均值。对生成任务ROUGE分数只能当参考。摘要写得和人工参考完全一样不一定是好事ROUGE高也不代表逻辑通顺。我一般会加一道规则检查摘要里必须包含工单中的关键实体比如订单号、金额不包含就重试一次或者转人工。这样能有效压制模型胡编的风险。模型幻觉是生成类任务绕不开的问题尤其在做摘要、报告时一定要做实体级校验否则一个金额写错就够你吃投诉的。5.3 成本与延迟坑失控的API账单用大模型API的日子最怕的项目之一就是重试逻辑写得不对。一次超时就重试重试再超时再重试账单会指数增长。我的建议重试最多两次而且第一次重试前必须加短暂的退避时间相同内容在短时间内失败走降级逻辑而不是继续烧钱。这句话值不少钱都是真金白银买来的教训。延迟方面不要指望模型API永远快。设计接口时就要给上游调用方留好超时和降级点。一个经验值大模型接口的P99延迟常常是平均延迟的三到五倍如果平均800ms那P99可能要3秒。服务化时一定要按P99设计超时时间否则用户就会周期性看到加载中。我习惯在网关层配一个兜底超时超过5秒直接返回正在处理请稍后查询避免调用方无限等待。5.4 问题速查表把上面这些整理成一张速查表你可以打印出来贴在工位上。症状可能原因排查步骤离线准线上崩数据分布不一致对比训练集和线上真实数据输出不合法JSON提示词约束不够加response_format和try/except接口很慢模型推理慢或网络延迟测P99、开缓存、上batch费用暴涨重试逻辑过重收紧重试次数和超时模型突然变笨Prompt或模型被改动翻实验记录回退版本这五类问题基本覆盖了我接手的多数从零项目第一周会撞上的坑。当然还有更多细节比如GPU显存不够、Docker镜像太大、日志把敏感信息打出来了这些属于具体场景里才会碰到的问题以后遇到再单独说。6. 从零开始的行动路线别等到准备好了再动手最后给一份我经常对新人说的行动路线。不是标准答案但至少能让你少走一点弯路。6.1 第一个月只做一件事跑通最小闭环第一个月不要碰Agent不要碰微调甚至不用学Docker。就做一件事把一个你手边最简单的任务用大模型API跑通。可以是文章摘要、邮件分类、闲聊机器人什么都行。要求是有一个输入界面哪怕命令行一个模型调用一个清晰的结果输出。在这个过程中你会自然接触到API调用、JSON解析、异常处理、环境变量。这些才是AI工程的地基。第二个月开始做服务化。把上个月的脚本用FastAPI包起来加Docker本地跑起来之后试着用POST请求调用它。你会发现这个月踩的坑比第一个月多得多比如跨域、端口占用、镜像拉不下来、依赖冲突。这些坑很烦人但每一个都在帮你理解线上环境不是Notebook。6.2 前期别碰的深水区有几个领域我建议前期别碰不是因为它们没用而是因为它们会严重分散你的注意力大规模分布式训练你不是在训练千亿参数模型一台单卡机器足够学到90%的工程经验复杂的K8s集群单机Docker熟练之后再考虑编排不然你连Service和Pod的关系都搞不清自己实现一个推理引擎用现成的vLLM、Triton省下时间去做业务价值更高的事。我的体会是AI工程的学习路径不是由难到易而是由小到大先在小系统里把每个坑踩一遍再在大系统里理解每个设计为什么存在。如果你一上来就照着大厂的架构图搭一套微服务GPU集群向量数据库大概率会在部署第一天就崩溃而且你根本不知道是哪里出了问题。反过来你从一个几KB的FastAPI服务开始每一步都是可控的出了问题也知道是在哪一行代码里崩的。这种掌控感才是从零开始阶段最值钱的东西。我自己是从传统后端转来做AI工程的刚开始也走了不少弯路收藏了一堆框架、读了很多论文真正让自己成长最快的反而是那个深夜把一个文本分类模型老老实实部署上线、被用户骂醒之后重新打磨的46个小时。所以我特别想对还在门口徘徊的人说一句不用等自己准备好了再动手。找一个你手边最小的业务问题走通数据、模型、部署、评测这一圈你已经超过了很多只会跑Notebook的人。哪怕第一版丑也没关系后续再慢慢补性能、补版本控制、补Agent能力。AI工程这个领域是典型的做了才会的技能看再多经验帖都不如自己把一个接口打到线上。