1. 项目概述当AI不再只是“调接口”工程化才是真正的分水岭AI engineering这个title最近一年越来越频繁地出现在技术社区的讨论里各大招聘网站上也挂出了不少相关岗位。但如果你以为它就是把大模型API接一接、把Prompt调一调那你大概率还没摸到这门技术的核心。我在经历了几个从零开始的AI项目之后最大的感受是能把模型跑通的人很多能把它稳定、安全、可维护地跑在生产环境里的人才是真正稀缺的。这个“ai-engineering-from-scratch”项目本质上是建立一套完整的AI工程能力体系——从最基础的模型原理理解到Prompt Engineering、RAG检索增强生成、Agent架构设计、评测体系搭建、甚至多AI协作的落地实践每一步都需要系统性的方法论而不能靠零散的“试错式开发”。这篇博文我希望能把这两年积累的经验拆开揉碎讲清楚AI工程一条龙的知识地图也给正在这条路上探索的朋友一份可复用的参考。无论你是刚开始接触AI开发的软件工程师还是已经在做AI产品但总觉得差点意思的开发者这篇文章都有你能带走的东西。我见过太多团队在AI项目上的典型困境模型选型拍脑袋、Gound Truth正确性评估基准缺失、Prompt改一次全网回归测一遍、Agent链条稍长就直接失控。这些问题表面上都是技术问题但骨子里都是工程问题。真正的AI工程不是算法的深奥程度而是能否把不确定性量化、把变化控制住、把复杂度管理好。这篇文章会从为什么、是什么、怎么做三个维度把整套思路展开给你看。2. 内容整体设计与思路拆解2.1 AI工程的核心矛盾与解决思路第一个问题AI工程和传统软件工程到底有什么本质区别我自己的答案是传统软件工程是在确定性的世界里做设计而AI工程是在不确定性世界里做治理。你的代码逻辑是确定的但模型的输出不是的你的接口返回结构是固定的但模型对不同输入的响应质量是有波动的。这种本质差异决定了你不能用老一套的思维来管理AI系统。举个例子。传统开发里你写一个函数输入订单金额输出税额逻辑是死板的测试用例一写就完事。但在AI系统里你给模型一段用户问题它返回的答案可能今天正确、明天句式就变了你稍微改了一个Prompt措辞可能某个很偏门的用例反而变好了。这不是说AI不可靠而是说我们需要一套适应这种不确定性的工程框架。我在这个项目里设计的整体思路是三段式协同架构——基础层、能力层、应用层。基础层就是模型本身和部署环境。做工程的人一定要明白一个道理模型选型是你所有上层建筑的地基。你现在用GPT-4效果好不代表你以后都要用它你现在用某个开源模型推理慢不代表你换个量化版本就不行。所以基础层的核心工作是建立模型选型的评估基准。能力层是整个架构的枢纽包含Prompt模板库、知识库接入、工具调用框架、记忆管理模块、评测系统。这一层解决的问题是让模型在我自己的业务场景里能够稳定地输出高质量的结果。能力层的设计质量直接决定了最终应用的智能化天花板。应用层则是你面向用户呈现的形态可能是聊天机器人、Copilot、自动化流程甚至是一个多AI协作的Agent系统。应用层的关键不是模型而是产品体验和容错设计。要知道用户能接受传统软件偶发卡顿但对AI的幻觉容忍度极低这就倒逼工程上必须做前置校验和降级方案。这套架构的核心优势在于松耦合、可替换。模型可以换Prompt可以调知识库可以更新而应用层不需要重构。我早期做AI项目时最大的教训就是把模型API调用和业务逻辑死死塞在一起结果每换一次模型都要牵一发动全身。后来按照这种分层思路重构替换模型的工作量从几天缩短到了半天。2.2 Prompt Engineering的系统化方法论很多人一听到Prompt Engineering就觉得是写提示词。如果只是写几句话那确实不需要专门开一个章节来讲。但真正的Prompt Engineering是在做一套可维护的、针对特定场景的交互协议。我在这个项目里使用的核心方法论是CO-STAR框架——Context上下文、Objective目标、Style风格、Tone语气、Audience受众、Response Format回复格式六个维度的结构化对齐。别小看这个框架它最大的价值不是让你的Prompt更花哨而是让Prompt的每个部分都有了为什么而存在的明确目的这为后续的调试和迭代提供了切入口。举个例子。我曾经帮一个教育团队优化一个作文批改系统的Prompt。一开始他们给的指令特别简单批改学生的作文给出建议。模型输出的结果泛泛而谈什么中心思想不够突出、内容不够丰富这种反馈对学生来说完全没用。后来用CO-STAR框架重构Context部分明确了这是给小学六年级学生的周记 Objective从批改改成识别3个最具体可执行的改进点 Style要求用鼓励性的口吻 Response Format强制结构化——每个改进点必须指出原文对应的句子、问题类型、改进示例。结果效果立竿见影。模型给出的反馈从内容不够丰富变成了你写今天很开心这句话时可以具体描写一下开心的原因和表现比如我建议改成今天数学考了95分同桌的李明跑过来拍着我的肩膀说这次进步真大。两版Prompt的差距本质上是工程化思维和玄学思维的差距。对于Prompt模板的版本管理我强烈建议用Git来控制。每一条Prompt的改动都要像代码改动一样记录在案。我有一个小习惯每次迭代Prompt后都会在commit message里写上改成X格式目的是解决Y问题效果是Z指标提升了多少。这样做了半年之后你会拥有一套非常宝贵的实验记录它会告诉你哪些措辞变化真正有效哪些只是自我感觉良好。2.3 架构选型背后的决策逻辑这个项目的第二个核心决策是构建模型无关Model Agnostic的能力中间层。如果你现在去看市面上很多成熟的AI开发框架它们都强调一件事不要让业务代码直接依赖某一个具体模型的SDK。我深以为然。为什么这么强调模型无关因为AI领域的发展速度太恐怖了。今天你用的最强模型三个月后可能就被另一个开源模型在同等参数量下超越了。如果你把所有业务逻辑都耦合在某一个模型平台上转换成本极高。反向来看如果你在架构上预留了抽象层那模型切换就变成了一次改配置而非改代码。这个抽象层在设计上需要三个组件 第一统一的调用接口。不管底层是OpenAI协议、Anthropic协议、还是本地部署的模型对上层都暴露一致的请求-响应格式。 第二统一的上下文管理。对话历史、知识库检索结果、工具调用记录都通过标准化的Context对象传递。 第三统一的输出校验。模型的输出进入业务逻辑之前先经过格式校验、内容校验、敏感信息检查三道关卡。我接触过一个做法律咨询AI的团队他们在早期没有做模型无关设计结果因为成本问题要从某商业模型厂商切换到开源模型整整折腾了三周——大量业务代码都在直接拼接模型响应的结构改一处错一处。后来切到抽象层设计之后再换模型两个小时搞定剩下时间全花在回归评测上。这个案例非常典型工程架构的早期投入会在后续的每一次迭代中加倍还给你。除了模型无关我在架构上还坚持了一个原则能不用Agent就不用Agent。这不是说Agent不好而是说Agent带来了额外的自由度和随之而来的不确定性。单轮问答场景用RAGPrompt就能解决何必把Tool Calling和多轮规划引入进来增加复杂度只有在任务确实需要多步骤推理、动态决策的场景才值得引入Agent架构。工程能力强的团队不是会用最炫技术的团队而是知道在什么场景用什么技术火候最合适的团队。3. 核心细节解析与实操要点3.1 RAG系统的搭建与优化全流程RAGRetrieval-Augmented Generation是目前AI工程里落地价值最高、应用范围最广的模式。简单来说就是让模型在回答问题之前先从你的知识库里检索相关信息作为参考再基于这些参考生成答案。这样既能利用大模型的通用推理能力又能把答案约束在你自己业务的知识边界内。RAG系统的搭建传统上分为索引、检索、生成三个环节。但我在项目里把整个流程拆得更细分成了七个可独立优化的节点文档加载、文本切分、向量化、索引构建、查询改写、检索融合、生成增强。讲几个踩过坑的细节。文档切分是最容易被低估的一环。很多人拿一个PDF就直接整篇扔给切分器按固定字符数切开就算完。这其实大错特错。我处理过大量技术手册最好的切分策略是结构化感知切分——先把文档解析成标题树然后保证每个切分块尽量完整地包含语义单元比如一个章节、一个完整的说明步骤而不是从句子中间切断。为什么要这么做因为模型阅读一个半截句子做出来的摘要和你给它一整段完整逻辑链条做出来的摘要质量差距是显而易见的。如果你用的切分工具能支持markdown标题识别一定优先用这个功能。向量化这个环节核心是Embedding模型的选择。我要给你一个忠告不要盲从任何Embedding模型的榜单分数一定要在自己的语料上测试。榜单上的平均分数是综合多个数据集的结果而你的业务文本有自己的领域特殊性。我试过一次很有意思的实验在两个Embedding模型上跑我们内部的故障排查文档检索A模型在公开基准上比B模型高了两个点但在我们的实际业务数据集上B模型检索准确率反而高出12%。所以一切以你的验证集为准。检索环节很多人只做向量相似度检索这个也不够。成熟的RAG系统应该做混合检索——向量检索负责捕捉语义BM25这类基于关键词的检索则负责精确匹配。为什么要混合因为用户的查询里经常包含专业术语、编号、型号等精确信号这些都是向量检索会模糊化处理的东西。我建议的比例是向量检索结果、关键词检索结果做加权融合权重通过一次小规模的离线实验来确定通常2:1到3:1之间的区间效果比较稳妥。3.2 Agent架构设计与Tool Calling的工程陷阱Agent系统是AI工程皇冠上的明珠也是最多翻车现场的重灾区。所谓Agent就是让模型具备规划-行动-观察-再规划的循环能力它能够调用外部工具、处理复杂任务。但工程视角下的Agent核心还是可控性。我在项目里做的Agent架构是双循环设计短循环是执行器负责单步工具调用长循环是规划器负责多步骤任务的分解和决策。这种拆分的好处在于短循环追求速度和失败恢复长循环追求任务覆盖度和步骤正确性。两者用不同的策略管理——短循环用白名单工具集长循环用状态机来跟踪任务进度。Tool Calling的工程陷阱最常见的有这么几类。第一类是过度工具化。我在早期Demo中给Agent挂了七八个不相关的工具结果模型在简单问题上反而纠结选哪个工具耗时成倍增加。后来做了工具集的动态路由——根据用户问题意图先经过一个轻量级的意图分类器只注入相关的3到4个工具定义准确率和速度都显著提升。第二类是参数传递的脏数据。模型生成的工具参数是字符串格式但后端接口需要结构化数据。你必须要有一层严格的结构化校验比如使用JSON Schema对模型输出进行验证。千万别把模型给的参数直接拼接进你的内部API请求这是很多数据安全事故的源头。第三类是Agent死循环。模型在一个错误的结果之上反复重试每次都以为自己在推进任务实际上能量全耗在无效循环里。我给Agent设计了两个保险丝最大步数限制通常5~8步和重复动作检测如果连续两步调用了相同工具且参数一致直接中断并请求用户澄清。最后提一个Agent评测的问题。Agent系统的非线性决策路径导致它的评测比普通问答复杂得多。我采用的方案是两级评测第一级单步工具调用正确率第二级任务最终完成率。第一级的问题在于精细定位第二级的问题是宏观把控。这两级指标一起看你才能知道一个Agent系统到底行不行。3.3 评测体系没有度量就没有优化如果让我选择整个AI工程里最重要但也最容易敷衍的部分我会说是评测体系的建设。绝大多数团队做AI项目的失败路径都是上线第一天效果惊艳上线一星期开始频繁出错上线一个月彻底失控。这背后的根源就是没有一套自动化、可持续的评测系统来监控每一次迭代的质量。评测体系的设计我从三个维度来展开。数据层面建设高质量的评测集是根基。评测集要怎么来我总结了三个来源真实用户反馈、基于业务规则的合成数据、金标人工标注。真实用户反馈最宝贵但对冷启动项目来说样本太少合成数据效率高但要防偏金标标注成本高但质量最稳。我的建议是三管齐下按照6:2:2的比例构建初版评测集然后逐月用线上数据回流扩充。指标层面要区分宏观和微观。宏观指标包括答案准确率、拒绝率应该拒绝回答时是否正确拒绝、幻觉率答案是否忠实于检索内容。微观指标则和你的具体业务相关比如电商场景的SKU命中率、客服场景的解决率。这里我非常推荐使用人工评测辅助体系来实现小样本高置信的判断——每个版本迭代抽300到500条样本让人工标注配合LLM-as-a-Judge模式就能在没有大量人工的前提下有效控制质量底线。流程层面必须把评测嵌入到CI/CD流水线里。每次Prompt改动、模型更新、知识库更新都自动触发一轮回归评测评测结果决定是否允许发版。这个流程的落地让AI系统的迭代从盲人摸象变成了科学实验。4. 实操过程与核心环节实现4.1 从零搭建一个本地知识问答系统的全记录理论知识讲了这么多接下来走一遍实操。我以搭建一个内部技术文档问答系统为例整个过程完全可以在本地完成核心组件包括一个中等规模的开源模型、一个向量数据库、一个Embedding模型、和一套编排代码。第一步是模型选择。如果你不想过于依赖商业API我建议用Open Source模型加量化部署的模式。模型参数量根据你的硬件条件来定24GB显存以上可以尝试14B级别的量化版本16GB左右的显存则选7B或8B级别更稳妥。选择模型的判断标准是在你的垂直领域语料上测试过效果而不是看它综合榜单的名次。第二步是知识库准备。把内部的PDF、Markdown、Word文档统一转成Markdown格式这一步我用脚本做了批量处理。然后根据既定的结构化感知切分策略把文档切分为每条512个字左右的文本块相邻块之间保留少量重叠避免上下文被硬生生截断。第三步是向量化入库。我使用开源的Embedding模型来批量生成向量然后存进向量数据库。这一步要注意的是批量大小Batch Size不要设太小不然Embedding过程会非常慢同时做好元数据管理每个向量要绑定文档来源、章节位置、更新时间这是以后做结果溯源的基础。第四步是写检索与生成逻辑。核心调用链是用户问题输入后先做查询改写把口语化问题转成更规范的检索语句接着混合检索Top-K文档块通常K取4到6比较合适然后把文档块和大语言模型拼接成Prompt最后调用大模型生成最终答案。第五步是接入评测。我为这个系统准备了200条评测用例覆盖技术问答、操作指引、故障排查等场景。每次改Prompt跑一遍评测重点盯准确率和幻觉率两个指标。整个实操过程中我至今后悔没在一开始就做的事情是把知识更新流程自动化。原来知识库更新全靠手动上传文档直到有一次把一份过期的手册误传上去导致输出了一段时间的错误信息才下决心构建知识解析、切分、入库、QA校验的全自动Pipeline。现在每次知识更新都会自动生成一份变更摘要和验证结果这件事千万不要省。4.2 多AI协作系统的可行性验证实验接下来这个实验想法比较前沿——多AI协作。简单来说就是让多个具备不同专长定位的AI可以是多个模型、也可以是同模型的不同角色配置协同完成一个复杂任务。听起来很高大上但工程落地的第一步其实是验证协作产生增量价值。我设计了一个验证实验一个AI负责写代码另一个AI负责Code Review第三个AI负责集成测试。对比方式是单一AI完成同样任务的最终效果评分。实验结果很有意思——在中等复杂度的需求下多AI协作的完成质量明显高于单一AI但在简单任务场景下多AI协作由于通信开销和上下文膨胀反而效率更低。这个结论给了我很重要的工程启示多AI协作不是银弹它是一种有适用场景的架构模式。场景复杂度高、任务颗粒度大、质量要求严格的场景值得引入多AI协作交互简单、响应要求快的场景用单模型加好Prompt就够了。工程架构上没有最先进的方案只有最合适的方案。实现层面我用的核心通信机制是共享工作区结构化通告。每个AI不是直接把输出内容传递出去而是把结果连同状态、依赖、风险说明写入共享状态区其他AI按需读取。这招可以避免多轮对话导致的上下文爆掉也是多AI协作设计里的核心思路。如果你也想实验这个方向建议从这个简单模式起步先跑通流程再看效果。5. 常见问题与排查技巧实录5.1 高频故障与排查思路速查表在我跑这个项目的过程中整理了一份高频故障清单分享给你。故障现象可能原因排查思路与解决方案检索结果质量差切分策略不当或Embedding模型不匹配检查切分块是否有完整语义单元在自有数据集上对比多个Embedding模型效果模型答案出现明显幻觉检索上下文不足或Prompt压制不足加大Top-K召回数在Prompt中明确仅基于提供的文本作答必要时引入引用溯源Agent反复调用错误工具工具描述模糊或意图路由不准优化工具描述明确输入输出格式与适用场景加入工具动态选择机制检查意图分类精度系统响应延迟高检索慢、生成慢或链路串行检索加缓存输出开启流式响应将多步骤可并行节点改为并发执行多轮对话记忆混乱上下文窗口管理失当引入摘要记忆机制对历史对话做压缩设定记忆持久化策略模型输出格式不稳定未做结构化约束或校验缺失在Prompt内明确JSON或Markdown约束增加JSON Schema输出校验失败时做一次规范重试5.2 后台运行细节日志、监控与安全日志系统在AI应用中比传统应用更重要因为你需要它来做事后的质量追溯。我在项目里对每一次模型调用都记录回放信息包括输入输出的完整内容、耗时、令牌消耗、检索命中的文档ID。这些日志在排查用户的每一次不满时都是最有力的证据。监控层面有三个指标必须设置阈值电话接口错误率、响应延迟P95、内容安全拦截率。前两个是通用指标第三个是AI特有指标。具体怎么设阈值建议取你系统运行一周的基线数据再在基线之上加一个合理波动区间。安全方面有两条铁律第一任何模型输出在进入用户界面之前必须经过内容安全过滤器第二任何工具调用在真正触发外部副作用操作之前必须经过权限校验。这两条不是产品体验问题是事故责任问题希望你不要有侥幸心理。6. 职业成长视角AI工程的能力地图与发展路径如果把AI工程当作一个职业方向来规划你需要掌握的能力远不止会调模型。我把它拆成四层能力地图每一层都是下一层的基础。第一层是编程与系统设计能力。你依然要精通数据结构、算法、分布式系统、数据库这些是AI工程的身体没有这个基础你连模型都部署不好。第二层是机器学习基础。你没有必要成为能推导反向传播公式的研究员但你至少要理解模型是怎么训练的、决定模型行为的关键参数有哪些、为什么会出现过拟合、泛化能力指什么。第三层是AI工程实践能力。包括模型服务化部署、Prompt调优、RAG构建、Agent编排、评测体系搭建、AI应用的可观测性与安全性设计。这一层是这个岗位区别于普通后端开发者的核心价值所在。第四层是产品思维与场景理解力。你要能判断什么场景真正需要AI、什么场景用传统代码就足够。这种判断力非常稀缺也是从工程师升级为技术负责人的关键分水岭。日常学习路径方面我给自己的实践方法是在实际项目里学而非堆积理论。光看书不写代码是学不会的光写代码不懂理论又会在关键时刻做出错误决策。正确路径是理论为实践做铺垫实践为理论做验证互相驱动前行。7. 扩展实践从单点到平台的AI工程全局当单点的AI应用跑通之后你会遇到一个新的问题怎么把它做成平台化支撑公司里的多个业务方使用这个阶段需要你跳出手工搭建的思维模式。平台化的核心是把能力沉淀为可复用的AI服务。比如将知识检索做成一个独立的检索服务提供一套标准API给各个上层应用调用把Prompt模板做成可配置化的管理后台把评测系统做成自助化的平台让业务方自己上传用例、触发评测、查看报告。这个阶段还需要引入AI网关的概念——所有模型调用统一经过网关转发。为什么因为网关是集中管控模型成本、权限、频率的最好位置。你可以为不同业务线分配不同的限额可以做模型版本灰度切换而不影响业务方还可以在网关层统一做内容安全策略的适配。从项目到平台最明显的工程心智转变是从完成到治理——开始考虑SLA目标、故障预案、成本优化、租户隔离这些系统性问题。这也是真正的AI工程和普通AI开发在思维深度上的根本差别。8. 写在最后的个人实战心得这个项目做到现在我最大的心得是AI工程能力的成长速度与你对不确定性的接纳速度成正比。你不可能一开始就做出完美的系统但你可以尽早放下写一次就跑的传统软件思维转变成跑起来之后持续调优的AI系统思维。还有一件很重要的事就是保留你的好奇心。AI工程发展地太快我今天写的这些东西可能半年后又有框架能做更好。但底层的能力——把问题拆解清楚、设计可评测的方案、在不确定性中建立秩序——这些才是穿越技术周期始终有效的元能力。对一个想要深耕这个领域的人来说最值得投入的正是这些不会被淘汰的底层能力。