AI测试-09-AI测试里的误判幻觉和越权风险怎么控制

在 AI 测试平台里，最容易被低估的不是“模型够不够聪明”，而是模型一旦开始参与判断、规划和执行，错误会以更隐蔽的方式进入测试链路。

传统自动化的错误通常比较直接：

• 定位不到元素
• 接口返回异常
• 断言失败
• 环境不可用

AI 测试里的风险不一样。它更常见的表现是：

• 看起来执行成功，实际判断错了
• 看起来在按目标做事，实际编造了不存在的信息
• 看起来只是做测试，实际调了不该调的工具或数据

这三类问题可以分别归到：

• 误判
• 幻觉
• 越权

如果这三类风险没有被单独设计控制骨架，AI 测试平台就会很快从“提升效率的工具”变成“把错误放大并掩盖证据的系统”。

这篇文章只聚焦一件事：AI 测试里的误判、幻觉和越权风险应该怎么分层、怎么控制、怎么留证、怎么审计。

一、先把三个问题拆开，不要混成一句“模型不稳定”

很多平台在复盘 AI 测试失败时，喜欢把问题统称成“模型不稳定”。
这种说法太粗，后面几乎无法落治理动作。

更合适的做法是先拆成三类。

1. 误判：执行了，也返回了，但判断错了

误判通常发生在：

• 视觉识别把相似元素看成目标元素
• 文本摘要把“部分成功”归成“完全成功”
• 工具结果收口时把不确定状态写成成功
• UI 场景里把旧页面残留状态当成当前结果

误判的特点是：

• 不一定有明显报错
• 很容易进入报告系统
• 一旦被写成成功，后续回归会持续放大错误

2. 幻觉：没有证据，但模型给了一个看起来合理的答案

幻觉更常见在：

• 没查到结果却补出一个解释
• 工具执行失败后，模型直接给出“推测性结论”
• 证据不完整时，模型自动填补缺失步骤
• RAG 召回不准时，模型引用了不适用的旧知识

幻觉的危险不在于“答错了”，而在于：

• 表达通常很完整
• 看起来逻辑顺
• 容易看起来像已验证

3. 越权：做了不该做的动作，或看了不该看的数据

越权一般出现在：

• 任务只允许读操作，却触发了写接口
• 测试环境任务越过边界访问了生产资源
• 模型调用了不属于当前任务白名单的工具
• 任务只允许查看摘要数据，却拉取了原始敏感数据

越权问题和“判断错没错”不是一个层级。
它属于权限边界失控，哪怕任务结果是对的，也依然是高风险事故。

所以第一步不是“增强提示词”，而是先在平台里明确：

• 哪些问题是误判
• 哪些问题是幻觉
• 哪些问题是越权

不拆清楚，后续控制策略一定会混乱。

二、风险分层要从链路看，不要只盯模型输出

AI 测试里的风险并不只出现在模型那一层。
更常见的情况是：风险在上游种下，在下游才暴露出来。

一个更可执行的分层方式，至少包含 5 层。

1. 输入层风险

这里的问题包括：

• 任务目标描述含糊
• 环境上下文缺失
• 当前状态没有传全
• 允许动作边界不清
• 敏感对象没有脱敏

输入层一旦模糊，后面的误判和越权概率会显著升高。

2. 推理层风险

这里主要是：

• 模型把概率判断当确定结论
• 自动补齐中间推理链
• 多步骤任务里自行改写目标
• 用旧上下文覆盖当前上下文

这一层对应的就是幻觉和意图漂移。

3. 工具调用层风险

这里关注：

• 选错工具
• 参数不完整
• 顺序错误
• 重试把写操作重复执行
• 调用了不允许暴露的能力

这一层是越权和误操作的高发区。

4. 结果收口层风险

这里的问题往往最隐蔽：

• 工具部分失败，却被归成成功
• 多条证据互相冲突，却没被标为不确定
• 失败被覆盖成“可忽略波动”
• 模型解释替代了原始结果

很多“误判”其实不是模型在前面看错了，而是这里把复杂结果压扁了。

5. 报告与审计层风险

如果没有这一层，前面所有控制都很难闭环。

典型问题包括：

• 报告里只有结论，没有证据引用
• 审计日志缺步骤 ID 和工具调用链
• 事后看不出是模型判断、规则判断还是人工覆盖
• 无法还原越权调用发生在哪个任务、哪个阶段

AI 测试平台要想长期可用，必须接受一个事实：
风险控制不是一个模型问题，而是一条执行链路问题。

三、控制骨架要先于模型能力落地

