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

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

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

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

  • 不会用到后面收费吧?