企业官网建设流程全解析

1. 从一个真实困境说起：为什么“能跑起来的 AI Demo”和“能上线的 AI 应用”之间隔了一整个团队

过去一年多，我参与过好几个企业内部的 AI 落地项目，从最开始的“拿个大模型 API 写个问答机器人”，到后来要给业务部门交付一套真正能用的智能应用，中间踩的坑几乎一模一样。最开始大家都很乐观：不就是调个接口、套个界面吗？两周就能上线。结果真到了要交付的时候，问题全冒出来了——模型调用散落在各个业务代码里，换个模型要改十几个文件；提示词版本混乱，运营改了一版效果变差，想回滚发现根本没记录；权限、审计、限流、计费这些企业级需求，一个都没有；更别提多租户、数据隔离、灰度发布了。

这就是我理解QuickBlue这类AI 应用底座出现的根本原因。它不是又一个“大模型套壳工具”，而是把 AI 能力当成企业里的一等公民，用工程化的方式把它管起来。你可以把它想象成企业内部的“AI 中台操作系统”：上层业务只管提需求，下层模型、提示词、知识库、工具调用、权限、监控这些脏活累活，全部由底座统一兜住。

这篇文章我想聊的不是 QuickBlue 某个具体功能的说明书，而是从一线落地视角，把“AI 应用底座”这件事拆开讲透：它到底解决什么问题、核心架构怎么设计、微服务这套东西为什么又派上了用场、Spring Cloud 和 Vite 在其中扮演什么角色、实操时有哪些坑。如果你正在负责企业 AI 落地，或者是个想往 AI 工程方向走的开发者，这篇应该能帮你少走不少弯路。

2. AI 应用底座到底是什么：把“模型能力”变成“企业资产”的那层东西

2.1 先搞清楚它不是什么

很多人第一次听到“AI 应用底座”，第一反应是“哦，就是个大模型管理平台吧”。这个理解只对了一半，而且是最容易误导人的那一半。我见过不少团队花大力气搭了个模型管理后台，能切换 GPT、能配 API Key、能看调用量，然后就觉得底座建好了。结果业务方要做一个“合同智能审查”应用，发现还是得从零写一遍：知识库要自己接、审查规则要自己写、审批流要自己串、权限要自己控。模型管理平台只解决了“调用哪个模型”，没解决“怎么把模型变成业务能力”。

所以我的定义是：AI 应用底座是一套把模型、提示词、知识、工具、流程、权限、监控统一抽象并标准化输出的工程基础设施。它的核心价值不在于“接了多少模型”，而在于“让业务团队用统一的方式消费 AI 能力，并且这些能力是可复用、可治理、可演进的”。

2.2 它和传统中台的区别在哪

传统业务中台抽象的是“用户中心”“订单中心”这类确定性能力，输入输出是稳定的。AI 应用底座抽象的是“不确定性能力”——同一个提示词，今天和明天的输出可能都不一样；同一个模型，换个版本效果可能天差地别。这就决定了底座的设计逻辑完全不同：

• 版本必须可追溯：提示词、模型配置、知识库切片策略，任何一环变了都要能定位到是哪次变更导致的效果波动。
• 效果必须可评估：不能只看“调用成功”，要看“回答质量”，所以底座里通常要内置评测集和 A/B 对比能力。
• 成本必须可计量：Token 是要花钱的，哪个部门、哪个应用、哪个用户用了多少，必须算得清清楚楚。
• 失败必须可降级：模型超时、限流、返回异常，业务不能直接崩，底座要有兜底策略。

这四点，是判断一个东西是不是“真底座”的试金石。只做模型接入的，叫网关；把这四件事都做了的，才配叫底座。

2.3 为什么现在企业特别需要它

我观察下来有三个推力。第一是模型迭代太快，今天用这个，下个月可能就换那个，如果业务代码和模型强绑定，每次换模型都是一次重构。第二是AI 应用数量在涨，一个企业从 1 个 AI 应用变成 20 个，如果没有统一底座，就是 20 套重复的轮子，维护成本指数级上升。第三是合规和成本压力，数据不能随便出、Token 不能随便烧，这些都需要在底座层统一管控，而不是指望每个业务团队自觉。

