企业官网建设流程全解析

从零开始做AI工程，这个仓库我整理了快两年，中间推倒重来了三次，终于敢说它真的“能打”了。如果你点进来是因为标题里那句“from scratch”，那你应该和我当初一样，受够了那些只会教你怎么 import 一个库、调一个现成接口的教程。市面上讲AI的课程多如牛毛，但能真正告诉你“一个AI系统从立项到上线，每一步该怎么做、为什么这么做、踩了坑怎么爬出来”的内容，少得可怜。这篇文章就是围绕我搭建这个名为“ai-engineering-from-scratch”的完整知识体系展开的，我会把它拆开揉碎，把我踩过的坑、验证过的方案、以及最终沉淀下来的那套工程方法论，全部摆到台面上。

写这个项目的初衷很简单：我想给“AI工程师”这个岗位画一张不那么悬浮的能力地图。2025年了，AI早就不是实验室里发论文的专利，它变成了业务系统里一个需要稳定运行、可评估、可迭代的模块。但市面上大多数人的认知还停留在“会调大模型API就能做AI应用”，或者“会训练模型就懂AI工程”，这两种极端我都见过，也都被坑过。真正的AI工程，是数据和模型之间的黏合剂，是评估和交付之间的桥梁，是从一个粗糙的想法到一套稳定系统的全过程管理。

这篇文章适合谁？适合那些刚入门、想系统构建AI工程能力的开发者；适合已经在做AI应用、但总感觉在“调包”和“拼凑”之间反复横跳的从业者；也适合团队里负责技术选型和项目落地的同学，你们需要一套能说服自己、也能说服业务的完整逻辑。我尽量把话说得直白，所有技术和术语都会解释清楚，但不会为了照顾小白而牺牲深度，因为工程本身就是一门关于取舍和细节的学问。

1. 内容整体设计与思路拆解

先搞清楚一个核心问题：当我们说“从零开始做AI工程”，这个“零”到底是什么？不是零基础，不是说你连Python都不会就能来搞AI，那叫从零学编程。我这里的“from scratch”，指的是抛弃那些“开箱即用”的黑盒方案，从AI系统最底层的逻辑开始，重新理解每一个环节为什么存在、为什么被设计成这样。

1.1 核心需求解析：两种工程师的认知断层

我在实际带团队和做技术咨询时，发现一个特别普遍的现象：算法工程师和业务开发之间存在一条巨大的鸿沟。算法工程师关注的是模型指标，比如BLEU、ROUGE、F1、准确率，他们觉得模型在测试集上分数涨了就是成功。但业务方关心的是用户体验、成本、响应延迟、稳定性，他们根本不在乎你用的什么模型架构。而传统的后端开发呢，他们熟悉高并发、缓存、数据库索引，但一碰到“模型返回的内容是概率性的、每次都不一样”就抓狂，觉得这玩意儿没法做工程。

这个鸿沟，恰好就是“AI工程”这个学科要填的东西。我整理这个项目时，第一件事就是把这套认知断层可视化。整个仓库的目录结构就是按这个逻辑来的：先从问题定义和数据出发，然后到建模和评估，再到部署和运维，最后是反馈和迭代闭环。这不是我拍脑袋想的，是我被现实毒打之后总结出来的。早期我做的第一个所谓“AI项目”特别天真，拿到数据就直接丢进模型训练，训练完看loss降了就欢天喜地，结果上线第一周就被业务方骂了四次——不是模型不work，而是我压根没有定义清楚“什么叫做work”。

所以这个项目的第一个大章节，是帮助读者建立一个完整的AI工程思维框架，而不是急着写代码。我见过太多人一上来就抱着Transformer论文啃，啃完发现连数据清洗都不会，这完全本末倒置了。真正的从零开始，是先从系统视角来看问题：你要解决什么业务问题？这个问题的输入输出边界在哪？用什么指标来衡量做得好不好？数据从哪里来、质量如何？这些问题想不清楚，后面每一步都是空中楼阁。

