Chuckle 最近的时间轴更新
Chuckle

Chuckle

🏢  家外蹲 / 前台
V2EX 第 604103 号会员,加入于 2022-11-30 18:49:14 +08:00
今日活跃度排名 22733
根据 Chuckle 的设置,主题列表只有在你登录之后才可查看
二手交易 相关的信息,包括已关闭的交易,不会被隐藏
Chuckle 最近回复了
1 天前
回复了 Comyn 创建的主题 Java ai 编程的情况在你们使用什么 IDE
vscode 族群 现在用 cursor
@linhey #8 看了,我们一个微前端 app 入口 50 多个依赖包,依赖包还有依赖包,业务组件都是封装抽离的,构建注入这套不现实,在看 bippy 动态注入的方案了
3 天前
回复了 287854442 创建的主题 程序员 MCP 是不是已经死了?没人再提这个了
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
5 天前
回复了 x1024m 创建的主题 程序员 怪不得这么多中转站
哪有平白无故的便宜,就差库克做苹果 ai 都得买中转了
6 天前
回复了 blueeon 创建的主题 程序员 为什么放弃了 RAG? RAG 的六大难题
思路不错,大模型缺少的始终是信息,无论是提示词工程还是知识库,都是为了更好地给大模型提供信息,剩下的就是相信大模型本身的计算能力了,我也在考虑将信息抽象若干层,当然这个若干层不能是人定的,而是用模型学习计算出来的,形成一张可扩展的、有层次的信息地图。让大模型能够自由寻找。这有点像人脑的记忆结构,人脑也会压缩记忆信息,回想起来的时候,往往只是模模糊糊知道大概发生了什么,有什么人、做了什么事之类的,如果需要想起来,可能会去找照片、录像、日记等等。
关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   5512 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 16ms · UTC 07:22 · PVG 15:22 · LAX 00:22 · JFK 03:22
♥ Do have faith in what you're doing.