AI+Playwright：构建意图驱动的智能自动化测试框架

1. 项目概述：当AI遇见Playwright，测试的范式革命

最近在团队里推动自动化测试，发现一个挺有意思的现象：测试脚本的维护成本，尤其是应对UI频繁变更的“脆弱性”，几乎成了所有自动化工程师的噩梦。一个按钮的>await page.click(‘#login-button’); await expect(page.locator(‘.welcome-msg’)).toHaveText(‘Welcome, User!’);

而是可以这样描述（通过注释、配置文件或专门的DSL）： “登录成功后，页面应显示欢迎信息，包含用户名。” 甚至更复杂：“在商品列表页，筛选价格在100-500元之间的商品，然后按销量排序，检查第一个商品的标题是否包含‘热卖’标签。”

AI（这里通常是一个经过微调或通过Prompt工程调优的大语言模型，如GPT-4、Claude或开源的Code Llama）的任务，就是将这些自然语言描述，结合当前页面的上下文（如HTML结构、屏幕截图），理解用户的“意图”，并将其转化为一系列可执行的、基于Playwright的操作指令和断言。

2.2 上下文感知层：Playwright提供“眼睛”和“手脚”

AI需要“看”页面才能理解。Playwright在这里扮演了无可替代的角色：

1. 页面快照：提供当前页面的完整HTML DOM树。这是AI理解页面结构的“源代码”。
2. 视觉截图：提供页面或特定区域的截图。对于纯HTML分析难以处理的复杂CSS渲染、Canvas图表或验证码，视觉信息至关重要。
3. 元数据：提供页面URL、标题、浏览器视口大小等信息，作为辅助上下文。
4. 执行引擎：AI规划出的操作步骤（点击、输入、滚动等），最终由Playwright来可靠地执行。Playwright的自动等待、网络拦截、多页面控制等高级特性，确保了执行的稳定性和覆盖率。

这个层是AI与真实浏览器环境交互的桥梁。没有Playwright稳定、全面的环境操控能力，AI的规划只能是纸上谈兵。

2.3 决策与生成层：AI作为“测试策略大脑”

这是最核心的一层。AI接收到“意图”和“页面上下文”后，需要完成以下决策：

• 元素定位：不再依赖固定的CSS选择器或XPath。AI可以分析DOM和截图，综合运用语义信息（如<button>登录</button>）、邻近文本、视觉位置、ARIA属性等多种方式，动态生成最鲁棒的元素定位策略。即使id变了，只要按钮的文字还是“登录”，AI就能找到它。
• 操作序列生成：将复杂的意图拆解成线性的、可执行的操作步骤。例如，“填写登录表单”可能被拆解为“定位用户名输入框”、“输入文本‘test’”、“定位密码输入框”、“输入文本‘123456’”、“定位登录按钮并点击”。
• 断言点识别与生成：判断测试是否通过，需要检查哪些关键点。AI需要根据意图，决定在哪些位置进行何种断言（文本内容、元素存在、属性值、视觉差异等），并生成相应的Playwright断言代码。

2.4 自愈与适应层：让测试脚本“活”起来

这是项目的终极价值所在。当测试执行失败时，传统脚本就停止了，需要人工介入排查是Bug还是脚本问题。而AI加持的系统可以尝试“自愈”：

1. 失败分析：AI分析失败截图和错误信息，判断是应用Bug（如页面报错）、环境问题（如网络超时）还是脚本定位问题（如元素找不到）。
2. 策略调整：如果是定位问题，AI可以尝试重新分析当前页面，生成新的定位策略，并重试失败的操作步骤。
3. 用例进化：将成功的定位策略和操作序列反馈学习，用于优化后续同类意图的识别，形成正向循环。

这个四层架构，共同构成了一个从“意图”到“验证”的闭环智能测试系统。它的优势在于将测试工程师从繁琐、脆弱的元素定位维护中解放出来，更专注于设计测试场景和业务逻辑本身。

3. 关键技术选型与工具链搭建

明确了架构，下一步就是选择合适的技术栈来落地。这里没有银弹，需要根据团队的技术背景、预算和对AI能力的依赖程度进行权衡。

3.1 Playwright：为什么是它，而不是Selenium或Cypress？

在浏览器自动化框架中，Playwright是我最终的选择，原因在于它为解决“脆弱性”问题提供了更好的基础设施：

• 强大的选择器引擎：Playwright支持文本选择器（text=）、角色选择器（role=）等，这些本身就比纯粹的CSS选择器更具语义性和鲁棒性。这为AI生成定位策略提供了更多、更可靠的选项。
• 自动等待机制：内置的自动等待网络空闲、元素可交互等，减少了因时序问题导致的Flaky Tests（不稳定的测试），让AI生成的步骤执行起来更稳定。
• 多浏览器、多上下文支持：一套脚本可在Chromium、Firefox、WebKit上运行，轻松模拟移动端视图，为AI测试提供了更丰富的上下文场景。
• 出色的调试与追踪能力：playwright trace可以录制完整的测试执行过程，包括DOM快照、网络请求、截图等。当AI测试失败时，这份详细的追踪记录是进行失败分析的宝贵资料。

实操心得：在初期搭建时，建议直接从Playwright的官方TypeScript/JavaScript SDK入手。它的API设计现代，文档清晰，社区活跃。Python版本虽然也不错，但在与一些前沿的AI工具链（如结合Cursor AI）集成时，TS/JS生态有时会更顺畅。

3.2 AI模型选择：云端大模型 vs. 本地轻量模型

这是成本、速度和隐私的权衡。

• 方案一：云端大模型API（如OpenAI GPT-4o， Anthropic Claude）

  • 优点：能力强大，在代码生成、逻辑推理、上下文理解方面表现卓越。几乎无需训练，通过精心设计的Prompt（提示词）就能获得很好的效果。适合快速原型验证和中小规模应用。
  • 缺点：有API调用成本，存在数据出境隐私风险（需谨慎处理页面HTML等敏感数据），网络延迟可能影响测试速度。
  • 关键技术：Prompt Engineering。你需要设计一套高效的“系统提示词”，来定义AI的角色（“你是一个专业的测试自动化工程师”）、任务（“将自然语言测试用例转化为Playwright代码”）、输出格式（“必须输出可执行的Playwright代码片段”）以及安全规范。

• 方案二：本地部署模型（如Code Llama, DeepSeek-Coder）

  • 优点：数据完全私有，无网络延迟，长期成本可能更低。适合对数据安全要求极高、测试规模巨大的企业级场景。
  • 缺点：需要一定的MLOps基础设施，模型能力可能略逊于顶级云端模型，需要更多的微调（Fine-tuning）工作才能达到理想效果。
  • 关键技术：模型微调。你需要收集一批“自然语言意图”和对应的“Playwright代码”配对数据，对基础代码模型进行微调，让它专门擅长这个转换任务。

• 方案三：视觉理解模型（如CLIP， Grounding DINO）

  • 特殊用途：当页面元素无法通过HTML语义有效定位时（如图标、图形按钮、Canvas绘制的图表），就需要专门的视觉模型。它可以分析屏幕截图，识别出“那个红色的购物车图标”或“折线图上最高点的数值”。
  • 通常用法：作为大语言模型的补充工具。LLM负责逻辑规划和代码生成，当它需要定位一个视觉元素时，可以调用视觉模型API来获取该元素在截图中的坐标，再通过Playwright的page.click(x, y)或结合坐标与DOM进行二次定位。

注意事项：起步阶段，我强烈推荐从方案一（GPT-4 API）开始。用最小的成本验证整个流程的可行性。隐私问题可以通过对HTML内容进行脱敏（如移除id,class的具体值，只保留标签和文本）来缓解。等整个智能测试的Pipeline跑通后，再根据实际需求和痛点，考虑引入视觉模型或迁移到本地模型。

3.3 集成开发环境：Cursor + Playwright CLI

工欲善其事，必先利其器。在开发AI驱动的测试脚本时，传统的IDE显得有些笨重。我目前的主力工具链是Cursor编辑器配合Playwright CLI。

• Cursor编辑器：它内置了强大的AI编程助手（基于GPT-4）。你可以在编辑器里直接用自然语言描述一个测试场景，比如“帮我在这个Playwright测试文件里，添加一个用AI定位‘忘记密码’链接并点击的步骤”，Cursor能理解上下文，生成高质量的代码片段。这本身就是在实践“意图驱动开发”。
• Playwright CLI：这是管理测试项目的瑞士军刀。playwright test运行测试，playwright codegen可以启动一个录制工具，虽然我们不完全依赖它，但在为AI收集“意图-代码”配对数据时，它是一个快速生成基础脚本的好帮手。playwright show-trace则是分析AI测试失败原因的利器。

这套组合能极大提升开发智能测试脚本的效率，让你更聚焦于测试逻辑本身，而非语法细节。

4. 实战：构建一个智能登录测试用例

让我们从一个最常见的场景开始：测试一个Web应用的登录功能。我们将构建一个脚本，它不仅能用传统方式登录，还能在页面UI发生变化时，尝试自我调整。

4.1 基础环境搭建与项目初始化

首先，确保你的环境已经就绪：

# 1. 初始化一个新的Node.js项目（如果你还没有） mkdir ai-playwright-test && cd ai-playwright-test npm init -y # 2. 安装Playwright及相关测试运行器 npm install @playwright/test # 3. 安装Playwright支持的浏览器（Chromium, Firefox, WebKit） npx playwright install # 4. 安装OpenAI官方Node.js SDK（用于调用GPT API） npm install openai # 5. 初始化Playwright配置文件，这个命令会创建 playwright.config.ts 和 tests/ 目录 npx playwright init

接下来，配置你的Playwright配置文件playwright.config.ts。为了配合AI测试，我建议做如下调整：

import { defineConfig, devices } from ‘@playwright/test’; export default defineConfig({ testDir: ‘./tests’, fullyParallel: true, // 支持并行测试，AI测试可能较慢，并行化很重要 forbidOnly: !!process.env.CI, // 在CI环境中禁止使用 test.only retries: process.env.CI ? 2 : 1, // 失败重试次数，给AI自愈留出机会 workers: process.env.CI ? 4 : ‘50%’, // 工作进程数 reporter: ‘html’, // 使用HTML报告，更直观 use: { baseURL: ‘https://your-test-app.com’, // 设置基础URL trace: ‘on-first-retry’, // 仅在第一次重试时记录追踪，平衡性能和调试需求 screenshot: ‘only-on-failure’, // 仅在失败时截图，供AI分析 video: ‘retain-on-failure’, // 仅在失败时保留录像 }, projects: [ { name: ‘chromium’, use: { ...devices[‘Desktop Chrome’] }, }, // 可以添加更多浏览器项目 ], });

4.2 实现AI指令生成器核心模块

这是整个系统的大脑。我们创建一个ai-orchestrator.ts模块，它负责与GPT API通信，将测试意图和页面上下文转化为Playwright指令。

// utils/ai-orchestrator.ts import OpenAI from ‘openai’; import { Page } from ‘@playwright/test’; export class AIOrchestrator { private openai: OpenAI; private model: string; constructor(apiKey: string, model: string = ‘gpt-4o’) { this.openai = new OpenAI({ apiKey }); this.model = model; } async generatePlaywrightActions( page: Page, userIntent: string ): Promise<{ actions: string; reasoning: string }> { // 1. 从Playwright获取页面上下文 const htmlContent = await page.content(); // 对HTML进行简化脱敏，移除可能的敏感信息，同时保留结构 const simplifiedHtml = this.sanitizeHtml(htmlContent); const screenshotBuffer = await page.screenshot({ fullPage: false }); // 截取可视区域 const screenshotBase64 = screenshotBuffer.toString(‘base64’); // 2. 构建给AI的Prompt（系统指令） const systemPrompt = `你是一个资深的Web自动化测试工程师，精通Playwright。你的任务是将用户的自然语言测试意图，转化为可执行的Playwright代码。 规则： 1. 你只能输出Playwright代码，代码必须符合Playwright的API规范。 2. 代码应该使用‘page’这个变量，它已经代表当前的页面对象。 3. 优先使用语义化的定位器，如 \`page.getByRole(‘button’, { name: ‘登录’ })\`， \`page.getByText(‘提交’)\`。 4. 如果语义定位器不奏效，再考虑使用CSS选择器，但尽量选择稳定的属性，如 \`data-testid\`。 5. 在操作后，添加合理的等待，例如 \`await page.waitForLoadState(‘networkidle’)\`。 6. 包含必要的断言来验证结果。 7. 你的输出格式必须是：\`\`\`javascript\n[你的代码]\n\`\`\` 当前页面HTML结构（已简化）: ${simplizedHtml} `; // 3. 构建用户消息 const userMessage = `用户意图：${userIntent} 请根据以上页面信息，生成实现该意图的Playwright代码。`; // 4. 调用OpenAI API try { const response = await this.openai.chat.completions.create({ model: this.model, messages: [ { role: ‘system’, content: systemPrompt }, { role: ‘user’, content: userMessage }, // 可以附加图片信息，如果模型支持视觉输入（如gpt-4o） // { // role: ‘user’, // content: [ // { type: ‘text’, text: userMessage }, // { type: ‘image_url’, image_url: { url: `data:image/png;base64,${screenshotBase64}` } }, // ], // }, ], temperature: 0.1, // 低温度，让输出更确定、更符合代码规范 max_tokens: 1500, }); const aiResponse = response.choices[0]?.message?.content || ‘’; // 5. 从AI响应中提取代码块 const codeMatch = aiResponse.match(/```(?:javascript|js)?\n([\s\S]*?)```/); const generatedCode = codeMatch ? codeMatch[1].trim() : aiResponse.trim(); const reasoning = aiResponse.replace(/```[\s\S]*?```/g, ‘’).trim(); // 提取AI的推理过程（如果有） return { actions: generatedCode, reasoning }; } catch (error) { console.error(‘AI指令生成失败:’, error); throw new Error(`AI指令生成失败: ${error.message}`); } } private sanitizeHtml(html: string): string { // 简单的脱敏函数，移除或混淆潜在的敏感属性 return html .replace(/id="[^"]*"/g, ‘id=“removed”’) // 移除所有id具体值 .replace(/class="[^"]*"/g, ‘class=“removed”’) // 移除所有class具体值 .replace(/name="[^"]*"/g, ‘name=“removed”’) .replace(/<script[\s\S]*?>[\s\S]*?<\/script>/gi, ‘’); // 移除脚本内容 } }

关键点解析：

1. 上下文提供：我们将简化后的HTML和可选截图传给AI，这是AI“理解”页面的基础。截图对于GPT-4o这类多模态模型尤其有用。
2. Prompt工程：systemPrompt至关重要。它定义了AI的角色、任务、规则和输出格式。明确的规则能极大提高生成代码的质量和安全性。
3. 输出解析：AI可能会在代码块外附加解释。我们使用正则表达式精准提取 ````javascript` 块内的代码。
4. 温度（Temperature）：设置为0.1，让AI的输出更确定、更可重复，这对于生成稳定的测试代码很重要。

4.3 编写智能登录测试脚本

现在，我们利用上面的AIOrchestrator来编写一个真正的测试用例。

// tests/ai-login.spec.ts import { test, expect, Page } from ‘@playwright/test’; import { AIOrchestrator } from ‘../utils/ai-orchestrator’; // 从环境变量读取OpenAI API Key，确保安全 const apiKey = process.env.OPENAI_API_KEY; if (!apiKey) { throw new Error(‘请设置 OPENAI_API_KEY 环境变量’); } const aiOrchestrator = new AIOrchestrator(apiKey); test.describe(‘AI驱动的智能登录测试’, () => { let page: Page; test.beforeEach(async ({ browser }) => { page = await browser.newPage(); await page.goto(‘/login’); // 使用配置中的baseURL }); test.afterEach(async () => { await page.close(); }); test(‘成功登录并跳转到仪表盘’, async () => { // 第一步：让AI生成登录操作的代码 const loginIntent = ‘在登录页面，找到用户名输入框并输入“testuser”，找到密码输入框并输入“password123”，然后找到登录按钮并点击。登录成功后，等待页面导航完成，并验证当前页面URL包含“dashboard”字样，且页面上存在一个包含用户邮箱“testuser@example.com”的元素。’; const { actions: generatedCode, reasoning } = await aiOrchestrator.generatePlaywrightActions(page, loginIntent); console.log(‘AI推理过程:’, reasoning); // 可选，用于调试 console.log(‘生成的代码:’, generatedCode); // 第二步：动态执行AI生成的代码 // 注意：这里使用 eval 需要极其谨慎，仅用于演示。生产环境应使用更安全的方式，如沙箱或代码解析。 try { // 创建一个安全的执行环境，将 page 和 expect 注入 const executeCode = new Function(‘page’, ‘expect’, generatedCode); await executeCode(page, expect); } catch (executionError) { // 如果执行出错，可能是AI生成的代码有误，或者页面已发生变化 console.error(‘执行AI生成的代码失败:’, executionError); // 这里可以触发“自愈”流程，例如：重新分析页面、尝试备用方案、或标记为需要人工审查 await page.screenshot({ path: ‘error-screenshot.png’ }); throw executionError; // 最终仍抛出错误，让测试失败 } // 第三步：额外的、更复杂的断言可以由AI继续生成，或者手动添加 // 例如，让AI检查仪表盘上的某个特定组件 const dashboardCheckIntent = ‘在当前页面（应该是仪表盘），检查是否存在一个显示“欢迎回来”的标题元素，并且找到一个“退出登录”的链接或按钮。’; const { actions: checkCode } = await aiOrchestrator.generatePlaywrightActions(page, dashboardCheckIntent); const executeCheck = new Function(‘page’, ‘expect’, checkCode); await executeCheck(page, expect); }); test(‘登录失败显示错误信息’, async () => { // 测试负面场景 const failIntent = ‘在登录页面，用户名输入“wrong”，密码输入“wrong”，点击登录按钮。然后验证页面上出现了一个包含“用户名或密码错误”文本的错误提示信息区域。’; const { actions: generatedCode } = await aiOrchestrator.generatePlaywrightActions(page, failIntent); const executeCode = new Function(‘page’, ‘expect’, generatedCode); await executeCode(page, expect); // 我们还可以断言登录按钮是否恢复可点击状态等 const loginButton = page.getByRole(‘button’, { name: ‘登录’ }); await expect(loginButton).toBeEnabled(); }); });

4.4 实现初步的“自愈”机制

上面的测试在AI生成代码失败时就结束了。一个更智能的系统应该能尝试自我修复。我们可以在AIOrchestrator中增加一个retryWithHealing方法。

// 在 AIOrchestrator 类中添加 async retryWithHealing( page: Page, originalIntent: string, failedAction: string, // 失败的具体操作描述，可从错误信息中提取 error: Error ): Promise<{ actions: string; healed: boolean }> { console.log(`检测到失败，尝试自愈。失败操作: ${failedAction}`); // 1. 获取失败后的最新页面状态 const currentHtml = await page.content(); const simplifiedHtml = this.sanitizeHtml(currentHtml); const screenshotBase64 = (await page.screenshot()).toString(‘base64’); // 2. 构建一个专注于修复的Prompt const healingPrompt = `之前的操作失败了，错误信息是：“${error.message}”。 用户原本的意图是：“${originalIntent}”，但在执行“${failedAction}”时出错。 这是当前页面的最新状态（HTML和截图）。请分析： 1. 页面是否已经发生了变化？目标元素是否还在？它可能变成了什么样子？ 2. 请重新生成**仅针对失败步骤**的Playwright代码，使用更鲁棒的定位策略。 3. 如果原目标确实不存在，请判断是否出现了错误页面或弹窗，并生成相应的处理代码（如关闭弹窗、点击返回等）。 输出格式同上。`; // 3. 调用AI获取修复方案 const { actions: healedCode } = await this.generatePlaywrightActionsInternal( page, healingPrompt, simplifiedHtml, screenshotBase64 ); // 4. 执行修复代码 try { const executeHealedCode = new Function(‘page’, ‘expect’, healedCode); await executeHealedCode(page, expect as any); // 注意类型安全 console.log(‘自愈成功！’); return { actions: healedCode, healed: true }; } catch (healingError) { console.error(‘自愈尝试也失败了:’, healingError); return { actions: ‘’, healed: false }; } } // 修改测试用例，加入重试逻辑 test(‘智能登录测试（带自愈）’, async ({ page }) => { const loginIntent = ‘...’; // 同上 const maxRetries = 2; let lastError: Error; for (let attempt = 0; attempt <= maxRetries; attempt++) { try { if (attempt === 0) { // 首次尝试 const { actions } = await aiOrchestrator.generatePlaywrightActions(page, loginIntent); const executeCode = new Function(‘page’, ‘expect’, actions); await executeCode(page, expect); } else { // 重试并自愈 const { healed } = await aiOrchestrator.retryWithHealing( page, loginIntent, `第${attempt}次尝试执行登录序列`, lastError! ); if (!healed) break; // 自愈失败，跳出循环 } // 如果成功，跳出循环 break; } catch (error) { lastError = error as Error; if (attempt === maxRetries) { // 最终还是失败了 throw error; } console.log(`第${attempt + 1}次尝试失败，准备重试...`); await page.waitForTimeout(1000); // 等待一秒再重试 } } });

5. 高级应用与场景扩展

基础的单步指令生成和自愈只是开始。结合Playwright的强大功能和AI的灵活性，我们可以实现更复杂的测试场景。

5.1 视觉回归测试的智能化

传统的视觉回归测试（如用pixelmatch对比截图）非常脆弱，任何无关的UI变动（如日期变化）都会导致失败。AI可以理解“哪些变化是重要的”。

• 思路：测试通过后，将关键区域（如购物车图标、主按钮）的截图和其语义描述（“页面右上角的购物车图标”）存入基准库。下次测试时，AI先根据描述定位到该区域，再截取当前状态的图片，最后调用视觉差异算法进行比较。AI可以忽略一些无关的像素级抖动。
• 实现：可以集成jest-image-snapshot或playwright-visual-comparison等库，但由AI来决定比较的区域和容忍阈值。

5.2 探索性测试与异常流测试

让AI像好奇的用户一样探索应用。

• 思路：给AI一个起始URL和宽泛的目标，如“探索这个电商网站，尝试找到并购买一个价格低于50元的商品，但不要真正完成支付”。AI需要自己规划路径：浏览分类、使用筛选器、查看商品详情、加入购物车、进入结算流程等。
• 挑战与技巧：这需要更强大的AI规划和状态管理能力。可以将其分解为多个子目标，并为AI定义一套安全操作规则（例如，“永远不要输入真实的支付信息”，“如果遇到弹窗，先尝试关闭”）。Playwright的page.on(‘dialog’)事件监听器可以很好地处理各种浏览器弹窗。

5.3 将AI测试集成到CI/CD流水线

智能测试最终要服务于持续交付。

• 策略：
  1. 分层测试：将AI测试放在流水线靠后的阶段（如集成测试阶段），因为其执行时间相对较长。核心的单元测试和API测试应先行。
  2. 稳定性处理：设置合理的重试次数和超时时间。利用Playwright的retries配置和我们的自愈逻辑。
  3. 结果分析：不仅看通过/失败，更要收集AI的“推理过程”（reasoning字段）和失败时的追踪文件（trace）。这些是分析“脆片性”根源和改进AI Prompt的宝贵数据。
  4. 资源管理：AI API调用有成本。可以在流水线中缓存成功的测试步骤对应的代码，下次相同意图和相似页面结构时直接使用缓存，而非每次都调用AI。

6. 避坑指南与性能优化

在实际项目中踩过不少坑，这里总结几个关键点：

1. 成本控制：

   • Token消耗：每次调用AI都会消耗Token。HTML内容可能很长。务必对HTML进行压缩和脱敏。移除所有注释、脚本内容、样式表，只保留主干标签和关键文本。可以将HTML长度控制在2000-3000个字符以内。
   • 缓存策略：为“意图+页面URL+页面内容哈希”建立缓存。如果页面结构未变，相同的意图可以直接使用上次生成的代码，无需调用AI。
   • 异步批处理：在CI/CD中，可以将多个测试用例的AI生成请求批量发送，有些API支持批量处理，能节省开销。

2. 稳定性与超时：

   • AI API调用可能网络超时。必须设置合理的超时和重试机制（如使用axios或openaiSDK的配置）。
   • Playwright操作本身也要设置超时，避免因AI生成错误代码导致测试无限期挂起。

3. 安全与隐私：

   • 绝不将未脱敏的、包含真实用户数据或内部信息的HTML发送给第三方AI服务。脱敏函数（如上面的sanitizeHtml）是必须的。
   • 考虑使用企业的私有化部署模型或通过API网关进行额外的数据过滤。

4. 提示词（Prompt）优化：

   • 这是影响效果最直接的因素。需要不断迭代你的systemPrompt。加入更多正面和反面的例子（Few-shot Learning）。
   • 明确禁止AI做什么，比如“不要使用基于绝对位置的XPath”，“不要操作文件上传输入框（除非意图明确指定）”。
   • 让AI在输出代码时，也输出它选择某个定位器的理由，这有助于你调试和改进Prompt。

5. 不要完全取代传统测试：

   • AI测试是强大的补充，但不是银弹。核心的业务逻辑、计算正确的断言，仍然需要由工程师精心设计的传统测试来保障。
   • 最佳实践是混合模式：关键路径（Happy Path）用稳定、快速的传统Playwright脚本。UI频繁变更的模块、探索性测试、异常流测试，则交给AI驱动。两者在测试报告中相互补充。

将AI引入自动化测试，最大的收获不是写更少的代码，而是构建了一种更具弹性和适应性的测试体系。它迫使我们去思考测试的“意图”而非“实现”，这本身就是一种进步。当然，这条路还很长，Prompt的打磨、成本的控制、自愈逻辑的完善，都需要在实战中不断迭代。但看到测试脚本在页面小改后能“自己想办法”通过时，那种感觉，确实很值。