devgo.cn你有没有遇到过这种场景：正专心写着代码，突然一个窗口弹出来抢走焦点，你敲的键全打进了那个窗口里，屏幕阅读器也开始朗读测试界面的内容——这是 Claude 在跑 UI 测试。对使用 JAWS 或 NVDA 等屏幕阅读器的开发者来说，这简直是灾难：Claude 每测一步，你的工作就被打断一次，焦点乱跳、按键乱飞、读屏软件在耳边不停播报测试窗口的内容。作者每天都要面对这个问题，于是干脆写了个工具，让 Claude 彻底搬进虚拟机里测试，你的桌面从此清净。
这个工具叫 vmtest，核心思路是利用 Hyper-V 的 PowerShell Direct 功能，让 Claude 与虚拟机通信。PowerShell Direct 是 Hyper-V 的一个特性，它通过虚拟机的管理通道直接执行命令，不需要网络连接，也不会弹出任何窗口。虚拟机里装了一个小助手，负责启动应用、读取辅助功能树（accessibility tree，即应用暴露给屏幕阅读器等辅助技术的界面结构信息）、点击按钮、发送按键、输入文字、截图、运行安装程序。每执行一步，它都会把键盘焦点落在哪里报告给 Claude。
作者对比了三种让 Claude 测试 Windows 应用的方式：直接在你自己电脑上跑（Claude 的默认方式，最快但会抢占焦点、乱发按键、干扰读屏）；只通过 GitHub Actions 跑 CI（完全不碰你的电脑，但每次检查要等几分钟，只能运行预先写好的测试，Claude 无法边探索边测试）；在本地跑一个测试虚拟机（vmtest 的方式，同样不碰你的电脑，但结果秒回，Claude 可以自由探索应用，每个任务都有干净可重复的起点）。代价是虚拟机运行时要占 2 到 8 GB 内存，以及需要保持虚拟机的 Windows 系统更新。作者的实际用法是混合的：不弹窗的构建和测试仍在本地跑；凡是会弹窗、发按键、安装卸载、需要检查辅助功能的操作，全部丢进虚拟机；CI 里保留完整的测试套件作为安全网。
vmtest 还有一个很实用的设计：每个任务（对应一个仓库和分支）都有自己的检查点（checkpoint），Claude 可以中途停下来，下次回来时应用还保持打开状态。任务合并后，虚拟机恢复到干净的初始状态。作者已经实际验证过：他让另一个 Claude 会话在 QuickMail 邮件应用上使用 vmtest，两个会话互相发消息协作，一个负责教另一个怎么用，期间作者自己继续干别的事。那个会话在虚拟机里安装了 QuickMail，检查首次运行时焦点落在哪里，然后卸载应用，确认卸载确认框在正确时机出现且焦点落在安全按钮上——这些是自动化构建检查无法回答的问题。
要使用 vmtest，你需要 Windows 11 专业版/企业版/教育版（家庭版没有 Hyper-V），开启 Hyper-V 功能，把自己加入 Hyper-V 管理员组，创建一个名为 ClaudeTesting 的 Windows 11 虚拟机，然后运行 vmtest prepare 让虚拟机自动登录、安装助手、保存干净检查点。最关键的一步是把 skill 文件复制到你的 .claude\skills\vmtest 目录，并在全局 CLAUDE.md 里加一行强制规则：任何打开窗口、发送按键或安装应用的 Windows 桌面应用测试，一律用 vmtest 在测试虚拟机里跑，绝不在本机跑。再加一条权限规则，让 vmtest 无需每次询问就能执行。
这个思路对任何被 AI 自动化测试干扰的开发场景都适用：不只是屏幕阅读器用户，任何不想让 AI 测试抢占你工作台的人都能受益。它把"AI 在哪儿跑"这个决策从"默认本机"变成了"按需隔离"。要注意的坑：测试虚拟机用的是临时默认密码，别复用真实密码；自动化测试能覆盖很多场景，但真实使用（不同读屏软件、辅助技术、用户配置）仍然不可替代。如果你也受困于 AI 测试抢占你的电脑，这个方案值得一试。
内容与图片版权归原作者所有 · 原文: https://theideaplace.net/letting-claude-test-windows-apps-in-a-vm-instead-of-on-my-pc/