AI测试评分表怎么设计：从主观感觉到结构化评估

做 AI 测试时，很多团队都会遇到一个很现实的问题：

AI 输出不像传统功能那样只有“对”或“错”，那测试结果到底怎么判断？

比如同一个 AI 功能，不同人看完输出后，评价可能完全不同。

测试同学说：

感觉还可以，但有些地方不够完整。

产品同学说：

这个回答太长了，不适合用户看。

研发同学说：

这不是模型问题，可能是 Prompt 或检索的问题。

业务方说：

看起来能用，但我不敢完全信。

最后大家很容易停在一句话：

这个效果感觉一般，还需要优化。

问题是，这种结论很难推进后续工作。

因为它没有回答清楚：

• 到底哪里不好？
• 是准确性问题，还是完整性问题？
• 是格式问题，还是幻觉问题？
• 这版比上一版好还是差？
• 能不能上线？
• 哪些问题必须先修？

所以 AI 测试想要真正落地，必须从“感觉判断”走向“结构化评估”。

而最简单、最实用的工具，就是：

AI 测试评分表。

这篇文章就专门讲清楚：

AI 测试评分表怎么设计，怎么适配不同场景，怎么用它支撑上线判断。

---

一、为什么 AI 测试需要评分表？

传统功能测试里，很多用例可以直接判断 Pass / Fail。

例如：

• 点击按钮是否跳转成功
• 接口返回码是否为 200
• 数据库字段是否更新
• 表单校验是否生效

但 AI 功能不一样。

很多时候，AI 输出不是简单的“完全对”或“完全错”，而是介于中间状态：

• 大方向对，但漏了关键点
• 格式对，但内容不够准确
• 内容完整，但有少量无依据推断
• 回答可用，但表达太冗长
• 能完成任务，但执行链路不够稳定

这时候如果只用 Pass / Fail，会有两个问题。

1. 判断太粗

一条输出可能整体可用，但有明显局部问题。
直接判 Fail 太重，判 Pass 又掩盖风险。

2. 不方便比较版本

Prompt 改版前后、模型切换前后，质量可能是多个维度同时变化。
如果没有评分表，很难说清楚：

到底是哪里变好了，哪里变差了。

所以评分表的价值不是追求绝对精确，而是：

把模糊感受拆成可讨论、可比较、可复盘的质量维度。

---

二、评分表不是为了“算一个分”，而是为了统一判断口径

很多团队一听评分表，会觉得：

AI 输出这么复杂，打分会不会很主观？

确实会有一定主观性。

但评分表的目标不是完全消除主观，而是减少无规则的主观。

没有评分表时，大家讨论的是：

我觉得好 / 我觉得不好。

有评分表后，大家讨论的是：

准确性扣了多少？完整性为什么扣分？幻觉问题是不是 P0？

这就从主观争论，变成了结构化讨论。

所以评分表真正的价值有三个：

1. 统一评价语言

让产品、测试、研发、业务方用同一套维度看问题。

2. 支撑版本对比

让 Prompt、模型、检索策略改版后，可以横向比较。

3. 支撑上线决策

让测试结论从“感觉可用”变成“基于评分和风险判断可灰度”。

---

三、AI测试评分表应该包含哪些核心维度？

不同 AI 功能评分维度会有差异，但大多数 AI 应用都绕不开下面 7 个基础维度。

---

1. 准确性

这是最核心的维度。

看 AI 是否正确理解输入，并给出符合事实、需求、文档或任务目标的输出。

常见扣分点：

• 理解错问题
• 答错事实
• 混淆概念
• 错误引用规则
• 把 A 场景回答成 B 场景

准确性通常应该占比较高。

---

2. 完整性

看 AI 是否覆盖了应该覆盖的信息。

常见扣分点：

• 漏掉关键规则
• 漏掉边界条件
• 漏掉异常场景
• 漏掉待办事项
• 漏掉风险点

很多 AI 输出“看起来没错”，但其实不完整。

---

3. 相关性

看 AI 是否围绕用户问题回答，是否跑题。

常见扣分点：

• 答非所问
• 输出无关背景
• 把简单问题扩展成大段泛论
• 多轮对话中偏离当前上下文

相关性尤其适合评估问答类、总结类场景。

---

4. 格式合规性

看 AI 是否按要求输出。

常见扣分点：

• 没按表格输出
• JSON 不合法
• 缺少字段
• 字段顺序不稳定
• 输出结构不符合约定
• 多次输出格式漂移

如果 AI 输出要接入系统，格式合规性非常重要。

---

5. 无幻觉

看 AI 是否生成了输入、文档或上下文中没有依据的内容。

常见扣分点：

• 编造规则
• 编造引用
• 编造负责人
• 编造截止时间
• 编造工具执行结果
• 凭常识补全业务结论

在 RAG、总结、Agent 场景里，无幻觉通常是高风险指标。

---

6. 稳定性

看同一输入多次执行时，核心结果是否稳定。

常见扣分点：

