企业官网建设流程全解析

1. 从"会跑模型"到"AI工程"：差的不是技术，是系统思维

我见过太多这样的场景：一个人兴冲冲地在笔记本上跑通了一个大模型Demo，对话流畅、效果惊艳，于是他觉得自己已经"会AI"了。但等他把这个Demo往真实的业务场景里一放，问题接踵而至——数据格式千奇百怪、模型答非所问、响应慢得让人抓狂、出了问题不知道是提示词的锅还是数据的锅。最后项目烂尾，留下一句"大模型也就那样"。

这恰恰是"会跑模型"和"懂AI工程"之间最本质的差距。

所谓AI工程，不是把模型API接进来就完事，而是从业务问题定义、数据准备、模型选型、评估体系搭建，到部署上线、监控反馈、持续迭代的一整套系统方法论。它解决的核心问题是：如何让一个AI能力在真实、复杂、多变的环境里稳定可靠地工作。

这篇文章想分享的，正是我从零开始搭建AI工程体系的全过程。不吹嘘哪个模型多厉害，也不纠结某个框架多时髦，只讲我在实际项目里验证过的思路、踩过的坑，以及那些文档里不会写但你迟早会撞上的问题。无论你是刚入门的技术爱好者，还是已经在业务里摸爬滚打的工程师，这篇文章应该都能给你一些可落地的参考。

为了不让讨论停留在抽象层面，我会用一个贯穿全文的虚拟案例来说明：给公司内部搭建一个"知识库问答助手"，让员工用自然语言查询制度文件、技术文档和项目经验。这个案例足够典型——它有数据清洗、有检索增强、有评估调优、有部署迭代，几乎覆盖了AI工程的所有关键环节。

2. 别急着选模型：先把问题定义清楚再动手

很多AI项目死在起跑线上，不是技术不够，而是根本没想清楚要解决什么问题。我在做知识库问答助手之前，先花了整整一周时间做需求澄清，这可能是整个项目里最值钱的一周。

2.1 需求澄清：和业务方对齐"什么是好的结果"

需求澄清不是简单问一句"你想要什么功能"，而是要挖出业务方真实的使用场景和验收标准。我常用的几个问题：

• 用户会用什么方式提问？是完整的句子，还是零散的关键词？
• 哪些问题的答案必须是完全准确的？哪些可以容忍模糊？
• 回答需要多快？5秒内还是可以接受1分钟？
• 如果AI答错了，最坏的后果是什么？
• 这个系统是给谁用的？技术背景如何？

以我们做内部知识库问答为例，访谈完行政、技术、销售三个部门后我发现，需求差异非常大：行政部希望查制度文件时给出原文出处和条款编号，错了就是合规风险；技术部希望查历史项目文档时能给出相似案例作为参考，允许一定模糊度；销售部最关心响应速度，他们问的大多是产品参数这类确定性信息。

这些差异直接影响后续所有技术决策：数据清洗的粒度、检索策略的选择、甚至模型提示词的设计方向。如果一开始不搞清楚，后面每走一步都是在空中楼阁上盖房子。

2.2 模型选型的决策框架：别只盯着"效果最好"

模型选型是另一个容易踩坑的地方。很多团队上来就想用最强的大模型，仿佛效果就是一切。但真实工程环境里，你要在效果、成本、延迟、可控性四个维度上做权衡。

我自己的选型框架是这样的：

1. 先根据需求澄清的结果，划定"必须答对"和"可以大致答对"的边界；
2. 对每个任务，优先尝试足够简单、足够便宜的方案，只有当它确实撑不住时再升级模型；
3. 永远给API模型留一个"降级路径"，比如模型服务不可用或超时时，退回关键词检索结果；
4. 如果涉及敏感数据，优先考虑私有化部署的开源模型，哪怕效果略差一点。

具体到知识库问答场景，我用的是"检索增强+中小规模模型"的组合方案：先用embedding模型做向量化召回，再把召回结果拼接成上下文，交给生成模型做最终回答。这样既控制了成本，又能保证答案有据可查。embedding模型选的是开源的中文向量模型，生成模型则根据场景混合使用API和私有化部署，实测下来效果和纯大模型方案差距不大，但成本和响应时间优势明显。

2.3 架构设计的核心原则：让每一层各司其职

