这几年被问得最多的一句话是我该从哪儿开始学AI网上的课程和资料多得吓人但大部分人学完一堆名词之后还是写不出一个能真正跑起来、能解决具体问题的AI系统。原因很简单——我们缺的从来不是模型知识而是把模型变成产品的“工程能力”。这个项目叫“ai-engineering-from-scratch”我的理解就是一件事不依赖任何花哨框架从最底层把AI工程的全链路亲手搭一遍。这篇文章是给两类人写的。一类是想转行做AI应用开发的同学另一类是已经在写业务代码、但觉得“调用API”太散、想系统化理解AI系统的工程师。我会把从提示词设计、模型调用、Agent编排到评测落地的完整思路拆开讲结合我实际跑过的项目代码和踩过的坑尽量用大白话把里面的门道说清楚。1. AI工程到底在解决什么问题很多人以为AI工程就是“调库”或者“写提示词”这是最大的误解。AI工程的核心矛盾在于大模型本身是不可靠的但产品必须可靠。我们要做的所有工作都是围绕这个矛盾展开的。1.1 从“会用模型”到“做AI工程”差了什么先看一段最朴素的代码几乎每个入门教程都会教你这么写from openai import OpenAI client OpenAI() response client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: 介绍一下AI工程}] ) print(response.choices[0].message.content)这段代码能跑但它只是“用模型”。把它放到真实业务里你会发现一堆问题用户输入的提示词五花八门模型输出格式不稳定偶尔还会胡说八道更别提成本控制、并发限流、上下文管理这些工程问题。我在实际项目里总结出一个观点AI工程 模型能力 工程约束 评测反馈。模型能力是地基工程约束是把你对模型的所有不信任用代码兜住评测反馈则告诉你“改完之后到底变好了还是变差了”。三者缺一不可。如果你只在调模型层下功夫那叫“提示词爱好者”把三层都打通了才叫AI工程师。这里分享一个我之前踩过的坑一开始我满脑子只想“怎么把效果调好”结果忽略了一个最基础的工程问题——数据格式。模型输出我用的是纯JSON文本但用户输入的字段经常缺失导致下游解析程序直接崩溃。后来我学乖了任何模型输出都要先做结构校验不符合预期就重试或者走兜底逻辑。这就是典型的“工程约束”。1.2 为什么学了一堆AI知识还是做不出东西这个问题我思考了很久后来发现本质是“知识结构”和“交付结构”不匹配。学AI的人大多数是从论文、课程、排行榜入手的这些材料天生偏向“模型性能”而不是“系统行为”。但企业要的AI系统是能在生产环境稳定运行、可以被监控、被测试、被回滚的软件资产。我可以打个比方学AI像是学做菜课程教的是“这道菜的标准配方”但实际工程是“开一家餐厅”。你不仅要会做菜还要考虑食材供应链数据、厨房动线架构、上菜速度性能、顾客投诉处理兜底策略。很多人在“标准配方”阶段就停了所以永远开不了餐厅。所以我给“从零开始”的路线定了个顺序先用一个最小项目跑通“提示词 → 模型调用 → 输出解析”闭环然后在此基础上叠加“评测集 → 自动化评测 → 回归保护”接着加“工具调用 → Agent化 → 多步骤任务”最后补上“数据回流 → 持续迭代 → 上线监控”。这个顺序是我后来复盘才总结出来的一开始我是一股脑全上结果哪里都在冒烟。1.3 AI工程的技术栈全景用一个表格把核心组件和它们的作用先摆出来后面章节逐个细讲。技术组件解决什么问题常用工具/方法提示词工程让模型稳定输出符合预期的内容结构化模板、少样本示例、思维链模型路由在成本、速度、效果之间做平衡按任务复杂度分层调用上下文管理在有限的上下文窗口里保留关键信息滑动窗口、摘要压缩、检索增强工具调用让模型能操作外部系统Function Calling、MCPAgent编排完成多步骤、需要决策的复杂任务规划器、执行器、记忆模块评测体系量化模型输出质量防止越改越差自动评测集、LLM作为裁判、人工抽检数据回流从失败案例中积累数据持续优化日志采集、标注平台、微调样本池这个技术栈不是每个项目都要全上但你必须知道每个组件是干什么用的。真实的AI工程项目不会只用到一个组件而是根据业务场景把其中几个组件组合起来形成一套“生产线”。我在做第一个正式项目的时候就经历了从“只写提示词”到“被迫搭建评测和日志体系”的完整过程那段时间的成长比看一百篇文章都大。2. 从零到一提示词工程的核心方法论提示词工程是被误解最深的领域很多人以为就是“把需求写清楚”。真正做工程之后你会发现提示词是你要维护的第一份“代码”它需要做版本管理、有测试用例覆盖、能应对边界输入。2.1 提示词的本质是接口设计不是聊天我第一次被“打脸”是在给一个法律问答系统写提示词的时候。我在提示词里写了“请用专业、严谨的语气回答”结果模型输出的内容里还是混进了一些网上常见的段子式表达。后来我反思问题出在“语气”这种抽象描述上——模型对抽象形容词的理解非常不稳定。把提示词当成接口设计之后我的写法完全变了。我会明确输入格式、输出格式、约束条件、兜底方案比如这样你是一名法律知识库助手。请严格基于以下资料回答问题。 资料 {context} 用户问题{question} 要求 1. 如果资料中没有相关信息请明确回答“根据现有资料无法回答”。 2. 输出格式为答案 引用来源编号。 3. 不要对超出资料范围的内容做推测。这个模板和“请专业回答”的差距在哪差距在于它把不确定性降到了最低上下文范围确定了输出格式确定了超出范围的处理方式也确定了。模型就算发挥“自由意志”也只能在这个框架里发挥。我从这个项目里总结出一个关键原则提示词里每多一个抽象形容词输出里就多一分失控的可能。要写就写可验证的约束不要写“语气温柔”“逻辑清晰”这类无法自动检查的描述。2.2 一套可复用的结构化提示词模板这里分享一个我维护了很久的通用模板它的结构分为五个区块角色定义、任务目标、输入变量、输出约束、边界处理。这个模板几乎可以适配80%的文本生成类任务。## 角色 你是{角色描述}具备{能力边界}。 ## 任务 你需要完成{任务描述} 输入材料如下 {input} ## 输出格式 必须按照以下结构输出 {output_schema} ## 质量要求 1. {可验证的约束A} 2. {可验证的约束B} ## 边界处理 - 如果输入信息不足输出{兜底文案} - 如果检测到有害内容输出{拒绝文案}你在使用的时候不需要把这套东西背下来关键是理解每个区块的作用。角色定义负责给模型一个“行为方向”任务目标负责聚焦输出格式负责让结果可程序化解析质量要求负责压缩发散空间边界处理负责兜住“最坏情况”。我见过最典型的反面教材是什么是开发者在提示词里写了一堆“不要”“禁止”“千万别”——结果模型的注意力被这些否定词吸引了反而更容易输出你不想看到的内容。更好的做法是把期望行为正面写清楚然后用边界处理去兜底。2.3 提示词也需要版本管理和回归测试这是我想特别强调的一点也是初级和资深工程师的分水岭。提示词不是一次性写完就完了它和代码一样需要版本管理。最痛苦的情况是某一天你改了系统里的逻辑发现整体效果变了但你根本不知道是因为代码改的还是因为提示词改的——如果提示词没有版本管理你就要在黑暗中摸索。我现在的做法是把提示词文件化用Git管理提交信息写清楚“改了哪里、为什么改、期望效果是什么”。然后在核心评测集上跑回归对比改动前后的得分。这里的核心逻辑是每次提示词变更先跑一遍评测集记录得分。变更后得分下降立即回滚。变更后得分上升保留并更新基线。这个流程听起来简单但一旦项目进入迭代期省下的时间是非常可观的。没有测评体系的团队几乎天天在“调优”和“回滚”之间反复横跳最后连自己都说不清哪版提示词是能用的。说到评测我多提一句。很多人觉得评测就是“把几个问题丢给模型看看回答好不好”。这种做法在探索期没问题但不能作为工程依据。我后面会专门讲评测集的搭建这里先留个钩子。3. AI Agent与工具调用的实战拆解现在聊Agent。这个词被炒得很热但很多项目只是给模型套了个“能调函数”的外壳就敢叫Agent。真正的Agent核心是能在一个多步骤任务里自己决定下一步做什么并且能在一个循环里不断接收反馈、修正路线。3.1 Agent的工作机制规划、行动、观察的循环我用一个生活化的类比来解释Agent。假设你让一个实习生去“查一下某竞品公司最新的融资情况整理成一页报告”。这个实习生不会只做一步他会先想“需要查什么信息”然后打开搜索引擎看结果发现有的页面打不开就换个关键词再查最后把信息汇总成报告。Agent做的事情一模一样只是由模型来扮演实习生。底层的循环逻辑是1. 给Agent一个目标 2. Agent根据目标生成“下一步计划” 3. Agent调用工具执行计划搜索、计算、读写数据库等 4. Agent观察工具返回结果 5. 根据结果决定“继续”还是“结束” 6. 循环直到目标达成或达到最大步数从工程上讲Agent的核心是“工具的定义和容错”。如果工具返回了异常结果Agent得能读懂错误信息并调整策略。如果工具超时Agent不能一直卡在那里。我在实现时会给每个工具定义一个“重试次数”和“失败文案”让模型在异常时能做出下一步判断。3.2 设计一个靠谱的Agent知识客服的真实案例我做过一个内部知识库客服Agent目标是从公司成千上万的文档里快速找到答案并回复用户。技术方案不复杂检索增强生成RAG 工具调用。但真正做到“靠谱”是连续迭代了三四周才达成的。先看看整体流程我给这个Agent设计了三个工具search_documents(keyword)从向量数据库检索相关文档片段。get_document_detail(doc_id)获取某篇文档的完整内容。escalate_to_human()人工介入的兜底工具。流程是这样的用户提问后Agent先用search_documents检索相关片段判断片段是否足够回答。如果信息不够就调用get_document_detail补充细节。如果连续两轮检索都无法定位答案就调用escalate_to_human把用户转给人工客服。这里的关键设计是“判断是否足够回答”。我把它做成了一个单独的提示词判断步骤而不是让Agent在同一个上下文里“边看边想”。单独的判断节点更容易测试和调优出了问题你能立刻知道是“检索烂了”还是“判断错了”。这种模块化思想是Agent工程和“让模型自由发挥”的最大区别。3.3 多Agent协作什么时候该用什么时候不该用现在的热点是“多Agent协作”把不同角色分配给不同Agent让它们互相讨论、共同完成任务。我用过的感觉是多Agent的上限很高但下限低得可怕。如果任务本身不需要分工强行拆多个Agent只会增加延迟、上下文混乱和不可控性。我的经验法则是如果任务可以被当成“一条流水线”就拆多个Agent如果任务只是“一次复杂的问答”就老老实实用单Agent 工具。比如“写一篇文章”这种任务可以拆成“调研Agent → 起草Agent → 审核Agent”每一步输入输出都清晰这是流水线适合多Agent。但“回答一个综合性问题”这种任务强行拆成“检索Agent”和“回答问题Agent”中间的多轮通信成本还不如一次性做完。还有一个容易被忽略的问题多Agent协作的“上下文隔离”。每个Agent的上下文不能无限膨胀要设计好“交接文档”就是上一个Agent输出的全部信息放到一个结构化字段里下一个Agent只依赖这个字段工作。这就像工厂流水线上传递的“工单”而不是让上一个工人当着下一个工人的面把所有事再讲一遍。4. 工程落地从原型到可交付系统的完整流程很多人的项目卡在“原型很好产品崩了”这个阶段。原型只要一个人、一晚上、一个API key就能跑通但可交付系统要面对的是真实用户、真实数据、真实故障。这一章我完整复盘一个我用AI工程思路从零搭建的项目。4.1 第一步需求拆解与场景边界划定我接到过一个需求“做一个能帮用户找租房信息的AI助手”。这句话一听就很不工程。你的用户是哪个城市预算区间偏好什么的房屋类型信息源是哪几个网站回答的形式是列表还是自然对话做不到这些“约束”你的AI助手就是个玩具。我做的第一件事是把需求拆成“能自动化”和“必须人工”两部分。AI能做的部分包括从结构化数据源筛选符合条件的房源、按用户偏好排序、用自然语言生成推荐说明、回答关于房屋配置的基础问题。必须人工的部分包括线下看房、合同细节确认、押金纠纷处理——这些完全不适合AI介入。然后我明确了一圈“边界场景”用户问的内容超出已接入的房源数据范围 → 礼貌告知“暂未覆盖该区域”。用户表达的是模糊意图比如“随便看看” → 主动追问明确偏好。用户对推荐结果不满意超过两次 → 转人工客服。划定边界不是给产品设限而是让AI系统有一个明确的能力圈这样你后面做的所有评测和优化都有了基准。没有边界的系统就像没有围栏的牧场迟早会“跑丢”。4.2 第二步RAG系统的搭建与上下文管理这个项目的信息来源是几百条结构化的房源记录量不大不需要用特别复杂的向量检索方案但对“准确率”的要求很高——用户问“有没有带地下室的”你不能因为语义相似就把“带阳台”的房子推出去。RAG系统的核心链路是文档切分 → 向量化入库 → 检索召回 → 重排筛选 → 送入模型生成回答。每一步看起来都很简单但每一步都会引入误差所以我非常注意细节。举个例子文档切分如果按固定长度切很容易把“一房一厅”切到上一段、“带阳台”切到下一段检索的时候就会漏掉关键信息。我改成了按“房源编号”做切分单位每套房子的描述作为一个独立片段入库。这样虽然在向量相似度上不如细粒度切分“灵活”但在业务精度上更可靠。上下文管理是另一个大坑。长对话场景下用户可能前面说了“要朝南”后面问“那这间呢”模型如果没有记住前文的约束就会给出错误推荐。我的方案是做一个“约束记忆模块”把对话中所有带明确条件的用户描述如“朝南”“预算5000以内”“不要一楼”自动抽取成结构化约束拼接进每次检索和生成的提示词里。这个方案比直接把整段对话塞进上下文更稳定而且能跨会话复用。4.3 第三步AI系统必须要有评测和回归保护这是我反复强调的一点没有评测的AI工程就是裸奔。我在这个项目里的做法是先花一天时间手工整理了50条真实用户问题覆盖了正常询问、模糊查询、超范围查询、恶意输入四大类。然后把每道题的“期望行为”明确写成可执行的判定规则而不是靠肉眼判断。评测分两层。第一层是客观规则可以直接用代码判定。比如“输出中是否包含指定房源ID”“超范围问题时是否按兜底文案回答”。第二层是主观质量我让一个更强模型当“裁判”按几个维度打分回答是否直接、是否完整、是否与检索结果一致。主观打分不能全信但用来做“数值参考”很有价值。有了这套评测后续改任何东西都有了依据。比如我试过把模型的温度参数从0.1调到0.4评测得分立刻有了可量化的变化——温度升高后回答更“丰富”但含有无关信息的次数也变多了。这种时候你就能用数据说服团队“这个改动该回滚”而不是凭感觉争论。4.4 第四步数据回流与持续迭代的闭环系统上线只是开始真正的工程价值在迭代回路里。用户问了什么问题、模型哪里回答得不好、哪个功能被高频触发——这些数据是AI系统最宝贵的资产。我的做法是给每次对话记录完整日志用户原始输入、系统检索的文档片段、模型输出、用户是否满意如果有反馈按钮、是否触发人工介入。每天晚上跑一次离线分析把“模型回答不合格”的案例挑出来进入标注池然后每周做一轮“硬案例复盘”。硬案例复盘的做法很简单把这周所有“答错了”的问题拿出来逐个分析原因——是检索没召回到正确文档是提示词约束不够还是模型理解错了原因分类之后针对性修。检索的问题改切分和检索逻辑提示词的问题改模板模型理解的问题则在提示词里补充少样本示例。很多团队问我为什么我的AI项目能持续变好他们的一两个月后就原地踏步了。答案就是这套闭环线上数据 → 失败分析 → 定向优化 → 回归评测 → 重新上线。AI系统的效果不是靠一次“大力出奇迹”调出来的是靠一轮一轮的迭代堆出来的。5. 常见问题与排查技巧实录这一章我把自己在多个AI工程项目里处理过的高频问题整理一下每条都来自实际线上环境。你可以把这一节当“排障速查表”用。5.1 模型输出乱变怎么调都稳不住怎么办这是排名第一的痛点。模型在某些问题上回答得很好一换问题风格就崩。我排查的第一步不是改提示词而是先看输入。很多时候“乱变”不是模型的问题是输入格式太乱——用户可能发来一堆口语化吐槽、表情符号、粘贴的网页内容模型被带偏太正常了。我的做法是在模型调用前加一个“输入清洗节点”把用户的原始输入标准化去掉无意义的符号、抽取核心意图、把长文本压缩成要点。这个节点可以是一个比较便宜的小模型调用也可以用规则实现。清洗之后再送给主模型稳定性会明显提升。另外一个常见原因是上下文污染。对话进行到第10轮前面某轮用户随口说了句“其实我也不确定我要什么”模型可能就“记仇”了后面的回答开始变得犹豫。解决办法是前面说的“约束记忆模块”——只保留经过抽取的结构化约束而不是把全量历史塞进上下文。5.2 检索不到正确答案但知识库里明明有RAG系统最常见的问题就是“召回不准确”。我遇到过一次很经典的案例用户问“支持24小时入住吗”知识库里有一句话是“本公寓提供全天候入住服务”但检索系统死活召回不到这句话。原因在于“24小时”和“全天候”在语义上虽然接近但在向量空间里的距离不够近排序时被更相似的其他内容挤掉了。我的排查思路分三步。第一步看召回Top10里到底有没有正确答案如果有那是重排逻辑的问题如果没有那是切分或检索策略的问题。第二步检查是不是关键词匹配太严格很多传统的检索方案还带了BM25混合权重不要因为混了关键词就忽略了语义检索。第三步如果召回质量持续不行就要补充同义改写——把用户问题里的口语化表达改写成一个更规范、更贴近库内语料的版本再检索。这个“查询改写”在很多场景下比换模型还管用。5.3 成本太高怎么办模型路由和缓存AI系统上线后很多团队第二个痛点是账单。一次复杂的Agent任务可能会调用模型十几次成本蹭蹭涨。我的做法是做“模型路由”简单任务用便宜的小模型复杂任务才调用大模型。具体怎么分我用一个“前置分流”规则比如用户问题长度短于30个字、且命中规则库里的“高频简单问题”直接走小模型加固定答案模板。只有需要推理、对比、多文档综合的问题才走大模型。这个分流逻辑用代码实现不依赖模型判断非常可控。缓存也值得做。很多用户的提问是相似的直接复用历史答案能省掉一大笔费用。我在实现时做了“语义缓存”用向量相似度判断新问题是否命中缓存库命中就直接返回不再调用模型。实测下来在重复度较高的客服场景里缓存命中率能做到20%-30%成本节约非常可观。5.4 Agent卡死、死循环、工具调用失败Agent类应用的上线问题主要集中在“不稳定”。我踩过的坑包括Agent在“检索→不满足→再检索”之间无限循环、工具返回了非JSON格式导致解析崩溃、模型误用了参数名导致工具调用失败。我的处理方式有几个。第一一定要设置最大迭代次数这属于“保命条款”。第二工具调用的返回结构必须是强约束的JSON解析失败时不要硬解析而是把错误信息反馈给模型让它自己修正重试。第三给工具调用加“异常出口”——连续失败N次后Agent必须停止并返回友好错误。这里我特别强调一下“把错误反馈给模型”这个设计。很多实现里工具调用失败就直接给用户报错了但Agent的意义在于它可以“自己救自己”。你只需要在工具返回里附带一行error: 解析失败请检查参数格式模型就会发现并修正。效果比对用户友好得多也更像一个“真人员工”的行为方式。5.5 工具与平台选型的避坑建议最后聊一下选型。市面上的AI开发框架很多各有各的适用场景但如果你的目标是“吃透AI工程原理”我的建议是先徒手写再上框架。徒手写一个包含检索、提示词拼接、模型调用、输出解析的完整链路你会对每一步的开销和脆弱点有体感。这个过程就像学驾驶先开手动挡虽然慢但理解深。如果你已经比较熟练可以考虑用一些偏底层的工具来提效向量数据库选开源的也行主流商业的也行关键是看数据量级和延迟要求Agent编排可以用框架但要知道框架只是帮你管理循环和状态底层的模型调用和评测逻辑还是你的核心资产。评估一个框架值不值得用我就看三点是不是有活跃社区维护、是不是容易接自定义模型、是不是把评测能力内置了。三者缺一个我都要多掂量掂量。我见过太多项目因为跟风用了某个炫酷框架结果框架本身迭代跟不上需求最后被卡住脖子。最后说一点实际感受。AI工程的门槛其实不在模型而在系统思维——你能不能把一句话的需求变成一个出了问题能定位、改了能验证、上线能监控的完整系统。跨过这道坎的过程很痛苦但跨过去之后你会发现所有AI应用的本质都一样模型提供可能性工程兜住确定性。这个“从零开始”的路走一遍就回不去了。