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

分公司，好公司不多。

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

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

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

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

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

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

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

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

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

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

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

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

内容不够聚焦，我先按照你说的内容问下我的疑惑哈：
1、你的需求文档有很多的测试点，这个需求文档是什么类型的？如果这个类型有分类的话，理论上就不会出现全量查询的情况；
2、在知识库中的设计中，可以多个，也可以单个，像我这种知识库结构只存差异化（增量迭代）的依赖关系还有编辑状态的内容，量是不大的，我就是单个的，如果是多个的话，只需要结合步骤 1 中对应的让 Skill 按照不同的需求去跳转该知识库即可，知识库的结构基本是一致的；
以上的表现带来得就是，不会出现巨量的全量更新去匹配的情况，并且 Agent 并行执行时，上下文的依赖也会解的比较小，几乎很少出现满载的情况，再不行，就只能分批写入了；

我觉得中间过程数据丢失，很大程度是你在需求文档的输出格式规范上没有做好约束，比如：我们现在需求文档，我会让他按照不同的类别输出（评审策划案）逻辑点，然后逻辑点扩散测试点，然后 review 之后产生一个规范化后（打分之后）的策划案，然后你就能通过这个需求，得到一份儿精炼过内容的一份儿规范化后的策划案（基本不会丢内容的），这样你在导入原始的策划案（prd）之后，实际上 Skill 还有知识库这些基本都是按照分治的思路一致在扩展去读你的需求，最后根据已有的内容产出一份儿还算 OK（基本不漏内容）的文件出来。