我最早想系统地写“ai-engineering-from-scratch”这件事其实不是因为看了什么热门课程而是踩了一次实实在在的坑。当时我们团队打算上一个AI Agent来做自动化测试老板丢过来一句话“把接口测试、回归测试都交给AI。”听起来很轻松对吧结果我们连第一条提示词模板都没写对模型一本正经地生成了不存在的测试数据还给了绿色的通过报告。那一刻我才意识到AI工程和“调一个API”之间的距离远比大多数人想象的大。它需要一套从数据、模型、提示词到评估、部署、迭代的完整体系任何一个环节掉链子整个系统都会翻车。这篇文章我想以“从零开始搭建AI工程体系”为主题把这条路拆开讲透重点回答三个问题AI工程到底在工程化什么真正的实操步骤是什么最容易在哪些环节翻车适合准备做AI应用、AI Agent、智能客服或自动化流程的开发者、架构师也适合那些已经接过大模型API但总觉得“味道不对”的团队参考。内容会尽量口语化但该上代码上代码该给参数给参数基本可以照着抄。1. 内容整体设计与思路拆解AI工程到底在工程化什么1.1 AI工程的三个层次先想清楚一个基础问题AI工程和传统软件工程差在哪儿传统工程解决的是“确定性逻辑”输入输出可以被穷举和测试AI工程面对的是概率模型同样的输入模型可能给出不同答案甚至给出错误但看起来很合理的答案。所以AI工程的核心不是“写代码调用模型”而是围绕这种不确定性建立控制机制。我习惯把AI工程拆成三个层次来看应用层你最终交付的Agent、智能客服、内容生成工具、自动化测试系统这是用户直接接触的东西。能力层大模型本身、提示词模板、函数调用、向量数据库、工具链编排这是让AI“能做事”的部分。基础设施层数据准备、评估体系、监控告警、成本控制、版本回滚这是决定AI系统能不能长期运行的底座。很多人从应用层开始直接写界面、接API跑到一半发现模型质量不行才回头补提示词、补数据、补评估整个项目变得像个打补丁大赛。正确的思路是从基础设施层往上走先定义“什么样的输出算合格”再选模型、设计提示词最后才是把功能包装给用户。1.2 为什么从零开始反而更高效这句话听起来有点反直觉因为网上到处是现成的框架、模板、脚手架。拿过来用不香吗香但容易让你跳过关键决策。你用了别人封装好的Agent框架却不知道它内部是怎么做工具调用的你复制了一段很酷的提示词却不清楚它为什么有效。等到线上出问题时你对系统的理解仅限于“它能跑”而不是“它为什么这样跑”。从零开始我指的是从最核心的调用逻辑开始不用重型框架先用原生SDK写一个能跑的最小闭环然后逐步替换和优化。这个过程类似于自己从水电图开始装修而不是直接买精装房。最早的那版代码可能很粗糙但你会因此在每个环节建立感觉——模型输出质量、响应延迟、上下文占用、成本波动这些体感是看文档永远无法替代的。我自己的经验是用最小的代码量跑通一次“输入→模型→输出→评估”之后再回头看LangChain之类的框架才能真正理解它们解决了什么问题、又带来了什么新的复杂度。否则你只是在一个黑盒上继续盖黑盒。1.3 什么时候你已经进入“AI工程”的坑有些信号很典型出现两个以上说明你已经需要体系化思路了提示词改了十几个版本效果时好时坏无法判断是词序问题还是模型抽风同一个问题换了一种问法就崩你开始怀疑是不是用户不会说话Agent偶尔调用错工具、偶尔卡在死循环团队里没有人能解释原因成本账单数字吓人但你说不清钱花在了哪些请求上模型升级之后原本正常的业务流程突然开始出错没有任何代码变更。如果这些情况你至少中了一半那就别继续“打补丁”了重新整理一下你的AI工程体系会更划算。2. 模型选型与提示词工程的实操要点2.1 模型选型先别急着做选择题很多团队一上来就问“用GPT-4还是Claude还是开源的某某”这是典型的顺序错误。第一步先想清楚任务类型再决定用哪类模型。任务类型推荐模型类别主要考量点开放域聊天、内容生成、头脑风暴通用对话模型表达质量、上下文长度、风格控制数学推理、代码生成、逻辑判断专用推理/代码模型逻辑正确性、代码执行能力知识库问答、相似度检索嵌入模型通用模型组合向量维度、检索召回率、生成幻觉率结构化数据抽取、分类、标注小参数模型或微调模型输出格式稳定性、成本多模态图片、音频、视频多模态模型输入限制、内容理解精度核心逻辑很简单不要用通用模型硬扛所有任务。拿分类和抽取这种结构性强、规则明确的任务来说用大模型有点浪费用小模型配合约束生成甚至正则成本和延迟都可以大幅下降。而复杂推理任务通用模型往往不如专门的推理模型靠谱。另外要注意模型版本冻结问题。大模型厂商经常更新版本看起来只是小迭代实际效果可能有波动。如果你做的是正式业务系统千万不要在代码里写“用最新模型”这种逻辑必须显式锁定版本号并建立升级前的回归测试机制。我自己就吃过这个亏——模型厂商把某个能力“悄悄增强了”结果我们的输出格式多了一个字段把解析模块干崩了。2.2 提示词工程的三个习惯提示词工程听起来很玄学好像是在跟模型“说话”。其实它是一门工程化的内容设计学科核心目标是降低输出的不确定性和解析成本。我总结了三个习惯基本能覆盖大部分场景。第一个习惯永远明确角色、任务、约束、输出格式。不要只写“帮我总结这段文字”而要写“你是技术文档整理助手请将以下内容总结为三条要点每条不超过30字使用中文输出不要出现‘首先/其次’之类的词直接给要点列表”。每多明确一个约束模型输出的可预测性就提升一截。第二个习惯用示例代替形容词。如果你告诉模型“要专业一点”它会给出一堆含糊的官话如果你给它两个“专业输出”的例子它会照着例子的结构走。在提示词里嵌入Few-shot示例是成本最低、效果最明显的手段。示例不在于多两三个高质量的反而比一堆凑数的更管用。第三个习惯把需要模型自由发挥的部分压缩到最小。能选项就选项能JSON就JSON。比如判断用户情绪不要问“情绪如何”而是给出枚举“positive / neutral / negative / mixed”再配合输出格式约束。这样你的下游解析只需处理固定枚举值不需要去做情感分析文本的二次解析系统稳定性会高很多。2.3 AI Agent从函数调用开始Agent的本质是让模型学会“使用工具”。目前最主流的实现路径是Function Calling函数调用模型在生成回复时不是直接输出最终答案而是输出一个工具调用指令你的代码执行这个工具再把结果反馈给模型形成一轮新的推理循环。这就是教科书里常见的ReAct模式Reason思考→ Act行动→ Observe观察结果→ 循环直到得到结论。我把一段最简可用的函数调用逻辑写成代码import openai from openai import OpenAI client OpenAI() # 定义一个“查询订单状态”的工具 tools [ { type: function, function: { name: get_order_status, description: 根据订单号查询订单的当前状态, parameters: { type: object, properties: { order_id: {type: string, description: 订单号} }, required: [order_id] } } } ] def get_order_status(order_id: str) - str: # 这里模拟查询数据库或调用内部接口 status_map {20240101: 已发货, 20240102: 待付款} return status_map.get(order_id, 未找到订单) messages [ {role: system, content: 你是订单助手必须通过查询工具回答订单问题。}, {role: user, content: 请帮我查一下订单 20240101 现在是什么状态} ] response client.chat.completions.create( modelgpt-4o-mini, # 生产环境务必锁定具体版本快照 messagesmessages, toolstools, tool_choiceauto, ) # 如果模型决定调用工具 if response.choices[0].message.tool_calls: tool_call response.choices[0].message.tool_calls[0] result get_order_status(tool_call.function.arguments) # 实际执行工具 # 把工具结果反馈给模型 messages.append(response.choices[0].message) messages.append({ role: tool, tool_call_id: tool_call.id, content: result }) final_response client.chat.completions.create( modelgpt-4o-mini, messagesmessages, toolstools, tool_choiceauto, ) print(final_response.choices[0].message.content)这段代码看着很短但包含了Agent系统的核心循环模型决策调用工具、程序执行工具、结果回填模型、模型继续推理。实际项目中工具数量可能几十个、几百个还涉及工具调度的优先级、并发控制、超时处理、工具鉴权复杂程度呈指数上升。但从最简实现开始你能牢牢掌握“模型是决策器代码是执行器”这一原则。3. 从零搭建一个可用AI应用一个完整实操案例3.1 业务背景与功能拆解理论讲再多不如跑一个完整项目。我以一个“智能客服工单自动分类回复助手”为例这个项目足够典型有结构化数据工单编号、客户信息、有非结构化文本问题描述、有决策动作分类和回复还涉及内部工具调用查询历史订单、查询退款进度。核心功能拆成三步工单分类把客户问题归入“订单查询 / 退款退货 / 技术咨询 / 投诉建议”四类信息提取从问题文本中提取订单号、退款金额等结构化字段回复生成基于当前状态生成给客户的回复草稿。这个流程其实就是很多企业“AI客服”的最小原型。技术上并不复杂但涉及了模型选型、提示词模板、结构化输出、工具调用和数据回流足够完整地展示AI工程的骨架。3.2 环境准备与一个小型实现我习惯用Python OpenAI SDK来实现但思路完全适用于其他大模型服务。核心依赖只有两个openai和pydantic前者用来调用模型后者用来做结构化输出校验。先准备一个数据提取模块。这部分用结构化输出JSON模式而不是纯文本回复目的是把结果变成可校验的Python对象from openai import OpenAI from pydantic import BaseModel, Field import json client OpenAI() class TicketInfo(BaseModel): category: str Field(description工单分类order_query / refund / tech_support / complaint) order_id: str Field(description从问题中提取的订单号没有则为空字符串) amount: float Field(description涉及的金额没有则为0) urgency: str Field(description紧急程度low / medium / high) def extract_ticket_info(question: str) - TicketInfo: response client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: 你是工单信息抽取助手。只输出规定字段的JSON。}, {role: user, content: f请从以下用户问题中提取信息{question}} ], response_format{type: json_object}, ) raw_json json.loads(response.choices[0].message.content) return TicketInfo(**raw_json)这段代码的关键在于response_format{type: json_object}。没有这个约束模型可能把JSON包在Markdown代码块里解析脚本会气得骂人加了之后输出直接就是干净的JSON配合Pydantic的校验基本杜绝了“字段缺失”“类型不对”这类问题。接下来是工单分类提示词模板。我把模板设计在代码之外单独放在配置文件里这样后续优化提示词不需要发版本改配置就行。生产环境强烈建议这样做SYSTEM_PROMPT 你是电商平台的智能客服预处理助手。 你的任务是对用户的工单问题做分类并提取关键信息。 输出必须满足以下JSON结构 { category: order_query | refund | tech_support | complaint, order_id: 字符串如不存在则填空字符串, confidence: 0到1之间的数字 } 注意 1. 必须完整输出JSON不要加任何解释文字。 2. 如果信息不足字段填空值不要猜测。 3.3 工作流、评估与数据回流闭环代码能跑通只是第一步AI工程的重点在“闭环”。我搭建这套智能客服系统时真正花时间的不是代码而是评估体系和数据回流。评估体系分三块单元评估针对分类和抽取模块准备一批人工标注的测试用例。每次修改提示词先过一遍这组用例计算准确率和字段完整率。场景评估模拟真实对话流程比如“查订单→催退款→转人工”观察Agent在长上下文中的行为是否符合预期。回归评估把线上出现过问题的case存成测试集模型每次升级、提示词每次改动都必须重跑一遍防止“修好一个问题引入三个问题”。数据回流是很多团队忽略的部分。线上用户的提问是最宝贵的训练素材和评估素材但直接拿用户数据去调整模型策略会涉及隐私合规问题所以一般做法是脱敏后存入样本库。我习惯把所有失败的case模型输出不合格的、Agent判断错误的自动存下来每周做一次复盘把共性case补充进测试集。这套闭环一开始感觉很麻烦但它本质上是一个质量守门员。没有它你根本分不清下一次效果变好是“提示词真的有效”还是“这次模型运气好”。4. 落地过程中的常见坑与排查技巧实录4.1 提示词不稳定与模型幻觉提示词不稳定的表现是同样的输入换成不同措辞结果差距很大。这个问题只能通过结构化和约束来缓解不要指望模型“理解你的深层意图”。具体做法是给模型提供确定的选项、预设的结构、明确的反例。有一次我们把系统提示词里的“不要输出多余内容”改成“只输出JSON对象”错误率立刻下降了非常多。细节差别就是这么大。模型幻觉则是另一类问题集中在知识库问答里。模型不是搜索引擎它不知道知识边界容易一本正经地编造答案。我们的解决方案是“先检索后生成”RAG先通过向量数据库检索相关知识片段再把这些片段作为上下文交给模型生成。如果检索不到相关片段直接让模型回答“我不知道”这样就切断了幻觉的主要来源。注意RAG只能降低幻觉概率无法完全消除关键场景仍需要人工审核或置信度阈值拦截。4.2 上下文管理、记忆与成本失控Agent类应用最容易被忽略的问题是多轮对话中的上下文膨胀。每轮都塞入完整历史很快就把模型的上下文窗口撑爆。常用的策略是窗口截断、摘要压缩和关键信息提取三结合。窗口截断就是只保留最近几轮对话摘要压缩是对早期对话做一轮总结用摘要代替原文关键信息提取是把订单号、用户名这类必须长期记住的信息单独存下来每次拼进上下文。这三种策略可以在成本和质量之间找到一个相对合理的平衡。成本失控和上下文膨胀是直系亲属。你的每轮请求都在为上下文长度付费而且输入和输出的价格模型不同很多团队看到账单时才发现最烧钱的不是推理而是那些无意义的历史记录。对策是给每条对话设置预算上限、为上下文做一个“引用链”只携带与当前问题相关的片段。成本监控必须从一开始就做不要等月底账单吓人再亡羊补牢。4.3 典型问题速查表问题现象常见原因排查方向同样的提示词今天好用明天不好用模型版本浮动 / 上下文内容变化锁定版本快照对比线上上下文日志输出格式频繁解析失败提示词约束不足 / 模型版本变化启用JSON模式补强schema校验增加重试逻辑Agent调用工具越来越频繁但无效提示词鼓励“多用工具” / 工具描述不清晰精简工具描述增加工具使用条件约束回复出现编造的订单信息RAG检索为空 / 上下文信息不足空检索兜底逻辑强制输出“无法确认”成本突然翻倍上下文膨胀 / 重试次数过多查看请求token均值做上下文压缩和重试上限限制模型分类判断越来越慢上下文太长 / 工具列表过多做分类检索只保留相关工具子集用户说“客服越来越笨”上下文被无关信息污染增加关键字段记忆弱化历史全量回传这套排查思路不只是针对智能客服放到任何AI应用上都通用。我建议每个AI项目从第一天就建一套线上日志系统把每次请求的输入输出、token消耗、延迟、模型版本都记录下来。踩坑并不可怕可怕的是你连踩的坑长什么样都看不清。最后说一点个人体会。AI工程真正难的地方不是某个模型有多强而是你要为不确定性搭建足够坚固的护栏。从零开始不是最省力的路但绝对是你理解AI系统最快的一条路。把最小闭环跑通、把评估体系立起来、把失败case沉淀成资产这些基本功做到位之后你会发现任何新模型、新框架都只是工具箱里又多了一把好用的工具而不是能让你偷懒的魔法。
