做了五年中后台，我以为表格+表单就是一切，直到大模型管理后台让我重新理解“管理“二字

AI小白龙*

165人浏览 · 2026-07-15 13:44:27

AI小白龙* · 2026-07-15 13:44:27 发布

我做了五年中后台前端。 antis 系统、CMS、CRM、ERP、运营平台，什么表格、表单、权限树、审批流，闭着眼都能搭。我的技术栈很稳定：Ant Design Pro、React、TypeScript、ProTable、ProForm，再配一个RBAC权限模型。。

当我接到"大模型管理后台"这个项目时，我的第一反应是：不就是管理几个模型、几个Prompt、几个知识库吗？表格加表单，搞定。

三个月后，我被自己打脸。大模型管理后台不是传统的资源管理，它管理的是一个"会变化、会出错、会消耗Token、会影响用户体验"的复杂系统。表格和表单装不下它。

一、模型管理：模型不是一行记录，而是一个"能力单元"

传统中后台管理一个"资源"，比如一个商品、一个用户，就是CRUD。但大模型不一样。一个模型有很多维度：

基础属性：模型名称、版本、提供商、API endpoint、上下文长度；
能力参数：temperature、top_p、max_tokens、频率惩罚、存在惩罚；
成本参数：输入Token单价、输出Token单价、缓存命中率；
可用性配置：哪些业务线能用、哪些场景能用、QPS限制、并发限制；
安全策略：敏感词过滤、输出审核、速率限制；
状态：在线、灰度、下线、仅测试。

这些如果全塞进一个表格，列数能到二十多列，根本没法看。我最后设计了一个"模型卡片+详情抽屉"的结构：

列表页用卡片展示核心信息：模型名、状态、当前调用量、平均延迟、成本趋势；
点击卡片打开详情抽屉，分Tab展示配置、监控、权限、日志；
模型能力参数用可视化滑块调节，实时显示推荐范围；
版本切换有明确的"设为默认"流程，避免误操作影响线上。

最有意思的是"模型灰度发布"。新模型上线，不能一刀切切换。我们做了一个流量调节器，可以按百分比、按用户分群、按业务线逐步放量。前端用ECharts实时显示新旧模型的成功率、延迟、成本对比，运营同学可以看着数据做决策。

二、Prompt 版本管理：让"提示词"像代码一样被管理

Prompt 是大模型应用的逻辑核心。一个业务可能有几百个Prompt，每个Prompt又在不断迭代。管理中后台必须让Prompt的变更有迹可循。

我设计了一个Prompt管理模块，包含：

列表视图：按业务线、场景、状态筛选；
版本树：每个Prompt的历史版本按时间线展示，可以对比任意两个版本；
在线状态：当前线上用的是哪个版本，哪些版本在A/B测试中；
效果指标：每个版本的调用量、通过率、用户满意度、Token消耗。

版本对比是一个重点功能。Prompt通常包含自然语言、变量占位符、Markdown示例。普通文本diff会把一个意思完整的句子拆得支离破碎。我引入了语义diff：对变量、条件块、Markdown结构分别处理，只对真正语义变化的部分高亮。

比如下面两个版本：

V1: 你是一个 helpful 的助手。
V2: 你是一个 helpful 且专业的助手。

diff 只高亮"且专业的"这几个字，而不是把整行标红再标绿。

我们还给Prompt版本加了"标签"系统：production、staging、experiment、draft。发布流程必须走审批：draft → staging → production。这个流程让Prompt变更不再随意，降低了线上风险。

三、知识库分块可视化：RAG 的"原材料"必须看得见

大模型应用很多用RAG架构，需要维护知识库。知识库里的文档会被切分成chunks，然后做Embedding入库。管理中后台要能看到这个切分过程和结果。

我设计了一个"知识库分块可视化"页面：

左侧是文档树，点击一个文档，右侧显示原文；
中间是分块视图，用不同颜色标注每个chunk的边界；
点击一个chunk，显示它的Embedding向量、相似度分布、被检索命中次数；
支持调整chunk大小和重叠策略，实时预览新的分块结果；
显示"未命中查询"：用户问了但知识库没召回的问题，帮助运营补全知识库。

这个可视化价值很大。有一次，运营同事发现很多用户问"退款多久到账"，但知识库里的相关文档被切成了很小的chunk，导致上下文丢失。调整chunk大小和重叠度后，召回率提升了30%。

我还加了一个"检索模拟器"：输入一个查询，系统显示它会被分成哪些chunk、每个chunk的相似度分数、最终拼进Prompt的上下文。这个工具让运营能直观调试RAG效果，不需要懂算法。

四、会话回放：不是聊天记录，而是"问题现场"

传统客服系统也有会话记录，但那是人与人对话。大模型应用的会话回放，要展示的是"人与AI系统"的完整交互过程，包括：

用户输入；
系统执行的每个步骤（检索、调用工具、调用模型、后处理）；
每个步骤的输入输出；
使用的Prompt版本；
调用的模型和参数；
消耗的Token和成本；
最终返回给用户的答案；
用户反馈（点赞、点踩、重新生成）。

我把会话回放设计成时间轴+树状结构。简单对话用时间轴就够了；复杂Agent调用用树状结构展示每个节点的执行过程。节点状态用颜色区分：成功、失败、超时、被跳过。

点击任意节点，右侧显示详细信息。比如点击模型调用节点，能看到完整的Prompt、返回的原始输出、解析后的结果、耗时、Token数。这让问题排查非常高效。

有一次用户投诉"AI回答错误"。我打开会话回放，发现检索节点召回了一篇过期的文档。问题不是模型错了，是知识库没更新。如果没有回放，我们可能要花几个小时才能定位。

五、Token 计费与 RBAC 权限：成本和安全是管理者的底线

大模型应用是有"成本意识"的系统。每次调用都要花钱，而且花得不少。管理中后台必须让管理者清楚看到钱花在哪里。

我设计了一个Token计费看板：

按时间维度：今日、本周、本月、自定义；
按模型维度：每个模型的调用量和费用；
按业务线维度：每个业务线用了多少Token；
按用户/会话维度：Top消费用户、异常消费；
成本预测：根据当前趋势预测下个月费用。

还有一个"配额管理"功能：给每个业务线、每个用户设置月度Token配额，接近阈值时发预警，超过后限制调用或切换到低成本模型。这个功能的实现需要前端和后端配额系统配合。

RBAC权限在大模型管理后台也变得更重要。谁能改Prompt？谁能上线模型？谁能看用户会话？谁能看成本数据？这些权限必须细分。我们设计了角色：

超级管理员：全部权限；
算法工程师：模型管理、Prompt编辑、实验配置；
运营人员：知识库管理、会话查看、用户反馈处理；
财务人员：成本看板、配额管理；
审计员：只读权限，查看所有操作日志。

权限控制到按钮级别。比如"设为默认模型"按钮，只有超级管理员和指定算法负责人能看到。

和操作权限配套的是操作审计。大模型后台的每次敏感操作都要记录：谁、什么时候、改了什么、改之前是什么。我们做了一个审计日志页面，可以按操作类型、操作人、时间范围筛选。关键操作（如Prompt上线、模型切换默认版本、配额调整）要求填写操作理由，并且会发送企业微信通知给相关Owner。这套审计机制，在上线前就被法务和合规团队重点Review过，因为它关系到数据安全和责任追溯。