企业官网建设流程全解析

直接说结论：现在大家讨论的AI工程，早就不是“写个Python脚本调一下API”这么简单了。我看到“ai-engineering-from-scratch”这个标题的第一反应是，这哥们想做的不是又一个demo，而是一整套能跑、能维护、能评估、能迭代的AI应用落地方法论。这个方向太对了，太多人卡在“模型能跑通”到“系统能稳定工作”之间的那段路上。

这篇文章我不打算讲什么高深理论，就是拆解一个从零开始的AI工程到底该怎么搭，核心模块有哪些，每步怎么选型、怎么避坑。不管你是技术负责人、后端开发还是刚转行做AI应用的，只要想把手里的LLM应用做成真正能扛业务的系统，这篇内容应该能帮你把整个链路梳理清楚。

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

1.1 到底什么才算“AI工程”

先说个我观察到的普遍现象。很多人觉得用LangChain写了几个chain，或者用Dify拖了个工作流，就算“做AI”了。这离工程化还差得远。真正的AI工程，至少得包含数据管线、上下文工程、模型调度、评估体系、可观测性、成本和风险控制这几块，缺一不可。

从零开始做AI工程，脑子里要有一张完整的地图。我自己的习惯是把整个系统分成四层来看：

• 数据层：文档解析、清洗、切片、向量化、索引构建，这是RAG的底座，也是幻觉的主要来源之一。
• 推理层：模型调用、Prompt模板管理、结构化输出、函数调用、多模型路由。这一层决定了AI的下限。
• 应用层：Agent编排、业务流程注入、工具调用、状态管理、人工审核机制。
• 评估与运维层：离线评测集、线上日志、质量监控、回归测试、成本统计。

这套分层不是学术定义，是从实际踩坑里总结出来的。你拿着这套分层去对照自己的项目，会发现自己缺的往往不是模型能力，而是数据层和评估层根本没建起来。

1.2 为什么很多AI项目死在“demo完成之后”

我做过的AI项目里，失败率最高的阶段不是技术验证，而是demo到生产的过渡期。demo阶段你只需要证明“模型能回答对几个问题”，生产阶段你需要证明“系统在数据变化、模型升级、用户乱问的情况下，仍然能保持可接受的准确率”。

这里有个非常反直觉的点：如果你从零开始设计AI工程，应该先把评估体系做出来，再回头优化Prompt和RAG链路。因为只有评估体系立住了，你才能知道每次改动是变好了还是变坏了。没有评估体系的AI项目，优化全靠感觉，上线全靠运气。

我还发现，很多开发者的第一反应是“先选个大模型”。这个思维在工程化视角下是错的。正确的顺序应该是：先定义场景和指标，再决定用哪种模型方案。比如客服问答场景，你需要的是可插拔的kb（knowledge base）管理能力，还是模型本身的通用知识就够？这决定了你是走RAG、走微调，还是直接裸模型加细Prompt。

2. 核心细节解析与实操要点

2.1 数据管线的关键环节与参数选择

数据管线是整个AI工程里最枯燥但最决定成败的部分。我见过太多项目，模型烂得离谱，根因其实是喂进去的数据烂。做AI工程的数据管线，要重点解决两件事：怎么把非结构化数据变成可检索的片段，怎么让检索结果真正匹配用户意图。

文档切片是第一道坎。切得太碎了，上下文碎片化，模型抓不住重点；切得太粗，混入大量噪声，检索精度和召回的效率都会下降。我常用的策略是“语义段落切分（semantic chunking）+重叠窗口（overlap）”。不是按字符数硬切的，而是按标题、段落、句子边界来切，再把过短的片段和相邻片段合并。

这里给一组我实测比较稳的初始参数，具体还要根据文档情况调整：

• chunk_size：按场景分，FAQ类切200~400字符，长文档切800~1200字符。
• chunk_overlap：80~200字符，目的是避免句子被拦腰截断导致语义缺失。
• 切片单位：优先考虑用Markdown标题、段落、甚至代码结构作为边界。
• 索引方式：先用BM25做稀疏检索，再用向量检索做语义召回，最后用Rerank模块做精排。

很多人会忽略“标题锚点”的作用。切片时把文档的层级标题作为上下文拼进每个chunk，会让检索命中率明显提升。比如一个产品手册里提到“温度范围”，如果chunk里只写着“工作温度0~40℃”，没有“环境要求”这个标题前缀，检索时关键词匹配会非常吃亏。所以在切片阶段，把父级标题带进文本内容，是一个性价比极高的预处理手段。

