Python+Playwright：AI交互自动化回归测试完整方案

提示词工程师大概是最近两年里最容易被误解的岗位。外人看着就是“写写文字”，实际上每天都在跟不确定性打交道。同一个问题，措辞从“请总结”改成“用三句话总结”，输出可能就完全变了一个风格；你为了让A场景的结果更结构化，改了系统提示词，结果B场景跟着翻车。这种回归问题，手工根本测不过来，所以我在负责某AI助手项目时，花了差不多一周时间，用Python和Playwright搭了一套专门针对AI交互的自动化回归测试。这篇文章就聊聊这套方案的完整思路和落地细节，内容包括工具选型、用例设计、断言策略以及我踩过的各种坑。

1. 从提示词迭代的痛点说起：这个项目到底在解决什么问题

1.1 提示词工程的“回归灾难”

做过提示词工程的人应该都有这种体验：你调的不是一句话，而是一整张因果网。

假设系统提示词里定义了角色的语气和输出格式，某天产品说“回答太啰嗦了，压缩一下”，你就把“请给出详细说明”改成了“请简洁回答”。结果测试发现，原本能稳定触发的工具调用功能开始频繁失败，因为Agent在“简洁回答”的压力下跳过了必要的上下文收集步骤。这种问题在提示词迭代过程中几乎每周都会出现。

更麻烦的是，提示词的影响范围经常是隐性的。一个负责“提取用户意图”的提示词片段，可能影响几轮之后的追问逻辑；一个负责“格式化输出”的约束，可能中断模型本来稳定的推理路径。手工回归测试对这种隐性依赖毫无办法，因为你根本不会想到要去专门验证那个被波及的功能模块。

我见过太多团队在提示词迭代上采用“出了事故再回滚”的策略，每次改动都像一次冒险。大家不是不想做测试，而是不知道用什么工具、按什么标准去测。专门做AI交互的自动化回归测试，核心目的就是解决这个痛点：让提示词改动从“心惊胆战”变成“有据可依”。

1.2 自动化回归要覆盖的三层目标

这套方案在设计之初，我就给自己定了三个层次的覆盖目标，后续所有的用例、断言和工具选型都是围绕这三个层次展开的。

第一层是功能层，也是最基础的：AI交互流程能正常走通，页面不报错，请求能发出，回复能展示。这一层如果挂了，其他都无从谈起。

第二层是质量层：输出结果是否符合提示词设定的约束。比如要求输出JSON却给了自然语言，要求三个要点却只给了一个，要求中文回答却冒出了英文。这一层直接关系到提示词约束是否生效。

第三层是一致性层：修改提示词之后，所有已有场景的行为是否符合预期，有没有破坏以前能正常工作的功能。这一层是回归测试的灵魂。没有一致性保障，每次改提示词都是一次赌博。

这三层目标层层递进，功能层保证“能用”，质量层保证“好用”，一致性层保证“稳定”。整个项目从用例设计到断言策略，都是围绕这三层目标展开的。

2. 工具选型：为什么是Python加Playwright

2.1 直接调LLM接口不够解决问题

很多人第一反应是：做AI交互的回归测试，直接用Python写个脚本调LLM的API不就行了？何必上Playwright这种浏览器自动化工具？

这个思路对纯后端接口的验证是有效的，但对提示词工程师来说远远不够。原因有两方面。

第一，提示词工程师关心的不只是模型返回了什么文本，还包括用户在真实交互界面里看到了什么。流式输出的渲染节奏、Markdown格式的展示效果、工具调用结果的呈现方式，这些都是模型Raw Output里看不出来的。很多问题恰恰出在“输出本身没问题，但渲染层处理不了”这种场景。

第二，AI交互通常不是一问一答那么简单。用户可能会连续追问、中途切换话题、点击推荐问题、上传附件，这些交互状态依赖前端的上下文管理。直接调API模拟不出这种状态流转，只有真实的浏览器环境才能覆盖。

所以选型思路很明确：必须有一个能够驱动真实浏览器的自动化工具，模拟用户的实际操作路径。

