大模型来了，测试岗不降反增？拆解 AI 测试的新机会

传统功能测试岗位需求在收缩，与此同时，懂大模型评测的测开岗位薪资在涨。脉脉、BOSS 直聘上的薪资差距是最直接的信号：传统功能测试和 AI 测试开发，已经不在同一个定价体系里了。

这不是矛盾，是结构性分化。AI 淘汰的从来不是“测试”这个岗位，而是“可被规则穷举的技能”。当测试对象从确定性系统变成不确定的 AI 系统，测试本身正在被重新定义。

一、先看清“不降反增”的真相

传统功能测试、兼容性测试、接口手工测试的岗位在大规模收缩。一个做了八年手工测试的工程师，面了十几家都拿不到 offer，因为面试官问的是“你怎么测大模型的幻觉”。

而另一边，AI 测试相关岗位在招聘平台上持续放量。南开大学就业指导中心发布的 AI 测试工程师岗位职责里，明确写着：参与 AI Agent 产品的测试和质量保障，设计测试用例验证回答准确性、工具调用、多轮交互、权限和系统稳定性，参与评测数据集、自动化评测工具及版本回归体系建设。

AI 没有让测试岗位消失，它在重新定价测试技能的价值。

二、测试对象变了，测试方法必须跟着变

过去我们测的是功能是否按预期执行。一个接口输入 A 返回 B，一个按钮点下去弹出 C。确定的、可枚举的、可重复验证的。

现在越来越多的系统里嵌入了大模型和 Agent。失效模式发生了根本变化——不再是功能 Bug，而是决策偏差、幻觉输出、工具误调用。

用传统测试的眼光看，一个 Agent “最后结果对了”就没问题。但从 AI 质量的角度看，它可能中间调了三次错误的工具、绕了五步弯路，这已经是定时炸弹。

测试从“验证功能”变成了“验证行为” 。测试对象的行为不再是确定的，测试方法就不能停留在精确匹配上。

三、真正实用的 AI 测试技巧与知识

机会集中在几个具体且稀缺的能力方向上。以下是当前最明确的切口和可落地的技巧。

技巧一：语义断言替代精确匹配

传统测试用 assertEquals，但大模型的输出没有两次是完全一样的。同一个问题问两遍，措辞可能完全不同，但意思都对。

实用做法：用 embedding 算语义相似度，意思对就放行。语义也比不了的，让另一个大模型当裁判，按你给的验收标准打分。裁判模型和被测模型尽量不同源，避免“自己给自己放水”。RAGAS 这类框架已经提供了现成的评分器，比如 SemanticSimilarity 和 AnswerAccuracy。

技巧二：RAG 要分两层测，不能只看最终答案

内部知识库、智能问答基本都是检索增强生成。最容易犯的错是只测“最终答案对不对”，结果答错时根本不知道是没检索到还是检索到了却答歪了。

实用做法：检索层测召回，生成层测忠实度。RAGAS 框架提供了完整的指标组合：

• ContextPrecision：检索到的相关文档排名是否高于无关文档
• ContextRecall：检索上下文是否包含回答查询所需的全部信息
• Faithfulness：输出是否与检索上下文实际一致（检测幻觉的核心指标）
• AnswerRelevancy：生成的答案是否真正回答了输入查询

Faithfulness 的实用算法是：把回答拆成独立的事实断言，逐条问“这个断言能从检索到的原文推出来吗”，算支持率。如果 faithfulness 低于阈值（比如 0.8），说明回答里大量内容没有原文支撑，存在幻觉风险。

技巧三：Agent 测的是过程，不是结果

Agent 调用工具时，“瞎调三次最后蒙对了答案”在生产上就是事故。要断言的是调用链路：调没调、调对没调对、参数合不合法。

实用做法：用断言框架检查 Agent 的轨迹（trace）。agentval 这类库提供了专门的断言方法：

import agentval as ap

def test_agent_searches_before_summarizing():
    trace = ap.Trace.from_file("traces/my_agent.json")
    
    # 断言工具被调用了
    ap.tool_called(trace, "web_search")
    
    # 断言调用顺序
    ap.step_order(trace, ["web_search", "summarize"])
    
    # 安全断言：Agent 绝不应该调用删除操作
    ap.tool_not_called(trace, "delete_file")
    
    # 根因分析：当第8步失败时，追溯到第1步的错误
    report = ap.analyze(trace)

同时把“越权调用、提示词注入”纳入用例——用户一句话就可能让模型“叛变”，这是传统测试没有的攻击面。

技巧四：幻觉测试要分层组合

没有绝对标准答案的情况下，幻觉测试需要分层策略：

第一层：规则检测——快速过滤明显幻觉。检测自相矛盾（用模型检查回答内部是否前后冲突）、标记不确定性表达（“可能是”“据称”“据说”等推测性词汇）。

第二层：外部知识校验——用知识库或搜索引擎验证事实性断言。

第三层：LLM-as-a-Judge——用更强的模型当裁判，按验收标准打分。

第四层：人工抽检——兜底和校准，尤其是敏感或主观任务。

技巧五：把评测跑进 CI

大模型功能最坑的地方：你没动代码，只是改了句 prompt、或者供应商悄悄升级了模型，线上质量就掉了。

实用做法：评测要像接口自动化一样进流水线，每次改动都跑。mcp-llm-eval 这类工具支持在 CI 中配置阈值门禁：

# .eval-gate.yml
thresholds:
  avg_faithfulness: 0.80
  avg_relevance: 0.75
  p95_ttft_ms: 500
  max_cost_per_query: 0.01

评测结果可以直接生成 PR 评论，检测回归是否超过容差，阈值不通过就阻断合并。

技巧六：攒一套 golden 数据集，这是最值钱的资产

评测需要“黄金数据集”：真实用户问题 + 人工标注的合格答案。它充当根据定义的质量指标评估模型性能的目标基准。

实用做法：把线上发现的坏案例和好案例，清洗脱敏后沉淀到离线评测集里。线上数据持续反哺离线实验室，形成“越用越准”的飞轮。数据集要覆盖多领域、多问题类型，并保持分布均衡，避免因数据偏差导致评测结果失真。

四、转型不是“重新学一遍 AI”

如果你已经有一到三年的测试经验，你过去积累的场景设计能力、边界构造思维、自动化基础，恰恰是 AI 测试最需要的基本功。

你以前做接口测试时测的那些场景——未登录访问、Token 失效、参数篡改、越权访问、异常参数、重放请求——本质上是“测试系统能不能抵抗一个主动寻找边界的调用方”。AI Agent 也是一样，只是对象从接口变成了一个可能自主行动的智能系统。

你不是在推翻过去的经验，是在把测试思维应用到一个更复杂、更不确定的系统上。

风口来的时候，焦虑没用。与其纠结“AI 会不会取代测试”，不如去研究一下 RAGAS 的 Faithfulness 怎么算、agentval 的 trace 断言怎么用、评测门禁怎么配进 CI。这些东西没有多难，但门槛在于你愿不愿意动手去测第一个大模型应用。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。