当 AI 能一键生成用例，测试工程师的价值就从『执行用例』挪到了『定义验收标准』

当 AI 能一键生成用例，测试工程师的价值就从『执行用例』挪到了『定义验收标准』

前阵子一个做接口测试的同学给我看：他把一份接口文档丢给 AI，几十条用例连同断言几秒钟就生成好了；另一个做 UI 的，让 AI 照着页面录了一段操作，直接吐出一份能跑的 Playwright 脚本。他们半开玩笑地问我同一句话：「那我们是不是快被替代了？」

我的回答是：被替代的那部分，确实该被替代——但被替代的从来不是「测试」，而是「把一份已经明确的验收标准，翻译成一条条用例」这个执行动作。至于「这份需求到底什么叫通过」这个判断，AI 到今天仍然替不了你，而且它越强，这个判断就越值钱。

这不是安慰。前程无忧的一份调研里有个定性说法：超三成应届生已经感知到 AI 带来的就业替代效应（口径来自前程无忧调研、经新京报/经济观察报报道）。感知到替代是真的，但替代落在哪个动作上，才是每个一线测试同学真正要想清楚的事。

AI 抹平的是「执行用例」的成本，抬高的是「定义验收标准」的价值——前者是它的主场，后者是你的老本行。

一、先分清两个动作：翻译用例 ≠ 定义通过

把测试工作拆开看，其实是两个性质完全不同的动作。

第一个动作是翻译：验收标准已经明确了——「金额字段必须是正整数」「未登录用户点结算要跳登录页」「退款超 7 天要拒答」——你把它们逐条变成用例、变成断言、变成脚本。这个动作规则清晰、可枚举、有大量范式，正是 AI 最擅长、也最先被自动化掉的部分。你手写它，只是在跟机器比谁打字快。

第二个动作是定义：面对一份模糊需求——「做一个智能退款助手，体验要好」——由你来判定「好」到底意味着什么、哪些是必须守住的红线、什么情况模型必须拒答、用什么口径算「通过」。这个动作没有现成答案，需要你对业务、对用户、对模型脾气同时下判断。AI 能帮你把定义好的标准翻译成用例，但它没法替你决定「什么才叫通过」。

慌，往往是因为把这两个动作混成了一团。你真正在被替代的，是第一个；而你真正该加码的，是第二个。

二、这恰恰是测试工程师的老本行

有意思的是，「把模糊需求拆成可判定标准」这件事，测试工程师干了很多年，只是换了个对象。

你当年做等价类划分，本质就是在模糊的输入空间里划出「哪几类值得测」；你做边界值分析，就是在给「通过/不通过」找那条精确的临界线；你写验收条件（acceptance criteria），就是把「产品说的体验好」翻译成「可判定的断言」。这些能力过去用在确定性系统上——输入定了、输出就定了。现在对象换成了不确定的模型：同样的输入，模型可能给出不同措辞、可能多一句话、可能该拒答时没拒。对象变难了，但你要干的事没变——还是把模糊拆成可判定，只是现在还要额外为「不确定性」本身定义验收口径。

所以这不是「测试工程师要转行去学一个新东西」，而是「测试工程师最核心的那部分判断力，突然变得前所未有地稀缺」。会用 AI 生成用例的人会越来越多，但能把一份含糊的模型需求拆成一套「模型也算得过、还能回归」的验收标准的人，依旧稀缺。

而且对象换成模型之后，「定义通过」这件事不是变简单了，是变难了。确定性系统里，输入定了输出就定了，你只要断言「等于某个值」；模型不一样——同一个问题问两次，措辞可能不同，可能这次带了句寒暄、下次没有，可能该拒答时它偏偏编了个答案。于是你不能再只写「结果正确」，得先想清楚：正确是指语义正确还是格式正确？允许它换措辞吗？换到什么程度算跑题？该拒答的边界划在哪？这些问题没有标准答案，全看你对业务代价的判断——答错一条会赔钱的场景，验收口径就得比闲聊机器人严苛得多。恰恰是这层「为不确定性定义口径」的活，AI 替不了，因为它需要的是对业务后果的权衡，而不是对范式的复现。

