企业官网建设流程全解析

“AI 中台”这个词，这两年快被聊烂了。但我见过太多团队，把“中台”做成了“重台”——花三个月搭架构，再花六个月填数据，等到终于能跑通一个Demo时，业务方早就不耐烦了，项目也就悄悄烂尾。我的观点很直接：AI 中台建设，应该轻型起步。不是反对中台，而是反对用建大型平台的方式去建中台。这篇文章想把我在好几个项目里用轻量打法做AI中台的思路、边界、步骤和坑，一次性说清楚，希望帮正准备折腾中台的团队少走点弯路。

1. 重型AI中台的教训：为什么“统一规划、分步实施”常常变成“永远在规划”

先说一个真实的场景。某次我去拜访一个朋友所在的团队，他们正在做公司级AI中台项目，立项会上定了“统一规划、分步实施”的大方向：建统一存储层、统一特征平台、统一模型仓库、统一推理服务，甚至还想把模型训练平台也一体化。架构画得很漂亮，PPT做了快一百页，各种技术选型评审开了两三轮。结果呢？三个月过去了，团队还在做底层存储的选型和数据治理，业务部门想接一个文档问答功能，发现中台连个最简单的模型调用接口都没开放。业务方等不起，自己找云厂商开了个API直接用。中台团队慢慢就变成了一个“名词制造机”，离业务越来越远。

这种搞法的问题不在技术的复杂程度，而在决策的链条被拉得太长了。每做一个统一规划，就要拉上所有业务方确认需求；每确定一个技术选型，就要等待层层评审。而AI领域的变化是以周为单位在跑的，今天还热门的方案，三个月后可能已经落后了。等你把重型底座铺好，业务早换了好几轮需求了。

1.1 重型中台的两个隐性成本

第一，隐性成本是“决策延迟”。重型方案必须先定义完整的抽象层，比如统一的数据格式、统一的模型推理协议、统一的权限体系。这些抽象层本身是合理的，但当它们需要被所有潜在使用方共同确认时，就会陷入无休止的评审和争论。有的团队为了一个字段命名讨论一周，不是大家闲得慌，而是因为一旦定了标准，后续所有系统都要跟着改，谁也不愿意拍这个板。

第二，隐性成本是“需求失焦”。做重型中台时，团队容易沉迷于搭建“能力基座”，而忽略了业务方当下到底要解决什么问题。我有次项目评审会，中台团队花了四十分钟介绍他们的模型网关设计，多路由、多副本、灰度发布、熔断降级，讲得非常专业。业务方听完只问了一句：我们想和现有客服系统打通，什么时候能排上？全场安静了。基座做得再坚固，如果上面不长业务，就是一片荒地。

1.2 轻型起步不是偷工减料，而是用最小成本验证中台假设

我理解的“AI中台”，本质上是一层面向多个业务场景、提供模型能力的共享服务层。轻型起步的意思是：先用最小可用的方案把这层服务搭起来，让它能支撑一到两个真实业务场景跑起来；然后再根据实际使用情况，逐步补充能力。这个思路其实和“精益创业”很像——先做一个MVP，看有没有人用，再决定要不要加大投入。

很多人听到“轻型起步”，第一反应是“那不就是做个API网关嘛，算什么中台”。这种看法恰恰搞错了重点。中台的核心不是系统多复杂，而是能不能让多个业务方一致地、低成本地获得模型能力。就算最初的实现只有一个简单的网关和几个脚本，只要业务方愿意接入，只要新场景能快速复用，它就已经在发挥中台的职能了。至于底层是该用Kubernetes还是裸机，是不是要上完整的模型生命周期管理平台，这些都是在验证了需求之后才需要考虑的事情。

2. 轻型AI中台的边界清单：什么该现在建，什么该缓一缓

既然要轻型起步，就必须给中台划定一个清晰的边界。我习惯用一张清单来约束自己：必建项和缓建项。必建项是保证中台能跑通闭环并提供基本价值的；缓建项不是不要，而是等规模验证后再考虑，避免在前置基础上消耗太多精力。

