企业官网建设流程全解析

说起来有点丢人。我们那个AI助手在内部测试的时候，简直是人见人夸。同事问什么，它答什么，引经据典，头头是道。当时大家一致觉得这项目稳了，甚至开始畅想“AI客服替代人工”“AI助理全员上岗”的画面。结果真正推到客户现场的那一天，对面只是换了个问法，我们的助手直接开始一本正经地胡说八道。那一刻，我站在会议室角落，脚趾几乎抠穿了地板。

那次翻车之后，我才真正开始思考一个以前从没认真对待的问题：我们到底是在“哄”模型，还是在“驯服”模型？“哄”是用甜言蜜语换片刻配合，换来的是一次两次的偶然成功；“驯服”是建立规则、训练反馈、确认边界，让模型的高水平表现可以稳定复现。这个区别，几乎是AI能不能真正落地的分水岭。

如果你也正处在“模型Demo跑通了，但离好用总是差一口气”的阶段，这篇内容应该能帮上忙。文章里不聊算法研究，不聊论文复现，只聊我们团队从“哄”到“驯服”的完整经历：踩了哪些坑、为什么这么设计、每一步是怎么想清楚的。

1. “哄”阶段：Prompt调参调到头秃，老板一句话就破防

1.1 那个完美的Demo和第一个裂纹

我们做的第一版方案非常朴素：一条精心打磨的系统提示词，加上一个大模型的云端API，再套一层简单的Web界面。当时信心满满，因为内部测试效果真的很好。

我们构造了大概二十条标准问题，比如“报销流程是什么”“年假怎么算”“门禁卡丢了找谁”。模型基本都能给出一段像模像样的回答。那段时间团队氛围特别好，大家都说这模型太聪明了，仿佛只要把提示词写得再具体一点，它就能解决一切问题。

裂纹出现在第一个星期之后。老板在全员会议上随口问了句“如果员工在南京出差，但社保交在上海，年假应该按哪边的规定算？”话音刚落，模型回复了一长串答案，看似严谨，实则左边引用了一个不相关的政策条款，右边混淆了属地原则，还把所有可能存在的方案全列了一遍，等于什么都没说。办公室里一片安静。

这个问题的根源不是模型变笨了，而是我们之前那二十条测试题都太规矩了。真实业务里的问题从来不会老老实实地按提示词里的模板来问，它们会加条件、换主语、省略背景，甚至一句话里塞两三个隐含前提。模型在这些问题上就开始自由发挥，因为它不懂规则，只知道“生成一个看起来合理的回答”。

1.2 为什么“哄”出来的效果注定走不远

那次会议之后，我们没有立刻放弃Prompt方案，而是开始加大力度“哄”它。让它更聪明。提示词里加上“你是公司内部的资深HR专家”，加上“回答要严谨负责”，加上“不确定的地方要说不知道”，加上“分条列点、逻辑清晰”。每加一句，测试集的好看程度就上升一点。

但实测下来，这套方案的脆弱性体现在四个层面：

• 语义的脆弱性。用户稍微换个问法，模型就抓不住重点。同一道题，用“报销上限是多少”和“我最多能报多少”去问，得到的答案经常不一样。这不完全是模型的错，是因为Prompt本身没有任何机制约束它“必须正确理解实体之间的关系”。
• 知识的边界模糊。模型训练时见过的知识是“广而浅”的，它擅长的是把看起来相关的信息组织起来，而不是判断“哪些信息才是真正确切的答案”。一旦话题从通用知识切换成企业内部私有知识，它就失去了依据，只能连猜带编。
• 上下文长度的隐忧。我们把太多背景信息塞进提示词，结果发现随着上下文增长，模型的注意力会被稀释，回答后面的问题质量明显下滑。尤其当历史对话超过一定长度之后，模型甚至会遗忘掉最开始给它的关键约束。
• 成本与效果的边际效应递减。为了持续“哄”出好效果，我们需要加大上下文、增加few-shot示例、反复重试不同写法。但每轮尝试都消耗Token，而且每改一句话，可能只在测试集的某几个问题上变好了，另外几个问题又变差了。这种“按下葫芦浮起瓢”的状况持续了两个多星期，团队内部开始有人质疑：我们是不是一直在原地打转？

我后来想明白一个事情：“哄”模型本质上是把模型当成了一个随机发挥的实习生。你给足背景、给足示例、反复叮嘱，它可能干得不错；但只要情况变了，它就会凭感觉乱来。你要知道，真正让人放心的，不是它某几个问题回答得多好，而是它在所有能预料到的情况下都能稳定输出。这恰好就是“哄”给不了的。

2. 从“哄”到“驯服”：把问题重新定义成工程问题

2.1 一次客户现场的“翻车”复盘

