★ FEATURED ARTICLE 这张名为ai-engineering-from-scratch的学习清单我在本地仓库里放了大半年一路从只会调 API 的初级玩家走到能独立设计 RAG 问答系统、搭建多 Agent 协作工作流、把模型真正推到线上服务的状态。如果你也准备从零开始踏入 AI 工程这个方向这篇内容就是把我踩过的路、绕过的弯、以及最终沉淀下来的可行路线完完整整地摊开给你看。它适合谁适合有基础编程经验、但对大模型应用开发和工程落地还停留在概念层面的人也适合那些已经在用各类 AI 工具、却始终觉得“差点工程味”的开发者和产品同学。读完你至少能省下两到三个月的自我摸索时间。先说一句实话AI 工程和外面对 AI 的浪漫想象很不一样。它不要求你从零复现一个 Transformer也不是天天聊“消灭失业”。它更像是把模型、数据、接口、评测、部署这一堆零件拧成一个可靠系统的组装过程。这篇文章里没有太多数学推导更多是实战打法和避坑记录我会按照从基本功到应用层、再到部署运维的顺序把整个知识体系拆开来讲。1. 先弄清楚ai-engineering 到底在解决什么问题很多人对 AI 工程的第一印象是“做人工智能”听起来很高大上。但真正进入这个领域你会发现AI 工程的核心任务不是发明新算法而是把现有模型能力变成稳定、可靠、可维护的产品功能。这个定位搞清楚之后整个学习方向才不会跑偏。1.1 搞 AI 工程不等于搞算法研究算法研究的目标是探索模型能力的边界比如发论文、做实验、验证新的网络结构而 AI 工程的目标是交付一个能扛住真实流量、出问题能排查、换数据能迭代的系统。两者一个偏向科学探索一个偏向工程建造技能树重叠但分叉明显。我见过不少新手一上来就啃 Transformer 论文、复现 Diffusion 模型结果折腾两个月连一个能跑的对话接口都没写出来。方向反了工程岗位更需要的是“知道模型擅长什么、不擅长什么然后设计一套流程让它稳定发挥”。用生活类比就是你去餐厅吃饭关心的是菜能不能稳定好吃、上菜快不快、就算换了个厨师味道也不跑偏而不是要求你自己会种菜养猪。那么工程人员需要理解到什么程度的原理我的标准是知道 token 是什么、注意力机制解决什么问题、temperature 影响什么、上下文窗口有什么限制就足够了。剩下的精力应该花在数据、接口、评测、部署这四个工程热点上。1.2 AI 工程师的能力模型拆解如果把 AI 工程岗位的能力要求画成一张地图大致有四层基础层Python、数据结构、SQL、Git、Linux 命令行。这是所有上层建筑的底座。模型层机器学习核心概念、深度学习基础、大模型 API 调用与微调、模型评估。工程层服务接口设计、容器化部署、监控告警、CI/CD、成本与性能优化。应用层Prompt 工程、RAG 检索增强、Agent 智能体设计、AI 工作流编排。四层不是串行执行的而是互相交织。比如你设计 Agent 时既要懂 Prompt 技巧也要懂接口超时怎么处理你部署模型时既要会配 Docker也要理解模型推理的 batch 机制。这种“全栈感”恰恰是 AI 工程和传统后端开发最大的差异也是它吸引人的地方。拿我自己举例早期我只盯着模型层觉得会调 API 就够了结果一上生产环境就露馅并发一高就超时、上下文一长成本失控、模型输出格式稍微一变前端就崩。后来把工程层补上再回头看那些问题其实都是可预判、可设计的。所以这套能力模型值得你每隔半年对照自查一次。2. 从零起步先跑通一条最小可用的技术栈学习 AI 工程最忌讳的就是“收藏一大堆教程然后一个都没跑通”。我的建议是别管那么多先用一条最基础的技术栈把 end-to-end 的小项目跑起来之后再逐步扩展。这里说的技术栈包括 Python 数据处理工具、机器学习基础框架、深度学习模型库以及最常用的大模型开发组件。2.1 编程与数据处理地基怎么打Python 是 AI 工程的通用语言这是绕不过去的。但你不必先精通所有语法再去碰 AI掌握列表推导、字典操作、函数定义、异常处理、类的基本用法就够起步了。真正要花力气的是数据处理三件套numpy、pandas、matplotlib。我推荐用一个经典数据集练手Titanic 生存预测。这个数据集不涉及敏感内容又足够真实适合练完整个数据处理流程。实操步骤大致是加载数据、查看缺失值、做特征工程、用 matplotlib 画几组分布图、最后训练一个最基础的逻辑回归模型。import pandas as pd from sklearn.model_selection import train_test_split from sklearn.linear_model import LogisticRegression df pd.read_csv(titanic.csv) df df[[Survived, Pclass, Sex, Age, Fare]].copy() df[Sex] df[Sex].map({male: 0, female: 1}) df[Age] df[Age].fillna(df[Age].median()) X_train, X_test, y_train, y_test train_test_split( df.drop(Survived, axis1), df[Survived], test_size0.2, random_state42 ) model LogisticRegression(max_iter500) model.fit(X_train, y_train) print(准确率:, model.score(X_test, y_test))这段代码的意义不在于准确率有多高而是让你完整感受一次“加载-清洗-训练-评估”的循环。这个循环就是 AI 工程里最高频的动作抽象后面所有花哨的应用都建立在这个基本循环之上。另外SQL 和 Git 一定要尽早补上。SQL 是因为真实业务数据大多存在数据库里你不可能总拿到 CSVGit 是因为任何一个靠谱的 AI 项目都需要版本管理尤其是 Prompt 和模型配置的版本管理后面迭代的时候你就知道多重要了。2.2 机器学习与深度学习核心概念怎么补机器学习这一层不需要啃完整个西瓜书才动手。我建议按三条主线去补模型是怎么学习的损失函数、梯度下降、模型为什么会犯错过拟合、偏差方差、怎么判断模型好不好准确率、召回率、F1、混淆矩阵。每一条主线都配一个 sklearn 的小实验比如用逻辑回归分类鸢尾花、用随机森林预测房价。深度学习部分重点理解神经网络的基本组成层、激活函数、损失函数、优化器、反向传播。你不需要手动推导 BP 公式但至少要知道“前向传播算出结果、反向传播更新参数”这个过程。然后用 PyTorch 写一个最简单的全连接网络在 MNIST 上跑一遍手写数字识别。import torch import torch.nn as nn import torch.optim as optim class SimpleNet(nn.Module): def __init__(self): super().__init__() self.fc nn.Sequential( nn.Flatten(), nn.Linear(28 * 28, 128), nn.ReLU(), nn.Linear(128, 10), ) def forward(self, x): return self.fc(x) model SimpleNet() optimizer optim.Adam(model.parameters(), lr1e-3) loss_fn nn.CrossEntropyLoss()这段代码会训练你的“深度学习体感”loss 怎么下降、batch size 怎么影响收敛、学习率设太大会发生什么。这些体感比背十个公式都管用。从深度学习切到大语言模型你只需要补三个概念token 是模型处理文本的最小单位上下文窗口是模型能“记住”的最大长度temperature 控制输出随机性。理解了这三个再配合 OpenAI、Claude、DeepSeek 这类 API你已经可以开始做一些像样的应用了。3. 应用层三大核心Prompt、RAG 与 Agent如果说基础层是内功那应用层就是招式。2024 年之后的大模型应用开发基本绕不开 Prompt 工程、RAG 和 Agent 这三件事。它们互相独立又可以组合是 AI 工程师日常工作台的核心工具。3.1 Prompt Engineering从“玄学”到可工程化很多人刚接触 Prompt 时觉得这是“玄学”同一个问题换个问法输出就天差地别。但实践久了你会发现Prompt 是有结构、有方法、可评测的。核心原则可以概括成四个字说清楚事。具体来说一个好 Prompt 通常包含四个要素角色设定、任务描述、输出格式、边界约束。举个例子你要做一个客服问答你是一个电商平台的售后客服助手。请根据用户的问题给出简洁、友好的回答。回答不超过三句话。如果你不知道答案请回复“这个问题我需要转给人工客服请稍等”。用户问题我的快递显示签收但没收到货怎么办对比一下差的 Prompt“帮我回答用户问题”。效果天差地别。好 Prompt 的本质是把模型当新入职的员工你把岗位职责、工作流程、禁止事项交代清楚它才能稳定干活。更难一点的技巧包括 few-shot 示例、思维链诱导、结构化输出要求 JSON。这些都不复杂但真正让 Prompt 从“写得不错”升级到“工业可用”的是评测。我强烈建议你给每个重要 Prompt 配 20 条测试用例隔一段时间跑一遍记录输出质量的变化。模型版本一升级你的 Prompt 可能就失效了没有评测集根本发现不了。3.2 RAG让模型学会“查资料”RAGRetrieval-Augmented Generation检索增强生成是目前解决模型幻觉和知识过时最实用的方案。原理很简单模型不知道你的私有数据那就先从你的文档里检索出相关内容塞进上下文再让模型基于这些内容回答。我记得之前做内部知识库问答系统核心流程就五步加载文档、切分块、向量化、存储到向量数据库、检索时组合上下文。用 LangChain 能很快搭起来from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import OpenAIEmbeddings from langchain_community.vectorstores import Chroma loader PyPDFLoader(company_handbook.pdf) docs loader.load() splitter RecursiveCharacterTextSplitter(chunk_size512, chunk_overlap64) chunks splitter.split_documents(docs) vectorstore Chroma.from_documents(chunks, OpenAIEmbeddings()) retriever vectorstore.as_retriever(search_kwargs{k: 4})这一段代码看起来简单但里面藏着大量工程细节。chunk_size 选多大我实测下来 256 到 512 个 token 之间效果比较均衡太小了上下文碎片化太大了检索不精准还浪费 token。chunk_overlap 留一点重叠避免切在语义中间导致关键信息丢失。检索返回多少块k4 是常见起点具体要看文档长度和 prompt 长度预算。RAG 的难点不在搭流程而在调优。检索准不准直接决定回答质量。如果召回的内容驴唇不对马嘴模型再强也救不回来。所以后续我还加了 Rerank 模型把检索出来的候选块重新排序。这个投入回报比很高强烈推荐在知识库场景里加上。3.3 从单轮对话到 Agent让模型用工具Agent 是当前 AI 工程最热的方向之一核心思想是让模型“动起来”不只回答问题而是自己决定调用什么工具、按什么顺序操作最终完成一个任务。打个比方RAG 是给模型一本参考书Agent 是给模型一双手。实现思路通常遵循 ReAct 模式Reason思考→ Act行动→ Observe观察结果→ 再思考。比如用户说“帮我查一下明天北京天气并设置一个提醒”模型会拆解成两步先调用天气查询工具拿到结果后再调用日历写入工具。这个过程中模型是在“推理下一步该干嘛”而不是一次性输出答案。def get_weather(city: str, date: str) - str: # 调用气象服务 API返回天气信息 return f{city} {date}: 晴23-31℃ def add_calendar(event: str, time: str) - str: # 写入日历 return f已添加日程{event} 时间{time} # Agent 框架会根据用户请求自动选择调用以上函数实际开发中我不建议自己从零写 Agent 框架。成熟的方案很多LangGraph 适合有向无环图和复杂状态管理CrewAI 适合模拟多角色协作比如一个研究员 Agent 负责查资料一个写作 Agent 负责出稿AutoGen 适合多智能体对话式协作。选型标准就一条你的任务是否真的需要多步骤决策。多 AI 协作也是热搜里反复出现的关键词。多个 Agent 之间怎么分配任务、怎么传递结果、怎么避免互相干扰比单个 Agent 的实现更考验工程能力。我的经验是协作越复杂越需要一个清晰的“主编”Agent 来汇总和裁决否则子 Agent 各自为政最终产出会非常散。4. 工程化落地部署、评测与 AI 工作流很多教程讲完 Prompt 和 RAG 就结束了但真正的考验才刚开始怎么把原型变成别人能用的服务怎么保证上线后不出幺蛾子怎么控制成本这一章我重点聊部署和评测这两块是 AI 工程区别于“AI 玩具”的分水岭。4.1 模型服务化把 Prompt 变成一个接口不管你是调用第三方大模型 API 还是自建模型服务对外暴露的都应该是一个统一、稳定的 HTTP 接口。这样上层业务不关心你底层用的是什么模型哪天你从 GPT 换成 DeepSeek只要接口协议不变调用方不用改代码。我用 FastAPI 写过很多次这种封装最小结构大概是from fastapi import FastAPI from pydantic import BaseModel from openai import OpenAI app FastAPI() client OpenAI() class ChatRequest(BaseModel): message: str session_id: str default class ChatResponse(BaseModel): reply: str usage: int app.post(/chat, response_modelChatResponse) def chat(req: ChatRequest): resp client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: req.message}], max_tokens512, temperature0.7, ) return ChatResponse( replyresp.choices[0].message.content, usageresp.usage.total_tokens, )接口写出来只是第一步生产环境要处理的问题多得多超时重试策略模型服务偶尔会慢不能一超时就报错、流式输出长回答必须流式返回否则用户等到崩溃、并发限制API 有 rate limit要做排队或限流、内容安全过滤输入输出两侧都要有检测。成本控制也是工程落地里最常被忽视的。大模型 API 按 token 计费聊天历史越长每轮调用越贵。一个很有效的技巧是 token 预算管理给每个会话设置最大上下文长度超出后自动截断或摘要压缩。我在生产环境里这么做过之后账单直接降了三分之一。4.2 评测是 AI 工程最重要的隐藏环节说句得罪人的话很多团队做的 AI Demo 不是“能做”而是“碰巧能做”。换一组测试数据就翻车这不是模型不行是评测缺失。传统软件有明确的单元测试AI 应用却因为输出不固定评测一直被轻视。但恰恰是评测决定了系统能不能长期迭代。我的做法是给每个 AI 功能维护一个“黄金数据集”比如 50 个用户真实问题配上标准答案每次改动 Prompt、换模型、调参数都跑一遍这 50 个用例然后量化打分。打分方式有两大类一类是传统的准确率、召回率、BLEU另一类是更实用的 LLM-as-Judge让另一个大模型当裁判给回答质量打等级。评测用例 37 用户问题退款多久到账 标准答案1-3 个工作日原路退回。 模型输出退款申请通过后资金会在 1 到 3 个工作日内退回到原支付账户。 裁判判定通过。信息一致表述更详细。这个流程听起来笨重但它是唯一能让 AI 项目“越改越好”的保障。没有评测集你改一个 Prompt效果是变好还是变坏全靠体感那和掷骰子没什么区别。4.3 AI 工作流从单次调用到可维护流水线AI 工作流这个概念最近非常火它的本质是把多个 AI 调用、条件判断、数据处理步骤编排成一条流水线。比如一个内容总结工作流输入一篇长文先抽取核心段落然后生成摘要再提取行动项最后通过邮件发送结果。每一步都用 AI但每一步的输出都经过校验整个过程的稳定性会远高于一个“万能 Prompt”。工程上常用的编排工具有 LangChain、LangGraph后者对有状态的复杂流程支持更好。LangGraph 的核心概念是 Node处理节点和 Edge流转边每个节点处理一段独立逻辑节点之间可以设置条件和状态。这种设计的好处是单步可调试、可重试、可替换。哪一步出问题了看日志就能定位不像单体 Prompt 出了问题只能瞎猜。多 AI 协作场景里工作流编排尤其重要。比如市场调研任务可能包含搜集资料、汇总提炼、生成报告三个环节每个环节可以用一个专门的 Agent 负责再由主控 Agent 统筹。实际操作时你需要在关键节点设置人工确认开关避免全自动流程在异常情况下越跑越偏。记住一个原则全自动不一定好人在环路的系统往往既稳定又可控。5. 一次完整的 AI 工程实战复盘私有知识库问答系统前面讲了这么多概念还是落地的例子最有说服力。我挑一个自己完整做过、且非常适合作为里程碑练习的项目来讲公司内部文档知识库问答系统。它涵盖了数据清洗、向量检索、Prompt 设计、评测、部署的完整闭环做完之后你对整个 AI 工程链路会有实打实的体感。5.1 项目选题与架构设计很多新手练习项目喜欢跟风做一个“全能聊天机器人”但需求太宽泛做完不知道好还是坏。知识库问答则是一个边界清晰、效果可测的方向给定一批内部文档用户提问系统返回有依据的回答。我当时处理的语料是几十份产品说明文档和售后政策文档大概几百页 PDF。架构上我没有搞得很复杂核心模块就三个离线索引、在线检索、对话生成。离线索引负责把 PDF 切块、向量化、存入 Chroma在线检索负责把用户问题向量化、查库、拿到 Top-K 文本块对话生成负责把检索结果和用户问题组合成 Prompt 交给大模型。系统里还加了一个引用溯源模块每个回答附上来自哪份文档、哪个章节方便用户核实。这种架构的好处是模块之间解耦你要换向量库可以只改一个模块你要换大模型可以只改对话生成模块你要调 Prompt 也不影响检索逻辑。对一个持续迭代的项目来说解耦就是一切。5.2 开发过程从数据到 Prompt 到评测开发过程里最脏最累的环节永远是数据。PDF 文件格式五花八门有扫描件、有表格、有图文混排直接塞给切分器会产生大量垃圾块。我当时花了整整两天做清洗把扫描件 OCR 转文字、去掉页眉页脚、修正表格顺序、合并重复段落。这一步骤没法偷懒数据质量直接决定检索质量。切分参数我经过几轮实验才定下来chunk_size384、chunk_overlap48。为什么是 384我大概测了 [128, 256, 384, 512, 768] 几档太小则上下文不完整太大则检索命中率下降384 在测试集上 F1 最高。这个数字没有普适性但测试方法你可以直接复用。Prompt 方面我的模板固定为三段式系统提示你是公司文档助手只基于给定文档回答、上下文块检索到的内容用 XML 标签包裹防止注入、用户问题明确要求回答中标注引用来源。此外还加了一个兜底语“如果文档中没有对应信息请明确回答不知道不要编造。”实测这个兜底语能把幻觉比例从十几个百分点压到接近零。评测是我的重点投入。我找业务方要了 60 个高频用户问题人工写了标准答案然后分三个维度打分准确性信息对不对、完整性关键点有没有漏、格式友好度回答是否方便阅读。每次改 Prompt 或调检索参数就跑一遍这 60 题记录分数变化。5.3 上线后的观察与迭代系统上线后我做的第一件事不是庆祝而是把所有线上问答记录存日志。日志字段包括用户问题、检索到的文档块 ID、模型原始输出、用户是否点了“有帮助”。这些日志是我后续迭代的金矿每两周分析一次找出回答质量差的高频案例然后针对性调整。迭代中我发现一个很有意思的现象用户实际提问方式和测试集差别很大。测试集里问“退款几天到账”真实用户会问“钱什么时候回来啊”“我那个退款咋还没到”表达更口语化、更模糊。于是我又加了一个“问题改写”环节先用一个小模型把口语化问题转成规范的检索关键词再去做向量查询。加了这一层之后检索命中率提升非常明显。成本方面上线首月我统计下来embedding 费用占比很小大头全在生成 token 上。于是我做了两项优化一是把对话历史压缩成摘要而不是逐轮完整带入二是对低风险问题用更小的模型对复杂问题才调大模型。这两招单月成本下降了四成回答质量基本没受影响。6. 新手学习路径避坑指南最后聊点务实的学 AI 工程这一路哪些坑几乎人人都踩以及如果重新来过我会怎么安排学习节奏。把这些经验打包成清单送给你希望能让你少走几段冤枉路。6.1 最容易翻车的六件事第一件上来就啃论文。AI 论文是给研究导向的人看的工程导向的人看半天注意力机制不如动手调一次 API 收获大。真想补理论找几篇经典综述读懂大方向就够了。第二件只调 API 不做底层理解。依赖某种固定的模型 API 本身没毛病但你要理解它背后的能力边界和失效模式。否则模型一换版本你的整个应用就跟着崩。第三件不建评测集就开干。没有评测集等于闭着眼睛改代码我今天给你十条优化建议你都分不清哪条真有用。第四件不设成本预算。大模型 API 真的能烧钱尤其在上生产之后。上线之前先算清楚单次调用成本、预估并发量、每月上限。第五件忽视数据隐私。把公司内部文档直接丢给外部模型 API这件事在很多行业是合规问题。轻则数据泄露重则吃官司。动手前先确认数据安全边界。第六件一上来就学各种复杂框架。LangChain、LangGraph、CrewAI 都是工具不是知识体系。未必要憋到精通全部门才开始写代码但也不要因为框架流行就盲学。6.2 给零基础的学习节奏建议如果每周能投入十到十五个小时我给出一条 24 周的路线参考第 1~4 周Python 语法 pandas SQL Git做一遍 Titanic 或类似的数据分析小项目。第 5~8 周机器学习基础sklearn 上手重点理解损失函数、过拟合、评估指标。第 9~12 周深度学习基础PyTorch 写图像分类或文本分类跑通一个端到端训练流程。第 13~16 周大模型应用入门学会调用 API系统练习 Prompt 设计建一个自己的评测集。第 17~20 周实现一个 RAG 系统从文档加载到向量检索到生成回答完整跑通。第 21~24 周把 RAG 系统部署成线上服务加上日志监控和成本控制写一份复盘文档。这套路线里每个阶段结束都要有一个拿得出手的产出物而不是“看完了视频”。比如第四周结束你手上应该有一份分析报告第十二周结束应该有一个能跑的训练脚本第二十周结束应该有一个能回答问题的知识库 Demo。产出物才是你找工作的底气也是你回顾成长的最好坐标。我个人带过不少新人也见过很多自学翻车的案例。一个很普遍的误区是把时间平均分配给所有知识点。实际上AI 工程里真正拉开差距的从来不是会多少模型而是三个能力调试能力出了问题能定位到哪一步、评测能力知道改没改好、工程落地能力能把原型变成产品。这三项值得你花大块时间去刻意练习。最后再分享一个我自己的小习惯每周写一份“踩坑记录”不用长三百字就够记下这周遇到的问题和解决思路。三个月后再翻你会看到明显的成长曲线。AI 这个领域变化极快但基本功和解决问题的思路是长期有效的把根扎稳后面的路自然会越走越宽。
阅读完成 · 觉得有帮助？
 线程安全设计)
