从零上手AI工程：模型选型、Prompt、RAG与Agent落地全攻略

“ai-engineering-from-scratch”这个名字，乍看像一个GitHub仓库的标题，但我知道它更是一种状态的描述——收藏夹里堆满了大模型新闻、Prompt技巧、部署教程，一打开编辑器还是不知道从哪动手。AI工程这个词被说烂了，可真正从零把一个AI应用跑起来、跑稳、跑上线的人，其实没有想象中那么多。

这篇文章想把零碎的知识串成一条线：模型选型、Prompt Engineering、RAG、AI Agent、测试评估、部署上线，一环扣一环讲清楚。适合刚入行想做AI应用开发的工程师，适合想从业务开发转AI方向的全栈同学，也适合那些已经用API做过小demo但迟迟不敢推向生产的人。核心目标只有一个：让你理解AI工程的全貌，然后能照着路径亲手搭出一个能交付的系统。

1. AI工程到底在“工程”什么

1.1 先别急着跑demo

GitHub上AI类的demo项目多如牛毛，很多README截图极其炫酷，Conversation流画得天花乱坠，但真正把它丢到生产环境，往往撑不过三天。原因很简单：demo解决的是“能不能跑”，工程解决的是“能不能稳定交付、维护、迭代”。这个区别，就像你用一口锅炒出过一盘好菜，和你在后厨同时管几十道菜、保证出餐速度、控制食材损耗、应对客诉，完全是两回事。

做AI工程也一样。模型只是你的“食材”，真正值钱的部分是把食材变成稳定菜品的流程：数据怎么清洗，提示词怎么管理，Agent怎么编排，结果怎么评估，线上怎么降级，成本怎么控制。这些才是AI工程的核心。所以我特别强调一点：不要被“大模型很厉害”冲昏头脑，你要先接受“模型会出错、会抽风、会不稳定”的现实，工程的价值就是在这个不稳定的基底上搭出相对稳定的系统。

1.2 把整个系统拆成五个层次

我在实际带项目和做咨询时，习惯把AI系统拆成五层来看，这样讨论问题不会一团浆糊。

每一层都有各自的坑。模型层的问题是选型混乱，今天看到一个评测榜单就换模型，明天看到一条新闻又换，完全没有自己的评估标准；数据层的问题是文档解析得稀烂，向量检索全凭运气；智能层的问题是提示词写成“聊天话术”，Agent跑几步就迷路。这五层不是割裂的，实际上一个生产级AI应用，每一层都得有人负责。

1.3 模型选型：没有最好的模型，只有匹配的方案

模型选型是很多人最纠结的一步，但也是被浪费时间最多的一步。我给一个非常实用的判断框架：

第一看场景。通用对话、代码生成、多模态理解、文本分类，各自的优势模型不一样，直接用榜单第一不见得适合你。第二看数据安全。业务数据能不能出内网，这决定了你必须本地部署还是可以调用云API。第三看团队维护能力。选开源模型意味着你要自己处理部署、评测、更新，团队没有这个精力就别硬撑。第四看成本。同等的效果下，一个7B量化模型跑在自建GPU上，和一个旗舰大模型API按token计费，长期成本可能差一个数量级。

聊到开源模型，最近国产开源阵营确实热闹，DeepSeek公开了一些智能体训练的新方法，Qwen系列也持续迭代。这些消息对工程侧最大的价值不是让普通工程师去复现训练过程，而是告诉我们底座模型的能力在不断上探。你在选型的时候不用太执着于“最新最热”，而要看它社区活跃度、License限制、量化生态成熟度。如果一个模型连像样的量化版本都没有，部署的时候有你哭的。

2. Prompt Engineering：AI应用的第一道工序

2.1 提示词是代码，不是聊天话术

很多人写Prompt，还停留在“请帮我写一段...”这种聊天口吻。一旦AI项目进入工程化，Prompt必须当成代码来管理：要有版本、要能评审、要能回滚、要能测试。

这是个认知问题。普通用户和用户聊天，AI工程师和模型编程——你写的每一段系统提示词都是在定义模型的行为边界。我之前见过一个项目，开发阶段提示词在测聊天窗口里试得挺好，一上线就崩，因为生产环境里用户输入千奇百怪，有带攻击性的、有故意诱导越狱的、有超长文本。这时候才发现，系统提示词完全没有兜底策略，模型被用户牵着鼻子走。

