如果是标准流程，当然不能接受。但现实是看老板对于这个产品的期待程度。如果是希望有一个较高的质量，那肯定是打回，如果是产品认为这玩意儿可以先上线，交代任务，再慢慢来改，那就要靠商量了。毕竟不是每个公司都是大公司，都是标准流程。很多时候做为测试，你如果执意要按标准来，会让大家难堪，只要沟通的东西有记录，出事不怕背锅就行，剩下就看你怎么灵活处理了，你要给出测试不通过的结论，但产品上不上线就不是你决定的了

我遇到过产品需求模糊，开发改了几版才对齐需求的，真就是各理解各的，一点沟通没有。我在中间沟通，每次产品都是挤牙膏输出，测完又说这里没按照他要求来，真是离谱到家了

大多数公司的领导对于 AI 没有清楚的认知，即想要低投入又想要高回报，吹得太过了。导致下面的人不得不面向绩效编程。现在我们公司用 AI 最有用的就是开发自己用 AI 辅助编程，老板提的什么用 AI 重构代码，优化提升效率，在本来审代码就不严格的公司感觉就是天方夜谭，所以用来用去还是在屎堆上缝缝补补。太多小公司老板觉得一个 Cursor 啥的就能帮他省很多钱

接近年底的时候辞吗？年终奖不要了？而且这个时间大概率是不怎么招人的，不太建议这个点裸辞

管理都是向上管理，不做好 ppt，怎么加钱呐。这种东西除非从上往下推，领导层真心想做才能做好，不然都是绩效指标

没啥好办法，时间给够硬着头皮做。建议不要用 AI，东西少无所谓。东西多了，还是自己搭框架比较好，便于后期维护。AI 只适合在屎堆上缝缝补补

所有页面做 UI 自动化？除非你们做一次性的 这后期元素变更啥的，维护成本得多高

钱多 事儿少 离家近 三样占两样就先赖着吧

所以这个就看你们公司内部对于质量的要求了。如果为了完成任务，那不如直接上线。这种情况在我们公司测试是可以直接打回的，就看你重不重视了

至少在我们公司，重构是非常严谨的。研发会详细列举各种服务所涉及到的功能并和测试一起开会讨论测试点。然后 case by case 的进行阶段性测试，保证各阶段无误后再上线，然后进行监控。目的就是一起保证重构的顺利过渡，不影响用户的体验。

专职吗？现在 AI 对于大多数公司，在测试方面还是辅助作用。专职做这些不担心边缘化被裁？如果是业务深耕，余力做这些感觉会锦上添花些？

每天自动化跑起来，出结果先不管，有人问再去看。如果不严重就排到后面去，如果严重就提高优先级。主要是怕有非提测的改动或者环境导致线上出现大面积异常

如果是主动离职，我还有心思整理整理，体面地交接下。但如果是毫无征兆的被裁员，就看我心情咯。反正我也不是什么高级牛马，公司离了我也能转

这还是得很有实力才能独家吧 剪辑门道也很多很细

我是觉得测试转产品真的是一条非常不错的路 如果公司支持的话 最好就内部转了

bug 要有多个维度，纯看数量是没有参考意义的。一个高质量的 bug 跟十个无关紧要的 bug，我是觉得能发现高质量 bug 的人业务理解更深刻。bug 数量短时间内很多 (比如你说的一天内 30-40) 只能证明要么开发质量非常差，要么就是需求没完全对齐。如果开发质量稳定，产品需求明确，一天能发现几个高质量的 bug 就已经很不错了

这么强 求带

卖保险？这个跨度有点大哦

找到一个想去的公司，结合 jd 先把简历拿给 AI 润色下，再针对性的学习 jd 上的要求

太难顶了 只能说先活着吧

送外卖？

真不容易啊 老哥

还是躲不开外包吗

也算是创业了

有人一起 确实更容易坚持下来