可以的 我加你

非常棒的文章~

不考虑成本的话 我更倾向于多招两个初级测试 根据大模型给的探索建议去点点点

业务场景覆盖率能有多少测过么？
遍历成本在频繁迭代里兜得住吗？
效果问题有可靠的验证 - 迭代手段吗？
遍历对象的兼容性有测试吗？
复杂场景搞得定吗？

ai 一定是未来，但现在 ai 行不行呢，这种智能体太多了，好像就没见到真正落地效果很好的

非常同意 现阶段 还是外围工程化措施 + 单点聚焦场景用 ai 实现 最可靠；经常听到引入了 xxxai 就怎样了、某某又出了用的是大模型可以 xxx 了，好像复杂化的问题加个大模型就可以 0 成本搞定一样。

复杂度不会凭空消失的

我严重怀疑说这话的这帮子人到底看没看过人月神话

目前在内测阶段 可以私我 v 我加你

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

你是怎么 又辞职了吗

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

你应该只是站在你作为某个 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 的诞生如是啊；
如果这个人不是你，也可以多点包容

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

当然是为了造机器人，只是文章里在用拧螺丝先做探索性落地而已；不要只看现在，也要想想未来；如果螺丝最终证明能拧，说明其他场景也是有希望去做的，即便现在技术下效果不好，但我们起码有了可行的方向 --- 而这已经很棒了。

不会用到后面收费吧？

太对了 很多 ppt 吹得很好 搞得公司都想玩 但是一瞅用例 写的人都看不明白 还想和代码挂钩？
但是 ppt 里是不会特地强调这个前提的，说实话，我觉得能搞成这个的，真是屈指可数

训练集从哪来啊，特别是多模态这块的，还是这个开源项目已经全部包含了

我们用的 yolov5 做的模型训练，然后智能识别出滑块的位置

但最终他也没给你深度分析出原因来啊。。都是搜索到的结果 车轱辘话

这还不简单 直接 frida 定点插异常进去啊