我的 AI 测试员说“所有功能正常”——画布一片空白，它到底看到了什么？
标题：我的AI测试代理说"所有功能正常"，画布却是空白的——它到底看到了什么
最早我把测试工作交给AI代理时，它报告说"所有功能正常，通过"。我自己打开工具一看——画布一片空白。AI并没有撒谎。在它看到的那个环境里，工具确实像是能正常工作。我用Claude + Chrome MCP对一大组Web工具做可视化测试，这类假阳性最终都归到两个原因。
原因一：requestAnimationFrame 在隐藏标签页中停止运行
Chrome MCP 通常跑在隐藏（后台）标签页里。而浏览器为了省电，在隐藏标签页中会大幅限制 requestAnimationFrame 的执行力度。在这种环境下测试画布或动画功能，结果如下：JS代码执行了，没有报错，事件处理也响应了——但渲染帧数停留在零。AI会看到一张截图加上干净的JS结果，于是得出结论"动画已启动，无错误，通过"。代码执行和像素渲染是两回事，而隐藏标签页抹掉了这个区别。
发布前的复现测试（2026年7月10日）
我不想让这篇文章变成"想当年"的牢骚，所以在发布前重新跑了一遍测量。通过 Chrome MCP 打开一个标签页，运行 rAF 计数器：
| 测量项目 | 结果 |
|---|---|
| document.visibilityState | hidden |
| rAF 触发次数（3.37秒内） | 0 |
| setInterval(100ms) 触发次数，同一窗口 | 4（预期：33） |
| setTimeout(3000ms) 实际延迟 | 3373ms |
rAF 不是被限速了，而是被停掉了——零帧。额外发现：setInterval 被削减到大约预期频率的1/8，连 setTimeout 都有偏差。所以不只是基于 rAF 的动画有问题；在隐藏标签页里，任何依赖定时器的逻辑都不可信。
修复方法
- 用
active: true打开标签页，使其保持可见 - 在可见标签页中触发交互，等待几秒，再截图确认渲染输出确实存在
- 如果必须在隐藏标签页中评估，报告里必须写明"动态渲染未通过视觉确认"，不能静默地标为通过
原因二：把"JS状态健康"当成"功能正常"
第二个陷阱在AI测试报告中表现为这样的通过理由：
onclick 绑定确认。JS零错误。库已加载。→ 通过
所有这些描述的是代码路径的健康程度，而不是功能本身的行为。
连线正确但画面空白，这种故障太常见了（原因1）。错误代码为零，但下载到的文件却是空的——这也是常事。我的修复方案很简单：先用 grep 在模板里搜索动态功能，每找到一处就强制插入一个行为检查。
以下是代码中需要行为检查的具体场景：
<canvas>
Interact in a visible tab → screenshot after a delay shows rendered content
<input type="file">
Upload a dummy file → preview src is non-empty
download attr / toBlob
Press the button → observe Blob creation
mousedown / touchstart
Fire the event → state/transform actually changed
requestAnimationFrame
Transform values differ after time passes
QA 报告必须附带一份功能覆盖率表格，凡是“代码中写了但行为未被验证”的项，一律不得判为通过。规则就这一条，光靠它就把误报数量大幅降了下来。
附赠功能：截图与 DOM 的矛盾检查
可视化 QA 还有个附带好处：能够交叉核对“代码声称的内容”和“像素实际展示的内容”。比如“类名明明是 text-secondary（理论上应该是青色），但渲染出来却是灰色”——这类层叠和覆盖 bug 就都能带着截图证据被揪出来。人类测试员往往只会卡在“颜色好像不太对”这一步，说不出所以然。
局限与注意事项
- 隐藏标签页的节流机制是浏览器的省电行为，Chrome 随时可能改策略。我的操作原则不是“隐藏标签页不好”，而是“动态渲染必须在可见状态下验证”。
- 行为检查既耗时又消耗令牌（token）。如果对每个工具的每个功能都跑一遍，代价太大。我只对 grep 检出动态功能的工具启用行为检查。
验证记录：2026 年 4 月到 6 月在生产环境验证过，2026 年 7 月 10 日重新复现。测试环境：Claude + Chrome MCP / Windows 11。