2.1 起步必建的三件事

第一件事是统一模型入口。不管底层接的是哪个模型服务商，不管业务方用的是大语言模型还是专用的图像模型，对外都应该提供一个统一的调用入口。这样业务方不需要自己研究各家API差异，后续替换模型供应商也只需要改内部映射。统一入口的形式可以很简单：一个API网关或代理服务，所有请求都走这个入口。

第二件事是成本可计量。AI能力不像普通后端接口，它的成本结构非常特殊——按token计费、按GPU占用计费、不同模型不同价格。如果中台不能把一个请求对应到具体业务方、具体场景的模型调用成本，那中台账就算不清了。账算不清，后续优化也无从谈起。所以轻型起步阶段，就要把成本采集和告警做上。

第三件事是效果可观测。这个“效果”不是指模型精度之类的离线指标，而是指业务方实际使用中的效果：用户的请求是否得到了合理响应，响应延迟是否可接受，是否产生了错误或幻觉输出。这些信息尽早在中台侧统一采集，会让后续的模型选型、调优、场景拓展都轻松很多。

2.2 缓建清单：数据湖、特征平台、统一知识图谱

很多重型中台方案里常见的内容，在轻型起步阶段应该明确缓建：

• 统一数据湖和数据治理平台。AI中台确实依赖数据，但起步阶段，业务方自己准备数据或通过接口上传数据，往往比中台统一收口快得多。
• 大规模特征平台。大模型时代的特征是“提示词”和“检索增强”，和传统机器学习时代的特征工程很不一样，不必急着为传统特征平台投入。
• 统一知识图谱。知识图谱听起来很高大上，但建设周期长、维护成本高，起步阶段用轻量的向量数据库存储业务知识就能覆盖大部分问答类场景。
• 完整模型训练平台。多数业务场景不需要从零训练模型，微调也只是小部分团队的需求。起步阶段调用成熟API，比自建训练平台划算太多了。

2.3 判断标准：是否被三个以上业务方重复踩坑

很多人问，缓建项的判断标准是什么？有没有一个客观规则。我总结了一个很朴素的判断逻辑：当至少三个业务方都提出同样的需求时，才值得由中台统一去建；如果一个需求只有一个业务方需要，那就让这个业务方自己解决，中台别越俎代庖。

比如，只有一个业务方需要对文档内容做向量化，那就让他们的开发直接调用嵌入模型接口，中台不需要专门做一套文档解析和向量化的服务。等第二个、第三个业务方都提出要接文档问答了，中台再把文档预处理、向量库、检索服务统一封装起来，这就是顺势而为。反观很多重型中台，业务方还没提出需求，就把向量检索服务、文档解析服务全部做好，做完了没人用，还得自己编使用场景，纯属浪费。

3. 模型服务层怎么搭：一个网关加一套协议，别急着造调度平台

轻型起步阶段，中台最核心的技术组件其实就一个：模型服务网关。它负责统一接入、路由转发、成本计量、访问控制和简单的可观测性。别小看这个网关，它做扎实了，中台的地基就稳了。

3.1 多供应商网关设计：统一协议，路由到不同模型

我推荐的做法是，网关层对外暴露一套统一的接口协议，参考业界普遍使用的OpenAI兼容协议格式。这样业务方只需要按照这套协议调用，不用关心背后接的是哪家的模型。网关需要维护一份模型路由表，把逻辑模型名映射到真实的供应商和模型ID。比如业务方请求“文案总结-快速”这个模型名，网关通过配置知道它应该路由到某个厂商的轻量模型；当这个模型因为成本或效果原因需要更换时，业务方不需要改动，只要在网关配置里调整映射即可。

我用一个简化的伪代码来说明网关的核心逻辑：

