杭州这地方的小老板都有点怪，觉得测试是功能点点点，接口压测，测试岗位本身就是软件质量的最后一道防线，项目上线后的质量监控必不可少。
但是可惜了，我在杭州呆了半年，遇到的前同事和领导都挺鼠目寸光的。

骑驴找马呗，我 25 年 2 月裁员后，先找了一家创业公司（北京开放大学外包）号称自研，觉得不行，去了杭州，也是国企外包。过渡到 25 年年底，经过前同事内推，进入了一家不错的自研公司。

伴鱼基本都是 App 原生 + Taro 或者 Taro 单做 App 及小程序，一旦用户体量上来，就会改为 Taro h5 webview 开发。
还有其他的公司也有，只是不在外面说。

招工资高，能力不高的，那也算整治就业市场了，建议你还是立即骑驴找马，跑步前进。
随时准备仲裁。公积金申诉。

@Hyschtaxjh 那就说明真的还有 20%赚钱，但是我这东西我从来不碰，我宁可支付宝买纳指。

第一次，公司待遇不公平，我一个人顶 3 个人 2500 ，另一个代码都敲不明白也 2500 ，
第二次，公司里养了好几个高薪养老，公司扛不住，只能继续压榨我们，为了薪资，也为了证明自己，跳槽
第三次，这家本来就是来北京的过渡，骑驴找马，跳了一家不错的公司，
第四次，杭州外包，创业公司，氛围不错，但是老板跟第一家的一样，画饼，不成事，但是挺开明，买 claude ，很有干劲，但是我觉得给 zhengfu 国企做项目外包，外包迟早会受 AI 及市场缩紧的影响。

是优点，但也是缺点，刀口向内的次数比较多，我装的热情，但我内心冷漠，是一个莫得感情的冷酷杀手。

先去办理下社保追诉，公积金追缴，去小红书查查，每天别忘去签到打卡。

脑袋用了开塞露，奇思妙想挡不住。

别忘了公积金申诉，社保申诉。乱七八糟的从小红书上搜一搜。

@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 像我之前呆的杭州、沈阳公司，普遍没有测试岗位，这才找这种的，以前都自测。