朋友上周去面测试开发岗，回来跟我吐槽：背了一肚子接口自动化八股，结果面试官问的是"AI 生成的测试脚本，你敢直接用吗？你怎么验收？"他当场卡壳。这个追问听起来刁钻，仔细想却一点都不意外。
为什么题型会变
逻辑很简单：面试题跟着测试对象走。2026 年 8 月 13 日晚，DeepSeek 发布首款开源 Agent 产品 DeepSeek Harness（简称 dsh），两天左右破 10 万星，目前超过 15 万星。它的理念是"一切皆插件"，模型适配、工具注册、会话日志、Agent Loop 都是可插拔组件，而它的终极目标更激进——Agent 在运行中自己编写、安装插件，错误修改可撤回。行业讨论的焦点已经变了：当 Agent 能自己写插件、自己改自己，"测试对象"就从静态代码变成了会自我演化的系统，传统测试方法面临重构。测试工作本身在变，面试题自然会跟着变。其实不用等面试，看看团队里日常的技术讨论就知道风向：以前聊框架选型、聊用例设计，现在越来越多地聊怎么给 Agent 定验收标准、怎么给模型输出设门禁。下面是我整理的三组对照例题，感受一下风向。
第一组：从"手写自动化"到"验收 AI 的自动化"
旧题型：请用 requests + pytest 手写一个登录接口的测试脚本。
新题型：AI 给你生成了一份测试脚本，你如何验证它是正确、可用的？
旧题考的是写代码的手艺，新题考的是验收的眼力。答题思路是给 AI 产物设一道"验收门禁"：先做静态检查，语法是否合法、有没有危险调用、有没有断言——AI 很喜欢生成看似完整、实则没有任何断言的摆设代码；再做冒烟执行，在限时隔离环境里跑一遍看结果；最后抽样审查断言是否真的对应业务规则，同时看覆盖增量，警惕"用例数量多＝质量好"的错觉。如果面试官追问"AI 生成的脚本永远通过怎么办"，可以接一句：故意植入一个已知缺陷，看用例能否抓住它——这就是变异测试的思路，专治"永远绿灯"的废用例。
面试时可以手写这样一段验收示意：
简化示意：对 AI 生成测试代码的验收门禁
import ast
import subprocess
import sys
DANGEROUS_CALLS = {"eval", "exec", "system", "popen"}
def static_check(code: str) -> list[str]:
"""静态检查：语法合法 + 无危险调用 + 存在断言"""
tree = ast.parse(code) # 语法错误会直接抛 SyntaxError
problems = []
has_assert = False
for node in ast.walk(tree):
if isinstance(node, ast.Assert):
has_assert = True
if isinstance(node, ast.Call):
name = getattr(node.func, "id", None) or getattr(node.func, "attr", None)
if name in DANGEROUS_CALLS:
problems.append(f"疑似危险调用: {name}")
if not has_assert:
problems.append("未发现断言，疑似冒烟摆设")
return problems
def smoke_run(code: str, timeout: int = 60) -> bool:
"""冒烟执行：限时子进程运行，退出码为 0 才通过"""
result = subprocess.run(
[sys.executable, "-c", code],
timeout=timeout,
capture_output=True,
)
return result.returncode == 0
第二组：从"断言精确返回值"到"回归非确定性输出"
旧题型：接口返回固定 JSON，你如何设计回归用例？
新题型：模型输出是非确定性的，同一个输入每次结果都不同，回归怎么做？
旧题的答案是等价类、边界值、精确断言；新题要换一套思路。答题要点：放弃"断言精确值"，改成"断言性质"——多次运行看通过率的分布，用统计结论代替单次结论；维护一组有代表性的基线用例（golden set），每次版本升级后固定跑一遍；打分上结合结构校验与语义评估。工程上还要把评估固定到具体环境和版本，每轮跑分留档，时间长了形成趋势线，质量回退才看得见。如果还能补一句"评估环境必须可复现，否则任何结论都不可信"，基本就是做过实战的人。
第三组：从"怎么提一个 bug"到"怎么给自进化系统归因"
旧题型：发现缺陷后，请描述你的复现和提交流程。
新题型：Agent 在生产环境出了错，但它当时的插件组合是自己临时装配的，你怎么复现？这算谁的问题？
这道题非常针对 dsh 这类场景。传统复现靠"代码版本＋环境"，自进化系统还要加一层运行时装配状态。答题思路：复现必须依赖快照——出错时刻的插件列表、会话日志、模型版本都要留痕；这正是"可检查"设计的价值，会话日志本来就是 dsh 里可插拔、可检查的组件。缺陷归因也要跟着变：从"这段代码是谁写的"变成"哪个环节的决策错了"——是模型决策错、工具实现错，还是插件组合错。再往前一步可以说：回滚机制本身也要被测试，撤销是否完备、顺序是否正确，都是新用例。从建设角度，这意味着要把审计日志从可选项变成必选项——Agent 运行时的每一次装配变化，都该留痕。
三组新题的共同逻辑
回头看这三组题，有一条共同的暗线：考察重心从"执行"挪到了"判断"。旧题型考你脚本写得快不快、用例设计得全不全——目标明确，你负责执行好；新题型默认产物本身可能不可靠，甚至目标都在变化，你得先回答"凭什么判定它可靠"。执行能力正在被 AI 接管，判断能力却很难被替代，这才是题型变化的根本原因。
求职者该怎么准备
我的建议是三件事。第一，把 Agent 原理补上，至少能讲清 Agent 循环在做什么，理解"一切皆插件"指的是模型适配、工具注册、会话日志这类组件都可替换。动手门槛其实不高，装好 Node.js 后一条 npx @deepseek-ai/dsh web 就能拉起体验环境，把亲手操作过的观察写进简历，比背十段介绍都管用。第二，把 AI 测试方法论练熟，非确定性测试、评估集、语义打分，每一项最好都有动手记录。第三，培养验收思维，AI 时代里"判断别人（包括机器）的产出是否可靠"的能力，比自己从头写更稀缺——比如聊到 AI 辅助编码时，主动讲讲你验收机器产出的具体做法，往往比罗列技术栈更能打动面试官。
题型在变，内核没变：面试永远在考你对"质量"二字的理解，只是质量的定义正在被改写。
本文整理自霍格沃兹测试开发学社的原创分享，更多测试开发与 AI 测试实战内容，我们下一篇见。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