真正的转折点来自一次外部演示。我们带着那个精心调教过的Demo去了客户那边，客户方的信息化负责人只问了两个问题：“这个答案的来源是什么？如果错了，我们的责任怎么算？”

第一问，我们答不上来；第二问，我们更答不上来。

复盘那次翻车，我们把失败拆成了三个层面：

• 产品层面：我们没有给用户任何“监督模型可信度”的手段，页面里只有一段AI生成的文字，没有来源、没有依据、没有“置信度”的展示。用户凭什么信任一个黑盒子？
• 技术层面：模型的生成过程完全没有和业务数据产生真实关联。它回答所有问题靠的都是“模型自己知道的东西”，而不是“我们提供的资料里写的东西”。这意味着我们无法追溯它为什么这么答，也无法保证它答得和规章制度一致。
• 流程层面：我们没有定义“什么样的回答算合格”。团队内部的验收标准就是“读起来像不像那么回事”，这个标准太主观了，根本无法自动化，更无法回归测试。

这三个层面归纳下来其实是一句话：我们一直把“让模型生成一段文字”当作目标，而真实业务需要的是“让系统给出一个有依据的答案”。前者是文本生成问题，后者是信息检索和信息综合的问题。角度一换，整个技术方案都变了。

2.2 新的架构长什么样：知识库加检索加生成

那段时间我们重新画了一张架构草图，核心思路是：不再让模型凭空发挥，而是让它先到“知识库”里找答案，找到足够支撑的证据之后，再把证据组织成人类能读的文字。

这套架构总结下来是下面五个环节：

1. 知识采集与清洗：把散落在各处Word、PDF、在线文档里的内部制度、流程说明、常见问题整理出来，统一格式，去除重复，标记权威版本。
2. 文本切分：把长文档切成固定大小的块，切的时候注意不要破坏语义完整性。这里需要一定的技术手段，比如按照标题层级、段落结构来切，而不是机械地按字数切。
3. 向量化入库：把每个文本块通过向量化模型转成向量，存入向量数据库。检索的时候把用户问题也转成向量，然后做距离计算，找出最相关的文本块。
4. 召回与重排：先用向量相似度做一轮初筛，把最相近的几十块文本捞出来，再用更精细的算法做重排，最终选出可以送入模型的那几块。
5. 生成回答：把选出来的文本块作为“参考资料”和用户问题一起组装成Prompt，送给模型，让它严格按照资料内容生成答案，并且要求标注来源。

第一次看到这套方案时，团队里有同事脱口而出：“这不就是把Prompt从‘背资料’改成了‘开卷考试’吗？”我说对，本质就是开卷考试。模型的能力依然是它自己的，但它回答问题的依据不再来自记忆里的模糊印象，而是来自我们提供的、最新的、经过审核的资料。考场上允许翻书，错误率一下就下来了。

当时我们也做过微调方案的可能性分析，最后还是选择了知识库加检索加生成的架构，原因很实际：

我们评估的结论是：业务场景不急迫到要“把规则刻进模型权重里”的程度，那就老老实实用检索增强的方法。这也成为后面一切工程的基石。

2.3 关键决策：自建知识库还是直接用别人封装好的能力

确定了技术架构后，下一个问题是：这类能力是自研，还是使用云平台提供的封装服务？我们的决策路径比较务实：

如果团队里没人懂向量化和检索排序，那就用封装好的，先把业务跑通再说。我们当时情况恰好是团队有一定技术底子，但人手有限，所以采用了“半自研”的方式：向量化模型和向量数据库用成熟产品，中间那层调度、重排、生成策略自己写。好处是自由度大，出了问题能快速定位；坏处是前期工程量多一点。

这里可以给一个建议：不要一开始就追求大而全的“Agent框架”，先把“单轮问答”这一条通路打扎实，再谈复杂编排。很多团队一上来就上多Agent协作、工具调用、记忆网络，结果连“回答准确率”这个基本指标都没定义清楚，翻车只是时间问题。

3. “驯服”的第一个拐点：给模型装上“评分表”

3.1 评估体系：靠感觉验收的时代结束了

旧的验收方式完全是“靠感觉”：几个人轮着看一遍模型回答，觉得语句通顺、内容合理，就点头通过。这种方式有两个致命问题：一是每个人的判断标准不一样，有人苛刻有人宽容；二是没有回归测试，今天改了个Prompt，你可能根本发现不了三天前的某个问题已经被改坏了。

所以我们做的第一件工程化改造，是建立一套可重复执行的评估体系。

首先是测试集建设。我们把测试集分成了三类：