AI工程和传统软件工程有一个很大的区别：传统系统里每个模块的行为是可预期的，而模型的行为天然带有不确定性。因此架构设计上必须建立一个原则——把确定性的部分交给代码，把不确定性的部分交给模型，并且给不确定性留好缓冲。

我的知识库问答系统大致分四层：

• 数据层：负责文档清洗、切分、向量化，生成并维护知识库索引；
• 检索层：根据用户问题召回最相关的文档片段；
• 生成层：把召回内容整理成上下文，交给LLM生成最终答案；
• 控制层：负责意图识别、兜底逻辑、引用溯源、日志记录。

每层只做自己的事，不越界。比如生成层绝不试图在没有召回内容的情况下凭空作答，控制层则时刻监控检索质量，一旦发现召回片段和问题的相关度过低，直接触发"信息不足"的兜底回复，而不是让模型硬着头皮编。这个设计看起来简单，却是整个系统稳定性的基石。

3. 数据工程：AI项目里最耗时、最不起眼、最要命的环节

如果说模型是AI项目的大脑，数据就是它的食物。我在这个项目里感受最深的一点是：数据工程占了我超过60%的精力，而它的重要性却最容易被低估。

3.1 从原始文档到可检索的知识单元：清洗与切分

公司知识库里的原始文档类型五花八门：PDF制度文件、Word技术方案、Excel产品参数、PPT培训材料、甚至还有扫描版的会议纪要。这些文档直接丢给模型是不行的，必须经过一套完整的清洗流程。

我总结的清洗步骤：

1. 格式统一：把所有文档转成纯文本或Markdown，去掉页眉页脚、水印、页码等噪音信息；
2. 编码修复：处理中文乱码、全半角符号混用、特殊字符等历史遗留问题；
3. 结构保留：对制度类文档，保留章节标题层级，这对后续切分至关重要；
4. 噪声过滤：剔除表格中无意义的空行、重复段落、废弃版本说明。

清洗完之后就是切分。切分粒度直接决定检索质量，这是很多新手最容易忽略的细节。切太碎，检索到的片段缺乏上下文语义；切太大，上下文窗口塞满无关信息，模型反而抓不住重点。

我试过几种切分策略，最终的经验是：固定字符数切分加重叠窗口，配合结构锚点。具体来说，优先按照文档本身的标题层级切分，当某个小节过长时再按固定长度（比如500字）切分，相邻切片之间保留50字左右的重叠。这样既能保证语义相对完整，又不会让检索单元过大。

3.2 向量化、索引与元数据：检索召回的基础设施

切分后的文本片段还需要转成向量才能做相似度检索。这里有两个关键选择：embedding模型的选择和向量索引的构建。

embedding模型我对比过好几个开源中文模型，最终选了一个在领域文档上表现均衡的，判断标准很简单——拿真实业务问题去测召回率，而不是看模型榜单分数。模型榜单测的是通用场景，你的领域文档长什么样，只有你自己测了才知道。

向量索引选择了支持混合检索的方案：既做向量相似度召回，也做关键词精确匹配。很多人只做向量检索，但实际场景里用户的提问往往包含产品型号、制度编号这类精确关键词，向量检索对这种精确匹配反而不如传统倒排索引靠谱。混合检索、然后融合排序，这个组合在知识库场景下实测提升非常明显。

元数据设计同样不能马虎。我给每个知识片段都打上了文档来源、部门归属、更新日期、权限级别等标签。这些标签短期内看不出价值，但在做权限过滤、结果去重、溯源展示时缺了它们寸步难行。

3.3 测试集建设：数据工程也讲究"验收标准"

数据工程做完了怎么算合格？这一年里我养成了一个习惯：不管做什么AI项目，第一周必须先建立一个小而精的测试集。

所谓测试集，就是一批真实、有代表性的用户问题，以及对应的标准答案。数量不用多，50到100条足矣，但必须覆盖各类典型场景和困难case。我把问题分成几类：

• 常见问题：员工最常问的，比如年假怎么休、报销流程是什么；
• 细节问题：需要从某个文档某一段落找到精确答案；
• 跨文档问题：答案分散在多个文档里，需要整合；
• 模糊/异常问题：问法不标准、甚至跟知识库无关的问题。

