ai-engineering-from-scratch这个标题直译过来就是从零开始做AI工程。我之所以一直想写这个主题是因为这两年带团队做AI项目见过太多人把跑通一个模型直接等同于完成了一个AI工程结果系统上线第一个月就被打回原形。这篇文章我不想讲那些玄乎的概念我会按一条真实走过的路径告诉你AI工程和算法Demo之间到底差在哪儿怎么用一个最小闭环项目从零练手以及Prompt Engineering和Agent在真实工程里应该放在什么位置。无论你是后端开发、算法工程师、测试还是想转行做AI产品的人这篇文章应该都能帮你少踩一些坑。后面提到的每一条几乎都是我们项目里试过、踩过、改过之后才沉淀下来的你可以放心拿去参考但最好还是带入自己的业务场景来读。1. AI工程和算法Demo之间差的是一整套体系1.1 我在真实项目里看到的调模型与做工程的差距先讲个最近发生的场景。去年有个项目是给内部客服团队做智能问答系统算法同学花一周时间把开源模型在离线测试集上跑出了不错的分数觉得自己已经交付了。可是到了联调阶段问题全冒出来了接口并发一上来就显存溢出模型回答的格式偶尔不是合法JSON把下游系统搞崩好不容易稳定了运营反馈同一个问题隔两天回答的版本就不一样根本没法对外承诺。这些事没有一件是模型效果不好造成的但每一件都让人头皮发麻。这就是调模型和做工程最本质的差别调模型关心的是准确率还能不能更高AI工程关心的是这个系统能不能在真实环境里稳定、可控、可迭代地跑下去。你可以把模型想象成一台发动机代码、数据、评测、监控、部署脚本是底盘、仪表盘和方向盘。发动机再猛没有仪表盘你根本不知道它什么时候过热没有方向盘你也没法微调方向。所以判断一个人是不是真在做AI工程就看两件事面对线上事故时能不能快速定位是哪一层出了问题能不能把一次灵光一现的效果提升变成团队可复现的例行流程。1.2 AI工程要解决的核心问题数据、评测、迭代如果你问我AI工程从零开始最应该抓住什么我的答案不是模型架构也不是某个框架而是三件事数据、评测、迭代。数据是原料决定了模型效果的天花板评测是仪表盘决定了你能不能准确判断一个改动是变好还是变坏迭代是方法决定了你能否把每一次线上反馈变成下一个版本的输入。我见过很多团队把90%的精力花在换模型和调超参数上却不愿意花一个下午清理训练数据里的脏数据更不愿意维护一套固定评测集。结果就是模型版本换了几十次每次效果全靠感觉还行线上bad case越积越多最后谁也不敢再动这个系统。反过来如果数据干净且可追溯评测集能自动化跑迭代自然就变成一个工程闭环改数据、改Prompt、跑评测、看bad case、再改。这个闭环一旦跑起来后面再复杂的系统都是在这个地基上叠出来的。说句得罪人的话大部分失败的AI项目死在最后一公里的不是模型而是没有把这个闭环修好。1.3 谁需要学AI工程不只是工程师还有一个常见误区觉得AI工程是算法工程师或后端工程师的事。我自己的观察是AI工程最大的瓶颈往往不是某个人水平不够而是团队协作里的信息差。产品经理如果不懂评测口径很容易被准确率又涨了这类汇报带着走测试同学如果不懂模型灰度就只会用老一套功能用例去测一个随机性很强的系统数据分析师如果不理解数据漂移就解释不了为什么线上效果每周都在变。所以在我的定义里AI工程其实是一门跨角色协作语言。你不用会写复杂的模型训练代码但你至少要理解数据、评测、迭代这三个支柱怎么互相作用。哪怕你只负责验收能问出这次改动在固定评测集上跑了吗bad case归类做没做老功能有没有回归测试就已经比只会说效果看着不错的参与者专业一个段位。后面写到的很多方法你完全可以站在自己角色里去用其中一部分。2. 从零动手选一个值得做的最小闭环项目2.1 为什么我建议从知识库问答而不是开放对话起步从零开始学AI工程最大的障碍往往不是学不会而是不知道拿什么练手。很多人一上来就搭一个什么都聊的机器人结果被对话管理、安全过滤、多轮状态这些复杂问题一压几周就放弃了。我的建议非常明确做一个垂直领域的知识库问答系统。理由有三个。第一边界清晰。数据是你自己整理过的文档不需要处理开放域带来的无限可能性。第二可以评测。你能定义答案是否来自资料是否准确是否完整这类相对客观的标准。第三它天然覆盖AI工程完整链路文档切分、向量化、检索、生成、评测、部署。你会在一个项目里把整张地图走完而不是只摸到一个点。等这条链路跑顺了再去碰开放对话、Agent这些进阶玩法那时你手里已经有工程方法去打底了。2.2 数据准备把清洗和标注流程跑通比数据量更重要确定方向后第一件事千万别急着接模型先把数据流程跑通。我建议先整理一批200到500条的高质量问答对当迷你数据集。注意这些问答对一定要从真实用户可能问的问题里来。你可以翻历史客服记录、看论坛提问、观察同事日常怎么问而不是坐在工位上拍脑袋觉得用户大概会这么问。数据的真实度直接决定你后面所有评测有没有参考价值。清洗阶段我会做四件事去重、去掉无意义符号和表情、统一指代比如咱们统一成我们、修正明显的错别字。清洗完再做一个背靠背人工标注至少两个人独立标注这个问题能否在知识库里找到答案然后算标注一致性。我一般要求Cohens Kappa不低于0.7再继续。这个数字看着像是统计洁癖但它的实际价值是如果两个标注人对可答还是不可答都达不成一致后面整个评测体系都站不住脚。与其在评测阶段反复争吵不如在数据阶段就把标准定下来。2.3 评测指标没有评测AI工程就无从谈起知识库问答的评测我习惯拆成检索和生成两个独立环节。检索环节看recallk通俗讲就是前k条检索结果里有没有命中正确答案所在的文档。假设某个问题在知识库里有3份相关文档检索前5条命中了2份那recall5就是2/3也就是67%。我一般要求recall5做到90%以上再去管生成。检索都捞不回来生成模型再强也巧妇难为无米之炊。生成环节看两个东西忠实度和有用性。忠实度衡量答案是否严格来自资料、有没有编造有用性衡量答案是否接住了用户问题的要点。具体操作上我会维护一个100条左右的固定评测集里面既有高频问题也有故意刁钻的边界问题。每次改动无论改了文档切分逻辑、向量模型还是Prompt都在这个评测集上跑一遍至少两个人独立给生成结果打1到5分再取平均。这个评测集就是你的资产。没有它你做的所谓优化就只是自我感觉良好有了它你才能说清楚上一次版本到底比这一次差在哪。2.4 第一次部署模型服务化最容易踩的三个坑最小闭环跑通之后进入部署阶段这才是AI工程真正的主场。开源模型建议直接用vLLM这类方案做服务化它自带连续批处理能把GPU利用率拉高不少。但不要急着上生产先处理我下面说的三个坑。第一个坑是并发和显存的关系。很多人以为模型服务占的显存就是模型权重的大小其实还要加上KV Cache和推理中间结果。我自己的粗算经验是单实例预留显存至少按模型权重大小的1.5到2倍来估batch size从1开始慢慢往上加同时盯P99延迟明显恶化就退一格再额外留20%余量给突发流量。第二个坑是超时和重试。大模型生成慢超时设太短会误伤正常请求太长又会拖死线程池。我一般把连接超时设5秒读取超时设30秒重试只做1次第二次失败直接降级比如返回检索到的相关资料而不是让用户对着一个转圈中的页面干等。第三个坑不是技术而是习惯从第一天起就把每个请求的输入、输出、检索到的文档ID、耗时、token数全部落盘。我后面还会反复强调这件事没有日志你连一次像样的bad case分析都做不了。3. Prompt Engineering 与 Agent 在工程中的真实位置3.1 被过度神话也被过度轻视的环节现在聊一个讨论最多、误解也最多的词Prompt Engineering。我在圈子里见过两种极端态度一种觉得它没什么技术含量无非是跟模型好好说话另一种是把它当成万能钥匙以为只要提示词写得足够花哨什么复杂功能都能实现。真实情况是两种都不对。我的理解里Prompt在AI工程中更像半成品代码。它和代码一样需要版本管理、测试、灰度但它又不能像代码那样靠断言来验证逻辑所以它实际上比常规代码更脆弱。一个在办公室里看着很完美的Prompt换一批数据分布、换一个模型版本可能立刻失灵。所以真正做AI工程的人不会抱着写一次就完事的心态而是会把Prompt当成一个需要持续维护的组件来对待。我后面讲的流程就是我们团队日常在用的那一套。3.2 一套可复用的Prompt设计流程从草稿到版本管理Prompt怎么工程化我按四个步骤做。第一步先定义输入输出结构。我会用JSON Schema一类的方式把输出格式焊死而不是靠自然语言去约束。比如知识库问答的输出必须包含answer和source_ids两个字段模型先按结构生成后端再做一轮校验。第二步写第一个版本时把说人话、不要编造、只根据资料回答这类约束写清但每条约束都应该是可评测的。比如你可以写如果资料中没有答案请明确回答资料中未找到相关答案然后在评测集里加几条资料中没有答案的case来验证看它是不是真的不硬编。第三步是迭代规则每次只改一个变量把新旧版本在固定评测集上的结果并列对比。很多人改Prompt跟煮汤一样这加一点那加一点最后效果好也不知道是哪个改动生效的效果差也不知道该回退谁。第四步是版本管理把Prompt存成独立文件和代码一起进Git库版本号写进评测报告。这样团队里谁调过、调了什么、效果涨还是跌一目了然。我见过太多项目Prompt散落在聊天记录和各种在线文档里出了问题根本不知道当初那个好用的版本长什么样。下面是一个简易Prompt模板你可以直接拿去改你是一个知识库问答助手。请仅依据以下资料回答用户问题。 规则 1. 如果资料中没有答案请直接回答资料中未找到相关答案。 2. 答案不超过200字。 3. 在答案末尾注明来源文档ID。 资料 {context} 用户问题 {question}这个模板看起来平平无奇但它背后的逻辑是每一条规则都能在评测集里转成一道验证用例比如第1条对应资料缺失类case第2条对应超长回答类case第3条对应来源缺失类case。能这样被验证的Prompt才算是工程组件而不是随手写的漂亮话。3.3 Agent工程化工具调用、状态管理与容错设计往深走一步就是Agent。我的态度依然很保守先别急着上Agent除非你已经把单模型闭环跑得足够稳。如果确定要做请按工程思路来而不是让模型自由发挥。假设你已经定了三个工具比如查天气、查日历、发通知要做会调用内部API的Agent你会发现三个新问题。第一个是工具定义。每个工具的参数必须定义成结构化Schema并且给模型搭配示例否则模型很容易把日期格式传错、把必填字段漏掉。第二个是状态管理。多轮对话里状态不要全部塞进上下文让模型自己记我会维护一个显式的状态对象记录当前用户走到哪个流程、哪些信息已收集、哪些还缺只把必要信息拼进Prompt这样既省token又减少遗忘。第三个是容错。模型调用工具失败是常态关键是别让它死循环。我之前做了一个调用内部工时系统的Agent模型连续三次把日期传成不存在的格式如果没有重试超2次自动转人工的兜底规则它能在同一个错误上空转一晚上。所以给Agent设任务上限、给每步设兜底逻辑不是可选项是必选项。4. 进入AI Native阶段必须补上的三大工程基建4.1 数据即代码效果回归从人工感觉变成自动动作聊到AI Native这个词网上的定义一个比一个玄。我自己理解得很朴素当一个团队不再只是偶尔调个AI接口而是把AI系统当成核心产品来持续迭代时过去的研发范式就不够用了。传统软件工程的核心是代码正确性测试用例固定输入输出确定AI系统不一样输入空间接近无限输出有随机性你没法靠几条断言保证质量。所以成熟的AI团队会把数据即代码当成一条原则。具体落实到操作上就是三件事评测集必须进Git仓库数据变更要像改代码一样走评审Prompt和模型配置作为版本化配置项和代码绑定发布每次模型升级或Prompt修改都要附带一份完整评测对比报告。可能有人觉得这套流程太重但我的经验是只要你的AI系统要健康存活超过三个月这笔成本是必须提前付的。不然迟早会在一场莫名其妙的bad case排查里消耗掉五倍的时间而且大概率还查不出所以然。4.2 可观测性让每一次输出都可追踪、可回放传统后端有APM监控就算及格了AI系统的可观测性门槛要高得多。我给AI服务设计的日志至少包含这些字段request_id、用户原始输入、检索到的文档ID列表、模型实际收到的Prompt、模型输出、耗时、token消耗数、是否走了重试或降级。每一行都要落盘并且能按request_id把一次完整请求链路串起来。为什么这么重视日志因为AI的bad case往往不是代码逻辑错而是数据分布变化的表现。比如运营团队上线了一批新文档检索召回率突然下降此时模型本身根本没动。如果你只有一个效果变差的感觉没有任何日志排查只能靠猜日志齐了你可以直接做回放把线上某一个真实bad case拿回来在当前版本模型上重跑一遍马上分清是检索环节丢了还是生成环节在编。这种回放调试能力是AI工程把传统工程甩开身位的地方谁早做谁受益。4.3 多AI协作与工作流编排的真实场景很多人听到多智能体协作就兴奋真落到工程上我更建议先把它理解成多个单一职责的模型服务通过编排一起干活而不是一群自由Agent在聊天。我们做过一个合同审查项目流程是这样的意图识别模型先判断用户是想查风险条款还是对比历史版本接着路由到不同检索服务取数最后再单独用一个生成模型写结论。这种拆分的好处是每个环节都有独立评测指标和降级方案。意图识别错了可以回退到默认流程检索没召回可以明确告知生成模型资料不足请说明原因生成模型挂了整个系统不会跟着瘫痪。编排上不一定要上重型框架先用状态机或一条清晰的任务队列把流程串起来就够了。我自己的体会是AI系统的复杂度是逐步暴露的一开始就上一个重量级编排框架只会给你的排查和调试增加不必要的负担等到你真正需要它的时候再上也不迟。5. 亲身踩坑清单与三个月进阶路线5.1 五个反复踩、别人也会踩的坑如果只能给五条建议我会选下面这五个因为它们几乎在每一个AI项目里都会出现而且越早知道越省钱。第一个坑不校验模型输出就直接用。模型偶尔会输出不合法JSON或者多出两个字段后端一解就崩。解法是在服务入口加一层输出校验不合格就重试一次再不行就降级千万别赌模型每次都听话。第二个坑只测准确率不测延迟。换更大的模型可能让接口从300毫秒变成3秒业务直接超时所以每次模型评测都必须带上P50和P99延迟指标缺一项都不完整。第三个坑把全量文档一股脑塞进向量库不做切分和去重结果检索结果里重复段落一大堆既浪费上下文空间又干扰生成。文档切分逻辑要有自己的独立评测别和模型效果混在一起。第四个坑Prompt改了但没记录。等到线上效果崩了你想回退到上一版却发现上一版根本不存在。从第一天就做Prompt版本管理这个习惯越早养成越好。第五个坑不看成本。跑一个亿级token的项目月账单可能真的让你措手不及。从一开始就按请求维度和token维度统计成本按天出报表谁烧钱一目了然。5.2 三个月入门路径按阶段给自己定验收标准最后给一条可执行的学习路径。我带过的实习生按这个节奏走普遍在三个月左右就能独立负责一个简单的AI服务迭代。第一阶段是第1到第2周选一个你最熟悉的知识领域做出最小知识库问答系统重点是把文档切分、向量检索、生成这三段都跑通先不追求效果。第二阶段是第3到第4周把评测体系建起来积累至少100条评测集定出你和业务方都认可的评分标准然后做第一轮完整评测。第三阶段是第2个月加部署和日志把服务接到线上哪怕只是内部小范围试用。这个阶段的目标不是优化效果而是练出出了问题能定位的能力。第四阶段是第3个月尝试加工具调用或简单Agent同时把数据、评测、版本管理这套流程固化到团队协作里。走到这一步你基本算是在做AI工程而不是在玩模型了。5.3 我最后想说的话把我觉得行变成指标说明它行关于AI工程这个方向我不太喜欢把它描述成又一个热门岗位。它更像是一套做AI产品必须具备的职业素养。不管你的title是算法工程师、后端工程师还是产品经理只要你参与AI系统的落地迟早都要面对同一件事让一个充满不确定性的东西变得可度量、可控制、可解释。你不需要从零推导Transformer的数学原理但要能说清楚自己的系统在哪个环节可能因为什么而变化。我自己最大的体会是AI工程真正的门槛不是框架不会用、模型原理不懂而是你愿不愿意把每一步都变成可以验证的动作。你什么时候能把我觉得这个Prompt不错换成评测集上比上个版本高了8分bad case数量在减少你就真正从跑模型的人跨进了做AI工程的人这个门槛。这个转变不惊天动地但所有稳定可用的AI系统地基都是这么打出来的。