1.2 方案选型背后的逻辑：为什么拒绝“拿来主义”

这个项目里我刻意避免了一件事：直接告诉你“用LangChain吧”或者“用LangGraph吧”。不是说这些工具不好，而是它们对新手来说是个巨大的陷阱。我自己早期就掉进过这个坑，用LangChain搭RAG应用，半小时就能跑通，但出了错根本不知道是哪里出了问题。链子断了、上下文丢了、召回不准、生成幻觉，你只能一层层扒源码，最后发现是某个封装太黑箱导致的。

我后来想明白了一件事：框架是别人对通用场景的抽象总结，但你的业务永远有特殊性。如果你不理解底层的逻辑，一旦情况超出框架预设范围，你就寸步难行。所以这个项目里，我坚持“用最小实现讲透原理，再引你去看工业级方案”。比如讲RAG，我会先带你用一百行左右的代码把一个最简的检索增强生成链路写出来，让你亲眼看到Embedding是干什么的、向量检索是怎么算相似度的、上下文是怎么拼接给模型的，然后再告诉你，理解了这些之后，你去看LangChain源码就能看懂它在每一层帮你做了什么。

这种从原理到工具、从手动到自动的路径，看起来很笨，但却是最扎实的。我带的几个实习生，按这个路径走下来，基本三周之后就能独立排查RAG系统的各种诡异问题，因为他们知道每条数据在系统里是怎么流动的。而对比那些直接上手LangChain的同学，遇到问题只能靠猜，靠改参数试，这是完全不同的成长曲线。

1.3 影响范围分析：AI工程在2025年的应用全貌

这套工程能力到底能用在哪些场景？我整理项目时做了一个横向梳理，至少覆盖了下面这些主战场：

• 知识库问答与RAG系统：这是目前落地最广的方向，企业内部的文档检索、客服自动问答、法律条文辅助检索，都属于这个范畴，核心难点在召回准确率和引用的可追溯性。
• 自动化内容生产：包括营销文案批量生成、周报总结、会议纪要整理、多语言翻译分发，核心难点在风格一致性和事实准确性控制。
• 数据分析与决策辅助：让大模型直接查数据库、生成分析报告、做异常检测归因，这里要解决的是模型和结构化数据之间的连接问题。
• 智能体工作流（Agent）：把模型从“回答问题”升级成“执行任务”，比如自动处理工单、自动排期、自动写代码修bug，这一块目前还在快速演进，但工程框架已经基本成型了。
• 行业垂直模型微调：在通用模型基础上用领域数据做继续训练，比如医疗、金融、法律用语适配，这里涉及数据合规、评测体系、灾难性遗忘等一系列工程问题。

不同应用场景的技术侧重点差异很大，但底层的工程骨架是共通的。这也是我把仓库设计成“主线+分支”结构的原因，主线讲通用工程链路，分支按场景展开专项案例。后面几章我会详细拆解这条通用链路里最重要的几个环节，给你一套拿来就能用的实操路径。

2. 核心技术解析：大模型应用开发的4个关键层级

进入技术细节之前，我想先打破一个误区：做AI工程，不等于写模型。2025年的今天，绝大多数业务场景根本不需要你从零预训练一个大模型，成本和数据的门槛都不是小团队能承受的。你需要的是“模型应用工程化”的能力，也就是把已经存在的强大模型，通过一系列工程手段接入你的业务系统。

2.1 模型接入层：API调用之上的工程考量

现在主流的模型接入方式有几种：直接调用商业API、部署开源模型、或者两者结合的混合架构。很多刚入门的同学选了最省事的商业API，以为就是把key填进去发个请求这么简单，但真正的工程问题全在“请求”之外。

首先是延迟和成本建模。大模型推理是出了名的慢和贵，一个中等复杂度的对话请求生成500个token，在标准配置下可能要花3到10秒，调用成本一次从几厘钱到几分钱不等。如果你的系统要服务一万个用户，高峰期并发一上来，延迟会指数级恶化。我在项目里专门放了一套压测脚本，自己搭过环境应该知道，不压测你永远不知道系统到底能扛多少流量。