这个测试集会陪伴项目从出生到成长，每次改动模型、优化提示词、调整切分策略，第一件事就是跑一遍测试集看效果差异。没有这个测试集，你所有的优化都是盲人摸象——凭感觉觉得好了，上线后被用户一堆问题打得措手不及。

4. 评估体系：没有评测标准，优化就是无底洞

做AI工程和做传统开发最大的心态差异是：传统开发里Bug是明确的、可复现的，但AI系统的"错"是模糊的、渐变的。同一个问题，这周回答得很好，下周换个模型版本就答偏了。因此，一个完善的评估体系，是AI项目能不能长期健康运行的分水岭。

4.1 从"人工看效果"到"可量化的多维指标"

很多团队做AI项目评估，就是开发人员自己多问几个问题，感觉"差不多"就上线了。这种评估方式最大的问题是不可复现、不可对比——你今天觉得效果好，改了一版之后感觉也还行，但到底哪里变好了、哪里变差了，完全说不清。

我设计的评估体系包含三个维度：

• 答案正确性：核心信息是否正确。按满分5分人工打分，或通过答案与标准答案的语义相似度自动评估；
• 回答忠实性：回答是否严格基于检索到的知识片段，有没有编造内容。这个指标我特别看重，直接关系用户信任；
• 引用可溯源性：答案是否清晰标注了来源文档和原文位置，能不能点开溯源。

三个维度分开打分，任何一次优化都要保证三项指标不出现明显劣化。尤其是忠实性，我把它设为一票否决项——哪怕答案再流畅再全面，只要发现有一次编造，就必须回炉。

4.2 自动化回归测试：给AI项目上个保险栓

人工评估必不可少，但不能天天靠人工——费时费力还容易手滑。我搭建了一个半自动化的回归测试机制：

• 每周自动跑一遍测试集，生成效果报告；
• 变更多个环节进行比较评估，任何改动的上线都得有评估数据支持；
• 生产环境的日志每周做一次bad case挖掘，主动抓取用户问过但系统答得不好的case，补进测试集。

这套机制救了我很多次。印象最深的一次是调整了切分策略，当时人工抽了几个问题觉得一切正常，结果自动回归测试发现"制度有效期类"问题的答案准确率下降了12个百分点——因为新的切分方式把"生效日期"这类关键信息从上下文里切出去了。如果不是回归测试拦住了这次改动，这个问题大概率会潜伏到用户吐槽之后才发现。

4.3 用户反馈闭环：评估体系的活水来源

测试集是固定的，但真实用户的问题是流动的。我做了两个低成本的动作来捕捉用户反馈：一是在问答页面加了一个"答案是否有帮助"的点赞点踩按钮；二是每周导出用户真实提问日志，人工筛选高频问题中没有被很好回答的case。

这些真实反馈会定期回流到测试集和知识库修正流程中。我发现一个有意思的现象：真实用户最常问的问题，往往和你预想的重点完全不同。比如我们做的是内部知识库问答，结果上线后最高频的问题居然是"会议室怎么预约"——这个问题的答案其实在OA系统里，根本不在知识库里。数据告诉我们，系统需要对接的入口比想象中多得多，而不是单纯在文档库里找答案。

5. 提示词、检索与生成：决定回答质量的三驾马车

评估体系落定之后，我才开始把重心放到回答质量的精细调优上。很多人一上来就死磕提示词，但我的建议是：先把数据和评估做好，再碰提示词——否则你连改得好不好都判断不了。

5.1 提示词设计的结构化方法：不是越复杂越好

关于提示词，我需要先纠一个普遍的误解。网上那些"一句话让AI帮你搞定一切"的万能提示词，在真实工程场景里基本是屠龙之技。专业的提示词设计，更像是在为一套严谨的业务逻辑编写控制规则。

我在知识库问答助手里用的提示词，核心包含五个要素：

1. 角色设定：告诉模型它是什么（内部知识库问答助手），以及行为边界（只能依据给定资料回答）；
2. 任务指令：明确生成任务（根据检索内容回答问题，不得超出范围）；
3. 格式约束：规定答案结构（先给结论，再给依据，标注引用编号）；
4. 负面约束：说明不能做什么（不知道就说不了解，不得编造，不得转发无关信息）；
5. 输入占位符：标记用户问题和检索上下文的位置。