class ModelGateway: def __init__(self, router_config): # router_config是模型路由配置，如 # {"文案总结-快速": {"provider": "cloud_a", "model": "fast-model", "max_tokens": 512}} self.router_config = router_config def handle_request(self, model_name, prompt, user_id, scene_id): route = self.router_config.get(model_name) if not route: raise ModelNotFoundError(f"未配置的模型名: {model_name}") # 从统一入口转发到底层供应商 response = call_provider(route["provider"], route["model"], prompt) # 记录调用明细，用于成本分摊和观测 record_usage(user_id, scene_id, model_name, response.usage) return response

这段代码看起来简单，但它体现了三个关键意识：对外统一、对内灵活、全程留痕。业务方永远只面对一套协议，底层怎么变都不影响他们；而中台则通过配置文件获得灵活性，换模型、加供应商都只是改配置的问题。

3.2 成本核算与预算控制：token计量、额度管理、告警

大模型应用的成本控制是一个很有特色的环节，它对账务的细致程度要求极高。我建议在网关层直接做四件事：

• 计量：每次请求记录输入和输出的token数，以及模型单价，计算出单次请求成本。
• 归因：通过请求头或参数识别userId和sceneId，把成本归因到具体业务线和具体场景。
• 额度管理：给不同业务方设置预算上限，超出后可以降级到更便宜的模型或者直接拒绝服务。
• 告警：当某个场景的日成本突增时，及时推送告警，防止AI成本失控。

这种成本控制意识非常重要。有一次我们看到某个场景的调用量翻了三倍，但业务效果并没有提升。打开网关的计量日志才发现，某个业务方在循环里调用了模型去处理一个本可以用规则处理的文本，白白烧掉了大量tokens。如果没有细粒度的成本归因，这种浪费根本发现不了。

3.3 可观测性建设：从日志到trace，再到效果评估

讲到可观测性，很多人第一时间想到的是看延迟和错误率。这些确实要看，但对AI中台来说，最重要的观测维度是回答质量和效果，而这一点恰恰是最难的。

起步阶段我会分两步走：

第一步，先做好基础遥测。所有请求统一打日志，记录提示词、模型返回、token用量、延迟、错误码。这些日志后续可以做离线分析。

第二步，建立轻量的效果标注与评估回路。某个业务方在使用文档问答场景时，可以在前端增加“点赞/点踩”按钮，后台把用户反馈数据回传中台。中台定期从日志里抽取用户点踩的案例，做人工质检，再把质检结果反馈给业务方，指导他们优化提示词或者更换检索策略。

有人会觉得这套东西太重，不如直接看业务方的最终业务指标。但正式接入业务指标往往需要很长的数据埋点和分析链路，会拖慢起步节奏。用“点赞/点踩”这种轻量反馈，已经是投入产出比很高的方案了。等中台跑熟了，再逐步接入更正式的业务效果评估也不迟。

3.4 提示词管理：把提示词当成代码一样管理

还有一个经常被轻视但实打实影响中台价值的部分——提示词管理。很多人觉得提示词写好了扔给业务方就行，这是大错特错。提示词本质上是AI应用的业务逻辑，它需要被认真管理。

我们做了一个很朴素的提示词管理库，每个场景的提示词都具备版本号、修改人和发布状态。业务方只需要传具体的业务参数，中台负责把参数填充进规范的提示词模板，再调用模型。这样做有几个好处：第一，业务方不会因为改了一个标点符号导致整个提示词失效；第二，中台升级公共提示词模板时，可以批量提升所有场景的效果；第三，提示词版本的变更可以审计回溯，出现问题时知道是什么时候改了什么导致的。

提示词管理看起来不属于“平台能力”，但它的实际价值可能比网关还大。毕竟在模型能力固定的前提下，提示词通常是最直接影响最终效果的因素。

4. 让业务方愿意用：轻量闭环比“能力丰富”更重要

中台最怕的事情是什么？不是技术选型错了，而是建好了没人用。没人用的中台，无论架构多好、性能多强，最终都是墓碑。要让业务方愿意用，关键是帮他们快速跑通**“从需求到能力”的闭环**。