其次是上下文管理策略。大模型的上下文窗口是宝贵的资源，尤其在做RAG或者Agent的时候，你不能把所有历史对话和检索到的文档全都一股脑塞进去。这里涉及截断、压缩、摘要递归等一堆策略，每一项都要结合你的业务场景去调。

再者是错误处理与降级方案。模型接口会超时、会限流、会返回异常格式，这种种概率问题在工程上必须有一套优雅的处理机制。我在生产环境里遇到过一次特别典型的故障，大模型供应商临时上线了一个新版本，行为产生了微小的偏移，导致我们系统的输出格式解析大面积失败。这种事情防不胜防，所以你的接入层必须有格式校验、失败重试、以及人工介入的兜底通道。

2.2 模型选择层：基座选型的评估矩阵

不少新人喜欢追新，哪个模型一发布就立刻换上去，这是大忌。模型选型应该是一个工程决策，不是追星行为。我在项目里整理了一套多维度的模型评估矩阵，你选任何基座模型时，都要把你关心的指标量化和加权：

我一般会给团队一个模板化的评估流程：先根据业务场景构造一批有代表性的测试样本，再让候选模型在这些样本上跑一轮盲测，统计分析出各家表现。这个流程听起来麻烦，但真能帮你省下后面所有迭代的坑，因为你才掌握自己业务的第一手情报，而不是全依赖于别人的榜单。

2.3 数据工程层：AI系统最容易被低估的地基

数据的重要性我再怎么强调都不为过。很多做AI应用的人，居然没有一套正式的数据收集和管理的流程，样本散落在各个聊天记录里，测试集完全没有标注标准，这种项目做出来的系统，上线翻车是必然的。

我自己的经验是，数据工程至少要做三件事：数据采集、数据清洗、数据标注。数据采集要解决“数据从哪来”的问题，你得理解业务场景中哪些是真实用户的真实请求，这些请求会以什么形态出现在系统里。数据清洗则要解决“数据能不能用”的问题，去重、去噪、格式标准化、敏感信息脱敏，每一步都要有明确的规则。数据标注则是决定“数据质量上限”的关卡，你到底期望模型输出什么答案，这个标准非定清楚不可。

很多团队觉得标注就是活多人傻的体力活，其实不然，标注标准的制定是最高级的工作之一。我在项目里专门讲了如何设计一套高质量的标注规范，包括怎么定义样本难度、怎么处理边界情况、怎么做标注一致性检验。说实话，一个标注标准写得好的团队，后面做评测和微调都会顺很多，因为系统评价的标杆立住了。

2.4 评测层：比“感觉还行”靠谱一万倍的体系化评估

评测可能是整个AI工程里最不受重视但最致命的一环。80%的团队跑通demo之后就直接上线了，然后靠着用户反馈来“盲人摸象”式迭代。用户说结果不对，运营转给开发，开发改个prompt试试，运营拿去测，又不行……这个循环效率极低。

好的评测体系应该像一把尺子，保证你的每次改动都能被度量。在项目里我把评测拆成两个层面：离线评测和在线评测。离线评测发生在系统上线前，你在固定的测试集上跑一套标准化的打分逻辑，比如RAG场景的召回率、生成场景的事实一致性、分类场景的准确率。在线评测则是在线上运行时的监控指标，比如用户点赞率、采纳率、反馈提交率，这些虽然延迟高但最真实。

这里我要特别强调一个新手常犯的错误：建了一个包含大量简单样本的测试集，导致评测分数虚高，上线后遇到了稍微复杂一点的用户请求就崩。所以构建测试集时，难度分布要尽可能贴合真实场景，甚至要有意加入一些“刁钻”的样本，测试系统边界到底在哪。

3. 实操过程与核心环节实现：从零到一搭建一个RAG知识库问答系统