所以所有正经的AI工程，都应该把提示词纳入代码仓库。你完全可以把每个版本的提示词单独建文件，标注修改日期、改动原因、评测结果。这能帮你后期快速定位“上次还正常，怎么这周就不对劲”的问题——多半就是模型底座升级或者提示词被悄悄改过。

2.2 结构化系统提示词怎么写

一段完整的系统提示词，至少要包含这几个部分：角色定义、任务目标、输入信息、输出格式、约束条件、兜底策略。

• 角色定义：告诉模型它是什么，比如“你是一个客服助手，只处理订单相关问题”。
• 任务目标：明确它要完成什么，比如“根据用户问题，从知识库中查找答案”。
• 输入信息：说清楚输入里有什么，比如“用户消息、检索到的参考资料”。
• 输出格式：给出模板，比如“先给结论，再列出参考依据”。
• 约束条件：告诉它不能做什么，比如“不要编造不存在的政策”。
• 兜底策略：当信息不足时怎么办，比如“如果参考材料中没有答案，明确回复‘当前知识范围无法回答’”。

这里特别要强调：结构化不是让你把提示词写得生硬，而是让关键信息在长文本里更容易被模型注意到。原理很简单，大模型的注意力机制对清晰的任务描述、明显的边界信号更敏感。你用“你是一个订单助手，下面是你的工作原则：1... 2... 3...”这种编号结构，指令遵从度就是比“你帮我看看这个订单怎么回事”高。

2.3 上下文管理和工具调用的边界

大模型不是记忆力越好越强，上下文窗口再大也是有限资源，而且超过一定长度后模型会“迷失在中间”：开头和结尾的内容它记得很清楚，中间段落常常被忽略。这就是为什么AI工程里一定要做上下文管理。

我的经验是，把信息分成三层：第一层是系统提示词，放长期稳定的行为规则，不占对话历史的配额；第二层是检索到的相关知识，每次请求动态塞入，控制长度；第三层是对话历史，这里最需要注意，超过一定轮数就要做摘要压缩，不能让对话无限膨胀。

工具调用则是Prompt层面另一个关键设计。意思是你给模型提供几个函数，每个函数配一份JSON Schema格式的“使用说明书”，模型根据用户请求决定要不要调用、传入什么参数。这解决了“模型缺乏实时数据”的痛点。设计工具说明时有两个坑：一个是描述写得太模糊，模型不知道该什么时候用它；另一个是工具太多，模型反而选择困难。原则上，工具数量能少则少，描述里写清楚“什么时候用、什么时候不用”，比堆一百个工具效果更好。

2.4 Prompt也要像代码一样做回归测试

提示词是AI应用里最脆弱、也最容易被忽略的瓶颈。改了系统提示词里一句话，可能整个输出风格都变了。所以从第一次写Prompt开始，就要配一个小的评测集。

评测集不用很大，先弄几十条典型的输入输出对。每次改Prompt，就自动跑一遍评测集，看看准确率、格式合规率、拒答率有没有变化。后面我会单独讲评测系统，但在Prompt阶段你要先有这个意识：任何一处提示词的修改，都是一次代码变更，必须带着证据上线。我碰到过很多团队，上线后效果崩了，复盘发现是有人“顺手”在系统提示词里加了一句讨好用户的话，结果模型变得只会拍马屁不会干活。这类事故，靠Review约定完全可以避免。

3. AI Agent：让模型从“回答”变成“干活”

3.1 Agent的本质是循环，不是玄学

AI Agent是当前最热的概念，但很多人的理解是错的。Agent不是天上掉下来的神秘智能体，它的核心是一个循环：推理下一步做什么，调用某个工具，观察工具返回结果，再决定下一步。这套机制有一个经典名字叫ReAct循环，理解它，你就理解了Agent的骨架。

我用一个类比解释。你给一个实习生布置任务：“去统计这个月的订单数，但数据库密码在运维那里，你去要一下。”如果这个实习生只会背标准答案，他肯定卡死。但一个会干活的实习生会这样：先分析任务，发现需要数据库权限，去找运维拿密码，拿到后执行查询，发现格式不对，再调整SQL，最后把结果整理交给你。Agent做的就是这个过程，只不过把“分析、行动、观察”变成了模型的循环推理。

