企业官网建设流程全解析

我常跟做开发和运维的朋友说一句话：别急着把大模型当成写文案、聊天、画图的工具，它真正能发挥巨大价值的地方，是你手里那些老系统、老规则、老流程。最近我正好做完一个很典型的项目，标题很直白——我用大模型把两套传统体系装进了AI。这里的“两套体系”，不是指两套软件，而是指几乎所有传统企业里都有的两样东西：一套是跑了几十年的业务规则体系，另一套是让系统能稳定运行的支撑运维体系。这篇文章就把我这个项目从设计到落地、从踩坑到调优的完整过程全盘托出，给想干类似事情的朋友一个可以直接落地的参考。

项目本身不复杂，难的是思路和细节。我不拉大旗，直接讲我做了什么、为什么这么做、哪些地方必须注意，看完你至少能知道该从哪下手。

1. 项目核心：到底哪两套传统体系，为什么非要“装进AI”

1.1 所谓两套传统体系，具体指什么

先说业务规则体系。传统企业里，业务规则往往不在代码里，也不在数据库里，而是散落在制度文档、岗位操作手册、历史工单、培训PPT啊、老师傅的备忘录里。比如某公司老旧的审批流，什么金额超过多少要走到哪一级；某个财务核算规则，遇到什么科目组合怎么处理；某些库存调拨的边界条件，什么情况能自动过、什么情况必须人工介入。这些规则是真金白银的经验，但问题是，它零散、模糊、更新缓慢，新人根本学不完，老员工也讲不全。

再说支撑运维体系。这是传统技术团队内部的一套运作规则：系统告警怎么分级、谁负责响应、应急预案要执行到什么程度、日志排查按什么顺序、多久巡检一次、什么状态下能重启服务。这些规则通常存在于内部的运维手册、值班记录、故障复盘文档里，甚至很多还装在老员工脑子里。它们不是标准化的代码逻辑，很难被新系统直接调用。

1.2 为什么要把它们“装进AI”

很多团队已经做过知识库，把文档传到一个系统里就算完了，结果发现没人用。原因很简单：传统知识库只能搜索，不能推理。你想查“某个金额以下走简易审批流程”，得自己先知道关键词，再去翻几份文档拼凑结论。而大模型的核心能力恰好是语义理解和逻辑推理，它可以把几十条分散的规则片段，组合成一条准确的回答。把这两套体系“装进AI”，本质上是把散落在各处的业务知识和运维经验，转成一种可持续积累、统一调用、带推理能力的服务。

这样做好处非常明显：新人培训周期大幅度缩短，老师傅不用反复被问同样的问题，运维响应不再依赖某个人在不在现场，业务规则变更时只需要更新知识源，不用重写整个系统。这就是我做的这件事的底层价值。

2. 整体设计思路：先拆体系，再选路线

2.1 拆体系的三个层次：规则、流程、数据

动手之前，我必须先把“两套体系”拆到可以落地的粒度。实际项目中，我按三个层次拆解：

• 规则层：业务的判断条件、阈值、边界。这是最核心的知识，比如“金额10万以下由部门负责人审批，10万到100万由分管领导审批，超过100万上会”。
• 流程层：一个请求从进入系统到结束要经过哪些环节，每个环节的输入输出是什么。比如告警出现后，是先查日志还是先捞指标。
• 数据层：各个体系里真正用来做判断的数据源。比如审批单的金额字段、设备的运行指标、历史工单的类别标签。

拆完之后，我得到一个结论：这两套体系本质上都是“规则 + 动作”。规则告诉你什么时候触发什么动作，动作的结果又会反过来影响下一条规则。想用大模型把它们装起来，就必须让模型既理解规则，又能执行动作。只做问答是不够的，必须能做调用。

2.2 为什么最终选了“知识库检索 + 工具调用”而不是微调

大模型落地方案无非几条路：直接让模型靠记忆回答、微调模型、用知识库检索增强、给模型配工具调用。很多人一听项目名称，第一反应是“你是不是微调了一个模型”。不是，我也强烈不建议一上来就微调。

原因很直接。微调适合让模型学习固定的表达风格或者特定的输出格式，但业务规则是高频变化的。今天审批金额阈值变了，明天告警级别标准变了，如果每次变动都要重新训一遍模型，成本极高且周期很长。而且微调很容易把新规则学进去了、把旧规则忘了，规则之间产生冲突时模型根本说不清楚依据是什么。

