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场景评分表怎么改下面给几类常见场景的评分表参考。场景1AI生成测试用例这类功能重点是“能不能生成可用测试资产”。评分项分值说明需求理解准确性20是否正确理解需求场景覆盖完整性25是否覆盖正常、异常、边界用例可执行性20步骤和预期是否清晰可执行输出结构完整性15字段是否齐全如标题、步骤、预期无幻觉10是否没有编造需求外规则优先级合理性5P0/P1/P2 是否基本合理稳定性5多次生成核心覆盖是否稳定这类场景里最重要的不是“写得像用例”而是覆盖是否合理测试人员能不能真的拿来用。场景2RAG知识库问答这类功能重点是“有没有基于正确文档回答”。评分项分值说明检索相关性20是否召回正确文档和片段答案准确性20答案是否符合文档事实答案完整性15是否覆盖问题所需关键信息无答案拒答15知识库无依据时是否拒答引用准确性15引用是否能支撑答案权限合规10是否未使用无权限内容表达清晰度5回答是否清楚易懂RAG 场景里尤其要注意答案正确但引用错误也不能算完全通过。场景3AI会议纪要总结这类功能重点是“能不能从沟通中提炼行动信息”。评分项分值说明主题识别准确性15是否抓住会议主线结论提炼准确性25是否识别最终结论待办提取完整性20是否提取事项、负责人、时间风险识别能力15是否识别风险和待确认项无幻觉15是否没有编造人员、时间、结论结构清晰度10是否适合直接同步给团队会议纪要类场景最容易的问题是把讨论过程写成最终结论把模糊表达写成明确承诺。场景4AI Agent任务执行这类功能重点是“能不能正确、安全地完成任务”。评分项分值说明意图识别准确性15是否理解用户真实目标任务拆解合理性15是否规划正确步骤工具选择正确性15是否调用正确工具参数传递准确性15工具参数是否正确安全确认机制15高风险操作是否确认异常处理能力10工具失败时是否处理正确执行结果真实性10是否真实完成不假完成权限合规5是否遵守权限边界Agent 场景里安全类维度要占比较高。因为 Agent 最大风险不是回答错而是做错了还真的执行了。七、哪些维度适合自动评分哪些必须人工判断评分表不是所有项都要人工打分。有些适合自动化有些必须人工判断。适合自动评分的维度维度自动判断方式格式合规性JSON 校验、字段校验、表格结构校验引用存在性是否返回引用字段关键词覆盖是否包含核心关键词权限合规是否使用无权限片段工具调用是否调用正确工具确认机制是否触发确认步骤执行结果是否返回真实任务 ID / 会议链接这些可以通过规则、脚本、日志或接口校验完成。适合半自动评分的维度维度方式完整性规则初筛 人工复核相关性关键词 / 相似度初筛 人工判断无幻觉来源匹配 人工确认稳定性多次结果比对 人工抽检这类维度可以辅助自动化但不建议完全交给规则判断。必须人工判断的维度维度原因业务准确性需要理解业务上下文重点提炼能力需要判断主次可用性需要结合真实使用场景风险判断需要结合业务影响上线建议需要综合质量和风险所以当前比较现实的做法是规则自动化 人工评分 抽样复核。八、评分结果怎么用于上线判断评分表不是为了得到一个好看的分数而是要服务上线决策。可以用下面这个判断框架。分数区间质量判断建议≥90质量较好可进入灰度或上线候选7589基本可用可灰度但需人工复核6074风险较高不建议直接上线需优化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 执行任务第二步确定 57 个评分维度不要太多太多会维护不动。第三步给每个维度分配权重总分 100核心维度权重更高。第四步给每个维度写扣分说明例如漏掉关键规则扣 510 分编造规则扣 15 分或直接 P0格式字段缺失扣 5 分第五步和固定样例库绑定使用同一组样例 同一张评分表才能支持版本对比。十三、小结AI 测试评分表怎么设计可以浓缩成一句话把“感觉还行”拆成准确性、完整性、格式、无幻觉、稳定性、可用性等可讨论的维度并结合场景权重支撑版本对比和上线判断。一个好用的评分表至少要做到维度清晰权重合理可解释扣分能适配不同 AI 场景能和样例库绑定能支撑测试报告和上线决策评分表的目标不是追求数学上的绝对客观而是让团队在同一套质量语言下讨论 AI 输出。这就是它最大的价值。写在最后AI 测试最怕的一句话是感觉还可以。因为这句话既不能指导优化也不能支撑上线。测试工程师真正要做的是把这种模糊判断变成哪个维度好哪个维度差哪类样例失败风险等级是什么是否可以灰度是否需要人工兜底这就是评分表存在的意义。它不是让 AI 测试变得完全机械化而是让团队在面对不确定输出时仍然能做出更稳定、更专业的判断。
AI测试评分表怎么设计：从主观感觉到结构化评估
发布时间：2026/5/22 2:54:32
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场景评分表怎么改下面给几类常见场景的评分表参考。场景1AI生成测试用例这类功能重点是“能不能生成可用测试资产”。评分项分值说明需求理解准确性20是否正确理解需求场景覆盖完整性25是否覆盖正常、异常、边界用例可执行性20步骤和预期是否清晰可执行输出结构完整性15字段是否齐全如标题、步骤、预期无幻觉10是否没有编造需求外规则优先级合理性5P0/P1/P2 是否基本合理稳定性5多次生成核心覆盖是否稳定这类场景里最重要的不是“写得像用例”而是覆盖是否合理测试人员能不能真的拿来用。场景2RAG知识库问答这类功能重点是“有没有基于正确文档回答”。评分项分值说明检索相关性20是否召回正确文档和片段答案准确性20答案是否符合文档事实答案完整性15是否覆盖问题所需关键信息无答案拒答15知识库无依据时是否拒答引用准确性15引用是否能支撑答案权限合规10是否未使用无权限内容表达清晰度5回答是否清楚易懂RAG 场景里尤其要注意答案正确但引用错误也不能算完全通过。场景3AI会议纪要总结这类功能重点是“能不能从沟通中提炼行动信息”。评分项分值说明主题识别准确性15是否抓住会议主线结论提炼准确性25是否识别最终结论待办提取完整性20是否提取事项、负责人、时间风险识别能力15是否识别风险和待确认项无幻觉15是否没有编造人员、时间、结论结构清晰度10是否适合直接同步给团队会议纪要类场景最容易的问题是把讨论过程写成最终结论把模糊表达写成明确承诺。场景4AI Agent任务执行这类功能重点是“能不能正确、安全地完成任务”。评分项分值说明意图识别准确性15是否理解用户真实目标任务拆解合理性15是否规划正确步骤工具选择正确性15是否调用正确工具参数传递准确性15工具参数是否正确安全确认机制15高风险操作是否确认异常处理能力10工具失败时是否处理正确执行结果真实性10是否真实完成不假完成权限合规5是否遵守权限边界Agent 场景里安全类维度要占比较高。因为 Agent 最大风险不是回答错而是做错了还真的执行了。七、哪些维度适合自动评分哪些必须人工判断评分表不是所有项都要人工打分。有些适合自动化有些必须人工判断。适合自动评分的维度维度自动判断方式格式合规性JSON 校验、字段校验、表格结构校验引用存在性是否返回引用字段关键词覆盖是否包含核心关键词权限合规是否使用无权限片段工具调用是否调用正确工具确认机制是否触发确认步骤执行结果是否返回真实任务 ID / 会议链接这些可以通过规则、脚本、日志或接口校验完成。适合半自动评分的维度维度方式完整性规则初筛 人工复核相关性关键词 / 相似度初筛 人工判断无幻觉来源匹配 人工确认稳定性多次结果比对 人工抽检这类维度可以辅助自动化但不建议完全交给规则判断。必须人工判断的维度维度原因业务准确性需要理解业务上下文重点提炼能力需要判断主次可用性需要结合真实使用场景风险判断需要结合业务影响上线建议需要综合质量和风险所以当前比较现实的做法是规则自动化 人工评分 抽样复核。八、评分结果怎么用于上线判断评分表不是为了得到一个好看的分数而是要服务上线决策。可以用下面这个判断框架。分数区间质量判断建议≥90质量较好可进入灰度或上线候选7589基本可用可灰度但需人工复核6074风险较高不建议直接上线需优化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 执行任务第二步确定 57 个评分维度不要太多太多会维护不动。第三步给每个维度分配权重总分 100核心维度权重更高。第四步给每个维度写扣分说明例如漏掉关键规则扣 510 分编造规则扣 15 分或直接 P0格式字段缺失扣 5 分第五步和固定样例库绑定使用同一组样例 同一张评分表才能支持版本对比。十三、小结AI 测试评分表怎么设计可以浓缩成一句话把“感觉还行”拆成准确性、完整性、格式、无幻觉、稳定性、可用性等可讨论的维度并结合场景权重支撑版本对比和上线判断。一个好用的评分表至少要做到维度清晰权重合理可解释扣分能适配不同 AI 场景能和样例库绑定能支撑测试报告和上线决策评分表的目标不是追求数学上的绝对客观而是让团队在同一套质量语言下讨论 AI 输出。这就是它最大的价值。写在最后AI 测试最怕的一句话是感觉还可以。因为这句话既不能指导优化也不能支撑上线。测试工程师真正要做的是把这种模糊判断变成哪个维度好哪个维度差哪类样例失败风险等级是什么是否可以灰度是否需要人工兜底这就是评分表存在的意义。它不是让 AI 测试变得完全机械化而是让团队在面对不确定输出时仍然能做出更稳定、更专业的判断。
