手把手从零搭建AI工程：提示词、RAG与Agent实战

1. 先搞清楚“AI工程”到底在工程什么1.1 AI工程不是调API是一整套流程很多人听到“AI工程”四个字第一反应是“这不就是调接口嘛”。这种理解不能说全错但会严重限制后面的成长空间。我接触下来真正意义上的AI工程核心不是“调用一个模型”而是围绕模型构建一套稳定、可维护、能解决实际问题的系统。从数据清洗、提示词编写、模型选型、参数调优到工作流编排、输出校验、异常兜底每一个环节都是在“做工程”。用一个生活化的类比来说会用微波炉热饭和开一家餐厅是两回事。前者是“使用AI”后者才是“AI工程”。餐厅要考虑食材采购、菜品设计、出餐流程、品质控制、顾客反馈闭环哪一环掉链子都会砸招牌。AI工程也是这样模型只是其中一件厨具真正决定上限的是你怎么围绕它构建起完整流程。标题里“from scratch”这个词非常关键。它意味着你不是在一个已经搭好脚手架的项目里修修补补而是要从空目录开始自己决定技术栈、自己验证可行路径、自己踩坑再填坑。这个过程很磨人但恰恰是建立系统认知的最佳方式。如果你只是想尽快出结果可以走快速路线用现成框架一键起项目但如果你想真正理解AI工程的内核“从零开始”这四个字值回票价。1.2 核心能力圈盘点Prompt、RAG、Agent与工具链市面上讨论AI工程时常常蹦出各种术语比如prompt engineering提示工程、AI Agent、RAG、工作流编排、AI编程等。这些词看着多追根溯源其实都围绕一个核心问题怎么让模型稳定地做对事情。我用一个四层漏斗来理解这些概念层级关键词核心要解决什么问题第一层提示工程让模型听懂你的意图输出符合预期的格式和内容第二层RAG / 上下文管理让模型访问到它训练时没见过的新信息并降低幻觉第三层Agent / 工具调用让模型能自主规划步骤并调用外部工具完成任务第四层工作流 / 工程化把单次交互变成稳定、可复用、可运维的完整流程这四层是渐进的。第一层不过关后面全白搭第二层能解决大量真实业务问题第三层打开了自动化想象空间第四层才是落地到生产环境的临门一脚。一个健康的AI工程学习路径应该按这个顺序往上爬而不是一上来就追Agent或者微调。这里特别提醒一点很多人被“AI Agent”吸引觉得它能自动搞定一切但Agent本质上依赖前两层的能力。模型如果都听不懂你在问什么它的“自主规划”只会越跑越偏。我从实践中得到的体会是与其一开始追求花哨的Agent框架不如先把提示词质量打磨到稳定水平再把知识库接上最后再考虑让模型自主决策。1.3 这篇内容适合谁能帮你解决什么问题这篇文章适合三类人。第一类是刚开始接触AI开发、想建立“工程思维”的初学者在到处看教程却不知从何下手第二类是有API使用经验、但觉得效果总是不稳定、想系统提升的开发者第三类是技术负责人或创业小团队需要从0到1搭建内部AI工具链想避开弯路。文章后面我会讲四块内容从零搭建本地开发环境与模型选型方案、一个手把手的AI工程小项目实操本地知识问答助手、一套不跑偏的自学路线以及我在实际过程中踩过的一些坑和排查心得。这些都不是教科书理论而是我自己试错、对比、复盘后的结果。2. 从零起步环境与工具链怎么选2.1 先评估现实条件硬件、成本与场景边界“从零开始”的第一步不是下载软件而是先想清楚自己的硬约束。做AI工程有三种典型的资源形态纯本地部署、纯云端API、本地与云端混合。我在实操中的选型原则是先明确数据敏感度、预算上限和响应速度要求再在这三个维度里画一条约束线。纯本地部署的优势是数据不外流、长期使用成本稳定适合个人学习和对隐私敏感的场景。但代价也很现实需要一块足够显存的显卡。我用一个粗算方式做过评估运行7B参数级别的量化模型大概需要6GB到8GB显存跑14B模型至少要12GB以上想要把70B级别的开源模型跑得流畅32GB显存才算宽裕。如果你的设备达不到不用硬着头皮上云端API也是一种非常务实的开端。纯云端API的优势是开箱即用、模型强大、维护成本低按调用量计费。适合快速验证产品想法、处理非敏感数据。我见过很多个人开发者和中小团队第一版MVP都是靠云端API跑通的等商业模式验证成功后再考虑私有化部署。混合路线则是把私有数据放在本地用开源模型做预处理或过滤再调用云端大模型做理解类任务兼顾隐私和效果。2.2 开发环境Python、IDE与AI编程辅助确定了资源形态后开发环境的搭建顺序就相对标准了。我建议从Python开始因为当前AI生态里Python是工具链最全、示例最多、社区资源最密集的语言没有之一。版本上选3.10或3.11都行这两个版本对PyTorch、Transformers等主流库的兼容性最好。装完Python后再用virtualenv或conda建一个独立的虚拟环境这能避免项目依赖冲突。IDE方面Visual Studio Code和PyCharm是目前使用率最高的两个选择。VS Code轻量、插件生态丰富特别适合做AI相关开发PyCharm对Python项目结构管理更细致适合习惯用IDE重模式的开发者。另外AI编程插件已经是很成熟的辅助工具可以帮你补全代码、解释报错、生成模板。我用下来的感受是这类插件能显著减少“查语法、找文档”的碎片时间但不要让它代替思考尤其是架构层面的决策必须自己拿主意。安装依赖时给一个常见命令序列方便直接参考# 创建并激活虚拟环境 python -m venv .venv # Windows激活命令 .venv\Scripts\activate # macOS/Linux激活命令 source .venv/bin/activate # 安装核心依赖 pip install python-dotenv openai # 如果走本地开源模型路线还需要安装 pip install transformers torch装完后建议顺手配置环境变量文件把API密钥这类敏感信息放到.env文件里不要硬编码在源码中。这个习惯虽然麻烦但对后续工程化的安全是加分项。2.3 模型选择四条路线怎么选模型选型是整个环节中最容易犯选择困难的地方。目前比较清晰的路线有四条云端闭源模型API效果最强、中文能力好、生态成熟适合快速上线按量付费。本地开源模型用Llama系列、Qwen系列等开源权重跑在自己的机器上数据安全可控但需要硬件支撑。国内大模型API对中文场景优化明显部分能力不比闭源标杆差有免费额度可以起步。混合策略先路由到本地小模型做简单任务复杂任务再调云端更强模型兼顾成本与效果。我给新手的建议是如果现有硬件条件一般第一轮从国内大模型API或云端闭源模型API入手先把工程链路跑通。跑通之后再尝试用开源模型在本地做同样的事情这时候对比效果与延迟你能直观地看到不同模型之间的差异理解“为什么某些任务需要更强模型兜底”。这种通过对比建立的判断力比单纯看排行榜有用得多。3. 手把手搭你的第一个AI工程小项目3.1 项目定义做一个本地知识问答助手为了让大家对上面提到的方法有一个具体的落点我拿出一个真实跑通过的小项目来做示范做一个针对自己文档库的知识问答助手。这个项目非常适合“from scratch”入门需求清晰、闭环短、后续扩展空间大。项目目标很直接你把一批PDF或Markdown文档丢进一个文件夹程序把文档内容切分成小段并存成向量索引之后你可以用自然语言向它提问它基于索引内容回答。这本质上就是一个简化版的RAG检索增强生成流程。拆解下来需要以下核心模块模块职责对应工程能力文档加载器读取PDF/Markdown/Word文件数据处理能力文本切分器把长文档切成适合检索的块对模型上下文窗口的理解向量化模块把文本块转换成向量熟悉Embedding模型检索模块计算查询与文档块的相似度检索策略与相似度计算生成模块将检索结果交给大模型组织回答提示词设计能力这个架构虽然简单但它把RAG的关键环节全部覆盖了。更重要的收获是当你跑通这个项目后RAG的优化方向——比如切分策略怎么调、检索结果怎么重排、提示词怎么设计——你都有一套自己的实验basis再回头读那些技术文章就不会两眼一抹黑。3.2 提示词工程是第一步精度来源很多人在搭这个项目时急着把代码跑起来却忽略了提示词工程这个最容易出效果也最容易被低估的环节。实际上当检索模块暂时无法做到十全十美时一个好的提示词能显著弥补不足。我以前面那个知识问答助手为例展示一个比“随便问问”稳定得多的提示词模板你是一名知识库问答助手。你的任务是根据下列“参考内容”回答用户的问题。 规则 1. 如果参考内容中包含答案请直接回答并在回答末尾列出引用编号。 2. 如果参考内容中没有答案请明确说“知识库中未找到相关信息”不要编造。 3. 回答使用与用户提问相同的语言。 4. 不要输出与问题无关的背景介绍。 参考内容 {检索到的文档片段} 用户问题 {用户问题}这段提示词有几个值得注意的设计决策。第一它定义了角色让模型进入预期状态第二它给出了明确规则尤其是“不要编造”这一条对减少幻觉有直接效果第三它用占位符明确区分了动态内容和静态指令方便后面代码里做替换。这些设计不是玄学而是在跟模型反复打交道中提炼出来的“沟通协议”。温度参数是另一个影响输出的关键点。默认值通常能平衡稳定性和创造性但对于知识问答场景我习惯把温度调低到0.2以下让回答更克制。你可以在代码里直接指定比如调用时传入temperature0.2。这一点很细微但对实验结果的一致性影响很大。3.3 把模型接进来接口调用与参数调优提示词设计好后下一步就是通过代码调用模型API。我给出一个精简的调用示例使用OpenAI兼容接口风格因为目前市面上大多数国内大模型API也都提供兼容格式通用性很好。import os from openai import OpenAI # 读取环境变量中的密钥与base_url client OpenAI( api_keyos.getenv(MODEL_API_KEY), base_urlos.getenv(MODEL_BASE_URL), ) def ask_model(system_prompt: str, user_content: str, temperature: float 0.2): response client.chat.completions.create( modelos.getenv(MODEL_NAME), temperaturetemperature, messages[ {role: system, content: system_prompt}, {role: user, content: user_content}, ], max_tokens512, ) return response.choices[0].message.content这段代码把模型名、密钥、请求地址全部外部化好处是切换不同服务商时只需要改环境变量不需要动代码逻辑。在实操中我强烈建议你保存好每次请求的模型名、温度参数、返回结果哪怕手写一个简单的日志函数都行。没有这个过程后续参数调优就只能靠感觉有了日志才能用数据说话。调用成功之后建议先做一次“最小闭环验证”不接检索、不接向量库直接让模型回答一个普通问题。这样你能快速确认API链路本身没问题后续再逐步加上检索与知识库排查范围会小很多。3.4 用工作流把零散步骤串起来单次问答做好之后接下来才是体现“工程”二字的地方把加载、切分、向量化、检索、生成这几个步骤串成一个稳定的工作流。我建议用一个Python脚本做整个流程的控制而不是在每个环节都用Jupyter Notebook手点。一个可运行的简化版流程如下# 1. 加载文档 documents load_documents(./docs) # 2. 切分文本 chunks split_documents(documents, chunk_size500, overlap50) # 3. 构建向量索引 index build_index(chunks) # 4. 处理用户问题 user_query 我的文档里提到了哪些部署注意事项 results index.search(user_query, top_k4) context format_context(results) # 5. 调用大模型生成回答 answer ask_model(context, user_query) print(answer)这个流程看起来直接但每一行都有可以深入优化的空间。比如切分时chunk_size500是经验值应该根据你文档的实际情况调整——代码文档和散文类文档的最优粒度完全不同比如检索返回的top_k不是越大越好上下文太长反而会把关键信息淹没。跑通这个流程之后你就有了一张“实验台”后续每优化一个环节都能通过对比回答质量来验证效果。4. 自学路线怎么安排才不跑偏4.1 顺序比内容更重要先提示词再Agent再微调很多自学AI工程的人问题不是不够努力而是学习的顺序不对。常见的一个坑是刚学会API调用没两周就去研究大模型微调才了解Agent概念就准备自己造一个多Agent系统。不是说这些方向不能碰而是它们依赖的前置能力你还没补齐。我实践的路线是先Prompt再RAG再Agent最后再碰微调。提示词工程是地基它训练你理解模型的“沟通习惯”这个能力在你后续任何阶段都有用。RAG是实际落地最多的方向它让你理解怎么给模型补充知识、怎么设计检索链路这个阶段能积累大量工程经验。Agent是在前两步基础上的自动化延伸如果你已经知道模型在什么情况下会出错、什么时候需要外部工具再学Agent会有完全不同的体感。微调放到最后是因为它投入大、门槛高而且大部分业务问题在微调之前就已被前三个阶段解决掉不少。真正需要微调的场景通常是风格迁移、垂直术语约束、私有数据适配这些更精细的需求。4.2 复盘型学习法建立自己的实验记录自学过程中最容易被忽略的环节是复盘。我看过太多人跑通了代码就觉得自己会了结果换一个模型、换一组参数就手足无措。要打破这个局面最有效的方法是建立自己的实验记录哪怕只是一个Markdown文件也好。我通常用这个模板来记录每次实验本次实验想验证什么假设用了哪种模型参数怎么设的输入了什么示例输出是什么实际效果怎么样与预期差别哪里下一步想调整什么坚持记录的另一个好处是它逼你把“感觉”变成“语言”而表达能力在AI工程里恰恰非常重要。当你能够清楚描述“这个模型在长文本任务上的回退现象比那个模型严重”时说明你对模型行为的理解已经到了一个新的层次。4.3 新手最容易陷进去的三个坑根据我观察到的自学案例新手在AI工程自学中最容易掉进三个坑。第一个坑是“教程搬运工”。跟着别人的代码敲了一遍感觉自己会了但脱离教程后什么都不会。应对方法是每学完一个章节就把教程关掉从空文件自己重新实现一遍卡住的地方正好就是没理解的地方。第二个坑是“工具松鼠症”。收藏各种优质文章、工具清单、模型榜单但真正动手的时间和收藏时间比低得可怜。这本质上是拿“收集”的感觉替代“实践”的进展。我的建议很简单删掉一半收藏把时间留给动手。第三个坑是“一次性成功期待”。刚开始跑出来的结果如果效果不好容易产生挫败感甚至怀疑方向。AI工程本质上就是一个反复试错的领域我见过成百上千次实验第一次效果就不错的反而是少数。把预期调成“先失败再从失败里找线索”学起来会踏实很多。5. 实测过程中踩过的坑与排查心得5.1 提示词写得好不好直接影响“工程”的成败常见问题第一类集中在“词不达意”。比如你问模型“总结一下这份文档”它可能给你输出一段散文式总结而不是你想要的列表。表现形式是返回内容看起来合理但格式和内容结构完全不符合预期。排查思路很简单先在提示词里明确输出格式直接说“请用列表形式输出要点不要使用段落”效果立刻不同。更通用一点的处理方式是“规定输入/输出协议”。输入协议告诉模型你会给出什么结构的信息输出协议告诉模型期望它按什么结构反馈。这样双端约束模型的输出就不会总是千奇百怪。另一种隐蔽得多的问题是“模型自作主张”。即使参考内容里没有答案模型也会基于自己的知识强行回答。这个问题在知识问答场景特别危险解决方式就是前面展示过的“未找到相关信息就明说”指令。并且还要在代码层面做兜底校验检测到模型输出包含“未找到”等关键词时前端就展示更友好的提示。5.2 上下文管理的坑窗口长不等于容量大我遇到的另一个高发问题是对上下文窗口的误解。很多人觉得模型上下文越长塞进去的东西越多越好结果回答反而变得混乱。根源在于模型对超长上下文的注意力分散真正关键的信息可能淹没在中后段。实操中我会用两个约束来管理上下文第一控制单条内容的长度必要时先让模型做摘要再用摘要去提问第二在RAG链路中控制检索返回条数通常3到5条就够多出的内容可能反而是噪声。这里有一个很值得体验的实验在同一个问题上分别用返回3条和返回10条的方式做对比你会第一次直观感受到“信息量不等同于有效信息”。5.3 选择可靠工具与守住合规底线新手在搜解决方案时容易被各种来路不明的工具和脚本吸引。我的建议是只从官方文档和主流开源仓库获取代码不要因为某个网盘压缩包方便就去运行它。安全上坚持底线不运行来源不清楚的脚本不让API密钥进入任何公开仓库。此外使用公开模型、开源模型时要让内容符合主流价值观不把技术用在低俗、越界或可能引发争议的方向。这一点在社区里是不成文的共识守住它才能让项目走得更远。5.4 从失败日志反推系统问题当链路变长之后排错不再只是看模型输出而要从整体流程找问题。我建议把失败场景归类成三层输入层问题文档格式不对、数据加载失败、处理层问题切分异常、向量维度不匹配、输出层问题提示词约束不生效、模型返回非预期内容。一般排查顺序是从底层往上层倒查先确认数据加载没问题再确认向量检索能召回相关内容最后再判断生成段提示词的效果。这个过程非常考验耐心但每经历一次你就会对整个系统多一分掌握。我现在遇到新项目不会害怕报错反而先把“把错误搞清楚”当作第一优先级因为错误本身就是系统告诉你它工作机制的最好教材。从“AI工程”这个标题出发我聊了核心能力圈、资源选型、RAG小项目实操、自学路线和排错方法。如果你边看边动手一个周末的时间足以把那个知识问答助手从空目录搭出雏形。过程中遇到报错不要慌回到那四层漏斗里找问题出在哪一层。我个人做了大量实验后最深的体会是AI工程里最贵的不是算力而是判断力。判断力从哪来从一次次对比、一次次记录、一次次只看数据不看感觉的复盘中来。把这一步做扎实你的“from scratch”就真的值了。