关键经验是负面约束必须具体，不能写成"要准确、要严谨"这种空话。比如我写的是："如果你无法从资料中找到答案，请直接回复'知识库中暂无相关信息，建议联系行政部或访问OA系统查阅'，不要尝试推测。"

5.2 检索与生成的配合：让模型轻松地做"摘抄"，而不是"创作"

生成层有两条高级经验，花了我很长时间才悟出来：

第一条，检索质量直接决定回答效果的天花板，提示词只是守住底线。模型再聪明，喂给它的上下文内容是错的，输出也只能是错的。所以与其花时间雕琢提示词，不如把精力花在提升检索召回精度上。在做检索增强（RAG）项目时，我周围太多人试图通过提示词让模型"更聪明"，但真正效果显著的优化，90%来自检索侧的改进。

第二条，给模型创造一个容易"抄对"的上下文。我一开始把检索到的所有片段一股脑拼接进提示词，结果模型经常在多个冗余片段中迷失重点。后来改为"检索后重排+关键片段摘取"：先用向量检索加关键词召回的粗筛，再用一个重排序模型对候选片段打分，只挑最相关的3到5个片段进上下文，并按相关度从高到低排列。实验数据表明，这种做法的答案准确率提升了将近9个百分点——解释也很自然：高质量的检索结果让模型从"命题作文"变成了"信息摘抄"，难度完全不同。

5.3 兜底设计：AI系统的"安全阀"

再好的检索和生成配置，也会有失败的时候。工程思维要求我们必须预设失败路径并设计好兜底处理。

我在知识库问答系统里设计了多级兜底：

• 模型超时或API不可用：返回检索列表，并提示"系统正忙，请稍后再试或点击以下相关文档";
• 检索召回score过低：直接触发"知识库中暂无相关信息"话术；
• 用户问题识别为闲聊：不做强行回答，转而引导用户输入与工作相关的问题；
• 涉及敏感权限的文档未被检索到：不回显"没有权限"这种泄露信息的话术，统一用"无法提供该文档内容"来处理。

这套兜底机制上线后，系统的容错能力有了质的提升。用户反馈里最明显的变化是：以前模型偶尔会"一本正经地胡说八道"，现在顶多是"抱歉查不到"，但用户不会觉得系统在骗人。

6. 部署上线与持续迭代：从"能用"到"好用"的最后一公里

一个AI系统在本地跑通了，和它能在生产环境稳定运行，中间隔着的距离比大多数人想象的要大。这个阶段考验的已经不是模型能力，而是软件工程的基本功。

6.1 服务化部署与性能优化

部署层面最重要的三个指标是延迟、吞吐和可用性。知识库问答的链路是"查询改写→向量检索→重排过滤→LLM生成"，每个环节都有延迟开销。我主要做了三件事：

第一，向量检索上缓存。把高频问题的检索结果缓存起来，热门问题直接命中缓存，几乎零延迟返回。数据表明，知识库类的问答请求约有20%是高频重复的，缓存带来的收益非常可观。

第二，对生成层做了流式输出改造。大模型生成答案通常是逐字输出的，如果等全部生成完再返回，首字响应时间会很长，用户体感就是"转圈圈"。流式输出让第一个字在几百毫秒内就出来，体感提升明显。技术实现并不复杂，但交互体验差异是质的。

第三，模型调用做容错。为API调用配置了超时重试和熔断机制。当模型服务连续报错时自动降级到纯检索模式，保证用户至少还能拿到相关文档，而不是一顿报错。这个设计很简单，但救命能力一流——我遇到过不止一次模型服务不稳定，如果没有降级机制，整个系统就直接瘫痪了。

6.2 日志、监控与bad case反哺

上线只是开始。我搭建了一套从日志到改进的闭环：每个问题、检索结果、生成的答案、用户反馈全部结构化记录；每天监控平均延迟、召回率、无命中率、用户点踩率等核心指标；每周做一次bad case专项分析，挑出有代表性的错误案例，反哺到数据清洗、切分策略、提示词调整的优先级排序里。

