目前游戏测试这块儿，AI 辅助测试用例个人认为做的已经相当好了，主要是流程问题，还有有效执行的问题，我觉得 AI 没啥毛病，比人做的好，目前来看。

自动化的话，AI 的自生成脚本，loop 方案还在探索，我个人感觉也不远了，主要是方法论实现上很有底层支持。

AI 游戏测试任重道远啊，没软件测试发展那么好。

现在互联网泡沫太多了，上一代的债，下一代来还了。

分公司，好公司不多。

加班时间短，不加班的游戏公司凤毛麟角。

互联网都挺费命的，不仅是游戏，我已经接近半年的 996 了，加的有点懵。最近想找个时间调休休息下 。

够呛了，我还想转出去的，你居然还想转来。

果然是围城么？哈哈。国内游戏 qa 很野蛮生长，不太适合入行，软测好些。相对下。

所有的游戏实际都是互通的，只是业务设计上存在复杂度的设计。

一个测试用例只写测试点跟耍流氓没区别吧。

没有优点，全是缺点，这本质上就跟程序不写注释，不去分层，产品设计只说概念不含细节有啥区别啊。

真就只顾自己爽了。哈哈。

哈哈哈，AI 应该会礼貌的回一句，毕竟现在的 AI 基本都是应答式的。

都转 Agent 就好了，但是目前我觉得人事（HR）才是目前人才市场流通中最关键也是阻碍性最大的一个挑战。

1、问题一的话，你这边应该是没去做差异化（增量迭代）的流程，导致你这边每次手动识别的时候，会存在你所描述的内容，（增量迭代）时，你需要做的是版本控制，然后去按照要求的内容做差异化内容的确认（会导出差异化内容）给你输出，然后你去从中调整这块的内容，也是可以迭代优化的 Skill，随着每次的 Skill 优化，就会越来越准，大概的样子是这样的。
当你做到这一步以后，再看下；这个是差异化的内容，你需要 review 之后再生成，有问题即时调整，调整的逻辑可以通用化就加入到 Skill；

2、对于跳知识库这个，我还是我上面那个观点，感觉你是较多的知识库，这个我不清楚你知识库咋分的，以及知识库存在的都是什么数据，按照我这边之所以去找依赖关系，是因为存依赖关系，结构简单，跳转清晰，这样 Agent 找的时候目的明确，跳转的时候 Skill 也需要去约束；大概这个样子，我的知识库结构： 你只需要关注我这边的结构就好。