蚂蚁招聘，简历投到个人 qq 邮箱？建议贴企业邮箱

公司质量高层求变，核心逻辑还是降本，反正已经陆陆续续有人头顶上的剑掉下来了

我在的公司基本全民 AI，产品研发测试都是在 AI，其实绝大部分人就是拿着锤子找钉子，无论什么方向都尝试用 AI “重塑”，这个思路是没问题的。

但正因为这个思路是很普遍，所以越是容易想到的想法就越多人挤，AI 的出现让很多问题似乎变得不再复杂了，但复杂度并没有消失，多数时候是从工程复杂度转化为给 AI 多维输入的复杂度。

同时一个错误的方向是，很多人想着靠 AI 一把梭把问题全解决了，但 AI 幻觉永远存在，AI 不会懂它没学过的东西，外部一定要尽量把可以确定的东西做成确定性，不要每次都让 AI 玄幻解决。

回到 AI 生成用例这个方向，可能是作为 QA “拿着锤子找钉子” 的前三个冒出来的想法，就类比研发第一个想到 “ AI 能不能根据需求文档直接生成需求所有代码” 一样，太广太泛，以至于第一眼让人以为很容易做而放松警惕（的确撸一个原型可以说毫无难度），实际上是非常难做的。

为啥难做？大家想到的是喂给 AI 需求文档，技术文档，进阶一些地再喂研发需求代码实现，但本质上，AI 不知道你的测试环境（有什么工具、用什么平台）、用例规范、功能历史上下文、业务特性……本质上就是 context 不够，所以【AI 生成用例】我个人感觉步子太大有点扯蛋。

但从始至终，基座模型还是会越发强大，下限越来越高，哪一天 AI 确实能一步到位生成用例了，咱们就失业了。

那也还是很多方向，但是有没有效果现在还无法评价。

如果我们锁死质量这一个狭隘的领域，你就去回忆一个需求从线下到线上都需要做什么质量活动呗。那用例设计、测试 case 编写只是线下最前置的一环，你要是把视角往后挪就能把思路打开。比如风险评估、自动化、监控兜底等。

需求风险评估方向，需求跟版/上线时风险是否可控，就可以从功能、性能、稳定性、安全、兼容、业务特性下手；随便举个例子，比如 app 启动主链路的代码有没有变更，会不会直接导致 app 启动时长变长，这就是很明确很单点的落地。
自动化方向，大模型把现有用例自动翻译为自动化，大模型生成自动化，大模型修复自动化，这些都是很容易想到的。

诸如此类吧

除非有什么特殊要求，不然首选第一种；接口自动化用例需要有原子性，每个 case 只测一个东西，保持简单

AI 不是最擅长代码吗？那就 AI 来写测试平台，什么最基础的 CICD、造数、抓包、用例管理都能用 AI 做

下班回家，业余多学点技术，用免费 AI 搭建一些项目原型。

先看你需要测什么方面的安全。

通用简单的 web 安全问题（如有安全风险的 web 配置，和一些简单的漏洞），有好多现成工具能拿来扫描，但效果可能不怎么样。比如：https://github.com/greenbone/openvas-scannerhttps://github.com/sqlmapproject/sqlmap，

业务性质的安全漏洞，都是靠经验去挖掘，依赖对业务场景和安全漏洞的理解，这种市面上没有工具，只能靠技能。

9 年 3 跳挺正常，平均 3 年换一家，不会是被诟病的地方。

现在呆的公司，从你的描述看，已经达到了个人各维度的天花板，薪酬空间、管理空间、技术空间都没法再上升，最重要的是公司业务发展也到达天花板，那接下来就不进则退，不突破可能或许会慢性死亡，劣势明显。

新的公司，管理空间没有质变化但至少有量的变化，有熟人关系对自己保护更好，最重要的是有新的技术空间，符合 AI 大趋势，公司还在上升，过去就有机会水涨船高吃到红利。

所以综合对比，当下是不进则退，过去短期有量变长期可能有质变。我认为可以跳。

这个要看业务的，不同的业务不可能拉在一个线上对比。就比如 toB 业务，7% 的逃逸率估计算一般或略差；但是对于 toC 尤其是带开发者开放属性的业务，逃逸率 10%+ 是正常的，因为长尾场景多得数不来。

而且问题逃逸也不一定代表什么，毕竟逃逸风险有高有低，同时，当下的测试资源和业务阶段也是影响逃逸率的重要因素。

故，你要找到同领域同类型（最好还是阶段类似）的业务去对比。