刚转到 AI 工程方向那阵子我一度以为只要把市面上的大模型教程刷完、能跑通公开数据集就算入门了。结果第一次真刀真枪接需求——给企业的工单系统做一个“自动分类并推荐负责人”的功能我才意识到模型能跑出结果只是整个工程链路的 1%剩下 99% 的活儿全藏在数据清洗、接口设计、失败兜底、效果评估和成本控制里。那个项目最后上线用了六周真正花在调模型上的时间不到三天。所以当有人问我“ai-engineering-from-scratch”该怎么开始我通常不会甩给他一份课程清单而是让他先想清楚一个问题你想要的到底是“会调模型”还是“能交付一个稳定的 AI 功能”这篇文章就是围绕这个问题展开的。我会从 AI 工程和纯算法工作的本质区别讲起再给出一套我自己实践过、也带人走过很多次的从零到一的路径怎么选第一个项目、怎么设计系统分层、怎么处理评估和监控、钱花在哪里。适合两类人看一类是有工程基础但没做过 AI 项目想往 AI 应用方向转的开发另一类是已经在跑模型、但总觉得离“生产可用”差一口气的研究型同学。1. 先说清楚AI 工程和“调模型”根本不是一回事1.1 你负责的不是模型而是模型能稳定交付价值的整个链路很多人对 AI 工程的理解是“训练和微调模型”这其实是把 AI 工程和算法研究混在了一起。真正的 AI 工程项目里模型只是其中一个组件。我见过太多人把精力全花在提升一个百分点准确率上结果上线之后被调用延迟、token 成本、脏数据、用户反馈循环这些问题拖垮。给你一个直观的比例一个典型的企业级 AI 功能比如“智能工单分类”它的工作量分布大致是——需求定义与指标设计20%数据采集、清洗、标注与回流25%检索/上下文/提示词等应用层逻辑20%服务封装、异步任务、缓存与兜底15%离线评估与线上监控15%模型训练/微调本身5%如果一个人只盯着最后那 5%就永远只能做 demo做不了产品。AI 工程的能力本质上是把模型的不确定性用工程手段包裹成产品的确定性。模型可能答错、可能超时、可能胡说八道工程师的职责是让这些情况发生的时候用户感知到的依然是可接受的结果。1.2 一个 AI 工程师在真实需求里到底要干哪些活拆开讲的话一个完整的 AI 功能从需求到上线工程师核心要交付六类东西。第一数据回路。包括初始数据的抽取、清洗、切分、向量化也包括线上用户反馈数据的回流和再标注。很多时候数据端的活比模型端更决定成败。第二推理服务。模型怎么被调用是同步 HTTP 接口还是异步任务用流式还是非流式并发和限流怎么做模型超时怎么办这些问题不解决模型再好也上不了线。第三上下文工程。提示词怎么组织、历史会话怎么管理、外部知识怎么塞进上下文、token 超限怎么截断。这一层是 AI 应用和传统后端最大的不同因为模型的输入输出都是非结构化的文本你得替模型“打理好”它看到的东西。第四评估体系。没有评估就没有迭代。你要建离线评测集定义指标在每次改动前跑回归你还要在线上埋点用人气反馈隐式判断效果是否退化。第五成本与性能治理。模型调用是花真金白银的延迟也是用户体验的一部分。所以要有缓存、有方案降级、有模型分级路由。第六安全与兜底。输入要过滤敏感信息输出要做合规校验模型拒绝服务或乱答时要有固定话术承接。这套兜底机制必须提前写不能等线上出事了再补。1.3 从零开始需要建立的核心能力清单基于上面的拆解我建议从零起步的人把能力建设分成四条线而不是一头扎进模型训练能力线具体内容优先级数据工程线爬取/解析/清洗/切分/向量化/标注最高应用工程线API 封装、并发、缓存、异步、状态管理最高模型应用线Prompt 设计、RAG、微调、模型选型高运维评估线评测集、指标监控、成本分析、A/B 测试高这四根柱子缺一根项目都撑不起来。而且你会发现前三根其实都是传统软件工程能力的延伸只有第四根稍微新一点。换句话说从开发转 AI 工程没有你想得那么难但前提是把“AI”从神坛上拉下来把它当成一个会犯错的外部服务去设计系统。2. 第一块跳板怎么挑一个值得从零做完的 AI 工程项目2.1 判断项目值的三个硬指标很多人学 AI 工程卡在第一步东西学了不少但没有一个自己从头到尾做过的项目。我建议用一个“三有原则”来筛项目有真实数据。不用公开 benchmark 里那种加工好的数据最好是能从网上拿到或自己产生的、带噪音的、不干净的数据。哪怕是一个社区评论、一份企业公开文档、一堆聊天记录都行。因为处理脏数据才是 AI 工程的主战场。有反馈闭环。项目做完以后要能收到“这次回答好不好”的信号。比如用户会不会点/会不会复制答案会不会追问。没有反馈信号的项目做完了也不知道自己做得怎么样也就没法迭代。有清晰但非唯一正确解。任务最好既有客观评价维度比如能不能被正确检索到又有开放空间比如不同的回答风格。这样既能做量化评估又能发挥工程设计的创造力。2.2 我推荐的三种入门项目形态结合这三个指标我给别人推荐过很多项目最后沉淀下来靠谱的主要是三类。第一类个人知识库问答助手RAG。拿你自己的笔记、博客文章、某本公开书籍做私有知识库用向量检索加 LLM 回答。数据不干净、格式五花八门非常练数据能力而且好不好用你自己一测便知。第二类开源社区内容的高频信息抽取。比如扒某个技术社区一周的帖子用模型做主题聚类、标签生成、摘要归纳。这类项目对评估指标的要求更高能锻炼把模糊输出变成结构化结果的能力。第三类一个小而美的 Agent 工具。比如做一个能自动查天气、查股票、算汇率的多工具机器人。这个项目能逼着你学会函数调用Function Calling、任务规划、多轮状态管理。注意功能别做多三个工具以内否则工程复杂度会迅速失控。2.3 为什么反对一上来就训练大模型还有一个很常见的误区觉得从零学 AI 工程就要先训练一个自己的模型。我在这事上栽过跟头。当时为了“显得有技术含量”我用开源底座微调了一个领域模型花了两张卡跑了一周多最后效果不如直接调 API 加一套好的检索和提示词。后来我把那次经历总结成一句话模型的能力是市场给你的工程的能力才是你自己创造的。起步阶段不要自己训练或微调模型理由很现实第一你没有足够的领域数据微调大概率会过拟合第二硬件和训练调参的成本会吞掉你学习工程本身的时间第三现在商用 API 和开源模型的能力边界已经很宽多数应用需求根本不用碰权重。把省下来的时间花在检索、评估、监控这些别人看不见但决定生死的环节上性价比高得多。所以我给“从零”定的技术路线是从 API 起步 → 做透一个 RAG 项目 → 再把其中一部分换成本地开源模型 → 最后才考虑微调。每一步变化都只引入一个新变量出问题你才知道该查哪儿。3. 四层架构实战一个客服问答助手的从零搭建全过程3.1 整体分层和选型逻辑纸上谈兵说够了直接上一个我最近带人复现过多次的项目“企业客服问答助手”。需求很简单用户提问助手基于既有的产品文档和常见问题库回答。我做这个项目时把系统拆成了四层这是我认为最适合入门、也最能体现工程价值的结构。四层分别是接入层、编排层、数据层、评估层。输出端不用自建模型服务直接接模型 API这样可以聚焦在工程本身。选型方面我的逻辑是“能用最熟悉的就用最熟悉的”。Python 后端用 FastAPI数据存取用 SQLite 起步向量库早期直接用内存里的 FAISS后面数据量大了再地方迁移到真正的向量数据库。模型先用商用 API 做主力同时保留一个本地模型的接口方便后面换。这样选的原因很简单你要学的是架构思想和工程细节不是学某个特定中间件怎么调包。一上来就上 Kubernetes 加一套分布式向量库出了故障你根本分不清是检索问题还是部署问题。3.2 数据层知识库切分与向量化索引建不好后面全是坑数据层是四层里最“脏”的也是工作量最大的。我处理客服文档时遇到过各种鬼东西PDF 里文字是图片、表格被拆成乱码、同一份产品有多个版本说明互相冲突。给我 8 小时做数据层大概有 5 小时会花在清洗和结构梳理上。切分是第一个关键决策点。切得太粗每段内容包含多个主题检索时匹配不精准切得太细语义被切断模型拿到的上下文碎片化。我常用的配方是按标题层级结构先切出大块再按段落和语义边界切小块chunk_size 设在 400 到 800 个 token 之间chunk_overlap 用 50 到 100 个 token。这个数据不是拍脑袋定的它大致对应模型一次能有效阅读的上下文长度以及相邻 chunk 之间语义衔接需要的重叠量。向量化的时候要特别注意 embedding 模型的选择。我踩过的坑是用通用 embedding 处理专业客服术语导致“退款时效”和“退款到账时间”在向量空间里离得不够近。后来在切分时保留了关键词加权同时在 embedding 前做了一步领域词表替换扩充检索准确率明显提升。embedding 不是只要访问一次 API 就完事数据清洗、标准化、领域适配都得做在前面。3.3 编排层检索、重排、上下文组装与提示词管理编排层是 AI 应用的核心干的事相当于传统后端里的业务逻辑只不过操作对象变成了向量和文本。我的检索策略不是一次召回直接丢给模型而是两段式先用向量检索召回 Top 20 个候选 chunk再用一个轻量级重排步骤比如基于关键词重叠和位置权重的简单打分把最相关的 3 到 5 个 chunk 挑出来。为什么这么干因为向量检索擅长语义匹配但不擅长精确判断重排能结合词面信息把“看起来相关但实际答非所问”的 chunk 过滤掉。这个组合让我的最终答案引用准确率从 62% 提到了 81%成本几乎没增加。上下文组装也需要讲逻辑。我给模型的 prompt 会包含几个固定部分角色设定、知识库内容、对话历史、当前问题、输出约束。知识库内容放在最前面因为模型对开头的注意力通常更集中对话历史做截断只保留最近三轮防止 token 超限输出约束里写明“根据知识库回答知识库不足时明确说不清楚不要编造”。这套模板看似简单但每一条都是从线上用户的实际错误反馈里逼出来的——模型不会天然知道什么叫“不乱编”。3.4 接入层同步还是异步长文本场景怎么处理接入层容易出现“代码五分钟手段一整晚”的情况。客服助手有两个典型入口网页聊天需要流式回答API 对接需要标准响应。我的建议是优先做流式接口因为 AI 应用的体验关键在于“首字延迟”用户能接受你答得慢但不能接受两秒没动静。这里有个更隐蔽的坑模型接口不是所有时候都稳定会有超时、限流、内容审核拦截。我的兜底设计是三层——第一层网络层面的重试和退避第二层业务层面的固定话术告诉用户“当前问题比较特殊我帮你转人工”第三层把失败的 query 记录到日志方便后续进评估集反思。一个合格的 AI 接口异常处理路径的长度不应该小于正常路径。长文本场景上我建议提前设计“拆分-分治-汇总”模式。比如用户问“你们售后政策涉及哪些方面”可能同时命中多个 chunk这时候与其让模型一次性读太多不如先用检索把命中的 chunk 分组让模型分别概括再汇总成最终答案。这个模式早就有了但配合大模型用效果出奇地好。3.5 我踩过的三个典型坑和完整排查链路这部分我不直接给答案还原一下排查过程因为排查思路比答案值钱。第一个坑用户问题有点绕时检索返回的 chunk 完全不对。我当时先去查向量化日志发现 query 里的几个核心词在 embedding 后被分散到了不同方向然后又去查切分结果发现知识库里用户最关心的“退款周期”相关内容被埋在了一段讲“订单状态”的长文本里。根因是切分时没有照顾主题完整性导致检索命中时语义权重被噪音稀释。解决方案是把那段长文本按主题子标题拆开并给每个 chunk 额外生成了三组同义关键词用于适配检索。链路是现象 → 查日志 → 查切分 → 改数据 → 复测。第二个坑上下文组装后模型回答离题而且很自信。第一反应是提示词问题改了好几版没用。后来把 prompt 完整打印出来才发现对话历史里夹了一句用户很久以前说的脏话模型把注意力全吸走了。根因是对话历史清洗不到位。解决方案是在组装前做一轮历史和输入脱敏。这个坑教会我先看模型“看到的东西”别急着怪模型。第三个坑评估时人工看效果很满意但线上用户满意度反而下降。排查发现线上实际 query 和测试集的 query 分布差很多——测试集来自产品同事写的“标准问法”线上用户则是“半句话式”提问。根因是测试集构建偏见。解决方案是从线上日志里挑真实 query 回流标注建立了一个“线上分布优先”的评测集。这个排查链路后来成了我做任何 AI 项目的标准动作。4. 能上线只是及格线评估、监控和成本这三件事决定项目生死4.1 离线评估集这样建指标才算数我见过太多项目死在“我觉得效果不错”这句话上。没有离线评估集的 AI 项目本质上是在盲改。评估集不该随便攒几条数据至少要满足三个要求。第一是来源真实。答案要来自真实用户问题而不是团队成员自问自答。第二是覆盖均衡。我一般会按难度分三层简单知识库里能直接找到原文、中等需要拼合多个 chunk 的信息、困难知识库无法完整覆盖需要触发拒答。比例大致是 4:4:2。第三是标注透明。每条评测数据要写清楚标准答案、判定维度是否准确、是否完整、是否基于引用避免两个人评出完全不同的结果。指标上我会把人评和机评结合。机评用 LLM-as-a-Judge让一个强模型给回答打分化评分人评则重点盯着“引用是否正确”这个硬指标因为引用错了流畅度再高也没用。每次改完代码或提示词就跑一遍回归对比分数差异。没有回归测试的 AI 项目和没有单元测试的后端项目一样都叫裸奔。4.2 线上监控比模型本身更容易被忽视模型上线只是开始监控才是保证项目不死的底线。我的监控分维度是三个词量、质、本。“量”指的是调用量、用户数、session 数这些基础流量指标异常波动说明可能有活动或者系统出问题。“质”包含首字延迟、完整响应时间、失败率、无答案率。我习惯给“无答案率”设一个两条线短时间小幅度上升不处理持续上升就要告警。“本”就是 token 消耗量我会按用户、按功能模块分别统计。这里有一个很实用的技巧给模型输出加一个不可见的“引用标记”比如在回答最后加上一段固定格式的来源编号。线上判断回答质量时直接统计“有多少回答带了有效引用”作为响应质量热的代理指标。这个信号不完美但胜在便宜、足够实时。你甚至可以把引用率骤降当成一个提前告警因为它往往先于用户投诉出现。4.3 成本账怎么算AI 应用的成本不是线性的随着用户量增长成本结构会发生三次转变你得提前有预期。阶段用户规模成本特征核心策略0→100测试期token 成本可以忽略重点优化效果别过度设计缓存100→1k早期用户token 成本开始肉眼可见加语义缓存、合并请求、降级方案1k→10k增长期成本成为约束模型分级路由、本地小模型承接简单问题第一次接到上千用户时我算过一笔账如果所有问题都走大模型每月 token 费用相当可观。后来我加了一道“意图分类前置路由”——先用一个轻量小模型把问题分到简单/困难两档简单问题走本地小模型只有复杂问题才调用大模型。整体成本降了约 40%而用户体验几乎没有变化。成本优化的本质不是省 API 钱而是通过系统设计让每一块钱都花在刀刃上。5. 给从零开始的人一份不鸡汤的成长路线5.1 应该学什么、暂时别碰什么从零开始学习顺序比学习内容更重要。我建议“四个先学四个不碰”先学 Python 后端基本功FastAPI 或 Flask不碰大模型源码。先学 Prompt 工程和 RAG 流程不碰分布式训练。先学评估和监控体系不碰花哨的 Agent 框架。先学怎么用好现成模型不碰从零预训练。为什么不碰框架因为现阶段的 LangChain 这类框架抽象层极厚出了问题你会被框架和模型两头折磨。我自己更推荐先用原生方式写一遍 RAGembedding、向量检索、prompt 组装、调用模型、解析输出全流程都自己写一遍。写完这遍框架里的概念你再看就是透明的了。5.2 按周划分的实操节奏我建议以六周为一个周期做完第一个项目。前两周搭环境、采集和清洗数据不着急跑模型把数据切分好、建好索引。第三周完成最简接口输入问题返回一个未经优化的答案。第四周做检索优化和重排让答案“看起来靠谱”。第五周做评估集和回归测试开始量化迭代。第六周上监控、写自动化测试、整理项目文档。这是一个刻意安排的节奏每两周只解决一个层级的问题避免同时改多个变量导致失控。六周后的产出不是一个“炫酷 demo”而是一套带评估、带日志、带文档的完整系统这放在简历上才叫项目经验。5.3 作品集怎么沉淀以及面试会被问什么作品集不需要多一个打磨透的项目胜过五个半成品。但“打磨透”有三个可验证标准一是你能写清楚数据来源和处理流程每一步处理都有理由二是你能画出系统的分层架构图并说清每层为什么这样设计三是有量化结果最好有一份“优化前与优化后”的对比记录。面试时高频被问的问题其实也很固定你做这个项目时检索召回率低怎么排查的模型回答出现幻觉你的兜底机制是什么线上调用量突然翻倍你怎么应对这些问题考察的都不是模型知识而是工程判断力。如果你能讲清楚某个问题出现时你的完整排查链路就已经比大多数只会背模型结构的人有竞争力了。最后分享一个我个人的体会做 AI 工程重要的不是掌握最新最热的模型而是建立“系统会出错”的预期并提前为出错做好准备。这种思维不是看书能学来的只能靠亲手把一个项目从无到有、从乱到稳地跑一遍。如果你正站在起点上不用等什么“基础扎实了再开始”直接挑一个数据不干净的、问题有点真实的小项目动手做一次。做完那一遍你就不再是 AI 工程“从零”的人了。