摘要： 现在不少测试工程师已经习惯用 AI 辅助编写自动化脚本、生成测试用例，甚至搭建测试框架。但到了技术面试，面对“这段代码是你写的还是 AI 写的”，很多人反而不知道怎么回答。面试官真正关注的，可能不是代码由谁敲出来，而是你能否解释设计思路、发现生成代码的问题，并对最终交付的测试结果负责。本文通过具体的测试开发案例和模拟面试追问，拆解如何回答这个问题。
01. 面试官一句“这是 AI 写的吗”，为什么很多人慌了？
假设你参加一场测试开发工程师的技术面试。
你介绍了自己在项目中搭建的 Python + Pytest 接口自动化测试框架，包括参数化测试、接口封装、测试数据管理、环境配置和持续集成。
面试官看完项目代码，突然问：
“你这里面的测试脚本，是自己写的，还是用 AI 生成的？”
这时候，你怎么回答？
有些人下意识地说：
“都是我自己写的。”
面试官接着追问：“那你为什么选择这样的夹具作用域？这里为什么需要加一个固定等待？”
如果自己根本没理解代码，这两句就可能问住。
还有人回答：“主要都是 AI 帮我生成的。”
面试官听完可能继续问：“那这个框架里面，你具体负责什么？”
也有人含糊其辞：“就是参考了一下 AI 的建议，自己做了点调整。”
这种回答也存在问题。
参考了什么？调整了什么？为什么调整？
没有具体信息，面试官无法判断你的技术能力。
真正有说服力的回答，不需要刻意强调代码是不是自己逐行敲出来的。
而是把自己在整个研发过程中的贡献解释清楚。
02. 面试官真正想考察的，可能是这 4 件事
为什么面试官要问 AI？
因为随着大模型编程能力越来越强，单纯展示一段运行成功的代码，已经很难充分证明候选人的技术水平。
尤其对于测试开发工程师来说，代码只是实现测试目标的一种手段。
面试官更可能希望判断以下四种能力。
| 考察维度 | 面试官可能继续追问的问题 |
|---|---|
| 需求理解 | 你为什么要测试这些场景？ |
| 技术设计 | 为什么采用这种框架和代码结构？ |
| 结果验证 | AI 生成的代码，你怎么知道它是对的？ |
| 问题处理 | 脚本出了问题，你能独立定位和修改吗？ |
这里有一个非常重要的区别：
代码能够运行，不代表测试设计正确；测试执行通过，也不代表业务质量有保障。
比如，一个 AI 生成的接口测试脚本，每次执行都显示 100% 通过率。
但是它只验证 HTTP 状态码，没有检查返回数据是否满足业务规则。
这种自动化脚本写得再漂亮，能发现多少问题？
再比如，一个自动化框架包含大量封装和设计模式，运行时却高度依赖测试执行顺序。
单独执行某条用例就失败。
这样的框架究竟是工程化设计，还是把复杂性带进了测试系统？
这些问题，才可能是面试官继续追问的重点。
03. 一个比较稳妥的回答方法：分三层讲清楚
面对“代码是你写的还是 AI 写的”，我更推荐采用三层回答法。
第一层：哪些东西是我设计和决定的？
例如：
- 测试需求边界与覆盖范围
- 正常、异常及边界场景的划分
- 用例判定标准与核心断言
- 测试数据和环境隔离策略
- 框架模块划分与工具选型
这些内容可以在 AI 介入之前由工程师制定，也可以借助 AI 讨论，但最终需要工程师做出判断。
第二层：哪些部分由 AI 辅助生成？
例如：
- 常规接口请求代码
- Pytest 参数化样板
- 重复的 Fixture 结构
- 部分测试数据构造代码
- 注释、文档和基础代码重构
这些工作有大量重复性，使用 AI 提高效率，本身没有什么问题。
第三层：哪些代码是经过我验证、修改，最终保留下来的？
这一层最能体现个人能力。
比如 AI 生成了 20 条自动化测试用例，你发现其中 5 条断言过于宽松、3 条依赖不稳定的数据、2 条与当前业务规则不一致。
你最终删除、重写或者补充了这些代码。
如果还能解释为什么做出这些调整，就能让面试官看到你的工程判断过程。
一段可以参考的面试回答
“这个框架确实使用了 AI 辅助开发，但不是让 AI 直接生成后就上线使用。
前期我先确定了接口测试需要覆盖的业务场景、断言规则以及测试数据管理方式。
具体实现时，像参数化、部分 Fixture 和重复的接口请求封装，我借助 AI 提高了开发效率。
但生成代码之后，我会逐项检查业务断言、异常分支、环境依赖和执行稳定性。
其中有几处 AI 生成的逻辑不符合实际业务，我重新设计过。
所以这套框架里面，AI 参与了代码实现，但测试设计、技术取舍和最终验收是由我负责的。”
到这里，还不算结束。
如果面试官继续问：“你具体改过什么？”
一定要拿出实际例子。
04. 三个特别适合准备的技术案例
案例一：AI 写的接口断言，只验证了状态码
假设你要测试一个订单详情查询接口。
AI 生成了以下代码：
response = requests.get(url, headers=headers)
assert response.status_code == 200
这段代码有没有错？
从语法和基本 HTTP 检查来看，没有明显问题。
但是从业务测试角度看，显然不够。
假设接口正常返回 200，但响应体中的订单金额错误，或者返回的是另一个用户的订单信息。
上述测试依然可能通过。
因此你需要继续根据接口契约和业务规则设计断言。
例如：
response = requests.get(url, headers=headers)
assert response.status_code == 200
data = response.json()
assert data["orderId"] == expected_order_id
assert data["amount"] == expected_amount
assert data["status"] in allowed_statuses
这里仅展示简化后的断言思路。实际项目中，还需要校验金额单位和精度、字段类型、订单归属以及错误响应等情况。
面试官可能问：
“为什么 AI 写的断言不够？”
你可以回答：
“因为它只验证了接口的 HTTP 层是否正常响应，没有验证业务结果。接口返回成功不等于返回内容正确。我会根据业务规则补充关键字段和状态转换的断言。”
这种回答比“我优化了一下 AI 代码”具体得多。
案例二：AI 生成固定等待，本地稳定，CI 经常失败
再看 UI 自动化测试。
AI 可能生成：
time.sleep(3)
driver.find_element(
By.ID, "submit"
).click()
本地执行一切正常。
但运行到 CI 环境，偶尔就会报元素找不到。
为什么？
因为固定等待时间无法保证页面元素一定完成加载。
环境负载、网络延迟和页面渲染速度都会影响执行结果。
更合理的方式是针对目标元素使用显式等待：
WebDriverWait(driver, 10).until(
EC.element_to_be_clickable(
(By.ID, "submit")
)
).click()
当然，显式等待也不是万能的。某些业务操作还需要验证异步请求是否完成、页面状态是否真正更新。
这个案例可以展示三种能力：
第一，理解脚本为什么不稳定。
第二，知道如何从固定时间等待改成条件等待。
第三，能够区分产品缺陷和自动化脚本自身的问题。
如果你能补充自己如何结合日志、截图和失败记录定位问题，回答会更完整。
案例三：AI 编造了一个看起来很合理的字段
这是 AI 辅助编写测试脚本时容易被忽略的问题。
假设接口实际返回字段为：
{
"orderId": "A1001",
"payStatus": "SUCCESS"
}
但 AI 依据提示词自行推测，生成：
assert data["paymentStatus"] == "SUCCESS"
paymentStatus 看起来完全符合命名习惯。
但接口根本没有这个字段。
如果工程师直接复制代码，就会遇到运行失败。
更值得警惕的是，当 AI 生成的字段虽然存在，却不符合当前业务语义时，问题可能更隐蔽。
例如，接口文档明确说明退款中的订单状态应该是 REFUNDING，AI 却按照自己的理解断言为 REFUNDED。
这时候，测试代码的语法、结构、执行逻辑可能都没有问题。
真正错误的是测试预期。
因此使用 AI 编写测试代码，不能只看代码能否执行，还需要核对接口契约、业务状态和真实的数据含义。
这也是为什么测试工程师不能把业务判断完全交给 AI。
05. 再加一道进阶题：AI 生成的测试用例全绿，就能上线吗？
面试官可能进一步追问：
“如果你用 AI 生成了一批自动化用例，执行结果全部通过，你怎么证明这些测试有效？”
这个问题已经不再是单纯的代码问题。
而是在考察测试有效性。
你可以从三个角度回答。
第一，检查需求覆盖。
把需求点与测试用例关联起来，查看正常流程、边界条件、异常操作是否覆盖。
尤其注意 AI 容易按照常见业务逻辑生成用例，却遗漏当前产品的特殊规则。
第二，检查断言有效性。
不能只看执行通过率。
可以通过有意构造错误响应、异常数据或受控缺陷，观察测试能否识别问题。
例如把预期金额改错、让订单状态返回错误值，确认相关断言是否真正失败。
第三，检查用例独立性与稳定性。
包括测试数据是否互相污染、执行顺序是否影响结果、测试环境变化是否引入假失败。
比如某个用例执行后修改了账号状态，却没有清理数据，导致下一条用例失败。
这种情况即使不是 AI 导致，也说明自动化测试的工程质量存在问题。
这里可以总结一句：
判断一套自动化测试是否有价值，不只看它能跑通多少用例，还要看真正出现错误时，它能拦住多少问题。
06. 模拟技术面试：连续追问可能会怎么展开？
下面整理一组模拟面试问答，适合准备 AI 测试开发、Python 测试开发和自动化测试相关岗位。
面试官：你这个自动化测试框架，是 AI 写的吗？
参考回答：
“部分代码用了 AI 辅助生成。框架整体设计、业务用例和断言规则是我确定的，AI 主要协助完成重复性编码。生成之后我做了功能验证和代码调整。”
面试官：那为什么公司不直接用 AI，还要招你？
参考回答：
“因为生成代码只解决了实现问题。实际项目还需要有人理解业务需求、识别测试风险、判断测试结果是否可信，以及处理自动化执行中的异常。AI 可以提高编码效率，但不能因为它生成了代码，就默认测试设计是正确的。”
面试官：如果没有 AI，你还能把这套框架写出来吗？
参考回答：
“可以完成核心部分，比如接口请求封装、Pytest 参数化、Fixture 管理和业务断言。不过借助 AI 可以减少重复编码的时间。对于一些不熟悉的库或者实现细节，我也会结合官方文档验证，而不是直接采用生成结果。”
这道题有一个前提：你必须确实能够独立完成核心实现。
否则，面试官很可能让你现场写一段。
面试官：AI 生成了错误代码，你怎么发现的？
参考回答：
“我一般从接口契约、业务预期和实际执行三个层面检查。例如之前遇到过状态码断言不足、字段名与接口定义不一致，以及固定等待导致脚本不稳定等典型问题。需要结合实际项目中自己处理过的例子说明。”
注意，正式面试时应替换成自己的真实经历，不要把示例直接说成亲身做过的项目。
面试官：AI 给了两种实现方案，你怎么选？
参考回答：
“我会看实际使用场景，而不是直接选代码更短的方案。比如涉及异步页面操作，我会更关注执行稳定性；涉及测试数据管理，会考虑用例隔离和维护成本；如果是团队共用的测试框架，还要考虑可读性和后续扩展。”
如果还能讲清楚为什么放弃另一个方案，说明你不只是接受 AI 的输出，而是真的参与了技术决策。
07. 面试前，最好准备一份 AI 辅助开发项目的复盘记录
对于已经把 AI 用到日常工作的测试工程师，我建议面试前不要只准备项目介绍。
最好挑选一段自己最熟悉的脚本或一个测试框架模块，完成下面这张复盘表。
| 准备内容 | 具体要回答什么 |
|---|---|
| 业务目标 | 这段代码解决什么测试问题？ |
| 个人设计 | 需求分析、用例和技术方案是谁决定的？ |
| AI 参与 | 哪些代码由 AI 辅助生成？ |
| 验证过程 | 如何确认生成结果符合需求？ |
| 真实修改 | 哪些生成内容被删除或重写？ |
| 设计取舍 | 为什么采用当前实现方案？ |
| 独立能力 | 不使用 AI 能否实现核心功能？ |
这张表不需要写得很长，但最好能够对应实际代码、提交记录或测试执行证据。
尤其要准备一个自己发现并修复问题的案例。
不要只是说：
“AI 生成的代码不太好，我优化过。”
而应该能够解释：
“原来的实现是什么、为什么存在风险、我怎么验证、最后修改了什么。”
当面试官要求你现场解释某段代码时，你也应该能够说清楚它的输入、执行逻辑、断言依据和可能的失败原因。
这样的准备比背一段标准话术更有效。
另外，面试时展示项目代码，别忘记处理企业内部接口地址、账号信息、密钥和真实业务数据。技术能力展示不能以泄露项目敏感信息为代价。
08. AI 时代，测试工程师的竞争力到底在哪里？
现在有一个值得思考的现象：
过去，测试开发岗位常常把“能不能写自动化脚本”作为重要的能力区分。
但当 AI 可以辅助生成接口请求、参数化代码、Page Object 封装，甚至整套框架的初始结构时，只会写基础脚本，确实越来越难形成明显优势。
这并不意味着编码能力不重要。
恰恰相反。
你越理解代码、测试设计和工程实践，就越能有效利用 AI，并发现它生成结果中的问题。
比如，同样让 AI 为订单系统生成自动化用例：
一个人只关注生成了多少条脚本、执行是否全部通过。
另一个人会继续检查：
- 支付成功但订单状态未更新，有没有覆盖？
- 重复请求是否会造成重复扣款？
- 接口超时后重试，是否可能造成重复创建？
- 不同用户之间是否存在数据越权访问？
- 测试数据是否影响后续用例？
- CI 执行失败时，能否快速定位原因？
两个人可能使用同一个模型，甚至得到结构相似的代码。
但最终的测试质量，完全可能不一样。
AI 可以帮助工程师更快地实现测试方案，但测试方案是否合理、测试结果是否可信，仍然需要专业判断。
这也解释了为什么在技术面试中，单纯强调自己写了多少代码，可能不如解释清楚一个真实的工程问题。
09. 最后：承认用了 AI，不应该成为面试中的心理负担
回到文章开头的问题。
面试官问：
“这段测试代码，到底是你写的还是 AI 写的？”
其实没有必要刻意回避。
如果确实使用了 AI，就承认使用了 AI。
但承认之后，还要说明它参与了哪些工作，以及自己承担了哪些工作。
有三个问题最好提前想清楚：
第一，我为什么这样设计？
第二，我怎么证明它是对的？
第三，出了问题，我能不能自己解决？
如果这三个问题都能回答清楚，那么 AI 辅助开发不仅不一定是减分项，反而能够体现你使用新工具提高研发效率的能力。
反过来，如果一个框架的代码结构解释不清、核心断言不知道为什么这样写、运行失败也只能把报错重新丢给 AI，那么即使代码全部是自己敲出来的，也很难说明具备成熟的测试开发能力。
技术面试不是比谁更能证明自己没有使用 AI。
而是要证明：
你能够独立判断问题、选择方案、验证结果，并对自己交付的测试代码负责。
最后留一个问题给大家：
如果两名测试工程师都能利用 AI 快速搭建一套自动化测试框架，你觉得面试官应该用什么标准，判断谁更值得录用？
欢迎在评论区聊聊你的看法。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
