团队要做自动化回归时，常见的卡点不是工具不会用，而是把两类东西混在一起谈：一边是写死断言、按用例跑的接口脚本，另一边是让模型看响应、判语义、自己生成用例的做法。混着用会出现「跑绿了但没测到」或者「模型每次说法都不一样，没法卡门禁」。这篇把两者的原理差异、各自能覆盖的场景、什么时候不该用 AI 讲清，并给一份可执行的落地顺序。
团队做自动化回归，卡点常常不是工具不会用，而是把两类东西混在一起谈。一类是写死断言、按用例跑的接口脚本；另一类是让模型看响应、判语义、自己生成用例的做法。混着用的典型后果是：要么「跑绿了但没测到」，要么「模型每次说法都不一样，根本没法卡门禁」。
这篇只讲一个角度：两者的原理差异落在哪、各自能覆盖什么、什么时候不该上 AI，最后给一份能照着做的落地顺序。想先看各家模型和 API 的公开资料，可以去 /official-api 和 /ai-rankings 对当时的数字，但选型别照搬别人的结论，得按自己业务判定规则来。
两者到底差在哪儿：判定方式决定一切
分水岭只有一个：谁负责判定，判定结果能不能被别人复现。传统接口自动化是确定输入对确定断言——状态码、字段值、schema、耗时阈值，跑一百次结果一样，失败就是失败。AI 自动化是把响应交给模型判断或生成，判定带概率性，同一份响应两次可能给出不同结论，所以必须额外做校验和兜底。
- 确定性断言
- 预期唯一，结果可复现，失败能直接定位到某一行
- 模型判定
- 预期是「合不合理」，需要评分口径和人工基线，结论有波动
- 可复现性
- 换个人、换个环境跑，结论应当一致，这是能不能卡门禁的前提
- 兜底层
- 模型判完之后用来兜住误判的一层规则，比如格式校验、关键词命中
记住一个判断顺序：能写成断言的，别交给模型。AI 只适合做判定规则写不出来的那部分，比如文案是否合规、答案是否覆盖要点。反过来，把有唯一预期的接口交给模型判，等于自己放弃了可复现性，出问题还不好解释。
适用面怎么分：哪些用例该给谁
盘点用例时按「能不能写成断言」打标签最省事。结构、鉴权、边界值、幂等、状态流转这类有明确预期的，天然属于传统接口自动化，成本低、结论稳；语义质量、多轮对话、结构化输出是否合理、异常文案是否说得过去、RAG 问答有没有答到点上，这类没有唯一答案的，才轮到 AI 判定。
| 用例类型 | 该走哪条链 | 判断标准 |
|---|---|---|
| 字段结构 / 状态码 | 传统断言 | 预期唯一，写得出期望值 |
| 鉴权 / 权限 / 数据一致性 | 传统断言，且必须阻断 | 强约束链路，不能靠模型放过 |
| 边界值与异常入参 | 传统断言为主 | 边界可枚举，能量化 |
| 答案是否覆盖要点 | AI 判定，人工基线 | 无唯一答案，靠评分口径 |
| 文案合规与语气 | AI 判定，先告警 | 人写规则穷举不完 |
| 用例草稿生成 | AI 辅助，人再筛 | 生成仅供参考，不进门禁 |
- 强约束链路（支付、权限、数据一致性）不能只凭模型说「看起来没问题」就放过，这类漏报代价最高
- 把 AI 用在前置环节更稳：生成用例草稿、补充边界场景、把失败日志归类，人再筛一遍，比直接用 AI 卡发布靠谱
- 多轮对话和 RAG 场景适合 AI 判定，但必须留一组人工标注样本做基线，否则标准会边跑边改
- 涉及金额计算、账目对账的，即使语义部分用 AI 判，数值部分也要有独立断言兜底
- 同一份响应既要过断言又要过模型时，先跑断言，断言不过就别浪费模型调用
不适用的边界也写清楚：当回归目标是「防止已修复的问题再出现」时，优先确定性断言；只有当缺陷本身就是「说得对不对、全不全」这种语义问题时，AI 判定才有不可替代的位置。
落进流水线：两条链怎么摆位置
两条链不要在同一个阶段混跑。确定性用例进必过门禁，模型判定的用例进观察位，先只告警不拦截，积累一段时间看误报率再决定是否升级为阻断。这样上线初期不会因为模型误判把整条流水线卡死，团队也不会因为一两次误报就失去信任。
- 固定输入同一份响应、同一份评分标准、同一个提示词版本，三者缺一不可，否则前后结论没法比较
- 提示词版本化把提示词当代码管，改动留记录，能回溯是哪次改动导致判定结果变化
- 双写结果判定结果和原始响应一起存下来，出现争议时人工能复核，这是模型判定能否被团队接受的关键
- 设观察位模型判定先只告警不阻断，按月看误报率，达标再升级为阻断
维护成本与常见坑
传统脚本的痛点是接口一改就大面积红，但定位快、修得也快；AI 判定的痛点是坏得安静——今天放过、明天放过，等你发现时已经漏了一批。所以两类用例的监控重点不同：前者看红了多少，后者看判定结果有没有漂移。
| 对比项 | 传统接口自动化 | AI 自动化 |
|---|---|---|
| 失败表现 | 立刻红，定位到行 | 可能静默通过，不易察觉 |
| 主要维护动作 | 改断言、改入参 | 看漂移、调提示词、换模型 |
| 单次耗时 | 毫秒到秒级 | 通常更慢，批量时要控并发 |
| 稳定性来源 | 确定的期望值 | 评分口径 + 人工基线 + 兜底规则 |
| 漏报风险点 | 断言写太松 | 标准漂移、样本覆盖不到 |
判定标准漂移是最大的坑：提示词没改、模型版本换了，结论也会变。做法是准备一组小规模对照用例，定期跑一遍看结论是否漂移。调用量和等待时间也要提前算，模型判定比断言慢得多，全量回归里塞太多会拖垮流水线，批量任务可以按并发分批跑，参考 /guides/batch-concurrency-throttle-guide。
AI 判定省的是「写判定规则」的力气，不是省「定标准」和「看结果」的力气。
给负责人一份落地清单
别一上来就全线铺开。先给现有接口用例打标签，把 AI 候选范围收窄到少数高价值场景，跑出误报和漏报的数据再谈扩大。下面这份顺序可以直接照做。
- 盘点打标签把现有接口用例按「能不能写成断言」分两类，能写的补齐断言，写不了的单独列成候选清单
- 二次筛选候选清单里排除涉及钱、权限、数据的场景，剩下的按业务影响排序，先做一两个高价值场景
- 定评分口径跑之前先写清「什么样算失败」，并留一组人工标注过的样本做基线，避免标准边跑边改
- 小范围试跑只挂告警不阻断，记录误报、漏报、单次耗时三项数据
- 按月回看误报高就收窄范围或改口径，漏报有就补人工基线样本，耗时高就降并发或缩范围，别硬扛
- 候选场景先选有明确评分维度、又不涉及强约束的，比如答案覆盖度、文案合规
- 基线样本要提前标好，边跑边改标准等于没标准
- 观察位至少跑满一个回归周期再决定是否升级为阻断
- 把模型判定的耗时单独统计，和确定性用例分开看，否则会误判整条流水线变慢
- 每次换模型或改提示词，都跑一遍基线样本，确认没漂移再继续
常见问题
AI 能不能直接替代传统接口自动化脚本？
替代不了。有明确预期值的用例，写成断言既快又稳，模型反而慢且不稳定。AI 适合补充那些判定规则写不出来的场景，两者是分工关系，不是替代关系。真要说替代，是替代人工看日志、写用例草稿这类前置工作。
模型判定结果不稳定，怎么让它能进门禁？
三个做法：固定输入（同一份响应加同一版评分标准）、跑多次取一致结论、给结论加人工复核通道。初期只做告警不做阻断，等误报率稳定下来再谈升级。具体阈值按你们自己的数据定，别抄别人的。
小团队没资源搭两套，先做哪个？
先把确定性断言这条链跑通，收益最直接：接口一改立刻知道。等接口回归稳定了，再挑一两个语义类场景试水 AI 判定。反过来先上 AI 判定，容易因为结论不稳导致没人信，最后整套自动化都被弃用。
