AI Agent 评测中，断言引擎、评测数据集、不确定性处理，每个概念都像全新的。其实把它们拽回传统测试一对比，发现不再神秘了。本文用大白话讲清楚：AI Agent 评测到底和传统测试是什么关系，哪些直接搬、哪些才是真正新的，以及那"真正新的 10%"到底该怎么处理。

---

1、一句话：90% 是老手艺，10% 是新难点

很多人在接触 AI 评测时，最大的障碍不是技术，是被一堆新词唬住了——"不确定性评估""LLM-as-Judge""属性断言"……每个词都暗示这是一套要从零学的全新体系。

其实不是。

AI Agent 评测的底层逻辑，和你做了多年的接口测试是同一套：发请求、拿响应、逐层断言。变的只有一样——喂进去的"输入"从结构化参数变成了自然语言意图，吐出来的"输出"从固定格式变成了每次可能不同的内容。 方法论本身没变，变的是处理不确定性的那 10%。

所以正确的策略是：把能类比其实的 90% 全锚回你已经会的东西，然后把精力全砸在那真正新的 10% 上。 下面逐层展开。

---

2 断言：状态码→格式→业务，三层其实差不多

2.1 传统接口测试的三层断言

做接口测试的人都有一个下意识的检查顺序：

1. 状态码：这次请求到底成没成？200 还是 500？
2. 数据格式：返回的 JSON 结构对不对？字段有没有缺、类型对不对？
3. 业务断言：具体业务逻辑对不对？比如新建一个品牌，品牌确实存在了吗？

这三层几乎是所有接口测试框架的标配，从上到下，一层不过就不用看下一层。

2.2 AI Agent 评测的三层断言——同一套

把这三层搬到 AI Agent 评测里，一一对应：

层级	传统接口测试	AI Agent 评测
第一层	状态码（200/500）	链路层：Agent 整个调用链是否跑完、有没有中途断流
第二层	数据格式（JSON schema 校验）	结构层：返回的计划/结果是否能正常解析、结构是否合法（比如周数对不对、天数对不对）
第三层	业务断言（新建品牌→品牌存在）	业务层：用户说的话，Agent 做到没有（说增肌→有没有力量训练；说无设备→设备是不是 0）

前两层几乎可以原封不动搬过来。 链路层就是"请求成没成"，结构层就是"格式对不对"，你原来怎么断现在还怎么断，传统测试的直觉在这两层直接生效。而且这两层是所有 Case 通用的，跟用户说了什么话无关——就像你不会因为测不同业务接口就换一套状态码检查逻辑。

真正的分叉，只发生在第三层。 这也是整套里最核心、最有挑战的一层——后面单独展开。

---

3 Case 设计：等价类和边界值没过时，只是输入变了

3.1 传统用例设计的五板斧

测试用例设计的经典方法，你闭着眼睛都能列出来：

• 等价类划分：把输入空间切成几类，每类取代表
• 边界值分析：找极端值、临界值
• 正例/反例：正常输入 vs 非法输入
• 场景法/流程覆盖：主流程、分支流程、异常流程
• 判定表：多条件组合，挑有代表性的

3.2 映射到 AI Agent 评测——逐条对应

传统方法	AI Agent 评测中的对应	举例
等价类划分	按用户意图类型划分	目标类（增肌/减脂/塑形）、调整类（轻松/加强）、编辑类（删/加/换动作）
边界值分析	极端/缺省诉求	无设备、时间极短（10 分钟）、诉求冲突、啥都不指定全走默认
正例/反例	正常诉求 vs 无理越界诉求	"三天练成肌肉男""把所有动作都删了"——看 Agent 会不会被带跑
场景法	多轮对话流程覆盖	主流程走完、中途改主意、中途给矛盾信息
判定表	诉求多条件组合	目标×水平×设备×时间×偏好，按代表性挑，不全排列

方法完全一样，只是切分维度从"参数取值"变成了"用户意图"。

3.3 这也回答了一个高频问题："数据集到底要多少条？"

答案是：不数条数，数意图等价类覆盖全没有。 你的核心意图类型、关键输入变体、典型坑点品类，是不是每一类都有足够样本？覆盖全了，黄金级可能就几十条精挑的；没覆盖全，几千条也是漏的。数量是覆盖度的结果，不是先定的目标。

3.4 唯一真新的难点

传统接口参数是离散明确的（status 就 1/2/3），你划等价类一眼能划清。但自然语言意图模糊得多、维度高得多、还带隐含诉求。"轻松点"这个意图，边界在哪？它还隐含着"别把动作删了""还得是个合法计划"这些没说出口的约束。

