1.触发节点:5 种触发条件：用户明确反馈（正确/错误）、高频重复（3 次/7 天）、周期复盘（每日/每周）、复杂任务验收
2.信息采集:排除问候语和闲聊，只保留含"点击/滑动/验证/文案/入口"等关键词的有效内容
3.自我反思:评估输出是否匹配需求、错误是偶发还是底层逻辑缺失、成功经验能否抽象为通用规则（人工 +AI）
4.规则抽象:生成规则 ID、模式、解决方案、适用场景、执行标准，并通过通用性/可执行性/无冲突/可追溯性四维验证
5.规则更新：写入分层记忆，短期 → 中期 → 长期：验证 ≥5 次升中期，≥10 次升长期，30 天未使用自动清理
5.持续迭代:下次任务应用更新后的规则

目前也是自己摸索在用，根据这些限定收成的 case 放到 midscene 中运行，跑通/跑不通需反馈 skill，再次更新后维护

如果是需求文档转 UI 自动化用例，目前我们是 3 步策略
1.需求文档拆解生成测试用例，规定好测试目标 - 步骤路径（父子结构的知识库文档）- 测试步骤 + 预期结果（预期结果一定要准确）
2.禅道 bug 转用例，需要禅道提交 skill，提交过程中结合需求文档和知识库，自动转换为 UI 自动化所需格式，提交 bug 的时候就规定好模版
3.人工测试过程中遍历测试用例，修改不合规、不完整和错误不明确的预期结果
4.整合所有结果，尝试转换 UI 自动化用例

目前我们也刚开始使用 midscene 做 UI 自动化，识别不准已现在运行的历史结果来看，还是通用限制 + 专项用例的提示词描述不清导致的
1.需要非常明确的路径、测试步骤、预期结果，这块目前是 2 方面优化（1）需求文档让产品提供更细致（2）根据需求拆解测试用例，人工执行完毕后根据需求维护用例后再执行
2.每次 midscene 执行完毕后使用 skill 总结，当前这条用例为什么可以跑通，积累成功经验，随后将跑不通的描述和用例自动总结到错题本，使用 2 个总结方式进行日常积累
3.adb 坐标点击到目标页面这个步骤感觉比较好用，等到目标界面后再进行 AI 识别，成功率会更高一些
当前我们也是在初步尝试，大家有更好的方法，辛苦指点

wiki 搭建个人知识库，全量索引不会有幻觉问题，大模型清洗需求文档，跟产品研发补全需求，搭配 LLM+ 提示词限制拆解需求文档生成测试用例，基本用例能达到九成可复用，其次 wiki+work buddy 或者 tare 可以做到自动迭代知识库和差异化记录，应该会更好一些

明白了，我的结构和差异化处理残缺，我再调整一下，太感谢了

对于
1.需求文档的类型，我们是那单个功能迭代的，比如我们新增了一个已活跃分为货币的报名方案，他所涉及的测试点有活跃分报名 - 存档 - 复活 - 结算 - 再来一局 - 强制踢出房间整个流程，整个会有一个功能介绍，有些功能是往期已有的，他就会简写成一句话，新增的会比较详细的描述
我从需求中总结到的这些测试点，拿报名这部分内容举例 1.报名费用还涉及金币报名、参赛券报名、金币不足、条件不足、新增活跃分不足等情况兼容，我从我的关键词调用的时候他不是光拿报名费这一个关键词，而是我需求中多个关键词一起去知识库内进行检索，可能能检测到报名费用这块检索 tab5-10，也可能被其他的关键词所污染就会造成丢失，而我如果拆分了需求，他又不能很好的按一个个的拆分点依次去查询
2.如果是跳多个知识库的话，就比如我的复活模块，我先需要知道需求中有复活这个内容，然后手动勾选复活相关得知识库，可能能很好地调用，但是这样的知识库分的太细了，没办法根据一个工作流来达到自动识别、调用的情况

辛苦问个问题，我现在有个困扰，我的需求文档有很多的测试点，直接全量查询 01.目录结构（找到比如报名、开赛模块），随后我让大模型再去找第二个知识库中报名的具体内容的时候，我发现他是拿一堆关键词去知识库里匹配，相当于我拿着一本书（测试点总结）去和另一本书（知识库）在匹配相似度，会导致数据丢失很大一部分，这块是怎么处理的呀，用模糊查询，类似 msql 数据库，先搭建格外完整的体系这样嘛

根据禅道 buglist 拆出来测试点，老员工的个人总结，产品那残留需求，都可以进行整合的

我的目前还好一些，大概能到 70%，希望在我知识库搭建完后能到 80 以上，我目前是先把需求让大模型清洗一遍，然后原版需求 + 清洗完后的需求分别交给 2 个 LLM，分别进行测试点总结和需求拆解，第三个 LLM 根据原需求和测试点总结进行用例生成，感觉会更精准一些