企业官网建设流程全解析

1. 场景认知与方案设计：为什么存量系统改造要“网关+适配层”

1.1 存量培训系统对AI的诉求，和你想的不太一样

先说结论：存量系统接入AI，技术难点从来不是“模型选哪个”，而是“怎么让一坨跑了五六年的老代码，优雅地接住AI能力，还不把自己搞崩”。

我前阵子正好在帮一家企业做内部培训系统的AI升级。这个系统本身很典型：基于传统B/S架构，后端是Java Spring系，前端是jQuery那一代的老页面，数据库里沉淀了上千门课程、几十万条学员学习记录，还绑定了考试、证书、岗位胜任力评估一大堆模块。说白了，这是一套标准的、业务逻辑复杂的存量系统——不是那种可以推倒重来的创业项目，而是每天都有几百上千人在用的生产系统。

这种系统想接AI，诉求其实非常朴素：

• 课程内容智能化：把存量课程文档自动生成测验题、知识点摘要、学习路径推荐。
• 学习过程智能化：学员在学习过程中随时提问，AI基于课程内容做定向答疑。
• 管理侧智能化：培训管理员用自然语言查询学习数据，比如“帮我统计上季度各部门考试通过率”，而不是去翻报表。
• 考核智能化：让AI辅助批改主观题、面试评分、生成能力评估报告。

这些需求听上去很美好，但真落地的时候，第一个问题就来了：这些功能分散在系统的不同模块里，有的在课程管理端，有的在学员端，有的在管理后台。如果每个模块都各自去对接大模型API，代码会变成什么样子？可以想象，每个模块都塞进去一套Prompt模板、一套API调用代码、一套鉴权逻辑，后续大模型接口版本一升级，全系统到处都要改。这就是最典型的“烟囱式接入”乱象。

1.2 没有网关的直连方式，到底踩了哪些坑

我在项目早期做过一个原型验证，当时图快，直接让各个模块调用大模型API。两周后复盘，问题清单拉出来非常难看：

第一，密钥管理失控。各个模块自己存API Key，有的写在配置文件里，有的干脆硬编码在代码里，还有的因为前端直接调模型接口，Key暴露在浏览器Network面板里。光是安全问题就够喝一壶的。

第二，模型能力不可替换。当时用的AI模型服务，半个月后因为成本或效果问题打算换掉，结果发现更换意味着所有调用方的代码都要动。有的模块用流式输出，有的用非流式，有的传参格式不对，有的解析不了新模型的返回结构，改起来牵一发动全身。

第三，无法统一治理。谁在调用、调了多少次、Token消耗多少、哪些Prompt效果差，全都没有全局视图。出了问题只能挨个模块翻日志。

所以后来我坚定了一个方向：在存量系统和外部大模型之间，必须加一层统一的AI能力网关，再加一层适配层。这两层是整个改造方案的骨架。

1.3 统一AI能力网关的核心作用

打个比方：存量系统是一栋老房子，大模型是外面的自来水厂。你不可能在每个房间里各自打一口井，而是要在房子外面修一个总水表、一套入户管道，再在每个房间装水龙头。AI能力网关就是那个总水表和入户管道——所有AI请求都从这里走，统一鉴权、统一计量、统一限流、统一路由。

网关层具体承担这几个职责：

• 统一入口：系统内所有模块的AI调用，都走网关，不直接碰外部模型API。
• 统一鉴权与租户隔离：内部系统的不同部门、不同角色，在网关层做权限控制，避免越权调用。
• 统一计量与审计：记录每个调用方的Token消耗、调用频次、耗时、成功率，方便成本分摊和后续优化。
• 统一路由与降级：网关可以根据模型服务的健康状态、成本策略、业务场景，把请求路由到不同的大模型，比如复杂任务路由到更强的模型，简单任务路由到便宜的模型。

至于适配层，它的作用更偏“翻译”：把外部各家大模型千奇百怪的API格式，翻译成系统内部统一的数据结构。这样存量系统的业务代码面对的是一个稳定的、符合自身语言习惯的接口，而不是今天适配OpenAI、明天适配国产模型的“API追新”噩梦。

2. 网关层落地实践：从Route到Fallback的完整设计

2.1 网关要做的六件事，缺一不可

先说网关的整体架构。我采用的是独立部署的微服务，不嵌入存量系统内部，而是作为一个独立的AI接入服务，和存量系统通过内部HTTP或gRPC通信。这样做的好处是，网关可以独立扩容、独立升级，不会影响存量系统的稳定性。

网关内部六个核心模块，各司其职：

