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

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

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

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

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

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

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

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

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

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