插个眼，目前我们就是直接让codex直接自己启动自己看页面，然后告诉他大概想怎么用

尝试过 ai 直接做 ui 测试。发现这条路走不通，稳定性，耗时，成本都是问题。

目前最佳实践应该是让 ai 写自动化测试脚本，谢谢 ai 只参与一次，后续都能稳定复用。

ui 有变化后，自然跑不通，ai 再去改就行

playwright mcp + skills + playwright cli,能固定的的都让ai使用cli的命令去生成自动化脚本，这样比较稳定。。。纯ai视觉化的话很吃token啊，稳定性也不能保证吧

我现在的思路是browser-use来跑元素定位，存档下来，然后用playwright来跑

我目前也是这个思路，这样才能保证稳定性，不然太痛苦了

是的，我也是这个想法，而且我们公司的产品迭代速度还很快，我也说过做ui自动化很没必要，可是领导还是安排了任务 ^-^

很正常，等7、8月大厂有关AI测试的对外实践ppt出来了，大概能有什么新的变化了，去年都是在解决AI测试用例，但是一直没有很好的解决AI测试执行的这个环节。你现在说的落地效果不好，应该就是 用例质量低、执行不稳定。我解决方案是：用好一点的模型 ^-^

比较好奇的一点是，做成这种ui的时候调用skills是什么调用诶，佬。

直接在项目中新建一个skill文件夹，然后给提示词吗

多好的模型算好呢，现在用的gpt-5.5

官方的skill直接装呀，自己写的md写完放进去也可以

pi-agent + midsence.js , 自然语言 → dsv4pro 产出测试用例 → dsv4pro 写midsence 测试 → qwen 3.6做多模态识别 → 产出 midsence报告 → gpt 评审测试报告

当然 自然语言也可以换成带用户故事的prd，这样prd出来丢给QA agent，就可以等待coding agent完成开发后自动转交给QA agent了 ^-^ （PS: 我自己的QA agent还是半成品

佬，这种方式的token成本会很高吧

我觉得核心在于测试规则的建立

• 需求文档自然语言结构化


• 项目固有规则预期


• ai完善规则，预判测试盲点
  
  个人认为只有建立完整详细的规则后ai测试才可

可以，但是也没办法直接解决稳定性和质量的问题。而且就像AI写代码一样，也会有bug要调整，那AI写测试脚本也会有bug。都需要调整的

现在还在野蛮生长期，周围ai测试落地的效果都不太理想，要么token成本很高，要么效果不理想。

感觉在企业中，主要是dify这种才较好用，工作流的迁移

不高，dsv4pro 在prd到测试用例的转化，大量命中缓存十分便宜。另外qwen 3.6的多模态能力只是提供给midsence使用的，这个库也是字节的，我用下来就是用来做元素定位而已，token使用量还行的。后续我在观望ds的多模态能力。。

chrome devtools protocol

AI在测试环节，目前我们发现会出现“偷懒”的问题，实际上未完成，却显示已测试通过。这个目前不知道有没有办法解决。