AI当QA测试员：40个Bug实验揭示提示词设计的意外真相

自动化测试只能发现你预先写了断言的问题。按钮功能正常但没人找得到它，表单能提交但电话号码格式要求反复试探——这些跑通CI却让用户困惑的体验问题，才是QA真正的价值所在。

一个自然的问题随之而来：AI Agent能否胜任这部分工作？不是检测页面是否加载，而是判断"真实用户会不会在这里感到困惑"。更进一步，这种能力在多大程度上取决于你如何提问？

一位开发者构建了一个藏有40个Bug的虚拟咖啡电商网站，用三种不同详细程度的提示词让Claude Code扮演QA测试员，实验结果颠覆了不少直觉。

实验设计：一个咖啡店网站与40个已知答案

要测试一个测试员，你必须事先知道正确答案。真实网站无法提供这个条件——如果Agent报告了5个问题，你无从判断它漏了10个还是总共只有5个。

因此实验者搭建了Ponto Coffee Roasters：一个包含商店页、产品页、购物篮、两步结账和注册表单的虚拟在线商店。没有真实服务器，只有一小段代码模拟后端行为，带有随机延迟和首次提交必然失败的设定——一个应用在等待和出错时的表现本身就是用户体验的重要组成部分。

40个Bug来自两个不同的AI模型。Claude构建了商店并植入前20个Bug；随后实验者要求Codex（另一个AI）在Claude无法看到的独立请求中引入另外20个。这样做是为了避免Bug和找Bug的工作全部来自同一个模型。

这些Bug覆盖面很广：几乎读不清的浅灰文字、点击后毫无反馈的"加入购物袋"按钮、显示"免费配送"但总价悄悄包含€6.90的评论步骤。购物篮的减号按钮实际上会增加咖啡数量，Logo链接指向购物篮，手机端结账页面溢出屏幕。还有一些更隐蔽的问题：搜索框在点击别处时自动清空，姓氏字段在输入8个字符后停止接收输入。

三种提问方式：从一行指令到完整清单

实验只改变了一个变量：提示词。

Level 1是最常见的单行指令："你是一名QA工程师。测试网站并寻找UX错误。"

Level 2赋予Agent一个角色（关注用户体验的资深QA测试员），提供商店背景信息、工作方法（先走主流程，再测试错误场景和小屏幕）以及报告格式。

Level 3在Level 2基础上增加了完整检查清单，基于Jakob Nielsen的10条可用性启发式原则和WCAG无障碍指南基础。它还要求Agent分轮测试：桌面端、错误场景、等待与失败、手机尺寸、仅键盘操作。

检查清单在任何Bug存在之前就已写好，避免清单描述的是答案而非测试维度。

Jakob Nielsen的10条可用性启发式原则由尼尔森·诺曼集团联合创始人雅各布·尼尔森于1990年代提出，是人机交互领域最常被引用的可用性评估框架之一。它包含十个维度：系统状态可见性、系统与现实世界匹配、用户控制与自由、一致性与标准、错误预防、识别而非回忆、使用的灵活性与效率、美学与极简设计、帮助用户识别与诊断错误、帮助与文档。这些原则不针对具体界面，而是提供一套通用的检查视角，常用于启发式评估——让少数评估者依据原则走查界面并列出违规点。

**WCAG（Web内容无障碍指南）**由W3C下属的Web无障碍倡议组织发布，是国际公认的无障碍标准。它围绕四项核心原则组织：可感知、可操作、可理解、健壮。每项原则下分若干成功标准，按A、AA、AAA三个等级划分合规要求。与Nielsen启发式关注一般可用性不同，WCAG更聚焦于残障用户——包括视觉、听觉、运动和认知障碍——能否感知和操作内容，例如键盘可访问性、颜色对比度、焦点可见性和屏幕阅读器兼容性。将两者结合成检查清单，等于同时覆盖了普通用户的体验痛点和无障碍合规底线。

公平性控制与评分方法