• 一次答对，一次答错
• 核心结论波动
• 格式时好时坏
• 引用来源不稳定
• 待办项时有时无

AI 输出可以有表达差异，但核心事实、结构和边界不能大幅波动。

---

7. 可用性

看输出是否真的适合业务使用。

常见扣分点：

• 太泛，不能直接使用
• 太长，用户不愿看
• 太粗，无法指导执行
• 结论不明确
• 需要大量人工重写

可用性是一个综合维度，通常用于判断输出的实际落地价值。

---

四、一张通用评分表怎么设计？

可以先用一张通用 100 分表作为基础版本。

评分项	分值	说明
准确性	25	是否正确理解输入并给出正确内容
完整性	20	是否覆盖关键点、规则、边界和风险
相关性	10	是否围绕问题回答，不跑题
格式合规性	15	是否按要求结构或格式输出
无幻觉	15	是否没有编造无依据内容
稳定性	10	多次输出核心结果是否一致
可用性	5	是否适合业务直接使用或轻量修改后使用

总分 100 分。

这张表适合作为多数 AI 文本输出类功能的基础评分表。

---

五、为什么分值不是平均分配？

因为不同维度的重要性不一样。

比如准确性和完整性通常是核心质量指标，所以权重更高。
而可用性虽然重要，但往往依赖前面几个维度，所以权重可以稍低。

但这不是固定答案。

真正使用时，应该根据场景调整。

例如：

• RAG 场景：无幻觉和引用依据要提高权重
• Agent 场景：安全确认和执行真实性要提高权重
• JSON 输出场景：格式合规性要提高权重
• 总结场景：完整性和重点提炼能力要提高权重

所以评分表不是一张表打天下，而是：

通用维度做底座，场景权重按业务调整。

---

六、不同AI场景，评分表怎么改？

下面给几类常见场景的评分表参考。

---

场景1：AI生成测试用例

这类功能重点是“能不能生成可用测试资产”。

评分项	分值	说明
需求理解准确性	20	是否正确理解需求
场景覆盖完整性	25	是否覆盖正常、异常、边界
用例可执行性	20	步骤和预期是否清晰可执行
输出结构完整性	15	字段是否齐全，如标题、步骤、预期
无幻觉	10	是否没有编造需求外规则
优先级合理性	5	P0/P1/P2 是否基本合理
稳定性	5	多次生成核心覆盖是否稳定

这类场景里，最重要的不是“写得像用例”，而是：

覆盖是否合理，测试人员能不能真的拿来用。

---

场景2：RAG知识库问答

这类功能重点是“有没有基于正确文档回答”。

评分项	分值	说明
检索相关性	20	是否召回正确文档和片段
答案准确性	20	答案是否符合文档事实
答案完整性	15	是否覆盖问题所需关键信息
无答案拒答	15	知识库无依据时是否拒答
引用准确性	15	引用是否能支撑答案
权限合规	10	是否未使用无权限内容
表达清晰度	5	回答是否清楚易懂

RAG 场景里，尤其要注意：

答案正确但引用错误，也不能算完全通过。

---

场景3：AI会议纪要总结

这类功能重点是“能不能从沟通中提炼行动信息”。

评分项	分值	说明
主题识别准确性	15	是否抓住会议主线
结论提炼准确性	25	是否识别最终结论
待办提取完整性	20	是否提取事项、负责人、时间
风险识别能力	15	是否识别风险和待确认项
无幻觉	15	是否没有编造人员、时间、结论
结构清晰度	10	是否适合直接同步给团队

会议纪要类场景最容易的问题是：

把讨论过程写成最终结论，把模糊表达写成明确承诺。

---

场景4：AI Agent任务执行

这类功能重点是“能不能正确、安全地完成任务”。

评分项	分值	说明
意图识别准确性	15	是否理解用户真实目标
任务拆解合理性	15	是否规划正确步骤
工具选择正确性	15	是否调用正确工具
参数传递准确性	15	工具参数是否正确
安全确认机制	15	高风险操作是否确认
异常处理能力	10	工具失败时是否处理正确
执行结果真实性	10	是否真实完成，不假完成
权限合规	5	是否遵守权限边界

Agent 场景里，安全类维度要占比较高。

因为 Agent 最大风险不是回答错，而是：

做错了还真的执行了。

---

七、哪些维度适合自动评分，哪些必须人工判断？

评分表不是所有项都要人工打分。
有些适合自动化，有些必须人工判断。

---

适合自动评分的维度

维度	自动判断方式
格式合规性	JSON 校验、字段校验、表格结构校验
引用存在性	是否返回引用字段
关键词覆盖	是否包含核心关键词
权限合规	是否使用无权限片段
工具调用	是否调用正确工具
确认机制	是否触发确认步骤
执行结果	是否返回真实任务 ID / 会议链接

这些可以通过规则、脚本、日志或接口校验完成。

---

适合半自动评分的维度

维度	方式
完整性	规则初筛 + 人工复核
相关性	关键词 / 相似度初筛 + 人工判断
无幻觉	来源匹配 + 人工确认
稳定性	多次结果比对 + 人工抽检

