如果一直在大厂，7-8 年一般是字节的 2-2/3-1，典型年 package 是 60-100w。

三年到 9 级，这算快的了，七八年 11 级，那得能力与机遇都不错才行。

没机会，你这些个人能力在大厂构不成竞争壁垒，这是对工作一两年的人要求，你这个年龄需要的不是这些，残酷点说如果在大厂，都大概率要被优化。
另外不要去大厂，钱是多，但是身心俱疲。

看看字节的新项目：https://github.com/bytedance/UI-TARS-desktop，对机器资源要求挺高的。

很不错的调研，几年前做过类似的工作，看你的调研路径很熟悉，很多项目也都是当时看过的。

我说一个建议和思路，实际上大部分情况我们并不需要一个非常通用的基于视觉的 UI 自动化测试框架，可想一下大部分需要 UI 自动化的产品，相对来说都是比较大型稳定的应用（否则做的价值不大），它们通常会有稳定的设计规范，完全可以基于特定产品去训练 UI 元素检测与识别，训练数据可以和设计部门合作，也可以基于你说的 UI 1.0 技术生成。
所以需要做的其实是降低整个训练链路的复杂度，让大家可以方便的在自己的产品上做训练。

做好元素的检测和识别是整套方案的基础，“ 唯一标识符” 必须得是语意化的才能有效的支持大模型执行自然语言的测试用例。

这个思路我做过，整套东西不难，关键是你自己没想清楚要解决的问题。这个思路适用的场景是页面展示效果的测试，我当时的场景就是广告 SDK，简单说就是页面业务逻辑少，主要看展示效果。
更进一步的，加上 diff 的思路，连用例都不用维护，解析 UI 组件之后自动遍历所有页面。使用 base 版本和测试版本进行图像 diff，可以全自动完成测试。
如果你想把这个思路用在 UI 自动化测试，那就是很难了，效率和效果比 UI 自动化测试框架都差很多。其实就是基于图像的方式解析 UI tree，好几年前字节做过这个方向，没看到大规模的落地，实际上 UI 自动化都还是用各种自动化框架做的。
这些年 UI 自动化测试框架在易用性稳定性上都有很大的进步，但是还是一个根本问题，大部分业务模式 UI 自动化的投入产出比太低。

效果很好：https://github.com/PaddlePaddle/PaddleOCR

耗时不会特别多，以我的经验看，CR 在执行测试之前，一个需求的代码 CR 典型时间是 1-2 个小时，但是需要这段时间保持高度的专注，并有以下作为前提：

1. 对测试项目整体的服务架构有一些了解
2. 对这个需求内容十分熟悉
3. 对所使用的语言有些熟悉

要想发现比较多的问题，一般建议 CR 之前，先自己想一下如果你来实现这个需求，需要改哪些模块，怎么实现，难点在那里，然后再具体看对应实现跟你的想象做对比，查漏补缺。通常会发现一些实现逻辑不对、不全的问题。
至于偏语法、语言的错误类型，需要对使用的语言有比较高的熟悉度，知道常见易写错的点。当然，现在随着大模型普及，完全可以让 AI 做这一层的工作，实际上 AI 也能做的更好。
另外是对于经常合作的开发，应该了解他的能力和经常会写错的地方，CR 时要重点关注，这点在小公司比较普遍，大厂的研发通常不会犯很低级的错误。
CR 还会带来后续的好处，先 CR 之后，在实际测试阶段对于出现的问题定位会更加的高效，长期积累也可以提高自己的能力。

给每个开发买一个 GitHub Copilot 就可以了。

我说的就是这个问题，实际上应该更为具体，比如写明具体的订单编号（通过这个订单编号依赖于之前的用例生成），或者指明订单的特性，比如 “最近一周的订单”。只有这样具体的测试用例才是有可能把用例编写和执行解耦的。

为什么要强调编写和执行解耦？这会带来很多收益，例如：

1. 可以把用例编写和执行拆分更小的工时单元，可以更灵活的安排排期。避免忙的时候忙死，闲的时候没事干。
2. 用例编写执行可以分给不同的人做，典型的是正职员工写用例，外包执行。

这就是大厂里面重业务逻辑测试部门在推进的事情，也是为了降本增效。当然客观的讲这个事情实际不是这么理想的，执行用例的人还是会有熟悉需求的成本，意愿上也不太愿意纯执行别人写的用例。但这个事情在领导层面看来有上面提到的收益，就会推进。

其实写不写用例也是一个看 ROI 的事情，写用例无疑会有很大的成本，只有尽可能多的扩充收益，才能把这个事情推动下去。