如果你最近也在关注AI工程这个方向大概率会看到一个现象讨论的人很多但能把从零开始到底该学什么、怎么做讲清楚的内容少之又少。我自己的经历就是从后端开发半路转过来的一开始以为AI工程就是调模型、写Prompt后来才意识到它其实是覆盖数据清洗、模型调用、检索增强、效果评估、Agent编排、成本治理的一条完整流水线。这篇文章不是教科书而是把我从零到一实践AI工程时踩过的坑、验证过的路径、以及沉淀下来的方法论尽量完整地分享出来。适合想入门的开发者、正在搭建AI应用的工程师以及所有被AI工程这个词绕晕的人。1. AI工程不是调模型而是一条从数据到交付的流水线1.1 先给AI工程划一个清晰的范围很多人对AI工程的第一印象是写Prompt或者微调模型这两个确实相关但都只是冰山一角。我给它下的定义是用工程方法让大语言模型稳定、可控、可度量地完成业务任务。这里面有三个关键词稳定、可控、可度量。稳定意味着同样的输入不能今天能跑明天就崩可控意味着模型输出要符合格式、长度、规则可度量意味着每次改动的效果好坏有数据支撑不是拍脑袋。用后端开发的类比来理解传统接口的入参和出参是契约明确的你调用一个函数输入合法就一定有预期输出。大模型不是这样它是一个概率系统同样的Prompt加同样的参数两次输出可能差出一大截。AI工程要做的就是在这层概率之上搭建确定性框架。比如用结构化输出约束JSON格式用检索增强减少幻觉用评估集提前发现回归。这些都是工程问题不是单纯的模型问题。1.2 为什么很多项目死在Demo很好、上线完蛋我在实际工作中接手过不少AI项目也见过身边团队从兴奋到崩溃的全过程。最常见的死法是Demo阶段用精心挑选的三个问题验证效果惊艳一到线上面对真实流量所有问题都露出来了。输入措辞一变化结果就跑偏PDF里有一张扫描表格解析出来全是乱码用户连续追问三个问题上下文窗口直接爆掉。我总结下来这些失败几乎都指向同一个根因把模型能力误当成系统能力。模型本身能写诗、能总结、能推理但你的业务流程里还有大量非模型环节——文件解析、数据去重、提示词组装、结果校验、错误重试、成本控制。这些环节任何一个出问题整体体验就是崩的。这也是为什么我会强调AI工程的第一课不是学模型而是建立系统视角先画清楚你的数据流再考虑模型放在哪个位置。2. 要补的地基大模型原理、Token思维与Prompt工程核心2.1 不用重学数学也能建立的模型直觉网上太多文章一上来就是Transformer架构图、注意力机制公式说实话大部分人看完就劝退了。我的经验是初期不需要做自回归模型和Embedding的数学推导但你要建立几个必要的直觉。第一个直觉是Token思维。模型不是按字阅读文本的而是把文本切成Token可以理解为词元这几个Token的组合决定理解结果。中文一个汉字经常被切成一到两个Token英文一个常用单词可能就是一个Token。这直接影响两个事一是上下文窗口能装多少内容二是计费成本。我在项目里经常遇到超长文本存不进去的问题很多人第一反应是换更大的模型实际上先做文本切分和摘要压缩就能缓解大半。第二个直觉是概率生成。模型下一个Token的选择是概率分布的采样结果temperature参数就是在调节这个分布的平滑度。temperature调低输出更确定但可能呆板调高输出更丰富但容易跑偏。工程上的建议是需要事实准确的任务比如抽取、分类把temperature压到0.1左右需要发散创意的任务比如文案生成可以放到0.7以上。但这个值不是越极端越好我在实测中发现0到0.3之间才是大多数稳定任务的安全区。2.2 Prompt工程的三层进阶指令、人设、结构化输出Prompt工程看起来入门门槛很低写几句中文就能和模型对话但从能用到稳定用中间是有几个台阶的。我把它拆成三层。第一层是指令明确。不要写帮我总结一下这段内容而要写请提取以下文本中的3个核心观点每个观点用不超过50字描述。指令越具体模型执行越稳定。关键技巧是把怎么做说清楚比如限定输出语言、字数、格式、是否需要引用原文。第二层是人设与上下文。给模型一个角色定位你是一名资深后端架构师再提供少量示例few-shot效果往往比单纯堆指令好。尤其是few-shot示例我建议在示例里刻意放一个错误改对的对比模型能学到的不只是格式还有改善逻辑。第三层是结构化输出。这是工程上最重要的一层。早期我让模型直接输出JSON十次里有两三次带多余解释文字解析必挂。后来用两个手段解决一是在Prompt末尾明确写仅输出JSON对象不要包含任何其他文字二是用函数调用Function Calling或JSON Schema约束输出。现在主流模型都支持结构化输出模式能让JSON解析成功率接近100%。我在项目里会把这一条列为硬性规范谁写Prompt不带格式约束谁就要负责在解析层兜底。2.3 Agent的基本范式ReAct、工具调用与记忆如果只是单轮问答其实用不到Agent这个词。Agent的核心是让模型在循环里自主决策根据目标推下一步动作调用外部工具观察结果再决定继续还是结束。这个循环的经典范式就是ReActReasoning Acting模型先写推理过程Thought再决定动作Action工具返回结果Observation如此循环直到任务完成。工程落地时工具调用是关键。模型不能直接执行代码它只是输出一个结构化的调用请求你的系统负责解析、执行、返回结果。这个设计决策很重要所有带副作用的操作比如写数据库、发消息、改配置必须经过你的代码层审核不能信任模型的自动行为。我见过一个实验项目让Agent自己调用删除接口结果因为Prompt里的一个小歧义把测试环境的脏数据全删了。从那以后我的原则是读类工具可以完全放开写类工具必须加二次确认。记忆模块也很容易被忽视。LLM本身没有记忆所有历史信息都要拼进上下文。常见的做法有短期记忆把对话历史塞进窗口、长期记忆用向量库存关键信息按需检索、以及工作记忆把任务状态写进一个结构化变量。我建议从简单做起先用对话历史固定窗口撑住大多数场景不要一开始就上复杂的记忆系统否则调试成本会翻好几倍。3. 从零搭一个带知识库的AI应用RAG完整落地记录3.1 技术选型为什么先用RAG而不是直接微调很多人在要不要微调这个问题上纠结很久。我的建议很直接能检索增强RAG解决的不要微调。微调的三大痛点是需要高质量标注数据通常至少几千条、训练成本高、模型更新后要重新训。而RAG的思路是把知识放在外部的向量数据库里用户提问时先检索出最相关的片段再拼进Prompt一起交给模型回答。一句话理解RAG给模型配一个开卷考试的参考资料。模型不需要背下你的内部文档只需要学会在给定资料里找答案。这在知识库问答、客服辅助、文档摘要场景下是性价比最高的方案。我个人的选型标准是如果业务知识会频繁变更比如产品文档每周更新无脑选RAG如果你需要模型学会特定表达风格或专业领域推理逻辑比如病历诊断、代码风格迁移才考虑微调。两者也可以组合使用先RAG后微调但那是后期优化的事入门阶段不建议碰组合复杂度。3.2 环境准备与最小可运行链路我第一次搭RAG时走了不少弯路核心原因是把链路想复杂了。其实最小可运行链路只有四段加载文档 → 切分 → 向量化 → 检索拼装。中间每一步都有现成工具初期不需要造轮子。我以Python环境为例实际操作时可以这样搭# 安装核心依赖示例 # pip install langchain langchain-community chromadb openai from langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.vectorstores import Chroma from langchain_openai import OpenAIEmbeddings # 1. 加载文档 loader TextLoader(knowledge_base.txt, encodingutf-8) docs loader.load() # 2. 切分文档 splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, separators[\n\n, \n, 。, , ] ) chunks splitter.split_documents(docs) # 3. 向量化并写入向量库 embedding OpenAIEmbeddings(modeltext-embedding-3-small) vectorstore Chroma.from_documents(chunks, embedding, persist_directory./chroma_db)这里有几个非常容易踩的坑。第一个是chunk_size的选择太大检索到的东西太泛模型答不到点子上太小信息碎片化上下文不完整。我的经验是中文场景从400到800字起步再根据实际效果调。第二个是chunk_overlap相邻片段之间要留一点重叠否则一个知识点被切在边界上就检索不到了。第三个是切分器的separators顺序先按段落切再按句子切这样能最大限度保留语义完整性。检索拼装的环节同样有讲究。构造的Prompt要明确告诉模型你只能依据以下资料回答如果资料中没有相关信息请直接说明你不知道。 不加这句话模型很容易穿越到自己的训练记忆里输出资料之外的内容幻觉率会明显上升。3.3 检索质量才是RAG的生死线我在把RAG项目推到生产环境之后最大的体会是用户感知到的回答质量约70%取决于检索质量而不是生成质量。举个例子如果资料库里有三份类似规格文档检索到的却是最旧的那版模型再聪明也会答错。所以RAG工程的核心工作其实是打磨召回和排序。先用一个表格说明召回阶段需要关注的参数参数作用我的建议初始值chunk_size决定每个检索单元的长度中文500字符左右top_k返回几个相关片段3-5个score_threshold相关性过滤阈值0.3-0.5视embedding模型而定embedding模型决定向量空间质量优先选更新、维度适中的商用模型检索质量差通常从两个方向排查一是查召回率看关键信息是不是根本没被检索到如果是要么切分粒度不对要么embedding模型能力不足二是查准确率看检索到的内容与问题是否相关如果不相关可以调整top_k或者在检索后加一轮重排Rerank。重排是高级玩法原理是拿一个交叉编码器模型对候选片段重新打分能把准确率拉高不少。成本会增加但如果你的场景对准确性要求高值得投。另外我强烈建议做一个黄金测试集提前准备20-50个真实业务问题每个问题标注正确答案应该引用哪份资料然后跑一次流水线计算检索命中率。没有这个测试集你后续改任何配置都无法判断是变好了还是变差了。4. 上线前必须想清楚的事评估、可观测性与成本4.1 没有评估集的AI工程是盲人摸象AI项目最大的工程痛点是没有明确的正确/错误边界。传统软件有单元测试输出对错一目了然大模型是开放式的同一句话可以有一百种表达。所以AI工程必须把评估当成第一等公民来设计。实用的做法是三层评估。第一层是规则评估模型的输出是否符合格式要求、是否包含关键词、长度是否合规这类可以直接用代码断言。第二层是模型评估让一个更强的模型比如GPT-4级别的评判模型当裁判按照你给的评分标准给输出打分适合判断回答是否准确这类主观任务。第三层是人工抽检定期把线上真实请求拿来看记录用户的反馈模式发现规则和模型评估都漏掉的问题。我工作中会维护一个evaluation/文件夹里面按场景放测试用例。每次改动Prompt、换模型、调参数先把整个评估集跑一遍看分数变化。没有这个过程你所谓感觉效果好多了其实不具备任何说服力。4.2 日志、追踪和AI可观测性到底在解决什么问题AI工程里调试一个坏回答的难度比传统后端高很多因为问题可能出在Prompt、上下文、检索结果、模型温度、参数解析任何一个环节。我早期排查问题靠肉眼翻日志效率极低。后来引入全链路追踪才算真正看清每一轮Agent循环里发生了什么。你需要记录的核心信息包括用户的原始输入、构造出的最终Prompt包含检索资料和对话历史、模型返回的完整输出、Token消耗、耗时、调用链中每一步的中间结果。把这些落到日志里问题一旦出现你就能回放整条链路哦原来是这一步的检索结果没召回正确资料而不是对着一个坏答案瞎猜。市面上有LangSmith、Langfuse这类工具也可以先用最朴素的方式在代码里埋点打印JSON日志。我自己的顺序是先有日志后有工具。一开始不要为了可观测性上太重的系统把关键的入参、出参、中间结果打出来就已经能解决80%的问题。4.3 Token账单那些看不见的成本黑洞很多人做AI工程的时候注意力全在效果上对成本几乎没概念。我给一个简单的计算方式一次问答的Token消耗 系统Prompt 用户问题 检索片段 历史对话 模型输出。其中检索片段和历史对话往往是最大的开支但它们最容易被忽略。比如一个Agent要跑五轮工具调用每轮都把历史全量塞进去成本会呈线性甚至超线性增长如果一次调用传入了5000 Token的系统Prompt而有效信息只有500 Token那90%的钱就白花了。控制成本的通用手段有三个。第一是压缩上下文把历史对话做摘要只保留关键结论让检索片段尽量短而准系统Prompt定期精简。第二是分层模型简单任务比如文本分类、实体抽取用小参数模型复杂推理任务才用旗舰模型。第三是缓存对重复性问题做结果缓存或者在模型层面使用按内容哈希的缓存机制。我在实践中发现做好这三件事成本往往能砍掉一半以上效果几乎不受影响。上线前还要定一个预算上限设置告警。AI系统的成本波动很剧烈一个被异常刷量的用户可能在几小时内烧掉你一个月的预算。我在生产环境一定会把每次请求的Token数记下来按用户和场景聚合异常增长立刻告警。5. Agent工程的深水区多步编排、边界控制与失败恢复5.1 从单次调用到Agent循环系统复杂度如何变化当你决定把AI应用从问答机器人升级成能自己干活的小助手时复杂度不是线性增长而是指数级增长。单次问答的失败模式只有模型答得不好Agent循环的失败模式却包括工具调用格式解析失败、模型连续做出错误决策、循环停不下来、中间状态丢失、副作用操作重复执行。我建议把Agent当微服务来设计每个工具就是一个独立的服务有自己的输入输出契约和错误处理。Agent本体只负责决策和编排不负责业务实现。比如一个查天气并提醒带伞的Agent查天气是一个工具推送提醒是另一个工具Agent只负责解析用户意图、按顺序调用、汇总结果。这么做的收益是所有工具都可以单独测试、单独替换出问题也不用整个系统跟着挂。还要给Agent一个生命周期上限。我见过最典型的失控场景是Agent在调用工具失败后不断重试越错越乱最后循环了几十次Token烧了几万个。解决办法是设置最大迭代次数比如5-8次到了就终止并告知用户结果未完全处理每次工具调用也要设置超时时间防止外部接口卡住整个链路。5.2 工具调用的稳定性格式错误、超时与幻觉工具调用是Agent链接外部世界的桥梁也是故障率最高的地方。我踩过最典型的坑就是模型输出的工具调用参数偶尔不合法。比如定义了一个查询订单工具参数是order_id字符串模型偶尔会传成null或带引号的数字。后来我用两把锁解决一是用JSON Schema严格约束参数格式并要求模型必须按Schema输出二是在解析层做兜底校验解析失败就返回错误信息给Agent重新生成而不是直接抛异常。超时问题同样频发。外部工具数据库、第三方API响应时间不可控Agent等不到结果就可能误判工具没生效然后重复调用。我的做法是每个工具都设定明确超时一般5-10秒超时返回工具调用超时请稍后再试同时给Agent一个判断规则同一个工具连续调用失败两次就放弃并转人工兜底。还有一个容易被忽视的问题叫幻觉性工具调用模型会编造一个不存在的工具名或者虚构一个工具返回结果只要你的系统允许了这种可能后面就会跟着一串错误。我的对策是两层封堵。第一在任何Prompt里都声明只能调用上述列表中的工具且必须等待工具实际返回结果后再继续。第二工具名做白名单校验参数做类型校验模型说调用了一个没注册的工具直接视为非法并反馈错误。这两个手段叠加后这类问题基本绝迹。5.3 我踩过的几个典型Agent坑及修复思路这里分享三个我印象比较深的实战问题。第一个是多轮任务的状态丢失。我给Agent设计了先查库存再下单的流程结果用户在中间环节换了个商品Agent还在用旧商品的信息做下单决策。根因是我把状态只放在上下文中一压栈就丢。修复方案是把关键状态当前选中的商品ID、订单类型、用户地址显式存在结构化变量里每次工具调用前用状态覆盖旧上下文。第二个是连续错误决策导致的南辕北辙。Agent在一次任务中连续三次选择了错误的工具而且每次都很自信。排查后发现问题是系统Prompt里的目标描述太抽象Agent根本不知道优先级。修复是我把任务拆成了阶段性子目标第一步先确认用户数量第二步校验库存第三步生成订单每一步完成前不允许跳到下一步。把流程写进Prompt后决策稳定性明显提升。第三个是死循环与自我协商。某个Agent在整理数据任务里不断调用查看数据工具然后觉得数据不完整又去调用写入数据工具反复横跳。这其实是目标定义不明确的体现。修复方式是引入一个简单的状态机每轮循环结束时Agent必须输出一个表示任务进度的枚举值进行中/已完成/无法完成只有进行中可以继续循环其他情况必须结束。一旦有了明确终点循环失控的概率就大大降低。6. 从个人项目走向团队协作AI原生研发的实践感悟6.1 AI辅助编程的真实收益与使用边界AI Native研发范式这两年被反复提及我在实战中的感受是它确实能显著提升个人生产力但对团队来说更重要的是定义清楚AI辅助的边界。以我自己的几个项目为例让AI写SQL、写Shell脚本、做代码格式化这类确定性任务能给到质量不错的产出我只需要做代码审查但涉及跨模块架构决策、数据一致性方案、复杂性能优化时AI的产出往往看起来对但经不起推敲。所以我的建议是把AI定位成高级结对程序员而不是自动写码机。让它快速产出初稿、补全样板代码、生成单元测试框架再由人类工程师把关关键逻辑。在提交评审时AI生成的代码同样要经过常规的Code Review流程不能因为是AI写的就降低标准。我见过有些团队为了追求AI采用率指标直接把AI生成的代码合进主干结果安全事故频出后来又退回去人工审查。还有一个非常实际的点AI生成的代码里经常带着幻觉API。它可能调用一个从未存在过的函数或包看起来特别合理一运行就是ImportError。应对方案是让AI在生成代码时附带测试命令或示例调用同时保留小步验证的习惯每次生成后立刻跑一遍最小测试。6.2 团队协作中如何管理Prompt、数据集与版本个人项目里Prompt写在哪、数据集放哪、版本怎么管都是小事。到了团队这些就成了事故高发区。最常见的现象是Prompt写在某个同事的本地文件里改了一版忘了注释为什么改数据集散落在聊天记录里没人知道最终版是哪一份模型升级后发现了回归却不知道是Prompt变了还是数据变了。我的经验是把AI工程资产当成代码一样管理。Prompt以Markdown或YAML文件形式入库每个Prompt带上使用场景说明和版本历史数据集包括评估集放在独立目录按日期和用途命名用Git LFS管理大文件每次Prompt或参数变更必须关联一次评估集跑分记录。团队小的时候这听起来繁重但一旦规模上来这套规范会救你很多次。另外我还推荐在团队内建一个踩坑Wiki把每个模型版本的已知问题、每个工具调用的异常模式、每个数据切片的缺陷记录下来。AI系统的问题往往是非确定性的这次复现不了、下次又出现如果没有记录同一类坑你会反复踩很多次。这个Wiki不需要很正式随手记定期整理价值很大。6.3 给零基础入门者的学习路线建议最后聊聊从头开始学AI工程到底应该怎么排优先级。我经常被问到类似的问题我的答案永远是不要从论文读起要从跑通一个最小Demo开始。先调用一个大模型接口写一个最简单的问答程序感受Token和温度参数然后做RAG加一个本地知识库体验检索对回答的影响再往后做Agent加工具调用处理循环和错误。每一步都动手做一遍比任何课程都有效。在动手的同时有把握地补理论。可以学习一些Prompt技巧、注意力机制的直观理解、向量检索的基本概念。不需要学透但要知道为什么这么设参数大概会更好。等有了阶段性的实际项目再回头读论文你会突然发现那些抽象的概念都活了。我给入门者安排的时间参考大概是这样第一周跑通API调用和Prompt基础第二到三周实现一个RAG问答第四到五周加一个简单的Agent工具调用第六周开始做评估集和成本控制。两个月左右你就能对AI工程的全貌有真实的掌控感。之后的道路就顺理成章了要么往深度走钻研检索质量、模型微调要么往广度走研究多Agent协作、AI落地架构。无论哪个方向你都已经不是从零了。结合我自己的感受说一句AI工程是个慢功夫但它的门槛恰恰不在模型而在工程意识。把数据流画清楚把评估做扎实把边界设明确这些看起来不起眼的习惯最后决定了你的AI应用是玩具还是产品。希望这篇文章能让你少走几步弯路。如果你看完之后也想从一个小项目开始尝试那就挑一个日常最耗时的重复任务先用RAG把它做成一个问答工具再慢慢加Agent能力动手之后你会发现所谓的AI工程其实并没有那么玄。