向量化的关键选择在于Embedding模型。如果你的文档是中文为主，直接套用通用英文Embedding模型效果会差不少。建议优先用中文语料训练或做过多语言适配的模型。另一个实操技巧是，Embedding模型尽量和Rerank模型分开选型，别指望一个模型既做召回又做精排还能都做得很好。

2.2 上下文工程：RAG和Prompt的实际操作边界

RAG不是简单地把检索结果塞进Prompt就完事了。我做了这么多项目之后，最大的感悟是：RAG的精度上限，取决于你对检索结果的“信任度”。而信任度，要靠一套完整的上下文工程来解决。

在你把检索片段交给模型之前，需要回答三个问题：

• 第一，这个片段到底和用户问题有多相关？相关性阈值设置多少才不会误召回？
• 第二，多个片段之间会不会自相矛盾？如果有矛盾，怎么裁决优先级？
• 第三，片段里有没有冗余信息？冗余信息会不会把模型带偏？

我常用的做法是引入两层过滤。第一层是粗滤，用一个比较宽松的相似度阈值把明显不相关的片段过滤掉，比如阈值为0.5~0.6（具体取决于Embedding模型分布）。第二层是精排，把Top 20的候选片段交给Rerank模型重新打分，取Top 3~5进入上下文窗口。这里要注意，Rerank之后别只看分数，要关注片段间的相对差距，如果第一名和第二名分数差距很小，建议同时保留这两个片段，让模型自行判断，也能避免一次“极端排序”带来的上下文误伤。

Prompt本身的工程，也容易犯傲慢的错误。别一股脑把所有东西都塞进System Prompt里。System Prompt的最佳状态是“稳定、简洁、可复用”，把变化的内容放到每轮请求的动态上下文里。我习惯把“任务指令”“输出格式约束”“上下文材料”“历史对话”这四个部分拆成独立的模板变量，而不是混在一个字符串里反复拼接。

这里分享一个我自己一直在用的小技巧：在Prompt里显式地给模型“拒绝回答”的出口。很多AI系统给用户的体验差，不是因为答错，而是因为不懂装懂。在Prompt里加一句“如果依据上下文无法确认答案，必须明确回复‘目前知识库中未找到相关信息’”，能大幅减少幻觉。但注意，不要只给一句话，还需要配一个“可回答性的评分预判”环节，让模型在正式回答前先自查有没有足够的上下文依据。

2.3 Agent编排的注意点

Agent是AI工程里最容易让人产生“技术兴奋感”的模块，但它也是失控重灾区。做Agent编排，我的建议是：能不用Agent就不用Agent，如果非用不可，务必给它加牢笼。

这句话不是反对Agent，而是告诉你，工程化场景里，稳定性和预期性比炫技重要得多。大部分业务场景本质上是有固定流程的，比如“查天气、再查机票、最后推荐酒店”，这一套编排用确定性流程就能写死。用Agent自由调用工具，确实能应对更复杂的场景，但代价是推理链路不可控、Token成本翻倍、错误路径难以追踪。

如果业务确实需要Agent，至少要做好三件事：

• 第一，工具白名单。Agent只能调用预先注册好的函数，绝对不能让它自由拼接系统指令。
• 第二，最大步数限制。单轮任务最多执行N次工具调用，超过就强制收敛并进入兜底回复。
• 第三，人在环（Human-in-the-loop）设计。涉及高危操作或金额操作，必须插入人工确认节点。

我在生产环境还会额外加一层“意图分流”。用户在输入的时候，先判断是闲聊、知识问答，还是复杂任务。只有复杂任务才进入Agent编排链路，其他场景直接走对应的轻量模块。这样做的好处是，大部分高并发请求落在简单的RAG或固定流程上，成本和延迟都能压下来。

3. 实操过程与核心环节实现

3.1 目标场景拆解：以“企业知识库智能助手”为例

为了把上面的方法落到可执行层面，我拿一个我非常熟悉的场景来讲：企业知识库智能助手。做这个场景的AI工程，要解决的核心痛点是员工每天花大量时间在内部文档里翻找信息。而AI助手要做的，就是把这些文档变成可交互的接口。

先做需求拆解。企业知识库助手分三个层级：

• 第一级：精准问答。“报销流程是什么”“年假制度怎么规定的”，这类问题需要精准命中对应文档片段。
• 第二级：归纳总结。“给我汇总这份项目的风险点”，需要跨多个文档做内容聚合。
• 第三级：操作引导。“帮我创建一个项目立项申请”，需要理解业务流程并调用对应工具完成操作。

不同层级的复杂度差异很大。第一级用传统RAG就能解决，第三级必须引入Agent。我的建议是，先做扎实第一级，再往上叠加第二级和第三级。很多项目一上来就想做“全自动智能体”，结果连文档检索的准确率都没优化好，最后体验一团糟。

