企业官网建设流程全解析

最近在技术社区和客户群里，关于 QuickBlue 的讨论明显多了起来。有人把它当成一个简单的模型聚合接口，有人问它和 LangChain 这类框架有什么区别，还有人直接问：我自己写个工具类封装大模型调用不行吗，为什么要专门上“底座”？这些问题背后，其实都指向同一个困惑：AI 应用底座到底是什么，它凭什么值得企业单独建一层。

我过去两年做了不少企业级 AI 项目的落地，从智能客服、文档助手到内部数据分析，踩过各种坑之后才慢慢想明白：底座不是技术炫耀，而是大模型走进真实业务后必然出现的一层“中间件”。这篇文章不聊概念包装，就用 QuickBlue 这类平台作为例子，说说底座解决什么问题、内部如何拆解、落地时怎么搭，以及我踩过的那些坑。不管你是技术负责人、AI 应用开发者，还是刚想清楚要往业务里塞大模型的架构师，这篇文章应该能帮你少走不少弯路。

1. QuickBlue 是什么：一次说清 AI 应用底座

1.1 从“调 API”到“建底座”：企业 AI 化的分水岭

过去做 AI 应用很简单：注册模型接口，写几段 Prompt，把用户输入怼进去，再把输出渲染出来。POC 阶段这么做完全没问题，可一旦进入生产环境，问题就全冒出来了。

模型侧，今天 A 模型效果好，明天 B 模型出来了，评测下来更强还更便宜，可业务代码全是按 A 模型的返回结构写的，切换一次要改几十个地方。业务侧，客服要知识库，文档助手也要知识库，每个项目都从零做一遍文档切分、向量化、检索调优，人力浪费非常明显。运维侧，模型是个黑盒，用户投诉某条回复不对，你连当时模型拿到什么上下文都查不到。这个阶段我经常用一句话总结：能跑通，但跑不稳，也跑不省。

“AI 应用底座”就是夹在模型与业务之间的一层。它把模型接入、知识检索、Prompt 管理、效果评测、日志追踪这些通用能力统一收拢起来，做成标准服务。业务部门不再直接面对模型，而是面对底座提供的一套类似内部网关的能力。QuickBlue 这个名字，正是按这个思路设计的一套平台化产品。

打个生活化的比方：底座就像企业的电力系统。家用电器（业务应用）不用关心电是从火电、水电还是风电来的，插上就能用。变压器、稳压器、保险丝这些脏活累活，由基础设施统一负责。如果没有这层基础设施，每个电器都要自己配一套发电设备，那画面想想都恐怖。

1.2 QuickBlue 的四层能力架构

QuickBlue 这类平台，我习惯把它拆成四层，每层解决一个特定维度的痛点。理解这四层，基本就理解了大半的底座设计逻辑。

第一层是接入层，核心是模型网关。各家模型接口的请求格式、鉴权方式、Token 计算规则都不一样，网关把这些差异全部屏蔽掉，对外暴露一套标准 API。在这一层里，还包含多模型注册、按场景路由、限流熔断、配额管理等功能。说白了，它让“换模型”变成改一行配置，而不是重写业务代码。

第二层是智能层，负责把简单的“一问一答”变成复杂的业务逻辑。这里包含 Prompt 模板管理、版本控制、工作流编排、Agent 工具调用等能力。比如一个智能客服流程，不是直接把用户问题丢给模型，而是先检索知识库，再拼接上下文，然后调用订单查询工具，最后生成答案。这些步骤如果散落在业务代码里，每个项目都要重写一遍，放在底座里就成了可复用的编排模板。

第三层是数据层，解决的是模型不懂企业知识的问题。它的核心是 RAG 知识库，包含文档解析、分块、向量化、检索、重排序等一整套流程。同时它还会记录每次对话的输入输出、模型版本、Prompt 版本、知识引用来源。这些数据是后续做评测和优化的原材料。数据层决定了模型回答的“上限”，知识库做得好，模型才真正像企业的员工，而不是一个什么都懂但什么都不知道的“外地专家”。

第四层是治理层，很多企业最容易忽略这一层，但往往最后吃大亏的也是这一层。它包含用户权限管理、内容安全过滤、成本核算、效果评测、可观测性追踪。没有治理层，AI 应用就处于野蛮生长状态：任何人都能调模型，成本无人管控，出了问题找不到责任人，敏感信息可能被模型带出。