前面讲了那么多框架和原理，这一章我用一个具体的案例带你完整走一遍流程。我选的是最经典、应用最广的RAG（检索增强生成）场景，目标是从零搭建一个企业内部知识库问答机器人。这个案例能覆盖AI工程的大多数核心环节，而且需求明确、效果可感知。

3.1 阶段一：问题定义与基准线建立

老规矩，动手写代码之前先想清楚问题和评价标准。假设场景是给公司做一个内部IT支持问答机器人，帮员工解答关于请假流程、报销规范、软件使用等日常问题。

第一步，列出系统的输入输出定义：输入是员工用自然语言提问，输出是准确且引用文档来源的文字答案。这里有两个关键点需要提前定义：一个问题是“什么算正确答案”，标准是答案必须能从知识库文档中找到对应原文作为支撑，不能是模型自己编造的；另一个是“覆盖哪些问题范围”，初期只支持IT和行政事务，超出范围要礼貌地告知无法回答。

基于这些定义，我要准备一份初始测试集。我手动收集了大约100个常见问题，覆盖各个子领域，并把每个问题按难度分了三级：简单（可直接从一段话找到答案）、中等（需要跨段落拼接信息）、困难（包含复杂条件判断）。这份测试集在后续所有迭代中都会作为核心评测基准，先建立baseline是防止后面迭代时失去方向。

3.2 阶段二：数据准备与文档切片

知识库问答系统的地基，是你要喂给系统的文档本身。我见过很多人图省事，把几千字的PDF整本扔进去，效果自然很差。大模型的上下文窗口虽然越来越大，但“窗口放得下”和“能准确理解”完全是两回事，太长且混杂的文本会淹没关键信息。

数据准备阶段核心操作就是文档解析和切片。文档解析，我建议先用成熟的解析库做预处理，将PDF、Word、Markdown等各种格式统一转成纯文本，注意表格的处理，不能简单粗暴地丢掉结构。切片策略就有讲究了，纯按固定长度切片会产生大量语义不完整的片段。我用的方案是结构优先混合切片：优先按文档的段落标题、列表项、表格行等结构边界切片；如果某个结构块过长，再按一个带重叠窗口的长度阈值二次切分，这样既保证了语义完整性，又能控制每段的长度。

切片做完了不要急着去embedding，先人工随机抽取几十个切片读一遍，检查有没有乱码、重复、语义错乱的问题。这一步花不了多少时间，但能保住你下游所有流程的质量。

3.3 阶段三：向量化与检索链路的搭建

现在的RAG系统大多采用“向量检索+关键词检索”混合召回的方式，我来拆解一下原因以及具体实现。向量检索擅长处理语义相近的查找，比如用户问“年假怎么休”，文档里写的是“带薪休假制度”，两者没有字面重叠但语义相关；关键词检索适合精确命中的场景，比如员工工号、特定系统名称等。两者结合，效果比单用任何一个都好很多。

向量化我用的是开源的Embedding模型，比如BGE系列或者最新的混合检索模型，具体选型要实测对比。基本流程就是先把上一步切好的文档切片全部灌入模型，生成对应的向量，存入向量数据库。向量数据库我推荐先从小型可自托管的方案上手，把核心概念跑通，理解什么是索引、什么是相似度计算，后面再根据数据规模决定是否引入分布式方案。

检索链路方面，我给出一套精简但完整的逻辑：先用向量检索取每个问题最相关的前K个切片，K值预设为8到12之间；再做一次基于关键词的BM25检索，同样取前K个；把两路结果合并去重，按融合分数排序，取最终Top-N，这里N我一般设5到8。之所以不直接用检索列表的全部结果，是为了控制拼接进上下文的内容长度。最后把这些Top-N个切片按顺序拼接到prompt里，同时附上格式化的引用来源，让模型在生成答案时可以指出来源。

3.4 阶段四：提示词工程与可控输出设计

