1. 先说清楚AI工程到底在造什么如果给AI工程下一个我自己的定义我会说它是一门把模型能力变成用户可感知、系统可维护、业务可交付的产品的工程学科。这不是算法工程师的理论推演也不是研究员的paper代码而是一套完整的方法论——从选模型、写Prompt、搭RAG、接Agent到压测、评估、成本控制、灰度发布每一步都是工程决策。我在最开始做AI项目时踩过的最大坑就是把调通API当成了完成工程。当时写了个调用大模型生成摘要的小工具Demo跑通时信心满满觉得AI应用也不过如此。但等到真正要上生产问题就全冒出来了模型输出不稳定这次返回JSON、下次给你夹带一段Markdown上下文窗口被撑爆长文档处理直接崩溃用户问题稍微换个说法回答质量肉眼可见地崩塌。那时候我才意识到AI工程的核心命题其实跟传统软件工程一样如何在一个充满不确定性的系统里构建可靠、可测、可迭代的产品。这篇文章写给谁两类人。一类是从传统后端、前端转来做AI应用的开发者你们不缺工程素养缺的是理解大模型的特殊脾气另一类是已经在用LangChain、Dify这类工具拼应用的同学你们需要从会用工具走向理解原理知道每一步的取舍和代价。我会按自己从零搭一个AI工程项目的真实路径来讲不堆概念只讲实操。2. 从零开始的技术选型别一上来就堆全家桶很多刚上手的朋友会问AI工程是不是必须上LangChain是不是直接找一套完整的智能体框架我的建议是先忍住。2.1 语言和框架怎么选整个AI应用技术栈里Python仍然是绝对主流因为模型SDK、数据处理生态、评估工具全都是Python优先。但如果你做的是偏向端上的产品、实时性要求高、或者团队本来就是前端为主TypeScriptNode.js也完全可行——目前主流模型厂商的SDK对TS支持已经非常好了再加上Vercel AI SDK这类工具做Web应用落地效率极高。框架层面我的真实体验是第一版能不用框架就不用框架。直接调OpenAI/Anthropic/国产模型的SDK或者用各家官方函数调用Function Calling接口先把手上的业务逻辑跑通。理由很朴素框架帮你封装了Prompt模板、记忆、工具调用这些环节但封装的代价是你没法看清每个环节的输入输出出了问题很难定位是模型的问题还是框架的锅。等业务验证了方向再引入框架或自研编排层那时候你的判断力完全不同。2.2 模型选型的原则按任务分而不是按名气分模型选型是AI工程里性价比最高的决策项。我不认为存在一个最好的模型能通吃所有场景更合理的策略是按任务分复杂推理、代码生成、长文本理解选顶级闭源模型比如各家的旗舰版成本高点但稳定这属于买确定性。意图识别、分类、抽取、改写中等尺寸的模型完全够用成本能省下70%以上。本地化、隐私敏感、离线部署考虑开源权重模型再用LoRA微调或量化压缩。我见过一个团队为了追求AI感给所有任务都上最强的模型结果成本翻了三倍响应速度还慢了一半用户体验反而更差。正确的思路是先做任务拆解再给每个子任务配上合适的模型——就像你不会拿大型服务器去跑一个定时脚本一样。提示模型选型时别忘了看一个常被忽略的指标——输出Token上限和上下文窗口。有些模型擅长对话但输出上限太低没法稳定生成结构化长文本有些模型上下文窗口大但中间位置的召回能力会衰减长文档场景需要额外验证。2.3 数据与向量数据库别在第一版追求高性能检索数据存储这块我建议第一版直接从向量数据库里挑一个主流的比如Milvus、Qdrant、pgvector不要自己研究ANN算法也不要在多个向量库里纠结。选型的判断标准是团队熟悉哪个生态、是否支持混合检索向量关键字、能否水平扩展。有个常见的误区是向量数据库越专业越好。如果你的数据量在几万条量级一个PostgreSQL加上pgvector扩展就够了省掉一个中间件对运维成本是很大的减负。数据规模到百万级、千万级再引入独立向量库那时候工程收益才明显。3. 摸清大模型的能力边界比学会调API更重要AI工程里面大部分翻车根源不是Prompt写不好而是设计者对模型的边界缺乏感知。我在团队里常说一句话先把大模型当成一个高智商但极度不稳的实习生再看你该怎么安排它的工作。3.1 模型不是数据库也不是规则引擎有大模型之后很多新手的自然反应是把产品逻辑都塞给大模型去理解执行。比如做一个请假审批系统让模型直接根据员工请假理由判断是否批准——这种做法非常危险。大模型不具备执行规则的一致性同一段话换个语气可能得到完全不同的判断结果这在实际工程里属于致命缺陷。正确的姿势是把模型用在语义理解和内容生成这两个它的绝对优势区把判断、计算、权限校验这些确定性逻辑留在代码里用户输入了一段话让模型抽取其中的日期、人员、事由结构化输出再用代码去校验日期格式、权限范围、剩余假期最后让模型生成一段审批意见回复用户。这样分工模型的不确定性被限制在理解和表达层业务正确性由代码保证。这个原则几乎可以套用到所有AI应用里。3.2 函数调用Function Calling是工程化的地基现在主流模型都支持函数调用能力它在工程里的地位怎么强调都不为过。你可以把它理解成给模型一只手让模型自己决定为了完成这个任务我需要调用哪个工具传入什么参数。实践中我建议把函数调用当成结构化接口来设计每个函数的参数必须有清晰的JSON Schema定义函数描述要写清楚什么时候该调用这个函数和参数的含义。举例你做一个天气查询助手函数描述如果只写查询天气模型很可能在用户问明天出门要不要带伞时不调用任何函数直接回答。但如果你把函数描述写成当用户询问天气状况、穿衣建议、出行安排等需要气象数据支撑的问题时调用此函数参数location为城市名date格式为YYYY-MM-DD调用成功率会提升很多。注意函数调用也会出错模型可能传入不存在的参数名、或者在不该调用的时候调用。工程上必须做好参数校验和失败兜底比如调用失败后给模型返回一个可读的错误信息让它重新规划。3.3 上下文窗口能用的窗口和真实的有效窗口各家模型都在比拼上下文窗口长度128K、256K甚至更夸张。但工程上的真相是窗口够不够长是一回事长距离信息能不能被看到是另一回事。模型本质上对中间位置的注意力会衰减塞入大量无关内容反而会稀释重点。所以做长文档问答时正确思路不是把全文塞进去而是先检索再拼装。用户的问题进来先找到最相关的几个片段把片段拼成Prompt再交给模型。这也自然引出后面要讲的RAG检索增强生成。4. Prompt Engineering的三个层次从写词到编排很多人以为Prompt Engineering就是给模型写一段提示词实际上它可以拆成三个层次提示词层、上下文工程层、系统编排层。越往下走越接近系统工程。4.1 提示词层先说清角色、任务、输入、输出最基础的提示词设计核心是说人话、边界清。一个合格的系统Prompt至少包含四要素角色定义、任务描述、输入说明、输出格式。我常用的写法是你是一个角色。 你的任务是任务描述。 你将收到这样的输入输入格式说明。 你必须输出以下格式输出格式/示例。 约束任何不可违反的规则比如只基于给定内容回答不要编造这套模板看着简单但实际效果比很多人随手写的帮我分析一下这段话要好得多。原因是它把模型的工作范围和输出标准一次性界定清楚了模型不需要去猜你要什么。进阶技巧是给模型提供几个基本一致的示例Few-shot。注意是基本一致而不是最好因为如果示例里有一个特殊的表达方式模型会不自觉地模仿你的示例风格。被它带偏还不如不给示例。4.2 上下文工程层模型记忆和知识的管理提示词层解决的是怎么问上下文工程层解决的是给它看什么。这里有个很有用的概念叫上下文预算——你能在多大程度上控制进入Prompt的信息。一个真实的例子我们的文档问答应用最初把所有相关片段不分主次全拼进去结果模型答问题答得含含糊糊。后来改动策略第一步先用大模型对小片段做一次相关性排序挑出最相关的3-5个片段再把它压缩改写成一个尽量简洁的背景段落喂给模型。同一个模型、同一个Prompt回答准确率提升了接近20个百分点。上下文工程里还有个被低估的细节信息的位置。有些模型对Prompt开头和结尾的注意力明显强于中间。所以关键指令放在开头角色和任务关键数据放在结尾用户问题新加入的内容中间放背景材料。虽然听起来很玄学但实测真的有效。4.3 系统编排层把多步任务分解成流水线复杂任务不要指望一次Prompt搞定你需要的是一条Pipeline。比如做一个行业调研报告生成器直接让模型一次输出完整报告结果通常是泛泛而谈。拆成多步之后效果完全不同第一步模型生成报告大纲结构化输出第二步针对每个小节让模型列出需要的数据或事实第三步检索相关材料并填充内容第四步汇总初稿再用一个润色/纠错Prompt做终审。每一步的输出都交给下一轮Prompt作为输入中间环节可以被记录、被干预、被替换。这其实就是Agent工作流的雏形——你不需要一步就让模型成为全知全能的天才你要做的是把它当作流水线上的协作节点。5. RAG落地搜索质量决定应用的天花板RAGRetrieval-Augmented Generation几乎是现在做知识库类AI应用的必选项。但我观察到一个现象很多人把RAG想得太简单以为就是Embedding入库向量检索拼接Prompt三段式。真跑到生产环境会发现一堆粒度问题、召回问题和解析问题。5.1 Embedding模型选型别迷信越大越好Embedding是整个RAG的地基。选Embedding模型时关注三点语义匹配效果、向量维度影响存储和检索成本、多语言/领域适配度。不要盲目追求维度高维度越高存储越大、检索越慢收益却很有限。对中文场景优先考察在中文语义相似度评测集上的表现很多英文优秀的Embedding模型在中文本土语义上表现平平。如果有条件可以拿自己业务里真实的问题和文档片段做一个小评测集对比两三个候选Embedding模型看哪个召回的Top-K里真正包含正确答案。这个小动作能帮你绕开很多玄学争论。5.2 分块策略粒度决定检索精度分块是RAG里最手工作坊但影响最大的环节。分太大一块内容里混了多个主题检索命中后噪声多分太小语义不完整检索到的片段缺乏上下文。我的经验是分块策略跟内容格式强相关没有万能参数一般文本按段落分块每块控制在300-500字代码/技术文档按语义块类、函数、章节分块同时保留结构化标题信息表格数据一行一条记录 表头重复拼接否则模型读不懂列含义。分块时保留上下文元数据很关键。比如你可以给每块附上章节路径、文档ID、标题层级这些元数据在后续检索和引用溯源时非常有用。5.3 检索优化的三个层次从快到精基础向量检索只是起点工程上通常按下面顺序逐步加码第一层混合检索。向量检索擅长语义匹配但精确的关键字/ID匹配是它的弱项。把BM25或SQL关键字检索与向量检索结果做加权融合RRF是个简单好用的融合算法能显著提升精确类问题的召回。第二层重排Rerank。初检召回Top-50的候选段落用一个专门的Rerank模型比如bge-reranker系列做细粒度相关性打分取Top-5。这个操作的成本比直接让大模型排序低得多效果却接近大模型精排。重排是RAG质量提升里性价比最高的一步强烈建议加。第三层引用与溯源。最终答案里要求模型标注每一句话对应的来源段落ID一方面方便用户核查另一方面你可以在产品后台分析哪些来源片段被频繁引用反向优化你的知识库内容和分块策略。提示别忽略一个愚蠢但救命的兜底逻辑——当检索结果的相似度分数低于阈值时宁可告诉用户知识库里暂时没有找到相关信息也不要硬凑答案。一个一本正经胡说八道的助手比一个我暂时不知道的助手可怕得多。5.4 文档解析是魔鬼所在文字版PDF、Word处理起来没太大问题但扫描件、非标准排版、表格嵌套、双栏文档每一个都能让你怀疑人生。工程上比较靠谱的做法是先做OCR比如PaddleOCR为主力再用解析清洗分层的思路把文档变成结构化数据后再分块。这块我只有一个忠告永远要留一个人工抽检环节。全自动解析的准确率不可能100%但在知识库上线初期抽取几个关键文档人工过目一遍可以帮你及时发现解析问题避免错误信息被用户看到后才暴露。6. 评估驱动开发没有评估闭环一切都是玄学AI工程跟传统工程最大的区别是没有明确的对错标准。同一个Prompt用户换一个问法结果就可能漂移。所以AI工程必须有自己的一套质量保障方法我把这套方法的核心叫作评估驱动开发。6.1 先建评估集再写代码很多团队的节奏是先做功能、后补测试。但在AI工程里我强烈建议反过来先花时间攒一个评估集。收集真实用户问题100条整理标准答案或者退而求其次把用户问题归类到预期的答案要点里。评估集将成为你所有迭代判断的裁判。这个评估集的来源可以是历史客服记录、你自己反复提的问题、朋友试用时提的问题甚至可以先让模型模拟出一批典型问题再人工校准。关键是真实、代表性强、覆盖边界情况。我见过不少项目卡在改一个Prompt怕影响其他场景的死结里其实就是因为没有评估集每一次改动都只能靠感觉去赌。6.2 评估方法从规则到AI裁判有了评估集之后怎么评估模型输出好不好分三个层次精确性评估适合抽取、分类、JSON生成这类任务直接用代码比对模型输出和标准答案统计准确率即可。这里面有个细节模型输出的JSON经常不规范所以解析要容错必要时让模型先输出再校验错了给错误信息让它重试。多要点打分适合问答、摘要类任务。把标准答案拆成多个要点每个要点让AI裁判用强模型判断是否在模型输出中被覆盖最后算要点覆盖率。这比整体打分可靠因为整体打分经常会因为措辞不同而误伤。AI裁判注意事项AI裁判也有偏差。用强模型评弱模型时会系统性偏向文笔流畅、篇幅较长的答案。所以评估Prompt要明确要求忽略长度差异按内容要点覆盖率打分最好固定几个回答的顺序避免位置偏差。6.3 回归测试每次改动都要跑一遍从你建好评估集那天起每次修改Prompt、换模型、调检索策略都必须跑一遍同一套评估集对比分数变化。这是AI工程版的回归测试它能让你改性的时候心里有底。我们团队现在把评估集跑分集成到CI流程里每次提交代码自动跑一次指标下降超过阈值就阻断合并。这个机制看起来增加了一点开发成本但相比模型行为漂移后线上爆雷的代价这点成本完全可以忽略。7. AI Agent实战从工具调用到自主任务编排Agent是现在最热的话题但也是被误解最多的概念。很多人以为Agent就是你问一句它自己把活儿全干了。真实工程里的Agent远没有那么神奇它的本质是一个由模型做决策、由代码做执行、按照循环机制运转的任务编排系统。7.1 先Workflow再Agent我的建议是从Workflow做起再在关键节点上逐步引入Agent的自主决策能力。Workflow是把业务流程固定成DAG每个节点做什么清清楚楚稳定可控Agent则是在某些节点上由模型自己决定下一步该做什么、是否要调用工具、调用哪个工具。一个落地案例我们的智能客服系统走的是混合路线——主流程是Workflow先意图识别再按工单类型走不同的处理路径但其中用户问题比较复杂需要查多个文档才能回答的场景会切入一个Agent子流程让模型自己决定查几个库、拼几次答案。这样既保证了90%常规问题的高效稳定又让剩下10%的疑难杂症有兜底解法。纯Agent方案的诱惑在于看起来自适应能力强但代价是行为不可预测、难以回归测试、出问题很难复现。如果你的场景业务规则清晰且稳定优先Workflow如果确实需要动态决策再考虑Agent并一定给它限制活动范围。7.2 记忆与状态管理Agent最容易翻车的环节多轮对话里的Agent有个阴暗角落上下文状态。模型自己维护的记忆是不可靠的它经常会在对话过程中遗忘或混淆信息。工程上正确的做法是模型只做一次性的信息抽取和决策输出真正的状态交给外部存储。我就犯过这个错误早期做一个Agent应用让模型自己在对话里记住用户选过的偏好比如我不吃辣结果对话到第5轮模型在回答完全不相关的问题时还把不吃辣扯进来。后来改造每轮对话先用一个抽取Prompt把用户偏好结构化出来写入独立的字段回答时再把结构化偏好作为上下文注入。从那以后状态一致性再也没出过问题。7.3 平台还是代码框架如果你不想从零造轮子Dify、Coze这类平台确实能快速搭出原型代码层面LangChain、LlamaIndex、Semantic Kernel这类框架各有一批拥趸。我的经验是原型阶段用平台/全套框架生产阶段必须能下探到一层。也就是说你要搞清楚平台内部帮你做了什么——Prompt是怎么拼的、工具调用的错误怎么处理的、多步执行失败时有没有回滚机制。否则上了线你会发现平台给的自由度和可观测性根本不够。我们现在用的方式底层工具调用直接写原生代码只把Agent编排逻辑用框架的抽象层来组织同时给每个环节加日志。遇到问题能定位到是哪一步、哪个工具的调用出了问题这在生产环境里是必须的。8. 工程化的另一半测试、可观测性和成本一个AI工程能稳定跑在生产环境靠的不是模型选得好而是四周的工程配套够扎实。最后这部分聊几个容易被忽略但决定成败的点。8.1 测试不只有提示词测试还有全链路测试AI应用的测试金字塔和传统应用长得很相似底层对工具函数、数据解析、业务逻辑做单元测试这部分是确定性代码100%要有中间层单次模型调用做输入输出快照测试——固定一组输入比较模型输出是否在合理范围内上层做端到端测试模拟一个完整的用户流程图确认最终结果满足业务目标。其中快照测试是我强烈推荐的在线把真实用户问题和当时的模型输出存下来定期对比当前模型输出和历史的差异。模型行为发生变化时快照测试能让你第一时间感知而不是等用户投诉上门。8.2 可观测性把模型当网络服务来监控调用大模型本质上是在调用一个由别人掌控的外部服务传统监控手段全都用得上调用量、错误率、P95/P99延迟、Token消耗量、费用估算。除此之外AI应用还需要监控语义健康度——比如注入攻击触发率、输出空内容/非法格式的比例、拒答率、甚至输出内容的敏感词命中率。日志方面每个外部调用都要把Prompt和回复记录下来。这里提醒一下隐私问题如果用户数据不允许出域就要考虑私有化部署模型或至少做脱敏处理这个一定要在产品设计阶段就想清楚而不是上线前才补。8.3 成本控制Cache、模型分层和蒸馏大模型的成本不像服务器有固定的账单它跟你的Prompt设计直接相关。省成本的三个杠杆语义缓存把用户问题和生成结果缓存下来相似问题命中缓存就不重新调用模型。用Embedding相似度做缓存命中判定实际能砍掉30%-50%的重复调用。模型分层开头说的任务拆解在这里就兑现了——能用小模型解决的绝不用大模型。在意图识别、摘要、改写这类任务上中小模型的表现已经足够好大规模上线能省下一大笔钱。蒸馏Distillation如果某个子任务的高质量输出模式比较固定考虑用强模型产出一批高质量数据微调小模型复刻这种能力。这样做一次性的训练成本换来长期的推理成本下降流量大的场景很划算。注意成本优化一定不能牺牲核心体验。定价的时候想清楚哪些交互必须走最强模型不可替代哪些允许低配版回答。优先级永远是核心场景质量 成本否则你省下的钱会以用户流失的形式加倍还回去。8.4 灰度发布与模型切换AI系统也需要平滑上线传统系统升级发布要灰度AI工程的模型切换、Prompt改动同样要灰度。我见过不止一次团队在生产环境直接换了新模型结果某个暗处的边角场景表现崩了用户截图投诉才发现。稳妥的做法是新旧模型或新旧Prompt并行运行线上流量按比例切比如先5%用前文提到的评估集用户反馈数据对比两者表现再逐步放开。新模型也好、新Prompt也好在没有评估证据之前感觉好用是不可靠的。我自己在项目里长期保留一个对比面板同一个用户问题让新旧两套方案同时回答人工或AI裁判对比优劣。这比任何翻来覆去的讨论都有说服力。从零做一个AI工程要学的技术点确实不少但真正决定项目生死的往往不是某个算法多高深而是一整套工程习惯把不确定性限制在可控范围、每个环节都有评估依据、每次变更都经得起回归。把这些基础打牢你会发现大模型应用开发和传统软件开发在心态上没什么两样只是多了一门理解新同事模型脾气的功课。