这个循环执行得顺不顺，差别在于你有没有给它足够好的“眼睛”和“手”。眼睛是读到的信息，手是能调用的工具。很多Agent项目死在第三轮循环，原因就是上下文里塞满了无用信息，模型在前面几轮推理里已经把自己绕晕了。

3.2 工具注册与Function Calling的工程细节

Function Calling是Agent落地最关键的工程点。逻辑听起来简单：模型不直接执行代码，它只负责决定“该调用哪个工具”和“传什么参数”，真正执行由你的程序来做。但工程细节非常多。

第一，工具定义里的description要面向模型的“意图理解”，而不是面向人。比如你写一个查天气的工具，描述不要写“接收城市名返回温度”，而要写“当用户询问某个城市当前或未来天气时使用，其他情况不要使用”。这样能显著提升工具调用的准确率。第二，工具执行的结果要整理好再塞回上下文，不要直接把原始报错丢给模型。第三，工具会失败、超时、返回空结果，你必须设计好失败分支，要么让模型换一个工具，要么明确告诉用户失败了，不能卡死在那里做无效循环。

我建议所有刚开始做Agent的团队，先写一个手工编排的伪Agent，把所有分支都跑通了，再上框架。直接套LangChain的AgentExecutor，看起来快，出了问题你根本不知道循环内部发生了什么。

3.3 记忆系统：别让Agent“失忆”

Agent一旦进入持续对话场景，记忆问题立刻出现。模型本身是无状态的，每次请求都是独立的，你需要主动为它搭建记忆系统。

记忆分三层。第一层是短期记忆，就是当前对话窗口的历史消息。这层需要做长度控制，超长时用摘要压缩，保留关键事实而不是逐字保存。第二层是长期记忆，通常存在向量数据库里，比如用户之前聊过的偏好、历史任务记录，需要时检索出相关内容放回上下文。第三层是结构化记忆，用表格来存，比如用户ID、当前任务状态、待确认参数，这类信息不适合放向量库，直接查记录更可靠。

很多Agent“做不下去”，不是因为模型不够聪明，而是因为它不记得上下文，用户说了三分钟后又重复问同一个信息。这种体验非常糟糕。所以设计记忆系统时，先列一个问题：“哪些信息需要跨对话保持”，再决定用什么存储，不要一上来就搞复杂的向量记忆框架。

3.4 多智能体编排的坑

多智能体协作现在很火，宣传上是“多个模型像公司一样分工合作”，但工程上它带来的复杂度是指数级上升的。我见过不少项目，业务完全不需要多Agent，但架构非要拆成“规划Agent、执行Agent、审查Agent”，结果每一层都在转述消息，上下文膨胀严重，最后模型互相甩锅，输出质量还不如单个Agent。

什么时候真正需要多智能体？当一个任务可以被清晰拆成几个独立角色，且每个角色需要的上下文高度隔离时，多智能体才有收益。比如一个写代码的Agent和一个做代码审查的Agent，两者看到的上下文不同，合并在一起会造成灾难。另一个经验是，多智能体之间传递的每一轮消息都会消耗Token，你要对通信成本有心理预期。我做过一个四Agent协作的实验，一次任务下来Token消耗比单Agent高5倍，效果提升却不明显。所以我的态度是：能用单Agent解决的，绝不拆多Agent；真要拆，先画清楚谁和谁交互、传什么消息、失败怎么兜底。

4. 工程化三件套：数据、RAG与微调

4.1 高质量数据是唯一的燃料

不管你是不是要微调模型，数据都是AI工程绕不开的环节。RAG要数据检索，评测要数据积累，Agent要数据反馈。很多项目死在“模型选对了、链路搭好了，但业务知识是空的”。

数据工程在这里主要指：把散落在PDF、Word、网页、数据库里的业务知识，整理成模型能有效利用的形式。第一步是清洗，去掉页眉页脚、重复段落、乱码字符；第二步是结构化，给文档打标签、分章节；第三步才是分块和向量化。这些活不性感，但没有它们，后面所有环节都是空中楼阁。

我还见过一个高频错误：直接把几千页的PDF全塞给模型，以为上下文窗口大就够了。结果模型在长文本里挑挑拣拣，回答得又慢又容易漏关键点。正确的思路永远是“先检索再作答”，而不是“全量喂入”。