所以我最终采用的技术架构是“双模驱动”：先利用检索增强生成（RAG）把规则片段捞出来，再通过函数调用（Function Calling）让大模型调用具体工具去执行动作。简单说，模型的角色不是背答案的人，而是“读资料的人 + 发指令的人”。资料来自身后挂载的知识库，动作来自一套标准化工具接口。

这个架构最大的优势是：规则变了，改知识库里的文档即可；动作变了，改工具接口即可。模型本身没有承载任何不稳定的事实记忆，输出全都有源可查。

2.3 整体数据流设计

我做了一张流程图（文字版）方便大家理解：

传统规则文档和运维手册 -> 解析与清洗 -> 规则快照库 -> 向量索引 -> 大模型检索 -> 结合用户问题生成回答；同时，用户问题 -> 意图识别 -> 工具调度 -> 返回实时数据 -> 大模型组合结果。

这个设计解决了一个很关键的问题：大模型不直接去读数据库，也不直接去连老系统，所有数据都通过工具接口间接获取。这样老系统不需要开任何直连权限，安全性大幅提高，出问题也好排查。

3. 关键技术选型与参数配置

3.1 选型考虑：不是越新越好，是越稳越好

这个项目里我不追新，选型原则就一句话：团队能维护、故障能处理、替换成本低。具体选型如下：

• 主体大模型：选用国内可用、上下文比较长、支持函数调用的开源商用模型均可。我实际用的模型支持8K到32K上下文，对规则问答和工具调度足够。
• 向量库：用轻量级方案。数据量不大，几千条规则片段，不需要上重型分布式引擎。我选了部署简单的方案，用容器跑，内存占用小，备份方便。
• 解析工具：老文档不少是Word格式、PDF格式、还有截图式PPT。解析工具用Python生态里的现成库，配合一个可配置的规则模板，把非结构化文本转成JSON结构。
• 编排框架：用流程引擎把“解析-索引-检索-调用-生成”串起来。我倾向于用轻量的异步任务队列，避免重框架。

这里特别强调一个点：不要迷信“企业级”三个字。很多重型框架光安装配置就要一周，出了问题组件之间互相推诿版本兼容问题，非常痛苦。团队能把轻量方案吃透，比上一个没人会维护的重平台强得多。

3.2 关键参数：分块大小、重叠、召回数量、置信度阈值

这部分是项目落地时最容易踩坑的地方，我直接把参数列出来，并说明我当时是怎么调的。

• 分块大小：规则文本不像小说那样连续，它经常是一段话里包含多条规则。我最终将chunk_size设为500个字符左右。太小了，一条完整的规则被截断，模型拼不回来；太大了，一个块里规则太多，检索噪音变大，召回精度下降。
• 重叠：重叠区块设为50个字符。主要为了防截断——如果一条规则正好横在两块之间，没有重叠就会被切成两半。这个值不需要精确，关键是存在。
• 召回数量：单轮检索默认召回3个块。业务规则问题通常答案就藏在1-2个块里，取3个是为了补全上下文。但不要贪多，取10个块会引入大量不相关内容，模型反而容易错误组合信息，把自己绕晕。
• 置信度阈值：低于阈值时不采用检索结果，直接让模型承认不知道。这个非常重要。传统规则出错的代价很高，不知道比瞎猜安全得多。我设置的阈值最终调到了0.55，经过验证，在保证回答率的情况下有效控制错误率。

这些参数不是一次调出来的，我后面会讲具体怎么测。但方向一定是：先定指标，再调参数，不要靠感觉。

4. 实操过程：从旧文档到AI问答与自动调度

4.1 第一步：梳理原材料，做规则快照

第一步不是写代码，是做信息架构。我把所有相关业务文档和运维手册集中到一起，先人工快速翻一遍，标记出哪些条目是“规则”，哪些只是描述性内容。这一步大概花了两天，产出是一张Excel表，每一行对应一条规则，字段包括：规则编号、所属体系（业务/运维）、触发条件、执行动作、生效范围、更新日期、原文档位置。

有了这张表之后，我写了脚本做规则快照：把每条规则抽取出来，生成固定结构的JSON。举个例子：

