正常的逻辑是，通过 BCD 找到各个浏览器在各个版本中高区分度的特征，然后进行检测，通过与已知的兼容性表格进行相似的匹配（如余弦相似度），可以锁定真实环境的浏览器和版本。
但是，在我高估AI智力的时候，我选择了另外的一个方向。这让我举步维艰。
我一开始的想法是通过AI（lingma QwenCode） 根据BCD的兼容性报告快速开发通用的，全覆盖的兼容性检测器。类似 Modernizr,Feature.js 等项目，但基于AI,可以更全面自动的同步BCD的更新更新检测器。。随后通过随机特性的兼容性，包括区分度（用于锁定类型和版本）和低区分度（增加检测代码复杂性和伪装难度），实现对浏览器版本的识别或伪装的识破。
当然想法很美好，结局很惨。由于进度越落后预期，并似乎进行了一个瓶颈。这里我记录一些有价值的思路和信息。
- 我让AI 解析BCD的数据，提供接口，根据当前浏览器版本
- 随机指定数量、类型的的特性
- 输出这部分特性的可用和不可用基本已知信息
- 我让AI 生成一个检测页面，对随机的特性进行检测，与已知信息进行比对，得到F1分数
- 预期可用实际不可用
- 预期可用实际不可用
- 预期不可用实际可用
- 预期不可用实际不可用
- F1 分数
- 预期不可用实际可用和预期可用实际不可用的检测错误特性列表
- 可缓存当前测试的特性和指定缓存的特性进行测试
- 设计了一个AI工作流
- 大循环:更新特性缓存，得到这批特性的检测错误列表
- 小循环:逐一开发修复检测错误列表的兼容性测试方法
由上3部分组成的闭环，理论上是可以通过时间，把所有的特性兼容性测试方法开发出来，在通过切换浏览器和版本完善整个项目。当然这是理论上，实际遇到的非常棘手的情况是：
- BCD 兼容性路径解析
- 起初，我任务可以通过某种模式识别出路径的规律，通过不同的规律解析到不同的但通用的检测方法上，但实际是这非常困难。我起初认为AI大量知识可以帮我找到规律，事实是不行。AI擅长总结归纳，创新并不是他的能力。也就是说，需要先把每个方法写出来，让它来重构才是正确的方式。但在这里就是先有鸡还是先有蛋的问题。
- 兼容性检测方法的开发
- 在情况1失败后，我尝试逐步推进检测方法的开发。但是呢，实际的情况是，AI 几乎没错只能解决一个兼容性方法的开发，而且遇到需要特殊设计的检测方法，往往就会自暴自弃。这点可能和大模型的注意力有关，当多个兼容性问题一起开发时，互相干扰，结果就是全军覆没，而对于需要特殊设计的方法。我猜测在大模型训练时为了控制大小，可能被剪枝了，因为这是个低概率情况。
- AI智力远低于预期
- 基于上面2点，根本问题时AI的智力没有达到我的要求。当然可能是我用的模型不够聪明，或者使用方法还不够高明。
后续：
- 我可能会先停止这个文件夹的内容
- 或者通过压缩特性数量继续推动这个计划
- 更换模型和开发方法
- 目前已经新开了文件夹，通过Trae的solo模型，使用最开始提的思路推进，希望会有好的结果。