指不定是AI一把梭哈的，请参考XXX这些工程帮我迁移到虚幻引擎

> 果然不是只有我感觉6.1sol慢，不过这额度也很久没掉这么慢过了 你别只看额度百分比，有没有可能是耗费token的速度慢了。 我今天用的是6.1sol，用了一整天，不到3000w的用量。前面2天用都是几亿的用量。 ![图片](https://cdn3.ldstatic.com/original/4X/7/5/4/7548747d6c587390d8f83a22fd156ae6e13c6789.

> 盲猜 盲猜啥啊，我都写清楚了：“rust做的UI项目，使用的是gpt-6.1 sol模型、高推理等级，开了fast。”

> astra和6sol都试了会跑两三个小时 哎，就是越做越重了，codex反复的复核、测试，随便做个内容就要几十分钟起步的，一点办法都没有，没其它的Agent可以用 ^-^

> sol6.1不是一点慢 已经被codex气哭了 ^-^

> ds4.1flash dsh也用过，感觉能力不太行，我现在已经魔怔了，codex是食之无味 ^-^

6.1sol你开的极高的推理模式，6你开的是轻度，这耗时肯定不一样啊。

> 接近翻倍 你说反了，是砍了一半的额度

那我可以理解，目前没有很好的工具可以解决后台操作、不抢占键鼠的工具么？ 咱不说影刀，我个人也是认为它有局限性的。

弊端也是有的，采用元素识别只能用在标准的Windows程序或者web上，如果是使用一些非标Windows控件做的程序，就没办法识别。 你说的精度和滚动条的这种，其实不算是问题：图片识别的算法可以解决精度的问题（不一定要像素的精准对比），滚动条是通过编排解决的，比如：``` while 出现滚动条 拖动滚动条; 识别可视化区域是否存在某个截图； if 存在 点击截图的位置

我其实不太了解的是，为啥这种自动化工具全部依赖于html元素识别。 为啥不采用“人眼看”的这种方式？ 人的操作都是先看到某个地方有某个按钮，就去点击它。那为何不采用截图去定位呢？这种方式理论上可以使用在任何的窗口上，包含非浏览器的窗口。

它也只能是操作浏览器吧，我说的是Windows应用。

这种每次运行都要用AI啊，这成本太大了。 我考虑做的是，可以利用AI来自动录制生成脚本，后续执行的时候不让AI介入。

正在写免责说明和迁移仓库，估计下午就可以开源出来了，后续佬你可以自己去看哈 管理端：  用户端： ![图片](https://cdn3.ldstatic.com/optimized/4X/

豆包一老说这个玩意有法律风险，随便一个问题就是有危险的，我怀疑就是以前出过什么岔子，现在豆包都是消极回复

^-^ 是的，属于是闭门造车了，整理一下免责说明，我也准备开源了。

^-^ 应该是吧，可能更多的就是加了一些“商业化”的功能，授权管理这一套

> CPA CAP不太了解是啥，底层上跟sub2api是一样的，也都是把订阅转成api key，我这个就是多了一些团队管理的功能吧，你就简单理解成，我这个部署到公网就是中转站，部署到私网就是团队内部自用网关。

我自己做了一个把codex的订阅做成api key的工具，加了一些成员额度控制的功能，目前在我们自己的团队里面使用，订阅一个codex 20x会员，不使用fast模式和GPT6 astra的话，基本上一个订阅够用3~4个人用，GitHub项目：huzz-open/aster-team