面了一个女生,她对AI工具的使用理解简直无敌

“

想发 offer不是因为她会用多少工具，而是她清楚地知道：AI 该嵌在哪里、不该嵌在哪里

你大概率也在用 AI，但你可能用错了层级。

📌 本文看点

我面过不少同学，简历上写「熟练使用 ChatGPT / 通义 / 豆包 辅助测试」。聊下去发现，大多数人的用法高度一致：把需求贴进去，让它出用例；把报错贴进去，让它改代码。

这当然比纯手写快。但那位女生的回答让我意识到，她和大多数人的差距，不在工具数量，在使用心智——也就是把 AI 放在工作流的哪一层。

先看四层分别是什么，再对照你自己落在哪一层。

L1 代写层：把 AI 当「代写机」

这是最常见的用法。输入：「帮我写这份需求的测试用例。」动作：复制粘贴，挑能跑的用。

问题：AI 不知道你的业务坑、历史缺陷、线上事故。它产出的用例像培训教材——四平八稳、覆盖主流程，却漏掉你这个项目真正会出事的边界。你以为覆盖率上来了，其实补的是最不重要的地方。

L2 助手层：把报错丢给 AI

进步了一档：遇到失败，把堆栈和日志贴给 AI 问「为什么报错」。

进步：开始让 AI 参与诊断，不再是纯代写。上限：仍是被动问答——你抛一个问题，它回一个答案。你没教它你的判定标准，它也不懂你这次要的是「先止血」还是「查根因」。

L3 协作者层：给上下文 + 约束 + 判定标准

这是她让我眼前一亮的一层，也是初中级完全可以练到的层。关键动作不是「问 AI」，而是先喂框架，再要中间产物。

你给 AI：需求背景 + 你已知的业务约束 + 一份明确的「产出格式要求」。AI 产出：不是最终用例，而是可评审的中间物——比如「测试点清单」「风险列表」「异常分支」。你拍板：哪些采纳、哪些补全、哪些砍掉，再让 AI 基于你确认过的内容展开。

L4 系统层：嵌进工作流，清楚边界

她的水准落在这层。不是因为她会某个神秘技巧，而是她把 L3 的协作方式固化成了每天的工作流，并且非常清楚 AI 的边界。

落到 L4 的人，工作流长这样：需求进来 → AI 出测试点清单 → 人审、补全业务坑 → AI 展开用例 → AI 当红队审盲点 → 执行发现失败 → AI 给根因排序 → 人定「该不该提 bug、优先级多高」→ 反馈给 AI 进入下一轮。

注意最后一步是人定，不是 AI 定。这就是边界。

不用等升职、不用换工具。下面 5 个动作，明天上班就能用，且都在L3 层级。

1. 需求 → 测试点，而不是需求 → 用例

把 PRD 或需求文档贴给 AI，但先别让它写用例。命令它：

你拿到清单后，补全只有你才知道的业务坑（比如「这个字段历史上被刷过单」），拍板确认，再让 AI 基于确认后的清单展开用例。这样用例里带着你的判断，而不是培训教材。

2. 让 AI 当「红队」审你的用例

写完用例，别急着执行。把用例贴回去，命令它：

你得到的是一份盲点清单。初中级最该补的，往往就在这 5 类里。

3. 失败分析要「根因排序」，不要「答案」

下次遇到报错，别只问「怎么修」。这样问：

你要的是「排查顺序」和「为什么」，不是一行修好的代码。这样你在学，不只是修。

4. 自动化脚本：你定验收，AI 写实现

让 AI 写 Playwright / pytest 脚本时，必须给它「验收标准」和「边界」，否则它只会写 happy path。

「断言明确」这一句很关键——只断言元素存在，等于没测。这个要求得你来提。

5. 异常数据构造：最被低估的一招

这是初中级最容易忽略、AI 又最擅长的事。让 AI 造「边界值 + 异常格式」的测试数据：

正常数据你手都能造；这些异常数据才是 bug 的温床，让 AI 批量产出，你只管喂进系统看反应。

聊到最后，我确认了一件事：她用的工具，不比任何人多。她的无敌来自两点。

第一，清楚 AI 的边界。这几件事，她从不让 AI 替她做：该不该提这个 bug（业务影响要人判断）；优先级排第几（牵扯排期和资源，得人定）；风险到底有多大（要对上下文负责）。

第二，建立闭环。她不是「问一次拿到答案就走」，而是 AI 产出 → 人审 → 人拍板 → 反馈给 AI → 下一轮。每一轮，AI 都更贴近她项目的真实情况。

不需要宏大的计划，先改三个习惯：

做完这三件，你就已经从 L1 爬到了 L3。剩下的，是把它变成每天的习惯。

AI 不会取代测试工程师。但会用 AI 的测试工程师，一定会在晋升和效率上，拉开和「只会让 AI 代写」的人的距离。

你差的从来不是工具，是用法。