所以**"划意图等价类"这一步，是 Case 设计环节唯一真正难的地方**——也是你精力该集中的地方。

延伸阅读：[子篇 4] AI 测试用例怎么设计？等价类和边界值没过时，只是输入变了

---

4 松紧度：第三层断言的核心战场

前面说了，断言的前两层可以直接从传统测试搬过来。第三层"业务断言"结构也相同，但判定方式分叉了——这是整套里最核心、最难、也最有价值的一层。

4.1 为什么传统的精确断言不够了

传统业务断言，预期结果是一个精确值："新建品牌成功→品牌存在"，查一下，在或不在，二值判定。

AI Agent 的业务断言不同。用户说"帮我轻松点"，Agent 减 2 组是对的，减 5 组也是对的——你不能断一个精确值，因为 AI 每次给的具体方案可能不同，而这种不同是正常的、是产品特性，不是 bug。

如果你把一个 AI 产品的正常弹性行为判成 Fail，那 Fail 的其实是你的测试，不是产品。过紧的断言，是 AI 评测里一种特有的、传统测试不会犯的 bug。

4.2 松紧度不是全局旋钮，是每条 check 各自定

不要问"这个 Case 该松还是该紧"，而是问**"这条 check 测的是哪一类东西"**。就三类：

① 意图违反类 → 必须严，二值，没有松紧可言

判断标准：AI 是否做了跟用户诉求方向相反的事。

• 用户说"不要删动作" → 动作数减少了 → Fail
• 用户说"无设备" → 计划里出现了设备 → Fail
• 用户说"轻松点" → 强度反而上升了 → Fail

这些是方向性的，只有"符合方向"和"背离方向"，哪怕在运动健康这么宽松的场景里也必须死断——因为它不是"做了多少"的问题，是"做没做反"的问题。

② 程度量级类 → 该松，但松是"有界宽区间"，不是"随便"

"轻松点减 2 组、3 组、5 组都在范围内"就是这类。给它划两条边：

• 下界 = 方向必须对：说轻松 → 组数/强度必须是降的，持平或上升直接 Fail
• 上界 = 不能离谱："轻松点"不能轻松到把训练做废（从 10 组减到 1 组），也不能顺手违反其他隐含约束
• 中间那一大段 → 全过

这就是"有界宽区间"——既没断死（留了 AI 该有的弹性），又不是完全不断（方向和离谱这两条边还守着）。

③ 语义质量类 → LLM 裁判或人工抽检

比如"计划总结描述得准不准"——这种真·语义模糊、化不成规则的，才上 LLM 裁判。但要记住：LLM 裁判每用一次，就牺牲一点可复现性（同一份数据裁判两次可能结论不同）。设计原则是——能压到确定性规则/阈值就绝不上 LLM 裁判。可复现性是预算，省着花。

4.3 分类一定，松紧自动出来

不用凭空拍"这个该多松"——你只要问每条 check：它是在测方向（严）、测程度（有界宽区间）、还是测语义（裁判）？ 分类一定，松紧就定了。

而且不同行业的差异，本质也是这三类 check 的占比不同。金融行业几乎全是意图违反类和精确类，所以整体显得严；运动健康里程度量级类占比高，所以整体显得松。不是行业有个全局旋钮，是占比不同带来的观感不同。

4.4 这层为什么最值钱

你在定松紧度的时候，本质上是在替这个 AI 产品定义"什么叫对"。这不是测试细节，是半个产品定义的活儿。而这恰恰是人的判断最不可能被 AI 接管的一层——因为 AI 不知道你的产品"该"允许什么。

📌 延伸阅读：[子篇 2] "帮我轻松一点"怎么断言？AI 评测中最难的松紧度设计

---

5 Mock 分层：别让 AI 一次猜四样东西

5.1 一次真实踩坑

某次迭代中，我把评审需求文档直接甩给 AI，让它一步到位生成测试脚本。结果：脚本里全是幻觉——输入是它编的、断言是它猜的、Mock 数据格式是它瞎凑的。一边测一边爆雷，最后基本等于重写。

根因不是 AI 模型不行，是我让它同时猜了四样东西：猜业务规则、猜默认值、猜 Mock 格式、猜断言标准。四样一起猜，当然满屏幻觉。

5.2 正确做法：分层组装，各层锁死

参考一个已经跑通的实践（动作微调评测），正确的 Mock 分层是：