2.2 Playwright在AI交互测试里的三个优势

我对比过Selenium、Puppeteer和Playwright，最终选了Playwright，主要是看中它在三个方面的表现。

第一个优势是自动等待机制。AI交互页面几乎都是动态渲染的，元素出现时机很不确定。Selenium要求你手动写显式等待，写少了容易崩，写多了浪费时间。Playwright的内置自动等待会等元素可交互之后再执行操作，省掉了大量sleep和wait逻辑。这一点在AI流式输出场景下尤其重要。

第二个优势是网络拦截能力。Playwright可以拦截和篡改网络请求，这对AI交互测试特别有用。比如我想模拟模型超时的场景，直接route拦截请求并挂起响应就行，不用真的调外部服务。还可以通过拦截请求来验证前端是否正确拼接了提示词上下文，这个后面细说。

第三个优势是Trace录制。Playwright跑测试的时候可以自动录屏并记录每一步操作的DOM快照，用例失败之后可以直接回放整个交互过程。调试AI交互问题的时候，有了操作回放和网络流水，定位效率高了一个量级。

工具层面还有一个务实考量：Python生态对测试支持成熟，pytest、pytest-html、pytest-xdist这些插件可以直接复用，写断言时又可以用Python里一堆现成的NLP工具库，非常适合AI交互测试这种既需要浏览器操作又需要文本分析的场景。

3. 环境搭建与第一个用例跑通

3.1 环境准备与最小化配置

环境准备很简单，Python 3.9以上，然后安装依赖：

pip install playwright pytest playwright install chromium

注意，playwright install这条命令是必须的，它负责下载对应版本的浏览器内核。我第一次跑的时候就漏了这一步，结果启动浏览器直接报错。

项目结构建议这样组织：

ai_regression/ ├── conftest.py ├── config.py ├── prompts/ │ ├── summary_system.txt │ └── translation_system.txt └── tests/ ├── test_chat_flow.py ├── test_summary.py └── test_tool_call.py

提示词单独放到prompts目录，不要写死在用例里。这样每次修改提示词只需要替换文件，回归用例不用动，自然就形成了“提示词版本变化”和“测试代码变化”的解耦。

conftest.py里做两件基础工作：启停浏览器和创建隔离的页面上下文。

import pytest from playwright.sync_api import sync_playwright @pytest.fixture(scope="session") def browser_instance(): with sync_playwright() as p: browser = p.chromium.launch(headless=True) yield browser browser.close() @pytest.fixture def page(browser_instance): context = browser_instance.new_context() page = context.new_page() yield page context.close()

这里用session级别的浏览器实例，每个测试用例单独创建新的context和page，好处是会话数据完全隔离，互不影响。

3.2 用同步API写出第一个用例

Playwright提供了同步和异步两套API。默认场景下我推荐用同步API，调试直观，配合pytest也不容易踩事件循环的坑。

第一个用例我选择最基础的“问答流式展示”场景：

import time from playwright.sync_api import sync_playwright APP_URL = "http://localhost:5173" def wait_for_content_stable(page, selector, timeout=15000): prev_text = "" stable_rounds = 0 deadline = time.time() + timeout while time.time() < deadline: text = page.locator(selector).inner_text() if text == prev_text: stable_rounds += 1 if stable_rounds >= 3: return text else: stable_rounds = 0 prev_text = text time.sleep(0.3) raise TimeoutError("AI输出内容在超时时间内未稳定") def test_qa_stream_display(page): page.goto(APP_URL) page.get_by_role("textbox", name="输入").fill("用一句话介绍你自己") page.get_by_role("button", name="发送").click() message = page.locator(".chat-message--assistant").last content = wait_for_content_stable(page, message) assert len(content) > 10

这个用例做了三件事：进入AI对话页面，输入问题并点击发送，等待流式输出稳定后断言内容非空。