这类维度可以辅助自动化，但不建议完全交给规则判断。

---

必须人工判断的维度

维度	原因
业务准确性	需要理解业务上下文
重点提炼能力	需要判断主次
可用性	需要结合真实使用场景
风险判断	需要结合业务影响
上线建议	需要综合质量和风险

所以当前比较现实的做法是：

规则自动化 + 人工评分 + 抽样复核。

---

八、评分结果怎么用于上线判断？

评分表不是为了得到一个好看的分数，而是要服务上线决策。

可以用下面这个判断框架。

分数区间	质量判断	建议
≥90	质量较好	可进入灰度或上线候选
75～89	基本可用	可灰度，但需人工复核
60～74	风险较高	不建议直接上线，需优化
<60	质量不足	不建议上线

但这里要特别注意：

不能只看总分。

例如一个功能总分 88，但存在 P0 问题，比如权限泄露或无答案编造，也不能上线。

所以最终上线判断要同时看：

• 总分
• P0 问题数量
• 高风险样例通过率
• 历史缺陷回归情况
• 是否需要人工兜底

---

九、一个更实用的上线判断表

建议在评分后再加一个上线决策表。

判断项	要求	是否满足
总分	≥75	是 / 否
P0 问题	0 个	是 / 否
高风险样例通过率	≥95%	是 / 否
历史缺陷回归	不复发	是 / 否
格式合规率	≥95%	是 / 否
人工兜底方案	已明确	是 / 否
灰度范围	已明确	是 / 否

只有这些条件都比较明确时，测试结论才有决策价值。

---

十、评分表使用时最容易踩的坑

---

1. 只看平均分

平均分高不代表安全。
高风险样例单独失败，可能比多个低风险样例失败更严重。

---

2. 所有场景用同一张表

生成测试用例、RAG、Agent 的质量重点不同。
不能完全用一张表硬套。

---

3. 分值设计过细

比如每项 7.5 分、13.2 分，实际执行起来很难。
建议用整数分，便于团队使用。

---

4. 没有扣分说明

只给分，不说明为什么扣分，后续无法复盘。
每个低分项都要有简短原因。

---

5. 不和样例库绑定

评分表必须和固定样例一起用。
否则每次评分对象都不同，结果无法比较。

---

十一、测试报告里怎么呈现评分结果？

评分结果最好不要只给一个总分。

建议至少包含三部分：

1. 总体得分

例如：

本轮 AI 会议纪要总结功能综合得分 82 分，达到灰度使用标准。

2. 分项得分

维度	得分	问题说明
主题识别	14/15	表现稳定
结论提炼	20/25	个别模糊表达误判
待办提取	17/20	漏 1 条隐含待办
风险识别	10/15	风险提炼不充分
无幻觉	13/15	个别截止时间推断偏强
结构清晰	9/10	格式较稳定

3. 风险结论

例如：

当前版本可作为会议纪要草稿工具灰度使用，但不建议直接自动发送正式纪要。模糊表达和风险识别问题需保留人工复核。

这样产品、研发和管理者才能真正看懂问题在哪里。

---

十二、一个最小可落地的评分表建设方法

如果团队刚开始，不需要一次做复杂。

可以按下面 5 步来。

第一步：选一个 AI 场景

比如：

• 生成测试用例
• RAG 问答
• 会议纪要总结
• Agent 执行任务

第二步：确定 5～7 个评分维度

不要太多，太多会维护不动。

第三步：给每个维度分配权重

总分 100，核心维度权重更高。

第四步：给每个维度写扣分说明

例如：

• 漏掉关键规则扣 5～10 分
• 编造规则扣 15 分或直接 P0
• 格式字段缺失扣 5 分

第五步：和固定样例库绑定使用

同一组样例 + 同一张评分表，才能支持版本对比。

---

十三、小结

AI 测试评分表怎么设计？

可以浓缩成一句话：

把“感觉还行”拆成准确性、完整性、格式、无幻觉、稳定性、可用性等可讨论的维度，并结合场景权重支撑版本对比和上线判断。

一个好用的评分表，至少要做到：

• 维度清晰
• 权重合理
• 可解释扣分
• 能适配不同 AI 场景
• 能和样例库绑定
• 能支撑测试报告和上线决策

评分表的目标不是追求数学上的绝对客观，而是：

让团队在同一套质量语言下讨论 AI 输出。

这就是它最大的价值。

---

写在最后

AI 测试最怕的一句话是：

感觉还可以。

因为这句话既不能指导优化，也不能支撑上线。

测试工程师真正要做的，是把这种模糊判断变成：

• 哪个维度好
• 哪个维度差
• 哪类样例失败
• 风险等级是什么
• 是否可以灰度
• 是否需要人工兜底

这就是评分表存在的意义。

它不是让 AI 测试变得完全机械化，而是让团队在面对不确定输出时，仍然能做出更稳定、更专业的判断。