QuickBlue 这类产品的定位，本质上就是回应这三个推力。它把“AI 能力消费”这件事标准化，让业务团队专注在业务逻辑上，而不是重复造 AI 基础设施的轮子。

3. 核心架构拆解：微服务为什么又成了 AI 底座的合理选择

3.1 从单体到微服务的必然性

有意思的是，AI 应用底座这个新物种，最后落地时用的却是微服务这套“老架构”。我一开始也觉得奇怪，AI 不是讲究轻量、快速吗？后来想明白了：底座要同时服务几十个业务应用，每个应用的流量特征、模型偏好、数据敏感度都不一样，单体架构根本扛不住这种异构需求。

举个具体例子。一个底座里通常有这么几块能力：模型网关、提示词管理、知识库检索、工具调用编排、权限审计、计费统计。这几块的负载特征完全不同——模型网关是 IO 密集型，要扛高并发；知识库检索是计算密集型，要做向量相似度计算；计费统计是写密集型，要保证不丢数据。如果全塞在一个进程里，任何一块出问题都会拖垮整体，扩容也只能整体扩，非常浪费。

微服务化之后，每块能力独立部署、独立扩容、独立降级。模型网关扛不住了加网关实例，知识库慢了加检索节点，互不影响。这就是为什么 QuickBlue 这类底座普遍采用微服务架构，而不是一个“大而全”的单体应用。

3.2 一张典型的底座微服务架构图长什么样

我不画图，用文字把典型分层说清楚，你脑子里能拼出来：

• 接入层：统一 API 网关，负责鉴权、限流、路由、协议转换。所有业务应用只跟这一层打交道。
• 能力层：模型网关服务、提示词服务、知识库服务、工具编排服务、会话管理服务。每个都是独立微服务。
• 治理层：配置中心、注册中心、链路追踪、日志聚合、指标监控。这层是微服务的“神经系统”。
• 数据层：向量数据库、关系库、缓存、对象存储。不同服务按需访问，不共享库。
• 控制台层：给管理员和运营用的 Web 界面，通常前后端分离，前端用 Vite 构建。

这个分层的关键在于能力层每个服务只干一件事。模型网关只管“把请求发给正确的模型并处理返回”，它不关心提示词怎么组装；提示词服务只管“版本管理和变量渲染”，它不关心模型是谁。职责单一，才能独立演进。

3.3 Spring Cloud 在底座里的真实角色

热词里出现了spring cloud、spring cloud alibaba停更了、spring cloud sentinel datasource redis集群这些，说明大家很关心技术选型。我说说我的实际判断。

Spring Cloud 这套东西在 AI 底座里主要解决三个问题：服务注册发现、配置管理、流量治理。服务注册发现让几十个微服务能互相找到；配置管理让模型参数、限流阈值能动态调整不用重启；流量治理（Sentinel 那套）让模型网关在突发流量下不被打垮。

关于spring cloud alibaba 停更这个事，我的看法是：不用恐慌，但要清醒。Spring Cloud Alibaba 的很多组件确实进入了维护模式，但这不代表你不能用。企业选型时更稳妥的做法是：核心治理能力优先用 Spring Cloud 官方体系（比如 Gateway、Config、LoadBalancer），阿里系组件按需选用，并且做好“万一哪天要替换”的抽象隔离。比如限流，你可以用 Sentinel，但要在代码里把限流逻辑封装成接口，将来换成 Resilience4j 也不至于伤筋动骨。

至于spring cloud sentinel datasource redis集群这个组合，典型场景是 Sentinel 的规则持久化。默认 Sentinel 规则存在内存里，重启就丢，生产环境必须持久化。用 Redis 集群做规则存储是常见做法，配置sentinel.datasource.redis指向集群，规则变更实时推送。这里有个坑：Redis 集群模式下，Sentinel 的发布订阅要处理好节点切换，否则规则推送会丢。我一般建议规则存储和业务缓存用不同的 Redis 实例，避免互相影响。

