Chuckle

vscode 族群 现在用 cursor

@linhey #8 看了，我们一个微前端 app 入口 50 多个依赖包，依赖包还有依赖包，业务组件都是封装抽离的，构建注入这套不现实，在看 bippy 动态注入的方案了

skill 本身就是个 tool ，也就是个 mcp 协议的东西

@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 都得买中转了