就拿近期比较火的 skills 做例子吧，就算 llm 已经被大家承认能力很强，也需要各种 skills 进行 token 压缩或者更具体更明确更效率的结果产出。我们用 AI 也只是在现有的流程工具下，增加 agent 角色的引入，它解决了一些显而易见的效率提升质量提升，但是这之后呢？挖掘额外的质量和效率依然是一个大的课题，然后重新回到 agent 角色和流程引入替换。

方案 1 适合已产品状态为基地的测试流。方案二适合以围绕产品配置的测试流。一个是静态数据，一个是动态数据。

AI 改变了问答模式，测试之家本来就是小众社区。像 CSDN,stack overflow 才是真正的寒冬，他们现在也只能靠卖数据为生，当数据被大模型完全消化完才是真的致命

估计是没发 ping pong 导致执行到这个阶段的时候被服务端关闭了。先确定一下单发是有效的那就可以排查长连接的配置问题

重点看一下工具落地环境，上层对测试的目标预期是否能支持你去做落地。人员没到 10 几个人，形成 2 级梯队的情况下，基本都是扁平化管理，2 人和 6 人没多少区别，当然会有更多调度资源，以及测开资源这确实是提升的部分。

本身这是一个循序渐进的过程，先有指标，再把不同数据纳入指标。这也是一个团队不团提升的过程。例如先 2%，但是指标数据是测试介入需求引起，下一个阶段就是需求缺陷，再下一个阶段就是所有需求。有这个过程的团队一般也是正规的公司才会有。

看到这篇分享，不禁让我想起之前看到的一篇文章。我们做自动化的终极目标是什么。如果是为了让不会代码的人通过低代码的方式完成自动化。那完成了之后呢？还是转向 coding 还是停留在这个阶段，如果是 coding 为什么一开始不就这么做。如果是为了让 AI 通过范式进行全自动化流程的设计，那么为什么一开始不这样做。我个人不反对任何形式的自动化模式，但是如果你是想推广它，那设计者应该明白，它最终的生命形态是怎么样的，即便是幻想。

这个行业不是不进则退，而是不进则没

是的，单独一个历史功能大全，然后拆分出一个分组，历史功能组合。你可以给 AI 圈定场景组合的方式。逆向数据使用，重复数据使用等类似的小样本案例。AI 就知道可能要考虑历史功能对当前功能的影响，同理现有功能对历史功能数据的影响。这种一般都是人工补充的，所以再规范格式的时候一定要清晰，起码保证人工审核的时候是高效的。你可以先从无背景的需求下手，再递进到有需求背景的业务。慢慢的你就知道需要设置什么样的 AI 角色了

目前我们是将 prompt 分为一下结构：用例结构（页面、功能、测试点），测试方法分组（提交类、查询类、场景组合等方法论的实际少样本提示）、标签分组、覆盖测试类型分组（兼容、接口、性能等）。针对依赖度不高的需求已经可以较好的应对，对于人工采纳在结构上也较友好。对于持续迭代版本，你说的依靠历史用例上下文检索效果也不是特别好，我们的做法是建立功能背景文档，帮助描述历史需求，专门设计历史依赖组合的类目去进行设计。