4.1 从“平台提供能力”到“业务自证价值”

传统中台思维是“我提供什么能力，业务方用什么”，但轻型中台要反过来——“业务方证明什么场景有效，我再把有效场景固化为中台能力”。我这个说法可能有点反直觉，但它是唯一能在资源有限的情况下让中台活下来的思路。

在实践中，中台应该对业务方说：你们不需要等我们建好平台，你们先可以直接接到一个基础模型端点，用最低成本验证你们的想法。如果你们验证了场景可行，中台会把这个场景纳入统一管理，优化成本、提升效果、做成可复用的服务。这种模式对业务方的门槛极低，任何团队都有一个可以在半天内跑通的起点。

4.2 一个场景从尝试到固化的完整路径

拿一个真实场景举例：人力资源部门想做一个简历筛选的辅助工具，自动总结候选人的优缺点。按照轻量中台的打法，整个过程可以这样走：

1. HR部门的技术接口人从模型网关获得一个试用密钥，使用我们预设的“通用文本总结”模型。
2. 他们用了几周时间，发现效果基本可用，但输出格式不稳定，有时优缺点混在一起。
3. 他们把案例反馈给中台团队，中台将“简历总结”定义为正式场景，并设计了专门的提示词模板，强制输出JSON结构。
4. 中台将模型路由切换到效果更好的专有模型，并针对简历解析做了预处理。
5. 场景正式上线，接入计量体系，HR部门每天能看到花费和调用量。

整个周期大概不到一个月。业务方自己参与了前两步的验证，到第3步时已经完全相信这套方案可行。这就是轻量闭环的意义——它让用户从“被动接受平台”变成了“主动共建平台”。

4.3 流量回放与回归测试：模型换代的保险带

模型升级或者提示词调整时，最令中台担心的是“某个场景变好，另一个场景变差”。传统的质量保障方式在AI时代有了一个新工具：流量回放与回归测试。

具体做法是，把一个场景历史请求的日志采集下来，重新用一个候选模型或新的提示词跑一遍，和线上的输出做对比。对比不能只看文本相似度，还得有人工抽检。我们在实践中会给候选版本生成一个差异报告，列出“主要变化点”和“疑似变差点”，由业务方决定是否接受。

这个流程听起来很常规，但它解决了AI中台的一个大难题：如何让模型升级不再“全凭感觉”。我还记得有一次我们想换一个成本更低的模型，通过回放测试发现，虽然整体输出质量持平，但在特定问法下回答风格变得特别生硬，业务方坚决要求保留旧模型。如果没有回放测试，这个细节根本不可能在上线前被发现。

5. 演进路线：从单团队试点到制度建设，不必一步跨到企业中台

轻型起步只是第一步，但它不代表永远小型化。中台的演进应该是有节奏、有路线的。我通常按三个阶段来规划AI中台的演进。

5.1 第一阶段：单团队试点，跑通全链路

第一个阶段，找一个意愿最强的业务团队合作，跑通“业务场景 → 统一网关 → 模型服务 → 效果反馈”的完整链路。这一阶段的目标非常纯粹：验证中台的核心价值假设，积累实操经验，找到业务方最关心的功能点。

选择试点团队时，我强调一个原则：选“痛点最痛”的团队，而不是“技术最强”的团队。技术强的团队会自己动手解决问题，反而不太依赖中台；痛点最痛的团队，才会认真配合你打磨链路。第一阶段通常持续4到8周。结束时，中台应当能回答三个问题：接入一个场景需要多少时间？成本大概是多少？效果由谁来评估？

这三个问题的答案，就是第二阶段的“招商说明书”。

5.2 第二阶段：三个业务方接入，固化沉淀

第二个阶段的目标是让至少三个不同业务方接入中台。注意，这里刻意强调“不同”，意味着要覆盖不同的业务形态——比如一个面向内部提效，一个面向外部客户响应，一个是偏向内容生产。场景差异越大，越能验证中台能力的通用性。

