我记得第一次接触“AI工程”这个概念时以为就是用Python调一个大模型接口把用户的问题扔进去再把返回结果展示到网页上仅此而已。真正上手做实际项目后才发现那只是整个AI工程链条里最末端的一小截。真正的“ai-engineering-from-scratch”是从模型能力认知、提示词设计、数据组织、系统架构到评测、部署、监控、迭代一条完整的能力链路。这篇文章是我从零搭建AI应用过程中的完整拆解适合那些已经会写代码、但还没真正把AI落地的开发者也适合正在规划AI项目的技术负责人。我不打算讲太高深的理论尽量给可参考、可复现、可以少走弯路的经验。1. 从零做AI工程先看清完整的能力地图很多教程上来就教“三段式提示词”或者告诉你用某个框架能两小时上线一个AI应用。但当你做完一个demo真正想让它承受真实用户请求、整合企业数据、稳定输出可用结果时问题会接踵而至模型回答不稳定、上下文切分错误导致检索不到关键信息、Agent在多步推理时路径崩溃、线上调用成本失控。这些问题单靠“调提示词”根本解决不了根源在于没有把AI工程当成一个完整系统来设计。1.1 AI工程和传统软件工程的本质差异传统软件是确定性系统同样的输入一定产生同样的输出。AI应用是概率性系统同样的Prompt在温度参数为0时也可能因模型版本变化而输出不同内容。这种不确定性贯穿整个工程链路决定了两件事第一你的架构必须为“模型可能出错”兜底。 第二你的测试与评估体系必须从“断言输出”转变为“评估分布”。打个比方传统开发像盖一栋框架结构楼每根钢筋位置是固定的AI工程更像是在河道上建水电站你既要利用水流的能量又要应对水位的波动。你不能假定大模型每次都不偏不倚你必须设计好“导流”“泄洪”“缓冲区”。另外一个容易忽略的差异是传统代码的可读性靠注释而AI工程的可读性靠提示词的可解释性、评测数据的质量和链路中间产物的可视化。一个团队能维护好Prompt和评测集比能写出漂亮代码更难得。这也是为什么很多AI项目代码很简陋但评测集做得好照样能在生产环境稳定跑很久。1.2 AI工程师必须具备的四层能力我从实际项目里总结下来一个合格的AI工程师需要同时具备四层能力缺一不可模型层能力理解不同大模型如通用对话模型、便宜快速的小模型、带视觉能力的多模态模型的适用边界知道什么样的任务交给什么样的模型而不是什么任务都堆一个最强模型。数据层能力能做文档解析、数据清洗、切片策略设计、知识库维护。很多AI项目效果不好不是模型不够强而是知识库里的数据乱得像一个没有整理过的仓库模型想找钥匙却被一堆杂物困住手脚。系统层能力会设计Agent编排、函数调用、任务规划、状态管理、缓存、熔断、限流。这里的系统设计经验大多来自传统后端开发但需要针对AI特有的延时、成本和不确定性做重新优化。评测与迭代能力能搭建评测集、设计自动化评测流程、分析失败案例、形成回归测试机制。没有评测就没有迭代依据AI应用只会越调越发散。我见过不少团队三个人写了一个好用的大模型应用但在上线一个月后开始逐渐崩坏数据变了、用户问法变了、模型更新了没有任何机制能警示“效果正在下降”。因为他们只做了调用封装没有做数据回流和评测闭环等于只有发动机没有仪表盘。2. 核心链路拆解提示词工程、RAG与Agent的构建要点AI工程的落地路径绝大多数最终会落在三条核心链路上直接提示词调用、检索增强生成、智能体编排。你可以把它们理解为一个递增的复杂度阶梯。直接调用最简单适合明确任务RAG增加了知识库的介入适合私域知识问答Agent则引入工具调用与多步决策适合完成任务型操作。但每一步都有它特有的难点和坑。2.1 提示词工程从“聊天”到“指令系统”很多初学者把提示词工程理解为“把话说得更清楚”这种理解太浅了。工程意义上的提示词是一个指令系统它由五部分构成角色定义、任务描述、输入数据、输出约束、边界纪律。角色定义不只是一个头衔例如“你是一名资深运维工程师”更是对该角色的知识边界、回复口吻和决策风格的约束。任务描述要用动词开头越清晰越好“从以下工单中提取故障等级和影响范围并给出恢复建议”而不是“请帮我分析一下这些工单”。输出约束必须明确格式例如“输出JSON格式包含 severity 和 reason 两个字段”并给出一个少样本示例。边界纪律则决定了模型在什么情况下不行动比如“如果无法确认答案返回unknown不要编造”。我常用的结构化提示词模板是这样的以Python代码组织prompt { system: ( 你是一个信息安全助手只负责从工单中提取结构化信息。 如果工单信息不足字段填空字符串禁止编造。 ), task: ( 解析工单内容输出JSON {category: hardware|software|network, priority: P0|P1|P2, summary: 不超过20字} ), context: ticket_text, response_format: {type: json_object}, temperature: 0.0, }注意temperature设置为0这是很多工程化调用的共识。虽然改成1.0会更有“创造性”但在绝大部分业务场景里你不需要模型发挥你需要它稳定。考察模型输出质量时首先看“格式偏差率”和“字段准确率”而不是“对话自然度”。这里还容易踩一个坑提示词不是越写越长越好。有些人习惯把所有背景、强调、警告都堆进去结果模型注意力被稀释关键指令反而失效。我的经验是提示词里只保留“模型需要但不知道”的信息那些已在前置确定性代码里完成的事不要交给模型判断。比如能通过正则判断的格式校验就一定不要写进提示词让模型去理解。2.2 RAG系统不是所有问题都需要微调微调常常被误解为“让模型学会新知识”但大模型的训练周期长、成本高更重要的是它存在“灾难性遗忘”风险。对于知识密集型场景比如企业内部制度问答、产品使用手册问答RAG检索增强生成是更务实的选择先通过检索找到相关文本片段再让模型基于这些片段作答。RAG从零搭建看起来简单文档切片、向量化、存向量库、相似度检索、拼Prompt五个步骤就能跑通。但要可用需要死磕四个细节。切片策略是首要问题。固定按照500字切常见案例是上下文被拦腰截断模型检索到一个“有头无尾”的片段逻辑链断裂回答自然错误。更合理的做法是按文档结构切片Markdown的一二级标题、Word的章节、PDF的段落边界让每个切片都尽量是语义自洽的完整单元。如果目标问答场景是碎片化的比如FAQ那应该按“一问一答”整体为切片而不是按字数硬切。向量化模型选择也有讲究。中文场景用开源向量模型比如bge-m3或者直接在云厂商的向量化接口里选中文模型效果通常比用通用英文向量模型好。向量维度决定存储成本维度越高精度越高但高并发下检索延迟和存储成本都会上升需要权衡。我个人建议先从768维起步够用即可。检索后的重排序环节是最多人忽略的。向量检索的Top-20里可能只有三四个是真正相关的把它们全塞进Prompt既增加token消耗又干扰输出。加一个重排序层用交叉编码器重新计算语义相似度然后只取Top-3给模型回答质量和token成本都能明显改善。最后一个细节是引用溯源。如果用户问了一个知识库里没有答案的问题模型可能会把两段不相关的内容揉在一起生成一个看似合理的答案这就是幻觉。工程上的兜底方式是让模型在输出时附带引用切片ID前端渲染时把引用展示出来如果引用置信度低于阈值可以拒绝回答告诉用户“没有找到可靠依据”。这一步虽然看似繁琐却是企业级应用能不能被信任的分水岭。2.3 Agent智能体让模型学会使用工具Agent的核心理念很简单不要试图让模型一次生成完整答案而是让它在一个循环里逐步行动、观察结果、调整计划。典型的循环是“思考—调用工具—观察输出—再次思考”也就是ReAct模式。我第一次搭Agent时犯的错是给模型塞了七八个工具让它自己选。结果是模型频繁在工具之间试探、用错参数、反复兜圈子一个简单查询花了好几次调用成本翻了四倍。后来我总结出几条原则工具数量控制在3到5个以内每个工具的描述必须说清楚“干什么用、什么时候用、要注意什么”。对模型而言工具描述就是它的操作手册写得越清晰调用准确率越高。必要的时候做“任务编排”把复杂任务拆成几个子Agent每个子Agent只负责一类工具。比如客服场景里订单查询Agent只查订单售后Agent只处理退款。不要让一个Agent拿全部工具那是既烧钱又不可靠的设计。设置最大迭代步数和超时时间否则一个Agent可能陷入死循环比如一直重复调用同一个失败的接口。给Agent记录“认知边界”明确告知它有哪些事做不了。比如没有视觉能力、不能操作真实系统它能调用哪个API就只调用哪个API避免模型“假装”工具调用成功。这个问题在真实项目中非常常见模型输出了一个像是成功但实际上并没有执行的假操作过程线上事故往往就是这么来的。Agent的生产力提升在于“工具越多越好”但工程稳定在于“工具边界越清晰越好”。两者之间需要取舍我的倾向是先做减法跑通了再逐步加工具。3. 从零搭建一个可用的AI问答应用完整实操过程理论讲再多不如走一遍真实的落地过程。我以一个“企业规章制度问答助手”为例完整演示从需求到上线的全过程。这个例子有代表性有私域知识有多轮上下文有权限隔离要求也有稳定性和成本压力几乎覆盖了前面说的所有核心环节。3.1 需求定义与技术选型过程需求方面业务方提出的原始需求是“想让员工可以直接问HR问题”但这不是一个好需求太模糊了。工程上必须先把它细化成边界清晰的场景你能接受回答哪些问题比如假勤制度、报销流程、差旅标准。哪些不能碰比如薪酬细节、绩效评定。回答风格是正式公文还是口语化多轮追问需要记住几轮上下文如果知识库里没有答案该回答“不知道”还是提供一个咨询入口把这些边界一条条写下来就是一份可执行的需求清单也是后续评测用例的来源。技术选型上我建议不要迷信“最强模型”。实际问题中70%的知识问答任务用一个中端模型就够用比最强模型便宜一个数量级响应还快。只有需要复杂推理的任务才值得上最强模型。表格模型选型时看三个维度中文理解能力、指令遵循能力、输出稳定性。前两个可以通过公开评测榜大致判断第三个只能靠自己用小样本测试。我的经验是用一组真实的业务问题跑50条检查格式偏差和内容准确率这种“小样本冒烟测试”比任何榜单都可靠。3.2 知识库清洗与切片这一步决定效果上限我见过太多人在向量模型和检索算法上反复调参但知识库文档本身还是一团乱麻。这一步必须做扎实而且做的顺序要在搭向量库之前。实际操作中我把原始文档分成三类处理结构化表格类比如“年假核算表”“报销标准表”直接转成CSV或SQLite记录查询时用精确匹配或规则引擎处理根本不需要走向量检索。章节型长文档按标题层级拆成2到4个段落大小的切片保留上下文摘要。高频FAQ类直接整理成一问一答的条目作为精调用例。这一步做了两天后续效果显著优于之前用“无脑按500字切”的方案。检索结果的Top-3相关度肉眼可见地提升模型回答也有了清晰出处。另外文档里常见的“本制度自发布之日执行”“详见附件”这类元信息要提前过滤掉否则它们会被切进很多无关切片拉低检索精度。清理工作还包括统一简繁体、纠正OCR后的错别字、把扫描件PDF重新跑一遍文字识别。3.3 接口链路与上下文管理设计核心链路是用户输入 - 意图识别 - 检索 - 组装上下文 - 大模型生成 - 输出与引用。这里重点说两个工程师容易忽略的环节。第一是意图识别和“门控”。不要什么输入都直接送进大模型先用一个分类器判断问题类型。如果用户只是在闲聊一句“最近怎么样”就不应触发知识库检索和模型调用直接走一个轻松回复即可节省成本也避免污染上下文。如果是攻击性输入、试图让模型忽略系统指令的内容更应该在入口就拦截掉不要让它进入知识库检索链路。第二是上下文管理。多轮对话意味着用户的当前问题往往依赖前面的对话。常见做法是把最近的对话历史压缩成“短期记忆”同时维护一个“用户画像摘要”比如用户在办理离职他的问题都与离职流程相关将这一概要放入系统提示词比把完整历史对话都塞进Prompt更高效。我的经验是每个请求携带的历史消息不超过10条超过的部分先做摘要再存储。这样既保证上下文不丢失又控制token消耗和响应时长。核心调用的请求结构大致如下{ model: gpt-4o-mini, messages: [ {role: system, content: system_prompt}, {role: user, content: user_question} ], temperature: 0.1, max_tokens: 512 }在多轮对话中上下文里还要保留last_reference_ids让模型优先引用上一轮提到的文档切片避免检索结果每轮都漂移回答才有一致性。否则用户上一轮问“年假怎么算”这一轮问“那病假呢”模型可能就忘记了“我们刚才在聊请假制度”这件事情。3.4 部署与成本控制个体项目也要讲经济效益一个人做的项目也需要考虑部署成本和调用成本不然撑不过持续迭代。将服务接口部署在函数计算平台上是比较轻量的选择无请求时不产生费用有请求时自动扩容配合内置的API网关限流可以避免大模型调用失控。向量数据库方面如果数据量只有几万条切片用轻量级的本地向量索引就够比如FAISS不必一开始就上分布式数据库。等数据量真到百万级、需要水平扩展和高可用时再迁移到专门的向量数据库也不迟。成本控制的关键指标是单次会话成本。计算公式很简单单次会话成本 平均token消耗 × 单价 × 平均轮次。你可以把日志里的token消耗按天聚合观察用户平均一次问答花了多少钱。我实践下来有几个省钱技巧先用分类器把不用模型也能回答的问题拦截掉检索到的相关切片先做摘要压缩再把摘要和切片一起送模型而不是把Top-3切片全文直接塞进去低频时段把模型切换到更便宜的版本只保留核心时段用高质量模型设置用户维度的每日调用上限防止异常调用把预算打穿。4. AI应用的评测体系没有评测就没有迭代在传统软件里测试是为了验证“功能是否符合预期”。在AI工程里评测更像是在“定义什么是好”同一道题不同人不同时间可能给出不同答案很难用简单的断言断言对错你必须先建立评测标准。4.1 评测集建设不要用100条全部期望完美跑通新手最容易犯的错误是拿二三十条“朋友问过的奇怪问题”当评测集然后手工肉眼观看回答“差不多对吧”就上线了。这样做最大的问题是样本太少、标准主观、无法回归。建设评测集核心是把条目按难度和场景分层L1基础条目共30条左右覆盖高频问题标准答案明确比如“年假休几天”“报销时限”。指标是准确率低于90%不应该上线。L2挑战条目约20条故意包含多轮追问、歧义、长句、细节缺失。目标是看模型在模糊条件下能否合理追问或给保守答案而不是瞎猜硬答。L3安全条目约10条专门用来测试不该回答的问题比如套取他人信息、诱导越权访问。目标是看系统会不会拒绝拒绝率应为100%。评测集是持续生长的不是一次性建完。每两周把线上真实用户的高频问题、失败案例加进评测集形成“数据闭环”。这样才能保证模型每次更新后你知道它到底是变好了还是变差了。4.2 自动化评测方法LLM-as-Judge的使用与陷阱评测少量样本可以由人工评定但一个每周迭代、并且要持续监控的AI应用必须自动化。主流方案是用模型当裁判让一个评估模型对回答进行1到5分打分或者直接比较两组输出哪个更好。这个方案跑得通前提是你得防几个坑。第一裁判模型会偏好语气更流畅、格式更漂亮的回答哪怕事实有误。所以评测Prompt要明确告诉它“优先以内容准确性打分语气和格式不作为主要评分依据”。第二裁判模型通常无法判定“是否引用了正确出处”需要结合代码逻辑先检查引用ID是否存在于答案对应的知识库切片中。第三如果有敏感内容的边界测试裁判需要能识别“回避是否合理”合理的回避应该被视为正确回答。更稳妥的做法是“结构化拆解”评测不要只问“这回答好不好”把评分拆成多个子项每个子项单独打分。评测维度说明判定方法内容准确性事实是否与知识库一致LLM裁判 人工抽检引用正确性引用ID是否真实对应内容代码校验格式合规是否按要求输出可用格式代码校验安全边界是否拒绝不该回答的问题LLM裁判 规则效率回答是否在预期轮次内完成日志统计我常用的做法是每次迭代后先跑一遍自动化评测看总准确率的变化曲线如果有明显下滑拉取典型的失败案例做人工分析找出是三方面原因还是数据问题。这个过程原则上不超一小时但能保证项目一直在正轨上前进。4.3 线上指标监控体系线上监控不能只看接口成功率。更重要的指标是用户侧的体验指标。我实践下来最有用的三个是无响应率用户发送后没有得到有效回答的比例、无效回答率模型返回了内容但无法满足询问目的的比例、多轮终止率用户进入多轮对话后是否在第二轮后就直接流失。这些指标能真实反映用户在跟AI对话时的感受跟传统后台的QPS、latency完全不是一回事。技术上需要做的是在请求日志里记录完整链路分类器结果、检索到的切片ID、模型调用时长、token消耗、用户是否点击了“有帮助”反馈按钮。这些数据将来是做评测集和迭代优化的金矿。很多项目上线后效果无法持续提升就是因为这些数据根本没有被记录下来等于每月的牙龈数据全部丢失你没法做任何复盘。5. 常见问题与故障排查手记这一篇可以说是全篇文章里最“值钱”的部分因为这些坑都是我一步一步踩出来的。不多说了直接上问题清单和处理策略。5.1 模型“一本正经地胡说八道”幻觉怎么抑制幻觉是AI应用最让人头疼的缺陷但你要先定位是哪一种幻觉。常见情况分三类第一类是知识库没有相关内容模型靠预训练“脑补”。解决方式是开引用溯源当模型找不到切片依据时强制它返回“资料库暂无相关信息”而不是自己自由发挥。第二类是多个切片之间信息冲突模型挑了一个不对的去执行。这种情况需要做冲突检测如果检索到的切片事实不一致要在Prompt里告诉模型“注意以下两个片段存在冲突请优先采用最新的制度版本”。第三类是切片的上下文不完整导致的理解偏差。比如切片只有“报销时限为15个工作日”但没有说明是“自发票开具之日起”模型就可能回答了错的条件范围。解决方式是审查切片是否保留了必要的前置条件和限定词。将评测集里面的幻觉用例按这三类分别标记然后针对修复效果做回归测试。平均来说解决好这三类幻觉率能下降70%剩下的部分需要更精准的数据治理来解决。5.2 智能体的循环不稳定如何引入有人工介入Agent在多步任务中常出现两种情况在错误路径上坚持不回头或者反复调用同一个失败工具不放弃。给Agent编排加一层“人工监督”非常关键尤其在生产环境里。实操上我是这样处理的所有Agent执行过程都产出一个“执行轨迹”每一步都记到日志里调用了哪个工具、输入了什么参数、返回什么结果、Agent认为下一步要做什么。在手艺上还可设置一个“人工审批点”当Agent准备执行高影响操作时比如在EHR里批量修改员工信息必须停下来生成一个待人工审核的请求由管理员确认后才执行。这个“人机同步”看似违背了“自动化”的理想却是当前AI工程落地的现实解Agent负责高效干活人类负责安全兜底。我在这类系统上线后严重事故的概率几乎降到零。5.3 模型输出格式不稳定怎样用两次调用解决一个高频的线上故障是明明在Prompt中要求输出JSON模型却偶尔输出一段Markdown或多余的说明文字导致下游解析任务失败。传统做法是反复调Prompt但总会有漏网之鱼。更稳定的做法是“格式修复调用”当第一次解析失败时把模型输出原样塞进第二个Prompt让它“只输出JSON不要任何额外内容”用一次额外的调用来换取格式100%稳定的输出。这个方案看起来成本上升实际因为失败比例通常低于5%整体成本增量很小效果却非常好。长期来看比较妥当的做法是在数据层面清洗模型输出用正则先剔除代码块标记再用JSON解析解析失败再触发修复调用。三层下来格式问题基本消失。5.4 同一个问题连续问两次答案却不一样模型输出的随机性在多轮对话中更明显用户会把这当成系统bug。虽然temperature0能降低随机性但不同天模型版本更新后输出风格也会变化让用户觉得“老答案找不到了”。工程上我给高频问题做了“语义缓存”将用户输入做向量化如果与历史问题的相似度超过0.95直接返回缓存答案不触发模型调用。既保证了答案一致性又省了大笔token费。有段时间这个缓存的命中率能达到40%。另外在Prompt中明确加上“官方回答模板”也很重要对于企业制度等高频问题把标准答案直接写到系统提示词里让模型“遵循原文不要发挥”一致性会大幅提升。6. 工程选型避坑指南与我的最终体会“从零不意味着从荒原开始”这是我做AI工程最大的领悟。框架用哪个、基座模型用哪个、云端还是私有化部署这些都该是基于场景的抉择而不是追热点。如果企业已经有成熟的DevOps体系选择一套支持私有化的AI编排框架会稳妥得多个人开发者在追求快速验证时优先考虑托管服务把精力花在业务逻辑上。关于模型的定制路径RAG最好在微调之前尝试原因之前说过微调成本高且有遗忘风险。只有当你需要改变模型的写作风格、固定输出格式、抽到特定领域推理能力时微调才值得考虑一般场景RAG完全够用。关于“AI Agent到底能不能代替人工”这个问题我的体会有两部分一是现在要解决的大多数业务问题靠结构化工作流已经把Agent用到八九成了真正的价值不在“全自动”而在“把重复劳动分层”。让模型承担最耗时的那部分理解、生成、检索工作人类做决策和兜底。二是你的系统设计从一开始就要服务于这一个目标可观测、可干预、可追溯。因为我一套工程化链路下来最欣慰的场景是上线三个月后我几乎没有为线上效果熬夜焦虑过。所有问题都能在评测集和监控面板上提前找到苗头处理起来也总有章可循。AI工程的乐趣正在于此你面对的是一个有智能、有不确定性的系统但你可以用工程把它驯服得几乎可控从最初的多轮试错到最后稳定交付这中间经历的每一次踩坑和修复都会内化成你自己的判断力和直觉。
