企业官网建设流程全解析

最近在牵头做一个内部AI工具平台，翻了翻项目仓库，第一个文档就是01_AI工具平台项目概述.md。别小看这个文件，项目能不能顺利推进，很大程度上在它落笔那一刻已经定了。很多人觉得“概述”就是把目标、架构、里程碑拼一页PPT，差不多写写就行，我一开始也这么想，结果项目做到一半就发现，架构边界和优先级如果没在一开始对齐，后面每个环节都在还债。

这篇文章就围绕这份概述文档展开，把我在文档里拆解的项目定位、分层架构、技术选型、核心流程和落地节奏重新整理一遍。它适合两类人：一类是准备从零搭建AI工具平台的开发者或技术负责人，另一类是打算把分散在各处的大模型能力统一收口到公司内部体系的团队。你不需要已经有多深的AI基础，但最好对后端服务和API网关有个大致概念。看完你会发现，AI平台项目真正难的不是模型调用，而是把“接入、路由、治理、计量”这件事想清楚。

1. 项目定位：为什么要在现在做一个AI工具平台

1.1 先说结论：概述文档要回答四个问题

写概述文档之前，我给自己定了一个规矩：它必须直接回答四个问题——为什么做、做到什么程度、由哪些系统组成、什么时候能交付。少了任何一个，后面就会出现“商务说能承诺，研发说没排期，测试说需求不明确”的混乱场面。

所以文档开头两页我没有放任何愿景口号，而是用一张表格把四个问题的答案列出来：场景是“统一接入多种大模型能力”，范围是“只做平台不做模型”，交付物是“网关、管理台、计量与审计”，节奏是“四周跑通MVP、八周完成试点”。这些结论在评审会上被反复挑战过，但正因为一开始就写死了，后面每次需求扩张都要回头对照这张表，省掉了很多无谓的争论。

1.2 背景：工具碎片化带来的真实痛点

我们当时面临的局面，很多团队应该都遇到过：商业大模型API、开源模型私有化部署、业务方自己微调的小模型，散落在各个项目里。每个模型都有自己的调用方式，有的走HTTP接口，有的只能用特定SDK，有的需要先加载权重再排队推理。权限体系各搞一套，成本数据对不上，审计日志更是不知道谁记了谁没记。

最尴尬的是，业务方来问“你们支持哪几个模型”的时候，没人能一句话说清楚。大家缺的从来不是模型，而是一个统一出口：把模型当成可插拔的资源池，上层应用只面对一个稳定的平台接口。这个认知是概述文档里最重要的一条判断，后续所有架构决策都是从这个判断推导出来的。

1.3 目标与边界：三个核心诉求与一条红线

概述文档里我明确了三个核心诉求，简单说就是“接入、治理、体验”。

接入指的是新模型从接入到上线的时间，目标是把行业里常见的“周级别”压缩到“小时级别”；治理指的是权限、配额、成本、审计都在同一个后台完成，不让每个应用自己另搞一套；体验指的是上层应用面对平台时，接口和鉴权模型保持长期稳定，不能因为背后换了个模型就要求应用改代码。

边界部分我划了一条红线：平台不生产模型，不自研基座模型，只做“连接”和“治理”。这一点必须写进文档，因为中途一定会有各种声音说“我们应该自己训一个模型”，一旦没有这条红线，项目就会被拉进一个完全不同的战场——数据、算力、算法人员，全是无底洞。写清边界不是保守，是让团队始终知道劲该往哪使。

提示：如果你也在写类似文档，建议把“不做什么”单独列一节，而且放在“做什么”后面紧挨着。只写目标不写边界，是概述文档失控的第一原因。

2. 整体架构与模块拆解

2.1 分层架构：把平台拆成五层

整个平台我在文档里划分成了五层：接入层、编排层、服务层、数据层、治理层。

接入层是唯一的API入口，负责鉴权、限流、协议适配；编排层处理工作流定义、模型路由、Agent链路；服务层承载模型代理、知识库检索、提示词模板、会话记忆这类通用能力；数据层负责请求日志、成本明细、用户反馈的存储；治理层则横向覆盖权限、配额、审计、监控告警。

