从零开始做AI工程化这个念头我三年前就有了但真正把它落地成一套可复用的方法论还是最近一年的事。当时我所在的小团队要在大模型能力之上做一个内部知识助手前两周大家都觉得有手就行——调个API嘛文档里全是现成示例。结果一到集成就傻眼了模型输出格式飘忽不定、接口超时、上下文一长就跑偏、账单翻出来整个项目差点被砍。那之后我才意识到AI工程的门槛根本不在调用模型这一层而在让模型在一个系统里稳定地干一件事这一层。这篇文章想聊的是我在这条路上沉淀下来的东西从模型选型、算力规划到Prompt工程化、Agent编排再到评估体系和踩坑清单。它不是教科书也不是某个框架的教程而是一张我自己验证过的ai engineering from scratch地图。适合三类人看准备入行AI工程师的开发者、要在业务里集成大模型的团队以及已经做出Demo但上不了生产的玩家。1. 认清AI工程和传统软件开发的底层差异1.1 不确定性是所有问题的源头传统软件开发我们面对的是一个确定性系统。输入确定输出确定出了bug有堆栈有日志可以复现。但到了大模型这里前面那套东西全都不灵了——同样的输入模型可能给出不同的输出而且这种差异不是你写错代码导致的是模型本身自带的。我第一次做生产级接入的时候犯的最大错误就是拿传统思路去处理模型输出。我写了一段字符串解析假设模型一定会输出JSON结果上线第二天就有几百条数据入库失败。原因特别简单模型在某个输出里多加了一个字母或者用markdown代码块把JSON包住了。这类问题放在传统程序里几乎不可能发生因为你写了解析器就必须遵守语法但模型是概率输出它只是大概率会输出JSON而不是一定。这个特点还会引发连锁反应。传统系统的错误处理是围绕异常设计的try-catch、错误码、重试队列。AI系统同样需要这些但多了两个新问题第一模型输出合法但不合意没有异常可以捕获只能靠校验层拦截第二同样的故障可能无法复现因为每次输出的随机性不同。这就决定了AI工程不能照搬传统研发流程必须单独设计。1.2 AI工程师到底要管哪些事这个差异带来的连锁反应是AI工程师的能力模型跟传统工程师完全不一样。我梳理了一下一个岗位要想把AI应用真正做稳至少要覆盖五块模型层知道主流模型的能力边界、参数含义能做选型判断数据层会对数据做清洗、构造评估样本甚至做微调工程层懂API编排、任务调度、缓存、异步处理评估层能设计评测集和观测指标让模型的输出从不可预期变成可度量成本层理解token计费、算力资源换算会做成本控制很多团队觉得AI工程师就是会调prompt的人这是最大的误解。prompt只是模型层里很小的一块真正难的是围绕prompt那一整套工程设施。我见过不少人Demo做得很好但一问到模型超时怎么办输出校验怎么设计评测集有多少条立刻卡壳。所以如果你正在招人或者准备入行我建议把重心放在工程能力上而不是看谁把prompt写得像魔法咒语。2. 模型选型与算力规划第一个真正要做的决策2.1 开源部署还是闭源API现在做AI应用第一道选择题就是用开源模型自己部署还是直接用闭源API。我的看法是不要先入为主先看场景再选。自己部署开源模型比如Qwen、DeepSeek、Llama系列优点很直接数据不出内网敏感业务放心请求量大了之后边际成本低可以按自己的场景做微调。代价是你要搞GPU、部署推理服务、处理并发和弹性伸缩。我见过一个朋友为了省钱买了一台挂着双卡的服务器跑开源模型结果一个高峰期直接把服务打挂最后紧急扩容折腾了两天。算下来省下的token费用全填在运维人力上了。闭源API的优点是省心不用管服务器模型效果好迭代快。缺点也明显按量付费量大之后开销很吓人数据要出网模型版本升级由厂商控制哪天接口行为变了你要跟着改。我的建议是分三层来做选型判断。第一看数据敏感度涉及客户隐私、内部文档的内容优先本地部署。第二看业务规模月调用量在百万级以上值得算一遍自建成本。第三看效果要求如果你的任务必须顶配模型的能力开源小模型扛不住那就老实买API。2.2 上下文、吞吐、成本三元权衡选定模型之后还有三个数要盯紧上下文长度、吞吐量、成本。很多新手只盯着上下文长度觉得越长约好但实际操作中这是个三元权衡。拿一个典型的客服问答场景来算账。假设每天10万次请求每次输入500个token、输出200个token。如果用一线闭源模型按输入30美元/百万token、输出60美元/百万token来估算价格大概在这个量级那么一天的token成本是输入侧5000万token也就是50乘以30等于1500美元输出侧2000万token20乘以60等于1200美元。两笔加一起2700美元一天。这个数字一出来很多demo阶段的乐观心态瞬间就没了。那怎么办三个手段。第一模型分级80%的简单问题走快而便宜的小模型只有20%的复杂问题才上大模型成本能砍掉一半以上。第二缓存复用常见问题的答案写进缓存命中了根本不调模型。第三上下文即成本输入侧的token是持续消耗的把系统提示词和检索到的资料压到最小也是变相省钱。这些事不做项目很难撑过试点阶段。3. Prompt Engineering从写提示词升级为设计协议3.1 生产级Prompt的完整结构刚开始接触Prompt的时候我和大多数人一样觉得它就是一个问题写得越清楚越好。但真正做生产系统Prompt的设计其实是在设计一个人机交互协议——你要让一个概率模型稳定地执行某个固定功能就必须把它的输入输出边界、行为约束、错误处理都定义清楚。一个我反复验证过的生产级Prompt结构通常包含六个部分角色与目标让模型知道它在这条链路里是谁要完成什么任务描述这次要处理的具体任务最好一段话说清输入格式明确告诉模型会收到什么结构的数据输出格式指定输出的结构比如一个JSON字段名、类型都写死约束条件不能做什么比如不能编造数据、不能输出分析过程示例给1到3个输入输出对把行为钉住这个结构看起来简单但实际执行起来有大量细节。比如输出格式这一项如果你不写死字段名和枚举值模型就会给你自由发挥你的解析层就得跟着遭殃。反过来一旦你把格式写死配合后面的结构化输出机制模型返回的结果就能被代码直接消费这才真正实现工程化。3.2 结构化输出与校验闭环说到结构化输出这是我把Prompt当协议用的核心手段。现在的实现路径有三种主流做法我分别说说适用场景。第一种是让模型按指定JSON Schema输出。你定义好schema字段、类型、必填项、枚举值然后把schema放进Prompt里要求模型严格按schema返回。这适合大多数自定义任务的场景。第二种是function calling工具调用适合需要触发下游动作的Agent场景。模型不是返回一段文本而是返回一个结构化的函数调用请求。这种机制比纯文本解析稳定太多因为参数都是按定义好的格式返回的。第三种是先用自由文本输出再用代码做解析兜底。比如模型写一段markdown你用解析器提取其中的表格或段落。这是最传统AI的做法灵活但是稳定性差我一般作为兜底方案保留。无论用哪种方式一个铁律是绝对不要信任模型的输出必须做校验。我在项目里通常会写一个validator层检查返回的JSON字段是否存在、类型对不对、枚举值是否合法。校验失败的请求再触发一次重新生成加一个上一次输出校验失败请重新生成的反馈。这一套下来线上数据入库的失败率才真正到了可控水平。3.3 Prompt需要版本管理Prompt在传统研发流程里是一个被严重低估的管理对象。代码有Git模型有版本但Prompt往往被当成改一句提示词随手就定了。等到线上效果回退你想排查是模型升级导致的还是Prompt被谁改过的时候就全抓瞎了。我现在要求团队把每一个线上Prompt都纳入版本管理和代码一样走评审、发布、回滚流程。Prompt文件本身就用文本存储放入版本库管理线上读取的是某个固定版本号不是最新文件。这样一旦线上指标下降可以快速对比前后版本的差异定位问题。4. 从单轮调用到AI Agent编排层的工程化4.1 Agent的核心循环感知、决策、行动、观察聊完单轮调用再说现在最热也最容易翻车的方向AI Agent。很多文章把Agent说得神乎其神但拆开来看一个Agent的核心就是一个循环感知接收用户的指令或环境反馈决策让模型思考下一步做什么行动调用某个工具或API观察拿到工具的执行结果再进入下一轮决策。这个模式本质上就是大家熟知的ReAct工程上没有魔法难点在于你把这个循环做成一个稳定可控的生产系统。我做的第一个Agent是代码变更审查助手。一开始设计得很理想模型读代码差异自动跑静态检查根据结果生成审查意见。看起来很简单但实际跑起来就发现模型在循环里会出现各种跑偏行为——它可能在一次审查里反复调用同一个工具可能生成了不存在的参数甚至可能在循环里思考到把系统提示词暴露出来。这些都是不可避免的要提前做好预案。4.2 工具调用的安全边界所以Agent逃不过一个核心工程问题工具调用的安全边界。我的原则是Agent能用的命令必须是一个白名单每个工具都要做三件事定义清楚入参、限制目标范围、记录完整日志。这里我吃过亏。一次内测中我用一个文件操作工具让Agent帮忙整理文档目录我在工具定义里没有严格限制路径范围结果它在整理过程中把一个配置文件移到了别的目录整个服务的配置加载直接崩掉。排查了半天最后在日志里看到它执行了移动命令。那个教训让我从此认识到Agent工具跟数据库连接一样必须最小权限。文件类工具限制在指定工作目录命令类工具只允许白名单命令网络类工具只开放白名单域名。更严格的做法是在沙箱容器里跑Agent让它没有权限去碰系统关键资源。4.3 多Agent协作没有智能只有协议关于多Agent协作我现在反而比之前冷静很多。市面上很多项目试图让多个Agent自由对话、互相聊出结果但从工程视角看这种设计极难稳定因为模型之间的沟通是概率事件你很难压住所有的理解偏差。我现在的倾向是多Agent之间不靠自由对话而是通过结构化协议协作。举个例子我在做一个资料整理系统时拆成了三个Agent检索Agent、摘要Agent、审核Agent。它们之间怎么协作我定义了一个共享的task结构体里面包含任务ID、输入文档、检索结果、摘要文本、审核状态。三个Agent各自处理这个结构体中的字段不再互相聊天。检索Agent负责写检索结果摘要Agent只读检索结果、写摘要审核Agent只读摘要、写审核意见。每个Agent只通过数据交换协作不直接对话。这套设计跑通之后系统的稳定性比最初让它们自己聊的版本高出一个量级。5. AI工程的测试与评估让概率模型可预期5.1 传统测试为什么失效做AI工程绕不开一个灵魂拷问怎么测试一个没有确定性输出的系统传统的单元测试没法直接套用因为你断言的预期结果永远是猜测模型今天能过明天同一套用例可能就挂了。刚开始我也很不适应后来逐渐总结出一套适合AI场景的测试体系核心思路是从断言准确率转向断言行为范围与关键约束。具体来说分三块。第一块是回归测试集也叫Golden Set。我维护了一个几百条的高质量输入-期望特征对每次改Prompt或换模型就让这批用例在测试环境里跑一遍人工或半自动检查输出是否还满足关键约束。第二块是约束校验测试不检查输出是不是正确只检查它是不是合规格式是否合法、字段是否齐全、有没有越界行为。第三块才是人工抽检经过前两轮过滤后剩下的内容人工评估。5.2 LLM-as-a-Judge用模型评估模型的注意点很多团队在做评估的时候会用另一个模型来打标也就是LLM-as-a-Judge。这个思路我认可但有几个坑必须先说。第一评估模型和被测模型不要是同一个两者通用能力太接近的话评估偏差很大。第二评估Prompt必须固定版本而且评估标准要可落地。我踩过的坑是评估Prompt里写了回答是否友好这种模糊标准结果评估模型基本打高分完全没区分度。后来我把标准改成了具体清单是否包含关键要点、是否有明确结论、是否出现错误信息源等评测分数才开始有区分度。5.3 线上可观测性评测集解决的是版本升级能不能上的问题线上的可观测性解决的是上了之后到底跑得怎么样。传统后端有日志、指标和链路追踪AI系统同样需要这套东西而且要额外加一层模型行为日志。每条线上请求我会记录用户输入、最终输出、token消耗、延迟、模型版本、Prompt版本以及如果是Agent场景还有中间每一步的工具调用记录。这不仅仅是排查问题时方便更重要的是为后续的评测集扩充提供素材——凡是线上用户明确反馈答非所问的请求我都要求捞回来经过清洗后进入回归测试集。这样你的评测集是跟着真实用户场景生长的而不是死的几百条例子。6. 从零到一的实战路线三个月的学习路径6.1 第一步先把单点调用做扎实如果你是真的从零开始我建议不要一上来就搞Agent或微调。先老老实实做一个单点调用项目调用一个大模型API做一个能稳定输入、稳定输出、有错误处理的小服务。这个阶段的核心目标是理解模型行为学会设计Prompt熟悉token计费能处理超时、限流、输出格式异常。我的建议是做一个简历解析工具或工单分类器输入是文本输出是结构化JSON工作量不大但能逼着你把上面说的闭环全走一遍。6.2 第二步给模型接上手和腿单点调用跑通之后再进入Agent阶段。把模型从只说话变成会做事的关键是工具调用。我建议做一个简单的工具型Agent比如给内部用的自动化报告生成Agent让它能查数据库、调接口、生成Markdown报告。这个阶段你会真正理解function calling、白名单权限、日志追踪这些工程东西到底有多重要。别贪多一个Agent就好先把循环跑稳。6.3 第三步跑通评估与发布闭环最后一步把你前面做的东西套上工程流程。给Agent配上评测集、约束校验层、线上监控面板、版本回滚机制。这一步做完你手里就是一个可以直接面对真实用户迭代的AI系统。到这时候你再回头看ai engineering from scratch这件事你就不会纠结该学什么框架——因为整个链路你已经自己走通了一遍。6.4 踩坑清单速查最后把我踩过的坑整理成一个速查清单新人项目起飞前最好过一遍上下文污染长会话里旧信息干扰新任务该裁剪时一定要裁剪结构化输出不校验不写validator迟早被模型自由发挥坑一次温度参数不调默认温度可能不适合你的任务代码生成类要调低成本没有监控账单上线后失控我见过最快的失控是三天花了预算的40%把模型当人用要求模型处理它不适合的任务比如超大文本一次性分析忽略回退机制线上模型输出突发异常没有兜底策略就是事故我自己走过一遍之后最大的体会是AI工程没有那么多玄学它本质上还是工程——把不确定性当成系统的一部分来设计。模型会升级、接口会变、成本会涨这些都是必然的你要做的是把评测、校验、监控、回滚这些东西建起来让任何一项变化都不会直接击穿业务。如果你现在正处在一个模型跑通但系统没上线的状态别急着追新框架新概念。把这个基础链路补起来你会发现很多效果不稳定的问题其实是工程设施缺失的问题。