3.4 Vite 为什么出现在 AI 底座的技术栈里

Vite出现在热词里，说明这个底座的控制台前端用了它。这其实很合理。AI 底座的控制台是个典型的中后台应用，页面多、组件多、开发时热更新要快。Vite 基于 ESM 的按需编译，冷启动比传统打包工具快一个数量级，改一行代码几乎秒级刷新，对天天调界面的前端来说体验提升巨大。

但我要提醒一点：Vite 在开发时爽，生产构建时要注意 chunk 拆分。AI 控制台往往依赖很多重型库（图表、编辑器、向量可视化），如果不做手动分包，首屏加载会很难看。我的经验是把echarts、monaco-editor这类大依赖单独拆 chunk，配合路由懒加载，首屏能压到 1 秒内。

4. 实操落地：从零搭一个最小可用的 AI 应用底座

4.1 先定边界，别一上来就追求大而全

我见过太多团队一上来就想把底座做成“什么都能干”，结果半年过去一个能用的功能都没有。我的建议是：第一版只做三件事——模型统一接入、提示词版本管理、调用审计。这三件事是所有 AI 应用的公共刚需，做完就能让业务团队感受到价值。

具体来说，模型统一接入要支持至少两种模型（一个云端、一个本地），并且用统一的 OpenAI 兼容协议对外暴露。这样业务方无论用哪个模型，代码都一样。提示词版本管理要支持变量、版本号、发布状态，运营改提示词不用找开发。调用审计要记录每次调用的应用、用户、模型、Token 数、耗时、结果状态，这是后续计费和优化的基础。

4.2 模型网关服务的核心实现思路

模型网关是整个底座最核心的服务，它的职责是“屏蔽模型差异”。我写一段伪代码说明核心逻辑：

