1. 先把话说透AI工程和普通写代码到底差在哪里我最早接触ai engineering这个概念的时候以为就是学会调大模型API写几个Prompt然后做得比以前用规则匹配更聪明的系统。真上手做了几个项目之后发现完全不是这么回事。如果只用一句话总结我的认知转变那就是传统软件工程处理的是确定性AI工程处理的是不确定性。代码运行一万次结果都一样但同一个Prompt调用十次结果可能有细微差别同一个问题换个问法模型可能给出完全相反的答案。这种不可控才是AI工程所有方法论要解决的核心问题。所以从零开始学AI工程不能从某个具体框架的API学起而是要先建立一套思维框架你的系统里哪个环节是确定性的哪个环节是不确定性的怎么在不确定性的前提下把系统的整体行为控制在一个可接受的范围。这篇内容不是某个工具的手册而是我这几年来从零开始搭建AI工程能力、落地实际项目的经验梳理。适合正准备把大模型接入业务系统、但又不太确定从哪下手的工程师也适合那些写Prompt已经有一阵子、但总感觉演示很美好、上线就翻车的团队。咱们把AI工程拆成四条主线来看模型调用层、上下文工程层、Agent编排层、质量评估层。每一层都有对应的新工种和新技能要求。标题里的from scratch不是说从写Transformer开始而是说从一个只会调API的开发者成长为一个能独立交付AI项目的工程负责人。这篇文章就是记录这条路怎么走的。2. 从零起步的第一步搭建AI工程底座而不是急着写业务代码很多新手拿到OpenAI或者国产大模型的API Key之后第一件事就是打开Jupyter Notebook写一个model.generate(prompt)跑通了就很兴奋。但真正做工程的时候你需要的不是Notebook而是一套能持续迭代、可观测、可回滚的小型基础设施。2.1 底座应该长什么样版本管理、配置中心、评测通道三件套我现在的每个AI项目哪怕是最小的内部工具也一定先搭三层东西。第一层是Prompt与样本的版本管理。Prompt不是写一次就完事的它会在项目生命周期里被改几十次。你应该像管理代码一样管理Prompt文本——放Git仓库每次修改有diff、有提交记录。很多团队用Notion或者飞书文档管理Prompt上线后发现这版Prompt是哪个版本跑出来的根本查不清楚。我的建议是Prompt文件一般我按system_prompt.py或prompts.yaml组织必须进版本库最好绑定一个版本号如果用了LangChain之类的框架它们有Prompt模板管理但底层还是得靠Git把关。第二层是模型路由与参数配置中心。你把API Key、模型名、温度参数、最大Token数、重试策略这些配置集中到一个配置文件或者环境变量里而不是散落在各处。模型迭代很快今天用的GPT-4明天可能换成更便宜的替代模型。如果配置写死在代码里换模型就变成一次大改。配置中心和业务代码分离之后切换模型只是改一个YAML的问题。第三层是最小可用的评测通道。哪怕项目还没开始也要先把输入样本集 预期行为 评分逻辑这个骨架搭起来。这个通道不一定一开始就很完善但它的存在会让你后续做的每一次改动都变得可以被验证。我见过太多团队项目做了三个月问你们怎么评估模型输出质量答曰我们每次都是人肉看的——听起来还行但一旦业务量上来人肉看的代价会彻底拖垮迭代速度。2.2 环境选型的一些思路不是越贵越好也不是开源就一定省钱关于模型选型只说一点个人经验。不要一开始就把主力业务绑在单一最强模型上。先拿最强的模型做原型验证确认这个任务方向可行然后根据任务难度做分层——简单分类任务用便宜小模型复杂推理交给大模型中等难度的提取类任务可以用开源模型私有化部署。成本差距是几十倍甚至上百倍。倒不是说开源模型不好而是你要算清另一笔账自托管模型需要GPU机器、运维监控、模型版本迭代的管理成本。如果团队只有一两个后端工程师优先用API服务等业务量稳定了、调用次数上来了再评估自托管的性价比。我们团队有个经验公式如果单日Token消耗稳定在千万级别以上并且延迟要求较高再考虑自托管方案否则API服务永远是省心的选择。2.3 模型调用层的工程细节重试、超时、流式与结构化输出模型调用看似只是发一个HTTP请求但工程细节非常多。一是重试策略。大模型API经常有超时和限流尤其是业务峰值时段。不能每次失败就直接抛异常回去否则用户看到的体验就是AI时不时抽风。通常我会做三次重试第一次快速失败第二次和第三次用指数退避间隔分别为1秒、3秒。如果三次都不行再走降级通道——比如返回一个预设的兜底回复或者调用一个更便宜的备用模型而不是把错误直接扔给用户。二是结构化输出。纯文本输出对最终用户没问题但如果你要让AI的结果继续参与程序逻辑就得让模型输出严格格式化的内容。常见的做法有两种一种是老牌的JSON Mode / JSON Schema约束提示模型只输出JSON并校验另一种是Function Calling让模型直接选择工具并填入参数参数本身就是结构化的。我在生产中绝大部分场景都走Function Calling路线它可以天然地和Agent框架结合比先输出文本再解析JSON少踩很多解析错误。三是流式输出。如果是面向聊天窗口的C端产品非流式响应会让人等得很崩溃。但是流式输出也有坑用户界面截断后半句话的展示、Token计费对不上、中间态被当作最终态缓存。如果你的产品接入流式务必设计好最终结果以finish_reasonstop为准的约定。3. 提示词工程的核心逻辑不是你写不出好Prompt而是你没有把Prompt当代码提示词工程Prompt Engineering是AI工程里面被讨论最多、被误解也最多的一个子领域。很多文章把写Prompt讲得像玄学动不动就说魔法词。但我的观点很朴素Prompt是运行在模型里的程序你要用一种偏软件工程的思维去写它。3.1 一个生产级Prompt的骨架角色、任务、约束、示例、边界我提倡把Prompt拆成若干个语义模块每个模块对应一个变量。一个比较经典的结构是这样角色设定System明确你是谁、你服务谁、你用什么风格说话。比如你是一名客户技术支持专家回复要专业、简洁、不提其他渠道没见过的问题。有了角色设定模型输出的风格方差会显著下降。任务描述Task说明这次具体要完成什么尽量用指令式的祈使句避免模糊的形容词。不是帮我看看这个评论怎么样而是判断这条评论的情感极性输出结果为positive/negative/neutral三种之一。约束条件Constraints说清什么不能做。比如不要编造你不知道的参数不要回答和问题无关的内容不超过50字。约束不是越多越好过多的约束会互相打架、降低指令遵循率我一般控制在三条以内挑最重要的。示例Few-shot给一两个输入输出对相当于给模型示范长什么样算是好结果。示例的质量非常重要不要随便写示例本身就是一套最小的评测标准。边界声明Fallback告诉模型遇到拿不准的情况怎么办。比如如果信息不足请直接说明需要补充哪些材料不要猜测。这里要提一个细节模型对Prompt末尾的指令遵循度高于开头。如果你有一段非执行不可的硬性指令放在末尾比放在开头有效。这个特点不是玄学Tokens的自注意力结构决定了模型对临近位置的上下文更敏感。3.2 从写Prompt到建Prompt版本把提示词当代码管理的实操建议我在2.1提到Prompt要进Git这里展开说说具体怎么组织。建议目录结构长这样prompts/ classify/ v1.yaml v2.yaml extract/ v1.yaml response/ v1.yaml v2.yaml v3.yaml每个YAML文件里面至少包含model,temperature,system_prompt,few_shot_examples四部分。改Prompt的时候不要直接在原文件上改而是新建一个v_n1文件保留旧版本。因为线上系统多半还跑着旧版本一旦你发现新Prompt效果不好随时能回滚。这个习惯救过我太多次了。另外一个容易被忽视的点是给每个Prompt版本记录为什么改。在Git的提交信息里写清楚用户反馈答非所问补充了关于xx场景的约束或者准确率下降调整示例中的xx边界。三个月后再看提交历史你能还原当初的所有决策这是工程化的一个标志。3.3 提示词工程和模型能力的关系别再迷信万能Prompt一个现实是当模型能力不够的时候再多的提示词工程也只是在逼近效果天花板。比如让一个小模型做复杂的数学推理你给它几十个示例它可能能达到70%的准确率换个大模型也许拆成两步ReAct就够了。所以做AI工程要有个成熟的心态先把任务拆解成小任务再判断每个小任务对模型能力的需求级别。真正成熟的AI工程师会花大量时间在做任务拆解而不是写长Prompt。大任务拆小任务也是后续做Agent编排的基础。所以我把Prompt工程这章收个尾Prompt值得你认真对待但要意识到它只是整个AI工程体系里的一个环节。别把全部希望押在一段神奇Prompt上那个东西我至今没见过。4. 上下文工程RAG、记忆与窗口管理决定系统是聪明还是失忆AI工程里模型本身是固定的真正拉开系统智商差距的是你往上下文里塞了什么、怎么塞的。这套东西现在被叫Context Engineering我从零搭建项目的时候完全没有这个框架是纯靠踩坑悟出来的。4.1 RAG不是把文档塞给向量数据库就完事了检索增强生成RAG现在是AI应用最主流的知识接入方式但太多人做出来的RAG效果差根本原因在于他们把一个检索问题想得太简单了——以为把PDF切块、向量化、存进向量数据库然后用户一提问就top-k召回把文档块拼进Prompt就完事了。实际效果通常是召回的东西和问题沾边但不精准模型被不相关信息带跑输出答非所问。我自己的RAG实战经验核心是三个环节都要花心思第一切分策略要跟着回答粒度走。页面上常见的固定500字切块法效果并不好。我发现更有效的是按文档的语义结构切分——比如按Markdown的二级标题来切每个标题下为一个块如果块太长再往下拆到三级标题。这样生成的块语义是完整的而不是从一个观点中间硬生生截断。回答按块来找而不是按字数来找。第二检索要多路召回再融合。只做向量Similarity检索有个毛病——对精确术语、人名、型号这类信息不敏感。我在实践里通常跑三路检索向量检索查语义相似、BM25类关键词检索查精确匹配、必要时加一路元数据过滤比如只看2024年之后的文档再把三路结果按一个简单的分数公式融合后排序。不要一上来就上基于Reranker的重排序虽然效果好但会增加系统复杂度和延迟。先用三路召回加权融合多数场景就够了。第三上下文拼装要引导模型先看证据再回答。把检索出的文档块拼进Prompt的时候不要平铺所有块要在前面加一行以下是参考资料请基于这些内容回答如果资料中没有相关信息请明确说明。这行字看着简单但对结果的引用准确性有明显影响。模型给自己立了一个忠于材料的默认设定。4.2 记忆管理短期窗口和长期事实要分开Agent系统的记忆问题也是上下文工程的一部分。如果你做一个多轮对话型Agent不能把历史消息全部无脑塞进上下文窗口迟早爆掉。我的做法是三层记忆分层会话短期记忆保存最近N轮对话全文一般我在生产环境设10-15轮取决于模型窗口。这些是模型当前推理必须依赖的信息。事实长期记忆从对话中抽取关键事实用户偏好、已知条件、业务参数存成结构化记录JSON或数据库字段。每次对话开始时把这些事实重新注入系统Prompt而不是靠模型从成千上万条历史消息里自己找。技能记忆记录过这个用户过去要求过哪些处理方式相当于个性化规则下次遇到类似问题直接匹配。这里有个最常见的误区就是聊记忆的时候只想到把多轮聊天记录存下来。真正的记忆系统要存储的是已经被提炼过的、与用户或者业务相关的状态。存储本身不复杂难的是什么时候提炼、提炼什么东西。4.3 手动管理Token窗口的一些计算公式上下文窗口规划建议从一开始就算清楚账。最大窗口W你要留出三块空间系统所需固定上下文角色设定、工具描述、知识库片段设为S多轮历史设为H模型输出空间设为O剩下的才是知识库动态检索块R。经验公式是R W - S - H - O并且要给O留足余地输出空间不够是生产环境很常见的问题。打个比方假设用16K窗口的模型系统固定上下文约2K多轮历史约4K输出预留2K那知识库动态检索块最多只有8K——按英文大概6000个Token、中文约4000字。明白这个账之后你就知道为什么盲目地文档库几千个块全都塞满是行不通的。有些团队做完RAG发现上下文放不下就开始压缩文档那其实应该早点在规划阶段就做取舍。5. Agent编排与Harness Engineering给会自己循环的系统装上缰绳如果说RAG是AI工程的第一阶段那么AI Agent就是第二阶段。Agent的概念不复杂——让大模型自己规划步骤、调用工具、观察结果、调整行动形成一个循环。复杂的是怎么保证这个循环不失控。5.1 我对Agent循环的认知从单模型调用到不确定性循环传统程序是直线式的——输入、处理、输出。Agent是循环式的——模型输出动作指令程序执行动作把结果反哺给模型模型再决定下一步。这个循环本质上是一个感知-决策-行动-观察链。每次循环都有出错和偏离主题的可能所以工程上最核心的问题是在什么情况下允许循环继续在什么情况下必须强制终止。我给Agent系统定了三条硬规则最大步数限制。循环最多执行N步通常6-10步超过就终止并告诉用户任务较为复杂我已执行了最多步数这是当前进展。不让Agent无限次地自我纠缠。每一步都必须有可观测的输入输出。Skip不能坐视Agent自己跑了200次Tool Call但不知道它在干嘛。每一步的推理内容、工具参数、执行结果都要记录日志。目标偏离检测。循环每执行完一步检查当前状态是否还在朝终极目标推进。判断方式可以是一个轻量模型对当前进度是否接近目标打一个分低于阈值就触发人工确认或终止。5.2 工具调用的设计规范比选框架更重要的设计模式Agent的落地表现很大程度取决于你给它设计的工具集。工具不是越全越好工具越多模型选错的概率越大。我自己的准则是每个Agent场景下工具数量控制在5-8个以内。宁可让工具数量少而精也不要一股脑把几十个API全暴露给模型。命名也很讲究。工具名要直白比如search_orders比query_order_info_from_order_service更不容易混淆。工具的description字段非常关键——模型是根据description来判断该不该用这个工具的必须写清功能、适用场景、参数格式、异常返回值含义。这个description本质上就是面向模型的接口文档。5.3 Harness EngineeringAgent工程的前沿实践AI工程圈最近一个很热的话题是Harness Engineering我理解它的本质是比起设法把Agent本身调得更聪明更值得花力气的是设计一套约束、反馈和兜底机制让一个能力有限的Agent也能在可控范围内干活。这个词的涵义有点像给一匹烈马套上马鞍与缰绳——不让它脱轨也不让它失去奔跑能力。Harness Engineering落到实践通常包含四部分工作约束与护栏定义Agent允许做什么、不允许做什么比如只能读取订单数据不能执行删除操作敏感操作必须加入权限拦截和人工确认。失败与降级路径Agent工具调用报错时怎么处理调用重试还是换工具连续失败会不会让Agent陷入死循环Harness的一部分就是提前铺好这些备选路径。质量锚点设定核心质量指标比如回答准确率、工具调用成功率、任务完成率让Agent的每一步都有短期的锚可以参考——这其实就是把前面说的评测通道引用进来。人机协作接口明确什么时候交给机器跑、什么时候必须人工介入。一个好的Harness不是全自动的而是知道自己的自动边界在哪里。近期还有个说法叫Loop Engineering我理解它更多是关注循环本身的工程控制——包括步数预算、进展评估、中断恢复。这些和Harness是同一层的思想只是侧重不同。如果你做Agent项目可以把Loop Engineering看作Agent跑起来之后的运维和控制问题。5.4 多Agent不是招财猫多度拆分的复杂度会反噬很多团队一上来就要搭多个Agent协作的系统什么规划Agent、执行Agent、审查Agent各司其职。我的强烈建议是先从一个Agent做起跑通端到端之后再把流程拆成两个、三个。多Agent协作的通信开销、状态共享、死锁问题非常复杂收益往往没想象中大。大部分实际场景用一个Agent配上合理的工具集就能解决只有当一个任务里包含多个明显不同的子目标、且需要不同知识体系时拆分才有真正的收益。如果团队没有很强的AI工程经验我非常不建议第一个Agent项目就上多Agent架构。那不是炫技是自找麻烦。6. 质量保障AI测试与评估从零开始的工程化分水岭前面说了一堆怎么搭系统但AI工程项目真正的分水岭是——你有没有一套可靠的评估体系。没有评估体系的AI项目是不可持续的每个改动都是在盲改上线靠感觉。6.1 建设评测集正例、反例、边界案例一个都不能少评测集是AI工程的测试用例。我每次做项目都会要求建设三类样本正例输入表现正常、期望结果清晰。这部分是模型见过较多、效果较好的领域。反例针对不应该答什么的场景比如用户问的超纲问题、带诱导性的问题期望行为是拒绝或澄清。边界案例最容易让系统翻车的情况——上下文不够时的回复、超长输入的截断、多轮话题切换、特殊格式的输入等。规模上从30-50条起步就够了不必等造出上千条才开工。但是一旦开始就要把它当成固定资产去维护——每周根据线上真实用户反馈补充10-20条新样本。最终一个稳定项目的评测集通常在500条以上。有了评测集评估方式有三层规则评分能用代码判断的如格式正确性、是否包含禁用词、模型评分用一个较强模型当裁判对输出质量和参考答案比对打分、人工抽检抽5%-10%样本做人工复核校准模型评分的偏差。三层结合效率和质量基本都能保住。6.2 回归测试AI项目改动后的第一道关卡AI项目上线之后如果改了Prompt或换了一种模型一定要跑评测回归。跑出来的分数不仅看平均值还要看每个样本的分数变化。有时候平均值上升但某个类别的样本大面积退化这种偏科回归是最容易坑人的。我的实践是把评测样本按业务场景打标签比如投诉处理订单查询闲聊兜底回归结果按标签分组展示。看到某个标签的分数明显下降就说明这个改动影响了那个子场景需要针对性修正。对于线上真实流量建议加一个影子验证环节新版本在导入生产环境之前先部署到影子环境把线上输入同时发给新旧两个版本处理跑几天对比两者输出质量确定新版本确实在关键指标上不落后于旧版本再慢慢放量切换。这个模式其实和互联网公司的金丝雀发布一脉相承只不过健康检查从监控指标变成了输出质量评估。6.3 可观测性AI应用要有自己的日志规范和追踪体系传统后端有日志、指标、链路追踪三大件AI应用在此基础上有几个特殊的观测点输入血统每一次模型调用对应的Prompt模板版本是多少检索到了哪些文档块最终生成结果是什么。Token账单按会话维度、按用户维度、按场景维度统计Token消耗。不加追踪的话你根本不知道哪个用户、哪个场景把成本吃掉了大半。延迟分析一次请求的总延迟里模型推理占多少、检索占多少、向量化占多少、外呼其他API占多少。不加追踪性能优化只能靠猜。我用过的方案里LangSmith方便但偏品牌绑定自建一个小型的Prompt与调用日志表也不难——核心是把每次调用的输入输出和元数据存下来之后配合评测集做离线回放分析。做到每一个线上坏case都能回放到当时的输入上下文这是AI工程能力成熟的一个显著标志。7. 我从零开始做AI工程踩过的几个真实的坑前面讲的都是方法论这一章我想把印象最深的一些坑单独拿出来说说因为这些实际操作中积累的经验是文档里不会写的。7.1 上下文塞爆的无声崩溃有一次我们做一个客服助手上线初期一切正常。运行了三天之后用户反馈机器人越来越傻了刚说完的事情马上忘有时候一句话要问三遍。排查了很久最后发现问题出在记忆策略上——我们没有对上下文做截断Session越长历史塞得越满后续检索的文档块不断被挤掉模型反而看不到当前需要的信息。这个问题的高明之处在于它不报错也不崩只是答案质量悄悄下降如果不是用户投诉根本发现不了。从那之后我给自己定了一条规矩所有Agent系统必须显式监控当前上下文的Token占用率超过80%就触发历史裁剪告警。7.2 越改越聪明导致的回归丢分还有一个印象很深的坑是我们试图优化一个分类任务的时候给Prompt加了一段常识背景说明当时随手一测发现正确率提升了不少就上线了。结果第二天一看评测结果原来几个接近90分的数据类别掉到了60分。原因是我们丢进去的那段背景信息给模型带来了先入为主的偏见某些类别的边界反而被模糊了。这给了我一个重要教训Prompt的每一次改动都要像改代码一样跑回归评测。不跑就跑后面迟早有一脚是踩在同一个坑里的。7.3 Token成本失控的隐形账单我们有个多轮检索场景刚开始没太在意Token消耗结果是月底账单出来成本比预估的高了三倍。复盘后发现我们为了提升准确率每轮都让模型把全文文档重新读一遍导致单次调用的Token量巨大。成本控制不能靠事后亡羊补牢在设计阶段就应该有预判——控制检索块大小、限制最大步数、对高频固定内容加缓存。现在只要上线新功能我第一件事就会要求能按场景预估Token成本再决定要不要做精简化处理。7.4 评测集与真实场景脱节有一个很隐蔽的问题就是评测集永远来自开发人员的想象和真实用户提问相差很远。我们的一个项目评测集准确率达到92%但用户反馈还是经常答非所问。后来分析发现评测集里的问题都是我们自己的工程师写的表述规范意图清晰真实用户的问题却很口语化、会有错别字、会有意图混杂的表达。模型真正暴露在脏乱差输入下表现自然大打折扣。从那以后我建评测集的一个原则就是每周从真实会话日志里抽20条用户输入直接进评测集不经过任何加工。这样才能保证评测集和真相不脱节。8. 下一步的方向AI Native研发范式与团队能力模型整个AI工程实践走到今天正在从把AI接入到传统软件系统演进到以AI为中心来设计整个系统——也就是大家常说的AI Native研发范式。8.1 从代码驱动到数据驱动的转变传统软件研发是代码驱动的——逻辑写好测试写好行为就确定了。AI Native项目则变成数据驱动的你维护的核心资产不是代码而是数据——Prompt模板、评测样本集、用户反馈、模型配置。这意味着研发过程中最重要的工作逐渐变成了数据的采集、清理、标注、迭代。团队会更像一个数据运营团队而非代码开发团队。一个可见的表现是你在Git里面最多的提交不再是代码文件而是评测集和Prompt配置。这也是为什么我会在前面反复强调要像管代码一样管理评测集和Prompt版本——因为它们才是AI系统的灵魂。8.2 团队角色有什么变化从零搭建AI工程项目团队至少需要四种角色AI应用工程师负责搭建端到端的AI应用懂Prompt、懂RAG、懂Agent编排、懂必要的后端。评测与数据工程师负责评测集建设、回归分析、数据飞轮运转。没有这个角色AI项目很容易沦为依赖个人感觉的黑箱。平台/DevOps工程师负责模型网关、成本监控、日志追踪、上线发布。业务/领域专家负责定义什么是好的输出这是AI应用能否真正解决业务问题的关键。YAML里那行不要在回复中编造没有依据的信息听起来简单但哪些信息算有依据往往只有业务专家能定义清楚。8.3 一个小结从零开始的路线图最后把这套从零开始的路径用路线图的方式压一遍方便大家直接落地使用。阶段一搭底座定模型选型、建配置中心、建一条最简陋的评测通道哪怕评测集只有20条。阶段二做单点选一个业务场景用Prompt工程把它跑通记录Prompt版本添加上下文管理。阶段三接Agent在稳定的单点闭环基础上引入工具调用与Agent循环设定步数上限、日志、护栏走向Harness Engineering。阶段四建体系把评测集规模拉到500条以上并每周补充配置影子环境做回归对比建立调用日志追踪让AI效果可度量、可回归、可回滚。阶段五数据飞轮从用户真实反馈中不断补充评测样本用线上数据修正Prompt与检索策略把项目从上线就停变成持续进化。每个阶段之间不要跳步。我看到过太多团队直接从阶段一跳到阶段三结果就是演示惊艳上了生产环境天天救火。AI工程的本质是用工程手段去驯服不确定性而工程手段从来都不是靠一个惊艳的Demo就能替代的。我个人这几年的体会是做AI工程最需要的那种能力其实不是技术知识而是在不确定性面前保持冷静的耐心。面对模型的随机输出你要有足够的工具和方法去观察它、评估它、约束它而不是靠重试祈求运气。如果你正打算从零开始做AI工程把前面这些内容当成一个路线图还不够更建议从自己的第一个小项目出发把评测集、Prompt版本、调用日志这三样基础功夫练扎实——这些才是真正的护城河。