只要 AI 测试开始接工具、接环境、接数据，就不能只靠“提示词约束”。
提示词可以辅助收敛，但不能代替系统控制。

更稳的做法是先把下面这套控制骨架落出来。

1. 任务白名单和工具白名单分开设计

不能只说“当前任务可执行”，还要明确：

• 当前任务属于什么类型
• 当前任务可调用哪些工具
• 当前工具允许哪些动作
• 当前动作能访问哪些资源

例如一个“验证订单展示是否正确”的任务，通常只应开放：

• 只读接口
• 只读数据库查询
• 截图
• 拉取限定范围日志

如果同一任务上下文里同时暴露：

• 删单接口
• 补数据接口
• 全量日志导出
• 跨环境资源访问

那越权就不是“偶发风险”，而是设计缺陷。

2. 让高风险动作必须经过双重确认

高风险动作至少包括：

• 写数据
• 删除数据
• 触发发布
• 修改配置
• 调用生产或准生产资源

这些动作不能只靠模型一句话触发。更稳的做法是：

• 先由模型提出动作意图
• 再由规则层校验
• 命中高风险策略时转人工确认或显式批准

如果平台允许模型在失败恢复时自动尝试“补数据”“重置环境”，控制边界很容易失控。

3. 给不确定状态单独留出口，不要强行二元化

误判经常发生在平台只允许写两种状态：

• 成功
• 失败

但 AI 测试现实里，经常会遇到第三类状态：

• 证据不足
• 结果冲突
• 模型判断不确定
• 环境异常导致无法归因

如果系统没有“不确定”或“待人工复核”这类出口，模型和平台就会被迫把灰色结果压进成功或失败，误判自然会上升。

4. 原始结果和模型解释必须分层保存

平台里至少要同时保存两类内容：

• 原始证据：截图、日志片段、请求响应、工具返回、页面状态
• 模型解释：对证据的摘要、归因、结论建议

如果只保留模型解释，后面基本无法复盘幻觉。

更糟的是，当模型解释写进最终报告，而原始证据没有引用链路时，团队只能围着“这段结论看起来像对的”打转，问题会越来越难收敛。

5. 每一步都要有执行主体标记

至少要能区分：

• 模型决策
• 规则引擎决策
• 工具执行结果
• 人工确认动作
• 人工覆盖结论

这样做的目的不是为了留“流水账”，而是为了在复盘时回答这几个关键问题：

• 结论是谁给出的
• 风险是谁放过的
• 工具是谁触发的
• 哪一步把错误放大了

没有主体标记，审计几乎没有意义。

四、证据与审计不是附属能力，而是风险控制核心

AI 测试一旦进入多步骤任务，光有“最后结果”已经不够用了。
必须把证据链和审计链拉出来。

1. 证据链最少要包含什么

一个可复盘的 AI 测试任务，至少要留下这些内容：

• 任务 ID、环境 ID、会话 ID
• 输入上下文摘要
• 模型输出的动作意图
• 工具调用参数
• 工具执行原始结果
• 关键截图或日志引用
• 平台收口状态
• 最终结论和结论来源

缺任何一层，后面都可能出现“知道错了，但不知道错在哪一步”。

2. 审计链最少要回答什么

审计不是把日志堆满，而是要让平台能快速回答：

• 有没有调用白名单外工具
• 有没有访问未授权环境
• 有没有高风险动作未经过确认
• 有没有证据缺失却仍输出确定结论
• 有没有一次失败后触发多次重复写操作

所以审计链不是普通执行日志，而是围绕风险问题设计的结构化记录。

3. 报告里不能只放“模型总结”

一个更稳的报告结构通常是：

• 任务结论
• 风险提示
• 原始证据索引
• 模型解释
• 审计摘要

顺序也很重要。
更合适的是先放事实和证据，再放模型解释，而不是反过来。

五、最小可执行控制骨架

如果平台还在第一阶段，不需要一开始就做成复杂治理系统。
但至少要先把下面这条最小链路跑通。

1. 执行前

• 明确任务目标和禁止动作
• 指定环境和资源边界
• 分配工具白名单
• 标记风险等级
• 对高风险任务强制人工批准

2. 执行中

• 每一步先产出动作意图
• 参数先过规则校验，再执行工具
• 原始结果和模型解释分层保存
• 遇到不确定状态进入待复核，而不是强行继续
• 高风险动作强制二次确认

3. 执行后

• 生成任务证据包
• 生成审计摘要
• 标记是否存在误判风险、幻觉风险、越权风险
• 对高风险任务进入复核队列
• 将误判样本和越权样本回灌到规则和提示模板

