最近有同学问我一个问题： “现在越来越多公司的校招测开岗开始关注 AI 使用能力，我需要准备到什么程度？”
先说一个更现实的结论：
AI 使用能力正在成为加分项，但还远没到“不会就没机会”的程度。
企业更看重的，依然是你对测试的理解，以及把事情做成的能力。
这篇文章不讲概念，我把自己最近一套跑通的流程分享出来：
用 AI 辅助写自动化测试，从能生成代码，到能稳定跑起来，中间到底经历了什么。
为什么是 Playwright + Claude Code
不是因为它们“最先进”，而是更适合当前阶段的实践。
Playwright的特点是接口设计比较语义化，比如点击、输入、等待这些操作本身就比较直观，这对 AI 生成代码是有帮助的。
而Claude Code的优势在于，它不仅依赖 prompt，还可以读取项目中的代码结构。这一点很关键—— 相比只基于描述生成代码，有上下文的生成更接近真实项目。
不过需要注意： 它并不能“完全理解你的业务”，关键约束仍然需要你补充。
第一步：先让 AI 理解你的项目（很多人会忽略）
一开始我直接让 AI 写脚本，结果基本不可用。 后来补了一步：在项目里加一个说明文件，让 AI 知道基本约束。
比如在根目录放一个 CLAUDE.md，写清楚：
## 项目信息 - 前端：React + TypeScript - 测试框架：Playwright - 测试目录：tests/e2e/ - Base URL：http://localhost:3000 ## 测试规范 - 使用 Page Object 模式 - 优先使用>第二步：把测试场景说清楚，而不是让 AI 猜一个常见问题是，描述太模糊，比如：
“写一个登录测试”
这种输入，AI 只能生成“看起来像测试”的代码，但很难直接用。
如果换成这样：
- 访问登录页
- 输入用户名和密码
- 点击登录
- 校验跳转结果
- 再补充异常情况（密码错误、空提交）
你会发现生成结果明显更可用。
本质上，这一步不是在“写 prompt”， 而是在做测试用例设计。
第三步：代码生成之后，一定要做 Review
AI 可以帮你写初稿，但质量控制还是要靠人。
我自己主要会看这几块：
选择器是否稳定
AI 常用 class 或 id，但这些容易随样式变化失效。
更推荐>第四步：运行和调试（这是必经过程）
第一次执行失败是正常的。
常见问题包括：
- 选择器不匹配
- 页面未加载完成就开始操作
- 测试数据不符合预期
一个比较实用的做法是： 把报错信息交给 Claude Code，让它一起参与修改。
通常几轮下来，可以把用例稳定下来。
第五步：接入 CI，让测试真正有价值
当脚本可以稳定运行后，可以考虑接入 CI 流程，例如：
e2e-tests: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - run: npm ci - run: npx playwright install --with-deps - run: npx playwright test
需要说明的是：
CI 中的测试不一定“永远稳定”，
实际项目中会存在波动（flaky test），目标是逐步提高稳定性，而不是追求绝对 100%。
三个常见问题（踩坑总结）
1. 选择器过于脆弱
使用 class 或 id 容易受页面改动影响，建议统一规范。
2. 测试之间有依赖
应保证每个测试可以独立执行，通过 beforeEach 处理前置条件。
3. 忽略加载时序
操作前应确认关键元素已渲染完成，否则在 CI 环境容易失败。
效率上的变化（更客观的说法）
以常见场景为例：
- 登录测试：从数小时缩短到几十分钟
- 完整页面 E2E：从 1~2 天缩短到数小时
整体来看，在结构清晰的场景下，效率通常可以提升 2~3 倍。
但需要强调：
AI 并不会减少你的判断工作，只是减少了重复编码的时间。
对校招生更重要的一点
企业关注的，不只是你“用了 AI”，而是你是否理解：
- 测试场景如何设计
- 为什么这么设计
- AI 在哪里帮助了你
- 哪些地方需要人工介入
如果你能把这些讲清楚，比单纯展示工具更有价值。
最后
AI 确实在改变自动化测试的方式，但它更像一个加速器，而不是替代者。
更合理的分工是：
- 人负责设计与判断
- AI 负责提高实现效率
如果你还没开始尝试，可以从一个简单场景入手，比如登录流程，完整跑一遍“生成—调试—稳定”的过程。
这比单纯看教程，更能建立你的真实能力。
霍格沃兹测试开发学社，是一个专注软件测试、自动化测试、人工智能测试与测试开发的技术交流社区