这个阶段，中台的职责开始从“服务支持”转向“能力沉淀”。之前业务方各自为战的方案（比如各自接的模型API、各自建的提示词、各自的向量库），在这个阶段应该被中台逐步接管。同时，中台应当开始制定一些“最低限度的规范”——比如接入审核标准、模型命名规范、成本分摊口径。规范的目的是保证一致性，不是为了管人。

三个业务方的接入过程，会倒逼中台的很多设计成熟起来。你可能会发现网关需要一个批量配额管理功能，或者提示词库需要一个分类体系。这些都是第一、二个业务方接入时不会遇到的，但第三个接入时，这些需求会变得尖锐起来。到这一步，中台的形态才算真正浮现，而不是靠PPT编出来的。

5.3 第三阶段：平台化与制度化，走向真正的中台

当接入场景达到一定数量（我们实践的体感是10个以上），且不同场景之间存在明显的共性能力时，才考虑把某些模块真正平台化。比如全公司统一的检索增强服务、统一的模型评测集、统一的规则引擎，这些这时候可以用更正式的工程能力和资源去建设。

同时，第三阶段需要把一部分“软规范”变成“硬制度”。比如预算审批制度：业务方要接入新场景，需要先提交成本预估和效果预期，由中台团队审核后开放额度。再比如模型评审制度：新的模型供应商要进入中台候选池，必须通过统一的安全测试和性能测试。这时的中台才算真正进入企业级基础设施的行列。

6. 写在后面：组织与文化的坑，比技术选型更难绕开

最后想聊几句更软但实际更硬的话题。AI中台建设面临的组织和文化挑战，很多时候比技术方案棘手得多。

6.1 中台团队怎么定KPI

很多人问中台团队的KPI应该怎么设。我的建议是：中台团队的绩效，不应该看他们自己产出了多少组件，而应该看接入场景的数量和业务的真实反馈。

这里有一个很经典但常被忽略的做法：中台团队的目标应该有一部分是由业务方来评分的。比如一个季度结束后，业务方说“中台帮我解决了什么问题、响应速度如何、效果是否稳定”，这些反馈直接决定中台成员的绩效奖金。这样做的好处是，从机制上逼着中台去服务业务，而不是关起门来造轮子。

6.2 与业务团队的协作边界

轻型中台特别强调“中台别什么都干”。很多中台团队为了显示存在感，主动帮业务方做需求分析、做效果运营，这其实是一种过度服务。过度服务短期看关系融洽，长期看业务方会失去对AI能力的独立判断力，中台也会陷入杂事之中。

正确的边界是：中台提供可复用的模型能力、工具和服务，业务方负责定义场景和评估业务价值。双方共同承担效果优化的责任，中台负责高质量地执行，业务方负责清晰地提出目标。如果某一方长期缺位，这个场景就应该暂停，而不是靠另一方死扛。

6.3 我自己的几点体会

翻了翻自己做AI中台的这些项目的记录，我印象最深的不是某个技术难点被攻克，而是“节奏感”这件事。AI中台的节奏，应该跟着业务成熟度走，而不是跟着技术热度走。业务还没验证就先把平台做大，是资源浪费；业务验证了却还停留在临时方案，是机会损失。轻型起步，本质上就是让基础设施的投入和业务的真实使用保持同频。

另外一个体会是：做AI中台的人，心态上要能接受“被替代”。你今天辛苦搭出来的组件，可能半年后发现商业产品已经做得更好，那时果断替换反而是一种成功，因为你的场景跑通了，价值验证了。中台不应该成为某个小组的自留地，它只是一个过渡态，一个让组织高效运用AI的服务性连接件。

如果你现在正准备启动AI中台建设，我给你的具体建议是：先想清楚三个业务场景的名字，再找一个能做统一入口的模型网关，然后把成本计量和效果反馈接到第一个业务上，别急着规划那十页架构图。走通这个最小闭环之后，你再回头看，会发现自己已经站在一座真正的中台工地上了。