AI测试面试的考察方式正在从“会不会写测试用例”变成“能不能建立一套可重复的AI质量评估链路”。8月份通常是一二三线城市招聘节奏加快的窗口如果准备近期投递AI测试方向简历上还只有接口测试、UI自动化和传统自动化脚本可能在初筛环节就被筛掉。现在的面试官更关心几个具体问题这个AI功能要怎么测、评测指标怎么打、模型乱输出时怎么兜底、同一个问题问十次结果不一样怎么处理。这已经不是“背几个大模型概念”能应付的面试强度而是要求候选人具备代码能力、数据能力、评测设计和排错能力。要理解这种强度先要拆清楚一个前提AI测试并不是一个单一岗位。不同企业口中的“AI测试”可能完全不是一回事。有些团队招“AI测试工程师”实际是做AI应用的产品质量保障被测对象是大模型接口、知识库问答、Agent工作流有些团队招的“测试开发”则是要求用大模型改造测试流程自动生成用例、自动定位失败原因。严格来说这是两条能力线但在面试现场往往被混合考察所以不能只准备其中一条。1. 8月AI测试面试的强度变化面试官到底在考什么1.1 “AI测试”不是单一岗位先分清两种能力线第一条能力线叫“测试AI”。被测对象是AI应用本身比如智能客服、内容审核、代码生成助手、Agent应用。这类测试的目标不是验证一个普通接口而是验证模型输出是否符合业务预期。传统测试里的预期结果通常是确定值比如登录接口返回200、购物车多了一个商品AI测试里预期结果往往是语义级别的例如“回答不能包含未经验证的医学建议”“不能对用户进行价值判断”“知识库没有覆盖的问题不能编造答案”。第二条能力线叫“用AI做测试”。被测对象还是软件系统但测试人员借助大模型生成用例、分析页面截图、从需求文档提取测试点、批量分类缺陷。这类能力更像测试开发但它叠加了prompt工程、模型评测、成本控制和稳定性设计。企业希望测试团队能通过AI降低手工成本于是会考察候选人能不能写一个稳定的用例生成脚本而不是只在网页上配置聊天机器人。面试时面试官不会直接说自己要考哪条线。很多人拿到的题目是“你准备怎么测试一个基于大模型的智能客服”实际考察的是两条线的融合既要设计AI应用的评测方案又要写出可落地的评测脚本。因此训练时要双向准备不能只学prompt也不能只学pytest。1.2 面试强度从功能执行升级到评测与工程化传统测试面试的高频考点是功能用例设计、接口测试、压力测试、自动化脚本。这些能力并没有过时但它们更多被当作“基础分”不再是决定性因素。AI测试岗位的加分项集中在这几类是否能设计语义级别的评测指标而不只是看接口通不通。是否能识别模型输出中的幻觉、偏见、安全风险。是否能搭建数据标注、批量回放、指标统计的回归测试流程。是否能处理模型输出的随机性让测试结果可以被信任。是否能评估RAG检索质量、Agent工具调用链路、多轮对话状态。下面的表可以比较直观地看到能力要求的迁移考察维度传统软件测试AI测试预期结果确定性状态码、字段、页面元素语义级正确性、忠实度、安全性缺陷类型功能缺陷、性能瓶颈幻觉、回答不一致、越权、提示注入、召回缺失测试数据固定测试数据标注集、对抗样本、随机输入断言方式等于、包含、不为空关键词覆盖、相似度、规则命中、人工抽检稳定性结果可复现需要控制温度、版本、上下文并容忍合理波动工具链Postman、JMeter、Selenium、AppiumLLM API、评测框架、向量库、Prompt管理、Agent模拟从这个表可以看出AI测试面试的强度不体现在“题目变难”而是体现在“被测对象变复杂”。如果候选人只掌握第一列回答第二列的问题时会明显感到无法落地这也是很多人面完后觉得“聊不下去”的原因。1.3 面试官判断“能去面试”的三个信号面试官筛选候选人时主要看三个信号。第一个信号是项目是否有完整闭环。做过AI测试项目的人能说清楚数据从哪来、指标怎么算、阈值怎么定、失败怎么分析、回归怎么跑只停留在“我用ChatGPT生成了测试用例”的人讲不出评测闭环。第二个信号是能不能解释“为什么”。例如为什么给模型设定temperature0还不能完全消除随机性为什么评测指标用recall而不是accuracy为什么RAG应用要单独测检索质量。这些问题没有标准答案但它能区分“背过名词”和“实际踩过坑”。第三个信号是面对模型随机性时有没有自己的方法。面试官常问“模型输出每次都不一样你怎么跑自动化测试”如果只回答“固定seed”或“调到temperature为0”会被追问到细节。实际可行的回答至少包括先对输出做结构化解析再对关键字段做语义断言同时记录原始输出和版本号最后用多次运行的结果分布而不是单次结果判断质量。2. 练到这个水平的前提技术栈、环境与数据集2.1 需要补齐的六项核心能力在准备面试项目之前先检查自己是否具备这六项能力Python基础能写函数、能处理JSON、能读写文件、能处理异常。自动化测试基础至少掌握pytest的fixture、断言、参数化、失败重跑。HTTP/API经验理解请求头、鉴权、状态码、响应体结构能处理流式响应。大模型API调用知道如何构造对话消息、如何解析chat.completions返回、如何设置temperature和max_tokens。数据理解能准备小规模标注数据能计算准确率、召回率、F1能分析模型错误样本。评测设计能针对问答、摘要、分类、Agent工具调用设计不同评测方案。如果前两项还不熟先不要急着写AI项目。很多面试失败的原因不是不懂AI而是代码量太少现场写一个评测函数都要卡壳。建议先用一个星期把pytest和requests练熟再叠加模型API调用。2.2 本机环境准备Python虚拟环境和依赖库学习环境不需要 GPU。大多数大模型能力可以通过API获得本地只需要一个Python环境。推荐从虚拟环境开始避免依赖污染。mkdir ai_test_prep cd ai_test_prep python3 -m venv venv source venv/bin/activate然后在虚拟环境中安装依赖。下面的requirements.txt是示例实际安装时以当前稳定版本为准requests2.31.0 pytest8.2.2 openai1.35.7 python-dotenv1.0.1代码中不直接写api_key使用环境变量文件.envLLM_API_KEY在这里填入你的key LLM_BASE_URLhttps://api.example.com/v1 LLM_MODELyour-model-name用python-dotenv加载import os from dotenv import load_dotenv load_dotenv() client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL), )这里要特别注意很多国产大模型、私有化模型都提供OpenAI兼容接口只需要改base_url和model即可。所以代码可以先用OpenAI接口风格写落到公司项目时再替换成实际服务。这也是面试中可以说得清楚的一个点方案不需要绑定具体厂商。2.3 没有GPU时如何完成可面试的AI测试实践没有GPU不等于不能做AI测试实践。建议按三个层次递进第一层直接用大模型API 本地Python脚本。适合做评测、用例生成、Prompt稳定性分析也是面试项目的基础。第二层本地跑开源小模型比如通过ollama拉取支持GGUF格式的7B或14B模型。这适合演示离线测试流程但要注意磁盘空间和首次加载时间。使用时不编造具体版本以ollama list和模型仓库说明为准。第三层构造一个“模拟AI服务”。用本地函数模拟模型输出比如根据问题返回预设答案。这样可以在没有外部网络、不消耗API成本的情况下调试pytest、断言和指标统计。面试时也可以强调真实服务没有就绪时用桩服务先跑通测试链路也是一项测试开发能力。数据集方面不建议一开始就用几十万条的公开数据集。先自己做20条带标签的问答对标注每道题的期望要点用于后续评测。可以整理成以下格式[ { question: 退货流程怎么走, key_points: [签收, 退货申请, 审核, 退款], category: after_sale }, { question: 发票什么时候可以开, key_points: [订单完成, 电子发票, 一个月内], category: invoice } ]这组数据规模小却能支撑起一个完整的评测项目输入几十条问题调用模型服务或桩服务把回答和key_points对比计算覆盖率和失败样本。这个模式在面试中比“我调过大模型的API”更有说服力。3. 做一个真正能讲清楚的项目AI客服评测最小闭环3.1 项目目标与目录结构为了面试建议做一个最小但完整的AI客服评测工具。它的目标不是实现客服系统而是搭建一条可复用的评测链路问题集 - 模型服务 - 输出解析 - 指标计算 - 回归报告。做到这个程度面试时几乎每个环节都能展开提问。目录结构可以这样安排ai_test_prep/ ├── .env ├── requirements.txt ├── data/ │ └── eval_questions.json ├── src/ │ ├── __init__.py │ ├── llm_client.py │ ├── evaluator.py │ └── parser.py └── tests/ └── test_chatbot_eval.py这个结构不复杂但要带着几个问题去理解data/eval_questions.json保存评测用例而不是硬编码在代码里。llm_client.py负责调用外部模型服务方便以后替换成真实接口。parser.py负责把模型返回的文本解析成JSON处理格式不稳定的情况。evaluator.py负责计算指标与测试框架解耦。tests/中使用pytest把评测固化成回归测试。3.2 用大模型API批量生成测试用例AI测试项目里一个常见需求是从需求描述生成测试用例。下面的代码演示最小实现使用OpenAI兼容接口# src/llm_client.py import os from openai import OpenAI from dotenv import load_dotenv load_dotenv() client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL), ) def generate_test_cases(requirement_text: str, model: str | None None): model_name model or os.getenv(LLM_MODEL, your-model-name) prompt 你是一名资深测试工程师。请根据下面的需求生成5条测试用例。 只输出JSON数组不要输出解释。每条用例包含字段id、title、precondition、steps、expected。 需求 {requirement_text} .strip() resp client.chat.completions.create( modelmodel_name, messages[ {role: system, content: 你是严谨的测试专家输出严格JSON。}, {role: user, content: prompt}, ], temperature0.2, ) return resp.choices[0].message.content这段代码的重点不是模型本身而是工程细节。temperature设置成0.2而不是0是为了在二次生成时保留一点语义灵活性同时让多数输出保持稳定max_tokens在真实项目中要按用例长度配置建议在面试时主动补充这个说明。模型返回的内容经常不是恰好一段JSON可能被 json 代码块包裹或者夹带额外说明。因此需要一个容错解析函数# src/parser.py import json import re def extract_json(text: str): text re.sub(r^(?:json)?|$, , text.strip(), flagsre.MULTILINE).strip() start text.find({) end text.rfind(}) if start -1 or end -1: raise ValueError(模型输出中没有找到JSON: text[:200]) try: return json.loads(text[start : end 1]) except json.JSONDecodeError as exc: raise ValueError(fJSON解析失败: {exc}原始内容: {text[:200]}) from exc这个函数是面试中很关键的一点因为“模型输出的格式不稳定”是AI测试的一个核心问题。能主动写出容错解析说明你理解被测对象本身具有不确定性。3.3 用规则与指标评测模型回答智能客服评测不能只判断“有没有返回”还要判断“回答是否覆盖了业务要点”。先用关键词覆盖做初版虽然粗糙但容易理解也方便面试时扩展开。# src/evaluator.py def evaluate_answer(question: str, key_points: list[str], answer: str) - dict: hit sum(1 for point in key_points if point in answer) recall hit / len(key_points) if key_points else 1.0 return { question: question, hit: hit, key_point_count: len(key_points), recall: round(recall, 4), answer_length: len(answer), }为了让脚本不依赖外部服务即可运行可以写一个“桩服务”模拟模型回答def get_chatbot_answer(question: str) - str: replies { 退货流程怎么走: 签收后七天内可以在订单详情提交退货申请审核通过后退款。, 发票什么时候可以开: 订单完成后可以在财务模块申请电子发票有效期一个月。, } return replies.get(question, 没有找到相关资料请咨询人工客服。)真实项目里这个函数应该改成requests.post或client.chat.completions.create调用。面试时可以用桩服务先讲清楚评测链路再说明替换成真实模型服务的位置。最后写一个批量评测入口# src/run_eval.py import json from src.evaluator import evaluate_answer from src.llm_client import get_chatbot_answer with open(data/eval_questions.json, encodingutf-8) as f: dataset json.load(f) results [] for item in dataset: answer get_chatbot_answer(item[question]) result evaluate_answer(item[question], item[key_points], answer) results.append(result) total_recall sum(r[recall] for r in results) / len(results) print(f平均召回率: {total_recall:.2%}) for r in results: print(r)这里注意get_chatbot_answer在不同版本的代码里可能放在不同模块实际项目中要保持导入路径一致。如果这一行报ImportError优先检查目录结构是否包含__init__.py以及是否在项目根目录运行。3.4 把评测固化成pytest回归测试面试时光说“我能跑脚本”是不够的应该说“我把评测集固化成回归测试每次版本变更都能自动跑”。用pytest封装# tests/test_chatbot_eval.py import pytest from src.evaluator import evaluate_answer from src.llm_client import get_chatbot_answer SAMPLE_CASES [ { question: 退货流程怎么走, key_points: [退货申请, 审核, 退款], min_recall: 0.6, }, { question: 发票什么时候可以开, key_points: [订单完成, 电子发票], min_recall: 0.5, }, ] def test_chatbot_answer_coverage(): for case in SAMPLE_CASES: answer get_chatbot_answer(case[question]) result evaluate_answer(case[question], case[key_points], answer) assert result[recall] case[min_recall], ( f问题: {case[question]}, 召回率过低: {result} )运行方式pytest tests/ -v预期输出会出现每个用例的PASSED或FAILED。这是面试项目里最重要的验证证据不是模型调用成功而是评测断言真实生效。3.5 运行结果与面试讲法项目做出来后不需要准备复杂PPT但要能一口气讲清楚这条链路“我的评测项目使用20条带业务要点的问答数据。先调用模型服务得到回答再用关键词召回率判断是否覆盖关键信息最后通过pytest跑成回归。对没有命中的样本会单独导出错误明细由测试人员判断是模型问题、prompt问题还是知识库缺失。”如果面试官追问“关键词覆盖率不准怎么办”可以说“可以把关键词规则升级成向量相似度、语义蕴含判断或人工抽检关键词是初版可解释方案不是终态。”这个回答能体现工程取舍能力。4. 用一套题面自测练到这个水平再去面试4.1 高频概念题20分钟口头抽查准备AI测试面试概念题不能只背定义。建议找一个安静环境模拟面试官提问每个问题先闭嘴想10秒再口头回答。如果答不出来就回到项目代码里找对应场景。问题回答要点什么是幻觉模型生成看似合理但与事实不符的内容测试要关注业务高危场景RAG是什么检索增强生成先从知识库检索相关片段再交给模型生成RAG测试关注什么检索召回率、知识片段相关性、引用是否有依据、找不到资料时是否拒答temperature有什么影响控制采样随机性越低越稳定但不会彻底消除随机性为什么模型输出不稳定采样策略、温度、上下文长度、模型版本都影响输出如何衡量回答质量准确率、召回率、忠实度、安全性、稳定性、耗时什么是提示注入用户输入尝试改写系统指令测试时要覆盖这种对抗输入Agent测试难点是什么工具调用链路长、状态多、外部依赖复杂要分步断言大模型API返回异常怎么排查先看HTTP状态码、响应体、限流和鉴权再看prompt和参数评测集怎么维护按业务场景分层定期加入线上bad case避免模型升级后回归遗漏口头回答时要注意不要只丢术语。比如回答“temperature控制随机性”后最好再补一句“所以我跑回归时会固定temperature但不会只依赖这一点还会多次运行看结果分布”。这句话能显著拉高印象分。4.2 场景设计题如何设计AI应用的测试策略面试官经常给一个场景智能客服要上线你怎么制定测试方案。回答要按层次展开而不是零散地说“准备测试数据、测一下”。推荐的回答框架先定义风险范围应答准确性、业务约束、安全性、稳定性、性能。再准备评测集覆盖常见问题、边界问题、恶意输入、未知问题、历史bad case。接着设计指标回答召回率、不相关回答率、拒答率、错误率、平均响应时间。然后做回归机制每次模型或prompt变更后跑同一份评测集对比指标。最后处理线上问题线上bad case定期回流到评测集形成闭环。这个框架能覆盖“测试AI”和“用AI做测试”两层而且没有用到任何特定工具适合不同业务背景。面试官如果追问“评测集怎么来”可以回答前三个版本人工标注后续把bad case和线上抽检回流进去淘汰老旧问题。4.3 现场编程题写一个模型输出评测函数有些面试会现场出题要求写一个函数校验模型输出是否包含关键信息。参考解法如下def check_answer(answer: str, key_points: list[str]) - dict: hit_points [point for point in key_points if point in answer] missing_points [point for point in key_points if point not in answer] recall len(hit_points) / len(key_points) return { hit_points: hit_points, missing_points: missing_points, recall: recall, pass: recall 0.6, } # 示例调用 print(check_answer(签收后可以申请退货审核通过后退款, [退货申请, 审核, 退款]))写完后要主动补充“这个函数只适合中文关键词完全匹配如果模型用同义词表达比如‘退货’说成‘退回’就会漏判。生产环境需要结合相似度模型或同义词表。”这种表达能体现你对方案的边界有判断而不是只交出代码。4.4 自测评分表判断是否达到投递门槛投递前可以用下面的评分表自测。每项1分按“能不能独立讲清楚且给出代码”打分。建议至少拿到4分再投递能力项0分状态1分状态2分状态模型API调用只在网页上聊过能写代码调用并解析返回能处理流式、异常、超时、鉴权评测设计只会说“看准确率”能设计针对业务场景的指标能解释指标缺陷并补充人工抽检自动化测试不熟悉pytest能写基本断言和参数化能把评测集固化到CI并输出报告数据分析不知道召回率怎么算能写纯Python计算指标能分析错误样本并反推测试集改进排错能力报错后无从下手能看HTTP状态码和日志能按排查链路定位模型、数据、代码问题这个表不是标准化考核而是给准备过程画一个框架。面试不是“把所有知识学完”而是先达到一个能正常交流的基准线再在真实面试中暴露问题、继续补齐。5. 练习过程中的高频坑与现场排查链路5.1 坑一只练Prompt不练评测和工程化很多人准备AI测试时把大量时间花在“怎么写好prompt让模型生成用例”但面试官会立刻问“模型生成的用例你怎么验证质量”如果只能回答“人工看一下吧”就会暴露工程化短板。Prompt能力有用但在测试岗位面试里它只是入口不是结果。重点应该放在生成结果的可解析性、可执行性、可度量性。练习时不要把“模型输出了”当作成功要把“模型输出能被解析和断言”当作成功。5.2 坑二项目停留在“调用API”没有回归和指标只写一个脚本运行client.chat.completions.create就说是AI测试项目是最常见的简历注水。面试官稍微追问评测集有多少条、指标是什么、失败标准是什么、遗漏样本怎么处理就难以接住。建议在项目里至少加入一份评测集条数不用多但要有业务标签。一个评价指标比如关键词召回率、格式有效比例、拒绝响应率。一个失败分析输出把未命中样本单独写成JSON文件。一个pytest入口能在命令行一键回归。有了这四个要素项目才具备“测试闭环”的说服力。5.3 坑三忽略模型输出的随机性跑一次就断言“正常”部分大模型API在temperature0时仍可能因为框架差异、采样算法版本、上下文编码不同而出现输出变化。如果只跑一次就得出结论这个测试结果不可复现。正确的做法是同一个用例跑多次统计通过率关键用例需要看单次的具体输出区分“偶发失败”和“稳定失败”。实践时可以在pytest里给关键用例加pytest.mark.parametrize(run_count, range(3))pytest.mark.parametrize(run_count, range(3)) def test_chatbot_answer_multiple_runs(run_count): answer get_chatbot_answer(退货流程怎么走) assert 退货申请 in answer这里run_count参数本身不会被函数体直接使用但它能让pytest生成三次独立执行便于观察波动。真实项目中建议把输出保存到文件避免只看控制台结果。5.4 现场出问题时按这条链路排查面试或练习中评测脚本报错时不要慌张。按下面的链路排查能覆盖大部分问题先确认输入。问题文本、key_points是否有空值编码是否为UTF-8。再确认API连接。检查base_url是否以/v1结尾api_key是否有效HTTP响应是否有401或429。然后看原始返回。不要直接解析先打印resp.choices[0].message.content看模型是否返回了预期内容。再看解析层。如果JSON解析失败优先用容错解析函数并检查是否存在代码块标记。接着检查断言。模型输出有内容但断言失败先看key_points是否粒度太小或者模型用了同义表达。最后看随机性。同一输入跑了多次结果不同需要降低temperature或增加多次运行统计。这条链路在面试现场可以直接说出来它体现的不是背题能力而是实际的调试思路。面试官往往更愿意接受“先看原始输出再定位”的回答而不是一上来就怀疑模型厂商。5.5 面试回答时的认知误区速查表误区正确认知“大模型测试就是看准确率”准确率只适合分类生成式任务要结合召回、忠实度、安全、稳定性“temperature0就没有随机性”多数场景能显著降低随机性但不能作为唯一保证“评测集越多越好”更关键的是覆盖率和标签质量20条高质量bad case比200条重复数据有效“AI生成用例不需要维护”prompt变化、模型版本变化都会让生成质量漂移需要持续评测“AI测试不需要人工抽检”自动指标只能兜底重要业务场景必须保留人工判定6. 面试前最后一轮检查能力清单、生产实践与扩展方向6.1 面试前自检清单面试前一天早上把下面几项完整过一遍[ ] 能独立创建Python虚拟环境并安装依赖不报错。[ ] 能写出调用OpenAI兼容接口的完整脚本并解析返回内容。[ ] 能解释准确率、召回率、F1的区别并写出计算逻辑。[ ] 能准备一份20条以上的业务评测集每条有question和key_points。[ ] 能把评测集接入pytest运行后能看到通过或失败。[ ] 能说出三个以上的AI测试风险点比如幻觉、提示注入、格式不稳定。[ ] 能按排查链路定位一次API调用失败而不是直接放弃。[ ] 能用两三句话讲清楚自己项目里的测试闭环。[ ] 能给出至少一个“当前方案有缺陷”的改进方向。[ ] 能展示一次失败分析哪条用例没过为什么怎么改。如果有一半没做到建议不要急着投递。再花两天补齐最薄弱的两项比盲目海投更有效率。6.2 学习环境与生产环境的差异面试准备阶段可以在自己电脑上跑通最小闭环但生产环境的AI测试要复杂得多。下面这张表可以帮助你回答“如果让你在正式项目里落地这个方案你会怎么改”环节学习/面试项目生产实践模型服务本机脚本或桩服务独立服务、接口鉴权、限流、灰度API密钥.env保存配置中心或密钥管理服务评测集手工维护JSON文件测试平台管理包含bad case回流用例运行本地pytestCI流水线定时任务分环境执行指标记录控制台打印存入数据库展示趋势图设置告警模型版本固定一个模型名记录模型版本、prompt版本、评测集版本随机性控制多次运行看结果固定seed、统计分布、设置通过率阈值异常处理捕获异常并打印重试、降级、告警、错误日志完整采集回答这类扩展问题时可以主动说“我会先做成一个最小可用版本跑两周积累足够失败样本后再补充平台化和告警”。这比把方案说得特别大而空要好。6.3 能直接用在项目里的最佳实践从AI测试面试准备到真正的项目落地有几条经验可以直接复用不要在断言里使用过于苛刻的精确匹配。模型输出中的同义词、语序变化都很正常建议先做关键词覆盖、长度合理性检查再逐步加入相似度模型。不要在高频用例里反复调用大模型API。评测集的每条样本在每次回归都会产生调用成本生产环境要控制用例规模并把稳定的评测结果缓存下来只重新执行受影响的用例。不要只依赖单一指标做上线判断。建议用“自动指标 人工抽检 失败样本分析”三层机制。自动指标负责发现问题人工抽检负责判断是否误报失败样本分析负责把问题归类再决定是改prompt、补数据还是修代码。不要忽视失败样本的归档。每次回归失败后把问题、模型输出、模型版本、prompt版本一起保存。没有版本信息的失败样本后面很难定位是模型升级导致还是prompt改动导致。6.4 从“能面试”到长期竞争力的扩展方向练到能去面试只是第一关。真正进入AI测试岗位后会不断遇到新的问题如何评测多轮对话、如何评估Agent工具调用、如何做线上真实流量回放、如何判断向量检索质量。建议按下面方向继续延伸多轮对话测试关注上下文记忆、话题切换、指代消解和错误累计。RAG评估对知识库分片质量、检索排序、引用完整性分别建模。Agent测试为每个工具调用设计单独的断言再组合成链路级测试。评测平台化把测试集、模型版本、指标报告沉淀成内部平台。数据回流把线上bad case自动聚类批量扩充评测集。如果时间有限优先做RAG评估。因为RAG是目前企业落地大模型应用最主流的架构面试提问概率高而且能从检索、生成、引用三段式展开比单纯聊“测试大模型”更好展示工程思路。AI测试面试真正考察的不是“会不会回答某一类题目”而是能不能在一段对话里证明自己对AI系统和测试系统都有判断。面试前不要追求把所有材料背完先把评测闭环跑通再围绕项目把每个决定背后的原因讲清楚。做到这一步再去面对二面里的开放场景题就有足够的底气把问题拉回自己熟悉的实操链路。