这个机制里最妙的一点是让bad case自己"说话"。比如通过日志分析我发现：当用户问法用了口语化表达或简称时，检索效果明显变差。于是我在检索前加了一层"同义扩展"逻辑，把"年假""休假""带薪假"这类相关表述统一映射后再去检索，命中率显著提升。这种洞察如果不依赖日志数据，纯粹靠拍脑袋想很难发现。

6.3 持续迭代的节奏：小步快跑，数据驱动

AI系统没有"做完"的一天。知识库里的文档在持续更新，用户的问题分布也在不断变化，系统必须跟着演进。我习惯的迭代节奏是：

• 每周一次小版本更新，通常包含知识库文档增量更新、提示词微调、坏case修补；
• 每月一次大版本评估，全面跑测试集、分析用户反馈、调整评估指标权重；
• 每次改动强制过回归测试，宁慢勿快，确保没有引入新的劣化。

节奏感非常重要，因为AI项目的改动往往牵一发动全身。我做事的雷打不动的原则是：每次只改一个变量，用数据对比来验证改动效果。如果同时改了好几个东西，效果变好或变差你都搞不清楚是哪个环节的贡献。

7. 真实记录：我在这个项目里踩过的几个坑

最后想写点纯粹的踩坑记录，这些坑你在教科书和官方文档里几乎看不到，但每一个都是真实时间换来的教训。

7.1 第一个坑：把模型当数据库用

项目初期，我贪图方便，让模型直接回答知识库问题，不接入检索环节。结果模型在回答具体制度和数据时经常出错——它会把训练数据里的过时信息当成最新内容。用户问"三类医疗器械的注册流程"，它答的是几年前的老流程。这个教训促使我下定决心做检索增强架构。本质上，让模型凭记忆回答动态更新的企业内部文档，等于让一个人考一份永远在更新的试——他能及格才是奇迹。

7.2 第二个坑：切分粒度想当然

我曾轻信"按段落切分最自然"的说法，结果制度文件里一句话往往跨了好几个段落，检索时老是召回语义不全的片段。后来通过测试集跑分对比，发现固定长度加重叠窗口的方式在召回率上明显占优，果断推翻重来。这个经历让我明白：在AI工程里，任何"理所当然"的判断都要用数据验证，直觉只配做假设，数据才配做结论。

7.3 第三个坑：忽视引用溯源

第一版系统回答问题时干干净净，没有任何引用标注。内部试用时收到一条印象深刻的反馈："这个答案看起来挺对的，但我怎么知道它是真的对？"没有出处，用户就不敢信。后来我把"引用来源"从增强项改成了必选项——每个核心结论后面都附上文档名和章节位置，点击即可查看原文。这个改动直接让用户信任度和采纳率上了一个大台阶，也让我真正理解了AI系统里"可信"这两个字的分量。

7.4 第四个坑：权限过滤想得太简单

公司知识库里有不同密级的文档，我一开始天真地认为"文档级权限控制就够了"。但真实情况是：同一份PDF里可能混着公开信息和机密段落，检索系统按文档粒度去过滤，机密内容照样会被召回。后来我把权限标签细化到"片段级"，并且在前置查询改写时带上提问者的权限上下文，检索阶段就过滤掉无权限的片段，才把这个问题解决干净。

7.5 第五个坑：拿着锤子找钉子

这个坑不是技术问题，是心态问题。项目做大了以后，有一段时间我沉迷于尝试各种新技术——换更强的模型、上更复杂的框架。但冷静下来跑测试集才发现，大部分"升级"对业务效果的提升微乎其微，倒是成本和复杂度直线上升。后来我给自己立了个规矩：任何技术升级，必须先回答一个问题——它到底解决了哪个具体的业务痛点？答不上来就不做。

回到最初的话题。从零开始做AI工程，真正考验人的不在于你调通了多少模型接口，而在于你愿不愿意为一个清晰的问题搭建完整的系统，为每一个环节建立可验证的评估标准，并接受"这是一个持续演进的过程"这个事实。

我自己的体会是：AI工程的入门门槛其实并不高，因为现成的工具链已经很完善了，真正稀缺的是系统思维——从定义问题、构造数据、设计评估，到部署迭代、闭环反馈。这个思维框架一旦建立，换个场景、换个模型，你都能快速复制出可靠落地的解决方案。希望这篇记录能把你在从零到一的路上少走几步弯路，哪怕只有一两个点能派上用场，我就觉得值了。