这么分层的逻辑很朴素：每一层都能独立演进，故障边界也清晰。网关挂了不会拖累编排层，计量数据库压力大也不会影响在线请求。很多团队一开始就把所有逻辑写在一个服务里，后面想拆的时候已经骑虎难下，所以概述阶段就应该把这五层画出来，哪怕第一版实现时有些层先不拆服务，但边界要在所有人脑子里成立。

2.2 核心模块：按优先级排出的第一版清单

架构定了，下一步就是模块粒度。我在文档里按P0、P1、P2排了一个模块清单，避免一上来就想把什么都做出来。

P0是MVP必须完成的，P1是试点阶段要有的，P2可以等首批用户跑起来再排期。这个优先级列表在评审时会有很大争议，尤其是“反馈闭环”被业务方提到P0，理由是没反馈没法优化效果。我的处理方式是：MVP阶段先通过日志和线上抽评代替正式反馈系统，等有真实用户了再做闭环。先有用户，再有反馈，这个顺序不能反。

2.3 请求生命周期：一条请求从接入到返回

概述文档里最核心的一张图，不是架构图，而是“一条请求的生命周期”。我用文字把它推演了一遍：

客户端调用平台网关，网关先做鉴权和配额校验，通过后进入路由策略模块，根据延迟、成本、效果分选定具体模型，再拼接提示词模板和上下文，最后调用上游模型服务。上游返回后，网关同步记录日志和成本明细，然后把结果返回给调用方。整个过程看起来只是“请求-转发-返回”，但每一个环节都对应一个模块和一个数据库表。

把这条链路写清楚最大的价值，是让所有人都知道：一次调用从进入到返回，经过了哪些系统、产生了哪些数据、哪些地方可能失败。项目做到一半，团队经常为“这个功能应该放在哪个模块”吵架，只要回头对照这条生命周期，答案往往一目了然。

3. 技术选型与关键决策

3.1 模型接入层：统一网关和路由策略怎么定

技术选型部分，我第一个写的是网关。统一网关不是简单的反向代理，它要干三件事：协议适配、动态路由、限流熔断。

协议适配解决“不同模型接口不一样”的问题，网关对外提供一套统一的接口格式，内部再转成各上游模型自己的格式。动态路由解决“多个模型都能回答同一个问题”的情况，给每个模型定义一个可实时调整的打分机制。限流熔断则是保护平台自己不被打垮，某个上游模型变慢或报错时，不能让它拖死所有请求。

路由策略我用了一个加权打分的方案，每个候选模型在四个指标上打分，再加权求和选最高的。

这个方案足够简单，也能解决实际问题。要注意的是，路由分不是算一次就完，要周期性地重算，比如每分钟刷新一次得分，不能硬编码“主备切换”，否则线上一个模型波动你就得手动改配置。

3.2 编排层：工作流与Agent运行时怎么选

编排层的选型，我在文档里特意区分了“固定流程”和“动态Agent”两个概念。

固定流程很好理解，比如“先做意图识别，再走知识库检索，最后调用大模型生成答案”，这种流程的状态是有限的、确定的，用状态机或任务DAG就能解决。难点在于动态Agent：模型要能自己决定调用哪个工具、什么时候需要多轮对话、怎么管理中间状态。

我给出的决策是：初期只做固定流程编排，不开放自由Agent能力。因为自由Agent的调试成本极高，边界不可控，用在内部工具上很容易把一个小问题放大成整条链路的不稳定。等固定流程的成功率稳定在90%以上，再考虑引入Agent运行时去处理“计划-执行-反思”这类动态链路。技术选型不是选最潮的，而是选当前阶段能驾驭的。

3.3 三个否决项：避免在选型上翻车

选型章节的最后，我列了三个否决项，是在项目概述阶段就要写进“非功能性约束”里的。

第一个是供应商锁定：所有上游模型必须可替换，网关层不准绑定任何一家模型的专用协议。今天用这家，明天换那家，对上层应用应该是无感的。第二个是上下文地狱：请求日志与会话状态必须分开存储，不能把历史消息全塞进模型上下文里。很多应用越用越慢，就是挤在一根狭窄的上下文通道里。第三个是成本失控：每个应用必须绑定成本上限，超过上限自动熔断或降级到备用模型。

