第 26 章：成熟度模型、团队能力与路线图

26.1 方法齐全不等于组织能力成熟

客服 Agent 团队已经有评测脚本、数据集、Judge、看板和若干报告。但问题仍然反复出现：

数据集没人维护。
门禁被紧急发布绕过。
Judge Prompt 改了却没有版本记录。
Bad Case 归因后没人负责修复。
线上指标异常后没有固定响应流程。

这说明评测体系不只是技术问题，也是一种组织能力。

本章把全书方法收束为三件事：

用成熟度模型判断团队位置。
明确团队角色和能力矩阵。
给出 90 天落地路线图。

26.2 五级成熟度模型

企业 AI 评测体系可以分为五级。

等级	名称	典型表现
L1	脚本级	个人脚本、临时样本、手工报告
L2	工具级	有固定工具和部分自动化
L3	平台级	有数据、执行、报告和版本管理
L4	组织级	接入门禁、线上回流和跨团队治理
L5	行业领先	形成可复用标准、持续红队和行业方法

成熟度不是看工具数量，而是看评测是否能持续影响质量决策。

26.2.1 成熟度要按证据判断

团队经常高估自己的成熟度。判断成熟度时，应看是否有可检查证据，而不是看是否使用了某个工具。

判断问题	说明
样本是否有版本、来源、Owner 和淘汰机制	判断数据是否可治理
指标是否能映射到业务目标和风险	判断评测是否有效
Run 是否能复现模型、Prompt、知识库、工具和 Evaluator 版本	判断结论是否可信
评测是否能阻断发布或触发审批	判断质量是否进入决策
Bad Case 是否有归因、修复和回归	判断问题是否形成闭环
线上信号是否回流到离线评测集	判断体系是否持续更新
门禁豁免是否有审批和期限	判断治理是否可审计

如果这些证据不存在，即使平台界面完整、报告漂亮，也仍然不能称为成熟体系。

26.3 L1：脚本级

L1 团队通常有少量样本和脚本。

典型表现：

用表格保存样本。
用脚本批量调用模型。
人工看部分输出。
报告靠手工整理。
样本和结果难追溯。

L1 的目标不是建设复杂平台，而是先建立基本标准：

固定 Case Schema。
记录版本。
建立最小 Golden Set。
明确高风险样本。

26.4 L2：工具级

L2 团队开始有工具化能力。

典型表现：

有评测工具或内部小平台。
能自动跑部分数据集。
有简单 Judge 或规则评估。
能生成报告。
但门禁、线上回流和归因仍弱。

L2 升级重点：

建立 Regression Set。
引入版本血缘。
做 Bad Case 分类。
让评测结果进入发布评审。

26.5 L3：平台级

L3 团队有 EvalOps 平台雏形。

典型表现：

管理 Model、Prompt、Dataset、Evaluator、Run、Report。
支持批量执行和对比。
记录 Trace 和成本。
有可复现运行记录。

L3 的瓶颈通常不是工具，而是治理。

升级重点：

接入 CI/CD 和发布门禁。
建立 Owner 机制。
将线上 Bad Case 回流。
建立评测体系质量回检。

26.6 L4：组织级

L4 团队已经把评测纳入组织流程。

典型表现：

评测结果能阻断发布。
门禁豁免有审批和留痕。
Bad Case 有归因、修复、回归和防复发。
线上看板支持多角色决策。
安全红队和合规证据链持续运行。

L4 的重点是持续运营：防止数据老化、指标失真、门禁失权和团队标准分裂。

26.7 L5：行业领先

L5 团队不仅支撑内部应用，还能形成行业级方法。

典型表现：

评测标准可迁移到多个业务线。
有成熟的红队和安全研究能力。
有高质量垂类 Rubric 和专家网络。
能沉淀平台能力和最佳实践。
能用评测结果反哺数据生产和模型迭代。

L5 不是所有团队的短期目标。多数企业应先做到 L3-L4，把真实生产闭环跑稳。

26.8 组织治理：Owner 机制

评测资产必须有 Owner。

对象	Owner 职责
指标树	保证指标与业务目标一致
数据集	维护样本质量、版本、污染和老化
Evaluator	维护评估器准确性和漂移
门禁	维护阈值、豁免和发布规则
线上看板	维护指标口径和告警
Bad Case	推动归因、修复和回归
安全红队	维护风险样本和证据链