三、两类测试工程师的分野

把这两种定位摊开对照，差别一目了然：

这张表不是说执行不重要——执行永远需要有人兜底。它想说的是：如果你的时间几乎全花在第一个动作上，那你是在和 AI 抢一件它注定会赢的活；把重心往第二个动作挪，你才站在 AI 帮你、而不是替你的那一侧。

四、怎么写一份「模型也算得过」的验收标准

道理讲完，落到可操作。给模型类需求写验收标准，我会强制自己答清三件事，缺一件就说明标准还没定义完：

第一，可判定的输出契约。别写「回答要准确」，要写成能判真假的形式：输出必须是合法 JSON、必须含哪些字段、金额必须是正整数、必须包含哪些关键实体。判定标准越接近一条能跑的断言，AI 就越没法糊弄，你也越能把它接进回归。

第二，可回归的评测口径。别写「大多数情况表现好」，要写清用什么集子、按什么指标、过什么阈值算通过：拿一批固定的代表性 case，规定通过率不得低于某个线、相对上一版不得明显劣化。口径固定了，「换了模型/改了 prompt 到底变好还是变坏」才有得比。

第三，明确的拒答边界。模型需求最容易漏的就是「什么时候它必须闭嘴」：超范围要拒答、缺信息要追问、涉及风险要转人工。把这些边界写成可判定的 case，往往比写「正常路径」更能防住线上事故。

下面这段清单式的伪代码，是我拆解一个「智能退款助手」需求时会填的模板——它不追求能运行，追求的是逼自己把每一条都写到「可判定」：

# 验收标准拆解模板：智能退款助手（伪代码/清单）
需求原文（模糊）: "做一个退款助手，体验要好，能自动判断能不能退"

拆成可判定验收标准:
1. 输出契约:
   - 必须是合法 JSON，含字段 {eligible: bool, reason: str, amount: int}
   - amount 必须为正整数；eligible=false 时 reason 不得为空
2. 正常路径（等价类）:
   - 未超 7 天 + 有订单号 -> eligible=true
   - 已超 7 天           -> eligible=false，reason 说明超时
3. 边界值:
   - 恰好第 7 天 / 第 8 天 -> 分别验证 true/false 的临界判定
4. 拒答边界（最容易漏）:
   - 缺订单号        -> 必须追问，不得直接判 eligible
   - 问政策外的问题  -> 必须拒答或转人工，不得编造
5. 回归口径:
   - 固定评测集 N 条代表性 case，通过率不得低于阈值 T
   - 换模型/改 prompt 后，相对基线不得明显劣化

为什么强调「可判定」。你回头看这份模板：每一条都能被翻译成一条断言、一个 case——这时候你再把它丢给 AI 生成用例，AI 生成得又快又准，因为标准是你定的，它只负责翻译。这正好回到了开头的分工：定义是你的活，执行交给它。反过来，如果你给 AI 的只是「体验要好」，它只能生成一堆看似合理、实则无法判定的用例，跑绿了你也不知道到底测没测到点上。

想练这层判断力，有个很轻的日常习惯：下次拿到任何一条需求，先别急着让 AI 生成用例，逼自己先用一句话回答「这条到底什么叫通过」，并且这句话里必须出现一个能被机器判真假的条件。答不出来，说明需求还没定义清楚，这时候生成再多用例都是空转；答得出来，你就已经站在了 AI 帮不了、也替不掉的那一侧。日积月累，这份「把模糊拆成可判定」的手感，才是别人抄不走的东西。

AI 时代测试工程师的护城河，不在于你比它写得更快，而在于你能把一句「体验要好」拆成十条它算得过的验收标准。

你最近一次写验收标准，是停留在「回答要准确」，还是已经拆到了「可判定的断言」这一层？欢迎聊聊你怎么给模型需求定「通过」的口径。