个人见解
1、把你的问题发给 ai，让他告诉你，你会有一个比较清晰的框架，最好是比较强的模型例如 opus 和 gpt
2、关注一些 skills 市场，上面会有比较多的现成的通用工作流，找高星的复制下来定制化就好了
3、做好历史库的迭代

以目前的 AI 能力，基本替代不了测试执行，基本还是人的测试执行效率会更高
大家提供的思路主要还是说如何用 AI 去提高项目质量，实际题主主要问题是 bug 从 100 变成了 300，可能用 ai 介入后，一些逻辑上或者代码风险上的的 bug 就能快速发现了，但是如果说是这多出来的 200 个 bug 都是显示上的问题，实际 AI 很难发现

其实就是几件事
1、持续的使用高质量 ai 软件：codex、Claude code、cursor 等
2、持续的想办法将自己的工作转成 ai 工作流
3、持续的关注 ai 方面落地的东西，搞几个 ai 公众号关注一下就行，他们会告诉你近期很热门的有什么

在我的工作流里面是打算在推验收或者推测试的时候进行的，和回归不太一样，主要还是检查一些代码的明显问题以及需求和代码实现不一致的地方，减少手工跑才能发现的问题数量

其实最好就是把问题发给牛的模型，它会给你比较系统的方法
个人拙见就是增加代码静态检查的工作流，同时找人用 ai 快速搭建接口测试和自动化回归测试

1、目前全链路替代不了
2、我目前想法是增加用例库，实际就是测试点的库，但是要做好增删改查的东西，定期复盘之类的，市面上有一些 knowledge 的 skills 可以参考一下

目前用的多的是 codex，可以试试看

可以分享一下目前想做的，整体就是提交内容的 review
1、常规 diff 的代码/配置 review，最好结合历史 bug 库
2、提交内容一致性检查，以测试点为参考，查出漏写多写写错的地方，当然一些表现类的测试点可以忽略

同游测个人经验：
遇到偶现 bug 怎么处理
1、先开单记录，如果是影响较大的就花时间去处理，影响不大，有时间的时候再去看，因为游测工作量还是挺大的
2、开单是最重要的，避免后续太忙给搞忘了

针对你这个问题，我的想法：
1、先看协议，如果返回的协议是空的，那么找后端反馈，如果返回协议正常但是显示是空的，反馈给前端
2、反馈完如果程序看代码难以修复，需要你稳定复现才能修复的话，就可以问下程序这里处理的逻辑是咋样的，再自己去联想每一步出问题的可能性，再去尝试复现
3、再复现不出来的话，就找程序加日志，看看具体是在哪里有问题
4、复现的时候如果随机概率较高的话，可以拉程序过来坐，复现出来了直接现场给他看就好了