路由模块：根据请求中的业务场景标识（比如course_generate、exam_question、chat_qa），决定把请求发往哪个模型服务。路由策略支持三种：按固定配置路由、按权重路由（比如新模型先接10%流量）、按规则路由（比如长文本走大上下文模型，短文本走快速模型）。

协议转换模块：把内部统一请求协议转换成外部模型API的协议。这个大模型接口是OpenAI格式，那个是百度千帆格式，另一个可能是阿里百炼格式，协议转换全部收敛在这一层。下游感知不到差异。

鉴权与限流模块：网关对外部请求做身份校验，校验通过后，再根据调用方的AppId和业务场景做限流。限流策略是令牌桶算法，基础容量按业务峰值1.5倍配置，比如培训系统平时每秒最多10个AI请求，我配置的就是每秒15个令牌，突发允许到每秒20个。

缓存模块：对重复性高的请求做结果缓存。比如“课程《Excel进阶》的知识点摘要”这种请求，内容是静态的，没必要每次都让模型重新生成。缓存key是“业务场景+模型版本+Prompt版本+输入内容的哈希值”，有效期根据内容类型设定，课程摘要类可以缓存一整天，答疑类不缓存。

审计与计量模块：记录每一次请求的完整链路信息，包括调用方、模型、Prompt摘要、Token消耗、耗时、状态码。这些数据一方面用于成本核算，另一方面用于后续模型效果对比——比如切换模型后，同一批请求的成功率和输出质量有没有变化。

熔断与降级模块：这是网关最关键的保命机制。外部大模型偶尔会超时、限流或者直接崩溃，网关必须能在这种情况下保护存量系统。我用的是连续失败熔断策略：比如某条路由连续10次请求失败（超时或5xx），熔断器打开，后续请求直接走降级逻辑——返回缓存结果、返回兜底内容或者转路由到备用模型，就不再傻等外部服务。

2.2 路由表的数据结构设计

路由表是整个网关的中枢配置，我用一个JSON配置来管理，存配置中心里，改配置不用重启服务：

{ "routes": [ { "scene": "course_summary", "model": "qwen-plus", "provider": "aliyun", "temperature": 0.3, "max_tokens": 2000, "timeout": 12000, "fallback": ["qwen-turbo", "local-rule-based"] }, { "scene": "chat_qa", "model": "deepseek-chat", "provider": "deepseek", "temperature": 0.5, "max_tokens": 3000, "timeout": 30000, "fallback": ["qwen-plus", "default-dialogue"] }, { "scene": "exam_generation", "model": "gpt-4o", "provider": "openai", "temperature": 0.7, "max_tokens": 4000, "timeout": 60000, "fallback": ["qwen-max"] } ], "app_credentials": { "training-web": "ak_****", "admin-console": "ak_****" } }

每个业务场景都对应一个路由条目，里面不光指定了模型，还指定了温度、最大Token数、超时时间和fallback顺序。这个设计的妙处在于：业务方根本不用关心底层是哪个模型，只需要知道自己是什么场景。比如“考试出题”这个场景想换更强的新模型，只需要去配置中心改一行，所有调用方自动生效。

2.3 流式输出的统一封装

存量培训系统的答疑场景，如果AI回复要等十几秒才能一次性返回，那体验是灾难级的。必须上流式输出（SSE）。

但问题来了：OpenAI的流式是text/event-stream，百炼的是data: {...}\n\n格式，不同家的流式格式有小差异；存量系统前端还是老jQuery那套，对SSE的原生支持几乎为零。

适配层的处理方式是从网关层就把流式统一掉——网关内部向上游模型请求流式，剥离各家协议的差异后，再以统一的SSE格式返回给存量系统。各个业务模块只需要按标准SSE协议处理就行。

存量系统对接时不用引入复杂的SSE客户端库，一个简单的EventSource就够了。为了让老浏览器也能兼容，我还加了一层降级：如果网关在3秒内检测到客户端不支持流式（连接断开或请求头没有Accept: text/event-stream），自动切换为非流式一次性返回。

3. 适配层关键细节：让老系统“无痛”调用新能力

3.1 适配层到底在翻译什么

网关解决的是“请求该往哪儿发”，适配层解决的是“业务代码该怎么写”。存量系统的业务代码不应该写任何和某个大模型相关的代码，它面对的应该是一套符合自身系统习惯的AI服务接口。

我设计了一个统一的AI服务接口，长这样（Java伪代码）：

