我大概明白了， 你的诉求应该是自然语言转接口自动化测试用例。 这个需要你事先把接口录入给大模型，让他生成访问的代码。 或者有接口的详细调用文档。 要 AI 去写代码，还是必须要有知识库的。 这样你就可以用自然语言的测试用例转成自动化测试代码了。

没看懂， 你这是要做什么？

手动测试的时候怎么造的数据， 就让 AI 怎么造

当前项目中所有的代码和文档，默认都会 embedding 并且保存到向量数据库中。 所以大模型每次运行其实都会去参考已有的文档和代码，这样它就能明白， 你说的用例步骤，其实在其他 case 里写过类似的并进行参考。 这也是为什么我一直说 知识库 是 AI 编程最重要的东西。 那什么是知识库？ 在你工程里一切的代码和文档都可以是知识库。

各种专项测试的工作流其实很有价值的，我现在性能测试和高可用测试都用 Agent 来执行

首先用例和需求肯定是要积累成一些文档的， 然后生成 case 的方法论和产品测试要点也要有。 再然后你可以搜一下 harness 的设计方法论， 这个方法论是能让 Agent 稳定高效运行的方法论，按这个思路去设计。如果你觉得 harness 太耗时或者太废 token， 那你也可以单纯遵循 “渐进式披露” 原则， 先写一个生成 case 的 skill 出来试试看。 你可以搜一下我提到的这几个设计方法。

想要 AI 效果好，知识库必须要好好积累。 这个知识库不仅仅是业务功能文档，还有设计测试用例的方法论和你的产品的测试特点。 比如在我们的产品里，如果模型广场里新增了模型，或者动了模型的逻辑。 那需要遍历到整个产品里所有跟模型有关的功能点。 所以在我的知识库里，专门有个文档是记录所有与模型相关的功能点，并在 skill 里告诉大模型，在这种情况下一定要遍历这里的所有模型相关的功能点。 而如果是涉及到前端的逻辑，知识库里也写好了各个模块的前端交互的流程，并且在 skill 里写了工作流， 就是识别到跟前端有关的操作。 要反复向用户确定是否有 figma 的交互稿，如果没有，设计到的输入框是否有字符数的限制等问题。

同一个模型， 不同的人用的效果天差地别，就在于使用的 “人” 是否有耐心，愿意去学习如何跟 AI 打交道。

开发人员用 AI 编写代码带来的最大的问题就是质量会更差。起码现阶段是这样的，很多开发同学还不得的用 Harness 的理念去设计 Agent，所以导致出错的概率比较大。所以呢，我们为了解决这个问题需要利用 AI 来去快速地生成大量的自动化测试用例。我们现在公有云的门禁的运行时间，就需要跑 5 个小时了。这是大量的自动化测试用例积累的结果。基本上这个门禁能跑下来。产品的质量问题就不会很大了。

有些时候，一些不起眼的地方，提升起效率来也挺夸张的。你比如说测试用例的编写，用传统的方式去写测试用例，花的时间很长。我们假设要编写 100 条测试用例。如果说要编写的相对比较详细一些，那么这 100 条测试用例的编写工作可能就会耗费一天时间，甚至更长。但用 AI 来去写的话，可能就是 10 分钟之内的事情。即便说你没有很好的知识库，让它自动探索出很好的用例。但我们就用人力来去编写测试点，然后让 AI 去生成更详细的步骤。这也是效率的一个很大的提升。

我比较赞同这位兄弟的看法，我们目前也是一使用 AI 快速搭建接口和 UI 的自动化。同时使用 AI 来完成各种专项，比如容灾测试、性能测试。还有一些其他的提升效率的比较散的地方。比如利用 AI 的总结能力去快速地理解需求文档，利用 AI 的能力快速完成一个调研行动。很多时候，来了一个任务没有什么特别好的思路，问问 AI 可能很快就能够把这个任务完成。我这里的更多的呢是在接到一些新的需求的时候，里面会涉及到一些我不懂的知识。尤其我在做这种技术型产品的时候，经常会遇到这种问题。用 AI 呢，我就能很快地去学习了解这方面的知识，并且拿到一个很好的解决方案来进行测试。 总结一下，就是多利用 AI 的能力来寻找方案。

AI 定位控件的时候，可以开缓存， 缓存存在本地。 只要定位过一次， 下一次就不用 AI 了。 也可以先用 css 定位再用 AI 兜底。 至于用 AI 去编写 case 的成本。 可以用差一点的模型， 或者精简一下 skill。

就写 sql 执行就好了， AI 是用来写 case 和定位控件的

多谢提醒

不好意思， 刚看到。 如果有很完善的设计稿， 其实是可以测试左移， 在没提前就写好 case 的，因为我们的控件定位现在都是用自然语言描述的了。 但这太要求设计稿的完善和开发团队严格按照设计稿开发的规范。

数据初始化？ 是什么数据哈，我没太 get 到你的点

是需要写脚本， 只不过我都是让 AI 写：

我没用 workbuddy， 我是用的 midsence， 基于多模态大模型的 UI 自动化识别方案。 底层用的 playwright，而 playwright 用 CDP 跟浏览器交互，目前用下来，稳定性还挺不错的。 多模态大模型通过截图来找到控件的坐标， 然后通过控件坐标，与 playwright 交互找到真正的控件对象。 然后通过 palywright 调用 cdp 操作浏览器。

整套东西用下来， AI 定位控件的正确率还是很高的，我用的是千问的多模态模型。 而 midsence 仍然是用 playwright 的，所以即便 AI 定位失败了， 我们还可以回退到传统的 css 定位。

你说的系统测试是？

我之前是占了入行早的便宜， 我 16 年初入的 AI 领域。 那时候行业不要求必须懂 AI， 毕竟整个行业里都没多少知道 AI 是什么东西的。 但其实现在也不是每个地方都要求懂 AI 才能进来。 因为现在懂 AI 的人仍然是少的。 如果每个公司都要求岗位必须有 AI 经验， 那就很难找到人了。 我们这里照片也不是把有 AI 相关经验当做硬性要求的。

元素如果极其 ID 稳定，甚至可以不用任何编写代码的框架了。 就老式的录制回放就行。

我写了一个探测的 Agent， 动态启动浏览器探测， 然后生成 CSS 和 AI 的定位方式。 优先 CSS，如果 CSS 定位失败，就降级到 AI 定位。 然后还有一个测试 Agent，测试不通过就打回去重新定位。 现在正确率还可以。

但我没有试过，我没有做过移动端的测试。

字节的 midsence 我看文档上是支持全平台的。

都是 AI 来写，我专门写了一个 skill，是一个有三个 agent 的 skill，专门去帮我探索 UI 界面并编写脚本。

续期有 8 折优惠， 你要是接受不了 200 块钱， 加我微信：ycwdaaaa，我给你搞个优惠券