很多人以为提示词工程就是写一段“你是XXX专家”之类的角色设定，这个理解太浅了。真正的提示词工程，是把系统行为约束和输出格式约束都塞进一段结构化的文本里。我在实际项目中用到的提示词模板至少包含以下要素：角色与目标、输入知识库内容标识、回答的行为准则、处理“不知道”情况的策略，以及强制输出格式的JSON Schema说明。

这里分享一个我亲测有效的经验：对输出格式的控制，不要只写在prompt里让模型“自觉遵守”，一定要在代码侧做双重校验。比如我要求模型返回一个包含answer和sources两个字段的JSON，哪怕prompt写得很清楚，模型偶尔还是会输出Markdown格式的代码块包裹、或者多了逗号导致JSON解析失败。所以我的做法是解析层尽可能宽容，能修复轻微格式错误就自动修复，修复不了就把这次请求标记为“格式异常”，触发重试或者转人工兜底。

行为准则的设定也很有讲究，至少要包含三条：第一，答案必须基于提供的知识库片段，不得引入片段之外的无关知识；第二，如果知识库中没有相关信息，要明确说明“当前知识库暂无此问题的答案”；第三，对于涉及操作步骤的问题，按步骤拆解输出，并在每步末尾标注引用来源编号。这些规则听起来简单，但能大幅减少模型的幻觉程度，让系统行为变得有边界。

3.5 阶段五：离线评测与调优闭环

系统能跑起来之后，真正的工程重头戏才开始——评测和调优。我带团队时最常说的话就是：demo是给人看的，评测是给系统看的。没有评测，你永远不知道一次改动是变好了还是变坏了。

我用的离线评测流程是这样的：先对初始测试集里的100个问题逐条跑一遍系统的完整链路，收集答案、引用来源、响应耗时、解析状态。然后根据事先定义好的评分标准来逐条打分。RAG场景的评分标准我一般分三部分：答案准确率，人工判断回答是否准确解决了问题；引用正确率，检查模型指出的引用来源是否真的支撑了答案；格式合法率，检查输出格式是否完全符合约定结构。

第一轮跑完，几乎肯定会发现一批bad case。我通常会把bad case归成几类：检索失败（相关片段没被召回）、生成错误（召回对了但答案不对）、格式异常（模型没按规定输出）。每一类问题的解法都不一样。检索失败，要调切片策略、调Embedding模型或者增加关键词检索权重；生成错误，要优化提示词、调整拼接的上下文排序；格式异常，要加解析后置校验和修复逻辑。改完之后，重新跑一遍完整测试集，确保修复旧问题的同时没有引入新问题。这种“bad case驱动”的迭代模式，是我认为效率最高的调优方法。

3.6 阶段六：部署上线与性能压测

评测通过后，就该考虑怎么让它稳定跑在生产环境了。很多开发者在本地跑demo挺开心，一上生产环境就原形毕露，因为在本地没人跟你抢资源，网络延迟可以忽略不计。真的部署要考虑的事情非常多。

我来说说部署架构里的几个关键决策。如果用的是商业API，那么你的部署重点在于请求转发层，需要设计好缓存、超时、重试、降级的逻辑；如果用的是开源模型自托管，那要关注推理服务框架的选择，典型的如vLLM、SGLang等，这些框架对高并发推理的支持远好于裸的Transformers库读入模型直接推理。

缓存是一个经常被忽视的性价比神器。很多知识库问答场景中，用户的问题是高度重复的，比如“怎么修改密码”“报销单怎么填”这种，每周被问几十上百次。如果你在系统里加一层基于语义相似度的缓存层，把问过的问题和对应答案存下来，后续重复或高度相似的问题直接命中缓存返回，不仅能大幅降低推理成本，还能把响应时间缩到毫秒级。我在实际项目里靠这个缓存，让一个日活几千人的内部系统，大模型API调用费用直接降了七成左右。

性能压测也不能省。我自己写的压测脚本会模拟不同并发数下的请求，记录P50、P95和P99延迟，看系统在什么压力下开始变慢。压测还有一个目的：测出系统在负载下的错误率。如果每秒并发只有5个就出现大量超时和解析失败，那说明架构设计有问题，不能在线上用。

