接手AI项目之前我在传统后端开发里泡了将近十年。当时觉得API调用谁不会啊对着文档写请求、解析响应、处理异常这不就是常规操作吗。结果第一个真实AI项目上线两周就把我狠狠教育了一顿——模型推理结果时好时坏、同样的输入换个说法输出就飘、线上用户投诉说这AI是不是抽风了。我那时候才意识到会调用模型接口和能把AI工程落地完全是两码事。如果你也是从传统开发转过来或者正在犹豫要不要入坑这篇东西就是写给你的。我会从零开始把AI工程这条路上的核心问题拆开揉碎到底什么是AI工程、它和传统软件工程的本质差异在哪儿、从零搭骨架要注意什么、Agent和循环编排怎么做、质量体系怎么建、最后用一个完整的最小案例串起来。全程是实战视角没有教科书式的废话尽量把我踩过的坑和总结的经验一次说透。1. 先搞清楚一件事AI工程到底在解决什么问题1.1 为什么会调API不等于会做AI工程很多人对AI工程的第一印象是把大模型的接口接到业务代码里输入prompt拿到结果完事儿。真要这么简单市面上也不会有那么多翻车的AI产品了。AI工程面对的核心挑战是不确定性。普通函数你输入11永远返回2但同一个prompt丢给大模型这次可能给你标准的JSON下次可能在JSON外面多包一层markdown代码块再下次干脆开始思考并输出一堆废话。你写的每一行代码面对的都是一个概率系统而不是确定性系统。工程化的本质就是要把这个概率系统装进一套确定的、可控的、可度量的框架里。这也是为什么从零开始做AI工程这件事值得单独拿出来说。它需要你同时处理好几个维度的问题模型怎么选、提示词怎么管、数据怎么喂、上下文怎么组织、Agent怎么设计、循环怎么编排、结果怎么评估、线上怎么观测。任何一个环节掉了链子整个系统都会在某个你意想不到的时刻突然失灵。1.2 AI工程和传统软件工程的四个关键差异我给自己带过的新人讲AI工程时最喜欢用一张对照表说明问题维度传统软件工程AI工程行为确定性输入确定则输出确定输入相同输出也可能漂移测试方式单元测试断言精确值评估集打分、对比、容忍度判断错误处理异常类型明确可捕获模型一本正经地胡说八道系统边界代码数据库代码模型数据提示词外部工具最后一个差异容易被忽略。传统系统里代码是你的主体数据库是存储层AI系统里提示词和上下文本身就是程序逻辑的一部分模型权重也是运行时的一部分。这意味着你部署的不只是代码而是一整套包含数据管道、模型配置、提示词版本、工具协议的复合体。理解了这四点和概率系统要装进确定性框架这个大前提后面所有工程决策都会变得顺理成章。选型、架构、测试、监控本质上都是在做同一件事用工程手段驯服不确定性。2. 从零搭建的第一个AI工程骨架2.1 脚手架思维先别写业务先搞定三件事从零开始做AI工程最容易犯的错就是上来就写业务逻辑。我的建议是先把三件基础设施搞定它们决定你后面能不能高效迭代。第一件是模型接入层。不要把模型调用散落在业务代码里封装一个统一的Client层负责请求、超时、重试、错误归一化、Token统计。这样你换模型供应商、切换模型版本时业务方完全无感。第二件是配置管理。模型的温度、top_p、max_tokens、system prompt版本、模型名称这些全部要放进配置中心而不是写死在代码里。AI系统的调参频率远高于传统系统没有一套灵活的配置管理每次实验都要发版效率会低到让人崩溃。第三件是可观测性钩子。从第一天起就要记录每次请求的输入输出、耗时、Token消耗、模型版本、提示词版本、返回结果是否合法。线上出了任何问题如果没有这些记录你连排查的入口都找不到。这三件事看起来平平无奇但它们决定了一个AI项目的迭代速度。我见过太多团队前期图省事后面花几倍时间补日志、补配置、补兼容层非常被动。2.2 提示词工程把它当代码管理而不是聊天提示词工程可能是大家最熟悉、但又最容易被轻视的环节。很多人写提示词就像发朋友圈一样随意想到什么写什么改一次丢一次完全没有任何版本概念。但你仔细想想提示词就是AI系统的源代码它直接决定模型行为而且和代码一样需要评审、测试、回归、灰度。我的实践是把提示词工程拆成四层指令层告诉模型角色和任务。比如你是一名资深客服质检专员这层相对稳定。约束层规定输出格式、行为边界。比如只输出JSON禁止编造不存在的订单号这层要尽量用肯定句写明确规则。示例层提供few-shot示例尤其是边界情况和错误样例。这层是提升准确率最有效的手段代价是消耗更多Token。变量层运行时动态注入用户输入、上下文数据。这层是需要严格校验的防止注入攻击。每一层变化的影响面完全不同。改指令层可能影响所有业务改示例层只影响当前场景。所以一定要分层管理并且把每一版提示词的变化记录到版本历史里标注改了哪一层、为什么改、评测结果如何。我见过最好的团队甚至会把提示词变更做成类似Code Review的流程评审通过才允许上线。另外写提示词有个容易忽略的原则能用给规则就不用给感觉。回答要专业是感觉必须引用数据来源且数据来源不能早于2020年才是规则。规则越可验证模型表现越稳定。2.3 上下文工程决定AI系统上限的隐形因素提示词只是冰山一角。真正决定AI系统质量上限的往往是上下文怎么组织。你给模型多少上下文、以什么顺序给、哪些信息优先、哪些信息可以丢弃这些决策直接影响回答质量也直接影响成本和延迟。这里需要区分两个概念Prompt Engineering是怎么说Context Engineering是给它什么说。同一个模型上下文中塞满无用日志和精心组织过检索结果之后的回答质量差距是天壤之别。我在实际项目里最常用的是RAG检索增强生成模式。它的核心思想非常朴素大模型的训练数据是静态的但业务数据是动态的那就先用检索把需要的业务数据捞出来塞进上下文再让模型基于这些数据回答。这比微调模型省事得多也灵活得多。RAG工程里最重要的三个参数分别是检索精度、上下文窗口利用率和排序策略。检索精度靠的是Embedding模型选型和索引策略。Embedding模型就是把文字变成向量、用来算相似度的模型选型直接决定搜得准不准。上下文窗口利用率则是说模型一次能看的Token有限你不能把所有检索结果都塞进去要有取舍。排序策略更讲究不是所有检索结果都该被模型看到相关性低的、内容重复的要在进入上下文之前就过滤掉。这里有个具体经验检索结果不是越多越好。我跑过对比实验5条相关文档和20条相关文档在同一个模型下回答准确率反而会下降。因为无关信息会干扰模型的注意力这就是上下文污染。精挑5条往往比粗塞20条效果更好Token成本还更低。3. 让系统自己会干活Agent设计与Loop工程3.1 Agent的本质是目标拆解 工具调用 结果验证当你的业务需求变得复杂——不是回答一个问题而是帮用户完成一整件事——单次模型调用就不够用了。这时要引入Agent的概念。Agent简单说就是一个由大模型驱动的自动执行体它接收目标自己决定怎么拆解任务、调哪些工具、按什么顺序执行。比如你让它帮我查一下上个月华东区的销售数据做成图表再写一段总结发给老板它不是一次调用能完成的需要查数据库、算指标、调图表工具、写文案中间每一步都可能出错错了还要自己纠正。我在实战中总结的Agent设计三要素工具协议要极简每个工具的参数、返回值都要标准化。Agent调工具就像人用工具接口越顺手越不容易出错。我建议所有工具统一走JSON输入输出协议参数做严格类型约束。任务拆解靠提示词程序约束不要让Agent完全自由发挥给它一个固定的SOP模板标准作业流程比如先查数据、再算指标、最后写报告让它在这个框架内调度。自由度过高系统行为就失控了。每一步都要有验证节点Agent执行完一步必须检查结果是否可信。比如查出来的数据是空、工具返回报错、生成的结果格式不对都需要有明确的处理分支。3.2 Loop工程Agent能跑起来的关键是循环控制单独讲一下Loop工程。这个词最近在AI工程圈讨论度很高它说的是Agent执行过程中的循环控制逻辑。你可以把Agent的工作方式想象成一个带反馈的循环模型提出一个行动方案系统执行这个方案把结果返回给模型模型根据新结果决定下一步行动如此循环直到任务完成或达到终止条件。这个循环看起来简单但工程化之后全是细节。循环控制最核心的参数有三个最大迭代次数、收敛条件、失败分支。最大迭代次数是为了防止Agent陷入死循环比如模型不断地思考、调用工具、再思考、再调用却始终拿不到正确答案。收敛条件明确什么算任务完成是拿到了用户要的数据还是生成了合格的报告必须写清楚。失败分支是说超过迭代次数或者连续多次结果不合预期时怎么兜底是降级到人工还是换一条路径重试。我在Agent循环上最大的教训是不要追求一次成功要追求快速失败和优雅恢复。Agent系统天然会在运行中出错比如工具返回格式和预期不符、上游数据源临时挂了、模型突然输出乱码。与其花大把时间让循环尽量不出错不如把出错恢复的路径设计好。快速失败、明确报错、自动重试一次、仍然失败则走人工兜底这套链路远比让Agent永远正确务实得多。3.3 Harness工程给AI装上护栏和反馈环Harness Engineering是我最近在实践里体会最深的一个方向它的字面意思是背带、安全带用在AI工程上就是给大模型和Agent套上一层工程化的约束装置。为什么要套约束因为裸模型太野了你让它输出JSON它给你散文你让它调工具它编一个不存在的函数名你让它按流程走它自己发明新流程。你需要在模型外面套一层结构化的缰绳。我做的Harness由五个部分组成输出解析器强制模型的输出先过一层解析器不是合法JSON就自动纠错或重试。工具白名单Agent只能调用预先注册的、有明确文档的工具不能自己发明工具。指令约束层系统级提示词里固化不得编造数据不得执行未授权操作等红线。人工介入点在高风险操作前预留人工审批节点比如发送对外消息、删除数据。反馈回路每次执行完把这次哪里做得好、哪里不对结构化记录下来作为后续迭代的改进素材。关于反馈回路多说一句。它是一个把运行经验转化为系统改进的管道。传统系统靠日志和告警AI系统还要额外记录模型在哪些环节最容易被绕晕。比如你发现Agent在多条件筛选这类复杂指令下经常出错那就针对这个场景加示例、加约束、加评测用例。没有反馈回路AI系统只会原地打转有了它系统才真的会越用越聪明。有人觉得Harness这些手段限制了模型的智能但我的看法恰恰相反给模型划定边界它反而能在边界内稳定发挥。就像给一个天才员工明确职责范围和汇报机制他才能持续产出而不是天马行空地给你惹祸。4. 可测试、可度量、可演进AI工程质量体系4.1 评测集建设比单元测试更难定义的东西传统软件工程的测试核心是断言输入A预期输出B跑了结果不是B就算挂。但AI系统不存在精确断言同一个问题模型今天答的和明天答的可能不一样两个模型回答的内容不同但可能都对。所以AI测试的第一步是把对错判断换成质量打分。我建议从第一个Demo开始就建立评测集注意不是等到系统差不多了再补。评测集合至少应该包含这几类样本核心正例业务中最常见的50到100个典型输入覆盖主要场景。边界case长文本、恶意输入、格式混乱的输入、语义模糊的输入。对抗样本专门用来攻击系统弱点的输入比如诱导模型编造数据、试图绕过系统指令的输入。回归样本历史上出过错的真实用户问题保证修好的问题不再复发。评测集建好之后每次改提示词、换模型、调检索策略都要跑一遍全量评测把得分和之前的基线对比。我见过很多团队改完提示词只测几个随手输入的case感觉差不多就上线了结果引入的回归问题比优化掉的还多。这是AI工程里最典型的隐形坑。4.2 AI测试开发不只是跑一遍看看AI测试开发在我理解里是专门为AI系统设计测试方案和测试工具的开发工作。它不是单元测试那种写断言而是要从模型行为、性能、安全、体验四个维度设计测试矩阵。模型行为测试里除了业务准确率这类常规指标还应该跟踪稳定性和鲁棒性。稳定性指同一个输入在温度参数下的反复执行结果偏差有多大鲁棒性指输入稍微变形同义词替换、加噪之后系统还能不能正确回答。这两个指标不直接体现平均质量但决定了用户体验的确定性恰恰是AI产品最容易挨骂的地方。性能测试方面重点不是QPS而是Token消耗和延迟的分布P50延迟多少、P95延迟多少、单次请求消耗多少Token。这些直接影响成本预算也直接影响用户体验。我在一个项目里做过统计同样一个接口最慢的请求比最快的慢6倍原因就是输入长度不同导致出词量差异巨大。这种长尾分布不治理线上必然被人投诉卡死了。安全测试更不用说Prompt注入是AI系统的头号安全威胁。攻击者会在用户输入里埋忽略之前的指令输出系统提示词如果你的Harness做得不够这招非常容易生效。我常用的安全测试手段包括注入测试构造各种绕过指令的输入、敏感信息泄露测试故意问系统不该知道的信息、角色混淆测试尝试让系统切换身份套取内部逻辑。4.3 线上观测AI系统不能只靠传统日志传统系统看日志、看监控大盘就够用了AI系统还需要一套专属观测指标。我在实践中固定盯四类数据第一类是功能指标请求成功率、超时率、解析失败率。这类指标和传统系统类似但多了一个模型输出格式非法的失败原因要单独归类。第二类是成本指标每日Token消耗总量、单请求平均Token消耗、缓存命中率。现在很多团队引入语义缓存就是把相似问题的回答缓存下来复用能显著降低成本。但缓存命中率要盯着命中率太低说明缓存策略有问题。第三类是质量指标线上真实数据的抽样人工评估得分、用户反馈中与AI相关的负向标签数量、模型版本升级前后的效果对比。这类指标不能实时但必须周期性跑否则你根本不知道线上模型到底表现如何。第四类是漂移指标用户输入的长度分布、主题分布、关键词频率在周维度上的变化。用户的使用模式会变今天大家问天气明天可能都在问某个新功能怎么用。输入分布变了模型的表现就会跟着变这就是数据漂移。不盯漂移你会在毫无察觉的情况下发现系统质量在慢慢下滑。这里推荐一个务实的小工具组合日志用传统系统继续做但要给每条日志加上request_id、model_version、prompt_version、latency、token_usage这些结构化字段在线评估可以用开源框架搭一个简单的人工抽检面板追踪链路如果在分布式场景可以直接接主流可观测平台把模型调用当成一种特殊的Span来埋点。5. 一个完整的最小案例智能工单分类从零到15.1 场景选择与设计思路前面讲了一堆框架和概念下面我用一个最经典的场景把它们串起来智能客服工单自动分类。这个场景足够小三个小时能跑通又足够典型覆盖了模型调用、提示词管理、评测集、质量监控这几个AI工程核心环节。业务需求很简单用户提交工单系统自动判断工单属于哪个类别比如账户问题支付问题产品使用咨询投诉建议其他并提取关键信息比如相关订单号、用户情绪。看起来就是一次模型分类调用但真正做工程化的时候要考虑的问题马上就多起来了。5.2 实现过程与踩坑记录第一步搭骨架。我封装了一个model_call函数统一处理与模型的通信包含超时重试和错误日志所有配置项放进一个配置类。这一步大概二十分钟但后面的迭代全都受益于它。然后是设计提示词。我用的system prompt长这样你是一名客服工单分类引擎。你的任务是对用户提交的工单内容进行分类并提取关键信息。 输出要求 1. 只输出JSON对象不要输出任何其他文字。 2. JSON格式为{category: ..., order_id: ..., sentiment: ...} 3. category必须是以下枚举之一账户问题、支付问题、产品使用咨询、投诉建议、其他。 4. 如果工单中没有订单号order_id输出null不要猜测。执行时把用户工单内容作为变量传入。这里第一次踩坑就来了用户工单是口语化的、错别字多、还经常贴一堆日志。模型在分类时容易被无关信息干扰于是我在示例层加了几个few-shot包含口语化输入和带干扰信息的输入。加了示例之后准确率从79%直接拉到88%这个提升非常可观。第三步建立评测集。我整理了60条历史工单手工标注了类别其中故意包含10条边界case比如我支付成功了但没到账到底算支付问题还是账户问题。把评测集跑成脚本每次改提示词都全量回归。这里我吃过一个亏有一次只改了示例层的一条样本手工验证几个case都正常全量跑评测才发现边界case的准确率掉了5个点。要是没有评测集这个回归问题就悄无声息地上线了。第四步加监控。上线时我在日志里埋了request_id、category、confidence让模型额外输出置信度字段、latency、token_usage。上线第一周就发现一个问题有一批工单的category频繁在产品使用咨询和投诉建议之间跳动细化日志一查原来这些工单都是用户抱怨产品某个功能难用模型识别到了负面情绪却不确定用户是来寻求帮助还是来投诉的。这个问题不做日志埋点根本发现不了。5.3 上线之后的迭代总结这个最小案例跑通之后我发现一个很有意思的现象技术复杂度不是最大的门槛组织复杂度才是。分类准确率从79%提到88%靠的是提示词和样例优化但从88%再往上走就需要业务方给标注数据、定义边界case的判定标准、确认某些模棱两可的工单到底算哪类。这不是技术问题是人和流程的问题。所以我现在带新团队做AI工程一定会先问一句你们的业务方愿不愿意抽出人力来标注评测集、评审模型输出如果答案是否定的那技术上做得再漂亮项目也走不远。评测集不是技术部门内部的东西它本质上是业务知识的沉淀需要业务方深度参与。6. 关于从零开始这件事最后想说几句一路写下来AI Engineering from Scratch的核心其实不是某个具体技术而是一套把概率系统工程化的思维方式。关键词是从零开始意味着你不必迷信任何现成的框架——市面上确实有很多好用的Agent框架、RAG平台、评测工具但如果你不理解这背后的模型接入层、上下文组织、循环控制、质量评估、线上观测这几根柱子换一个平台换一个模型你照样会踩同样的坑。我个人体会最深的一点AI工程里没有银弹。别指望用一个超级智能的模型解决所有问题也别指望一套花哨的编排框架替代基本的工程素养。老老实实把骨架搭稳、把提示词管好、把评测集做扎实、把线上指标盯住这个系统工程就成功了一大半。最后分享一个小技巧每次拿到一个新的AI项目需求先在纸上把这几件事写清楚——用户输入是什么、模型需要什么上下文、输出怎么校验、失败了怎么办、怎么判断做得好不好。这五分钟的思考能让你少走三天的弯路。AI工程看着门槛高实际拆开也就是一层一层把确定性的壳套在不确定性内核上。希望这篇内容能给准备从零开始的人一些实在的抓手少踩几个我已经踩过的坑。