这四层并不要求每层都做得很重，但企业一旦进入多场景、多团队协作阶段，这四层几乎缺一不可。这也是底座区别于普通开发框架的关键：框架解决的是“怎么写代码”，底座解决的是“怎么稳定地运营一套智能系统”。

2. 为什么企业需要一个 AI 应用底座：痛点与边界

2.1 企业落地 AI 的六个真实痛点

我在客户现场听得最多的诉求是“我们要上大模型”，但深入了解之后，发现大家真正困惑的不是模型效果，而是下面这六个问题。

第一个痛点是重复建设。同一家公司，客服团队做了一套知识库，文档团队又做了一套知识库，算法团队为了演示再搭一套。每套都要处理格式解析、文本分块、向量化、检索调优，周期长、效果参差不齐，还互相不通用。底座的第一个价值，就是把“造轮子”变成“用轮子”。

第二个痛点是模型切换成本。采购、开源、商用，企业往往同时接触多个模型。A 模型适合写文案，B 模型逻辑推理更强，C 模型部署成本低。没有统一抽象层的时候，每换一个模型都涉及接口改造、数据结构调整、异常处理重写，测试周期以周为单位。有了底座，模型是插拔式的，切换只影响路由配置。

第三个痛点是数据闭环断裂。很多团队做模型选型时线下评测效果不错，上线后效果如何却没人跟踪。用户反馈差，问题出在 Prompt、知识库还是模型本身，完全没有数据支撑。底座把每次请求的上下文、模型版本、引用来源、用户反馈全部记录下来，效果问题就不再是玄学，而是可以定位、可以回归的工程问题。

第四个痛点是治理缺位。我见过一个团队给全体员工开放了模型问答入口，结果有员工把内部保密制度粘贴进去问“这么写合规吗”，最后相关信息出现在生成结果里被其他人看到。权限隔离、内容审计、操作日志，这些在业务系统里已经是常识，但在 AI 应用里常常被遗忘。底座把这套机制补齐，让 AI 系统符合企业内部的安全规范。

第五个痛点是成本失控。大模型按 Token 计费，业务量上去之后账单非常吓人。没有配额限制、没有路由优化、没有缓存复用，一个月跑出几十万费用并不稀奇。底座可以在模型层面做“降级路由”：简单问题走便宜的小模型，复杂问题才调度强模型。

第六个痛点是协作低效。业务部门不懂 Prompt，算法部门不懂业务，两边来回拉扯。底座把 Prompt 变成可视化的模板管理，业务人员也能参与调优，算法人员只需要维护底层模型。这类协作方式，明显比“业务提需求，算法改代码”的循环高效得多。

2.2 底座、大模型和业务应用的边界

很多团队对底座的理解有两个极端。一种认为底座就是大模型本身，买一个平台回来就什么都有了；另一种觉得底座没有价值，直接调 API 就够了。这两种理解都偏了。

大模型提供的是“智力”，但它不了解你的业务，也没有权限概念，更不会自动适配你的知识库。业务应用是面向用户的产品形态，需要交互设计、业务流程、体验优化。底座刚好在两者之间，它做的事是：把大模型的通用智力，转换为企业内可稳定调用的服务能力。形象点说，大模型是发动机，底座是变速箱和传动轴，业务应用是车身。只有发动机，车跑不起来；只有车身，车没有动力；底座负责把动力平稳地传递到轮子上。

需要特别提醒的是，底座并不适合所有团队。如果你们只是做一两个 POC 验证场景、只有两三个人参与、也没有长期运营的计划，那直接调 API 写工具类就够了。底座的引入本身有学习和运维成本，需要团队有平台意识。我在实际工作中建议的判断标准是：同时运行的 AI 场景超过五个，或者参与的人数超过十人，或者企业对审计合规有硬性要求，满足任意一条，就应该认真考虑底座。

2.3 架构演进：什么时候该上 QuickBlue 这类底座

企业 AI 架构通常经历三个阶段。第一个阶段是 API 直连，适合快速验证想法，缺点是逻辑散落、无法复用。第二个阶段是在项目内部做工具类封装，把模型调用统一到一个类里，比如写一个 LLMClient，优点是单一项目内可控，缺点是换一个项目重新复制一遍。第三个阶段才是独立底座平台，把能力沉淀为组织级服务。

什么时候算到了该迁移的临界点？我总结了几条信号。代码里出现超过三处直接调用模型接口的地方；知识库逻辑在多个项目里重复出现；模型效果评估全靠人工印象而不是标准评测集；上线后没人能说清某条错误回答当时用了什么 Prompt 和模型版本。这些信号出现任意两条，就说明缺底座这层抽象。

