一些看法

大模型已抢占各类互联网大会、社区博客的头条，测试领域也已经有非常多的讨论。

我认为现处于探索>>实际落地的阶段，主要因为以下几个原因：

1. 无法控制大模型的"涌现"能力：主流的技术路线 LangChain + RAG + Agent 可以快速上手并看到一些"效果"。但是，目前只看到了 demo 级别的成功，因为预期结果不够稳定 甚至无法预知，进而无法大规模落地。
2. RAG 的数据质量：RAG 其实与大模型无关，主要是向量数据库的 topk 问题，他很大程度取决于训练数据结构、分词策略、embedding model、re-rank 策略等等，需要大量的实践经验。
3. 代码生成有点鸡肋：代码生成的难点在于输入参数与业务的融合以及断言逻辑，与传统的单测/接口用例生成效果相比，大模型生成并没有很大的提升。各大厂商的 IDE 助手并没有很惊艳的感觉。
4. GPT4 比开源模型更加强大：由于数据安全的考虑，在方案落地时需要选用开源本地大模型，避免数据泄露。而诸多的本地大模型的体验效果比 GPT4 还是会有较大差距（Qwen2 据说很不错，还没有试用）
5. 大模型微调需要消耗大量的资源，以及有较高的技术门槛。

1. 代理的作用

在不侵入原有代码的前提下实现代码增强，比如说在目标对象的某个方法执行前后可以增加一些自定义的操作。

2. 静态代理

静态代理中，我们对目标对象的每个方法的增强都是手动完成的，这种代理方式需要代理对象和目标对象实现一样的接口。

从 JVM 层面来说， 静态代理在编译时就将接口、实现类、代理类这些都变成了一个个实际的 class 文件。

优点：可以在不修改目标对象的前提下扩展目标对象的功能。

缺点：

1. 冗余。由于代理对象要实现与目标对象一致的接口，会产生过多的代理类。
2. 不易维护。一旦接口增加方法，目标对象与代理对象都要进行修改。

SPI 全称 Service Provider Interface，是 Java 提供的一套用来被第三方实现或者扩展的 API，它可以用来启用框架扩展和替换组件。

整体机制如上图，Java SPI 实际上是“基于接口的编程＋策略模式＋配置文件”组合实现的动态加载机制。