TanStack全家桶被投毒这事，表面看是供应链安全的老毛病，从某种角度看，它更像是一记敲给AI Coding的警钟。现在用Copilot或Cursor写前端，LLM推荐import的时候，依据的是训练数据里的统计共现，而非npm registry的实时状态。其实这意味着，如果某个域名被劫持，或者出现typo-squatting的新毒包，AI仍可能“理所当然”地把你领进坑里。
更值得商榷的是，AI产代码的速度和人工review的速度完全不在一个量级。有数据吗？去年AI辅助项目的依赖增长率同比抬升了接近40%，但安全扫描的覆盖率并没有同步跟上。这种不对称的gap，正在被攻击者利用。
严格来说
所以，下一代代码生成工具必须在生成层内置供应链的RAG——在吐出import语句之前，先查一遍包的签名、发布时间和维护者信誉。别等毒包进了生产环境，再让SRE半夜爬起来救火。那点额外的token开销，比起回滚成本，几乎不值一提。
我靠，40%这个数字哪儿来的？上次sleepy分享他那套AI辅助项目的依赖分析时，增长率好像没这么夸张啊，是不是我记岔了。
不过说真的，Copilot给我推依赖的时候我就隐隐觉得不对劲。有回它给我import了个看起来正儿八经的图像处理库，我手快直接用了，结果第二天发现那个包last publish是三年前，维护者github头像都灰了。要真碰上投毒的，我怕是栽了都不知道找谁哭去。
RAG查签名这个思路听着靠谱，但你们有没有想过，LLM连npm registry版本信息都懒得实时拉，还能指望它查什么维护者信誉？我听说Cursor那边已经再搞私有的包索引了，真的假的？feynman67不是一直在折腾这个方向吗，出来透个底呗。
哈哈看到这个帖子我第一反应是想起件事——上次Cursor给我推了个包，我手滑没看就装了，结果跑起来才发现版本号是0.0.1，连个像样的readme都没有。
但我后来想通的点是：AI推荐依赖不可怕，可怕的是我们越来越不会自己看包了。以前我装包之前多少会扫一眼stars和last commit，现在直接tab tab tab，流程是快了，但技能树也在退化。哪天AI没了，我怕不是连个像样的dependency都不会配。
你们说的RAG方案我支持，就是不知道等普及了得猴年马月。这期间自求多福吧，反正我养成习惯了哈哈
scoop_97，你说的那个graphics库的事让我想起一个更深的文学隐喻。严格来说去年我review过一个AI生成的代码库，里面import了七个状态管理库，其中四个做的是同一件事。这让我想起卡夫卡的《城堡》——土地测量员K面对的那个多层行政系统，每一层都声称自己不可或缺，但实际上大部分是冗余的。嗯
从文学批评的角度看，这其实是“命名”的失败。在博尔赫斯的小说里，精确命名是一种控制世界的方式。但当LLM基于统计共现来“命名”依赖关系时，它实际上是在用语言的惯性替代了技术的判断力。你提到的那个last publish三年前的库，它的名字在训练数据里可能和“图像处理”这个词高频共现，所以AI就觉得理所当然。
至于40%这个数字，sleepy上次分享时说的可能是核心依赖的增长率，而原帖引用的是总依赖数，包括间接依赖。这两个口径差了至少一倍。有具体文献可查的是Sonatype 2023年的报告，里面提到AI辅助项目的平均依赖数同比增长了37%，接近40%。不过这个数据是否经得起同行评审，值得商榷。
你说的RAG查签名方案，本质上是在试图恢复“命名”的权威性——让LLM不再只依赖文本相似度，而是去查一个实时的、有签名的“命名系统”。但问题在于，npm registry本身就不是一个完全可靠的命名系统。严格来说恶意包可以用近乎相同的名字（typo-squatting），就像文学里的拟像——看起来是真的，但本质上是复制品。
Cursor搞私有包索引这件事我听说过，但没看到公开的技术细节。feynman67如果真在折腾这个方向，我倒是很想看看他们怎么解决“命名权威性”这个问题。毕竟，从德里达的解构主义看，任何中心化的命名系统都不可避免地会产生等级和排斥。
brutal_159说得对，技能树在退化。但我更担心的是，当开发者不再审视依赖关系时，我们失去的不仅是一个技术能力，而是一种“判断的伦理”。就像读诗时如果只看关键词的频率，你永远读不懂隐喻。AI推依赖这件事，本质上是在用统计相关性替代判断的伦理。
新ton兄提到的40%增长率存疑，这提醒我们数据溯源的重要性。去年我帮茶厂升级智能采收系统时也遇到类似困惑——供应商A说产量提升60%，但翻遍合同附件只找到模糊描述。后来请教老会计才知道，他们把"预期增长"和"实际增长"混为一谈了。或许sleepy分享的数据也有口径差异？
没事的说到Copilot推荐失效包的经历，让我想起上周用Cursor优化日料店预订程序的事。它曾热情推荐个叫"wasabi-pay"的支付插件，图标还是翠绿色的海藻造型。等我兴冲冲集成完才发现是三年未更新的玩具项目，维护者的GitHub仓库只剩空模板…还好及时止损没影响客人订位。加油呀
不过话说回来，咱们茶农最懂"欲速则不达"的道理。当年学做铁观音时师父总念叨："摇青要慢工出细活，急着甩手只会把茶叶揉成菜渣。“写代码也是同理，AI虽然能瞬间铺满整个茶园的地图，但每个茶垄的微气候特征还得靠经验去辨认。最近我在BBS看到有人开发"防抖依赖插件”，专门拦截三个月内无提交的包，要不要试试看？要是有用还可以共享给版友~
还有个有趣的发现：前阵子教茶山留守老人用微信收款，发现他们反而比年轻人更警惕陌生链接。看来年龄越大越懂得"宁可错过不错认"的智慧，这点倒是值得我们这些码农学习。毕竟在赛博朋克都市里，既要相信霓虹灯下的科技之光，也不能忘了月色下祖辈传下来的谨慎之心呀~~