没有 Owner 的资产会迅速失效。

26.9 变更管理

评测体系自身也需要变更管理。

需要管理的变更包括：

评测集新增、删除和重分层。
Rubric 修改。
Judge Prompt 修改。
门禁阈值修改。
知识库、工具和 Agent 策略变更。
紧急发布和门禁豁免。

每次变更都要记录原因、影响范围、审批人和回归结果。

评测体系如果没有变更治理，分数会失去可比性，门禁也会失去权威。

26.10 团队角色

成熟评测团队通常包含多类角色。

角色	核心职责
评测方法负责人	指标、Rubric、实验设计
评测平台工程师	EvalOps 平台、执行引擎、数据血缘
数据 / 标注负责人	样本采集、标注、质检和污染控制
Agent 评测工程师	Tool、Trace、沙箱和执行评测
红队安全评测	攻击样本、安全门禁、合规证据链
评测产品 / 运营	看板、报告、流程和跨团队协作
领域专家	业务标准、Rubric 仲裁、高风险样本

一个人可以承担多个角色，但职责不能缺失。

26.11 能力矩阵

专业 AI 评测人才需要复合能力。

能力	说明
方法论	能从业务目标拆指标、样本和 Rubric
工程化	能构建自动化执行、版本血缘和平台能力
Agent 技术	理解 RAG、Tool、Memory、Workflow、Trace
统计实验	理解样本量、置信区间、版本对比和显著性
数据治理	维护数据质量、污染、老化和隔离
安全红队	设计攻击样本和安全门禁
业务抽象	把行业规则转成评测资产
组织推动	让评测进入发布、灰度和优化流程

评测负责人最关键的能力，是把技术证据转化为组织决策。

26.12 个人成长路径

AI 评测从业者可以按四个阶段成长。

阶段	重点
执行评测	跑样本、看结果、整理报告
设计评测	设计指标、Rubric、Case 和 Evaluator
建设体系	建平台、门禁、线上回流和归因闭环
影响组织	制定标准、推动发布治理和质量文化

从跑 Benchmark 到建设质量基础设施，是能力跃迁的关键。

26.13 90 天企业级评测体系启动路线图

一个团队可以用 90 天启动最小闭环。

第 1-30 天：建立最小评测资产

选择一个高价值场景，例如客服退款。
梳理业务目标和风险场景。
建立 100-300 条初始 Eval Case。
定义指标树和 Rubric。
建立 Golden Set 和高风险小集。
记录模型、Prompt、知识库和工具版本。

第 31-60 天：自动化和回归

建立自动化执行脚本或轻量平台。
接入规则、脚本、Judge 和人工复核。
建立 Regression Set。
记录 Run、Report、Trace 和成本。
对关键变更触发评测。
输出发布前质量报告。

第 61-90 天：门禁和线上闭环

接入 CI/CD 或发布审批。
设置高危门禁和灰度观察指标。
建立线上质量看板。
采集线上 Bad Case。
建立归因、修复、回归流程。
明确指标、数据、Evaluator 和门禁 Owner。

90 天目标不是做完整平台，而是让一个业务场景形成可运行闭环。

26.13.1 90 天路线图的风险控制

90 天启动路线图最常见的失败，是目标过大。团队一开始想同时覆盖所有业务线、所有模型、所有风险，结果样本质量不稳、平台尚未成型、门禁也无法落地。

更稳妥的做法是明确三条约束：

只选择一个高价值场景作为主战场。
只把少量 P0 / P1 风险接入硬门禁。
只建设足够支撑闭环的轻量平台能力。

风险	表现	应对
范围过大	多业务线同时铺开，样本质量下降	固定一个场景，形成样板后复制
平台先行	工具开发很多，评测标准不足	先定义 Case、Rubric、门禁，再平台化
门禁过重	大量指标阻断发布，研发绕开流程	只把红线指标设为硬门禁
人评过载	高低风险样本都进入人工	规则和 Judge 分流，人工聚焦争议和高风险
线上断流	Bad Case 没有进入回归	指定 Owner 和回流周期

路线图不是项目计划表，而是组织能力建设节奏。每 30 天都应形成可验证资产，而不是只完成会议和文档。

26.14 客服 Agent 三个月升级案例

