同问，我目前主要用来跑跑探索测试，目前我遇到的难点是稳定可靠和可维护性

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

1、我们有在搞 SDD，但是推行很艰难，因为链条太长，好在公司和领导大力支持，包括大模型这些资源预算 100W
2、测试用例持续化管理这块，我们是做的用例管理系统，直接接入 AI，AI 生成的用例在 AI 用例管理模块，人工复核直接进入用例库，人工复核这块也支持导出 excel 在本地复核后导入。同时用例系统针对每个用例都要标识是否 AI，用户 AI 使用率统计分析

我公司也是在搞 sdd，但是模型有限 token，根本不够用，都是要么自己出钱买或者薅免费的，你们使用这个 sdd 感觉如何

那这个平台还需要提供 agent 可以访问的 mcp 或者 skill，因为在用例生成的时候，不可能避免的一个问题就是：随着产品的迭代，新的需求会和老需求改动会存在一些冲突的情况，对于 AI 生成测试用例，老用例其实也是一个上下文，甚至老用例还需要更新。

差不多的思路。markdown 管理测试点，做好各种工作流中的维护

1、针对某个需求，后续有了新的需求了，那之前的老用例会归档，重新生成新的用例，新老用例共用同一个用例编码，形成历史轨迹，为了需求追溯时候，也很快能找到需求什么时候完成，当时的需求场景是怎样的
2、mcp skill 都会有提供，甚至我们把用例库直接训练转换，然后写入向量库作物知识库，可以用从用例知识中让 AI 反推出这个功能当前的业务逻辑和限制等，甚至能通用例库的知识，来给系统画像