让computer use 速度飞起来：JEV-Ultrafast 的 DOM 决策链路实测
-
数据很扎实，尤其把 read/decide/act 分段计时——这一步就比大多数「体感快多了」的分享有价值。补几点，把结论钉死、也方便别人复现：
-
9.9× 是「读屏方式 + 决策方式 + 动作注入」三个变量一起换的结果（还叠了 13 步→8 步的步数差）。想归因就做个 2×2：{截图 / DOM} × {自由生成 / Choice}，动作层固定成同一个（都用 XTEST 或都用 CDP 合成）。耗时同时给「每步」和「每动作」两种口径，否则读者会拿 271/13=20.9s 对 27.4/8=3.4s 说事。
-
decide 的 894–1404ms，先量网络往返：同链路 ping / 一次空 Choice 的 RTT，差额才是分类器本身。若 RTT 占大头，本地小分类器或裁剪/缓存元素表，可能比换模型更有效。JEV README 报的 0.13–0.38s 大概率是近端数字，跨洋对不上属正常，写清这点即可。
-
confidence 门控方向对，但当概率用之前先做校准：拿一批带标签的步画 reliability diagram，或至少按操作类型分阈值（DONE/BLOCKED 与 CLICK 代价不对称）。低置信重读要设上限，否则会退化成另一种空转。
-
act 的 1.3–1.7s：14 个 wheel tick 每次 XSync 是纯浪费，合成一批事件后一次 flush，或减少 tick、加大单次滚动量；给「14 次 sync vs 一次 flush」一组对照就有说服力。
-
原生桌面缺口，除了 OCR，Linux 上还有 AT-SPI（pyatspi）这条确定性读法：能拿角色、名称、可执行动作和几何，和 JEV「确定性读 + Choice」是同一套哲学，比 OCR 稳且便宜；OCR 留最后回退。
-
安全面提醒：元素表是模型输入，页面文本（label/aria）就成了不可信输入，可能诱导 Choice；元素文本要限长、去控制字符。XTEST 是全局坐标，跑的时候别把凭据/私聊窗口留在同一屏。
-
单个任务的方差可能很大（第 1 步 read 就吃了 4.45s 的加载）。建议固定 10 个站点 × 3 次取中位数，连同 JSON trace 一起发，别人才能真复现。
-
-
，
T terry 固定了此主题
-
-
，系统 取消固定了此主题
-
其实把截图分析改成CDP就已经加速很多了。但是有些靠脚本加载的网页，从DOM那里读出来的就是一堆JS调用，还要fallback到截图分析。对应Hermes里面就是browser（看DOM）和browser_vision（看截图）两个工具。
JEV实际加速了多少，要跟没有JEV的DOM路线对比
对, 我也这么觉得.
从截图到操作DOM, 这一步加速我猜测是加速幅度最大的. -
其实把截图分析改成CDP就已经加速很多了。但是有些靠脚本加载的网页，从DOM那里读出来的就是一堆JS调用，还要fallback到截图分析。对应Hermes里面就是browser（看DOM）和browser_vision（看截图）两个工具。
JEV实际加速了多少，要跟没有JEV的DOM路线对比
-
-
它准确率不是100%
应用到财务流程中？它准确率不是100%
应用到财务流程中？也不算严格用在财务流程里吧，我想做的其实就是一个自动化创建、提交报销单的应用，输入出差时长，或者报销类目的简单自然语言的描述，以及发票，水单之类的文件，然后这个应用自动化分析，审核，最终提交报销单，达到减少员工的报销工时的目的。我们现在报销攒的多了，至少花一下午，甚至花一天去做提交
只要报销单正确率能到90%左右就好，这个应该可以实测多轮以后加一些自动化审核流程做到。最终提交的报销单有些小错误也不要紧，有外包的人员来审核报销单的错误，打回来再由人来改就好了。
