Playwright Agent 实战教程：让 AI 把测试计划变成能跑的代码

Playwright Agent 官方 Generator 实战演示：拿着测试计划生成能跑的用例，附一份"审生成代码"验收清单，零基础可跟做。
测试计划评审完了，10 个场景还得一行行敲成代码？让 AI 照着计划逐条写，你只负责验收。

一、计划评审完，代码还在一行行敲

测试计划写完——specs/jiucaiquan-condition-order-plan.md

Playwright Agent 实战教程：让 AI 帮你写测试计划

这 10 条场景，还得自己翻译成代码。

本篇讲第二个：Generator。全程你不用手敲用例，只管给上下文、验收产出。

先快速对一下流水线（第 1 篇讲过三个官方 AI 工具）：

• • 🎭 Planner —— 自己逛网站，把"测什么"列成测试计划
• • 🎭 Generator —— 照计划逐条做一遍，写出能跑的代码
• • 🎭 Healer —— 用例挂了自动诊断、修复、重跑

它跟"直接让 AI 写用例"最大的区别，一句话说死：先计划后生成。计划是你审过、签过字的地图，Generator 只负责把地图翻译成路。地图错了才轮到代码错——而不是让 AI 自己猜你要测什么。

系列共 3 篇，每篇独立可读；这是第 2 篇。

二、跟着做完，你能拿到