public interface AiService { // 生成类任务：摘要、出题、报告 AiResult generate(AiRequest request); // 对话类任务：答疑、多轮交互 AiStreamResult chatStream(AiRequest request); // 嵌入类任务：向量化，用于相似度检索 AiResult embed(AiRequest request); } public class AiRequest { private String scene; // 业务场景，如 course_summary private String prompt; // 业务方组装好的Prompt private String modelHint; // 可选，调用方想指定模型偏好 private Integer maxTokens; // 可选，默认走路由表配置 private Double temperature; // 可选，默认走路由表配置 private Map<String, String> meta; // 扩展字段，如用户ID、课程ID }

所有存量模块只需要依赖这个接口，由适配层去实现具体逻辑。适配层内部做三件事：组装最终Prompt、调用网关、解析网关响应并转化成业务对象。

3.2 体系化Prompt管理：模板不是写死，而是配置化

这里是我个人认为最容易被忽视、但实际收益最大的一个设计：Prompt模板的配置化治理。

一开始各个模块都自己拼Prompt，拼出来的东西五花八门。后来我统一做了一个Prompt模板管理表，存在数据库里，每条模板有版本号、所属场景、模板内容、变量占位符。

举个例子，课程摘要的模板长这样：

你是一位企业培训讲师，擅长提炼课程核心知识点。 请根据以下课程大纲和讲义内容，生成一份简洁的知识点摘要。 要求： 1. 按要点列出，不超过6个要点； 2. 每个要点用一句话概括，不超过50字； 3. 输出格式为Markdown列表。 课程名称：{{courseName}} 课程内容： {{courseContent}}

模板里的{{courseName}}、{{courseContent}}是占位符，适配层在运行时用实际数据替换。模板版本和模型版本是绑定的，每次更新Prompt模板都会带上版本记录，这样如果效果变差了，可以随时回滚到上一版。

这里面我有一个重要经验：Prompt模板不要只放在代码里，一定要放到配置中心或数据库里。因为业务人员（培训运营）经常会想调整语言风格或要求，如果模板改动需要开发发版，节奏上双方都痛苦。模板配置化之后，运营自己都可以试参数。

3.3 长文本处理和知识库检索的落地

培训系统里有个刚需：AI基于特定的课程内容回答学员问题。这里牵扯到一个很实际的技术问题，课程讲义动辄几万字，直接全量塞进Prompt，模型吃不下也费钱。我的方案是经典的“离线切开+在线检索”：

离线处理流程：

1. 课程文档上传后，系统自动解析提取正文。
2. 按固定窗口大小做切分，我一般按512个字符切一段，重叠64个字符，避免把一句话拦腰截断。
3. 每段调用嵌入模型做向量化，存入向量数据库（用的开源方案，部署在内网）。

在线处理流程：

1. 学员提问，先对问题做向量化。
2. 在向量库做相似度检索，取Top5最相关的片段。
3. 把检索结果作为上下文，和问题一起组装Prompt，调用模型回答，要求模型“仅基于提供的资料回答”。

这里有个细节经验：检索的相似度阈值一定要调。太严格了召回不到资料，模型容易胡编；太宽松了塞进无关内容，模型容易被带偏。我这边最终把阈值定在0.72左右，供你们参考，实际按语料的情况调。

3.4 记忆与多轮对话：别让老系统背新债

答疑场景必须支持多轮对话，但存量系统之前没有会话管理能力，我不建议为了AI功能去大改老系统的会话架构。适配层做了轻量级的解决：网关侧保存最近的10轮对话历史（作为上下文），业务侧只传当前的用户输入。

具体实现上，每个会话会生成一个sessionId，适配层用Redis存储该会话的历史消息列表。每次请求时，适配层取出最近10条消息，拼装成多轮对话的消息数组，再连同新问题一起发给模型。多轮回复结束后，把新问答追加进Redis。这个方案的好处是存量系统不需要做任何会话状态的改造，业务模块只需要存一个sessionId即可。

4. 上手实操：一个最小可用接入方案，从0到1的完整路径

4.1 这套方案的技术栈选型和建议

如果你也想给自己的存量系统做AI接入，我建议不要把架构搞得过于复杂。一个可以跑起来的最小架构只需要四个部分：

• 存量系统侧改造：加一个AiService接口和对应实现，把所有AI调用从业务代码中剥离出来。
• AI能力网关：独立服务，开源网关可以直接用Spring Cloud Gateway二次开发，或者APISIX这类七层网关加上自定义插件。我自己是拿Spring Boot写了一个轻量级网关，因为需要深度定制路由和熔断逻辑。
• 模型服务：优先用一个主流大模型API起步，同时申请一个备用模型（国内和国外各一家），验证路由切换能力。
• 向量存储：数据量不大的话，可以用开源的向量库，单机部署足够。

技术选型上有个注意事项：优先用你团队熟悉的技术栈去实现网关和适配层。这个方案的难点不在技术新潮，而在稳定接缝，别在存量系统改造中引入太多需要团队重新学习的东西。

4.2 两周内可以跑通的任务拆解

我把整个落地过程拆成几个阶段，每个阶段有明确的交付物，方便你照着排期：

第一周：搭建网关骨架和统一接口

• 搭建网关服务工程，实现路由、鉴权、审计三个核心模块。
• 封装AiService统一接口，先在存量系统里找两个最简单的场景切入。
• 联调通过，跑通第一条AI请求全链路。这一步的核心目标是验证“存量系统代码不直接碰模型API”这个约束有没有被执行到位。

第二周：适配层完善和场景扩展

• 完成默认大模型和备用大模型的适配器开发，实现故障自动切换能力。
• 上线Prompt模板管理，把存量场景的模板全部配置化。
• 完成缓存和限流策略配置。
• 扩展接入3-5个核心业务场景，比如课程摘要、自动出题、智能答疑、学习报告生成。

这个节奏是经过验证的，只要团队里有一到两个熟悉Spring系开发的人，完全可以在两周内让老系统真正“长”出AI能力。

4.3 数据埋点与效果评估

还有一个容易被忽略的环节：AI功能上线只是开始，效果评估才是闭环。

我在网关的审计模块里，除了记录Token和耗时之外，还让存量系统在展示AI结果时，悄悄埋了一个“有用/无用”的反馈按钮。学员点“有用”或“无用”后，反馈数据会回传到审计库里，这样我就能追踪到每个场景、每个模型版本、每个Prompt版本的实际效果。

比如我发现，某门课程的答疑场景，学员点“无用”的比例显著高于平均水平。拉出日志一看，是这门课程的讲义切分质量太差，向量检索到的内容不相关。调整切分逻辑后，无用比例下降了30%以上。没有埋点反馈，这种问题光靠技术和人工都很难定位到具体课程。

5. 常见问题与排障实录

5.1 问题速查表

我按整个项目周期遇到的真实问题，整理成了一个速查表：

5.2 两个最值得注意的坑

坑一：千万不要相信大模型API文档里的返回格式。

我接入某国产大模型时，文档上写的是标准OpenAI格式，真跑起来发现流式的数据分隔符和OpenAI不同，有一个字段名称也不一样。如果没有适配层统一兜底，业务代码全得跟着返工。所以适配层里每种模型都做一套独立解析逻辑，用单元测试固定住返回格式的兼容性。

坑二：Redis缓存穿透问题在AI场景里会被放大。

答疑场景里如果大量的问题都是新的，缓存扛不住，每次都穿透到模型服务，Token成本直接失控。后来我不仅对最终结果做了缓存，还对向量检索结果做了缓存，同一门课程的相似问题不再重复检索。这个优化让API调用量下降了接近一半。

6. 演进路线：从“能用”到“好用”

到这一步，网关+适配层已经让培训系统稳定跑起来了。接下来可以往两个方向演进：

一是引入智能体（Agent）能力编排。纯粹的单次问答价值有限，但把AI从“单次对话工具”升级成“业务流程执行者”后，价值完全不一样了。比如“新员工入职后自动生成90天学习计划”这个需求，网关的AI能力只负责内容生成，真正让它自动跑起来，还需要配合业务流程编排，去拉取岗位数据、调用课程库、生成学习路径、推送任务。这就是智能体干的活。

二是把网关升级成企业内部统一的AI中台。现在只是培训系统在用，但公司内部还有其他系统——客服、知识库、办公协同——都在观望。网关的技术底座是通用的，后续其他系统接入的成本比从零开始低很多。到时候，整个公司的AI能力入口统一收口，模型选型、成本控制、效果评估都能在公司层面闭环管理。

这次“存量培训系统AI升级”的项目，我最大的体会是：AI改造的成败，很多时候不取决于模型的聪明程度，而取决于系统架构的整洁程度。一套好的接入方案，能让业务方无感地享受模型升级带来的能力提升；而一套糟糕的接入方案，会让每一次模型切换都变成一次伤筋动骨的重构。

如果你也正在折腾存量系统的AI改造，我建议第一件事不是选模型，而是先把“所有AI调用必须经过统一网关和适配层”这条纪律定下来，然后让全组人背熟。规矩立住了，后面的事情都是水到渠成。