4. 常见问题与排查技巧实录

这部分我整理了在长年实战中遇到频率最高的几个问题，每一条都是真实踩过坑之后总结出来的解决方案。如果你在搭自己的系统时碰到了类似问题，直接照方抓药就行，能省下大量排查时间。

4.1 检索结果一团糟：命中率低是病根

RAG系统最常见的问题，就是用户问了一个问题，检索出来的文档片段完全不相关，导致模型只能瞎编。这个问题我遇到太多次了，排查思路基本是从下往上逐层看。

先看数据源，文档本身的编码、解析、切片是否有问题。打开向量数据库，随便查几个切片内容，如果发现切片里都是乱码或者包含大量无意义的导航字符，根源在数据清洗。再看Embedding模型，你用的向量化模型对中英文混排、专业术语的处理能力如何，如果选了一个中文效果很差的模型，召回率肯定上不去。最后看检索策略，K值是不是设置得当，熔断阈值（最低相似度下限）是不是设置得太高或太低，太低会把一堆无关片段带进来，太高则会漏掉真正有用的内容。

我个人的排查顺序是：先跑一个最简单的“直接按字面关键词搜索”，如果这个都能搜到而向量检索搜不到，那多半是Embedding模型对语义理解不到位；如果关键词也搜不到，那问题多半在前面几环，切片或解析环节把关键内容切坏了。用这种二分法排查，能非常快速地缩小问题范围。

4.2 模型幻觉问题：引用了不存在的来源

这是RAG系统最伤信心的问题，模型给的答案有模有样，但引用的文档来源里根本找不到对应内容。用户信手点开引用一看，发现被引用的文档根本不是那个意思，系统信任度瞬间垮掉。

解决幻觉问题，我从两个方向同时下手。方向一是在生成端的prompt里加严格约束，比如明确要求“如果知识库中没有可用信息，只说不知道”，同时告诉模型更优的做法是在拿不准的时候少说为妙。方向二是引入事后的验证环节，把模型输出的关键信息反向映射到引用片段中去，做一个简单的基于文本重叠的核验，如果发现模型输出了大量引用片段中完全没有的内容，就把这次回答标为“低置信度”，不进入正式回复通道。

这个方法不能100%消除幻觉，但能把幻觉出现率压到可接受范围之内。我始终觉得AI系统追求的目标不是0幻觉，而是把幻觉控制在用户能感知、系统可兜底的范围内。

4.3 并发一高就延迟爆炸

很多系统在并发低的时候响应流畅，并发一上去就崩溃，这是典型的“没有做资源规划”的表现。大模型推理是计算密集型任务，如果没有把无状态服务和有状态的推理过程分开，所有请求都直接打到模型推理进程上，延迟必然会随着并发线性甚至指数级上涨。

这个问题有三板斧可以处理：第一板斧，加缓存，把重复或高相似度的请求拦在推理之前，这部分前面已经讲过了；第二板斧，对推理请求做队列化处理，设定最大并发数，进来多的任务先排队，不要让请求一窝蜂地涌向模型；第三板斧，如果用的是自托管模型，要做推理服务化部署，利用连续批处理等技术把吞吐量拉高，而不是一个请求一个请求地跑。

另外一个常见低性能点是串行调用导致的级联延迟，比如一个问答请求，你要先做向量检索，然后做关键词检索，两路完成后合并再调大模型。如果这几步是串行的，总耗时就是各部分相加。优化思路是把向量检索和关键词检索并行化，两路同时跑，等两边结果都齐了再做合并，这样总延迟就从“一加二”变成“一和二取大”，效果立竿见影。

4.4 评测指标与真实体验脱节

这个问题的隐蔽性特别强，系统离线评测分数很好看，上线后用户就是不买账。原因往往是评测指标选错了，或者测试集和线上数据分布不一致。