注意那个wait_for_content_stable函数，它解决的是AI交互测试里最麻烦的一个问题：流式输出什么时候算结束。直接用page.locator().inner_text()是不够的，因为模型输出是打字机效果，元素刚开始出现时内容还在增长，拿到一个半截字符串就会导致后续断言不稳定。

等待策略的原理是轮询读取内容，如果连续几轮内容不变，就认为输出已经稳定。这个“连续几轮不变”的判断很关键，实测下来比固定sleep可靠得多，既不会过早截断也不会无谓等待。

3.3 模拟真实交互路径：从输入到工具调用

基础用例跑通之后，我很快加了一个更贴近真实场景的用例：模拟“追问+工具调用”的完整链路。

比如某数据分析助手，用户先问“上周销售额怎么样”，Agent会调用一个数据查询工具，然后用查询结果生成回答。这种场景的回归测试要覆盖三件事：前端是否正确发起了工具调用请求、工具调用结果是否正确回填到了对话上下文、最终回答是否引用了数据结果。

def test_tool_call_flow(page): page.goto(APP_URL) with page.expect_response(lambda r: "/api/tool/query" in r.url) as resp_info: page.get_by_role("textbox", name="输入").fill("查询上周销售额") page.get_by_role("button", name="发送").click() response = resp_info.value assert response.status == 200 content = wait_for_content_stable(page, ".chat-message--assistant") assert "销售额" in content

这段代码里最有价值的是page.expect_response这个用法。它能在某个动作发生的同时等待特定请求出现并捕获响应，既验证了操作触发了预期的工具调用，又拿到了响应内容做进一步校验。比“先操作再查接口日志”的方法靠谱得多。

4. 处理LLM输出的不确定性：断言设计的核心思路

4.1 结构断言：先保证“长得对”

AI回归测试和传统Web测试最大的区别在断言环节。传统接口返回的都是确定值，断言可以直接比较。LLM的输出天然有随机性，同一个提示词同一个问题，两次返回可能文本完全不同。这种情况下，断言绝不能建立在“字符串完全相等”上，必须分层设计。

第一层是结构断言，主要用于验证输出格式是否符合要求。现在很多AI应用走Function Call或者结构化输出，前端拿到JSON后渲染成卡片、表格、图表。这种场景先检查JSON结构，再验证字段内容。

import json def assert_ai_output_structure(text): data = json.loads(text) assert "summary" in data, "输出缺少 summary 字段" assert isinstance(data.get("points"), list), "points 字段必须是数组" assert len(data["points"]) >= 3, "要点数量不足 3 条"

结构断言的定位是“兜底检查”。如果提示词明确要求了输出格式，那么格式错误就是最严重的回归信号，其他内容层面的问题都排在它后面。

4.2 内容断言：关键信息有没有到位

结构正确不代表内容正确。第二层内容断言要验证的是：AI回答里是否包含了必须出现的关键实体、关键结论或关键数据。

比如让AI总结一篇文章，标准是“核心指标、风险提示、行动建议”三个部分都要覆盖到。回归测试不会去判断总结写得好不好，但要能确认这些必要的元素没有被漏掉。

def assert_key_points_in_text(text, required_points): missing = [point for point in required_points if point not in text] assert not missing, f"AI输出中缺少关键信息: {missing}"

我之前还写过一版基于关键词变体匹配的增强版。因为AI可能用“用户留存”代替“留存率”这种同义表达，不能只做子串匹配。做法是先定义每个关键点的同义词集合，只要命中任何一个就算覆盖。

这种断言的灵活性要控制好。太严格会把AI正常的表达多样性误判为回归失败，太宽松又失去验证意义。我一般先用真实模型跑10次标注结果，观察哪些是稳定出现的表达，再据此设定匹配规则。

4.3 语义近似度断言：给回归留一点容错空间

结构断言和内容断言能解决大部分“硬指标”，但还有一个场景覆盖不到：提示词改动后，AI回答的风格和方向发生了微妙变化。比如你希望回答“更务实”，结果改完提示词AI变得过度发散，内容全都在讲背景概念，核心建议反而不见了。