4. 最小记录表

字段	说明
task_id	任务唯一标识
step_id	当前步骤编号
actor_type	模型 / 规则 / 工具 / 人工
intent	当前动作意图
tool_name	工具名称
risk_level	风险等级
permission_check	是否通过权限校验
result_status	成功 / 失败 / 不确定
evidence_refs	证据引用
audit_flag	是否命中审计规则

这个表不复杂，但足够把多数风险收进可追踪范围。

六、最容易踩的坑，不在模型弱，而在平台设计懒

1. 只做提示词约束，不做系统约束

这是最常见的问题。
提示词里写了“不要越权”“不要编造”，但工具层没有白名单、权限层没有校验、审计层没有拦截。
这种控制几乎等于没有控制。

2. 只保留模型结论，不保留原始证据

短期看起来报告更整洁，长期一定失控。
一旦出现幻觉，后面没有任何可复核抓手。

3. 把失败恢复直接交给模型自由处理

失败恢复通常会触发：

• 重试
• 补数据
• 回退
• 重新初始化环境

这些动作本身就带风险。
如果不加边界，模型很容易在“修复现场”的过程中把现场进一步改坏。

4. 把“不确定”错误地当成“失败太多，先算成功”

为了让看板好看，有些平台会把灰色结果压成成功或轻微波动。
这不是优化体验，而是在给误判铺路。

5. 审计只记结果，不记过程

只记“最终调了哪个工具”远远不够。
风险往往发生在：

• 谁提出了调用
• 谁放行了调用
• 谁覆盖了结论
• 谁忽略了缺失证据

不把过程记下来，后面很难做责任和治理闭环。

七、真实案例：一次“看起来成功”的 AI 回归，为什么最后被判成高风险任务

场景

一个 AI 测试任务负责验证“下单后订单详情页展示正确，并同步校验订单状态接口返回正常”。
任务允许：

• 打开测试环境页面
• 调用只读订单接口
• 截图
• 查询只读数据库视图

任务不允许：

• 重建订单
• 调用写接口
• 切换环境

执行

任务执行过程里，模型先完成了页面操作，并返回：

• 订单详情页展示正常
• 状态接口返回成功
• 数据库中存在对应订单记录

最终报告给出的结论是“任务通过”。

现象

人工抽检时发现两个异常：

• 页面截图里的订单号和接口返回里的订单号不一致
• 审计日志里出现了一次未在计划中的“补查订单详情”工具调用

从结果上看，任务像是成功了，但证据链对不上。

排查

按步骤回放后，发现问题出在三处：

1. 页面层识别把上一条残留订单卡片当成了当前订单结果，形成第一次误判。
2. 接口查询没有命中新生成订单，模型在解释阶段把“未查到”写成了“接口正常返回”，形成幻觉。
3. 平台为了提高成功率，自动放开了一个扩展查询工具，虽然没有写数据，但这个工具不在当前任务白名单里，形成越权。

也就是说，这次任务表面上是一条通过用例，实际上同时命中了：

• 误判
• 幻觉
• 越权

修复

后续修复动作不是简单改一句提示词，而是做了 4 个收口：

1. 页面结果必须和任务上下文里的订单 ID 做强绑定，不允许只按视觉相似度判成功。
2. 接口或数据库未查到结果时，平台只允许写“不确定”或“待复核”，不允许模型补齐成确定结论。
3. 工具层把扩展查询工具移出默认白名单，只在显式审批后开放。
4. 报告页改成“原始证据优先、模型解释次之”，并把审计摘要上浮到结论区。

这次修复之后，任务通过率短期下降了，但误判率和高风险误放率明显下降。
对 AI 测试平台来说，这种下降是必要代价，不是性能退化。

八、真正要控制的不是模型，而是平台把风险放大的能力

AI 测试不是不能用，也不是只能停留在演示层。
真正决定它能不能长期落地的，不是模型一次能答对多少，而是平台有没有把下面几件事做好：

• 把误判、幻觉、越权拆开治理
• 把风险分层到输入、推理、工具、收口、审计整条链路
• 给高风险动作留审批边界
• 给不确定结果留正式出口
• 把原始证据和模型解释分层保存
• 把审计做成结构化能力，而不是事后翻日志

AI 测试一旦接入真实环境，最重要的能力从来不是“更会做事”，而是做错事时能被及时拦住，做错后还能被完整复盘。

这条线如果收不住，模型越强，风险只会越大。
这条线如果收得住，AI 测试平台才有资格进入更复杂的自动化和决策链路。