客服 Agent 团队可以按以下节奏推进：

时间	目标	产物
第 1 月	建立退款场景评测基础	指标树、Golden Set、风险清单
第 2 月	接入自动回归	Eval Case、Judge、Run Report、Trace
第 3 月	接入发布和线上闭环	门禁、看板、Bad Case 归因、Regression Set

三个月后，团队至少应做到：

Prompt 修改自动触发核心回归。
知识库更新触发 RAG Case。
退款工具变更触发 Tool / Trace Case。
P0 安全失败阻断发布。
线上高价值 Bad Case 能进入归因和回归。

这时团队已经从脚本级进入更稳定的组织化闭环起点。

26.15 交付物一：AI 评测体系成熟度模型

等级	核心能力	升级重点
L1 脚本级	能跑样本	Schema、版本、Golden
L2 工具级	能自动评测	Regression、血缘、归因
L3 平台级	能复现和对比	门禁、Owner、线上回流
L4 组织级	能影响发布和治理	持续运营、安全合规、质量回检
L5 行业领先	能形成行业方法	标准化、跨业务复用、专家网络

成熟度评估应按证据判断，而不是按团队自评。

26.15.1 成熟度诊断问题

团队可以用下面的问题判断自己处于哪个阶段。

诊断问题	若答案为否，说明什么
核心评测数据是否有版本、来源、Owner 和淘汰机制	数据资产仍不稳定
每次评测 Run 是否能复现模型、Prompt、知识库、工具和 Evaluator 版本	版本对比不可信
高风险失败是否能阻断发布	评测尚未进入真实决策
门禁豁免是否有审批、期限和补偿措施	治理不可审计
线上 Bad Case 是否能进入归因和回归	离线体系会逐渐失效
Judge 或规则评估器是否定期回检	评估器可能漂移
评测结果是否能指导具体 Owner 修复	报告不能转化为改进
安全红队样本是否持续维护	安全能力可能停留在一次性检查

如果多数问题回答是否定的，团队不应急于追求更复杂平台，而应先补齐版本、数据、门禁和回流这些基本治理能力。

26.16 交付物二：评测团队角色与能力矩阵

角色	方法论	工程化	Agent 技术	统计实验	业务抽象	组织推动
评测负责人	高	中	中	高	高	高
平台工程师	中	高	中	中	中	中
Agent 评测工程师	高	高	高	中	中	中
数据负责人	中	中	中	中	高	中
红队安全	高	中	高	中	高	高
评测产品 / 运营	中	中	中	中	高	高
领域专家	中	低	低	中	高	中

团队不一定一次配齐所有专职人员，但能力必须有人覆盖。

26.17 交付物三：90 天企业级评测体系启动路线图

阶段	关键任务	验收标准
1-30 天	场景、指标、样本、Rubric	能对一个核心场景给出可信离线报告
31-60 天	自动执行、版本血缘、回归	能稳定比较候选版本
61-90 天	门禁、线上监控、Bad Case 闭环	能影响发布并处理线上问题

路线图应从一个业务场景开始，而不是一开始覆盖所有应用。

26.18 终稿级收束：评测体系的完成定义

企业级 AI 评测体系的完成定义，不是“有多少样本”或“跑了多少分”，而是能否稳定回答六个问题：

这个 AI 系统要为业务创造什么价值？
哪些失败会造成不可接受的损失？
当前版本在哪些场景可靠，在哪些场景不可靠？
候选版本能否发布、灰度、阻断或回滚？
失败发生后，能否定位根因并完成修复验证？
线上新问题能否回流为长期质量资产？

如果一个团队能持续回答这六个问题，就已经从“跑评测”进入“管理 AI 质量”。这也是本书所有章节的共同指向。

26.19 本章小结

企业级 AI 评测的终点不是工具，而是组织能力。

成熟评测体系要有数据、指标、Evaluator、平台、门禁、线上回流、归因、修复和治理机制，也要有明确 Owner 和跨团队协作流程。

本书从传统测试失效开始，沿着业务目标、风险场景、分层对象、数据、Evaluator、Trace、平台、门禁、监控、归因、优化、安全、垂类和组织化一路展开。最终目标只有一个：让企业能够用可验证、可复现、可行动的方式管理 LLM 与 Agent 系统质量。