Chuckle

写点 cli 工具、浏览器插件、司内自用软件这种，一个仓库搞定，没有复杂多包依赖关系，代码总量最多几 w 的，那现在 AI 随便写，3 天平地起高楼，也不用 cr ，自己点一点看看功能对了就行。
但是吧，司内重业务的代码，一个页面背后几十个独立包，依赖关系错综复杂，代码加起来快百万，AI 就省省吧，上下文不够的，现在的渐进式加载就会漏东西，只能辅助人处理，比如找函数的链路，某个参数到底有没有用到之类的，明确一个小功能点去改，改完几百行代码 cr 下也行，至于全自动整个需求让 AI 改就算了，包是进雷区的。
每次改这种维护了好几年的项目，就和拆弹专家一样

和 spec 驱动差不多？

公司开的 cursor ，这个月已经 100 多刀了

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 后端，或者自己造、自己修（