饿了么这么多年一直不温不火，直到在淘宝加个 tab 变成淘宝闪购后，居然变成双赢的局面，业务这种东西有时就是这么奇怪，之前的产品肯定都是想着怎么使用推荐算法去获取新用户和维持老用户活跃度，结果把外卖入口引入，就能让用户一天至少打开三次淘宝

类比场景：就好像 K8S、docker 这些东西，实际情况就是能接触的测试人不多，没实践机会学完就忘，也很难学到位，但是经不住大部分有进取心的测试去学，然后再感叹学完没多大用。
说到底的关键就是有没有平台和机会去让你实践这些道理，而机会和平台是可遇不可求

实践了之后，就会开始相信运气和命

外包本来就是极度不稳定的，挺正常
你看下你之前签的合同，然后咨询下相关律师，在社区问是没用的

看 13 年到现在每年的大学生毕业数量，我个人觉得往后几年开始，裁员的人数将会大幅提升，不管是出于 Z 策压力还是出于新鲜血液更换

先什么都不做，小组开会时问问你的下属他们想做什么，汇聚总结后，再跟你的领导讨论看看，同意了就安排下然后交给下面的人去做，不同意那就继续这个循环。还有想想你的前组长为什么要跳去产品组，以后是不是也要学习下他

出门在外，人设是自己给的，社区里的人说的话都不要太当真

谢谢夸奖 ，我的确在公司里是和光同尘，在风险规避和防背锅这方面有独到的见解

25 岁

你这个是面向什么业务设计的？80% 的识别成功率影响不大吗？

如果是我，我会问这几个问题：

1. 80% 识别率是怎么统计的？样本覆盖了哪些场景？不同复杂度页面的识别率差异有多大？
2. 80% 成功率之外的 20% 失败场景，你们怎么处理？是回退手工测试，还是有其他自动化兜底方案？
3. 新框架识别率只有 80%，实际落地时，这个成功率真的能比传统方案更稳吗？有没有和旧方案做过对比测试（比如相同页面的执行稳定性、维护成本）？
4. 80% 成功率是针对所有页面，还是只覆盖了部分简单场景？如果遇到高频的复杂页面（比如表单嵌套、动态加载），识别率会不会暴跌？这种情况下怎么保障测试质量？
5. token 消耗怎么计算？每次元素识别、用例执行要花多少钱？有没有统计过
6. 20% 的不稳定性会不会让业务测试提心吊胆？，增加了监控和重跑的负担，违背了自动化提升效率的初衷？

另外你的描述，给我一种你没有 在实际业务测试中用过这个测试框架的感觉，否则 80% 的成功率你都写出来？
你想想识别成功率是 80%，不考虑其他因素，算你一条用例的成功率是 80%，若一次回归测试有 50 个用例，全部成功的概率仅为 0.8⁵⁰ ≈ 0.0001%（几乎为 0），这意味着几乎每次执行都会出现失败，这就是我上面想问的，如果每次执行都会出现识别率问题，那你们的精力是不是都分散到区分是实际 bug 还是识别问题？