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

分公司，好公司不多。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

某鱼是指啥？我们后端主程找的一个教程，自己弄的，我这个是他充值账号下开的令牌，平台确实有一个叫智汇 API。

请问你是业务上的 QA 么？ 感觉过简历现在有点困难。

我个人体验下来，游戏测试的用例产出能达到这个精度的话，软件测试用例就更不用说了，我感觉精度更是高的吓人了。

1、目录结构上看起来挺像的，但是我比你的会全一些，我觉得主要你缺了一个评测模块，它的作用是，规范化这个管线模块中的内容，因为系统跟战斗是完全不同的 2 个管线，所以你要约束规范他们的产出路径。上游策划案就需要去约束（我这边会规范化以后去打分策划案，评分太低的不满足我要求的，我会直接跟主策划说，案子质量太低了这种）约束的关键词如：存在未定义的概念；案子之间存在相同名词，但是名词定义不统一；模糊的场景描述；注入此类的关键约束，约束完以后，然后再依赖按照咱自己的测试用例输出格式输出测试用例；另外我的 Skill 跟知识库是分开的，因为我的经验库（知识库）是全局的，Skill 是非全局的（局内，外围，流程，资源）这种细化的检查，模块的话，就是一级目录是模块名，二次目录就是规范化以后的策划案还有归档以后的原始稿；其他的大差不差，我后面计划还有置入自动化动作检查，但是需要有合适的视频解析的大模型；
2、我没用 dify，就是一个单纯的知识库性质的 md 文件，结构简单的，就是我上面描述的那种。我觉得自己通过依赖关系去自查就 OK 了，还有就是要有纠错逻辑，就是差异化的内容要消化在生产过程中；
3、目前非强制，但是设计框架要基本遵循，不然就太扯淡了，我们主策原话：你无法去约束每个人都按照你这样的设计结构去描述，我迄今为止没见过，那都这样说了，那按照设计框架去设计总说得过去吧？所以这边规范化策划案的流程中就是按照设计框架去解析他写的原始稿，通过走这个流程，强制把所有的策划的产出拉齐，这样就解决问题了。缺少的东西会体现出来，比如：我们设计动作的时候，会给对应匹配逻辑，资源池，动作标注的名称，衔接优化的逻辑，最终的表现解决预期这类的描述，这些都是抽象出来的。
直说的话，就是 AI 帮我们清晰数据，给一个最规范的内容。

嗯，是的。维护一个目录仓库，本地的知识库是我抽象出来的通用知识框架，产物就是一个 md 文件，但是里面会记录每次生成的 case 的依赖关系，差异化的知识清单，每次生成 case 的时候都通读知识清单里的内容。命中率挺高的。

目前我这边用起来成本比较低的方式：

git 托管知识库，规范化和评测策划案，编写测试用例，用例输出规范等相关 Skill 和知识库文件；

然后花点钱买 claudecode 的令牌（30 块左右吧，无限额度，偶尔会抽风那种无伤大雅）每次通过多个 Agent 并行执行去批量导入文件（主要是解决上下文限制问题）。

现在的方式就是，策划案有了就导入到这套流程里，然后就去忙别的，然后他自己帮我生成相应的处理路径，但是需要我 review 下关键信息：矛盾的点啊，有分歧的内容，需要我进一步确认，然后就这样生成相应的用例了。

目前我组搭建以后已经用起来了，系统相关的测试收效甚好（写的比系统测试的小伙伴写的好，非常全，个别难以搭建的测试场景，我让他们自己斟酌），战斗需要更详细的 Skill 要求跟依赖关系（我是 ACT 类的写实战斗游戏）效果也能达到个 7788，因为搭建半个月，内容量还没起来，但是只会越来越好。

这是我目前的方式，支持迭代也支持历史批量导入生成。

纵向比。

发了，但是不及预期，难受了。

今天最后一天班。 冲！~

出于好奇，无恶意，车载测试，是不是平时会有外出开车的测试习惯？

另外补充一句，长期稳定的项目，自动化回归应该是做的已经比较到位的程度，应该是可以支持回归工作的。

也能极大提升效率；

这种涉及性能优化重构内容的模块，就比较看测试负责人还有主程在业务上的抽象能力了。

能力不够的话，就是上面这种情况，性能优化的影响面，是资源变更还是系统结构优化上，还是代码效率上，这种就分层去搞呗，在哪个层面就涉及哪方面的变动，编入排期就好，资源变更就涉及需求侧了，就要排期，按影响面去排期测试就好，代码效率的话，那基本跟需求没关系，就是算法效率上的优化，理论上不会涉及需求内容，有明显提升，功能几乎不需要跑，如果是系统结构上的，那就是常说的重构了，重构就需要全量验证了，也是流入排期走流程去就好了。

这种测试负责人的角色就是要知道分层的意义，还有 case 设计意义，主程就是有能力 review 并且可以告知风险，协同测试负责人去要排期出来的，一线不就舒服了么？Bro。

感觉就是这样。

不得不说，策略得当，值得学习。

个人很有风险意识还有规划，点赞了。

直呼其名，或者叫一个字。

可以转产品了。