在AI圈子里泡了几年我越来越觉得一个残酷的事实会调API的人和会做AI工程的人完全是两种物种。前者是“用户”后者是“构建者”。标题里的ai-engineering-from-scratch说的就是从零开始、不依赖现成框架、亲手把AI能力落地成真正可用的系统。这个过程不浪漫甚至有点枯燥但它是区分“玩具Demo”和“生产级应用”的关键分水岭。这篇文章不是一篇“AI科普”而是一份从业者的实操地图。我会从为什么需要AI工程思维讲起拆解从基础学习到Agent、RAG、模型微调、部署评估的完整路径中间穿插我踩过的坑和验证过的方案。如果你正在学Prompt Engineering或者已经能跑通几个AI Demo、但不知道下一步怎么走这篇文章就是写给你的。1. AI工程到底在解决什么问题从“能跑”到“能用”的距离1.1 为什么单纯的Prompt Engineering不够用了最近一两年“Prompt Engineering”这个概念被炒得很热好像只要会写提示词就能造出AI应用。但真正在业务里跑过AI的人都知道提示词只是AI工程的冰山一角。你可以在提示词里让模型扮演客服、翻译、代码审查员但只要跳出单次问答的范畴问题就全来了。举个例子做一个“简历问答助手”用户上传一份PDF简历然后向AI提问“这个候选人做过几个项目”。你写一个很长的提示词把PDF内容粘进上下文让模型回答。单次测试时效果还凑合但你马上会遇到几个现实问题PDF动辄几十页直接塞进上下文Token消耗大、响应慢还可能超出上下文窗口。用户的提问方式千奇百怪同一个意思换一种说法模型回答质量可能天差地别。几十个人同时用每次请求都调用大模型API成本怎么控制模型今天回答得好明天换一个版本或调一下参数回答风格就变了。这些问题没有一个能靠“写提示词”解决。它们涉及信息抽取、存储索引、检索策略、并发控制、缓存、评估反馈——这就是AI工程的范畴。你可以把Prompt Engineering理解为“跟AI对话的艺术”而AI Engineering是“把AI对话变成稳定业务服务的一切手段”。前者是文科题后者是工程题。1.2 AI工程的知识体系全景比你想的更“杂”我梳理过一张AI工程的能力地图核心有五块第一块是基础理论。不用成为数学博士但线性代数、概率论、机器学习基础得过一遍。你需要知道“嵌入向量”到底在算什么“注意力机制”为什么能抓住长距离依赖。不懂这些后面调参、查问题就像隔着一层毛玻璃。第二块是模型能力认知。现在的大模型各有各的脾气有的擅长推理有的擅长对话有的中文好有的代码强。知道什么任务选什么模型是工程判断力的起点。同时要理解温度、Top-P、频率惩罚这些采样参数对输出的影响它们直接决定你的应用是“稳定输出”还是“随机发挥”。第三块是应用架构设计。也就是把模型嵌进业务系统的那层胶水。包括怎么设计Agent的工作流怎么用RAG检索增强生成补足模型的知识盲区怎么管理多轮对话的上下文怎么规划多模型的协作。这块是纯工程问题跟传统后端开发高度重合。第四块是数据与评估。AI工程最大的隐藏成本不是训练是评估。你怎么知道一个改动是变好还是变坏这需要建立评估集、设计评测指标、跑回归测试。很多团队在数据和评估上投入不够导致AI应用越迭代越不稳。第五块是部署运营。模型推理的延迟、并发、缓存、降级策略日志和可观测性成本监控安全合规。这一块往往决定项目能不能从Demo走到生产环境。这五块覆盖了“思路—实验—开发—上线—维护”的完整生命周期。如果你只想玩一玩学个Prompt就够想靠AI吃饭这五块绕不开。2. 从零起步的路线规划先把四块地基打好2.1 数学和Python不需要精通但必须知道“在算什么”我知道很多人看到数学就头大所以先说结论除非你要从零训练模型否则不需要学完整个数学系。但有三样东西无法回避向量、矩阵、概率。向量和矩阵是AI的基本单位。文字会被转成向量图像会被转成矩阵位置编码本质是正弦波函数的组合。理解向量的余弦相似度之后你就明白RAG系统里“语义相近”是怎么算出来的。我在面试实习生时经常问一个问题“如果我把100个无关的文本向量放在一起它们两两之间的余弦相似度大概在什么范围”能回答出“趋近于0但不为0”的人说明真的理解了向量空间。概率论里重点抓条件概率和贝叶斯思维。大模型本质就是一个“给前文预测后文”的概率模型你调温度参数就是在调节概率分布的“锐利程度”。温度调高低概率词被选中的机会变大所以回答更多样但也更容易跑偏。Python的话熟练掌握基础语法、Pandas处理表格、Requests调API、Json解析数据就够了。如果你要用到PyTorch或Transformers库看模型结构再补一点NumPy和张量操作。我的经验是别花几个月系统学完再动手用任务倒逼学习效率高得多——比如亲手调一次OpenAI或DeepSeek的API把返回的JSON解析成结构化数据比刷十遍语法书都管用。2.2 跑通完整链路从API调用到第一个对话机器人学习编程的第一课是“Hello World”学习AI工程的第一课是“跑通一次完整的模型调用链路”。不要满足于在网页上跟ChatGPT聊天那只是“用AI”不是“构建AI”。什么是完整链路用一个脚本调API输入一段文本拿到结构化输出然后把它接到一个极简的Web界面上。我自己带新手时最常用的一个入门任务是这样的写一个Python脚本调用任意一个大模型API输入“把这段话翻译成英文今天天气不错”然后打印出返回结果。完成之后加一个小改动让模型以JSON格式返回结果字段名是translation和confidence_score再让Python脚本解析这个JSON并只输出translation字段。这个小任务看起来简单但里面藏着一个核心工程思维不要让模型输出自由文本而是约束它输出结构化数据。这是AI工程的基本功。自由文本人类看着方便但程序没法稳定处理JSON则可以直接进入业务逻辑。从入门第一天就养成“结构化输出”的习惯会帮你少走很多弯路。2.3 把“模型”当组件而不是“答案机”工程思维第一步很多新手最常见的错觉是把大模型当成“什么都知道的答案机”问什么都能答。但工程思维要求你把模型当成一个概率组件——它接收输入按概率分布吐出Token中间充满不确定性。这个认知转变非常重要。如果你认为模型是“答案机”遇到回答错误时你会骂它明明告诉你了为什么还错如果你认为模型是“概率组件”你会反思我的输入是否提供了足够信息约束是否明确输出的概率分布是不是被采样参数推得太散了后一种思维方式才是排查AI问题该有的姿势。打个比方开关只有“开”和“关”这是电路思维大模型更像水龙头水流大小取决于你拧多紧、水压多高、管道多粗。AI工程的核心能力就是学会控制这“水流”——用Prompt约束方向用参数控制随机性用外部工具兜底事实性让模型的输出尽量稳定在你想要的那个区间。这不是玄学是可操作的系统方法论。3. 核心工程能力的实战拆解Prompt、Agent与RAG3.1 Prompt Engineering的系统方法从“碰运气”到“可复用”Prompt Engineering之所以能独立成一个方向是因为它有了一套相对成熟的方法论不是玄学更不是“话术”。我用下来最核心的套路是**“角色任务约束示例输出格式”五段式**。先说角色。给模型一个明确定位它就能调动对应的行为模式。你说“你是资深Python工程师请审查代码”和直接说“看看这段代码有问题吗”质量完全不同。因为角色隐含了知识范围和回应风格。然后是任务陈述。要具体、动词导向。“总结这篇文章”是模糊任务“从这篇文章中提取3个核心论点每个论点点用不超过50字概括并按重要程度排序输出”就是清晰任务。清晰任务才能得到稳定输出。接着是约束。能做什么、不能做什么、长度多少、不要编造什么全部写清楚。比如“如果简历信息中没有提到项目成果请回答‘未提供相关信息’不要自行推测”能极大减少模型的幻觉。示例Few-shot是最有效的控制手段。给一个输入输出对模型就能模仿那个格式。我有一次让模型从发票中抽取字段试了很多提示词都抽不准后来加了两条手工标注的示例准确率立刻从70%跳到95%。这就是示例的力量。输出格式约束上面说过了JSON是首选。如果平台支持JSON Schema直接用不支持的在提示词里写清楚字段名和类型。我自己常用的一个模板长这样你是[角色]。你的任务是[具体任务描述]。 要求 - [约束1] - [约束2] - 如果信息不足回答[兜底话术]不要编造。 以下是示例 输入[示例输入] 输出[示例输出] 请对下面的输入执行任务并按[输出格式]返回 输入[真实输入]这个模板看似笨但极其可靠。我的经验是稳定优先于惊艳。AI应用上线之后宁可持续产出70分的稳定结果也不要今天95分明天40分。3.2 Agent设计当模型开始调用工具系统才真正“干活”Agent是最近两年AI工程最热的方向。为什么热因为单次问答是“嘴皮子功夫”而Agent是“手脚功夫”——你能让模型自主决定调用哪些工具、执行哪些动作模型从“对话者”变成了“执行者”。一个最小可用的Agent系统包含三部分模型大脑、工具手脚、运行循环决策机制。以最常见的ReAct模式为例运行循环是模型观察当前状态决定下一步动作是调用工具还是直接回答执行动作后拿到观察结果把结果放回上下文继续推理直到模型认为任务完成。构造一个例子你想做一个“邮件自动分类回复Agent”。给模型三个工具read_email()、classify_email()、generate_reply()。模型收到新邮件后会自己决定先读邮件再分类是咨询、投诉还是合作最后按分类生成回复初稿。整个过程你写一个循环把模型和工具串起来模型在循环里决定每一步干什么。这里面最有挑战的是工具调用规范。你得让模型知道有哪些工具、每个工具接收什么参数、何时该用哪个。有效做法是把工具列表写成JSON Schema让模型生成符合Schema的调用请求。现在主流模型都原生支持Function Calling工程上省了很多事。踩过的坑必须说Agent的最大风险是失控迭代。模型在一个错误决策上反复循环每次调用都花钱、花时间。我在做一个Python代码修复Agent时模型拿着一个编译错误连续三次执意修改同一行代码越改越错。后来我在循环里加了两道防线最大迭代次数限制默认5次和止损条件连续两次同类操作未改变状态就直接放弃这才止住。3.3 RAG实战给模型外挂“知识库”但不只是“塞文本”RAG检索增强生成是目前企业落地的最大热门。逻辑很简单LLM的训练数据有截止日期也不包含企业内部资料。与其重新训练模型不如在问答时先从知识库检索相关内容把结果塞进上下文让模型“带着资料作答”。原理简单做起来满身是坑。一个标准的RAG流程是文档切分 → 向量化 → 存储索引 → 检索 → 重排 → 注入提示词 → 生成回答。任何一环出问题回答质量都会崩。文档切分是第一个坑。切得太碎语义断裂检索回来的片段看不懂切得太长噪声太多检索精度下降。做过几个实战项目后我习惯用1000到1500字的句子级切分重叠200字左右既保留上下文又控制Token。结构化的文档PDF报告、表格优先按章节切不硬切。向量化注意模型选择。中文环境下开源推荐BAAI/bge-m3效果扎实对中文语义理解比通用模型好很多而且兼容英文。向量维度高一点没关系但要跟检索库容量匹配。检索环节很多人默认是“向量相似度召回”。但实测下来混合检索关键词BM25向量检索几乎总是优于纯向量检索。为什么向量检索擅长“语义相近”但专有名词、人名、编号、型号这类精确匹配BM25更可靠。比如用户搜“CCD-971”纯向量检索可能召回“传感器型号”却漏了原文里的具体编号BM25能精准命中。把两路结果做融合或者重排召回质量会有肉眼可见的提升。最后在生成提示词里要把“检索到的资料”和“无法回答的处理方式”写明白。我最常用的一段话是根据以下资料回答问题。如果资料中没有足够信息回答问题请直接回复“资料中未找到相关信息”不要自行推测。资料内容...这句“不要自行推测”能显著压住模型幻觉。RAG系统里80%的错误回答不是因为模型笨而是检索返回了一堆不相关的内容模型被带偏了。3.4 多模态与多模型协作好的架构是让每个模型干擅长的事单一模型处理所有任务是理想状态实际工程里很少这么做。多模型协作越来越常见ARCHITECTURE上记住一句话让最强的模型做决策让最合适的模型做具体执行。做一个图片转结构化信息的应用你可以让多模态模型如GPT-4V或者开源的Qwen-VL做OCR和视觉理解把图片内容转成文字和结构化描述然后用一个便宜快速的文本模型做字段抽取、格式整理最后用一个大参数模型做质量的终检和修正。视觉“看”小模型“整理”大模型“把关”。成本比全程调用大模型低得多准确率比只用小模型高得多。在做这些实践时我的多年经验是不要迷信“一个模型通吃”要把任务拆开给每个环节选最合适的模型并用清晰的接口定义把它们串成流水线。接口就是输入输出格式只要是JSON环节之间就能无缝替换——今天用这个模型明天觉得效果不好换成另一个只要接口不变改动成本就极低。这就是工程架构的红利。4. 亲手搭一个最小可用的AI应用招聘问答Agent全流程4.1 需求拆解与整体设计纸上谈兵再多不如亲手做一个。下面是我带新手做“招聘问答Agent”的完整过程你可以直接照着做一遍。需求只有两条但很典型用户上传一份候选人简历PDF或TXT系统从中抽取结构化信息姓名、学历、工作年限、技术栈、项目经历。用户用自然语言提问Agent基于这份简历回答例如“这个人用过哪些编程语言”“他最近一段工作干了什么”这个需求的工程价值在于简历内容需要抽取结构化问答应基于简历而非模型内置知识需要多轮对话。正好覆盖信息抽取、RAG、多轮对话三个核心能力。整体设计分三条线抽取服务简历转结构化JSON、问答服务RAG检索生成回答、对话管理多轮上下文处理。技术选型上模型用DeepSeek或通义千问的API都行成本低向量库直接用Chroma或FAISS这种轻量方案入门阶段不碰Elasticsearch。4.2 关键代码实现与参数选择第一步简历信息抽取。核心技巧上面说过约束模型输出JSON。Python脚本核心就十几行import json from openai import OpenAI client OpenAI(api_keyyour-api-key, base_urlhttps://api.deepseek.com) def extract_resume(text): prompt f 你是招聘系统信息抽取模块。请从下面的简历文本中提取信息并按给定的JSON格式返回不要输出除JSON外的任何内容 {{ name: string or null, education: {{school: string or null, degree: string or null}}, work_years: number or null, skills: [string], projects: [{{name: string, description: string, highlights: [string]}}] }} 如果简历中不存在某字段填null不要编造。 简历文本 {text[:6000]} resp client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: prompt}], temperature0.1, response_format{type: json_object} ) return json.loads(resp.choices[0].message.content)这段代码里有三个细节值得注意。第一是text[:6000]简历太长时截断——不是偷懒而是防止超Token窗口和降低乱抽取的概率。实践中6000字符覆盖了90%的简历。第二是temperature0.1信息抽取任务要的是稳定和忠实不是创意温度必须压低。第三是response_format{type: json_object}强制模型输出合法JSON从源头消灭解析报错。第二步建立向量索引。把简历按段落切块向量化后存入Chromaimport chromadb from sentence_transformers import SentenceTransformer # 中文/多语言嵌入模型 embedder SentenceTransformer(BAAI/bge-m3) # 切块按段落切每块不超过600字符 chunks [para for para in resume_text.split(\n\n) if len(para.strip()) 20] vectors embedder.encode(chunks).tolist() # 存入chroma首次运行需pip install chromadb client_db chromadb.Client() collection client_db.create_collection(resume_kb) collection.add( documentschunks, embeddingsvectors, ids[fchunk{i} for i in range(len(chunks))] )这里有一个常见坑嵌入模型和大模型最好分开选。BGE负责“理解语义生成向量”DeepSeek负责“阅读资料回答问题”各司其职。千万别用一个大模型又做嵌入又做生成成本高且效果不一定好。第三步问答服务。查向量库取前三相关的片段拼进提示词def ask_question(question, history): qvec embedder.encode([question]) results collection.query(query_embeddingsqvec, n_results3) context \n\n.join(results[documents][0]) history_text for msg in history[-4:]: history_text f{用户 if msg[role]user else 助手}: {msg[content]}\n prompt f你是候选人简历问答助手。根据以下简历片段回答问题。 简历片段 {context} 对话历史 {history_text} 用户的当前问题{question} 要求 - 只用简历片段回答不要使用外部知识推测。 - 如果片段中没有信息回复“简历中未包含相关信息”。 resp client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: prompt}], temperature0.3 ) return resp.choices[0].message.contentn_results3和history[-4:]是我调过多次的默认值。Top-K太小召回不够Top-K太大噪声污染生成答案。三轮左右的对话历史在上下文信息量和Token消耗之间最均衡。这些数字看着随意但都是实测后沉淀下来的经验值。4.3 效果不足时的优化路径做完第一版你大概率会发现简历信息抽取有漏项问答时答案有时不精确。别急着调Prompt按这套顺序排查90%的问题能解先看检索是否正确。如果检索回来的前三条片段本身都不相关生成环节再填多少提示词都白搭。用打印的方式直接看results[documents]返回的内容对比问题跟片段是否语义相关。不相关就调整切块策略或换嵌入模型。再看上下文是否完整。简历里的“2021至2023年在XX公司担任Java工程师”可能被切成了两半上半截在chunk1下半截在chunk2单独检索到哪块都缺信息。解决方法是切块时增加重叠或者把抽取出来的结构化JSON也一并注入上下文。最后修正约束提示词。早期版本我让模型“尽量回答”结果模型看到简历没写薪资就自己编了个30K。后来改成“如果片段中没有明确信息必须回复简历中未包含相关信息”幻觉才止住。AI工程里“不做”往往比“要做”更重要。5. 常见问题与排查技巧实录遇到过的问题希望你别再踩5.1 输出魔改与不稳定别忽略温度与格式约束新手最常遇到的现象同样的Prompt跑10次有8次好用2次格式错乱或跑题。大概率原因有两个温度太高和输出约束太弱。所有需要稳定输出的任务温度控制在0到0.3之间。需要适度多样性又不失控的场景可以试试温度0.7同时配合Top-P降到0.8以下。**。0.1是抽取任务0.3是问答任务0.7是创意文案1.0以上慎用——那基本是随机发疯区间。这是我认为最有用的控制技巧一定要记下来。输出约束方面能做三件事就都做API支持response_format就用JSON模式不支持则在提示词里写“只输出JSON不要输出任何其他内容”代码层面加一层解析异常兜底解析失败就重试一次。重试后还是失败记录日志并返回“系统繁忙”不要将裸错误抛给用户。5.2 Token和上下文窗口你的钱是怎么悄悄烧掉的Token是AI应用的账单。上下文越长每次调用越贵而且答案质量不一定更好——模型注意力会被大量无关上下文稀释。实际项目中控制Token的方法我总结了三条聊天历史只保留最近几轮重要的信息抽成“事实摘要”而不是保留原始对话检索片段按相关度截断超过1500字符的片段不用用结构化中间结果替代原始长文本比如简历抽取一轮后后续问答都基于JSON抽取结果进行不再重复读取全文。我自己做的招聘Agent第一版每次对话平均消耗4000 Token优化后降到800。这个差距放在单个用户上不明显放在日请求量上万的生产环境里就是一个月几万块的差别。成本思维是AI工程师和生产环境中必须考量的核心能力。5.3 系统稳定性与安全边界用功能禁区和数据清洗管理风险最后聊一个容易被忽视但极端重要的话题AI系统的安全边界。很多团队把模型当成“什么都可以说”的自由体上线之后直接放出API结果就是模型被各种越狱。做AI工程要建立两道防线。第一道在能力边界按需求限定任务范围把“开放问答”改造成“基于资料库的受限问答”不知道的就答不知道不自由发挥。第二道在输入边界用户提交的内容必须做基本的数据清洗和敏感信息识别危险代码片段、恶意指令这类内容要有机制识别和阻断Prompt注入和CSRF是真实存在的攻击方式。我在做浏览器侧AI组件时开头设计了一个“全局无障碍”的功能想着可以让AI读取并操作页面上的任何元素。但后面做安全评审时发现这种能力一旦被恶意网页利用AI会被引导读取用户在不同网站的敏感内容。我最终还是把“全局无障碍”收敛成了“仅允许用户主动指定元素”才把风险挡在外面。这个经历给了我特别深的教训实现功能的工程师很多但能管住功能边界的工程师才真正稀缺。6. 从“学完所有再动手”到“边做边学”我的最后一点体会我见过太多人倒在“准备阶段”数学没学完不敢动手框架没看全不敢写代码模型没研究透不敢做Agent。但AI工程这行最有效的学习方式永远是带着真实问题强行做出一个能跑的东西。你不需要在第一天就理解Transformer的所有细节但你需要亲手让一个API返回你想要的JSON然后把那个JSON变成界面上的一个答案。工具会过时模型会迭代框架会换代但工程方法论不会——结构化输出、缓存设计、错误处理、成本控制、安全边界、评估反馈这些东西从去年到明年、从这家公司到那家公司底层逻辑几乎不变。这才是ai-engineering-from-scratch真正值得花时间的地方。如果你看完这篇文章想立刻动手我给你的任务很简单拿一份真实的简历用上文的思路搭一个问答Agent然后故意制造三个错误——让他回答简历里没写的信息、连续追问同一话题、上传格式混乱的PDF。去观察它在什么情况下会崩、怎么崩、崩了之后怎么补救。把这些都记录下来你就已经一只脚踏进AI工程的大门了。至于后面的路Agent编排、微调、推理加速、评估体系每一样都是深水区但至少你已经在正确的方向上了。