举一个我实际遇到的例子：某个客服问答系统，离线评测时我们主要看答案准确率，业务方也觉得不错，结果上线第一周用户平均反馈分惨淡。后来一查，发现用户反馈里有很多“回答得太啰嗦”“没有直接告诉我怎么操作”的抱怨。原来我们的评测只看“信息是否正确”，但没有把“答案是否简洁直接”作为重要评判维度。后来在评测标准里加了“步骤指令覆盖率”和“答案简洁性”指标，专门针对操作类问题做了更多测试，再优化了一版prompt，情况立刻好转。

这给了我一个很重要的教训：评测指标一定是从业务目标反推出来的，而不是从技术能力顺着做的。先想明白业务上什么行为是好的，再反推用什么指标去度量。这个顺序一旦搞错，你后面所有的调优都可能是在原地打转。

4.5 常见问题速查表

5. 项目进阶路线：从RAG到多Agent系统

如果你把上面这个RAG案例完整地跟做了一遍，你的AI工程地基可以说已经打得相当扎实了。接下来，我想给你一个进阶路线的参考。AI工程这个领域最迷人的地方在于，它永远有下一层复杂度等着你去解锁。

5.1 多Agent协作：把任务编排交给系统

单一RAG链路解决不了的问题，往往需要引入“多个不同角色的模型协同工作”。我举个例子，做一个“智能项目周报生成助手”，如果只是单纯地跑一次RAG，你得到的答案可能只是资料罗列，不够有条理。但如果你拆成三个角色的Agent：一个Agent负责从聊天记录和项目管理工具里收集所有本周事项，一个Agent负责把事项分类并补全关键信息，还有一个Agent负责梳成结构化报告并检查是否有数据遗漏，每个Agent各司其职，效果就会完全不一样。

多Agent系统的工程复杂度体现在任务编排、状态管理和消息传递上，每一个环节都需要严谨设计。在项目里我把这套拆解成了几个核心模式：流水线模式适合固定流程的任务；路由模式适合根据用户意图分发到不同专家的场景；协商模式适合多个Agent对同一个问题做交叉验证的场景。先掌握这三个模式，大部分业务需求都够用了。

5.2 微调实战：什么时候需要，什么时候千万别碰

很多人问我，什么情况下需要微调，什么情况下做个RAG就够了。我的回答很简单：先做RAG和提示词优化，把能榨干通用模型能力的空间都榨干，再思考要不要微调。

如果确实面临以下两类问题再考虑微调：一个是风格或者输出格式有极其固定的要求，通用模型怎么提示词都学不会；另一个是领域知识有大量高频的特殊表达，连RAG都很难稳定检索到。这两种情况下，微调能显著提升效果。

但微调绝对不是免费的午餐。数据量小了容易过拟合，数据质量差还不如不调，微调之后还可能发生“灾难性遗忘”，也就是模型学会了你的领域表达，却忘了通用的问答能力。所以我的建议是，微调前先做一轮成本收益分析，把数据准备的工作量、训练的资源成本、评估的体系建设都算进去，千万不要头脑一热就开训。

5.3 持续迭代的工程文化：AI系统的护城河

最后这点想聊点务虚但重要的事情。AI系统的护城河，根本不在你用了多厉害的模型，而在于你的团队能不能持续、系统化地迭代它。模型会更新、会替换、会上涨价格，但你的数据资产、评测体系、迭代方法论，这些才是真正壁垒深厚的东西。

在做这个项目的过程里，我把大量篇幅留给了评测流程、数据标注实践、bad case分析模板这类“不那么酷”的东西，因为它们才是AI工程长期运转的血液。是从零开始，不只是从零开始学技术，更是从零开始建立一套严谨的工作方法。我真心希望读这套项目的人，最终收获的是一种——拿到一个AI需求时，心里有完整的执行路径、知道每一步怎么做、出了bug知道怎么查的底气。这种底气，是刷再多的Demo都换不来的，这是真正工程化的力量所在。