4.2 RAG和微调，别搞反了

很多刚入行的人一听到“模型不够聪明”就想去微调，一微调就上GPU，一上GPU就烧钱，最后效果还不一定好。实际上大部分场景，RAG才是优先级更高的方案。

我梳理过两者的适用边界：

简单说，RAG是让模型“查资料”，微调是让模型“改习惯”。大多数项目一开始只要“查好资料”就够了，微调等产品形态稳定了再考虑。另外，微调无法解决“知识时效性”问题，模型微调完，知识又过时了，你还得重训，这个周期长到难以忍受。

4.3 RAG流水线实操

RAG其实是一套流水线，每一个环节都有可以优化的地方。我按顺序讲一份可直接复用的实操方案。

第一步是文档解析。PDF、Office文档别用普通解析库硬啃，试试把文档转成文本后人工抽查十页，确认没有乱码和截断。这一步决定了后面检索的天花板。

第二步是分块。经验值给你作参考：通用文本用512到1024个Token左右的分块大小，分块之间保留64到128个Token的重叠。分块太小，语义被切碎；分块太大，一个块里塞了太多主题，检索噪声变大。没有绝对最优，你需要在自己的数据上做实验。

第三步是嵌入向量化。中文场景可以优先考虑开源的BGE系列或商用Embedding接口，选型标准是“在你的业务问题集上检索准确率高”，而不是榜单数字好看。

第四步是向量存储。轻量场景直接用pgvector或SQLite向量插件就行，先跑通再上Milvus这类专业库。很多业务远没到需要重引擎的量级。

第五步是检索。TopK一般从3到10之间调，太少了容易漏，太多了噪声多。如果你发现检索出来的片段牛头不对马嘴，优先排查切分和Embedding，而不是调大TopK。

第六步是重排（Rerank）。这是一个很容易被忽略但性价比很高的环节。检索召回几十条候选后，用重排序模型精排一次，只取前几段进上下文，回答质量会有明显提升。

最后是引注设计。所有回答都应该给出来源片段，这一是让用户能自查，二是方便你定位“模型答错是因为没检索到，还是检索到了不会用”。

4.4 微调的真实现场

如果你确实走到了要微调这一步，我提醒三件事。第一，微调需要的数据格式必须是“指令-回答”成对的结构，靠凭空想象生成训练集是不行的，优先从真实业务日志里整理输入和期望输出。第二，效果验证要用留出集，不能在训练数据里自测。第三，微调后的模型一定要和底模做对比测试“回退检查”，防止微调把模型原有的通用能力毁了——很多做垂直微调的团队都栽在这上面，专业术语是懂了一些，常识却变得一塌糊涂。

5. 测试、评测与上线部署

5.1 AI应用不能只测代码，还要测模型行为

传统开发里，我们写单测、做集成测试，断言函数的返回值。但AI应用不一样：同一个输入，模型两次回答可能不一样；输入稍微换个说法，回答就可能塌方。所以AI工程的测试要覆盖两层：一层是代码逻辑测试，另一层是模型行为评测。

我建议你尽早建立“评测集机制”：收集真实的用户问题，可以是几百条，给每条标注期望的回答要点或评分标准。每次系统改动，就在评测集上跑一遍，用规则或者模型打分，观察准确率、拒答率、格式合规率的变化。没有这个机制，你做任何优化都是靠感觉，上线后出问题也不知道是哪次改动导致的。

这里顺便提一句现在热门的“AI测试开发”方向，本质上就是用大模型来辅助生成测试用例、构造对抗样本。效率提升确实明显，但你要留个心眼：大模型写的测试用例不一定覆盖到业务的关键路径，人工抽检评判仍然不可少。

5.2 评测方法：规则、人评与LLM as Judge

评测AI输出的方法大致有三类。第一类是规则评测，适合可以程序化校验的场景，比如“是否包含指定字段”“JSON格式是否合法”，速度快且稳定。第二类是人工抽检，适合开放式的最终效果判断，比如对话体验、文案质量，人力成本高但最可信。第三类是LLM as Judge，让一个大模型当裁判打分，适合中等规模批量评测，但存在位置偏差、自夸偏差等问题，需要你通过设计评分标准、多次取样、用已知答案校正来缓解。