{ "rule_id": "BR-0012", "category": "approval_process", "trigger_condition": "申报金额 >= 100000 AND < 1000000", "action": "由分管领导审批，审批时限为两个工作日", "scope": "销售部门及采购部门", "source": "管理规范文件V5.2，第8.3节", "effective_date": "2024-01-01" }

这步很重要，因为大模型最怕引用混乱的信息源。规则快照相当于给模型一份“规范字典”，每条规则都有编号、来源、生效日期。模型回答时如果被问到“这个规则现在还有效吗”，它可以直接调用快照里的时间字段做判断。

4.2 第二步：构建检索库和问答链路

快照生成后，我把JSON序列化成自然语言文本，再送去分块和向量化。结构化数据转成自然语言是必要的，因为用户提问通常很口语化，比如“十万块的项目要不要上会”，而JSON里存的是“金额 >= 100000”，两者直接算相似度效果很差。转成自然语言后，文本变成“规则条目：业务规则编号BR-0012，针对销售部门和采购部门，当申报金额大于等于10万元且小于100万元时，需要提交分管领导审批；有效起始日期为2024年1月1日”，这样跟用户问题的语义距离近得多。

问答链路我是这样设计的：

1. 用户输入问题。
2. 系统同时做两件事：一是把问题向量化去检索规则块，二是做意图分类，判断这个问题是需要查规则、查数据，还是需要执行某个动作。
3. 如果只是查规则，就把检索到的块拼接进提示词，让模型基于块内信息生成答案。
4. 如果需要查数据或执行动作，就先把用户问题里的关键参数抽出来，走工具调度，拿到结果后回填给模型。

这里最核心的提示词模板，我贴一个简化版：

你是一个企业内部规则助手。请仅依据提供的规则片段回答用户问题。 规则片段： {context} 用户问题：{question} 要求： 1. 如果规则片段没有覆盖该问题，请明确回答“当前知识库中没有相关规则”。 2. 回答时说明规则依据的编号。 3. 不需要推测或补充不存在的信息。

这个提示词看着很朴素，但效果非常稳。它扼住了大模型最容易犯的问题：被问到一个不在知识库里的问题，强行编规则。

4.3 第三步：把第二套体系变成“可调用工具”

业务规则问答只是第一套体系，运维支撑体系才是让系统真正有价值的地方。我选了三个高频运维动作做成工具接口：

• 查询服务状态：入参服务名，返回当前进程状态、最近5分钟错误日志数量。
• 查询故障预案：入参故障类型，从预案库返回对应处置步骤。这个接口背后的数据就是传统运维手册的预案部分。
• 提交工单：入参类型、标题、描述、影响范围，调用老系统接口创建工单。

每个工具都定义了明确的JSON Schema，大模型根据用户问题决定调哪个工具、填什么参数。比如用户问“支付服务最近报错多吗”，模型识别出“支付服务”是服务名，“最近报错多吗”是对应查询状态工具，于是生成如下调用：

{ "tool": "query_service_status", "params": { "service_name": "payment-service", "error_window_minutes": 5 } }

这就是“装进AI”的第二层含义：模型不只是会回答，还能触发执行。运维人员对着这个系统说一句话，告警日志查了、预案调出来了、工单也顺手提了，整个链路全部自动化。

4.4 第四步：评估与迭代调参

系统写完根本不算完，我花了一周做评估。准备测试集，从真实工单和经常被问到的问题里选了200条，分成两组：一组是规则问答，另一组是工具调度。对每组，我都让系统输出结果，再由人工标注正确/错误。我定义的核心指标只有两个：

• 准确率：回答内容和规则或工具结果是否一致。
• 覆盖率：系统能正确回答的有效问题比例。

第一轮测试结果很不理想，准确率只有70%左右。原因分析下来主要有三个：

• 一是分块太大，一个块吃到两条不同规则，模型混淆了适用范围。
• 二是提示词里没有强调“未命中就拒绝”，模型在规则边缘问题上会脑补。
• 三是工具调用时，参数抽取不稳定，比如“最近5分钟”被识别成“最近5天”。

调整思路是：分块大小从800降到500，重叠从100降到50；提示词强化拒绝指令；工具参数识别加了一步“参数合法性校验”，模型抽完参数后先校验再调用，不合格就让用户澄清。第二轮测试准确率到了91%，覆盖率约83%。剩下一部分无法覆盖的问题，主要是规则确实不在知识库里，这个正确，不需要强求100%。