每次运行使用相同的Agent和模型：Claude Code（Anthropic的编码Agent）运行Claude Sonnet 5.5，通过Playwright驱动全新浏览器实例。浏览器是它唯一的工具——无法读取文件或使用终端，因此无法查看源代码或答案。它只能像访客一样使用网站。每个级别运行三次，因为AI输出存在随机性。

每份报告对照答案键评分：清晰描述一个Bug得满分，仅提及得半分，遗漏不得分。这被称为加权检测分数。为减少评分主观性，一个独立的AI Agent在不知道实验者评分的情况下对所有九份报告进行了评分，两者每份报告的差异不超过半分。

结果：更"好"的提示词反而更差

提示词	三次得分	平均分	百分比	每次耗时	每次成本
Level 1：单行指令	24, 25, 25	24.7 / 40	62%	1.7分钟	$0.51
Level 2：角色+背景	21, 22, 23.5	22.2 / 40	55%	1.9分钟	$0.51
Level 3：完整清单	27.5, 31.5, 32	30.3 / 40	76%	3.5分钟	$0.81

第一个意外就在中间行。实验者预期每个级别都会超越前一个，但Level 2输给了单行指令。

Level 2产出了更长、更精致的条目，每个问题都有标题、位置、影响和严重程度——得分却更低。单行指令运行写出了快速而密集的列表。报告格式可能有所贡献，但这些运行无法将格式的影响与Agent探索方式差异隔离开来。这是一个值得测试的模式，而非结论。

清单改变的不只是措辞，而是行为

Level 3不仅仅是描述得更好，它做了不同的事。

它是唯一按下Tab键的级别——这是测试不使用鼠标的用户如何体验网站的方式，也是全部三次Level 3运行都发现"没有可见键盘焦点"的原因。其他六次运行无一捕获此问题。

每次运行、每个级别都在某个时刻将窗口缩小到手机宽度。但只有Level 3在三次运行中的两次发现了结账页面在手机上溢出。Level 1和Level 2的运行均未报告此问题，其中一次甚至声明"在375px下没有水平滚动"。

清单的作用像一个测试计划。它没有让Agent变聪明，而是让它去了否则会跳过的位置。

清单也会收窄注意力

相反的情况同样存在。页脚的新闻订阅框有一个永不停止的旋转加载图标。一次单行指令运行清晰地报告了它，另外两次获得部分分数。六次使用详细指令的运行一分未得——它们遵循给定的流程路径，而页脚不在其中。

这种现象在人类测试员身上同样常见。给测试员一份清单，他们会覆盖清单上的内容。自由探索发现奇怪的问题，结构化的方法发现彻底的问题。

测试计划与测试章程的区别有助于解释这一现象。测试计划通常是预先定义的、结构化的文档，列出要覆盖的功能、场景和检查项，强调可重复性和覆盖率；测试章程则来自探索性测试方法论，由测试员在限定时间内自由探索并记录发现，强调发现未知问题。二者并非对立：结构化方法保证已知风险被系统覆盖，探索性方法则用于发现计划中没有预料到的问题。给测试员一份检查清单，相当于把测试计划交到他们手里——他们倾向于逐项打勾，把注意力分配给清单上的内容，从而减少对清单之外区域的偶然发现。这被称为清单驱动的注意力收窄，也是为什么许多团队在回归测试之外仍保留探索性测试时段。

九个运行都没找到的Bug

有五个Bug被所有九次运行遗漏。其中四个来自Codex的集合：搜索框仅接受12个字符、搜索框在点击别处时自动清空、姓氏字段在8个字符处停止、商店页面上Huila Sunrise咖啡卡片显示的是另一款咖啡的图片。

第五个来自Claude的集合：双击"加入购物袋"会添加两次商品。

这些问题大多有一个共同点：它们不产生明显的错误消息或布局破损。找到它们需要尝试边界值或跨交互比较行为。没有一份报告识别出商店页和产品页之间的图片不匹配。

双击Bug是一个更复杂的案例。Codex的集合还设置了一次单击添加两件商品，因此双击会添加四件。由于一次单击已经添加了两件，重复点击问题更难区分。植入的Bug可能互相遮蔽。

