1. 为什么AI工程不是调包、写提示词而是一整套系统工程先说个我自己的经历。几年前我还是个传统后台开发者日常工作是写接口、调数据库、做服务治理听到AI应用的第一反应是这不就是调个API然后把返回的JSON拼到业务逻辑里吗直到我真接了一个内部知识库问答项目才发现完全不是这么回事。同一个模型同一份文档换了几个问法结果就飘用户的追问稍微带点指代系统就分不清更别提上线之后token成本、响应延迟、输出格式不稳定这些问题一个接一个冒出来。后来我才慢慢理解ai-engineering这个词之所以这两年频繁出现在工程师的讨论里是因为它确实代表了一类新工种。它不是机器学习研究不需要你推导损失函数、训练大模型它也不是传统后端开发不能靠输入确定、输出确定的思维来设计系统。AI工程的核心是把大模型当成一个不确定的组件用工程手段让它变得可控、可测、可维护、可迭代。这篇文章我想从自己从零开始建立AI工程能力的过程出发聊聊我眼中AI工程到底在做什么、需要哪些能力、从哪条路线切入最省力、实际落地时会遇到哪些坑。如果你也处于想入局但不知道怎么系统学习的阶段或者已经在做AI应用但总觉得哪里不对下面这些内容应该能帮上忙。1.1 AI工程和机器学习、传统软件开发的边界到底在哪先厘清概念。机器学习工程师通常关注的是模型本身的精度、训练效率、数据质量他们的产出物是一个模型文件或者一套训练流水线。传统软件工程师关注的是系统的确定性、并发、可用性他们的产出物是一套行为稳定的程序。AI工程师夹在两者中间但做的事情又不太一样。AI工程消耗的是别人训练好的模型不管是闭源API还是开源权重然后围绕这个模型构建应用。这意味着三件传统开发里不太会遇到的事第一输出不确定同样的输入可能给出完全不同的回答你需要设计评估和降级方案第二能力边界模糊模型能不能干这件事往往要试了才知道甚至同一个任务换几天后的模型版本效果就差很多第三成本随交互增长代码跑一次消耗的是CPU模型调一次消耗的是token思考怎么省token本身就是性能优化的主要手段。我见过不少团队用传统开发的思路去做AI应用最常见的表现是希望让RAG检索增强生成的召回率百分之百准希望Agent永远不要犯选择错误。说实话这方向就错了AI工程的目标不是消除不确定性——那等于不用大模型——而是在不确定性之上建立确定性。你需要的是量化它、兜住它、在关键路径上限制它。1.2 一个常见误区把提示词工程当成全部入门前我对AI工程的理解确实很狭隘觉得核心就是写提示词谁提示词写得好谁就厉害。深入之后才发现提示词只是最表层的东西。真正决定一个AI应用能不能落地的是下面这几层数据层你的知识库怎么清洗、怎么分块、怎么建立索引这决定了RAG系统的上限评测层你用什么数据集、什么指标来判断这次改动是变好了还是变坏了这决定了迭代的方向推理层模型选择、上下文策略、结构化输出这决定了回答的质量和稳定性系统层缓存、重试、限流、监控、审计这决定了线上能不能跑得稳安全层输入输出过滤、权限校验、数据隔离这决定了你敢不敢让它面对真实用户我接触过的很多失败项目问题都出在这几层中的某一层而不是提示词写得不够好。所以我在带新人时都会先说一句如果你只准备学一样东西先学评测而不是提示词。为什么因为评测是你的方向盘没有它你连自己开得好不好都不知道什么优化都是空谈。这个观点会在后文反复出现因为它是整个AI工程的方法论核心。1.3 哪些人最适合走这条路线AI工程的门槛比大多数人想象的低但天花板很高。就我的观察适合走这条路的人通常有几类第一类是有后端开发经验的工程师。懂数据库、懂缓存、懂服务治理做RAG和Agent系统时有天然的架构优势大模型的API对你来说不过是一个新型外部依赖。第二类是做过数据分析或大数据的人。评估集设计、指标统计、badcase分析这些工作本质上是数据工作者在干的事转到AI工程之后你会发现之前的统计学直觉非常有用。第三类是产品意识比较强的开发者。AI工程的应用形态还在快速演化今天能落地的产品形态、交互方式都不是定论。能够从用户体验反推技术方案的人在这个阶段的优势比纯技术能力强的人更大。不太适合的也有比如完全拒绝接受随机性的开发者或者希望趁热点速成、不想在底层工程上花时间的初学者。AI工程确实有不少套路但没有速成至少我没见过。2. 从零起步的技能升级路线我的技术栈与学习路径设计如果你是个想从零开始的人第一步不是去学LangChain也不是去背模型榜单而是先把底层的工程能力补齐再一层层往上叠AI相关的东西。我自己的路线可以概括为四个阶段每个阶段的侧重点完全不同踩过的坑也很有代表性。2.1 阶段一先稳固基础工程能力这个阶段不碰任何AI相关的东西目的是把地基打牢。具体来说有三个重点一Python编程。这是目前AI生态最友好的语言没有之一。你不用学得很深类、装饰器、生成器、类型注解这几个点掌握好就够用异步编程asyncio最好也了解因为大模型API的等待时间动辄几秒同步阻塞会把并发能力全毁掉。二HTTP和接口设计。AI应用的产出本质上是接口服务你需要理解RESTful设计、请求响应模型、错误码体系知道怎么设计一个让前端好对接、让外部系统好调用的API。三数据库和缓存。向量数据库只是数据库的一种新型索引方式你仍然需要理解传统的关系型数据库、KV存储知道什么时候用MySQL、什么时候用Redis、什么时候才需要pgvector或Milvus。我见过太多人一上来就往向量库里塞数据连最基本的数据建模都没做结果检索效果一塌糊涂。这个阶段怎么自测试着独立写一个带用户认证、数据库读写、日志记录的小型后端服务部署到云服务器上能稳定跑一个月就算过关。2.2 阶段二从一次API调用理解完整的应用链路第二步是做一次端到端的AI应用小实验。不要用任何框架直接用Python标准库或requests调用一个LLM的API实现一个最简单的问答脚本。关键是过程中你要有意识地问自己这几个问题这个API的输入输出结构是什么哪些字段是必填的温度、top_p这些参数实际影响输出到什么程度如果把用户输入原样拼进prompt会发生什么提示注入的入门体验网络超时、限流、API返回异常你的脚本能撑住吗我当时做这个实验的感受是一个Hello World式的调用藏着大量工程细节。等我把超时重试、错误分类、日志记录、成本统计这四件事都加进去之后代码量翻了七倍但我也真正建立了对AI应用复杂度的基本直觉。这里给你的实操建议是手写一次、跑通一次、加满工程处理再进入下一个阶段。2.3 阶段三掌握三类核心技术组件基础过关之后就要开始接触AI工程真正的几块硬骨头。根据我实际项目的使用频率优先级排序是这样的第一优先RAG检索增强生成。这是目前企业落地最多、最实用的方案。你需要掌握文档如何分块chunking、如何选embedding模型、向量化之后如何做相似度检索、检索结果如何和用户问题一起组织进上下文。看起来不难但每个环节都有坑我在第4章会展开细讲。第二优先结构化输出与校验。LLM返回的是自然语言但业务系统要的是JSON。怎么引导模型输出稳定结构的JSON、怎么用JSON Schema做校验、校验失败之后怎么自动重试这些是每个AI应用都绕不开的工程细节。第三优先多轮对话的状态管理。如果应用不是一次性问答就有上下文累积的问题。如何把历史对话精简化、如何在多轮之间保持主题稳定、如何控制输入模型的token总量这几年积累了不少技巧但核心思路仍然是控制好模型看到的内容。我建议在这个阶段就用LangChain或者LlamaIndex这类框架做一遍完整项目但不是无脑用而是每一个封装的接口都要去翻源码理解它内部做了什么。框架是用来提高效率的不是用来掩盖无知的。2.4 阶段四深入到评测、监控和优化循环走到这个阶段你才算真正摸到了AI工程的核心门道。框架、RAG、提示词都只是战术手段评测和监控才是战略中枢。这个阶段需要掌握的东西很具体怎么构造评测集收集真实用户问题、标注理想回答、区分可接受和不可接受怎么设计评估指标除了准确率、召回率这些经典指标还要考虑工程指标比如延迟、成本、重试率怎么做回归测试每次改prompt或换模型都跑一遍历史评测集防止修一个bug又弄坏一个功能怎么做线上监控记录每次调用的模型、token、延迟、用户反馈这些数据是持续优化的燃料我这几个阶段的痛点最后都指向一个答案——评测。在最早期我改prompt就像盲人摸象调完觉得好了就上线结果用户视角一测全是问题。后来老老实实做了几十条评测样本才第一次感受到知道自己改对了没有是怎样的体验。3. 从想法到上线一条可复制的AI应用主干链路技术能力铺开之后下一个问题就是一个真实的AI应用是怎么从想法走到上线的我把自己的开发流程拆了拆总结出一条通用链路每一步都对应具体的工具和参数。这条链路适用于绝大多数LLM应用无论你是做知识库问答、销售助手还是代码生成工具。3.1 第一步需求拆解明确可接受的错误率很多人做AI应用上来就写代码这是最容易走偏的开始方式。正确的做法是先用自然语言把需求说清楚这个应用给谁用、解决什么问题、用户在什么场景下会触发它、错误输出的代价有多大。举个可量化的例子如果做一个企业内部的制度问答机器人用户问年假怎么算模型如果引用错了一条制度代价可能是一个员工的假期被算错影响不小。这个时候可接受错误率就不能定得太高可能得控制在5%以下。但如果做一个头脑风暴助手用户要的是灵感回答偏一点完全无所谓错误率容忍度就可以放到30%。明确这个数字之后你才知道后面的步骤要做到多精细。我自己用的一个简单办法是给需求评三个维度——准确性要求、速度要求、成本上限每个维度打1到5分总分低于8分的需求优先做简单方案高于12分的需求才值得上复杂架构。3.2 第二步搭建最小评测集标注期待行为这是我在所有项目里最早做的一件事因为后面所有改动都需要有判断依据。最小评测集的规模不需要很大20到50条真实问题就够起步。关键在于每条问题要有配套的期待行为描述而不只是一个参考答案。比如这条评测样本用户问题我上个月请了三天病假会影响我的年假额度吗期待行为回答应该明确说明病假和年假的关系引用相关制度条款编号并提醒如果有医院证明需要提交给HR。不可接受行为直接回答会影响/不会影响而没有任何制度依据或者答非所问。为什么要写期待行为而不是参考答案因为LLM的输出天然有变体两句话不一样但可能同样正确。只有明确什么算对、什么算错的边界评测才能稳定打分。3.3 第三步选模型和定基础参数按场景做减法模型选择是预算和质量的平衡这里给一张我常用的对比维度方便你把需求摆到桌面上选对比维度闭源大模型API开源模型本地部署初始成本无硬件成本按量付费GPU服务器成本几万到几十万不等单次调用成本较高按token计费部署后边际成本极低效果天花板高持续更新取决于所选模型普遍有差距数据安全依赖服务商的数据政策完全本地可控运维复杂度无只管调用需要自行处理部署、扩容、故障恢复我的总体倾向是起步一律用API验证跑通之后再考虑换开源模型省成本。因为早期V1阶段最重要的是快速迭代API省掉了大量运维负担。只有当你的调用量稳定、prompt稳定、评测集也稳定时换开源模型才有靠谱的判断依据。基础参数也不是随便设的。温度参数默认用0.2到0.5之间需要创造性任务才调高需要稳定事实回答就调到0max_tokens一定要设防止模型失控输出一大段废话top_p一般保持默认跟温度配合使用效果最好。这里有一个容易被忽略的点每次调用最好显式传一个system prompt哪怕为空这样后续调整策略时不用改动所有调用点。3.4 第四步实现应用骨架从第一个能跑的版本开始接下来才是编码环节。我习惯用FastAPI搭后端因为自带OpenAPI文档、异步支持和类型校验三个特性都特别适合AI应用。下面是一个最精简的问答接口骨架你可以把它当成起点from fastapi import FastAPI, HTTPException from pydantic import BaseModel import httpx app FastAPI() LLM_API_URL https://api.example.com/v1/chat/completions API_KEY your-api-key class Query(BaseModel): question: str session_id: str | None None class Answer(BaseModel): answer: str cost_tokens: int latency_ms: int app.post(/ask, response_modelAnswer) async def ask(query: Query): start_time time.time() try: async with httpx.AsyncClient(timeout30) as client: resp await client.post( LLM_API_URL, headers{Authorization: fBearer {API_KEY}}, json{ model: your-model, messages: [ {role: system, content: 你是企业内部制度问答助手回答必须基于提供的制度内容。}, {role: user, content: query.question} ], temperature: 0.2, max_tokens: 1024 } ) resp.raise_for_status() data resp.json() answer_text data[choices][0][message][content] token_usage data[usage][total_tokens] except httpx.TimeoutException: raise HTTPException(status_code504, detail模型响应超时) except Exception as e: raise HTTPException(status_code500, detailf调用失败: {str(e)}) latency_ms int((time.time() - start_time) * 1000) return Answer(answeranswer_text, cost_tokenstoken_usage, latency_mslatency_ms)这个骨架有几个细节值得说明第一超时设定为30秒因为大模型的响应时间波动很大太短容易误伤、太长用户等不起第二返回体里包含cost_tokens和latency_ms这两个字段不是为了给用户看的而是为后续监控和成本分析打基础第三把session_id字段留出来多轮对话扩展时不用改接口结构。3.5 第五步日志、监控和灰度缺一不可接口能跑通只是开始真正的工程化是从加日志开始的。每次调用我至少记录以下几类数据时间戳、用户标识脱敏后、模型名称、输入和输出内容、token消耗、延迟、是否触发重试、用户的后续行为比如有没有点有帮助/没帮助。有了日志之后监控面板的内容就丰富了。我常用的面板指标包括每日调用量、平均延迟和P95延迟、token成本趋势、错误率分布、用户反馈标签的占比。这些指标不是用来看看的而是用来做决策的——比如P95延迟超过5秒了就要考虑换更快的模型还是加缓存某类问题的错误率突然升高大概率是上游知识库更新导致的。上线方式我也不建议一把梭。小流量灰度是成本最低的验证方式先用5%的流量测几天观察评测集之外真实用户的表现如果错误率、延迟、成本都在可接受范围再逐步放大。灰度期间我会手动看一部分badcase记下模型最容易翻车的模式作为下一轮优化的输入。4. 上下文工程被低估的隐性杠杆很多人在AI应用里犯的错不是模型选得不好而是喂给模型的内容不对。上下文工程在很长一段时间里是AI工程里讨论最少、但收益最高的领域。它管的事情是模型每次调用能看到的全部内容——系统提示、对话历史、检索文档、用户当前输入——如何组合、排序、压缩和更新。4.1 上下文窗口不是越大越好迷失在中间是真实存在的事厂商宣传上下文窗口从4K涨到128K、200K时很多人的第一反应是那我干脆把整本手册都塞进去。实际用下来你会发现模型对上下文的注意力并不均匀。有研究测试过模型对开头和结尾内容的关注度显著高于中间部分这被称为迷失在中间lost in the middle现象。也就是说你把关键信息放在文档中部模型很可能视而不见哪怕它在上下文窗口之内。所以我的第一个经验是不要把上下文窗口当作无限存储用。一个需要模型重点关注的指令或文档要么放在system prompt里位置优先级最高要么放在用户问题的紧邻位置位置优先级次高最危险的位置是长段参考资料的中间部分。4.2 上下文的标准结构模板每条发往模型的请求我会统一按照下面的结构组装上下文[系统指令区] 你是一个[角色]你的任务是[目标]。 你必须在回答中遵守以下规则[规则1、规则2、规则3] [知识参考区] 以下是回答问题时可以参考的资料 [检索到的文档块A] [检索到的文档块B] [用户输入区] 用户的问题是XXXX 注意如果资料中没有相关信息请直接说资料中未找到相关内容不要编造。这个结构的三段式有它的道理系统指令区负责设定角色和边界知识参考区负责提供事实依据用户输入区负责发起请求。三段之间用明确的分隔词区隔能显著减少模型混淆信息的可能。特别是最后一句资料没有就说没有不要编造这条指令极大地降低了我在知识问答场景下的幻觉率。4.3 RAG的常见优化链分块、检索、重排、引用RAG系统是上下文工程最典型的应用场景。我从一个能跑的RAG到一个好用的RAG先后做了四轮优化每一步都有明确的原因。第一轮优化是分块策略。一开始我用固定长度切块比如512字一切结果大量语义完整的段落被拦腰截断检索出来的内容经常前言不搭后语。后来改成按文档结构切块优先按章节、段落边界切切完的块如果超过上限再二次切。这个改动让检索内容的质量有明显提升原因是语义边界被保留了。第二轮优化是检索后的重排。向量检索的结果不一定按真正有用排序很多相似但并非所需的内容会排在最前面。我加了重排模型之后效果提升很大——这相当于在矢量检索之后多做了一个精排代价是每次查询多几十毫秒延迟但收益在准确率上非常值。第三轮优化是引用标注。让模型在回答中标注信息来源如根据《考勤制度》第三章第二条这既方便用户核对也倒逼模型更谨慎地使用资料。实测下来加了引用要求之后幻觉率下降明显因为模型需要把回答和上下文的某个具体位置绑定起来。第四轮是召回阈值调优。向量检索返回的相关度分数是一个很好的信号但不同文档集的分数分布差异很大。我会先跑一批评测样本画出相关度分数分布和是否真有帮助的交叉表找出一个合理的下限阈值低于该阈值的检索结果直接丢弃避免无关内容污染上下文。4.4 多轮对话中的上下文压缩控制成本的关键手段多轮对话的上下文管理是另一个大坑。最简单的做法是把全部历史对话原样发给模型但很快你就会得到一个用户和模型都觉得慢的响应以及飞涨的token账单。我的处理方式是把对话历史分成三个层次语义摘要层每3到5轮对话之后用模型对之前的对话生成一段压缩摘要包括用户已经提过的问题已经给出的结论仍未解决的问题原始消息层只保留最近2到3轮的完整原文因为用户的当前意图往往依赖刚刚说过的话业务状态层如果应用中涉及表单填写、流程推进要把结构化状态比如用户已确认预订日期待确认房间类型单独抽出来每次精确注入而不依赖对话原文这套三层结构解决了一个关键问题你既保留了长期的信息又不至于让token消耗线性增长。实测下来在多轮对话平均20轮的情况下这套方案比全量发历史节约50%到60%的token而用户体验几乎无损。4.5 上下文工程质量自检清单最后给一个自查清单每做一个AI应用前你都可以拿它过一遍系统指令是否明确说明了模型的角色、任务、边界和不许做的事知识资料放在哪个位置关键信息是否处于开头或结尾区域参考资料如果很长有没有为模型提供先定位再阅读的索引序言用户输入和资料之间有没有清晰的分隔模型能否区分你给的资料和用户的话有没有显式要求模型在资料不足时承认不知道多轮对话场景下历史消息有没有做压缩和状态抽取输出格式是否有明确的schema约束和校验如果你发现一半以上都答不上来那当前应用的质量瓶颈大概率不在模型能力而在上下文工程本身。5. 让Agent系统不失控可观测性与可靠性设计如果说RAG是AI工程的标准件Agent就是高端玩法。但Agent也给工程带来了新的挑战它不是单次调用而是模型自主决定调用什么工具、走什么流程、什么时候结束。这带来了极大的灵活性和不确定性也最容易让系统在线上做出不可预期的行为。这一章说说我在实际项目中沉淀下来的可靠性打法。5.1 Agent失控的常见形态你要防的是这几种先说清楚敌人长什么样。我踩过和帮别人排查过的Agent失控案例基本集中在三类循环空转模型反复调用同一个工具每次都得到相同结果但就是不停止。比如一个搜索Agent查不到信息就一直查一次对话消耗了上百次搜索。动作越权Agent被无意中引导去执行预期外的工具。比如一个只读查询Agent在用户请求下居然调用了写数据库的工具。幻觉合理化工具调用失败了但模型不是承认失败而是编造一个看似合理但没有依据的结果继续往下走。这些问题的技术本质是你在把一个不可预测的模型放到一个需要确定性的行为链路里。所以我的核心思路不是让模型更可控而是把不可控的部分隔离在可控的框架内。5.2 可观测性设计每一步都能回放Agent除错最困难的一点是它为什么不这样走、为什么那样走你看不到。所以第一件事就是给每个Agent调用加上完整trace。我自己设计的最小trace结构长这样{ trace_id: e8c5f1..., session_id: sess_88990, user_query: 帮我查一下上季度销售数据, steps: [ { step_index: 1, type: llm_call, model: gpt-4o-mini, input_tokens: 320, output_tokens: 85, reasoning: 用户需要查询销售数据需要调用数据库查询工具, chosen_action: query_sales_db, parameters: {period: last_quarter} }, { step_index: 2, type: tool_call, tool_name: query_sales_db, tool_input: {period: last_quarter}, tool_output_status: success, tool_output_summary: 共返回12行数据总销售额1250万 } ], final_answer: 上季度总销售额为1250万元, total_cost_usd: 0.0031, total_latency_ms: 8400 }这个trace的价值在于当线上出了问题你可以一笔一笔回放Agent的决策过程看到它在哪里选择了错误的工具、为什么选错、在哪一步开始偏离轨道。没有这个你只能对着最终错误结果瞎猜。我的建议是每条trace至少保留30天存入日志系统按session_id和trace_id做索引。当用户投诉时就拉出完整trace判断是模型决策问题、工具实现问题还是用户输入诱导问题再针对性修复。5.3 让Agent有边界地自主四道硬约束有了trace只是事后能查更重要的是事前防呆。我常用的四道约束按优先级排列如下第一道白名单工具机制。Agent可调用的工具必须在一个集中注册表里明确列出每个工具带独立的权限描述。模型只能在白名单里选工具不存在的工具或超出权限的工具直接不允许出现在选择列表中。这道做得好的话绝大多数越权行为在第一层就被拦住了。第二道单轮最大步数限制。给Agent的每次任务设定最大执行步数比如10步。达到步数上限而任务未完成时强制进入总结并移交人工的状态。这直接解决了循环空转问题。第三道危险操作需要二次确认。对删除、写库、发送消息这类有副作用的工具设计一个人工确认闸口。Agent可以生成我想执行该操作的请求但真正执行前需要用户点击确认。这个设计牺牲了一点点自动化率但保住了整个系统的底线。第四道输出结构校验。每轮Agent的输出不只检查内容还要检查类型和结构。如果模型说要调用query_sales_db但传入的参数不是JSON对象、或者缺少必填字段整轮决策直接重来而不是硬着头皮执行。5.4 用反馈闭环喂养评测集Agent系统上线后还有一件特别重要的事情把线上用户反馈和异常情况回流到评测集。每次用户点了没帮助每次Agent中途失败、超时、被人工干预都是宝贵的学习样本。我会每周花半小时把这一类的badcase筛选出来归入评测集并标注期待行为。下一轮Agent的策略调整、提示词优化、工具设计改进都用膨胀后的评测集做回归测试。这个节奏坚持三个月之后你会发现Agent的稳定性提升非常明显——不是因为它变聪明了而是因为你用评测集给每一次改动兜住了底。我个人在大规模Agent项目上的体会是Agent不是一个你写完就能不管的组件它是一个需要持续投喂数据、持续回归验证的系统。把反馈闭环建好Agent就会越跑越稳否则它就会像一个没有纪律的天才状态好的时候惊艳状态差的时候让你想删库跑路。6. 实战复盘我返工最多的问题与规避清单做了几年AI工程之后回看有一类坑特别有意思它们看起来是随机踩的实际上几乎每个项目都会重演一遍。我把踩过且代价最大的几个问题整理出来希望你能绕开。6.1 评测集建得太晚等于开车不看路我在第二个项目里犯的这个错误最典型。当时花了两周时间精心调prompt、优化检索逻辑感觉效果每天都在变好。结果一上评测集核心指标反而从68分掉到61分——之前所谓的变好只是个别case的主观感受系统整体并没有变好。这个教训让我把先建评测集写进了自己所有项目的启动清单。没有评测集的优化是自嗨。现在我要么第一天就搭一个最粗糙的评测集哪怕是10条问题要么就明确告诉自己当前处于探索阶段所有改动不做效果结论。6.2 Prompt和模型没有版本管理改坏了没法回退传统代码有Gitprompt和模型配置也应该有版本管理。最开始我把prompt直接写在代码里每次调整都是改完直接上出了问题时根本不知道是prompt改坏了还是模型升级导致的。现在的做法是用配置文件统一管理# prompt_config.yaml version: 3.2 model: gpt-4o-mini temperature: 0.2 system_prompt: | 你是企业内部制度问答助手回答必须基于提供的制度内容。 如果制度内容中没有相关信息直接说明未找到不要编造。 rag_settings: chunk_size: 512 top_k: 5 similarity_threshold: 0.42每次修改prompt或选型时同步更新版本号并在修改记录里写好为什么改、预期改善什么、评测前后分数是多少。这样做的好处是发现效果变差时可以快速回退到上一个配置而不是在代码里翻历史。6.3 没估算token成本就上线月底账单吓人一跳这是我第一次做线上项目时的真实经历功能是好了但一个月跑下来token账单比我预想的高了8倍。原因是我没有估算调用量部分用户高频使用而且长上下文的请求占用了大量token。现在每个项目上线前我都会做一次成本预演公式很简单月成本 ≈ 日均请求量 × 平均请求token数 × 每token单价 × 30具体算一步你就明白为什么容易失控。假设日均请求量1000次平均每次请求包括system prompt、历史对话和输出共3000 token模型单价是每百万token约15元那么月成本就是1000 x 3000 x 15 / 1000000 x 30 1350元。如果系统再叠加RAG检索和Agent多轮调用token消耗会按步数倍增成本直接呈数量级上升。控制token的主要手段我在上下文工程那章已经讲过——压缩历史、精简提示、设置max_tokens这三板斧能把成本砍掉一半以上。6.4 高估模型的推理能力任务设计过于复杂另一个高频教训是我总想让模型一口气完成一个复杂任务比如先抽取信息再判断意图再生成回答。结果模型在一个环节出错后面全部跟着错排查起来非常费劲。后来我学到一种更可靠的做法把复杂任务拆成多个简单步骤每步只做一件事步与步之间插入确定性校验。举个例子与其让模型在一次调用里完成从用户消息判断是否需要调用工具、调什么工具、生成参数不如拆成两次调用先用一个低成本的模型做意图分类再根据分类结果决定下一步动作。每一步的产出都可以校验出了问题可以精准定位到具体环节。这话听起来有点反直觉多调用一次模型成本变高了但稳定性的提升远超成本增加。我自己在复杂业务场景里的判断标准是如果某一步模型出错的代价大于多调用一次的成本那就拆开做如果任务简单到模型几乎不可能错那就不用拆。6.5 规避清单汇总最后把返工点汇总成一张自查表你每做一个AI应用过一遍这张表能省下很多时间坑症状预防手段评测集缺失改prompt靠感觉效果无法量化第一天就建20条核心评测样本没有版本管理改坏后无法回退prompt/模型配置纳入版本控制成本估算缺失月账单失控上线前用公式估算设定成本红线任务链路过深单点出错导致全链路失败拆解任务、环节间增加确定性校验忽略超时重试模型偶尔超时用户请求失败设置合理超时、指数退避重试输出不做校验格式错误导致下游解析异常用schema校验失败自动重试或降级无灰度意识全量上线后暴雷5%流量灰度跑几天观察数据再放量7. 走出入门阶段之后我接下来要啃的关键方向AI工程这个领域变化太快了每半年回头看之前的最佳实践可能都要修正。但在快速变化背后有些方向性的东西是相对稳定的值得你在完成主线学习后持续投入。第一个方向是评测工程的深化。我现在搭建的评测集还停留在几十到几百条手工标注但真正成熟的AI应用需要的是多层次的评测体系单元评测、场景评测、线上A/B测试、对抗性攻击测试。我下一步打算研究的方向是用大模型自动生成评测样本和评估结果把评测从人工密集型变成半自动流水线。这一个方向值得任何AI工程师花时间因为评测体系的优劣直接决定迭代效率的优劣。第二个方向是多模态应用的工程化。文本之外图像理解、音频处理、视频分析正在成为应用的新常态。这些场景的上下文工程、结构化输出和监控体系都有自己的特殊性。我有预感未来一年里能独立把多模态任务端到端落地的人会是人才市场最稀缺的一类。第三个方向是端侧和边缘部署。不是所有应用都适合把数据发到云端隐私敏感和网络不稳定的场景越来越多需要把模型跑在手机上或边缘服务器里。量化、剪枝、模型压缩这些词会从ML研究人员的嘴里逐渐变成AI工程师的日常词汇。第四个方向是成本与效率的持续优化。模型能力会持续增强但贵和慢这两个问题会长期存在。缓存策略、模型路由简单问题走小模型、复杂问题走大模型、蒸馏与微调这些方向上的积累会让你对任何项目的预算都更有掌控力。如果你也在走这条路我的建议很简单找到一个小而完整的真实问题用全文提到的完整链路把它做上线跑上一个月。亲手经历过一次评测、调优、监控、修bug的循环比看一百篇文章都有用。AI工程最终是个实践学科动手越早思考才能越深。最后说一个我最近才真正想明白的小心得AI工程的核心竞争力不在你会用哪个框架、调哪个模型而在于你能不能为一个不确定的世界搭出确定的流程。这个能力在任何技术浪潮下都不会过时。