• • 一条可直接复制的指令，让 Generator 按计划产出 tests/*.spec.ts
• • 一份 「审生成代码」验收清单（4 条）：AI 一秒写 200 行，你得在 10 分钟内判断它有没有自由发挥
• • 配套源码包：seed + 已修好的配置 + 10 场景计划 + 生成出来的 10 条用例 + 验收清单 + FAQ

演示站：jiucaiquan.com（韭菜圈 · A 股条件单工具箱），真实在迭代的中文站，免登录。

三、准备：确认两样东西（1 分钟）

前置：Node.js 18+、VS Code、GitHub Copilot Chat 已登录（怎么装见第 1 篇第 3 节）。

Generator 是流水线的第 2 段，它只认两样输入：

1. 1. seed.spec.ts 已跑绿 —— 它决定"从哪个页面状态出发"
2. 2. specs/jiucaiquan-condition-order-plan.md 在位 —— 它决定"要生成哪些场景"

npx playwright test seed.spec.ts --reporter=list
# ✅ seed passed — jiucaiquan.com 首页就绪

💡 没跟过第 1 篇也能接上：源码包里已经把这两样都备好了，复制进项目即可（README.md 第 2 步）。seed 红着别往下走——起点不对，生成出来的代码全是歪的。

四、关键动作：叫 Generator 干活

四步走：

1. 1. VS Code 打开项目，Copilot Chat 切到 Agent Mode（代理模式）
2. 2. 选代理 @playwright-test-generator
3. 3. 把 seed.spec.ts 和计划文件都加进上下文（少了哪个它都得靠猜）
4. 4. 贴下面这条指令（指令决定产出质量，可直接复制）

请按 specs/jiucaiquan-condition-order-plan.md 生成 Playwright 测试代码。
要求：
1. 以 seed.spec.ts 为起点，沿用它的页面与标题校验；
2. 每个场景一条 test，测试名与计划里的场景标题一致；
3. 只写计划里有的场景，不要自己扩展；
4. 定位优先用 getByRole / getByLabel / getByText，不要用 nth-child、xpath、深层 CSS；
5. 断言用 expect(...).toBeVisible() 这类可重试写法，不要用 waitForTimeout；
6. 生成到 tests/condition-order.spec.ts，生成完自己跑一遍。

指令里第 3、4、5 条是故意写死的：这三条分别对应后面验收清单里最容易出问题的三条。你少写一句，就多半要在审的时候把它打回去重写。

它会自己走完一整轮：读计划 → 打开页面核对真实文案和元素 → 写代码 → 跑一遍。终端节奏长这样（真实以你本机为准）：

[读计划]    ✓ 3 个场景组 / 10 个场景，起始状态取自 seed
[逐条生成]  ✓ 1.1–1.3 → ✓ 2.1–2.5 → ✓ 3.1–3.2
[写文件]    ✓ tests/condition-order.spec.ts（10 条用例，与计划一一对应）
[自跑]      ✓ 10 passed

五、看它交出的代码：审什么（本篇最值钱）

节选 2.2 一条（完整 10 条在源码包 tests/condition-order.spec.ts）：

test('2.2 正常输入并生成次日条件单参考', async ({ page }) => {
  await page.getByLabel('代码').fill('600519');
  await page.getByLabel('名称').fill('贵州茅台');
  await page.getByLabel('开盘价').fill('1700.00');
  await page.getByLabel(/收盘|最新价/).fill('1710.00');
  await page.getByLabel('最高价').fill('1720.00');
  await page.getByLabel('最低价').fill('1690.00');

  const result = page.getByText('次日条件单参考').first();
  await expect(result).toBeVisible();

  // 低吸价 / 高抛价 / 观察价 三行都要有值（非空）
  for (const label of ['低吸价', '高抛价', '观察价']) {
    const row = page.getByText(new RegExp(label)).first();
    await expect(row).toBeVisible();
    await expect(row).not.toHaveText(/^[\s\-—]*$/);
  }

  await expect(page.getByRole('button', { name: '复制条件单文案' })).toBeEnabled();
});

这段有两个细节值得抄进自己项目：

• • 定位全走用户看得见的东西：getByLabel('最高价')、getByRole('button', { name: '复制条件单文案' })，没有一条 nth-child——页面改版时它们大概率还活着
• • 断言校验的是业务结果，不是"点完了"：循环确认低吸价 / 高抛价 / 观察价三行都非空，计划里写的预期结果一条没落

但别急着 commit。 AI 生成的代码最大的风险不是"跑不起来"，而是"跑得起来但没人复核过"。拿下面 4 条过一遍，10 分钟足够：

① 场景齐不齐

计划里 10 个场景，生成的就该有 10 条 test()，不多不少。名称对得上，别自己加戏。

② 选择器稳不稳

getByRole('button', { name: '加入自选' }) 好过 div:nth-child(3) > button。
判断标准只有一句：页面改版时会不会挂。

③ 断言在不在

点了就完事的用例是假用例。每条 test() 至少一个 expect(...)，否则绿了也说明不了任何问题。

④ 有没有硬等

waitForTimeout(2000) 一律打回。改 await expect(...).toBeVisible()——自带轮询重试，机器快慢都稳。

这 4 条建议直接存下来，每次生成新用例都拿出来对一遍。源码包里的 REVIEW.md 是它的可打印版，还附了这次生成被"打回"的真实记录：2.4 用了硬等、3.2 多生成了一个计划里没有的场景。

审完再跑，不算完，跑稳才算：

npx playwright test tests/condition-order.spec.ts --repeat-each=3

一次绿不算绿，连跑 3 次全绿才叫修好。

六、最常见的 4 个坑

坑 1｜它不按计划写，自由发挥。
上下文里必须同时给 seed.spec.ts 和计划文件；指令里加死"只写计划里有的场景"。

坑 2｜生成的选择器全是 nth-child 和 xpath。
指令第 4 条写死"优先 getByRole / getByLabel"；已经生成完了就把那几条贴回对话让它重写。

坑 3｜生成完一条都没跑起来。
先确认文件在 testDir 范围内（本项目 testDir: '.'），再 npx playwright test --list 自检；macOS 12/13 装不上 Chromium 就加 PW_CHANNEL=chrome。

坑 4｜跑完发现多了一条计划里没有的场景。
删掉。计划是你签过字的地图，多出来的场景没人评审过，留着就是负债。

七、3 条心法，照做少踩坑

1. 1. 计划是输入，不是参考 —— 别让 Generator 自由发挥，它该干的只是翻译
2. 2. 生成完必对着计划逐条打勾 —— AI 最容易的两件事就是漏场景和加戏
3. 3. 一次绿不算绿 —— --repeat-each=3 是成本最低的防偶发红手段

八、新手最常问的 3 个问题

Q1：它会不会改我的计划文件？
不会，它只读。但要确认计划文件真的加进了上下文——没加，它就只能靠猜页面。

Q2：生成完还要人工改吗？这不就白自动化了？
要，但改的是判断，不是敲键盘。它一分钟写 200 行，你花 10 分钟审：省下的是打字时间，留下的是"哪些场景值得测""这样断言对不对"。

Q3：能生成 API 测试或别的语言的用例吗？
官方围绕 TypeScript（@playwright/test）支持得最完整。但"计划 → 生成"这套思路不绑语言，先用 TS 工程把流程跑通验证价值。

选择器不稳、出现硬等、生成的文件跑不起来——更多问题见源码包里的 FAQ.md（开头有 30 秒踩坑速查）。

九、小结 & 下一篇

• • Generator = 读计划 + 核对页面 + 写代码，把"测什么"变成"能跑"
• • 你的角色：给足上下文 + 审产出——4 条验收清单，10 分钟过一遍
• • 下一篇：Healer 跑测试、诊故障、改代码、重跑 —— 用例挂了让 AI 自己修

评论区聊聊：你更怕 AI 生成代码"漏场景"，还是"自己加戏"？ 我会逐条回。