Vibetest Use

一个 MCP QA 工具，用多个 Browser-Use agent 并行检查网站 UI、链接、可访问性和技术问题。

这个能力解决什么问题

vibe-coded 网站常见问题不是“页面能打开”这么简单，而是链接断、按钮没反应、布局溢出、可访问性差、localhost 和线上表现不一致。Vibetest Use 解决的是让开发者在 Claude Code 或 Cursor 里发一句测试指令，启动多个 Browser-Use agent 对目标网站做自动 QA。

核心逻辑

输入是 MCP host 里的自然语言请求，包含 URL、agent 数量和是否 headless，例如测试 localhost 或某个线上网站。MCP server 解析参数后启动多个 Browser-Use agent，每个 agent 用 Playwright/Chromium 浏览页面，寻找 UI bug、broken links、accessibility issues 和技术问题。输出是 QA 发现、问题描述和可能的浏览器证据，供开发者继续修复。

技术结构

• MCP Server：安装后以 vibetest-mcp 作为 Claude Code/Cursor 的 MCP server，接收测试任务。
• Browser-Use agents：实际浏览和判断由 Browser-Use agent 完成，支持多个 agent 并发提高覆盖面。
• Playwright Chromium：README 要求安装 chromium，说明底层仍依赖可控浏览器。
• 参数模型：URL、agent 数量、headless/non-headless 是 README 暴露的核心控制面。
• 模型依赖：要求 Python 3.11+ 和 Google API key，README 指向 Gemini 2.0 Flash。

为什么值得参考

它把 QA 做成一个 MCP 命令，而不是让开发者自己组织测试 prompt。值得参考的是它的任务接口很窄：目标 URL、并发 agent 数、headless 模式。这比暴露一堆浏览器底层工具更适合产品团队使用，也适合嵌入“开发后自动抽检”的工作流。

为什么不建议直接套用

README 信息相对薄，缺少详细报告格式、覆盖策略、失败重试和误报处理说明；它依赖 Google API key 和 Browser-Use，模型判断稳定性需要实测。多 agent 并发会增加成本和目标站点压力，不能替代 Playwright/Vitest 这类确定性回归测试。

如何改造成自己的版本

内部版本可以借它的接口，不必照搬实现：定义 url、test_focus、agent_count、viewport、auth_state、report_format 六个参数；每个 agent 分配固定关注点，例如链接、表单、移动端、可访问性；最后合并成按严重级别排序的报告，并要求每条问题带复现步骤和截图。并发数默认 2-3，不让用户随意开到 10。

适用场景

• vibe-coded 或快速迭代网站的人工前自动抽检。
• localhost/staging 页面需要快速找明显 UI/链接问题。
• 团队已经在 Claude Code/Cursor 中使用 MCP。

不适用场景

• 需要严格可重复的单元/端到端测试替代品。
• 生产后台、私密用户数据或高风险操作页面。
• 无法接受模型误报/漏报或并发浏览成本。

公开版边界

• 项目较新，成熟度待验证。

参考信息

• 原项目：vibetest-use
• 作者：browser-use
• 相关概念：[[网页 QA]]、[[Browser-Use]]、[[MCP]]
• 相关卡片：保守留空