我喜欢在Cursor内部使用Playwright MCP。对于未知的bug，它确实很有用。打开页面，检查DOM结构，点击操作，查看控制台日志，找出模态框卡住的原因。这种互动循环正是MCP擅长的。但后来我发现我在用同样的方式处理类似的操作流程：登录 → 打开设置 → 更改时区 → 保存 → 刷新 → 确认时区更改。这个流程已经很熟悉了。Cursor仍然花费了一半的时间来打开页面、查看快照、决定要点击什么，重新阅读页面然后解释它看到的内容。这种方法确实有效，但感觉像是为一个90秒的烟雾测试而维持整个浏览器会话。于是我把工作流分开了：未知问题：使用Cursor + 浏览器MCP 已知可重复检查：外部CLI 永久关键流程：代码仓库中的Playwright测试 对于中间层，我一直在尝试TestMu的Kane CLI。Cursor可以通过相同的AGENTS.md样式路径读取Kane指令，并在修改后调用它。Kane运行目标并给出Cursor结构化的通过/失败输出以及浏览器证据。因此，不是包含每次点击和页面快照的编码对话，Cursor主要获取：流程完成或失败断言失败最后页面状态运行结果的证据 这种分离感觉更加清晰。我并不是在说MCP总是过度消耗上下文信息。如果代理正在调试未知的问题，那么这个上下文就是关键点。我也不是用Kane替代Playwright。认证、计费、权限以及稳定的回归测试仍然属于正式测试范畴。这是特别针对那种流程足够重复以至于不适合探索但又不够重要不足以立即构建和维护为永久性测试的尴尬中间地带。你是选择在Cursor的上下文中保留浏览器控制，还是将已知检查移出到CLI/CI之外？—— 来自/u/NammieMieMie [链接] [评论]