从成本和质量平衡来说，我建议采用“规则 + 样本级LLM评测 + 周级人工抽检”三层组合。全部靠人工，迭代速度太慢；全部靠模型裁判，容易镜面效应——裁判和自己用了同一个底模，错也错得一模一样。

5.3 本地部署与推理优化

什么时候需要本地部署？数据不出内网是硬性要求、或按Token计费的API成本已经高到无法接受、或者你需要在离线环境跑Agent流程。这些场景下，你就要面对推理优化。

工具选型你直接按场景来。个人开发验证，用Ollama最省心，一条命令拉起一个模型服务。生产环境高并发，vLLM是主流选择，支持PagedAttention，吞吐量高很多。边缘设备或嵌入式环境，llama.cpp很有用。

量化是成本与效果的权衡艺术。Q4_K_M这种4比特量化，在多数场景下和半精度模型的差距很小，模型体积却能缩小约75%。我见过有人为了极致省内存上2比特量化，结果模型开始胡言乱语，业务不可用，省下的钱全赔在调试时间上，完全不划算。一般从Q4或Q5开始尝试，别一上来就追最小体积。

部署层面还有一个高频坑：并发提高时首Token延迟飙升。这个和生产环境的排队策略、KV Cache预留都有关系，不能只看远程benchmark，一定要在你自己的业务负载下压测。

5.4 可观测性与成本控制

AI系统上线后，最怕变成黑盒。你必须记录每一次请求的模型版本、Token消耗、响应延迟、调用了哪些工具、用户最终是否满意。这些日志不仅用于排查问题，更是调优的依据。我给自己的项目定了一个规矩：没有日志的功能不允许上线。

成本控制方面有两个实用技巧。一个是模型路由：简单问题让小型模型处理，复杂问题才上大模型，用一个判单模型或分类器做分发。另一个是结果缓存：相同或相似的请求在短时间内直接返回缓存结果，能省掉大量重复消费。团队规模不大的时候，先抓这两条，比盲目上各种花哨优化都管用。

6. 从入门到能打：路线图与常见坑

6.1 30天从零到落地路线

如果你是真想开始，我给你一条我自己验证过的30天路线。

第一周：搭环境，把API调用跑通。用Python或你熟悉的语言，调用一个云端大模型API，实现基础的对话和流式输出。这期间可以做点小实验，比如用不同Prompt让模型扮演不同角色，感受指令遵从的变化。IDE里装上AI编程插件，比如PyCharm的AI助手，让插件帮你写胶水代码，把精力留给真正的逻辑。

第二周：做一个RAG知识库问答。选一个你熟悉的文档集，比如产品手册，跑完整的解析、分块、向量化、检索生成链路。把评测集建起来，每天记录准确率的变化。

第三周：做Agent。选一个需要多步骤的任务，比如“根据订单文件生成周报”，让Agent学习调用工具、处理失败、整理结果。这周的重点不是炫技，而是把循环逻辑吃透。

第四周：部署上线。用本地推理或云API，把应用部署出来做压测，记录并发、延迟、成本数据，然后做一轮优化迭代。一个月跑下来，你对AI工程的认知会比看三百条资讯都深。

6.2 常见问题排查速查表

这些坑我几乎都在真实项目里踩过。尤其是“上下文窗口超限”，很多开发者第一反应是换更大窗口的模型，完全没想过自己做摘要压缩。换到百万级上下文的模型后，延迟和成本同时爆炸，问题依然没有根治。

6.3 别只盯着聊天机器人

最后想提醒一点：AI工程的机会远不止“聊天网页版”。我最近观察到不少行业软件都在悄悄做AI化改造，比如立创EDA这类专业设计工具也开始集成AI助手，这说明AI工程正在渗透到每一个垂直工具里。如果你只会在通用聊天窗口里调Prompt，其实还停留在用户层面；真正把你和普通用户区分开的，是你能否把AI能力嵌到一个具体的工作流里——自动生成工程文档、辅助测试用例生成、在IDE里做代码审查辅助，这些都是AI工程的用武之地。

掌握“从零构建”的内功后，你会发现所谓的新概念，本质上都还是我前面讲的那五层系统在不同场景下的组合而已。懂得这些，无论热点怎么变，你都能很快拆解它的工程实现路径。