降智没感觉到，但是感觉到对 AI 有了依赖性。。。

没法处理，领导们觉得他们成效斐然，继续加码，做事的人怨声载道，反馈情况还会被说觉悟不行，只会唱反调，没有改变，提的方案是开倒车，这尼玛谁还愿意去触霉头。

不输出情绪的话，我会这么回答，供参考：
用例的规模和组织要求的粒度，项目的紧急情况和业务的难易程度、重要程度都有关。这个项目我所负责的部分，明确的用例设计总数量没有特别进行记忆，但是规模没有超过 XXX，由于项目比较急，测试资源紧张，我倾向于的策略是用最小的测试用例总数覆盖最多的场景，但是测试功能点总体保持不变，多版本迭代的时候，能复用尽量复用，以缩减写用例的时间，保持用例的可维护性，保障项目的进度，但是不影响项目的质量。

如果看到你的领导考了，你最好考一个。。。

兄弟，我怎么感觉你像是 33 还没谈过恋爱。你这种很容易上当受骗呀

有时候因为环境问题也没办法，只能在用户那儿看~。。。

复现是为了定位问题，如果有报错接口和用户日志了之后，开发一定要让你稳定复现，说明他们还没发现问题在哪里。
如果你根据报错接口和用户日志已经定位到什么问题了，直接教他怎么改就行。

至于复现，你先通过 vpn 和国外用户操作同一功能，看有没有同样问题，如果有，就复现了，如果没有，再根据自身对网络、系统部署结构的理解和之前的报错记录和日志，逐一排查是哪个环节的问题。

实在没办法复现，就从两方面着手，一是看看日志哪些地方要改进，看不出问题的日志≈没有，二是最最最最最坏的情况，让用户配合你复现（最丢人的做法，不建议）

啥时候 AI 能背锅了才有搞头。
所谓 “测试不完全，等于完全不测试”，测试找到 99 个 BUG，漏测 1 个，测试的价值就会被削弱 99%。

AI 能给日常工作提效，但是展示在 PPT 中的提效会很虚。

我们也在搞类似的东西，但是完全偏离了方向。以我司情况举例，考核一年一个样。一句 “用数据说话”，就让现在很多管理层过度依赖量化指标，忽视定性评估，导致员工只关注数字，忽略实际价值，为应付考核而忽视可持续发展，另外很多数据缺乏监督机制，大家都是程序员，一般知道怎么造数据出来，进而导致数据失真。最终这些指标就变成了内卷工具和大家吐槽的对象了。

最可怕的是，大家都知道数据失真，数据反应不了真实情况，然后设置更多的指标，让数据更有说服力，但是设置的这些东西，一跟不上变化，二有时候就是拍了个脑袋，三弄这个指标的压根儿没干过活。又导致新的指标变成大家的槽点，进入恶性循环了。