企业 LLM 平台建设路线：分四期，别想一步到位

1. 本节产出

一份四期演进路线图（含每期的目标、范围、验收标准、投入估算），以及三个真实失败案例说明为什么不能一步到位。

2. 前置依赖

02 篇与 03 篇的核心内容
理解企业内多团队协同的约束

3. 为什么「平台一步到位」必然失败

三个真实案例：

案例一：先建平台后找场景。 某公司投入 6 个月做「企业 AI 中台」，包含网关、编排、知识库、Agent 框架。上线后发现：业务团队不知道用来做什么，只有 2 个团队接入，且都是边缘场景。一年后平台被边缘化。

案例二：每个团队各建一套。 另一家公司没有统一规划，A 团队做客服 RAG、B 团队做代码助手、C 团队做文档问答。结果是三套向量库、三种权限模型、三份账单。一年后想统一，迁移成本比从零做还高。

案例三：跳过治理直接铺开。 某公司鼓励全员用 AI，三个月后：API Key 散落在几十个仓库、月账单 40 万无法归因、有团队把客户数据传给了公有云模型。然后紧急刹车，全盘重来。

共同教训：

教训	结论
没有场景的平台是空壳	场景驱动，不是平台驱动
各自为战必然重复建设	需要在第二期就沉淀共享能力
治理不能后置	治理能力要跟着场景一起长，不能等出事再补

4. 核心原理

4.1 四期演进

第一期（0-3 个月）：单点突破
    选一个高价值场景做透，跑通端到端
    沉淀：模型适配、基础成本统计
    验收：一个生产应用 + 可量化的业务收益

第二期（3-6 个月）：能力复用
    第二个场景接入，抽出共享组件
    沉淀：模型网关、统一权限、RAG 底座、成本归因
    验收：新场景接入成本 < 第一期的一半

第三期（6-12 个月）：平台化
    多团队自助接入，配额与治理完善
    沉淀：自助接入流程、配额管理、审计合规、可观测
    验收：3+ 团队自助接入，账单可按团队归因

第四期（12 个月+）：优化与深化
    私有化、模型微调、成本深度优化
    验收：成本下降 30%+，核心场景私有化

第一期的唯一目标是「证明价值」，不是建平台。很多团队第一期就想做通用能力，结果既没证明价值也没建成平台。

4.2 每期的范围边界（明确「不做什么」）

期	做	不做
一期	单场景、单租户、基础观测	多租户、自助接入、复杂编排
二期	共享网关、权限模型、第二个场景	Agent 平台、私有化
三期	自助接入、配额、审计、多场景	模型训练、跨云
四期	私有化、模型优化、成本深度治理	—

明确「不做什么」比「做什么」更重要。范围蔓延是这类项目失败的首要原因。

4.3 场景选择的评估矩阵

维度	说明	权重
业务价值	能省多少钱/多少时间，可量化	高
数据可得性	文档/数据是否已数字化且质量合格	高（常被低估）
容错度	出错的代价是否可接受	高
技术可行性	当前模型能力能否覆盖	中
推动力	有没有业务方愿意配合	中

「数据可得性」是最常被低估的一维。很多想法很好，但文档散落在个人电脑、格式混乱、版本冲突——光整理数据就要三个月。评估场景时先看数据。

4.4 投入估算参考

期	人力	周期	主要成本项
一期	2-3 人	2-3 月	人力为主，模型费用小
二期	3-5 人	3-4 月	人力 + 模型费用上升
三期	5-8 人	6 月	人力 + 平台运维 + 模型费用
四期	视规模	6 月+	GPU / 私有化硬件投入显著

模型费用在第三期会成为显著支出，这也是为什么成本治理要提前布局（见 04-07）。

5. 代码走查（PoC 与文档）

5.1 ADR（架构决策记录）模板

markdown

# ADR-001：模型接入方案

## 状态
已接受 · 2026-10-03

## 背景
需要接入多家模型厂商做灾备。团队有 Spring 技术栈，
无专职算法工程师。

## 决策
统一走 OpenAI 兼容协议，通过 Spring AI 的 OpenAiChatModel 接入；
厂商差异配置化；自研 ModelRouter 做路由与降级。

## 备选方案
A. 各厂商官方 SDK：维护成本高，每家一套 API
B. 自研协议抽象层：工作量不划算，框架已提供

## 后果
- 正：切换厂商零代码改动；新人上手快
- 负：厂商独有特性不可用；需逐模型实测能力

ADR 是这一篇的关键交付物。它记录了「为什么这么选」，半年后新人问「为什么不用 LangChain」时能直接翻出来。

5.2 路线图文档结构

architecture/
├── README.md               # 一页纸：现状、目标、路线
├── roadmap.md              # 四期路线（本节产出）
├── ADR/
│   ├── 001-model-access.md
│   ├── 002-vector-store.md
│   ├── 003-multi-tenant.md
│   └── ...
├── diagrams/
│   ├── c4-context.svg      # 系统上下文
│   ├── c4-container.svg    # 容器视图
│   └── deployment.svg      # 部署视图
├── cost-model.xlsx         # 成本测算模板
└── poc-plan.md             # PoC 计划

5.3 一期的最小架构

yaml

# 一期只做这些，不要多
services:
  app:                      # 单应用，内含 RAG 与 Agent
    image: your-app
  pgvector:
    image: pgvector/pgvector:pg16
  redis:
    image: redis:7-alpine
  prometheus + grafana:     # 基础可观测

一期不要引入：服务网格、消息队列、分布式向量库、K8s 编排复杂度。能单机跑就单机跑，等真的需要再拆。

6. 跑起来

本节产出以文档为主，验证方式是「评审通过」：

bash

git checkout ch04-01-roadmap
# 产出物
open architecture/roadmap.md
open architecture/ADR/001-model-access.md

自检清单：

检查项	通过标准
场景明确	一期只有一个场景，且有量化收益目标
边界清晰	每期都写了「不做什么」
数据评估	已确认数据可得性（不是「应该可以」）
ADR 齐全	至少 3 个关键决策有记录
估算有依据	人力与成本估算有推导过程

7. 生产避坑

第一期的目标是证明价值，不是建平台。把通用能力建设放在价值证明之前，是本类项目最常见的失败模式。正确顺序：先用最直接的方式做一个能用的应用 → 证明价值 → 再沉淀平台。
评估场景时先看数据可得性。想法很好但文档散乱、格式混乱、版本冲突的场景，光数据整理就会吃掉整个一期的工期。这一步不能想当然，必须实际抽查 20 份文档。
明确写出每期「不做什么」。范围蔓延是渐进的（每次加一点），等发现时已经超期。写在文档里的边界，是抵御范围蔓延最有效的手段。

8. 延伸与锚点

思考题：多模型接入怎么做成可路由、可降级的？（答案在下一课时：模型网关）
代码锚点：git checkout ch04-01-roadmap
下一课时：04-02 模型网关与路由降级
对应课件：L04-01 建设路线图

企业 LLM 平台建设路线：分四期，别想一步到位 ​

1. 本节产出 ​

2. 前置依赖 ​

3. 为什么「平台一步到位」必然失败 ​

4. 核心原理 ​

4.1 四期演进 ​

4.2 每期的范围边界（明确「不做什么」） ​

4.3 场景选择的评估矩阵 ​

4.4 投入估算参考 ​

5. 代码走查（PoC 与文档） ​

5.1 ADR（架构决策记录）模板 ​

5.2 路线图文档结构 ​

5.3 一期的最小架构 ​

6. 跑起来 ​

7. 生产避坑 ​

8. 延伸与锚点 ​