年初开始我带团队从零搭了一套完整的 AI 工程落地流程从最基础的 Prompt 调优到 RAG 检索增强再到能跑通的 Agent 工作流中间踩了不少坑也沉淀出了一套自己觉得比较顺手的方法论。这个项目我给它起名 ai-engineering-from-scratch寓意就是不带任何历史包袱从白纸阶段开始思考 AI 工程到底是什么、该怎么一步步落地。这篇文章就把我整个思路、实操过程和一些避坑经验完整写出来希望能给正在从 0 到 1 摸索 AI 工程的朋友一些参考。1. 内容整体设计与思路拆解1.1 先搞懂 AI 工程不等于调 API很多人一听到 AI 工程第一反应就是调用大模型接口嘛有什么难的。说实话我刚开始也这么想但真正深入做下去才发现AI 工程的核心难点根本不在于怎么调 API而在于怎么把大模型这种概率性输出的东西嵌进一套稳定、可维护、可评估的系统里。传统软件工程追求的是确定性——同一个输入必然产生同一个输出。但大模型天生就不一样温度调到 0 也不代表它 100% 稳定同样的 Prompt 在不同时间调用结果可能就有细微差异。这就带来了一系列工程挑战怎么保证生成结果的质量、怎么在用户输入千变万化的情况下保持系统一致表现、怎么评估一次改动是变好了还是变坏了。所以我在设计这个项目时第一原则就是确定性优先。凡是能用规则、能用代码解决的问题绝不丢给模型自由发挥。模型只做那些真正需要理解力、生成力的核心环节其余外围逻辑全部用传统代码来兜底。1.2 核心需求拆解五个层次一次看清我把整个 AI 工程的知识体系拆成五个层次从下往上依次是基础层大模型的基本原理、API 调用方式、token 计费逻辑。这是地基不搞懂这里的细节后面很多优化都无从下手。Prompt 工程层怎么写出高质量指令、怎么设计少样本示例、怎么用结构化输出约束模型行为。上下文工程层怎么管理上下文窗口、怎么做 RAG 检索增强、怎么处理超长文本。Agent 编排层怎么让模型学会调用工具、怎么拆解复杂任务、怎么实现多步推理。工程化落地层评估体系怎么搭建、日志怎么记录、成本怎么控制、怎么监控线上表现。设计这个项目时我刻意强调从零开始的思路每个层次都有对应的实操项目不搞纯理论。因为 AI 工程这行只看不练根本不可能真正理解细节尤其是像 RAG 这种涉及检索和生成的复合型技术必须亲手调一遍 embedding 的 chunk 大小、相似度阈值这些参数才知道里面水有多深。1.3 为什么选择这条技术路线技术选型上我坚定选择了 Python 生态。原因有几个一是目前大模型 SDK 对 Python 的支持最成熟OpenAI、阿里云百炼、百度千帆这些平台的 SDK 都是 Python 优先二是 AI 生态的数据处理工具链离不开 Pythonpandas、numpy 在处理评估数据时比任何其他语言都顺手三是 PyTorch 等技术栈在 Python 环境下最顺畅后续想深入模型微调也方便。框架层面我也纠结过要不要直接用 LangChain 这类大而全的框架。最终决定是前期不用框架纯手工写调用逻辑等到项目做深了再逐渐引入框架。原因很简单——直接用框架确实写起来省事但它会把你和底层细节隔绝开。比如 LangChain 里一个简单的 prompt 模板背后是它自己的一套变量解析逻辑你不去看源码永远不知道它在你 prompt 里做了什么手脚。这和我from scratch的项目初衷是背道而驰的。2. 大模型基础原理精讲与 Prompt 工程核心细节2.1 token 与上下文窗口AI 工程的第一堂课做 AI 工程第一个必须理解透彻的概念就是 token。Token 是大模型处理文本的最小单位可以粗略理解为半个词或者一个汉字的一部分。中文环境下一个汉字通常对应 1 到 2 个 token英文环境下一个单词约等于 1.3 个 token。这不是我说的玄学这是真实计费和对模型能力边界的直接影响因素。上下文窗口就是模型一次性最多能处理多少 token。比如某个模型窗口是 128K token你以为这意味着你可以塞一本十万字的书进去实际上远远没有那么理想。因为窗口里不光要放你的知识库内容还有系统指令、对话历史、中间推理过程、工具调用结果这些全都算在窗口占用里。我实测下来一个真实业务场景中系统提示词占 500 token对话历史占 2000 tokenRAG 检索出来的上下文占 1000 token你真正能留给模型自由发挥的生成空间是很有限的。理解了这一点很多问题就豁然开朗了为什么长对话会突然报错上下文长度超限、为什么知识内容多的时候模型回答质量反而下降都是因为窗口被撑爆之后模型被迫做取舍舍弃掉了一些它认为不太重要但实际上很关键的信息。2.2 Prompt 工程实操从模板化到结构化Prompt 工程听起来高深本质上就是在做一件事降低模型理解的歧义度。我的经验是好的 Prompt 一定要遵循角色 任务 约束 输出格式四要素结构。所谓角色就是给模型一个身份锚点比如你是一名资深的数据分析师。这不是走过场角色设定能让模型的输出风格和用词习惯迅速聚拢到你想要的方向。任务描述必须具体、可量化比如提取这段话中的所有公司名称、金额和日期而不是分析这段话。约束条件要写清楚不能做什么比如不要编造文本中不存在的信息。输出格式则要用严格的 JSON Schema 加以约束宁可在 prompt 里多花几百个 token 描述格式细节也不能让模型自由发挥输出一段白话。我在项目里给团队定了一个硬性规范凡是面向机器的输出一律要求模型返回严格 JSON 格式并且在前端增加重试解析校验兜底逻辑。不是所有解析失败都交给用户去修改而是后台自动将解析失败这个信号配同原始输出回传给模型让它自己修复格式问题实测修复成功率能到 90% 以上。2.3 少样本学习与思维链设计少样本学习是 Prompt 工程里最实用的技巧之一。模型没有见过你的业务数据直接让它做专业判断很容易跑偏。解决思路是给示例。不需要多三五个高质量示例就能显著提升效果。我举一个实际项目中的例子需要模型从招聘 JD 里面抽取岗位薪资短语比如月薪 20 到 30K、薪资面议这种。如果只是给一句请抽取薪资相关信息模型很容易把月底双薪也当成薪资信息或者把年假 15 天里的数字 15 关联过去。但如果你给它三条带标准输出的示例模型的理解立刻准确起来。这比你在 prompt 里反复强调薪资指的是直接货币报酬要有效得多。因为示例是具体可感的而抽象描述模型未必能完全执行。思维链则是另一种大杀器。让模型一步步思考不是空话对这个项目的关键复杂任务我会在 prompt 里明确要求模型先把推理过程写出来再给最终结论。格式大概是先让模型列出已知条件再做分析判断最后给输出结果。虽然这样会多消耗一些 token但准确性提升非常明显尤其适合数据推理、逻辑判断这类任务。如果出于成本考虑不想每次都思维链可以先用一个轻量模型判断任务复杂度再决定是否让模型展开推理。3. 实操过程与核心环节实现3.1 环境搭建与 API 接入注意点动手第一步是搭建开发环境。我的建议是用 Python 3.10 以上的版本配一张不算太好的显卡也能跑起来纯 API 调用方式对硬件没有要求。先用 venv 或 conda 建一个独立的虚拟环境这是纯开发基本素养一定要做否则后面依赖冲突能把人逼疯。依赖包其实很简单核心就是 openai、requests 甚至是 httpx 库后续做 RAG 的话再加上一个向量数据库的客户端。我踩过的一个坑是 OpenAI 兼容接口的 base_url 配置很多国产模型的 API 声明兼容 OpenAI 格式你只需要改 base_url 和 api_key 就能调用但如果没有正确设置环境变量请求会被发送到官方服务器导致报错。我的习惯是把 base_url、api_key、model 名称全部整理到一个配置文件中明确区分不同供应商不在代码里写死任何环境相关的值。配置好之后先跑一个最简示例测试连通性。我项目里第一个示例是让模型写一段自我介绍输入输出都很简单目标是确认链路是通的。这里有两个实用的小技巧一是设置超时时间不能太短因为大模型推理慢网络一波动 10 秒就断开会很惨我一般设 60 秒以上二是要设置 max_tokens 上限不然模型自己不受控地生成很容易造成 token 浪费。3.2 第一个完整的 AI 应用情感分类器环境通了之后我建议动手做第一个小项目。我选择了情感分类器因为它的逻辑清晰、评估直观而且能完整展示 prompt 设计、结构化输出、错误重试、日志记录的全流程。核心代码逻辑大致是三步。第一构造带角色和任务描述的 prompt要求模型对用户输入做情感判断。第二用 JSON 模式约束输出格式确保 response 是一个包含 sentiment 和 confidence 字段的 JSON 对象。第三在代码里做异常捕获和重试解析失败时自动重试一次。这样一个简单的分类器就能稳定运行。做完这个分类器后我顺手设计了三个简单测试用例一个积极、一个消极、一个中性跑了一遍确认输出结果符合预期。这个测试先行的习惯对 AI 工程特别重要。如果发现某条样例分类错了不要急着改 prompt先把错误样例记录下来攒多了统一分析定位出共性规律后再动手改效率会高很多。3.3 RAG 检索增强给模型装上知识库单纯的 API 调用来做业务问答一定会碰到一个问题模型不知道你的私有业务数据。它虽然知识面广但你的产品文档、内部政策、历史案例对它来说全是未知领域。解决方案就是 RAGRetrieval-Augmented Generation检索增强生成。RAG 的原理可以简化成三步先把文档切成小块用 embedding 模型把每块文本转化成向量用户提问时把用户问题转成同一个向量空间里的向量做相似度检索最后把检索到的 Top-K 条文本块连同问题一起塞进上下文让模型基于这些参考内容来回答。听起来不难实操中的坑非常密集。首先是文档切分chunk size 大了语义完整但检索不精准小了检索精准但又可能截断语义。我测试下来中文文本按 200 到 300 字切分带 50 字左右的重叠区效果比较平衡。其次是检索召回率Top-K 值太小容易漏信息太大容易把无关内容也一起塞进窗口干扰模型输出。我的经验是先用 K3看效果再调整到 K5。最后是相关性阈值低于一定相似度的内容不让它进入上下文宁可不答也不能给用户一个没根据的编造答案。3.4 Agent 工作流让模型学会使用工具RAG 做好了下一步就是带着 Agent 玩了。Agent 的核心能力是让模型自己决定要不要调用工具、调用哪个工具、怎么根据工具结果继续执行。你可以把 Agent 流程理解成一场交替进行的多轮对话系统循环执行接收用户意图 - 让模型决策下一步动作 - 执行动作并返回结果 - 再把结果交给模型继续判断这几步直到模型认为任务已经完成。我在项目里实现了一个简单的查询 计算双工具 Agent。查询工具负责查一份本地商品价格表计算工具负责算批量采购的总价。模型被告知如果用户询问商品价格要调用查询工具如果要计算总价要调用计算工具如果信息不够可以追问用户。实现的关键是工具描述必须用自然语言把这个工具是干什么的什么时候用参数怎么填这三个信息说清楚。模型是靠工具的描述来决定何时调用的描述写得不准确模型就会瞎调用。一个常见的困惑是为什么有文档还要让 Agent 调用工具而不是直接去文档里检索因为 Agent 工具调用的本质是边看边做它能根据用户真实诉求动态地选择信息来源和计算路径而不是依赖预设的检索流程。当你的任务链路比较复杂、判定条件多的时候Agent 比固定流程灵活得多。3.5 上下文管理让长对话不崩坏做聊天机器人类应用时上下文管理是绕不开的坎。最简单粗暴的方式是直接把全部历史对话一股脑塞给模型这个方案在对话轮数少的 demo 阶段还凑合真正上线的时候马上会撞到两个问题窗口超限和费用爆炸。我的做法是通过两步实现上下文管理。第一步是截断只保留最近若干轮核心对话比如最近 10 轮的摘要。如果业务中还有关键信息不能丢就把它压缩成记忆摘要单独放进一个系统变量里。第二步是压缩对话轮数很多时让模型每个月或每二十轮做一次对话摘要整理把早期对话浓缩成 200 字以内的概括性文本。这样模型永远只看到摘要 最近几轮完整对话既能保持上下文连续性又不会无限膨胀。上下文窗口被占满导致报错输出结果中总是出现旧信息这些都是上下文管理没做好的表现。我的判断标准是只要模型在 8 轮以上的对话中还能记住用户最开始交代的三个关键约束这套上下文方案就算合格了。达不到的话就需要再调整摘要策略或者增大压缩频率。4. 常见问题与排查技巧实录4.1 输出格式不稳定与解析失败我的项目运行中遇到的第一类高频问题就是模型的 JSON 输出偶尔会带多余的说明文字或出现格式断行导致 json.loads 直接抛异常。我踩了几次坑之后总结了一条铁律解析前先清洗清洗不救再重试重试不成功再降级兜底。清洗方案很简单从返回的文本中用正则匹配出第一组{}包裹的内容当作 JSON 处理。大多数情况下模型输出的 JSON 都是被反引号或者说明性文字裹挟的提取大括号内容就足够干净了。如果提取出来依然无法解析那就让模型修复。把报错信息和原始文本一起再发一次请求告诉模型你刚才的输出格式有误请根据错误信息修正后再输出实测修复率相当高。如果重试两次还不行那就只能返回一个默认兜底结果给用户同时告警让开发介入。这个兜底方案看着小但工程上意义很大。AI 应用的健壮性不是指望模型永远正确而是面对模型犯错的时候有一整条降级路径可以走。4.2 token 超限与成本失控项目推进到 RAG 和 Agent 阶段后我发现 token 消耗猛增。最夸张的一次是测试一个复杂任务链路三个 Agent 协作加上检索调用单轮对话烧掉了 30 万 token。一核算成本吓得赶紧停下来排查。排查的结论是Agent 工具调用的循环太开放了。模型在决策过程中可能因为一次错误判断反复调用同一个工具好几遍每次都带回一堆无用的上下文。这种浪费是隐形的你对着控制台看不出明显问题但账单会狠狠教你做人。后来我做了四件事抑制成本失控。一是给每次 Agent 编排任务设置最大调用轮数超过轮数直接强制结束不让模型无限循环。二是工具调用返回的内容只保留核心字段去掉冗余的过程性描述减少上下文进入量。三是每次重新组织 prompt 时裁剪对话历史而不是无脑拼接。四是给模型选择更经济的型号处理中间过程只在最后综合生成时调用最强模型。这四招下来成本直接降了七成效果非常明显。4.3 模型幻觉与答非所问幻觉问题可以算得上 AI 应用里最让人头疼的问题之一了。模型一本正经地告诉你一个完全不存在的数据或者把 A 项目的结论安到 B 项目头上这种事在业务场景中非常致命。原因其实不复杂——模型本质是接着你的话往下编的你的 prompt 给了它想象空间它就顺着最合理的路径生成。所以减少幻觉的方法万变不离其宗不给它自由发挥的空间。给足上下文让参考信息里能找到答案强调来源在 prompt 里说只能基于提供的材料回答不要引用外部知识要求引用让模型在回答里带上检索到的原文片段或编号设置诚实底线没有信息就直接说该信息未在本文档中提及绝不编造。我做过一个实验让模型在没有任何参考材料的情况下回答公司内部某个流程问题它 100% 编造。而给了参考材料但没做引用要求时仍会有两成概率编造细节。加一条只能基于材料回答的提示后编造率降到了 5% 以下。再要求给出引用片段几乎稳定在 0 幻觉。这就是工程干预的力量。4.4 线上监控与效果评估体系最后一条要重点讲讲评估体系。AI 应用的线上效果千万不能靠看着还行来评估必须建立一个量化评估机制。我项目里的做法是建立一个样例集 评分卡双轮机制。样例集里放的是经过精挑细选的黄金测试集覆盖用户最常见的 20 种提问模式和 5 种极端情况每条样例都标注了预期答案和评分标准。每次对 prompt、RAG 策略或模型参数做调整后都要用这套测试集整体跑一遍。评分卡则是从准确性、完整性、可读性三个维度打分每项 1 到 5 分总权重加权求和。哪个维度分数掉了就说明本次改动在这个方向上有副作用需要回滚或再调优。文本相似度计算来做自动化初筛然后把交集的偏差项拿出来人工审查。这样既保证了客观也不至于每天耗太多人力。监控指标上核心盯两个数平均响应时间不能超过 5 秒和 token 成本单次调用不能超过预设水位线。这两个数一旦异常大概率就是上下文策略或者工具调用逻辑出了问题。4.5 模型选型与多模型混合使用最后补充一个项目后期才悟到的东西不要对模型搞一款用到底。合适的模型配合适的任务多模型混合编排才能最大化性价比。我在项目里把模型按成本和能力分了三档小模型负责路由、分类、意图识别这类简单任务快而便宜中模型负责检索结果的整理、信息抽取这类中等复杂任务平衡效果大模型只在最终的复杂生成与逻辑推理环节出现把它当作压轴选手而不是什么杂活都交给它。这一套组合下来整体效果和直接用最强模型几乎持平但成本只有后者的三分之一。选型时一定要做真实的业务样例评测不要只看模型在官方榜单上的跑分。跑分高不代表你的场景表现好我用一个简历信息抽取的样例去测了四款模型表现最好的竟然不是排名最靠前的那款所以实测才是硬道理。这个项目做到现在我最大的体会是 AI 工程的重点不在AI而在工程二字。算法模型固然重要但真正决定一个 AI 产品能不能上线、稳不稳定、值不值得维护的是那些看似不起眼的工程细节上下文怎么管理、输出怎么校验、成本怎么控制、效果怎么评测。如果你也想从零开始做 AI 工程我的建议是先把基础原理啃透再动手做几个完整的小项目感受一下痛点不要一上来就追着热点框架跑。最后再分享一个小技巧把你每次踩坑和对应的排查方案记录下来沉淀成团队的故障手册这比你收藏多少篇教程都管用。