边界值分析是软件测试中的经典黑盒技术。它基于一个观察：错误往往集中在输入域的边界附近，而非中间值。因此测试员会重点测试最小值、最大值、刚好超出边界以及边界附近的值，例如字段允许12个字符时，测试11、12、13以及更长字符串。当搜索框仅在12字符处截断、姓氏字段在8字符后停止接收输入时，只有主动输入超长或极短值才可能触发。这类缺陷不会抛出错误提示或破坏布局，Agent若只走正常流程就难以察觉。

与之互补的是跨交互比较，即在不同页面或状态下对比同一信息或控件的行为。例如商店页与产品页对同一款咖啡使用不同图片，若不主动比对就发现不了；按钮一次点击添加两件商品、双击添加四件，也需要对比单击与双击的结果才能识别。这两类方法都要求测试员主动构造非典型操作，而非依赖界面自身的反馈信号。

所有人都找到的Bug

另一方面，每次运行都报告了Logo指向购物篮和密码明文显示。同样的一致发现包括：名为"免费"实则收费的配送、忽略数量的购物篮行、页面间价格变化——所有九次运行都捕获了这些数值不一致，包括单行指令运行。

评分者每次运行最多标记一个误报，主要是关于测试环境导致的加载缓慢而非应用本身。每次运行还发现了无人植入的真实问题，如没有自动完成提示的表单字段、屏幕阅读器不会播报的错误消息、以及注册后页头仍显示"创建账户"。

实验的局限

这是一个小规模实验。九次运行、单一模型是一个提示而非证明，换一个模型可能改变数字。测试在云沙箱中运行，阻断了Web字体，与真实访客体验略有差异。全部40个Bug来自AI（两个不同模型），人类测试员可能会植入不同类型的问题。一些植入的Bug互相作用：产品描述被裁切部分掩盖了文字墙问题，重复的"加入购物袋"模糊了双击Bug。这改变了某些Bug的可见度，也意味着五个普遍遗漏并不都指向Agent的单一弱点。

下一步：一个会学习的检查清单

清单让Agent变得彻底，单行指令的自由让Agent变得好奇。因此建议在每次发布前运行两个互补的流程：一次清单运行，一次自由探索运行——后者的任务是发现清单上还没有的Bug。

回顾已保存的分数，实验者将运行两两组合，给每个Bug取两次运行中的最佳得分。一次自由运行加一次清单运行平均得分31.6/40，两次清单运行平均32.3/40。这是回顾性计算而非独立测试的工作流，但表明自由运行不会提高分数——它的价值在于发现尚未进入清单的问题。

那些发现，连同人类测试员的发现和真实用户的抱怨，会反馈到清单中。有些成为通用习惯（如"在每个字段中输入异常长的值"），因需要判断力而保留。另一些是具体的回归问题（如"新闻订阅旋转图标必须停止"），清单是便宜的占位符——添加一行只需几秒，用Cypress等工具编写端到端测试则需要真正的投入。因此先上清单，等有时间或清单变长后再毕业为Cypress测试。

AI能当你的QA测试员吗？

在这个小实验中，浏览器驱动的AI快速且廉价地发现了许多植入的功能和可用性问题。最佳配置以每次不到一美元的成本达到76%的检测率。清单改善了覆盖率，但几个隐蔽Bug在每次运行中都被遗漏。它适合作为发布前的第一轮筛查，而非替代那个输入长名字、不小心点错地方、然后想"等等，刚才这里看起来不是不一样吗"的人类测试员。

关于提示词的核心启示是：AI测试员的提示词工作原理很像测试计划。你放进去的内容会被仔细覆盖，你遗漏的内容可能永远不会被访问。而像任何好的测试计划一样，它永远不该完成——Agent今天遗漏的每个Bug都是明天清单的候选行。

整个实验是开源的：商店、40个Bug、三种提示词、每个Agent的报告和评分。你可以在GitHub上运行自己的提示词，看看能捕获多少。

你是否尝试过用AI Agent进行QA或UX审查？欢迎分享它们为你发现了什么，又径直走过了什么。