Chuckle

@linhey #5 组件在依赖包里怎么办，发到生产包的总不能编译时注入 debug-data 属性吧

@Chuckle 只改 app 的构建，能做到给安装的依赖包产物里的组件加上 data-***的额外信息么

最近刚好也需要个从页面元素定位到源码的方案，为的也是 AI 能知道要改哪里、影响范围评估等等。
umi+qiankun 微前端，要改的东西都在独立包里，app 工程就是个页面入口，有时候套快 5 层包人找起来很麻烦，本地只跑 app 的 source map 也没用，安装的包产物都是服务器构建出来的，构建时在节点上注入大量信息也不太行，除非每个包都构建两个版本，构建生产 app 用的 和 开发时带信息的产物。
我现在做法是提取 dom 特征节点（还是有注入一些特殊属性的）、url 路径等元信息，克隆所有的几百个包到本地，让 AI 自己先暴力找，确实能找到，就是慢，也费 token 。优化的话，找到了就把信息落向量数据库里，类似 RAG 一样，特征信息变动还是少的，特征节点嵌套结构也稳定，下次找就快了，至少能快速找到对应包工程，再去定位具体代码。
不过，如果从 React 本身入手，模仿 React Scan 运行时注入应该更好？
另外 AI 写代码确实好用，就是测试起来太麻烦了，很难自闭环，业务链路长又大，e2e 测试的时候没数据，或者接口报错，AI 能自己 call 后端，或者自己造、自己修（

光结构化替换的话信息本身没变，对 AI 来说没区别，要是塞多无用中间代码，200k 上下文里就 1k 有效代码的话，信息多了，对 AI 才有点麻烦

nestjs ，司内内部服务、监控之类的都用它，业务还是用 java

哪有平白无故的便宜，就差库克做苹果 ai 都得买中转了

思路不错，大模型缺少的始终是信息，无论是提示词工程还是知识库，都是为了更好地给大模型提供信息，剩下的就是相信大模型本身的计算能力了，我也在考虑将信息抽象若干层，当然这个若干层不能是人定的，而是用模型学习计算出来的，形成一张可扩展的、有层次的信息地图。让大模型能够自由寻找。这有点像人脑的记忆结构，人脑也会压缩记忆信息，回想起来的时候，往往只是模模糊糊知道大概发生了什么，有什么人、做了什么事之类的，如果需要想起来，可能会去找照片、录像、日记等等。

有上下文可以回滚，不过就怕是命令删除、清空了文件，这种文件内容不在上下文的，或者上下文已经被压缩了，就寄了，话说现在这些 agent 为啥不考虑搞个备份机制，每次对现有文件的写操作都先把原文件备份到一个地方，这个地方设置个 50g 也够用了吧，新的替代旧的

clash x pro 无问题