别人问我做 AI 工程到底从哪起步我从来不会直接甩一份课程清单。因为我自己就是从零硬啃过来的太清楚这条路最大的陷阱是什么——不是学不会而是不知道先学什么、学到什么程度算够、学和用之间那条沟怎么迈过去。项目标题叫“ai-engineering-from-scratch”本质上就是在问一件事一个没有深厚算法背景的人能不能靠自己在真实业务里把 AI 用起来、把系统搭起来、把问题扛下来。我的答案是能但路径跟你搜到的那些“三天精通大模型”的爽文完全不一样。这篇文章就是我基于自己踩坑经历整理出的完整路线从基础补课到真实落地每一步都告诉你为什么这么做、卡住了怎么办。先说清楚这篇文章适合谁你可能是写了好几年业务代码想转 AI 方向的工程师也可能是刚毕业想做算法但又怕数学拖后腿的新人甚至是你已经在用现成 API 做小工具、但一遇到效果不好就不知道怎么调的项目负责人。不管哪种只要你愿意从原理层往下钻一层而不是永远停在“调包”层面这篇文章就是给你写的。1. 项目到底在做什么从“会用 AI”到“会做 AI 工程”1.1 “从零开始”的真实含义我得先纠正一个普遍误解很多人以为 ai-engineering-from-scratch 是从头写一个神经网络、自己实现反向传播那叫学术研究不叫工程。真正的 AI 工程是把 AI 能力变成稳定、可维护、可评估、可上线的系统。从零开始的“零”指的不是零基础开始写代码而是从“你手头只有一个业务问题、没有现成 AI 方案”的状态开始。举个例子老板说“帮我把用户反馈自动分类”这不是让你训练个新模型而是让你从数据收集、模型选型、效果评估、接口封装到监控上线全链路走一遍。这套能力跟会不会手推 Transformer 公式完全是两码事。我见过太多人栽在同一个坑里花三个月补数学、读论文结果一上手真实数据就懵了——数据脏、标注不一致、模型在测试集上挺好一上线就崩。这就是典型的“学了一堆知识没练过工程”。所以这篇文章里我默认你的起点是“会写 Python、懂基本的数据结构”但不需要你会证明收敛性也不需要你能背出注意力机制的矩阵推导。1.2 一条主线贯穿始终整个路线我只抓一条主线用最小成本跑通一个端到端的 AI 项目再在反复迭代中补齐所有能力。这条线的逻辑很简单——AI 工程的知识点太散了模型训练是一块、数据处理是一块、服务部署是一块、效果评估又是一块你单学任何一块都会觉得“我学了干嘛用的”。但如果你心里揣着一个具体项目比如“我要做一个文档问答机器人”那所有知识点都有了落点数据清理是为了让模型读得懂你的文档向量检索是为了快速找到相关片段 Prompt 调优是为了让回答贴合你的业务评估脚本是为了知道改动到底是变好了还是变坏了。我当年入门时的第一个完整项目就是给团队内部做了一个技术文档问答工具。从现在的眼光看它简陋得要命——就是 embedding 加向量库套一个开源模型——但那个项目教会我的东西比之后一年读的论文都多。这也是为什么我强烈建议你不要从“学”开始要从“做一个东西”开始。目标不明确的时候你连学什么都判断不了。2. 环境与工具链开工前必须备齐的家当2.1 硬件和环境的现实选择聊工具链之前先解决一个最劝退的问题要不要买显卡我的经验是——先别买先用云 GPU 或者直接用 API。原因很简单你在入门阶段最大的瓶颈不是算力是对整个流程的理解。等你真开始训练小模型、跑微调了再考虑本地硬件也不迟。我见过太多人花一万多买了显卡回来结果半年里每天跑的是教程里的 MNIST利用率不足 5%。我自己常用的组合是这样日常写代码用自己的笔记本需要跑训练的时候租云 GPU 按小时计费调 API 做实验直接用现成的模型服务。这套组合的好处是灵活你随时可以停不用为闲置硬件心疼电费和折旧。等到你确认自己确实要长期做模型训练了再按需求配机器那时候你已经知道自己要什么了。环境这块我强烈建议一开始就养成用虚拟环境的习惯。Python 的依赖版本问题在 AI 项目里会被放大十倍——昨天还能跑的代码今天装了个新包就崩了这几乎是我们所有人的日常。用 conda 或 venv 把每个项目的依赖隔离好这个习惯越早养成后面越少遭罪。2.2 核心工具清单和选型逻辑工具选型没有标准答案但我可以给你一份“怎么选都不至于错”的基础组合用途推荐工具不用它用谁选型理由交互式实验Jupyter Notebook / VS Code纯脚本文件跑一步看一步排查数据问题靠它最直观数据处理pandas / Polars手写循环向量化操作快语法贴近直觉深度学习框架PyTorchTensorFlow生态最活跃调试体验好社区答案多版本管理Git DVC可选只存代码不存数据模型和数据也要版本化否则复现就是扯淡模型服务FastAPIFlask自带类型校验和文档异步支持好适合做推理接口你可能发现我没把 LangChain 这类框架放进“必备”清单。不是它不好而是我建议你先用裸代码跑通再上框架——这样你才能明白框架到底帮你省了什么。一上来就套框架遇到问题你会完全不知道从哪排查那感觉就像看别人用魔法自己拿到魔杖却念不出咒语。安装这块还有个具体建议把 PyTorch、Transformers 这类重量级依赖装到一个专门的环境里别跟其他项目混。我因为混装依赖导致环境崩掉、重装了一整天环境的经历说出来都是泪。现在我的规矩很简单——每个项目独立环境装完包立刻记录版本号这样不管过多久回头都能精确复现当时的运行条件。3. 核心基础拆解真正要补的知识点只有四块3.1 数据能力AI 工程的立身之本AI 工程里最被低估的技能是数据处理。很多转行过来的人把注意力全放在模型上结果一接真实需求就发现80% 的时间花在了清洗、标注、格式转换上。你需要掌握的核心操作包括处理缺失值、去重、文本清洗、标签分布检查、训练集和验证集的划分逻辑。这听起来像数据分析师的活但 AI 工程里的数据处理有自己的特殊性——你得时刻想着这份数据喂给模型之后会怎么样。比如标签分布如果不均衡模型大概率会把多数类学得特别好、少数类直接忽略再比如训练集和验证集如果划分不当数据泄漏会让你的评估结果虚高得离谱。我自己的习惯是每个项目先花一整天“盘数据”看字段、看分布、画几张图、跑几个统计量完全不碰模型。这个过程看似低效但几乎每次都能发现几个后面会炸雷的问题——有空值混进了数字列、时区没对齐导致时间特征错乱、用户 ID 在不同表里格式不一致等等。数据上的问题发现得越早修起来越便宜这是所有 AI 工程里最划算的投入。额外说一句关于标注的体会小规模项目里自己标几百条数据然后认真做一遍一致性检查比花钱找人标几千条然后完全不质检靠谱得多。你要的不是“量”是“标签到底准不准”因为模型学的是你给它的答案而不是你以为的正确答案。3.2 机器学习的“够用”底线我知道很多人一听说学机器学习就头大觉得那是数学天才的领地。实际做工程真的不需要你懂所有公式但有几件事必须搞清楚。第一个是模型评估。精确率、召回率、F1、AUC这几个指标每个都必须能用自己的话说清楚。因为 AI 项目的所有决策——换模型、调参数、改 Prompt——都需要通过指标来判断有没有变好说不清楚指标你就是在凭感觉做工程。第二个是过拟合与欠拟合。这俩概念看似基础但我见过太多工程事故的根源就是它俩。模型在训练集上表现完美、一到新数据就崩这是过拟合训练集和验证集都一塌糊涂这是欠拟合。你要能根据训练曲线判断出当前模型处在哪个状态才能知道下一步该加数据、加正则还是换模型。第三个是常见模型类型的选择逻辑。分类、回归、聚类、序列建模每种任务适合什么模型、大概什么复杂度你得有个谱系图在脑子里。不是让你背模型动物园而是让你遇到问题时知道往哪个方向找答案。我见过一个特别典型的问题一个做 NLP 的朋友把 BERT 用在了一个只有两千条样本的小分类任务上结果效果不如简单的 TF-IDF 加逻辑回归还慢得要命。这就是对模型适用场景没概念——不是越复杂的模型越好是合适才好。3.3 Prompt 工程新时代的“接口调用”大模型时代Prompt 工程成了 AI 工程里躲不掉的一环。但我要泼一盆冷水网上那些“60 条 Prompt 咒语”大部分是玄学真正有用的 Prompt 工程是有方法论的。核心就三件事把任务描述清楚、给出期望的输出格式、提供少量示例。描述不清楚模型就只能猜输出格式不限定你后续解析就全是事没有示例模型面对一些边界情况就会自由发挥。这三个基础点做好效果就能超过 80% 的“咒语党”。我自己的经验是写 Prompt 要像写需求文档一样——场景、输入、输出、约束条件、失败兜底逐条写清楚。比如你让模型从用户评论里提取商品名不能只写“提取商品名”要写清楚“如果一句话里出现多个商品名全部输出如果没有商品名输出‘无’”。这些边界说明才是 Prompt 工程真正的价值所在。另外一定要养成版本管理的习惯。Prompt 的改动在效果上的变化经常是隐性的不记录版本你根本不知道是哪一个改动让效果变好了。我通常会把 Prompt 存成文本文件放进 Git备注里写清楚改动意图这样回溯的时候清清楚楚。3.4 模型部署与服务化从 Notebook 到生产环境Notebook 里跑的代码和线上服务的代码中间隔着一条巨大的河。工程化的核心差异在于Notebook 里你追求的是探索效率生产环境追求的是稳定、可控、可观测。你得掌握的基础技能包括把模型封装成标准接口、处理并发请求、模型加载与推理的分离、请求日志与错误追踪。这里面最容易出问题的是推理服务的内存管理——大模型加载到显存里之后每来一个请求都得让它跟模型做交互并发高了直接爆显存所以你得会控制批次大小、限制最大并发数、设置超时和重试策略。FastAPI 是我推荐的首选框架因为它自带 OpenAPI 文档你写完接口马上能在浏览器里调试而且它的异步支持很成熟处理并发推理体验比 Flask 好太多。部署方式我建议从小做到大先在本地起服务做联调再扔到 Docker 里跑最后才上容器编排平台。每一步加一层复杂度出问题了也能精准定位是代码问题还是环境问题。还有一点很关键模型更新和上线要分开。生产环境里经常有“旧模型还活着、新模型正在训练”的状态你得让服务架构支持模型的热切换而不能每次更新模型都重启整个服务。这个细节做不好你就会被老板问“怎么又停机了”问到怀疑人生。4. 实操路线图从零跑通第一个端到端项目4.1 项目选题别贪大选一个能两周内跑通的路线图再漂亮不动手都是白搭。我先给你定一个具体的起步项目做一个“文档问答机器人”输入一堆文本资料用户提问后返回基于这些资料的答案。这个项目几乎是完美的起点。第一它同时覆盖了文本处理、向量化、检索、大模型调用四条主线第二它的每一部分都有现成的轮子可以用你不用从零造第三它的效果一眼就能看出好坏非常适合用来建立“改进了什么、效果怎么变”的工程直觉。实现思路用大白话说就是这样你有一堆文档先把它切成长度合适的片段把每个片段用 embedding 模型转成向量存进向量数据库。用户提问时把问题也转成向量在库里找最相似的几个片段然后把“用户问题 找到的片段”一起丢给大模型让它基于这些材料生成回答。这就是目前主流 RAG 架构的最小可行实现。为什么选这条路线而不去微调一个模型原因是——检索比硬记更可控。文档更新了你只需要重新切分和索引不需要重新训练模型系统答错了你还能查出来是“没找到资料”还是“找到了但没用好”问题可定位。这种可解释性对刚上手的你来说是无价的。4.2 第一周任务拆解数据、向量化和检索第一周只做四件事不碰大模型。第一写脚本把文档读进来做基本的清洗和切分。切分这里有个关键参数片段长度不要一刀切要按语义边界来切——比如按段落切而不是机械地按几百个字符切否则检索到的片段会“前言不搭后语”大模型拿到手也答不好。第二安装 embedding 模型把每个片段向量化。向量化之后你要做一件事把几个有代表性的片段打印出来看看语义相近的文本向量是不是真的相近。这一步不要省因为 embedding 模型也是要选的——有的模型对中文支持不好向量化出来一塌糊涂不早点发现等系统搭完再换就麻烦了。第三搭一个最简单的检索函数问题向量跟所有片段向量算相似度返回 top-k 个片段。这一步里你会第一次体会到“相似度到底意味着什么”的实感——哪些问法能检索到好资料哪些问法检索出来是牛头不对马嘴。第四写一个人工评估脚本你准备五十个问题每个问题看一眼检索回来的片段对不对记一个“检索命中率”。这个数字就是你后续优化的基准线改切分方式、换 embedding 模型都要拿它来衡量变好了还是变差了。没有这个评估脚本你后面所有的“优化”都是在裸奔。4.3 第二周任务拆解接通大模型和评估闭环第二周把剩下的链路补上。你先用任一个大模型 API 做生成层——把检索到的片段跟用户问题拼到一个 Prompt 里让模型基于片段作答然后把“知识库的答案”和“没给资料时的答案”放一起对比你会发现差距极其明显。这一步的目的是让你直观感受到检索对生成质量的决定性影响。接着做两件非常有工程味的事。第一为整个系统写一个评估集里面每一种问题类型都覆盖到——有明确答案的、需要跨片段整合的、资料里根本没有的等等。资料里没有的问题特别重要因为你要验证系统能不能在找不到答案时老实说“不知道”而不是一本正经地编。第二给系统加“引用来源”。大模型输出答案时要求它同时标注答案来自哪些片段。这个功能在真实业务里几乎是刚需——用户需要一个能对质的依据你也需要一个排查问题的抓手。实现起来不复杂只要在 Prompt 里要求模型“回答末尾标注引用编号”再把编号映射成原始文档出处就行。到这里你已经拥有了一个端到端可跑的 RAG 项目。它不完美但它足够让你建立起“数据—检索—生成—评估—调优”的完整闭环意识。之后你再去看各种高级技巧——重排序、混合检索、查询改写——都是在这个闭环上做增强不会再像看天书了。5. 常见故障排查实录这些坑我替你踩过了5.1 检索质量差先别急着换模型先看数据最常遇到的问题就是“检索结果乱七八糟”。大多数人第一反应是换个更强的新模型但我可以负责任地说——大部分时候问题出在文档切分和查询本身。排查逻辑是固定的。先看一眼原始文档是不是干净有没有大量 OCR 噪声、乱码、超长表格再检查切分逻辑是不是把一个完整语义段落拦腰截断了然后看查询内容本身——用户问得太模糊跟你的文档用语完全对不上再强的检索系统也召回不了最后才是评估 embedding 模型的匹配度。我印象最深的一次调试一个法律文档问答系统检索总是召回错误法条。查了半天发现是文档里有大量的“以下简称”表述——“本法”“本条例”“该规定”这类词在切分时被单独切出来了语义完全不完整。后来改成按章节语义块切分、切完再做一遍小标题拼接检索效果立刻上了一个台阶。所以记住数据端的问题永远排在模型端之前排查。5.2 模型回答胡编乱造把“我不知道”变成一种能力第二个高频事故是模型给出振振有词的错误答案也就是所谓的幻觉。这个问题的根子在于你让模型“自由发挥”了但它其实不知道界限在哪。我的解决方案分三层。第一层Prompt 里明确写只能根据提供的资料回答资料里没有的信息要明确说“资料中未提及”不许自行补充。第二层做一个答案校验检查生成的内容里关键实体是否真的出现在检索到的片段里如果核心名词对不上宁可让系统回答“无法确认”也不要硬给答案。第三层调低生成温度参数让输出更保守减少模型自己“发挥”的空间。不过也要做好心理准备幻觉只能被压低到这个程度永远不能完全清零。所以工程上的心态是——改善它、监测它、在它犯错时能发现它。这也是为什么我前面强调“引用来源”必须做用户和你能拿答案对比原文错误就藏不住了。5.3 服务性能扛不住先量化瓶颈再谈优化系统上线后最常见的报错就是“太慢了”“老超时”。这时候千万别拍脑袋优化——先把瓶颈量化出来。你可以在接口日志里加三段时间的埋点检索耗时、模型生成耗时、前后处理耗时。以我的经验90% 的“慢”都出在模型生成耗时上检索那部分通常只有几十毫秒。生成耗时受两个因素控制一是输出长度生成的 token 越多越慢二是输入长度你塞给模型的资料片段越多它“读”得也越久。所以优化手段很直接限制输出长度、只保留最相关的 top-k 片段而不是全部塞进去、给模型加“最多输出 300 字”这类约束。如果并发上来之后开始排队了优先做两件事给服务加缓存重复问题直接返回上次结果再上一套简单的请求队列和限流机制让服务在压力下优雅地变慢而不是直接崩溃。生产环境的底线是“可用”不是“快”。6. 进阶方向从跑通到专业你需要补哪些能力6.1 评估体系的工程化如果你跑通了项目接下来最值得投资的是把评估体系搭得像样。很多 AI 团队的悲剧是“感觉效果还行但说不清到底行在哪”这个问题会在项目规模变大后彻底爆发。工程化的评估体系包含三个层次离线指标评估、线上效果监控、用户反馈收集。离线阶段用你的测试集跑指标上线后记录真实请求的输入输出、埋点统计回答长度、响应时间、无效回答比例再往后做用户对回答点赞点踩的收集。这套体系建起来之后你做任何改动——“换个模型”“调整 Prompt”“改切分方式”——都能用数据说话而不是靠“感觉好像变好了”。这一层的意义说穿了就一句话AI 项目的不确定性太高了没有评估体系你就永远在一个“不知道改没改对”的泥潭里挣扎。相反有了明确的指标基线你每次迭代都是一个可控的实验效率完全不在一个量级。6.2 微调模型什么时候值得做什么时候别碰很多人跑通 RAG 之后下一个想法就是微调模型。我先给你一个判断标准如果你的问题是“模型不够听话”或“输出格式不对”先优化 Prompt微调解决不了这个如果你的问题是“模型回答里频繁出错的专业知识”而你的知识库已经能给足资料那问题也在检索和 Prompt 侧。真正值得做微调的场景就两个一是你有非常多特定的输入输出样例Prompt 怎么写都塞不下、效果也不稳定二是你需要在离线场景跑推理模型要专门压缩过。如果你俩条件都不沾就别碰微调。微调的成本不只是训练那几天还有数据准备、效果回归、模型版本管理一套流程下来非常消耗精力。就算真要微调我也劝你从小参数量的模型开始比如用 LoRA 这类高效微调方法而不是全参微调。它的好处是训练快、显存占用低、还能把训练好的权重单独存成一个文件换模型版本成本极低。等你确认全参微调有必要了再上不迟——相信我大多数项目走不到那一步。6.3 从单点技术到系统思维最后的成长瓶颈做到这一步你的技术栈已经覆盖了 AI 工程的大部分拼图。如果还有什么能让你跟同行拉开差距我觉得是系统思维——不是某个模型用得熟练而是你能把一个 AI 系统放在整个业务流程里看。举个例子同一个文档问答能力给内部员工用和给外部客户用要求完全不一样内部的容忍度更高外部的响应速度和回答可靠性都是硬指标。再比如你的系统要不要做多轮对话记忆上下文能存多长过期文档怎么下架这些问题没有标准答案全靠你在具体场景里权衡。这种判断力只有通过真实项目里的反复摩擦才能练出来。我给所有进阶者的建议是多接“脏活累活”。别人不愿意做的数据处理、效果回流、线上监控你去做别人嫌烦的文档整理、标注规范、失败案例复盘你去总结。AI 工程现在稀缺的从来不是会调模型的人而是能把系统从 60 分稳稳推到 90 分、还说得清每一分是怎么来的人。最后分享一个我坚持很久的习惯每个项目结束写一份“如果重来我会怎么做”的复盘笔记三五百字就行重点记录当初的判断哪里错了、哪里有运气成分。这个习惯让我在五六年里攒下了厚厚一本实战认知比任何课程都值钱。希望你从第一个文档问答项目开始就建好自己的这本笔记。