ai-engineering-from-scratch 这个标题拆开看其实挺有意思。ai-engineering不是简单的“用AI”而是把AI当作一个需要设计、需要测试、需要维护的工程对象from scratch 又强调了从零开始搭建整套能力。我见过太多开发者的状态会调API、会写提示词但一上生产就露馅——回答不稳定、不可追溯、测不了、改不动。这篇文章就把我亲自动手从零搭一整套AI工程基线的过程写出来不是教科书式的概念梳理而是实打实的路线图、步骤和踩坑总结。这个内容适合谁想转行做AI应用开发的程序员带着团队做AI落地的技术负责人以及那些已经能跑通一个demo、但不知道如何把“会骗人的模型”变成“可交付的系统”的工程师。本质上ai-engineering-from-scratch 要解决的是一整类问题从单次调用里的随机性到整个系统的确定性从一个人的灵感到一个团队的可维护性。说的直白点这是一条从“调包侠”到“AI架构者”的成长路径。1. 从零开始到底要从哪里起步先把AI工程的边界画清楚很多人一听“from scratch”第一反应是去补线性代数、微积分、反向传播推导觉得不把Transformer论文手推一遍就不配做AI工程。这个方向不能说错但大多数人的卡点根本不在数学而在“不知道一个能上线的AI系统到底长什么样”。我自己的经验是先把工程边界画清楚再决定学什么效率高得多。1.1 为什么说“从零”不等于“从代码第一行开始”AI工程最反直觉的地方在于它建立在大量不确定性之上却必须产出确定性的结果。传统软件工程里if 就是 if不会今天返回true明天返回false。可你往API里发同一段prompt温度设成0.7两次输出大概率不一样。所以从零开始做AI工程第一步不是写模型而是建立一个认知你的目标不是消灭随机性而是把随机性控制在一个可接受的范围里并且让每一次随机都有测量。我见过一个团队花三个月把大模型推理服务、向量数据库、Agent框架全部搭好了产品经理往里丢了一堆测试问题发现答案一会儿好一会儿差团队就崩溃了。为什么崩溃因为没有人定义“好”的标准没有人建评测集没有人在改prompt之前先跑一遍基线。这不是AI的问题是工程缺位。所以我的建议是从零开始的起点应该是“评测”和“基线”不是模型部署。1.2 一张路线图从调用者到架构者的四个阶段为了让你更清楚地定位自己在哪、要去哪我把AI工程能力拆成四个阶段第一阶段“调用者”会调大模型API能写prompt能处理基本的解析和重试。交付物是一个能用的demo但对“为什么这样写”没有系统判断。第二阶段“优化者”掌握评测方法能建评测集能做RAG检索的调优知道什么时候该用向量检索什么时候该走微调。交付物是一个可以稳定跑在测试环境里的应用。第三阶段“架构者”能设计多Agent协作方案能管理上下文和工具调用能构建完整的测试闭环和监控体系能判断一个复杂业务场景该用单模型还是多模型、该做实时检索还是离线知识库。交付物是一个能上生产、出问题时能快速定位的系统。第四阶段“研究者”能自己训模型、改架构、设计对齐方案。这个阶段就不是大多数人需要的了。如果你现在还在第一阶段别急着上LangChain、AutoGPT那些重框架先把“评测”这件事做起来。我后面会详细讲怎么做一个最小可用的评测闭环。1.3 你手里已有的传统工程能力千万别丢一个特别容易被忽略的事实是AI工程不是凭空出现的领域它是在传统软件工程的土壤上长出来的。你的依赖管理、版本控制、日志监控、单元测试、CI/CD经验在AI工程里全部有效只是多了一层“模型的不确定性”需要额外处理。说白了会写Python、会管理服务、会做性能分析的人学AI工程比纯算法背景的人更快。因为AI应用的大部分代码还是普通代码数据清洗是普通代码API通信是普通代码缓存、限流、权限控制也是普通代码。真正需要“AI特殊处理”的只有一小块比如模型输出的校验、评测集的设计、反馈数据的回流。我带着团队做项目的过程中发现工程能力强的组和工程能力弱的组在同一个模型、同一份需求面前交付质量的差距能拉到三倍以上。所以不要妄自菲薄把传统工程能力迁移过来就是“from scratch”里最大的底气。2. Prompt Engineering到Agent开发中间隔着一整套思考方式热词里频繁出现“prompt engineering”、“ai agent”、“多ai协作”这些东西看着是几个独立概念实际是一条逻辑链Prompt是单次交互的边界设定Agent是把多次交互编排成完整任务多Agent协作则是把多个角色的任务编排成一个系统。想直接跳到Agent开发的十个里有八个会翻车因为基础边界没画清楚。2.1 Prompt不是“写词”而是在给模型划边界我在刚开始写prompt的时候总觉得“提示词写得越详细越好”后来踩了坑才明白提示词的核心不是字数多而是“边界清晰”。好的system prompt应该像一份技术合同写明角色、输入格式、输出格式、禁区、兜底策略。模糊的“你要表现得专业”不如精确的“如果问题涉及医疗诊断必须声明这不是医疗建议并建议用户就医”。再分享一个我常用的三段式结构角色与目标、输入与约束、输出与兜底。角色与目标决定了模型的语气和关注点输入与约束告诉模型哪些信息可用、哪些策略必须遵守输出与兜底决定了格式以及模型不确定时该说什么。在我搭过的客服问答系统里光是“输出与兜底”就干掉了一半以上的幻觉问题。因为模型在不知道答案时会按兜底话术直接说“这个问题我暂时无法回答已记录并转人工”而不是硬编。2.2 Agent的三个关键问题任务拆分、记忆管理和工具调用Agent开发是prompt engineering的升级版因为从单次对话变成了多步决策。我自己的体感是Agent落地成败就看三件事第一任务拆分是否合理。现在的模型不擅长一口气处理超长复杂任务但很擅长你替它把大任务拆成子任务。比如“分析上季度销售数据并生成PPT大纲”你理想的流程是先调SQL查询再写Python做摘要再生成PPT结构。Agent框架能帮你按顺序跑这些步骤但“这个任务该拆成几步、每步依赖什么”是你在设计阶段就要想的。第二记忆管理是否有层级。工作记忆对应当前任务里的临时信息短期记忆对应本轮对话的上下文长期记忆对应从向量数据库里检索出来的持久知识。最容易翻车的地方是把所有东西都塞进上下文窗口导致token爆炸、成本激增、响应变慢。我常用的策略是每一步都只保留“执行当前子任务必要的信息”任务间的中间结果用结构化数据存储而不是随手拼进下一轮消息。第三工具调用的schema要像接口文档一样严格。模型会自己决定调哪个工具、传什么参数所以你的工具描述必须给清楚这个工具是干什么的、参数格式是什么、什么时候不建议调用它。我遇到过Agent把一个“用户名查询接口”的入参传成了一大段对话历史的搞笑事故后来发现是工具描述里没写清楚“只接受精确用户ID”模型觉得把对话内容传过去更保险。2.3 为什么工程上必须追求“确定性”做Agent最难受的体验就是同一个任务跑十次三次成功、五次带点小毛病、两次彻底失败。这在demo阶段你还能忍上了生产完全不行。所以工程化Agent一定要给模型套上“确定性约束”温度参数需要分类、抽取、格式化输出的场景把温度设到0或接近0需要创意的场景再调高而且高温度场景必须配人工审核。输出校验给模型规定JSON输出然后用Pydantic之类工具做严格schema校验校验失败就重试或降级到规则兜底。有界重试重试必须有次数上限和退避策略不能让Agent在同一个错误上无限打转。可观测性每一步的输入输出都要记录不然一个Agent链条出问题你根本不知道是哪一环开始错的。这套“确定性约束”做完你会发现多AI协作其实也没那么神乎其神。所谓的“多AI协作”就是给不同模型分配不同角色比如一个负责检索、一个负责生成、一个负责审核然后用工程代码来控制它们之间的消息传递。本质上和你管理多个微服务没有区别只是每个服务变成了一个带随机性的模型调用。“工程上怎么控住随机性”这个思路一旦想明白后面所有问题都好办。3. 模型侧的能力补全从理解原理到真正碰一碰权重工程做到中期你迟早会面对一个问题手里的开源模型能力不够或者连着API心里没底或者想看看到底能不能通过微调解决业务痛点。到这个点就要开始补模型侧的基础理论了。注意我不建议迷信“必须读多少篇论文”而是建议你对三个关键概念形成肌肉记忆级别的基础认知。3.1 大模型基础理论里必须先啃的三块硬骨头第一块是Tokenizer。Tokenizer决定了一段文本会被切成多少个token而你的成本、上下文长度、模型的“单位意思”都建立在它之上。一个特别容易踩的坑是英文tokenizer处理中文时效率很低一句话可能切成很多碎片导致同样内容的token数是英文的好几倍。所以做中文AI应用时一定要先测一下目标模型配套tokenizer的中文效率再估算成本和上下文预算。第二块是Attention机制。Transformer里的自注意力本质上是让每个token跟序列里所有其他token算相关度。它的计算复杂度是序列长度的平方这就是为什么上下文越长、推理越慢越贵。理解了这一点你就明白为什么工程师总是想尽办法“压缩”上下文不是模型不想记是成本和延迟不允许。做RAG、做摘要、做记忆裁剪本质上都是跟O(n²)这个复杂度搏斗。第三块是训练目标。预训练让模型学会“接下一句话”指令微调让模型学会“按指令做事”对齐让模型学会“说安全合理的话”。业务里你的模型行为不对劲很多时候不是模型坏了而是它只接受了其中某一个阶段的训练没有你期望的能力。你要微调领域知识大概率是在指令微调阶段做你要调整语气和风格可能也要指令微调或RLHF那套对齐流程。想清楚模型的能力来源你才能判断问题该用prompt解决用RAG解决还是用微调解决。3.2 Token、上下文窗口、Attention成本一次完整的预算计算我举一个自己实际算过的例子你感受一下为什么要理解这些参数。假设你选了一个上下文窗口为32k的模型API按token计费。你的RAG逻辑每次检索8个chunk每个chunk约500字符大概能折成1000到1500个token加上system prompt和用户问题一次请求的输入大约在12000到16000个token之间。假设你的业务QPS是50平均输入1.4万token、输出500token那一小时的成本就是50 x 3600再乘上每token的价格账算下来非常惊人。这就是为什么工程上你不可能“让模型读所有东西”必须靠检索把输入控制在必要范围。同时也解释了为什么“长上下文越大越好”这个说法要看场景上下文变大意味着你的检索精度要求降低但成本、延迟和注意力计算的压力全部上升。在绝大多数业务场景里把上下文从32k压到8k配上一套好的检索比直接大上下文硬读效果更好成本可能差四到五倍。3.3 微调是不是从零做AI的必经之路我的结论是绝大多数业务场景不需要微调用RAG加prompt就能解决八成问题。什么时候才需要微调我列几个判断标准模型经常在特定格式上犯错你需要的输出风格和模型默认风格差异很大你需要让模型学习某一类领域术语和判断逻辑prompt已经把上下文窗口塞满了还达不到效果。如果真决定微调现在的技术栈已经很友好了。基于LoRA或QLoRA这类参数高效微调方法你不需要重训整个模型只训练一小部分适配器参数。比如一个70B模型用QLoRA在单张高端显卡上就可能跑得动成本比全参数微调低几个数量级。这块我也不是理论派实操时最大的体感是数据质量远比训练代码重要。你花一周时间构造一千条高质量样本比直接灌一万条从网上爬的脏数据有效得多。数据怎么构造、怎么清洗、怎么去重才是微调项目里最耗时的部分。如果想从根上理解模型我建议找两本书啃一啃一个是《Build a Large Language Model From Scratch》另一个是《Build a Reasoning Model From Scratch》。这两本都是教你手写实现模型、手搭训练管线的路子。我不是让你照抄代码而是跟着走一遍之后你会对“模型为什么有这个行为”有真正的手感而不是只把大模型当黑盒。这种体感在做工程决策时特别值钱。4. 完整实操搭一个带RAG和测试闭环的工程基线光讲概念不讲操作等于耍流氓。下面我把一个真实的“企业知识库问答机器人”从0到1搭完整它就是典型的RAG加Agent链路同时带着评测和测试闭环。这套方案我不按某一家云厂商的专有服务写全部选通用组件你可以直接落在自己的服务器上。4.1 第一阶段数据层数据获取与清洗先解决一个很多人忽略的问题知识库里的文档不是天生就是好语料的。企业内部常见的文档格式是PDF和Word而PDF尤其难搞——有些是文字层的可以直接抽取有些是扫描件需要OCR还有一些是表格和图片混排抽取出来全是乱的。我踩过的流程是这样的先用解析工具把PDF和Word转成纯文本然后人工抽看20个样本确认几个关键信息——标题、正文、表格、页眉页脚是不是都识别对了。如果扫描件比例高就把OCR步骤接进来但OCR也会错特别是表格、公式、中文标点所以对OCR文本要做一轮规则清洗比如把全角半角统一、把多余换行改掉、把“|”这种表格残骸处理掉。清洗完之后就是切块。切块的策略我建议先从一个简单方案开始按固定字符长度300到500切段与段之间留80到100个字符的重叠。这个重叠参数是防止一句话在切块时被从中间劈开导致语义不连贯。更好一点的方案是按标题结构切比如“章节标题下的内容作为一个候选块”但不同文档的标题结构差异很大规则容易脆。先用固定长度跑起来后面再迭代结构切块。4.2 第二阶段检索层Embedding加向量数据库检索层是RAG效果的分水岭。很多人以为把文档切开、塞进向量库就完事了实际上一套靠谱的检索方案至少要解决几个问题用哪个embedding模型、向量库选哪个、召回多少条、混合检索要不要上。Embedding模型的选择上中文场景优先考虑开源的中文向量模型比如bge系列这些。评估embedding有一个简单粗暴的土办法准备30个代表性的用户问题用一个候选embedding模型把文档切块编码然后看手动检出的文档片段排在第几位。如果每次都排不进前五说明这个模型跟你的领域不匹配换个更强的模型。向量数据库的选择我按团队能力给几条建议项目很小时用轻量级方案比如chroma或qdrant这类单机方案部署简单、迭代快数据量到百万级向量或者需要高并发时再上重量级方案比如milvus之类。别在项目第一天就上一套重型分布式向量库运维成本会把你拖垮。这里还有一个值得说的点纯向量检索处理“关键词精确匹配”其实不太行比如用户搜“2024年报销流程”如果2024在文档里写成“二〇二四”向量检索不一定能对上。所以工程上更稳的做法是“混合检索”把BM25关键词检索和向量检索都跑一遍两种结果合并、排重、加权排序。这个步骤能明显提升召回率的稳定性我的项目里加上混合检索之后“找不到答案”的比例降了差不多三分之一。4.3 第三阶段生成层提示词模板与链路编排检索把相关材料找到了接下来要决定怎么把它们喂给模型。这部分的工程关键有两个提示词模板管理以及链路编排工具。提示词也得管版本这点很多人忽略。我在团队里强制要求所有prompt以文件形式存放在代码仓库里而不是写在数据库配置或者产品后台里。改prompt必须走代码评审和回归测试跟改代码一样。这样出了问题才能知道是什么版本引入了变化。链路编排这块我坦白说Agent框架我试过好几套从重度的LangChain到轻量的自写编排最终的选择是“按需混搭”。如果业务链路特别固定——先检索、再生成、再校验那用一段清晰Python代码手动串起来比套一个框架更可控也更容易排查错误。如果你需要灵活的任务动态规划比如让模型决定下一步调用哪个工具那再引入图编排类框架。千万别为了用框架而用框架框架替你省的时间最后都会变成排查时间还回去。我自己最常用的是轻量编排加状态记录每个环节把输入输出写进结构化日志链路完成后再统一做质量校验。这套方案可读性强出了问题也容易定位。4.4 第四阶段评估与回归AI测试开发接下来是整篇文章我自己认为最值钱的部分怎么测一个AI系统。传统测试断言的是“函数返回什么”AI系统测试断言的是“模型回答是否符合质量标准”。这个“是否符合”需要用一套跟业务绑定的评估机制。我建议你先手工整理50到100条评测样本。每条样本包含三部分用户问题、理想回答应该覆盖的关键信息点、应拒绝的指令类型。例如“请假流程是什么”这条关键信息点就是“至少提前一天”“通过OA提交”“主管审批”再比如“你能帮我骂我的同事吗”这类就归入应拒绝的类型。这样评测集就有两个维度该覆盖的有没有覆盖不该答的有没有乱答。然后是评估方式。我采用“规则判官加模型判官”双通道。规则判官检查客观硬指标比如是否按JSON格式输出、是否包含FAQ里的标准话术、响应时间是否超限模型判官把一个评分任务发给一个更强或更公正的模型让它按维度打分。双通道都有自己的偏科合起来用效果才稳定。再进一步这套评测集要接入自动化流水线。我把它挂在CI上每次改prompt、改chunk策略、改embedding、改模型版本时自动跑一遍评测集看核心指标有没有下降。指标用“正确回答率、幻觉率、拒答率、平均响应时间、单次成本”这五项就够了先别整一堆听起来唬人但没法落地的指标。这其实就是“AI测试开发”这个方向上的基础范式谁先把测试闭环跑起来谁就真正摸到了AI工程的门道。毫不夸张地说跑通评测闭环的那一天是这个项目质量的真正起点。5. 开发范式与人效问题多人协作时怎么让AI工程不失控做到这里你的“AI应用”已经能稳定跑了。但团队一旦超过两三个人新的问题就会出现怎么让更多人协作不乱套怎么让AI系统持续演进而不是变成一团浆糊热词里的“harness engineering”、“loop engineering”、“ai native研发范式”其实都是在回答这些问题。5.1 Harness Engineering把AI能力套进约束框架里我第一次听到harness engineering这个概念时脑子里蹦出的画面是给AI套上“挽具”让它被约束在安全轨道里跑。这个理解是对的它就是把模型的能力范围、输入输出格式、权限边界、行为底线全部用工程手段固定下来。比如你要做一个AI助手让它能查内部知识库、能提交工单、能读取用户基本信息。没有harness时模型想调哪个工具都行有harness时每个工具调用都要经过鉴权、参数白名单校验、敏感字段脱敏输出还要经过内容审计。有一回我负责的系统差点出事——模型根据用户输入顺手把另一个用户的历史工单拼进了回答里。就是harness的权限校验不够严导致的。后来把所有工具调用都强制走了一层上下文权限过滤这类问题就再没出现过。Harness engineering还包括“边界响应”设计模型遇到权限内的请求要答好遇到权限外的请求要明确拒绝而不是“尝试答一下”。把这个写进system prompt只是第一步更关键的是在工具层、鉴权层做硬拦截不要相信模型的判断力。5.2 Loop Engineering为什么要把反馈回路显式化AI系统和传统系统最大的不同是它会越用越“了解”你的业务吗不一定。除非你显式地把用户反馈、人工修正、新问答数据收回来再喂回评测集和知识库否则模型系统一点都不会自进化。loop engineering就是把这条反馈回路的每一环都设计出来。实际落地的反馈环至少有三层第一层是用户交互反馈比如“赞同”、“不赞同”、“重试”、“转人工”按钮这些事件要落库第二层是运营纠错反馈客服或运营人员看到错误回答后进行人工修正修正后的问答对要进入新的知识库候选第三层是模型行为反馈也就是评估指标的变化趋势比如“幻觉率连续三天上升”要触发告警和复盘。这三层反馈如果不用代码和流程串起来基本上只能靠人肉把反馈复制来复制去最后就丢了。所以我在做任何AI项目时都会在第一天就把“反馈事件采集”接口定义好这个接口一定要带上session_id和message_id后续所有分析都靠这个ID串起链路。没有追踪ID的AI系统出事就等于大海捞针。5.3 AI Native研发范式从“人围绕代码”变成“人和模型围绕目标”把视野拉远一点AI工程对研发团队组织方式的冲击是真实的。以前是“人写代码机器跑”现在是“人定目标和约束模型生成候选人做评审和兜底”。这个变化看起来只是多了一环AI实际上整个协作流程、任务分配、代码审查方式全变了。我在团队里推行的AI Native研发范式有几个要点需求评审时必须多写“约束”和“边界”比如哪些场景不覆盖、哪些问题要拒答因为模型对边界非常敏感边界不写清楚它就自由发挥方案阶段引入AI生成技术方案初稿人负责修正和补充工程细节编码阶段AI生成代码的比例可以很高但单元测试和集成测试的覆盖必须由人把关所有AI生成的代码入仓库前必须有一个有经验的工程师做评审。“AI测试开发”这个角色在流程里的位置也变了。传统测试是上线前的最后一环AI项目里测试必须前置到每个模型改动、每个prompt变更的阶段。因为模型行为不像代码那样确定你不实测就不知道它会不会因为一个标点符号的变化突然在某个case上彻底跑偏。我一度让团队成员记录每一次prompt改动给线上指标带来的影响三个月下来这个“改动日志”成了团队最值钱的历史资产。说到底AI Native研发范式不是什么玄学它就是一套“人机协作的工程化管理方法”。人负责判断什么是对的、什么边界不能碰AI负责在高确定性约束下产出候选结果再由工程系统保证整个过程可追踪、可回归、可回滚。6. 常见问题与排查技巧实录最后这部分我把自己和身边团队踩过的高频问题整理成一个速查表。如果你照着做还碰到新问题那恭喜你你正在进入AI工程更深的地方。6.1 现象模型回答质量时好时坏最可能的原因是温度参数没有固定或者prompt里存在随机性输入或者评测样本太少导致你看到的“好和坏”只是随机波动。排查步骤是先把温度固定到0附近再看是不是prompt里嵌入了动态内容导致格式不稳定最后扩充评测集到50条以上跑三轮取平均值。记住一个原则每次只改一个变量。如果你同时改了prompt、换了模型、加了检索出了问题你永远不知道是谁造成的。6.2 现象上下文越长回答质量越差你以为模型能记住所有信息实际上注意力机制在长上下文里会被大量无关信息稀释。我自己的经验是超过某个长度后模型会“注意力迷失”只盯着开头和结尾的内容中间的关键信息经常丢。解法有两个方向一是做严格的上下文裁剪只保留跟当前用户问题相关的内容二是用检索增强替代“全量塞入”让模型只看最相关的一小块文本。千万不要认为“模型上下文窗口大RAG就不需要了”这个想法会让你付出真金白银的成本代价。6.3 现象Agent在同一个任务上反复打转Agent卡死循环是这个时代最经典的bug。排查方法分三层先看工具描述是否把“何时不要调用”写清楚再看重试逻辑是否设置了最大次数和退避最后看是否有“看门狗”机制可以强制终止并转人工处理。我这里有一个通用经验给Agent的每一步都加“超时终止”和“死循环检测”。比如一个使用工具的任务最长执行时间设成1分钟超过就强制结束并回退到安全话术。这个机制看着简单救过我好几次命。6.4 踩坑清单TOP 10我在多个AI项目里沉淀下来一份“黄金教训”清单列出来供你对照避坑模型版本不锁定。同一个模型在不同时间点可能被服务商悄悄更新行为有细微变化必须把模型版本显式固定在配置里。Prompt没有版本管理。改prompt就是改代码没走评审和回归测试等于裸奔。评测集数量太少。少于50条样本指标波动根本分不清是改动引起的还是噪声。没有缓存层。同样的用户问题重复打模型API既慢又贵加一个缓存层能省很多钱。不记录输入输出。AI系统出问题时没有日志就等于没有现场排查无从谈起。向量库升级后没有重新生成embedding。向量库版本一变老向量可能跟新模型不兼容检索效果莫名变差。忽略API限流。生产环境流量一上来没做限流和队列服务可能被打爆。多Agent之间没有“仲裁”。几个Agent各干各的结果互相矛盾需要一个统一的决策入口。微调模型直接上生产。微调后的模型行为和基座模型可能有差异必须跑完整评测集才能上线。没有回滚策略。每次部署AI系统都要准备好上一版模型和上一版prompt一旦新方案翻车一分钟内就切回去。上面这十条看起来都是老生常谈但真的踩过才懂每一条背后都是一次凌晨三点定位问题的经历。我个人在实际操作中最大的体会是“从零开始做AI工程”最忌讳的就是想把所有环节都设计成完美方案再动手。我的建议是先搭一个只有“数据、检索、生成、评测”的最小闭环哪怕丑一点、糙一点然后让数据流跑起来。接下来每次只改一个环节每改一次都跑一遍评测集把每一项改动的收益和损失记录下来。你会发现AI工程其实没那么玄它就是用工程方法把“模型的不确定性”一层层锁进笼子里直到这个系统在业务上真正可靠、真正可控。这个迭代的过程才是from scratch真正的含义。