public interface ModelProvider { ChatResponse chat(ChatRequest request); String getName(); } @Service public class ModelGateway { private final Map<String, ModelProvider> providers; private final RateLimiter rateLimiter; private final AuditLogger auditLogger; public ChatResponse route(String appId, ChatRequest request) { // 1. 鉴权与配额检查 Quota quota = quotaService.check(appId); if (!quota.hasRemaining()) { throw new QuotaExceededException(appId); } // 2. 限流 if (!rateLimiter.tryAcquire(appId)) { throw new RateLimitException(appId); } // 3. 选择模型（按应用配置或路由策略） String modelName = routingService.select(appId, request); ModelProvider provider = providers.get(modelName); // 4. 调用并记录审计 long start = System.currentTimeMillis(); try { ChatResponse response = provider.chat(request); auditLogger.success(appId, modelName, request, response, System.currentTimeMillis() - start); return response; } catch (Exception e) { auditLogger.failure(appId, modelName, request, e); // 5. 降级：切备用模型 return fallbackService.fallback(appId, request); } } }

这段代码里最关键的是第 5 步降级。很多团队做网关只做转发，不做降级，结果主模型一挂业务全挂。我的经验是每个应用至少配一个备用模型，主模型连续失败 N 次自动切换，切换后要告警，让人知道出事了。

4.3 提示词服务的版本管理设计

提示词管理看着简单，做起来坑很多。核心是要把提示词当成“代码”来管。我的设计是：

这里有个我踩过的坑：变量渲染一定要做转义和长度限制。有次业务方传了个超长变量，直接把提示词撑爆，模型返回一堆乱码。后来我在渲染层加了单变量最大长度和总长度校验，超了直接拒绝，问题就没了。

4.4 用 Sentinel 做流量治理的配置要点

模型网关是流量入口，必须做限流。用 Sentinel 的话，核心配置如下：

spring: cloud: sentinel: datasource: redis: redis: host: ${REDIS_HOST} port: ${REDIS_PORT} password: ${REDIS_PASSWORD} rule-type: flow >// vite.config.ts 关键配置 export default defineConfig({ build: { rollupOptions: { output: { manualChunks: { 'echarts': ['echarts'], 'editor': ['monaco-editor'], 'vendor': ['vue', 'vue-router', 'pinia'] } } } } })

实测下来，不做分包首屏 JS 能到 3MB 以上，做了之后压到 800KB 左右，加载体验完全不一样。

5. 踩坑实录：AI 应用底座落地时最容易翻车的几个地方

5.1 多租户数据隔离没做好，上线即事故

这是最严重也最常见的坑。底座服务多个业务方，如果知识库、会话记录、提示词没有做租户隔离，A 部门能查到 B 部门的数据，这在企业里是红线。我的做法是所有数据表强制带 tenant_id 字段，所有查询强制带租户条件，并且在 ORM 层做拦截，防止开发忘记加条件。向量数据库也要按租户分 collection 或加 metadata 过滤，不能混在一起。

5.2 模型调用超时没处理，线程池被打满

模型调用是慢操作，几秒到几十秒都正常。如果网关用同步阻塞调用，并发一上来线程池瞬间打满，整个服务不可用。必须用异步 + 超时控制。我的配置是：连接超时 5 秒，读超时按模型设（快的 30 秒，慢的 120 秒），超时直接走降级。同时线程池要隔离，模型调用用一个独立线程池，不要和业务线程混用。

5.3 提示词改了没评测，效果崩了才发现

运营改提示词是很频繁的，如果没有评测机制，改坏了要等用户投诉才知道。我的经验是建立最小评测集，每个核心应用准备 20 到 50 条典型问题，改提示词后自动跑一遍，得分低于基线就拦截发布。这个投入不大，但能挡住 80% 的低级错误。

5.4 常见问题速查表

5.5 几个只有踩过才知道的细节

第一，模型返回的流式响应要处理好断连。用户关掉页面，后端还在往一个已经断开的连接写数据，会报一堆异常。要在写之前检查连接状态，断了就取消模型调用，省 Token。

第二，Token 计数不要自己估。不同模型的分词方式不一样，自己按字符数估会差很多。能用模型返回的 usage 就用返回的，不能用就用对应模型的分词器算。

第三，审计日志不要同步写。每次调用都同步写数据库，高并发下数据库扛不住。用消息队列异步落库，或者先写本地文件再批量入库。

第四，配置中心的值变更要能回滚。有次改了个限流阈值，改错了导致全局限流，业务全挂。后来所有配置变更都留版本，一键回滚，心里踏实多了。

6. 关于选型和演进，我的一些个人判断

聊到这儿，我想说说对几个热词背后问题的真实看法。微服务拆分这件事，我的观点是不要为了微服务而微服务。AI 底座确实适合微服务，但拆分的粒度要控制。我的经验是按“能力边界”拆，不按“技术分层”拆。模型网关、提示词、知识库、审计，这四个拆开就够了，别再往下拆成“模型调用服务”“模型返回处理服务”这种，那是过度设计。

若依 spring cloud、若依微服务plus这类脚手架，适合快速起步，但要注意它们默认的很多配置是给传统业务系统用的，AI 场景下要改。比如默认的数据库连接池大小、默认的超时时间，都不适合模型调用这种慢操作，得按实际情况调。

至于spring cloud alibaba 停更，我的态度是：已经在用的不用急着换，但要开始做技术债管理。把阿里系组件的使用收敛到少数几个模块，做好接口抽象，将来真要换的时候，改动范围可控。新项目选型时，核心链路优先用 Spring Cloud 官方组件，阿里系组件作为增强按需引入。

QuickBlue 这类 AI 应用底座的价值，说到底不是技术多先进，而是把 AI 落地过程中那些“每个团队都要踩一遍的坑”提前填好了。它让企业不用从零开始造轮子，能把精力放在真正产生业务价值的地方。我在实际项目里最大的体会是：底座的成熟度，决定了企业 AI 应用能走多快、走多远。没有底座，做 3 个应用就到头了；有了底座，做 30 个应用也只是配置的差别。这个杠杆效应，才是它真正值得投入的原因。