要在测试域吗？如果可以的话我这里有一个

你是怎么 又辞职了吗

我们都已经做成产品要上线了。。

你应该只是站在你作为某个 app 产线的测试的角度，这个最大的好处是低成本的复用性；比如说，一个 app 的登录是一个脚本，如果集团内 10 个产线用呢？ 一个 app 的阻碍性场景假设有 10 个，你就要写 10 个脚本，10 个 app 就是 100 个；你还没算上培训人家写脚本的教育成本；这个基本上就是拿来即用的。

嗯 这个主要是解决卡点场景的人力成本问题，例如：登录脚本、表单填写、有逻辑的流程步骤等等，这块的适用度比较好，不需要像传统的方案一样，一个场景去写一个脚本执行，基本都能够按照用户场景，自主的执行往下的流程；
目前落地不好的地方其实也写了；
第一个，api 的资费问题
第二个，受限于 token 的长度，能够遍历的深度有限

那只是昵称。。。

没有 这不是匿名贴。。

我们去年做了一个方案，当时还没有 gpt4v，我们是直接用的页面树给的 gpt，让 gpt 根据目标进行遍历 app；测试下来，通用性还行，从登录到翻页到点击滑动基本都 ok，而且行为逻辑也较为符合人的思维；
缺点不少，都是关于 gpt 的：
1、太贵 太贵 太贵，3.5 效果不佳。4 真的太贵
2、基于当时 8k 的 token 长度，哪怕我做了历史操作的循环限制，但用完之后，还是会降智（因为没有历史记录可以参考了），这个对能够遍历的页面数量和深度影响很大

目前来看，这个效果还是很不错的，传统 app 遍历要不是随机或者一定能力的定向，例如自己在关键页面去写脚本，比如在登录页，插登录脚本，才能进登录后的页面，但使用 gpt 遍历，完全不需要，能够识别大部分的用户场景，自主去判断如何进行下一步。

但 gpt 自身的限制，确实很影响落地的实际效果，也许再过几年，才能够有完全可用的效果。

生产力进化的过程内会高速生产和淘汰掉大部分的方案，这谁都说不好的事情，但总有人要去做看起来屁事没用的探索，gpt 的诞生如是啊；
如果这个人不是你，也可以多点包容

问一下楼主，这个页面元素的标注，是人工标注的吗？还是有全自动识别元素并标注数据集的方法？