层级	谁负责	内容
上游完整数据（Fixture）	人存	保存一份真实的上游返回 JSON，不编造
业务 Case	人写	只描述这条 Case 和公共 Fixture 的差异——场景、用户输入、业务预期
公共配置	人定	账号、时区等所有 Case 通用的请求参数
请求组装（映射器）	代码（人写规则）	加载 Fixture + 合并 Case 差异 + 填入公共配置 = 最终请求

关键原则：每条 Case 不复制一大份完整 JSON，只声明自己跟公共 Fixture 不同的地方。组装是映射器的活儿。

5.3 这套分层解决了什么

• AI 没有"重新编造完整 JSON"的机会——Fixture 是真的、差异是你写的、组装是代码做的，幻觉空间被压到最小
• 接口一变，你改的只是映射器那一个文件，不是每条 Case 里复制的一大份 JSON
• 不确定性被圈进了一个点，而不是散在全项目

5.4 接口没出来怎么办

现实中，开发的接口往往还没出来，返回格式不确定。此时的策略是：

1. 业务事实层现在就做（场景、用户输入、业务预期——这些不依赖接口格式）
2. 不要提前写假 JSON 去猜格式——那又把你拉回"让 AI 猜"的老路
3. 依赖接口格式的部分（Fixture、映射器）显性标记为"待定"，等开发确认后再补
4. 主动找开发要一份真实返回的样例 JSON（要实物不要口头描述），而不是等他们评审时才甩给你

不依赖格式的先做实，依赖格式的显性标记。 做的时候没心虚，等确认了补的时候不返工。

📌 延伸阅读：[子篇 3] AI 生成的测试脚本为什么全是幻觉？一次踩坑复盘讲透 Mock 分层

---

6 人机协作：AI 是执行器，不是决策器

6.1 一条贯穿全文的主线

回看上面每一节，其实都在回答同一个问题：在 AI 评测里，哪些是人做的，哪些交给 AI？

环节	人做（判断）	AI 做（执行）
Case 设计	划意图等价类、定边界、选代表场景	按你定好的类和模板批量生成 Case 变体
断言设计	定三层规则、定每条 check 的松紧类型	把你定好的规则翻译成检查代码
Mock 组装	存 Fixture、写 Case 差异、定映射规则	按映射器组装请求
松紧度	决定哪些严/哪些松/用哪种判定模式	按你选的模式执行判定

人定规则，AI 做翻译。人握尺子，AI 跑卷子。

6.2 谁用得好 AI？

不是"会用 AI 工具的人"，而是手里有那把"判断的尺子"的人。

AI 缺的从来不是执行力，是判断力。判断力只能从真实的业务踩坑里长出来——你不知道"轻松点"该断多松，是因为你没见过减 2 组和减 8 组的区别；你不知道哪些该精确断哪些该放开，是因为你没被"过紧断言误杀正常结果"坑过。

这些坑踩过了，尺子就长出来了。尺子在手里，AI 才知道往哪跑。

---

7 总结：只有 10% 是新的，但那 10% 决定你的段位

维度	传统测试直接搬（90%）	AI 评测真正新的（10%）
断言	第一层（状态码/链路）、第二层（格式/结构）照搬	第三层业务断言的判定方式分叉：从精确值→检查规则
Case 设计	等价类、边界值、场景法、判定表全部适用	输入从结构化参数变成自然语言意图，划等价类更难
Mock	分层、组装、Fixture 的思路不变	需要处理接口未定时的分层占位策略
松紧度	传统不存在这个问题（精确值就一个答案）	三分类（意图违反/程度量级/语义质量） 是全新的设计
人机分工	传统全是人做	需要明确判断归人、执行归 AI的边界

把能搬的 90% 搬过来，是效率；把新的 10% 搞透，是壁垒。

---

后续子篇预告

本文是总纲。后续将围绕每个核心环节展开实操细节：

1. AI Agent 断言不神秘：状态码→格式→业务，三层你早就会了
2. "帮我轻松一点"怎么断言？AI 评测中最难的松紧度设计
3. AI 生成的测试脚本为什么全是幻觉？一次踩坑复盘讲透 Mock 分层
4. AI 测试用例怎么设计？等价类和边界值没过时，只是输入变了

每篇都从一个真实踩坑出发，有前后对比，读完能动手做。

---

如果你也是从传统测试转到 AI 评测的，欢迎评论区聊聊你踩过的坑——尤其是第三层松紧度那块，每个业务场景都有自己的故事。