3.2 从零搭建RAG链路的实操步骤

我先说清楚这部分的操作路径，再给每个环节的关键参数和意图。

第一步，数据准备。把企业内部文档统一转成Markdown或纯文本格式。这一步是为了去掉PDF、Word里的复杂排版问题，让后续切片的稳定性能达到工程标准。

第二步，切片。按文档结构优先切分，再结合长度限制做二次切分。比如一个chapter太长，就在二级标题处断开。每个chunk以“父标题+内容”的格式存储，同时保留来源、页数、文档名作为元数据。切片完成率要做到100%，任何解析失败的文件都要在日志里单独标注，不静默丢弃。

第三步，向量化。调用Embedding模型把每个chunk转成向量。这里要记录模型版本和向量维度，因为后续升级模型会导致整个库需要重建索引。没有做版本管理的向量库，以后每次模型升级都等于技术债爆发。

第四步，构建双路检索。BM25索引负责字面匹配，向量索引负责语义召回。双路结果做融合排序。我常用的策略是：分别取两边Top 20，做RRF（Reciprocal Rank Fusion）融合，再交给Rerank模型精排，最终取Top 3~5作为上下文。

第五步，接入Prompt。在Prompt里明确告诉模型：你有两份信息来源，第一份是检索到的知识库片段，第二份是你的通用知识。当片段信息不足时，优先用片段；片段无法回答时，直接承认不知道。

整个过程里，有四个参数需要特别关注：

• top_k：进入Rerank阶段之前保留多少候选，一般是20~30。
• top_n：最终进Prompt的片段数，一般3~5，具体看模型上下文窗口。
• rerank_score阈值：不同Rerank模型分数分布差异很大，建议在真实数据上跑一遍分布再设阈值。
• temperature：知识问答类场景通常设0.1~0.3，避免模型自由发挥。

3.3 Agent编排的轻量实现

再演示一下轻量Agent怎么搭。我用的是“状态机+工具注册中心”模式，而不是让Agent完全自主规划。

工具注册中心是一个列表，每项包含工具名、参数协议、权限等级、超时时间。Agent在推理时只能从注册中心里选择工具，不能绕过注册中心去调用其他函数。状态机则定义了整个业务流程的节点流转。比如“获取报销流程”这个任务，状态流转是：意图识别 → 关联政策检索 → 生成步骤说明 → 可选操作：打开报销系统。每一步都是可控的，模型只负责填参数，不负责决定流程走向。

这种半自主模式的好处是，你可以清晰地知道用户卡在哪一步，以及Agent在哪一步执行错误。全自主Agent的推理过程是黑盒，出了问题你也很难从日志里定位，只能看到模型在反复调用同一个工具空转，这种体验我实在不想再来一次。

3.4 评估体系的从零构建

评估是AI工程里我投入精力最多、也是回报最明显的一块。没有评估体系，前面所有的优化工作都像在黑夜里开车。

我构建评估体系分三个步骤。

第一，建评测集。从真实用户日志里挑选200~500条典型问题，覆盖常见场景、边界场景、问题变体和已知的失败案。失败案尤其重要，每次线上出了badcase，都要收敛到评测集里，确保后续优化不会让同样的错误复发。

第二，定评测维度。我常用四个维度：准确率、完整度、可读性和安全性。准确率看核心事实是否正确；完整度看必要信息是否遗漏；可读性看表达是否清晰；安全性看是否触发了不当内容或幻觉风险。每个维度按1~5分打分，也可以用大模型当裁判做自动打分，但一定要抽样人工复核。

第三，做回归测试。每次修改Prompt、更新切片策略、更换Embedding模型之后，都要在评测集上跑一遍全量回归。我的标准是：准确率下降超过1个百分点就不能上线。

还有一个容易被忽略的指标，叫“拒绝率”。系统在无法判断时是否敢于拒绝回答。很多AI系统为了追求“有求必应”，硬编答案，结果幻觉率飙升。我把拒绝率当成一个独立的健康指标在监控，太高说明知识库覆盖度不够，太低说明系统在胡编。

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

4.1 检索质量差的典型原因

AI工程落地过程中，最省时间的投入就是学会快速排查检索质量问题。我整理了四个最常见的病根。

第一是切片不合理。明明有相关内容，但切片的时候把关键信息拦腰截断，导致两个片段各有一半信息，检索时两段都命中，但都不完整。排查方法是人工挑几个badcase，看看返回的chunk内容是否完整涵盖答案。解决方法是调大overlap，或者改成“以段落边界为主、长度限制兜底”的切分策略。

