我做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工程可以分成四块：数据工程、模型工程、推理部署工程、评测观测工程。下面这张对照表，把每一块的核心任务和常见工具体现出来，也方便你对照着检查自己的短板。

这四块不是按时间顺序执行的，而是滚动迭代的。你从最小可用的数据管线开始，做一版模型，部署上线，然后在观测中发现数据问题，再回来改数据。走通一轮之后，才算真正入门。我强调一点：大多数教程只教第二块，也就是"模型工程"，甚至只教到"调用模型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_key=os.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} ], temperature=0.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工程项目最大的隐性成本是"想不起来当时为什么这么做"。举一个例子：

这样的记录看起来简陋，但关键时刻能救命。线上效果回退了，翻这张表就知道哪个开关该回滚。

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 问题速查表

把上面这些整理成一张速查表，你可以打印出来贴在工位上。

这五类问题，基本覆盖了我接手的多数从零项目第一周会撞上的坑。当然还有更多细节，比如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工程这个领域，是典型的"做了才会"的技能，看再多经验帖，都不如自己把一个接口打到线上。