• 标准题集：来自真实业务中最常见、最高频的问题，这些问题的答案有明确标准，必须答对。
• 变体题集：把标准题换各种问法、加各种约束条件，比如变换部门属性、换时间范围、叠加多个条件。目的是考察模型在语义变化下能不能保持稳定。
• 对抗题集：故意设置一些超范围、诱导性、上下文不完整的问题。比如问一个完全不在知识库里的话题，或者问“如果老板明确规定不许报销，但大家都这么干，你怎么办”。这类题不看回答得多漂亮，只看能不能识别边界、会不会被带偏。

三类题合在一起，初期我们做了大概一百五十道。数量不多，但每一个都经过人工校准，因为评估集本身就是尺子，尺子不准，后面所有测量都没意义。

其次是评分维度。给模型回答打分的时候，我们从五个角度来评：

1. 正确性：核心事实是否准确，有没有出现知识性错误。
2. 完整性：该回答的点是否都覆盖了，有没有漏掉关键条件。
3. 可追溯性：回答里的内容是否能在知识库里找到依据。
4. 合规性：语气、措辞是否符合企业内部沟通规范，有没有传递危险建议。
5. 稳定性：同一道题多次提问，回答是否保持一致，会不会有时对时错。

每个维度按1到5分打分，最后汇总。我们给每个维度设了最低阈值，任何一个维度不过线，整条答案就算不通过。

3.2 一个典型的版本迭代流程是什么样

有了评估体系，后续的每个改动都走标准流程：

1. 拿到一波线上真实失败案例，人工归纳问题模式。
2. 修改提示词、调整重排规则或者补充知识库内容。
3. 跑一遍完整测试集，对比新旧版本的评分变化。
4. 如果标准题集得分上升、对抗题集得分不下降，才允许进入灰度发布。

这里有个细节容易踩坑：每次改动针对性非常强的时候，模型在这类问题上会变好，但在另外一些问题上的表现可能会悄悄滑坡。没有回归测试，这种滑坡极难察觉。我们第一次回归就发现，某个Prompt改动让报销问题的得分从4.6涨到了4.9，但年假计算的得分从4.7掉到了4.1。后来检查发现，是因为我们在提示词里过度强调了“要严格核对报销标准”，模型给其他计算类问题也套用了报销语境的约束。

这就是为什么要反复强调测试集和回归机制。没有这把尺子，所谓的优化就永远停留在踩西瓜皮的水平，滑到哪里算哪里。

4. 把提示词当代码管，把模型当系统管

4.1 提示词纳入版本管理：告别“改完就上线”

以前我们改Prompt是文档里直接改，改完复制粘贴到线上，几乎没有版本概念。后来团队内部出现了一次事故：某成员为了测试效果，在线上把“系统提示词”临时换了，结果忘记换回来，模型回答风格整整漂移了四个小时才被人发现。

从那次以后，我们就彻底改变了管理方式。所有提示词、示例、路由规则全部像代码一样纳入仓库管理，每一次修改都走提交、评审、合并的流程。有人觉得这个流程太繁琐了，说“Prompt这么轻量的东西，有必要搞这么重吗”？但实际执行下来，这个策略省下的时间远超预期。因为Prompt是极易被随意修改的，但它的影响范围极大，一行字的改动可能影响千万次请求。没有流程管控，线上就是砧板上的一块肉，谁都能砍一刀。

提示：哪怕团队只有两三个人，也建议至少把“谁改的、为什么改、改之前效果如何、改之后效果如何”这条记录链保留下来。AI项目的调试会非常频繁，没有变更记录，过两周你就不知道线上那版配置到底是怎么演化出来的了。

4.2 灰度发布与监控：模型上线不能靠拍脑袋

模型类的系统有一个特点：没有绝对的正确，只有概率上的稳定。这就意味着我们不能像传统功能那样“测完直接全量发布”，必须留一条灰度通道。

我们的做法是分三层灰度：

• 第一层：内部白名单。先让产品、运营、客服几个核心角色体验，收集主观反馈。
• 第二层：小流量灰度。随机抽取5%到10%的线上请求，分配到新版本上，同时关注数据指标。
• 第三层：全量发布。稳定运行两到三天之后，选择业务低峰期进行全量切换。

灰度期间主要盯哪些指标？我们重点关注五个：

1. 调用量：有没有异常突降（可能是服务报错）。
2. Token消耗：有没有异常突增（可能是Prompt设计问题导致长输出）。
3. 用户反馈率：点“有用”或“无用”的比例变化。
4. 人工修正率：客服人工介入修改AI回答的比例，这个指标最能反映真实质量问题。
5. 延迟分布：P50和P95响应时间是否在可接受范围内。

这五类指标里，最需要重视的是人工修正率。因为它直接反映用户对回答不满意的真实比例，而且它是可观测的、可量化的，不像“感觉差不多”那样虚无缥缈。

4.3 团队分工的变化：从“一个人扛”到“一条流水线”