这里要额外强调一句：QuickBlue 的价值不在于“建了就完了”，而在于它提供了能力沉淀的载体。没有底座，每次项目交付完，能力就归还给了项目组，公司什么积累都没有；有了底座，知识库越用越厚，评测集越攒越全，路由策略越调越细，这些才是企业真正能留下的资产。

3. QuickBlue 核心能力拆解与实操要点

3.1 多模型接入：统一网关的配置逻辑

统一网关是底座最基础的能力，但很多人把它想简单了，以为只是做一个接口转发。真实场景要复杂得多：不同模型对 Token 的计算方式不同，有的把汉字算 1 个 Token，有的算 0.5 到 2 个不等；返回结构里，有的把引用信息放在单独字段，有的塞在文本里；有的模型支持工具调用，有的不支持。网关要做的不仅是转发，而是把这些差异全部归一化。

我通常在 QuickBlue 里按“能力标签”来注册模型。比如给每个模型打上“快速问答”“深度推理”“工具调用”“长文档理解”这样的标签，路由时按场景选择。下面是一份典型的网关配置示例：

{ "model_gateway": { "providers": [ { "name": "fast-default", "capabilities": ["qa", "chat", "tool-call"], "cost_per_1k_tokens": 0.001, "latency_target_ms": 1500 }, { "name": "pro-reasoning", "capabilities": ["deep-reasoning", "long-context", "tool-call"], "cost_per_1k_tokens": 0.02, "latency_target_ms": 6000 } ], "routing": { "scene": "customer_service", "prefer_model": "fast-default", "fallback_models": ["pro-reasoning"], "timeout_ms": 8000, "enable_stream": true } } }

这份配置里有两个细节值得注意。一是 fallback（兜底）逻辑，fast 模型超时或返回异常时自动切换 pro 模型，这个机制能显著提升线上可用性。二是 enable_stream 要打开，流式输出能大幅改善用户等待体验，第一个 Token 的返回时间重要性甚至高于总耗时。实际配置时，我建议针对每个场景单独设置路由，不要全局套一套规则，因为客服场景和数据分析场景对延迟和推理深度的要求完全不同。

3.2 Prompt 管理与版本灰度：经常被低估的一层

Prompt 是底座里最有杠杆效应的部分，一行的改动可能让准确率从 70% 跳到 90%，也可能让效果直接崩盘。没有管理机制的团队，通常会出现这种情况：运营同事在调试页面改了一句 Prompt，效果看着不错，直接点了保存并上线，晚上业务反馈大量异常。症结就在于没有版本控制和灰度发布。

QuickBlue 这类平台，一般会把 Prompt 做成模板，然后在模板里嵌入变量。举个例子，一个文档问答场景的 Prompt 模板会写成：

你是企业的{role}，负责解答用户关于{domain}的问题。 请严格基于以下资料回答。 如果资料中没有相关内容，请直接说明“未找到相关答案”，禁止编造。 资料： {context} 问题： {question}

注意这里的 {context} 和 {question} 是运行时填充的变量，{role} 和 {domain} 是配置变量。用模板有几个好处：一是不同场景可以复用同一套结构，只需改配置；二是变量内容来自知识库检索和用户输入，来源清晰，日志里可以追踪。但模板只是第一步，真正的关键是把 Prompt 当作代码来管理：每次修改生成新版本，发布时选择灰度比例，线上异常时能一键回滚到上一版本。

我在实操中有一条硬规矩：任何 Prompt 的变更，必须先在评测集上跑一遍，对比新旧版本在准确率、拒答率、无用信息率三个指标上的差异。评测通过后再灰度到 10% 流量，观察真实对话日志，确认没问题再全量发布。这套流程看起来繁琐，但能避免绝大多数线上事故。

3.3 RAG 知识库的正确打开方式

知识库是底座中最容易做烂的部分。很多团队把文档往向量数据库一扔就完事，结果检索出来的内容驴唇不对马嘴，模型基于错误资料生成错误答案，还一脸无辜。问题往往不是出在模型，而是出在知识库的处理流水线上。

一条合格的知识库流水线，至少包含四个环节：格式解析、内容清洗、文本分块、向量化入库。格式解析要把 PDF、Word、网页里的文字和表格提取出来；内容清洗要把页眉页脚、重复段落、乱码符清理干净；文本分块决定检索粒度；向量化入库决定匹配效果。这里不做过度技术化展开，只强调两个实操细节。

