你的 AI 不仅仅编写测试，还会运行它们。
Source: Dev.to
在真实浏览器中编写可运行的测试
大多数 AI 生成的测试在 Node.js 中运行——针对 jsdom（一个模拟的 DOM）。这在很多情况下都能工作，但它并不等同于在实际应用中运行，使用真实的组件、真实的路由以及真实的网络模拟。
TWD 测试在浏览器中运行。它们在你正在运行的应用内部执行，针对真实的 DOM，挂载你的实际组件树。/twd 技能——TWD AI 插件 的一部分——会编写测试，在浏览器中运行它们，读取结果，如果出现失败，则修复代码并重新运行。
完整循环
- Write – 代理读取你的
.claude/twd-patterns.md，了解项目的测试约定，然后生成符合这些模式的测试。 - Execute – 测试通过
twd-relay发送到你的浏览器，这是一个将代理与运行在应用中的 TWD 侧边栏连接的 WebSocket 中继。 - Read results – 通过/失败状态以纯文本形式返回，并附带错误细节（没有截图，没有 DOM 转储——只有你需要的信号）。
- Fix and re‑run – 如果测试失败，代理读取错误信息，调整测试并重新执行。
此循环自动运行；在完成之前你无需参与。
How the Relay Works (Without Getting Heavy)
twd-relay 使用 WebSocket 连接在代理和浏览器之间。当代理想要运行测试时，它会通过中继发送命令。浏览器在运行中的应用内部执行测试——针对真实的 DOM，使用你已经模拟的 API 响应，并且使用真实的组件状态。
结果以简洁的文本返回：是否通过？，如果没有，则返回 错误信息是什么。这使得令牌使用量非常低，给代理提供与你在终端中看到的相同输出——结构化且可操作。
在构建之前先运行
推荐的工作流程是先写测试。先运行 /twd 再实现功能。
/twd Write a test for the checkout form — it should verify that submitting with an empty email shows a validation error代理根据你现有的模式编写测试，在浏览器中运行它，并且会失败——因为该功能尚未实现。这个失败本身就充当了规范。随后你实现功能，测试通过，而你无需考虑测试结构、选择器或 mock 设置；代理会使用项目中已经掌握的模式来处理这些。
当测试无法通过时会发生什么
并不是每个测试都能在第一次尝试时修复。有时代理会遇到它无法解决的情况——组件的行为与预期不同，或模式无法清晰地转换。
/twd 技能通过硬性限制来处理这种情况：如果在三次修复尝试后测试仍然失败，它会被标记为 it.skip 并在文件中留下注释。它不会阻塞其余的测试运行，让你可以稍后调查真正的问题。这种做法保持了信任：失败会被显现出来，而不是被静默隐藏。
保持对话清洁
/twd 技能在一个分叉的上下文中运行，这意味着测试迭代、失败尝试和修复循环会与主对话分开进行。完成后，你会收到一个摘要，说明哪些通过、哪些被跳过以及创建了哪些文件，而无需滚动浏览大量调试信息。
一个具体示例
假设你正在构建一个 Vue 组件，用于获取并显示用户数据。你执行：
/twd Write tests for the UserProfile component在幕后：
- 代理读取
.claude/twd-patterns.md，了解你的项目约定、如何使用twd.mockRequest()来模拟 API 端点，以及在screenDom中使用哪些选择器。 - 它生成的测试会模拟
/api/users/:id端点，访问页面，并断言显示的数据是否正确。 - 通过中继在你的浏览器中运行这些测试。
- 如果测试失败（例如选择器与标记不匹配），代理会读取错误信息，修正查询并重新运行。
- 所有测试最终都会通过。
**总耗时：**不到两分钟，且无需人工干预。
实际需要的入门准备
- 在你的应用中运行的 TWD 侧边栏（来自
twd-js）。 - 本地运行的
twd-relay。 - 由
/twd:setup生成的.claude/twd-patterns.md。 - 从 twd‑ai repository 安装的
/twd技能。
就这么简单。relay 负责浏览器连接，patterns 文件定义约定，skill 协调其余工作。
即将推出：CI 设置
在本地编写和运行测试只是方程式的一半。另一半是将它们集成到 CI 流水线中，使测试在每次推送时无头运行，根本不需要浏览器。
本系列的下一篇文章介绍 /twd:ci-setup，它会配置你的项目在 CI 中使用无头 CLI 运行器执行 TWD 测试。如果你曾希望 AI 编写的测试来把关部署，这篇文章就是你需要阅读的。