5. 实施过程中踩到的坑与排障实录

5.1 问题一：模型一本正经地编造不存在的规则

这是最让人头大的问题。比如知识库里只有一条规则“金额10万以下由部门负责人审批”，用户问“金额8万由谁审批”，模型回答正确。但用户问“金额50万由谁审批”，知识库里没有对应规则，模型居然答出了“由总经理审批”——明显是瞎编。

排查思路不复杂：定位到是提示词没有做防御性约束。加了一句“如知识库未覆盖，必须说明无相关规则”，同时把检索结果的置信度阈值加上。这之后编造现象基本消失。但注意，添加阈值后“未找到规则”的回复次数增加了，这是可以接受的，宁可答不上来也不能答错。

5.2 问题二：检索到的规则和用户问题完全不相关

有一次用户问“采购合同终止处理流程”，系统却回答了“货物验收规则”。我排查发现是向量检索的召回逻辑出了问题——问题里的“终止、处理、流程”都是抽象词，跟“验收规则”的文本在向量空间里距离意外近。

解决办法是给知识库加了“规则类别”元数据，检索时先过滤再排序，用户问题先做一次粗分类，直接锁定“合同管理”这个类别，再去该类别下检索。相当于把全局检索改成了分桶检索，准确度提升非常明显。这个经验对规则数量多的场景尤其适用。

5.3 问题三：工具调用参数抽取不稳定

模型抽参数这件事，本质上还是概率生成，不是严格解析。我遇到过用户说“看看支付服务咋样了”，模型没生成任何参数，直接空调；也遇到过把“支付”当成服务名，实际服务名是“payment-core”。这是“中文别名”和“内部标识”之间的映射问题。

最终方案是两步走：第一，给模型提供一份服务名映射表，直接放进提示词或让模型先查映射接口；第二，对所有抽出的参数做一次校验，不符合枚举值、格式不对、时间区间异常的直接拒绝并反问用户。经过这两步，工具调用失败率从原来的15%左右降到了2%以内。

5.4 另列一份避坑速查表

6. 量化效果与个人经验总结

6.1 上线之后，我统计了几组数据

整个系统上线运行三个月后，我拉了几组数据出来。先说业务规则问答场景：一线运营人员提问题后，系统能直接给出含规则编号的答案，2分钟内解决问题。相比以前要找制度文档、问上级、翻群记录，单次问题处理时间从平均45分钟降到2分钟。每天能处理的咨询量从几十条提升到几百条，而且回答口径统一，再也不会出现“两个人给出两个答案”的情况。

再说运维支撑场景：值班人员每天做例行巡检时，直接问系统“今天有什么异常告警”，系统自动查询并汇总异常项。出现告警时，系统先自动查预案、查服务状态，再生成处置建议，值班人员确认后一键提交工单。这个流程走完平均需要40秒，而以前人工做完这几个动作至少15分钟。上线以来，真正由系统准确识别并触发预案的告警处理占比大概三分之一，其余由值班人员判断后人工干预。

最后是维护成本。两个多月里，业务规则发生过三次调整，我每次只需要更新对应的规则文档，重新跑一遍解析索引，十几分钟完成。这让我非常确信，这种“内容即代码”的方式是传统体系接入AI的可行路径。

6.2 我个人在实际操作中最深的几点体会

第一，项目成败的瓶颈从来不是模型能力，而是规则梳理能力。函数调用、向量检索这些技术细节都有成熟方案，但把散落在人脑和文档里的规则整理成结构化的快照，需要极其细心且熟悉业务的人去做。这个工作偷懒不得，后面所有效果都建立在这个基础上。

第二，要把“拒绝回答”当成一种正常能力来建设。很多团队上来就让大模型尽量答，追求回答率，结果错误答案污染用户信任。我最后的策略是：让系统在无法回答时明说不知道，并提供人工咨询入口。用户反而更信任这个系统。

第三，工具调用的边界要克制。只开放最高频、最安全、参数最明确的几个动作。一开始就想把所有老系统接口都接进来，只会让模型陷入参数灾难。优先做两三个有实际强需求的动作，跑通了再扩。

我目前的规划是继续给这个体系增加“规则变更影响分析”能力——当某条规则更新时，自动找出所有关联的旧规则和历史工单，提示可能有影响的范围。这个方向做好了，传统体系的持续演进能力会上一个新台阶。