第一个细节是分块策略。我常用的参数是：每个分块 256 到 512 个 Token，相邻分块重叠 10% 到 20%。分块太小，语义不完整，检索命中但信息不足；分块太大，容易混入无关内容，生成时上下文被污染。按标题层级切分比固定长度切分效果更好，因为业务文档本身有结构，把同一小节的内容划在一起，语义内聚度高。重叠部分则是为了缓解“跨块丢信息”的问题，尤其适用于条款类文档。

第二个细节是检索调优。初始阶段把 TopK 设为 3 到 5，相似度阈值不要一开始就卡得很死，可以先 0.7 再逐步上调。我见过不少团队把阈值设成 0.9，结果大量问题召回为空，模型只能“抱歉无法回答”。调优的顺序应该是：先看分块是否合理，再调 TopK，最后调阈值。如果检索结果整体都相关但不够精准，可以考虑接一个重排序模型，把粗排结果做一次精细化打分。

知识库上线之后同样需要持续运营。每周抽一批线上 badcase，看是分块切坏了、文档更新了没同步，还是用户问法和文档说法差异太大。我在项目里养成了记录“同义改写”的习惯：把用户常用的说法补充到知识库的路由词表里，检索召回率很快就有肉眼可见的提升。

3.4 评测、观测与安全护栏：底座能不能长期用的关键

评测是底座里最“反直觉”的部分：它决定系统能不能持续变好，却最容易被团队砍掉。原因很简单，评测集的构建需要人工标注，短期内看不到回报。但我可以负责任地说，没有评测集的底座，三个月后就会腐化到无法维护。

评测集不需要一开始就很大，三五十条高质量样本就够用了。关键是覆盖面：正常问题、模糊问题、越界问题、敏感问题、知识库没有答案的问题，每类至少 10 条。我常用的指标是准确率、忠实度、拒答率、兜底率。准确率看答得对不对，忠实度看答案是否严格来自知识库，拒答率看该拒答的时候是否拒绝，兜底率看知识库无答案时模型是否妥善处理而不是硬编。

观测侧，QuickBlue 一类平台会做完整的链路追踪。每次生成请求都应该记录：Prompt 版本号、模型版本号、知识库引用列表、Token 消耗、时延分布。这样当用户投诉“上次答错了”的时候，你可以准确定位到是哪一版 Prompt、哪个知识文档、哪个模型生成的结果，而不是靠猜。我把这套日志称为 AI 系统的“飞行记录仪”，没有它，所有优化都是盲人摸象。

安全护栏方面，至少要有四件事：敏感内容过滤，在输入和输出两侧都做；权限隔离，不同部门只能检索各自授权范围内的知识库；操作审计，谁在什么时间调用了什么模型的什么能力；成本配额，每个业务线有独立的预算上限。这四件事做完，底座才算具备了进入生产环境的资格。

4. 落地实操：从 0 到 1 搭建一个 AI 应用底座

4.1 开工之前，先回答三个问题

很多团队把 QuickBlue 部署起来，然后发现没人用或者用不好，根源在于没想清楚边界就开始动工。动手之前，我建议三个问题必须拿到明确答案。

第一个问题：场景边界是什么，不做什么。底座最容易犯的错误是“什么都要接”，从客服、写作、代码生成到数据分析，全都想在第一期上。正确的做法是圈定一到两个核心场景，把它做深做透。我通常建议选择业务方配合度高、效果能量化、数据相对干净的场景作为第一个落地对象。

第二个问题：部署形态怎么定。是选择 SaaS 版本快速试用，还是在企业内网私有化部署。如果业务数据高度敏感，合规部门通常会要求私有化，这需要提前评估算力资源和运维人力。如果只是内部工具型应用，先用 SaaS 版跑通价值，再考虑私有化也不迟。

第三个问题：团队归属和运营机制。底座必须有明确的 owner，不能是“人人有责”但无人负责。正常配置是至少两个人：一个偏平台工程，负责模型接入、稳定性和成本；一个偏 AI 应用运营，负责 Prompt 调优、知识库更新和评测集维护。这两个角色可以不是专职，但必须有明确指标，否则底座三个月后就变成僵尸平台。

4.2 部署与初始化的关键步骤

