如题所示，虽然这个帖子我是用 playwright mcp 发送的，但是感觉如果只是在聊天框里通过自然语言控制 mcp server 操作，有点蠢啊，对自动化测试有什么加成吗，感觉不如 midscene 或者 broswer-use 之类的工具更有意义。总不能每次想用 ai 测啥，我还得盯着聊天框里实时指导吧？
截图是我在聊天框里调试的过程，我没有遵循 prompt 工程的原则，例如尽可能一步只做一件事儿之类的，但从调教过程来说，我觉得这像一个玩具，不具备在测试工作中应用能力啊。
下面是我用 midscene 在 ai 的帮助下写的脚本（我完全不会 js）：
这个理念比较认同，只让 ai 做它能做且人不愿意做的事儿（例如高宽容性的元素定位），流程控制还是代码里来，写一次就完事儿了，总比愚蠢的在聊天框里去指导 ai 怎么做好吧，有那功夫我点点点不好吗
有那功夫我点点点不好吗
技术是演进的嘛，不好用就慢慢改进。如果还是点点点，那没人为技术演进而努力了。
UI 自动化可以有一些用，playwright-mcp 初始化浏览器后可以开启录制操作，cursor 把录制过程直接转成用例。
接入工作流，把写好的用例交给他去一条条执行
已经积累了很多用例的场景，应该如何将这些用例转换成 AI 执行的步骤，或者将 AI 执行的步骤转换成用例集中？感觉这个过程还要人参与的话，短期用处不是很大
恒温
回复
我不是反对技术演进，相反我还挺感兴趣的，当初发这个帖子是想咨询 playwright mcp 的用法，不过目前看这个东西好像还没有好的落地场景，只能作为一个玩具。 即使作为玩具来讲，感觉 midscene 的路子更正确一些。如果还是要人为的盯着对话框一点一点的调整，没意义，等它演进吧。
我还是赞同 AI 如果真的好用，AI 的提供商已经演化出成型的方案卖给顾客了。不过先阶段 AI 还在辅助阶段，如果 AI 已经完全代替了某个垂直的行业，那也不至于遍地都是卖课的了