第二是Query与文档用词不一致。用户问“工资什么时候发”，文档里写的是“薪酬发放日期”。字面上匹配不上，向量召回也弱。解决方法是做同义词扩展或建立领域词表，在检索时对Query做轻度改写。

第三是Embedding模型和业务领域不匹配。通用模型在垂直领域（医疗、法律、金融）的效果往往很有限。解决办法是用领域语料微调Embedding模型，或者换一个在目标领域有优势的商用Embedding。

第四是上下文窗口塞了太多低相关片段。前3个相关，后5个全是模糊相关的。模型在大量噪声干扰下，更倾向回答通用知识而非片段信息。解决方法是降低top_n，并设置一个更严格的Rerank阈值。

4.2 幻觉问题的排查思路

幻觉是AI应用里最致命的问题，但我发现，很多人遇到幻觉就直接甩锅给模型，完全不去排查其他环节。其实工程层面能做的预防非常多。

我的排查路径是什么？先查Prompt里有没有强制要求“只能根据上下文回答”？再查检索片段里是否存在信息冲突？然后查系统里有没有给模型足够的“说不知道”的空间？最后才是考虑换一个更强的模型。前面三步没做好，换再大的模型也白搭。

还有个小经验分享：不要在System Prompt里写太长太复杂的自我认知。比如你让模型扮演“企业智能助手”，就要给它定“人设边界”——能干什么、不能干什么、不知道的时候怎么说。人设写得模糊，模型就会倾向于用“通用人工智能”的默认行为模式来回答，也就是自由发挥，幻觉率直线上升。

4.3 成本与性能调优记录

最后聊一个几乎所有从零做AI工程的人都会遇到的问题：成本失控。

我做过的案例里，成本最大的来源不是模型推理本身，而是把太多不必要的内容塞进上下文。很多方案的Prompt动辄3000~5000个token，其中一大半是重复的历史对话和无关知识片段。我的优化习惯是：

• 首先控制上下文长度，把知识片段之外的内容压到500 token以内。
• 其次做问题分类，复杂问题走大模型，简单问题走短Prompt的轻量模型。
• 再采用缓存策略，对固定知识片段的Embedding结果做长期缓存，不重复计算。
• 最后控制历史对话轮数，超过5轮就做摘要压缩，而不是原样拼接。

性能上，工程化的关键是横向扩展。如果你的链路是“BM25 + 向量检索 + Rerank + LLM”，那这四个组件的资源消耗完全不一样。建议单独部署：重计算放GPU做Embedding和Rerank，检索实例用纯CPU撑高并发，LLM推理走单独的模型服务。这样任意一个环节出现瓶颈，都可以独立扩容，不会互相拖累。

成本监控也要做细，不是看月底账单，而是要按业务线、按功能模块拆分数Token消耗。哪条链路消耗最高一目了然。我发现很多团队连基本的Token消耗统计都没有，月底账单爆炸却找不到源头。

5. 从零到一：给新手的落地建议

写到这里，其实整体链路已经梳理得差不多了。但我还想再给那些刚准备入手的读者，多添几句自己的切身感受。做AI工程，最大的误区是一开始就想做一个“全能系统”。全能系统做成之前，你可能已经耗尽了团队的耐心。

我的经验是，从零开始，一定要划出一条“最小可用边界”。比如企业知识库助手，最小可用边界就是：能精准回答10个高频问题，检索命中率超过90%，且拒绝率在合理范围内。先把这10个问题做到极致，再逐步扩展知识库范围和增加Agent能力。

另外，AI工程的代码质量要求，不比传统后端低。别因为它是AI应用就把代码质量放松了。Prompt模板要纳入版本管理，Embedding模型的版本要记录在向量库的元数据里，评测集要像测试用例一样维护。每一行配置的变化，都要能追溯到“为什么改”“改了什么”“效果如何”。

很多人以为AI工程的难点在于模型，实际做下来你会发现，难点在于整个系统的可维护性。模型被替代是很正常的事，今天你用GPT-4o，明天可能就换成开源模型或自研模型。只有当你的数据管线、评估体系、Prompt模板都独立于模型存在时，换模型才是一件低成本的事。

这个领域变化太快，今天的最佳实践明天可能就过时。但工程化的思维不会过时：先定义可衡量的指标，再建立可信的评估，然后用结构化的方式把不确定性拆解成确定性模块。把这套思维刻在脑子里，无论底层模型怎么变，你都能快速跟上节奏。

最后再分享一个小习惯，这也是我最近一直在坚持的：每天从线上日志里挑一个badcase，放到评测集里，然后让技术团队归档。不需要当天修复，但必须记录。坚持一个月，你会看到你的系统在真实数据上的表现有一个看得见的跃升。这个习惯投入极低，回报却远超任何一次模型升级。