按 QuickBlue 这类平台的常见部署路径，我会分成六步走。第一步，准备基础环境。需要一台应用服务器和一个向量数据库实例。向量库可以用开源自建的，也可以直接用平台内置的，初期建议用内置能力减少运维负担。第二步，部署控制台和网关服务，这通常是一套标准的容器化应用，拉取镜像、配置数据库连接、启动服务即可。第三步，在控制台配置模型供应商信息，把模型的 API Key 录入并完成连通性测试。这一步一定要注意，生产环境的模型密钥不要写在业务代码里，而是放在底座配置中心统一管理，通过加密存储和访问控制保护起来。第四步，创建第一个知识库。导入一份真实业务文档，检查切分结果是否合理，向量化任务是否正常完成。我习惯用一份大约几十页的 FAQ 文档来做验证，信息密度高、格式相对规整，最适合检验流水线效果。第五步，配置一个最简单的问答应用，把模型路由、知识库、Prompt 模板串起来，跑通端到端。第六步，验证日志和监控是否正常，确认请求链路能在观测面板里完整呈现。

每一步都有明确的验收标准。环境部署完的验收标准是控制台能正常访问；模型接入的验收标准是测试请求能在 3 秒内返回结果；知识库的验收标准是随机提问三条业务问题，模型都能给出带引用来源的回答；日志的验收标准是每一条请求都能在追踪页面里查到完整链路。这六步看起来不难，但要顺利完成，前面提到的三个问题必须先有答案。否则，做完最后一步经常会遇到“然后呢”的尴尬，底座有了，业务不会接。

4.3 第一个业务场景接入全流程：以智能客服为例

我用一个实际做过的内部 IT 运维客服场景，来演示完整的接入过程。当时这家公司有 300 多页的常见问题手册，覆盖网络故障、账号权限、软件安装、硬件申请四类问题。整个接入流程分五步，每一步都有具体的配置和验收标准。

第一步，配置知识库。导入手册后，我按照标题层级重新调整了分块参数，每个分块 350 Token 左右，重叠率设为 15%。完成后随机抽取了 20 个问题做检索测试，确认每个问题都能召回相关文档片段。这一步做得好不好，直接决定后面所有环节的体验，所以值得多花时间。

第二步，编写 Prompt 模板。角色设定是“企业 IT 支持助手”，要求回答简洁、不超过三到五句话、必须附上知识库文档编号作为引用来源。我在模板里特别加了一条约束：当问题超出知识库范围时，明确告知用户“请提交工单或联系IT服务台”，并给出工单入口链接。这条约束显著降低了模型“强行编答案”的概率。

第三步，配置路由策略。知识库问答类请求走 fast-default 模型，因为这类问题模板化程度高，不需要深度推理。只有涉及故障排查的多轮对话才调度到 pro-reasoning 模型。我通过查询日志观察到，约 85% 的请求都由 fast 模型处理，整体成本比全部走 pro 模型下降了 60% 以上。

第四步，联调验证。我准备了 40 个测试问题，覆盖正常咨询、模糊表达、超范围问题、敏感话题四类，逐一验证回答是否符合预期。这个环节发现了不少问题，比如模糊表达“网连不上”召回不到准确文档，后来我调整了路由词表，加入了“网络断开”“无法上网”“WiFi 连不上”等常见说法，召回率明显提升。

第五步，灰度上线。先开放内部 5% 员工试用一周，观察用户反馈、拒答率和兜底率。之后逐步放量到 30%、100%。上线两周后，问题解决率从传统工单模式的 45% 提升到了 78%，同时工单量下降了 30%。这个结果说明，底座的价值不在于模型选得有多强，而在于知识库、Prompt、路由、反馈这些环节是否真正打磨到位。

5. 常见问题与排查技巧实录

5.1 响应慢、老超时：先查链路，别直接怪模型

AI 应用响应慢，很多人第一反应是“模型不行”，但排查下来往往另有原因。我在项目里总结了一套排查顺序。第一步看网络层，是不是内网到模型供应商的链路延迟高；第二步看网关配置，超时时间是不是设得太短；第三步看检索层，向量库查询慢可能是因为数据量增长后没有优化索引；第四步看生成层，模型返回的 Token 数是不是被场景需求撑大了，比如要求生成 2000 字的回答，耗时就接近普通问答复的四五倍。

