从零开始搭建AI工程体系这件事我前后折腾了差不多两年。最早我也是一个一个API去调写完一个能聊天的demo就觉得自己已经会AI了。直到后来真正要交付一个能稳定处理真实业务数据的系统才发现自己之前的认知基本停留在“调接口”层面。如果你也正处于“能写demo但不会做工程”的阶段或者已经在做 AI 应用但总觉得方法论不成体系这篇内容就是我想分享的整套路线。AI工程从零开始从写demo到交付系统的实战路线先把我对AI工程的理解说清楚它不只是写提示词也不只是调大模型API而是围绕“模型能力”构建的一整套工程系统包括数据准备、提示词设计、检索增强、Agent调度、评测反馈、部署运维。这个领域和传统软件工程有一个核心区别传统工程的产物是确定性的代码而AI工程的产物是概率性的模型行为。你能控制的不再是每一条执行路径而是模型的输入分布、约束条件和反馈回路。这篇文章适合正在做AI应用开发、准备转型做AI工程或者已经在带AI项目的朋友我会把核心环节的原理、踩坑记录和可落地的步骤全部拆开讲。1. AI工程从零开始到底要学什么1.1 先搞清楚传统工程和AI工程的边界我在带团队的时候最常被问到的问题就是以前做后端、做前端的经验放到AI项目里还有用吗答案是有用但需要做一次认知层面的切换。传统软件工程处理的是确定逻辑。比如你写一个订单系统输入下单请求经过库存扣减、支付回调输出订单状态每一步都可预测、可测试、可回滚。而AI工程面对的是概率系统。模型根据你给的上下文计算出一段最有可能的回复但这段回复不保证对甚至同一句话问两次答案可能不同。这意味着传统那套“单元测试覆盖分支逻辑”的思路不能直接照搬。我见过很多团队在AI项目上“翻车”翻车的原因往往不是模型不够强而是把模型当成了传统函数来用。举个例子有人直接让模型从用户反馈中提取结构化字段不做输出约束也不做校验结果线上跑了一周解析出的数据里混入了模型自编的日期、人名和编号。这不是模型的错是工程上没有对概率输出做控制和兜底。从零开始学AI工程首要任务不是学某个框架怎么用而是建立一套和传统开发不同的思维模型。你要关注的不是“代码分支是否完备”而是“数据分布是否可控、输出边界是否清晰、失败路径是否有人兜底”。1.2 一个合格的AI工程师需要哪些能力面板我在面试AI工程师的时候会重点关注五个维度的能力这五个维度也正好对应AI工程的核心环节第一个是数据能力。AI系统的效果上限由数据决定不是由模型决定。你能不能把业务原始数据清洗成模型可以消费的格式能不能判断哪些数据需要进入提示词、哪些数据需要存进向量库这直接决定系统能不能跑。很多从传统开发转过来的人对数据的情感是“数据是别人的事”但AI工程里数据就是你代码的一部分。第二个是提示词工程能力。这并不是简单的“会问问题”而是能根据模型特性设计出稳定的行为协议。同一个任务用不同的提示词结构输出质量的差距可能是毁灭性的。这块内容我后面会专门展开。第三个是评估能力。这是最容易被低估的。传统开发有明确的断言AI项目没有。你需要自己设计评估集、评估指标和评估流程而且要让评估运行得足够快、足够便宜才能进入高频迭代循环。第四个是应用架构能力。RAG的检索与融合、Agent的工具调用与循环控制、多模型协同的调度策略这些都是AI工程的底层骨架。模型只是大脑工程是血管、肌肉和神经。第五个是部署和监控能力。模型服务的高可用、上下文管理、成本控制、日志追踪缺一不可。总结下来从零开始最忌讳的就是只盯着“模型能力”这一个点把其他环节都当作“外围工作”。在我实际经验里一个AI项目的成本分布通常是数据准备和清洗占三成提示词和评测迭代占四成应用架构和部署占两成模型本身只占一成。1.3 从零开始的人最容易缺的是系统视角如果你去搜AI学习路线大部分资源都是教你用LangChain、LlamaIndex、写Agent或者是一堆大模型原理科普。这些内容有用但都是碎片。真正从零开始搭建AI工程最缺的不是工具或知识而是“把这些环节串起来”的系统视角。我给你举个例子。一个常见的AI问答系统看起来只需要“把用户问题发给模型把回答返回给用户”但一个可交付的版本要处理的额外问题包括用户问题需要改写和意图识别、答案需要附上引用来源、模型无法回答的时候要有兜底话术、回答内容要走内容审核和合规检查、每次会话要维护上下文窗口、历史记录要做持久化、模型升级之后要重新跑回归评测。这些环节里任何一个没考虑到系统上线就是一个事故。所以我个人强烈建议从零开始学习的时候不要只跟着教程敲代码而是要定期退后一步把你做的每一个小模块放回“一个完整AI系统”的全局里问自己这个模块解决的是全局里的哪个问题如果它挂了影响范围是什么2. 搭建你的第一个AI工程骨架2.1 环境准备目录结构先设计好再动手写代码我见过很多人从零开始做AI项目第一步就是pip install openai langchain然后对着教程敲demo。这没有错但等代码量上来了目录乱成一团prompt和业务逻辑耦合在一起数据文件散落在各处想迭代一个版本要翻半天代码——这个时候返工的成本比一开始设计好要高得多。这里分享一套我跑过多个项目后沉淀的最小目录结构你可以在第一个项目里直接抄ai_engineering_project/ ├── configs/ # 所有配置模型参数、API配置、提示词版本 │ ├── settings.yaml │ └── prompts/ ├── data/ # 原始数据与处理后数据 │ ├── raw/ │ ├── processed/ │ └── golden/ # 评估集 ├── src/ │ ├── ingestion/ # 数据清抢、切分、入库 │ ├── retrieval/ # 检索与召回模块 │ ├── generation/ # 模型调用与提示词组装 │ ├── agents/ # Agent调度逻辑 │ ├── evaluation/ # 离线评估模块 │ └── serving/ # API服务层 ├── notebooks/ # 实验与探索 ├── tests/ # 单元测试和回归测试 └── scripts/ # 脚本工具这套结构的好处是提示词被当作配置管理评估集有独立目录数据流向清晰你随时能知道“改成本影响哪里、加场景要动哪里”。从零开始就把骨架搭对后面你的迭代速度会快很多。Python环境这块我强烈建议用uv或poetry来管理依赖而不是直接把所有包全局安装到系统里。AI项目的依赖坑我踩过太多了某个库要求pydantic2另一个要求pydantic2两个库又同时被LangChain依赖不隔离环境直接原地爆炸。uv的依赖解析速度和锁文件管理比我之前用的工具顺滑很多新项目我都直接用uv init起步。2.2 API配置与密钥管理别把key写进代码这听起来像老生常谈但我真的在一个客户的代码仓库里见过提交上去的API Key因为他们的开发者把key写进了配置文件然后整个仓库直接托管在公司GitLab上。这个Key直到被扫描工具报出来才换掉这个过程中别人完全可以用他们的额度跑自己的业务。正确做法是所有密钥和环境相关的配置放在环境变量或本地.env文件里而且.env必须进.gitignore。同时建议对API做一层调用封装方便统一加日志、加缓存、做重试。我一般会在src/generation/llm_client.py里写一个LLMClient类统一处理API鉴权、超时、重试、token统计。这样不管底层接的是DeepSeek、GPT、Claude还是本地模型上层调用的接口都保持不变后面模型选型要切换只改这一层成本极低。2.3 模型选型不是越贵越强就越好从零开始选模型的时候很多人会直接选“当前榜单最强的模型”然后跑了一段时间发现成本完全兜不住。AI工程选模型核心不是选“最强的”而是选“这个任务下性价比和稳定性最优的”。我的决策框架是这样先看任务类型。如果是复杂的代码生成、多步推理、长文本理解那确实需要一线强模型。但如果你的核心场景是“基于已经检索到的资料做摘要”或者“从短文本里提取字段”一个轻量模型配合好的提示词效果完全不差成本可能只有大模型的十分之一。还要考虑模型上下文长度和数据隐私。如果业务数据要求私有化部署那你只能在本地可部署的开源模型里选如果对延迟有要求大模型的推理速度可能就是硬伤。我实操中的策略是“分级模型路由”简单任务走轻量模型复杂任务走强模型中间用规则或小模型做路由判断。举例来说用户问“今天天气怎么样”这种意图明确的问题直接用轻量模型回答如果问题涉及多跳推理、代码生成才路由到强模型。这个策略在很多项目里都能把成本降低50%以上。3. 提示词工程从“写话术”到“写接口契约”3.1 提示词的底层逻辑是概率控制我早期写提示词时很痛苦因为总感觉是在“碰运气”——今天调好的效果明天模型一更新就变了。后来我意识到提示词工程不是一个文本创作问题而是一个概率控制问题。你要做的是通过文本结构和约束把模型的输出概率推向你想让它去的方向。打个比方模型就像一个海量的联想机器你给的提示词就像方向盘。你写“帮我写一篇文章”模型往任何方向编造的概率都很高你写“你是电商平台的客服根据以下订单信息回答用户问题如果信息不足必须回答‘抱歉我需要查询一下’禁止编造。订单信息{json}”输出就大概率被约束在业务边界内。提示词工程的核心工作包括角色设定限定身份和立场、任务描述说清楚要做什么、输入数据结构给模型明确的信息来源、输出格式约束规定返回什么形态、边界和禁忌说明不能做什么、示例通过few-shot演示正确的输入输出映射。这六个要素缺一不可。3.2 用结构化提示词模板来管理迭代提示词是AI工程里迭代最频繁的部分所以绝不能把提示词散落在业务代码里面。我每次写提示词都走模板化管理流程# Role 你是{业务角色}负责{工作任务说明}。 # Task 根据提供的{资料类型}回答用户问题。你的回答必须满足以下要求 1. 如果需要引用资料必须标注来源编号格式为【来源{编号}】。 2. 如果资料中无法找到答案必须回答“抱歉根据现有资料我无法回答这个问题”禁止编造。 3. 回答长度控制在{长度要求}以内。 # Input 资料{retrieved_context} 用户问题{question} # Output Format 返回JSON格式字段包括answerstring、sourcesstring数组、confidencefloat0到1。这套模板在项目里用得非常稳。三个关键点第一把“禁止编造”和“信息不足时怎么说”写进提示词能明显降低幻觉率第二把输出格式约束成JSON让模型输出可直接被上层程序解析减少解析错误和排查成本第三提示词的版本要记录每次修改都写changelog否则你根本无法判断“效果变好是模型升级导致的还是提示词改动导致的”。3.3 高级技巧思考链、温度参数与结构化输出如果你做的是复杂任务比如逻辑推理、多步骤规划可以用chain-of-thought技术引导模型分步思考。最简单的做法是在提示词里加一句“让我们分步骤思考”或者在示例中展示“第一步分析问题第二步生成候选方案第三步评估并选择”。这里要注意一个反直觉的坑对于复杂推理任务让模型”先思考再回答”确实有效但如果你把思考结果也给用户看用户会被一大段思维过程干扰体验很差。工程上的做法是把思维链隐藏起来只把最终结果返回给用户。温度参数也值得花时间理解。温度越高输出越随机、越有创造性温度越低输出越确定、越稳定。我做信息抽取、分类、客服问答这一类追求稳定性的任务温度通常设置在0.1到0.3之间做创意写作、头脑风暴才用到0.7以上。注意不同的模型实现里温度的实际表现略有差异务必在你用的模型上实测几组温度值来确认。还有一个重要趋势很多模型服务商现在支持结构化输出模式比如OpenAI的JSON mode或其它API里的response_format参数。能启用结构化输出就尽量启用它比“在提示词里要求输出JSON”要可靠得多。4. RAG让AI学会“查资料再回答”4.1 为什么需要RAG架构是什么我在一个企业知识库项目上第一次尝到RAG的甜头。用户问的是公司内部制度、产品文档模型如果没有读到这些内容只会给出泛泛的通用答案甚至编造不存在的制度。RAG的思路很简单在模型回答之前先从你私有的资料库中检索到和问题最相关的内容然后把检索结果作为上下文一起送给模型。一个完整的RAG架构分为三个阶段索引阶段把原始文档切块、向量化、写入向量库、召回阶段用户问题转成向量去向量库做相似度检索、增强生成阶段把召回的内容和用户问题组装成提示词交给模型生成答案。为什么不能直接把整个文档都塞进提示词因为模型的上下文窗口有限而且信息一多杂讯会干扰模型判断。检索的意义是从海量资料里找出最相关的那几十行内容让模型只基于高信号内容进行回答。4.2 RAG落地最容易出错的三个环节我在多个RAG项目里反复踩坑最典型的三个环节是切分、召回和重排。第一是文本切分。很多人直接按固定字符数切块结果把完整的一句话或一个知识点拦腰切断导致召回的内容语义不完整。我后来用“结构感知切分”优先按Markdown标题、段落、列表层级来切每个块控制在500到800字之间相邻块之间保留一部分重叠。这样一个知识点尽量落在同一个块里召回质量明显改善。第二是召回。向量检索不是万能的它擅长语义相似但用户问题里的关键词有时反而匹配不到。我现在习惯做混合检索向量检索加关键词检索比如BM25把两个结果用加权方式合并。注意召回并不代表准确召回率不等于精确率你必须有大致的系统性预期如果最终答案质量不好很大概率是召回的内容就没对而不是生成环节出了问题。第三是重排。第一次召回可以放宽取回比如20到50条候选然后用一个重排模型reranker精排取前5到8条进入提示词。重排模型的输入是一对“问题-文档块”输出相关性分数它的精准度通常高于向量相似度本身。加一层重排回答质量能提升不止一个档次。4.3 Embedding模型选型和向量库配置Embedding模型负责把文本变成向量它的质量直接决定召回效果。选型主要看语义理解能力、维度大小影响存储和检索成本、是否适合你的语言场景中文业务数据需要中文能力强的模型、是否支持私有化部署。常用开源方案是BGE系列、M3E国内也有不少中文优化模型。如果选API服务很多云厂商都提供embedding接口方便但注意成本。向量库的选型主要看你团队的技术栈和数据规模。数据量小比如几十万条之内用轻量方案如chromadb、qdrant容器版就够跑数据量大、有高并发需求就用milvus或elasticsearch自带向量能力这类服务化方案。有一个参数我要单独强调top_k。有些教程喜欢把top_k设到10甚至20想着“多一点总没坏处”。但实际上上下文塞得太多模型的注意力被稀释答案反而更差还多花了token。我一般在重排后取5到8条如果都是高度相关的内容这个量足够模型回答大部分问题。5. AI Agent从问答窗口到自主执行系统5.1 Agent的本质是“让模型使用工具”Agent是AI工程里现在最火的方向之一。很多人第一次接触Agent会惊讶于“模型竟然能自己调用工具完成任务”。但工程上Agent没有多神秘它的核心是一个让模型循环执行“思考-行动-观察”的过程。打个比方传统问答模型像一个只会说话的实习生你问什么他回答什么Agent像一个接了任务后能够查资料、发邮件、填表格、找同事确认的实习生每一步他会告诉你他在做什么、拿到了什么结果、下一步打算做什么。所以Agent工程的关键是给这个“实习生”一套足够清晰的口头指令系统提示词和足够顺手的工具工具注册列表。从零开始做Agent建议不要一上来就上LangChain或其它框架而是先用原生代码实现一个小循环理解背后的机制。这个循环大致是这样1. 把用户任务和可用工具描述发给模型 2. 模型返回一个决策要么直接给出最终答案要么指定调用某个工具入参 3. 程序执行工具函数把结果返回给模型 4. 模型基于工具结果更新想法继续思考下一步 5. 重复执行直到模型认为任务完成给出最终答案或达到最大循环次数5.2 Agent工程的三个核心设计问题设计一个可用的Agent我总结为三个核心问题任务拆解、工具调用、终止条件。任务拆解解决的是“复杂任务怎么一步步完成”。你可以把用户的大目标拆成若干子任务每个子任务对应一个模型调用。比如“分析这份销售数据并写一份周报”Agent需要先读文件、再统计数据、然后生成报表文本。这个拆解可以由模型动态规划也可以由你提前编排好。工程稳定性的优先级是能预先编排的就别让模型自由发挥。模型自由发挥意味着输出路径不可控一旦规划错了整个任务就废了。工具调用的关键是“工具描述要写清楚”。模型的工具选择依赖工具描述你给它一个工具描述如果写“get sales data”模型很可能不知道什么时候用、传入什么参数。好的工具描述应该写成这样“get_sales_data(region: str, date_range: tuple[str, str]) - dict —— 获取指定区域和日期区间的销售汇总数据用于回答销售相关问题时首先调用”。描述越精确模型选择正确工具的概率越高。终止条件是最容易忽视的。没有终止条件的Agent会陷入死循环模型不停地说“我调用一下工具看看”工具返回了它又说“我再确认一下”。我每次都会在系统提示词里明写如果已经收集到足够信息回答用户问题必须直接输出最终答案不允许继续调用工具。同时代码层面的最大循环次数通常设5到8轮超过就截断并返回当前最佳结果避免用户等待和token浪费。5.3 Agent多步操作的质量保障Agent跑起来之后你会发现单次模型调用都稳定但一连串调用下来经常出错要么中间某个环节生成格式不对要么用到了错误的参数。所以工程上一定要给Agent加四道保险第一道是结构化的工具调用协议。不要让它输出自然语言再去解析而是要求它输出严格格式化的JSON包含tool_name和tool_args字段。解析失败就重试一次仍然失败就终止并报错。第二道是关键操作的确认机制。涉及重要动作比如发送邮件、对外API调用、删除数据要先让Agent产出计划人点击确认后才真正执行。人类介入不是降低效率而是给系统一个安全网。第三道是上下文压缩。Agent在多轮循环后消息历史里的工具结果会很长。token越滚越多成本暴涨而且模型容易“忘记”最初的任务。可以在每轮循环结束时用一个小模型把前期对话压缩成摘要保留关键信息丢弃噪音。第四道是设置清晰的Agent边界。不要让Agent对能力范围之外的请求硬撑。如果它需要的信息不在可用工具中要允许它直接说“我需要更多信息”而不是编造出一个结果。我在项目里见过太多次Agent一本正经地编造数据最后被用户使用的过程污染了——边界意识要刻进系统提示词里并且要在评测中反复测试。6. 评估与测试AI工程里最值钱的工作都在这里6.1 没有评测就没有迭代的方向你可能已经发现AI工程里最难的不是“让模型做对一次”而是“让模型每次都做对”。我见过很多团队把时间都花在调试单个case上这个case不对改一下提示词那个case又不对再改一下。改来改去case A好了case B坏了完全没有方向。这就是为什么评估是AI工程里最核心的环节。你要先把“效果好坏”变成可量化的指标再让这些指标指导你改系统而不是靠感觉。评估做好了你改提示词、换模型、调整检索参数都能立刻看到全局影响评估没做你的AI项目永远停留在“demo能跑”的状态。6.2 从零搭建评估集和评估流程评估集golden set是评估的地基。从零开始你至少需要准备50到200条样本每条样本包含输入、期望输出或判定标准。来源可以是历史用户问题、客服对话记录、业务方提供的高频场景也可以让业务同学标注。关键是这些样本要能代表真实线上分布不能只挑你会做的。然后你需要定义评估指标。任务不同指标不同。如果是分类任务用准确率、精确率、召回率如果是生成式问答指标会比较复杂可以用LLM-as-Judge让一个强模型当裁判打分也可以人工抽检打分还可以用RAG场景里的引用准确度。实际操作中我一般三种评估方式混用自动化指标快速跑量LLM裁判跑大部分样本人工只抽检小部分重点case。评估的频率也很重要。每次改动后都要跑一遍完整的评估集并把结果记录下来。我建议在项目里建一份评估报告表记录每一次改动的版本、评估指标变化、badcase清单。这样你就有了“系统进步的历史账本”后面排查问题会非常有依据。6.3 LLM-as-Judge的设计细节用LLM当裁判是AI工程里绕不开的一个方法。因为人工评估太慢太贵而传统自动化指标比如BLEU对对话和生成任务很不靠谱。LLM-as-Judge的做法是把“待评估的回答”和“参考答案/评分标准”一起发给一个强模型让它按你设定的维度打分。这里的关键是把评分标准写清楚。我一般会定义四个维度准确性是否忠于资料、有没有胡说八道、完整性是否覆盖了问题所有要点、友好度表达是否清晰自然、格式合规是否按要求输出。每个维度1到5分并且在提示词里给每个分数档位写具体描述否则裁判模型打分会飘。还有一个很重要但容易被忽略的点裁判模型会偏爱更长的答案。同一个信息量下答案写得越长分数越高这会让你的系统朝冗长的方向演进。处理办法是在评分标准里加一条“表达精炼不啰嗦”并在提示词中强制说明“长度不影响分数”。6.4 线上监控评估不能只做离线离线评估只能覆盖你准备好的样本但线上用户的问题千奇百怪你一定会遇到评估集里没覆盖的情况。所以线上监控必须做起来。最基础的是日志每次模型请求都要记录输入、输出、模型名、token数、延迟、用户反馈如果有。然后是用户反馈通道设置“点赞/点踩”或“回答是否有帮助”按钮把用户反馈自动写入badcase库定期人工分析。对于AI客服类系统我还会做一个“拦截率”监控当模型连续两次对同一类问题回答“无法回答”说明知识库覆盖有缺失需要触发更新流程。这些都是在真实项目中帮我提前发现问题的机制比等用户投诉要有效得多。7. 实操路线图从零开始的第一年怎么走7.1 分阶段学习路径如果你真的是零基础起步我给你一条已经验证过的分阶段路径。第一个月搭建环境和理解原理。花两周时间把Python环境、API调用、提示词基础弄熟再花两周时间动手做一个小工具比如“根据简历内容自动生成面试问题”或“新闻摘要机器人”。这个阶段不要求工程化目标是跑通全流程。第二到三个月补齐工程化能力。把第一个月的小工具重构成规范的项目结构加入提示词版本管理、日志、简单的评估集。同时开始学习RAG做一个企业内部文档问答的MVP。这阶段你会开始体会到“demo和系统的差距”。第四到六个月掌握评估和Agent。给你的问答系统建评估流水线每天记录badcase迭代至少两轮。同时上手做一个小型Agent项目比如“自动整理文件夹并生成报告”的工具体会模型循环调用工具的机制。第七到十二个月做一个完整项目并上线。找一个真实的业务场景可以是内部工具也可以是面向用户的助手完整走一遍数据准备、RAG、Agent、评估、上线、监控的全流程。这个项目会成为你能力的最佳证明。7.2 一个真实小项目从需求到落地的工程拆解我带你走一遍我曾经做过的一个员工知识库问答助手的完整流程你可以参考这个框架。需求阶段业务方提的需求是“让员工能随时问公司制度比如年假怎么休、报销流程是什么”。第一反应可能是直接做个问答API但实际工程拆解后问题复杂得多制度文档分散在多个系统格式有PDF有Word还有网页员工问法多样“年假能休几天”和“我入职一年了有多少天假”其实是同一个知识点制度可能每季度更新更新后旧答案不能继续出现。数据阶段我先把所有制度文档收集起来按制度类别和时间版本整理一份制度更新就生成新版本记录。然后清洗掉页眉页脚、表格噪声按章节结构切块每块打上来源、生效时间、制度类别三个元数据字段。RAG阶段向量库建好后做了第一批测试发现员工问“报销”时系统检索回来的常常是“差旅报销”和“采购报销”混在一起用户根本分不清。后来在索引阶段加入了制度分类字段召回时按问题意图先过滤类别再按向量相似度排序问题得到明显改善。生成阶段提示词里强制模型必须标注来源编号和生效日期如果知识库里没有适合的内容就回答“请查阅OA系统相关公告”。用评估集跑了一轮后又发现“数字准确性”是主要问题比如制度里写的“入职满一年享受5天年假”总是被模型换算错。后来我把相关数据在提示词里格式化输出减少模型运算负担数字错误率下降很明显。上线后监控日志发现一个高频问题员工问“加班费怎么算”系统经常回答出不同版本。排查后发现是制度更新后新老版本同时存在于知识库召回时优先生成了旧版本。解决方案是在切分时给每个文档块打上生效时间召回后在重排阶段按生效时间降序作为排序权重之一最终把这个问题彻底解决。7.3 我建议你绕开这几个大坑第一个坑是过早投入微调。很多人刚接触AI工程就想“我能不能用自家数据微调一个模型”但微调的成本高、迭代慢而且很多场景根本不需要微调。RAG加提示词能覆盖90%的企业知识问答需求先跑通再判断要不要微调。第二个坑是追逐新模型。大模型领域每个月都有新模型发布每次你都要评估是否值得切换。我给自己的原则是除非新模型在评测集上带来明确提升或者成本降低明显否则不轻率切换。切换一次模型后面提示词、评估集、所有回归测试全要重新跑成本很高。第三个坑是忽视数据更新机制。AI系统上线只是开始数据会变、制度会变、用户问法会变。如果你没有一套定期更新数据、重新索引、回归评估的机制系统会在运行几个月后逐渐变差而你自己可能都感觉不到。8. 常见问题与排查技巧实录8.1 模型输出不稳定怎么排查同样一个问题模型昨天答得好今天答得差这种问题很常见。排查顺序我建议是这样第一确认提示词版本没变第二确认模型版本没变有些API模型后台可能悄悄升级第三检查温度参数是否被改动第四确认输入上下文有没有变化比如检索到的资料变了。如果全部确认没问题还是不稳定那就是模型本身的概率特性需要你在工程上加约束比如降低温度、增加输出格式约束、加一层后处理校验。8.2 RAG召回质量差怎么定位是哪个环节的问题排查召回质量时先不要急着改代码。我常用一个方法把用户问题、召回到的文档块、最终生成的答案三者放在一起人工看一遍。如果召回的文档本身就和问题无关那问题出在检索如果文档相关但答案用不上问题出在提示词或生成如果答案引用了文档但引用错误问题出在生成阶段的逻辑。定位到环节之后再针对性优化效率高得多。8.3 Agent陷入死循环或反复调用同一个工具先设置硬性最大循环次数保证系统不卡死。然后检查工具的描述是否足够清楚模型反复调用同一个工具往往说明它没有从结果中得到有效信息。再检查工具返回的内容格式——如果返回的是一大段JSON模型可能解析不干净。可以在工具返回前增加格式化处理只保留最关键的信息。8.4 成本控制不住token烧得太快这是AI工程上线后最现实的问题。控制成本的手段包括用模型分级路由简单问题用轻量模型对历史对话做压缩和截断不要无限累积上下文缓存高频问题的完整回答定时统计各业务线的token消耗出现异常及时排查。我在项目里曾用上面这套组合把一个客服系统的月成本降低了将近60%效果非常直接。8.5 常见问题速查表现象常见原因优先排查手段回答不准确召回内容不相关或缺失人工检查召回结果确认检索环节无问题回答带幻觉提示词缺少禁止编造的边界补充边界声明开启结构化输出输出格式解析失败模型没按要求输出JSON使用原生结构化输出模式重试并加日志效果时好时坏模型版本升级或温度过高固定模型版本调低温度跑评估集回归成本快速上升上下文无限增长或复杂任务占比高加对话压缩、模型路由、缓存常见问题用户反馈“答案太官方”提示词缺少人设引导在系统提示词里补充口语化风格要求做AI工程快两年我最想说的几句话如果我能对刚开始做AI工程的自己说几句话我会说别把太多时间花在一个case的Debug上更别因为模型偶尔的惊艳回答就误以为自己已经掌握了一切。AI工程的本质是和数据分布打交道是和不确定性共处是用一套系统方法把模型的平均水准不断抬高。从零开始的路没有捷径但没有捷径本身也是一种好事——因为所有认真走完这条路的人得到的都是真正的能力而不是一个看起来像“AI工程师”的壳子。每次完成一个项目记得把过程中的badcase、提示词版本、数据版本都留好。它们看起来没什么用但下一次你遇到类似问题时会发现经验就是由这些零散记录堆起来的。