初期的项目组结构非常简单：一个人写代码，一个人调Prompt，另一个人偶尔帮帮忙。但随着方案复杂度上升，这种“全能型选手”模式越来越扛不住。

到后期，团队内部事实上自动分化成了四个角色：

• 知识库管理员：负责整理文档、标注版本、处理文档更新。这个角色不需要太懂技术，但必须非常懂业务。
• 评测工程师：负责测试集建设、评分执行、回归分析。他们成为项目里“质量把关人”。
• 提示词与策略工程师：负责Prompt设计、检索策略调整、重排规则优化。
• 系统工程师：负责整体架构稳定性、监控、部署、成本控制。

这个分工不是某一天开会决定的，而是被问题倒逼出来的。如果你所在的团队还没有到这个规模，也不用着急，但至少要在意识上建立“不同角色关注的事完全不一样”的认知。否则很容易出现所有人都在调Prompt，但没人关心知识库的更新时效性，也没人统计线上回答的修正率。

5. 实用避坑清单：那些文档里不会写的教训

5.1 上下文污染：多轮对话里的“窜味”问题

用户问完一个事，再问另一个看起来毫不相关的事，模型可能还会受到前面对话的影响。这个现象叫上下文污染。我们遇到过一个经典案例：用户先查了“某个长期休假政策”，紧接着又问“如何申请海外出差补贴”，结果模型把休假审批流程套在了出差补贴上，整个逻辑全乱了。

解决方案并不复杂：给对话加一个意图识别前置环节。当用户开启一个新话题时，系统主动清空前几轮的历史记录，只保留和当前话题相关的上下文。对于一般问答场景，甚至可以只保留当前轮次，不需要把整段对话都丢给模型。

5.2 召回阈值设置：太严什么都召不回，太松什么都塞进来

检索阶段如果召回阈值设得太严格，容易把正确的知识块漏掉，模型会因为没有资料而拒绝回答；如果太宽松，无关的知识块也会被送进上下文，模型生成时容易被干扰，反而输出一些似是而非的内容。

我们的实践中，阈值是先通过离线实验确定一个大致的范围（比如相似度在0.3到0.5之间），再结合线上用户反馈逐步微调。重排阶段我们的经验是：不要只按相关度排序，还要考虑文档的权威性和时效性。有些旧版制度文件和新版文件同时存在时，必须让新版优先，否则模型很容易引用到已经作废的条款。

5.3 评估集污染：用测试集当训练集，最后测了个寂寞

这是我们走过的一段弯路。有一次为了让某个新功能快速上线，团队直接把几十道测试题里的标准答案喂进了知识库。结果模型在这些题上的得分全线飘红，大家欢呼雀跃。但真实用户很快反馈：“为什么我问了同样的问题，回答和之前不一样，而且新答案像是直接背课文？”

原因很粗暴：测试集里面的标准答案进了知识库，模型等于是看到答案再答题，这份成绩完全失真。这件事之后，我们给测试集加了隔离：测试集只保存在评测环境，绝不进入知识库或任何线上系统；知识库更新时还会自动检查相似度，避免新旧内容冲突。

5.4 成本控制：算Token这账不能不算

稳定运行之后，成本问题就会浮上水面。我们总结过几个比较实用的控本手段：

• 命中缓存：把相同问题的回答缓存起来，重复问题直接返回缓存结果，不再调用模型。
• 知识召回预筛选：如果检索发现知识库里根本没有相关内容，直接返回“未找到答案”，不再把空白上下文喂给模型生成。
• 轻量模型分流：简单问题用轻量级模型回答，只有复杂问题才调用更大参数的模型。实际上大多数业务问题并不需要满血版大模型来处理。

这几个手段加起来，我们线上单次请求的成本大概比最初下降了四成左右。效果非常明显。

写在训练完这套系统之后的几句真话

现在回头再看那次客户现场翻车，我心里反而是感谢的。如果没有那一场难堪，我们可能还在“多写两句提示词就能让模型变聪明”的幻觉里打转。踩过这么多坑，我个人的体会是：AI落地成功与否，往往不取决于模型本身有多聪明，而取决于你是否愿意为它搭建一套完整的、可评估、可回归、可控制的工作流体系。

最后再分享一个细节：一旦你把评估体系搭好，再往后改任何东西，心里都有谱了。改完跑一遍分数，你自己就知道能不能上，不用再纠结要不要连夜调Prompt。这个过程有点像带新人——刚开始你要反复叮嘱、手把手教，后来你给了他一套明确的工作日志和验收标准，他反而能独立把事情办得很稳。

如果这篇经历能让你少走一点弯路，或者至少让你在听到老板说“把这个AI做得更强一点”的时候，能多一个“先看看测试集分数”的清醒念头，那这次分享就值了。