这种软性变化靠关键词断言很难捕获。我用的方案是计算语义近似度：把修改前的输出作为基线，修改后的输出与基线做相似度对比，低于阈值就判定为回归失败。

from difflib import SequenceMatcher def semantic_similarity(text_a, text_b): shorter, longer = sorted([text_a, text_b], key=len) matcher = SequenceMatcher(None, shorter, longer) return matcher.ratio() def assert_semantic_stability(text, baseline, threshold=0.45): score = semantic_similarity(text, baseline) assert score >= threshold, f"语义相似度 {score:.2f} 低于阈值 {threshold}"

到这里你可能想问：diff算法能衡量语义吗？严格来说不能。SequenceMatcher基于字符重叠度，只能算是“近似度”而不是“语义相似度”。如果条件允许，用embedding模型计算向量余弦相似度会更准确。我后来升级过一版，用本地部署的embedding接口算相似度，效果提升明显，但代价是测试耗时变长。

实际项目中可以先上diff方案，观察一段时间。如果误报率太高，再考虑升级embedding相似度。

4.4 流式输出的稳定等待策略和容错机制

前面提到的wait_for_content_stable解决了“内容没输出完”的问题。但还有一个更隐蔽的坑：模型偶尔会输出一大段废话然后自纠，或者输出到一半连接中断再恢复。这种情况下内容会出现“先稳定、又变化、再稳定”的抖动。

我推荐的策略是：不做极致的等待收敛，而是重试。高置信度的断言直接放在重试循环里，第一次断言失败后重新运行整个用例，如果三次内有两次通过就算成功。这其实也符合AI应用的现实——用户遇到一次小故障可以重发消息，只要不是频繁出错就不算产品缺陷。

5. 用例组织与回归策略：让测试真正跑起来

5.1 从提示词版本和时间线两个维度组织用例

用例设计好了，还要考虑怎么组织才能发挥回归的效果。我在实际项目中按两个维度做了划分。

功能维度：把AI助手的主要使用场景拆成用例组，问答、总结、翻译、改写、工具调用、多轮对话，每个功能一组，每组下面再细分具体场景。这样提示词改动时可以直接定位到受影响的用例组。

版本维度：把提示词本身当作“被测对象”。每次迭代提示词，用同一套用例回归两轮：第一轮用当前线上版本的提示词，第二轮用候选版本。对比两个版本的通过率和关键场景的语义相似度已经足以判断提示词变更是否安全。

这个对比逻辑是这套方案的核心价值。如果只跑候选版本，用例全过但你不知道跟线上比是好是坏。有了线上版本作为对照基线的回归结果，你才能回答“这次改提示词到底有没有变好”。

5.2 数据隔离和基于环境的配置管理

测试环境的数据隔离一定要重视。AI应用的对话记录会因为用户状态、历史上下文而产生完全不同的输出。回归测试必须保证每次跑在干净的状态里。

具体做法是上面提到的每个用例独立创建Playwright的context，同时通过API清理服务端会话数据，确保同一用户每次进入都是“新对话”状态。

另外把环境相关的配置统一放到config.py里：

import os APP_URL = os.getenv("AI_APP_URL", "http://localhost:5173") MODEL_NAME = os.getenv("AI_MODEL_NAME", "test-model") USE_MOCK = os.getenv("AI_USE_MOCK", "0") == "1" BASE_SYSTEM_TEMPLATE = "prompts/summary_system.txt"

USE_MOCK这个开关很重要。开发调试阶段可以开启mock模式，不真正调用模型，而是返回预置的固定文本。跑通测试逻辑之后再把开关关掉，用真实模型验证。这样能快速区分“测试代码问题”和“模型输出问题”。

5.3 失败重试与回归报告的落地

AI交互的不确定性决定了用例不能一次失败就直接判Fail。我在pytest中加了重试机制，失败后自动重跑两次，仍然失败才标记最终结果。