这三个否决项，本质上都是在回答同一个问题：平台会不会变成一个人的玩具，或者一个大坑。选型一时爽，填坑火葬场，提前把否决项写清楚能避免很多“技术可行但产品不可控”的悲剧。

4. 核心场景与交互流程设计

4.1 管理员视角：接入一个新模型需要几步

平台上接一个新模型，我定的目标是“小时级”。为了达到这个目标，接入过程必须配置化，而不是写代码。

管理员在模型管理台上传模型配置，包括上游接口地址、鉴权方式、模型名称、上下文长度、限流参数；系统发起连通性测试，确认基础调用成功；通过后配置模型别名和路由权重，先在灰度环境放量；观察监控面板上的延迟、成功率、成本数据；最后点击全量发布。

每个步骤都有标准操作流程，唯独“模型效果评估”不能自动化完事，要靠人工在线抽查。我见过很多团队快速接入了模型，但没人验证回答质量，上线后业务方发现效果不对，只能全线回退。所以“接入快”不等于“上线快”，质量确认永远是管理员流程里不可跳过的一环。

4.2 开发者视角：从注册到调通全流程

开发者接入平台的流程我花了不少心思设计，因为开发者体验直接决定平台能不能推广开。

登录平台后自助申请API Key，选一个模型名（比如“备用模型A”这种平台别名），系统立刻生成示例代码和在线调试页。这里我特别强调，示例代码必须从真实网关配置里自动生成，不能靠文档维护者手写，否则文档和线上不一致，开发者会踩到“示例明明能跑但线上报错”的坑。

在线调试页比文档有用得多，开发者可以直接在页面上传参数，看到真实的返回结果和计费Token数。我建议任何AI工具平台都把“调试器”当作第一优先级功能，它比一万字的使用手册更能降低接入门槛。

4.3 运营者视角：用量统计与成本分摊怎么算

计量与成本分摊是平台是否可信的试金石。我的方案是按组织、应用、模型三个维度做成本分摊。

每晚定时任务把当天的请求日志聚合成账单数据，生成一张分摊报表，再推送到内部财务系统。报表字段包括：日期、组织、应用、模型、调用次数、总Token数、费用、配额占比。业务方如果有疑问，可以直接从请求日志反查某一次调用的明细。

这里有个容易扯皮的点：Token统计口径。上游返回一个Token数，网关自己计算的可能是另一个数，两边不一致时以谁为准。我定的规则是“以网关计费口径为准，上游返回数据仅作参考”，同时保留原始请求日志至少30天，方便重算。这条规则我写进了概述的非功能性约束，后来真的帮我们避免了一次不小的财务纠纷。

注意：计量模块看起来枯燥，但它是平台能否让多方安心使用的信任基础。概述文档里如果没有计量与审计方案，后面补会非常被动。

5. 里程碑规划与验收标准

5.1 四阶段推进：先跑通再跑顺

落地节奏我拆成了四步，每步不贪多，只完成一个相对完整的目标。

阶段一是单模型接入的POC，两周内让平台网关成功代理一个上游商业模型，打通最基本的调用链路。阶段二是统一网关与管理后台的MVP，四周完成，支持模型配置、API Key管理、基础计量和日志查询。阶段三是核心应用迁移与计量完善，四个星期把三个试点应用迁到平台上，跑通成本分摊和审计查询。阶段四是开放更多模型与规模化推广，后续持续迭代。

分阶段的目的很简单：每四周都能看到可演示的成果，团队和业务方都能保持信心。如果一上来就规划一个需要六个月的大全栈，中间没有任何交付节点，项目大概率会在第三个月被质疑甚至被砍掉。

5.2 验收清单：每个模块的合格线

概述文档里我还列了每个模块的验收标准，没验收标准的需求等于没需求。

这些数字不是随便拍的。网关的“上游P95加100ms”是基于“平台自身消耗尽量低”的原则定的，预算放得很松，目标就是不让平台成为链路里的明显瓶颈。账单误差小于1%保留了一些过程误差的空间，但要求财务对账时能解释清楚所有差异来源。验收标准在文档里写得越早，开发和测试就有明确的靶子。

