ZhaokunZhang

@beimenjun 通过询问作者得到一份真实场景的数据
一条中长复杂度的 App 自动化 case ，从进入洋葱 App 做题板块，到循环完成 5 道题，并断言结束页结果正确。该 case 实际共请求豆包视觉模型 doubao-seed-1-6-vision-250815 共 33 次。

在执行过程中，我们在调用层实现了 Token 经济熔断机制：当上下文 token 接近一档上限时，主动切断当前会话上下文并开启新一段请求，避免后续 prompt tokens 持续累积进入更高计费档位。这个真实案例中，第 21 次模型请求时 prompt tokens 达到 31,328 ，第 22 次请求被熔断切段后降到 2,982 。

这次真实执行的 token 数据为：总 prompt tokens = 486,363 ，总 completion tokens = 2,613 ，其中 cached tokens = 438,549 ，缓存命中率 90.2%，真实推理 token 为 50,427 。

按该模型一档计价口径估算：未命中输入 0.72 元 / 百万 tokens ，缓存命中输入 0.16 元 / 百万 tokens ，输出 7.2 元 / 百万 tokens 。

费用公式为：

总费用 = 未命中输入 token × 未命中输入单价 + 缓存命中 token × 缓存命中单价 + 输出 token × 输出单价

代入数据：

未命中输入 token = 486,363 − 438,549 = 47,814 ，费用约 0.034 元；缓存命中 token = 438,549 ，费用约 0.070 元；输出 token = 2,613 ，费用约 0.019 元。

所以这条 33 次模型请求的中长复杂度 case ，整体推理费用约为 0.12 元上下。该金额已经包含缓存命中 token 的计费，但未包含缓存存储费；缓存存储费量级很小，暂不计入。

@lancevps 这个可能理解岔了，AI 生成测试用例是输入，AI Phone 做的是执行。目前我们使用的典型场景是：AI 生成测试用例后（比如 cursor 生成的），触发器直接自动调用 ai-phone 开始端到端的真机执行

@clemente 你提的 hook + AI 方式确实在调试和快速验证上很高效，但在我们公司属于开发自测阶段的验证手段，在测试场景里，我们还是需要在真实设备上多端完整走一遍用户流程，确保交互和界面行为都被覆盖。

@kkwwuuww 目前真机手装，后续会加入这个功能，上传分发

@beimenjun 关于经济性和速度，其实做了不少工作：
经济：
开启模型主动式缓存：模型在首次执行测试用例时就会有约 90% 的 token 消耗落在缓存区，消耗其实不算大。
同时有分段逻辑：当模型上下文达到 30K token 时会主动断连，并注入上下文辅助信息，保证执行稳定，同时避免触发模型阶梯计费。
速度:
纯视觉回放比较复杂，要速度会牺牲稳定性，要保证稳定又会牺牲速度，因为无法自动判断每个动作是否准确落下。
目前有三种缓存策略，适配不同场景：
1. 固定轨迹回放
* 按首次执行的动作完整回放，对业务稳定性要求高。
* 每步页面检测严格，保证稳定后执行，但速度一般。
2. 路标缓存回放
* 每步执行后与首次缓存路标对齐，判断动作是否正确。
* 正确就继续回放；不正确就按首次执行真实间隔加载完成，再由 VLM 局部介入修复本步骤，修复后继续缓存回放。
* 静态需求场景下速度最快。
3. 位置重建缓存回放
* 针对业务频繁变动的场景，将首次执行动作抽象缓存，再次执行只询问模型位置，不重新推理。
* 保证实时正确，同时节省成本，速度比首次执行略快。

弹窗/非业务浮层标记逻辑
* 在路标和位置重建回放中，如果弹窗存在，会帮助关闭；不存在则跳过继续回放，保证整体稳定性。
这些方案各自适配不同场景，但天然都对业务稳定性有一定要求。

@cthunter 如果 deepseek 视觉模型全量，估计成本更低。

@WebKit 我这边都是端内 web view 有些需要触发端内桥的功能。主要是这个。 作者本人没 v2 号。

@XuDongJianSama 像我之前呆的杭州、沈阳公司，普遍没有测试岗位，这才找这种的，以前都自测。

@jinxgogo 不是的，从我之前在杭州的经历，这个是减负的。