重试要注意区分失败原因。如果是网络超时、浏览器崩溃这种基础设施问题，重试没问题。但如果是断言失败，重试同样大概率失败，反而浪费时间，所以我的重试只针对TimeoutError这类异常，断言失败直接失败。

测试报告方面，用的是pytest-html加Playwright自带的Trace录制。每个失败用例自动保存trace文件，测试结束后把HTML报告和trace文件归档到本次触发记录的目录。报告命名带上时间和提示词版本号，方便回溯源因。

就这样用了大概两周，我们在一次提示词改动中提前发现了三个回归问题，其中一个是关键功能被破坏，手工测试根本不可能测出来的。

6. 常见问题与排查技巧实录

6.1 选择器不稳定导致“好不容易等到却点了错地方”

AI交互页面高度动态化，DOM结构变化频繁。之前用CSS路径写选择器，经常因为某个wrapper类名变化就挂了。后来统一改用Playwright的get_by_role和data-testid，稳定了很多。

前端是React或Vue项目的话，强烈建议让开发在每个交互元素上加data-testid属性。虽然听起来有点侵入性，但对测试的稳定性提升是指数级的，一次投入长期受用。

排查选择器问题，最实用的技巧是Playwright的codegen命令。执行playwright codegen打开浏览器，手动操作一遍AI交互，它会自动生成对应的选择器代码，比自己对着DOM树找效率高太多。

6.2 流式输出与自动等待冲突

Playwright的自动等待其实有副作用。它觉得元素可交互时，内容可能还在输出中。比如获取输入框的值用于断言，拿到的可能还是空字符串。

解决办法是我在3.2节里写的轮询稳定判断函数。各种AI应用都可以复用这个思路，等文本连续几轮不再变化再做断言。注意轮询间隔要合适，0.2到0.5秒比较合理，太短CPU占用高，太长拖慢整个测试。

6.3 断言过严造成大量误报

这是所有AI回归测试都会遇到的坎。刚开始我把语义相似度阈值设在0.6，结果跑完一次真实模型回归，失败率超过一半。后来逐一分析失败用例，发现大部分是正常表达差异。

解决方案是先用真实模型收集20到30个样本输出，统计baseline与候选的相似度分布，把阈值设在分布均值减去一倍标准差的位置。同时每个关键信息点的匹配规则做成可配置的，不同场景不用不同的严格度。

这里提醒一句：误报的杀伤力被低估了。回归测试如果天天误报，团队会逐渐对失败用例失去信任，最后看到红灯也不当回事。宁可阈值放宽一点，先保证“报出来的都是真问题”。

6.4 页面元素明明存在却一直等待超时

排查经验：先打开headed模式看一遍真实运行过程，确认是不是visible状态与可交互状态的差异。AI应用经常出现loading态遮罩挡在输入框上方，Playwright认为元素被遮挡就不会执行操作。

page.locator(".overlay-loading").wait_for(state="hidden")

在操作前加一行这样的等待，把loading遮挡层等掉再继续，能消除绝大多数超时问题。

6.5 常见问题速查表

用这套表格对照排查，大部分问题都可以在几分钟内定位。

结尾：围绕提示词的持续验证

最后说一个我自己的体会。这套方案跑起来之后，最大的收获不是节省了多少手工测试时间，而是让我敢大胆改提示词了。以前动一行系统提示词，心里总会犯嘀咕，不知道会影响哪些下游场景；现在每次调整之后跑一遍回归，通过率、语义相似度、关键功能状态一目了然，心里立刻有数。

这个框架后续还可以扩展。我在计划加一个“提示词变更对比报告”的功能：每次提示词改动自动跑两个版本的回归，输出差异报告，直接在CI界面可视化展示。这样提示词工程师和产品都可以直观看到改动带来的影响。

如果你也在做提示词工程，建议尽早把这种基于浏览器自动化的回归机制搭起来。别等线上出了事故再补，到那时候成本高得多。从最简单的问答流式展示用例开始，跑通之后再加断言、加工具调用场景、加语义稳定校验，一步步完善，投入一周左右就能初具规模。