5.3 风险预案：最坏情况发生时怎么办

最后我在文档里写了三类最坏情况的风险预案。

第一类是全部商用模型服务故障，网关自动把请求路由到备用模型，同时开启降级策略，给调用方返回一个降级提示而不是空响应。第二类是计量数据丢失，网关层保留原始请求日志最少30天，可以在日志基础上重算账单，不能出现“钱算不清”的情况。第三类是某个应用恶意刷量，配额上限加异常检测告警，连续多次超限自动封禁应用Key并通知管理员。

有人会觉得风险预案是后话，等出了问题再写也不迟。但经验告诉我，预案写不写完全是两码事：不写预案，故障发生的时候团队是恐慌的；写好预案，故障发生时团队是在执行方案。恐慌和执行，结果天壤之别。

6. 落地过程中最常见的五个坑

6.1 定需求的人不看概述文档

第一个坑是概述文档写完了，但真正拍板的人一眼都没看。评审会上大家各说各的，最后开完会文档就躺在共享盘里吃灰。

我的经验是：概述文档必须在线评审时从头到尾读一遍，不能默认大家都会自己看。并且在文档末尾放一栏“同意/反对/保留”，要求每个关键决策人都留下明确意见。这不是走流程，而是为了后续出现分歧时有一个追溯依据。

6.2 一上来就追求“完美架构”

第二个坑是架构设计过度。第一版就想做可视化编排、模型自动评测、多租户隔离、跨区域容灾，结果做了半年连一条完整链路都没跑通。

正确的做法是MVP只做一条最小的闭环：应用调用网关，网关调用一个上游模型，记录日志，返回结果。这条闭环跑通之后，所有的架构能力都往这条链路上做增量。完美架构不是设计出来的，是一步步吃出来的，急于求成只会产出空中楼阁。

6.3 只规划功能，不规划数据

第三个坑是概述文档写了一大堆功能，却没有人提到数据怎么存、存多久、谁有权访问。Token用量、用户反馈、模型输出样本这些数据，是平台后面做效果优化的基础资产。

我在项目第一天就建立了对象存储的目录规范和数据库表分区原则，例如“反馈数据按组织隔离，模型输出样本只保留必要业务字段”。等有了真实用户和真实数据再补数据治理方案，已经太晚了，历史数据可能已经存得乱七八糟。

6.4 忽视安全审计与内容合规

第四个坑是忽略大模型输出本身的风险。模型生成的内容不可控，平台作为中间层，必须把审计责任明确下来：每一次调用的输入输出都要有日志，特定场景下要接敏感内容检测，还要给用户提供申诉入口。

这一块在概述文档里不是“可选项”，而是“必选项”。特别是面向企业内部的平台，如果审计没做到位，一旦出了问题，责任会落在平台团队头上。安全审计是护身符，不是业绩负担。

6.5 把“技术可行性”误当成“产品可行性”

第五个坑是技术团队容易有的执念：既然平台能接入十个模型，那就把所有模型都开放给所有用户。

结果就是用户面对一堆选择无所适从，也不知道哪个模型适合自己。我在文档里要求每个模型都必须打上“适用场景标签”，例如“代码生成”“通用对话”“低延迟分类”，同时限制普通用户只能看到与自己权限相关的模型。技术可行性强调的是“能”，产品可行性强调的是“适合”，这个区别在概述阶段就要分清楚。

最后再说一点经验

我这个项目落地到现在，最深的体会是：概述文档写得好不好，判断标准不是词藻多专业，架构图画得多炫，而是你把它拿给一个从没参与过的后端同事，他看完能不能说出三句话——这个平台对外提供什么、请求经过哪几个环节、日志和账单存在哪里。如果他能说出来，这份概述就算立住了。

另外留一个小技巧：概述文档里的所有数字，包括“小时级接入”“可用性99%”“账单误差小于1%”，在初稿阶段都标注“当前为预期值，以压测和线上实测为准”。这样后续数据有偏差时，团队有修正空间，也不会因为一个拍脑袋的数字互相甩锅。把这个文档放在代码仓库docs目录里，和代码一起评审、一起更新，它会成为整个项目最重要的一份资产。