优化手段按性价比排列：优先开流式输出，让用户先看到内容而不是干等；然后做结果缓存，高频常见问题命中缓存后直接返回，这套方案在客服场景里能把 30% 左右的请求耗时降到 100 毫秒以内；再往后考虑路由降级，简单问题切换到更快的模型；最后才是优化检索链路和调大超时阈值。这几种手段叠加后，我负责的项目平均首 Token 延迟从 3 秒降到了 0.8 秒左右，用户体感改善非常明显。

5.2 回答质量时好时坏：上下文污染是最常见的元凶

线上表现忽好忽坏，最常见的原因有三个。第一是上下文污染，知识库检索回来的片段里混了大量无关内容，模型被带偏。这类问题通过查看日志里的引用来源就能定位，把无效片段过滤掉即可。第二是 Prompt 被悄悄改动，有人直接在调试页面改了配置并发布，没有走版本管理流程。如果你发现同一个问题上午回答正确、下午回答错误，先检查 Prompt 版本是不是变了。第三是知识库更新出了问题，新版本文档和旧版本冲突，模型同时检索到相互矛盾的内容，生成结果自然不稳定。

我的应对措施有三条。首先，给知识文档加上生效时间和优先级字段，同主题文档默认只召回生效时间最近的那版。其次，所有 Prompt 修改必须关联需求记录，上线前强制跑评测集。最后，每周固定跑一次回归测试，对比关键指标是否有漂移。这套流程实施后，线上的“玄学问题”基本绝迹。

5.3 检索不到知识：按四个环节逐个排查

很多团队在知识库上线后会发现，有些问题明明在文档里有答案，模型却回答不上来。排查时按下面四个环节依次检查。第一个环节是分块，如果查询的核心信息恰好被分块边界切断，检索自然命中不全，这时候需要调整分块大小或重叠率。第二个环节是向量化，查询语句和文档表述差异过大时，向量相似度会偏低，解决办法是维护同义改写词表。第三个环节是 TopK，取太少会导致正确答案排到列表后面被截掉。第四个环节是相似度阈值，设得太高会把弱相关的可接受结果也过滤掉。

我特别想强调一个容易被忽略的“源头治理”思路：如果某类问题反复检索不到，优先回头检查原始文档的质量，而不是一味调参数。文档本身表述含糊、逻辑混乱，再好的切分和检索算法也无济于事。与业务部门合作，把高频问题对应的内容重写清楚，往往是效果提升最快的方法。

5.4 成本失控：三个抓手管住 Token 账单

大模型账单失控，本质上是因为没有“成本意识”的路由设计。第一个抓手是模型降级，绝大多数业务场景根本不需要最强的模型，将日常问答类请求路由到低成本模型，保留强模型处理复杂任务可以大幅压缩成本。第二个抓手是缓存，完全相同或高度相似的问题直接命中缓存，既不消耗 Token 又让响应速度更快，客服场景特别适合。第三个抓手是配额告警，为每个业务线设置月度预算上限并配置超限提醒，同时按日粒度同步到负责人。

我还习惯在底座里维护一张“场景成本表”，按场景统计每千次请求的平均 Token 消耗和总费用。有了这张表，哪个场景是成本黑洞一目了然。比如我们曾发现“文档总结”类请求因为输出长度很长，占总成本的 40%，后来通过限制输出长度和改走更经济的模型，成本直接砍半。

5.5 避坑清单速查

最后把项目里踩过的坑归纳成一张速查表，方便你在交付前逐条核对。

避坑表里最后一条尤其值得多说一句。模型的权限控制能力天然薄弱，它只是一个文本生成器，并不知道哪些信息可以讲给谁听。底座必须在检索前做权限过滤，在生成后做内容审计，双管齐下，敏感数据才不会被模型“不经意”地带出去。这个点，很多技术团队直到出了事故才想起来补课。

踩过这么多坑之后，我最大的体感是：AI 应用底座不是买来就完事的，它是一个需要持续运营的系统。QuickBlue 这类平台的价值，在于逼着企业把模型接入、知识库、Prompt、评测、治理这些事一次性想清楚，而不是等出了事故再亡羊补牢。如果你们正准备在企业里大规模引入大模型，与其让十个项目各自摸索，不如先把底座这层立起来。

最后分享一个小技巧：底座的第一个场景千万别选“全公司 AI 助手”这种大而泛的需求，一定要选一个范围明确、业务方有耐心、效果能量化的场景。先把一条链路跑通，再谈横向扩展。这个忠告，是我自己用两次失败的项目换来的，希望后来者不用再交同样的学费。