这周信息量很大，我挑了 7 个我觉得值得聊的话题。从工具链革命到 AI 安全漏洞，从浏览器大战到函数式编程的哲学争议，内容比较杂，慢慢看。
Vite Plus：前端工具链大一统
上周 GitHub Trending 上冒出一个项目：Vite Plus，来自 Vite 团队官方。简单说就是它把 Vite、Vitest、Oxlint、Oxfmt、Rolldown 这些工具全部整合到一个命令里，一个 vp 命令搞定开发、构建、测试、lint、格式化、依赖管理，甚至还能管 Node.js 版本。
基于 Rust，MIT 协议，3.3k 星。有 39 个贡献者，版本已经迭代到 v0.1.13 了，不是那种刚挂上去的项目。
我在想这东西出来之后，turborepo、nx 这些 monorepo 工具是不是该紧张了。因为 Vite Plus 本身就内置了缓存和依赖感知的任务调度，而且配置全集中在 vite.config.ts 里，不用分别维护 vitest.config、eslint.config、prettier.config 那一堆文件。
不过现在还比较早期，等生态再成熟一点，很可能会成为 Vite 用户的标准工具链。
引申的思考：这种一揽子方案，相对于之前的 Vite，地盘在扩大，想融入现有工程框架中的难度就会变大，且看后续如何发展吧。
被限制的 Mobile Safari
有个叫 pwa.gripe 的网站专门统计 Apple 对 Mobile Safari 的限制，最近更新到了 2026 年的数据。看完之后说实话挺窒息的。
跟 Android Chrome 一对比，Safari 不支持的东西一长串：Web Push 推送、后台同步、蓝牙 API、NFC、振动、面容检测、联系人选择器、网络信息……全部打叉。PWA 的快捷方式、文件处理、协议处理也是不支持的。
说白了 Apple 就是不想让 Web 应用在 iOS 上有原生应用的能力。这样你就得去 App Store 下载，苹果就能收 30%。
这个问题每年都有人骂，日本和欧盟已经立法强制苹果开放第三方浏览器引擎了。但对国内用户来说，短期内这个问题无解——你能选的只有 Safari 和微信内置浏览器，作为前端来讲这是好还是坏呢，真说不好。
版本控制要不要换赛道？
BitTorrent 的发明者 Bram Cohen 上周发了 Manyana，一个基于 CRDT 的版本控制系统原型。只有 470 行 Python 代码，是个概念验证，但思路很有意思。
Git 的合并机制大家都熟悉：三向合并，找到共同祖先，然后两边改了同一个地方就报冲突，停下来让你手动解决。Bram 的观点是这个过程太笨了。
Manyana 用 CRDT 做合并，核心思想是"合并永远不会失败"。两边改了同一个地方？自动标记出来给你看，但不阻塞你的工作。而且不用找共同祖先，两个状态直接合就行。冲突展示也更直观——分别告诉你左方删了什么、右方加了什么，而不是 Git 那种 <<<<<<< / >>>>>>> 的大段代码块。
当然现在还只是个原型，能不能真正替代 Git 是另一回事。但 AI 时代代码量暴增、频繁产生大量 WIP 提交，传统的合并机制确实开始吃力了。
OpenClaw 的安全问题：82 个 CVE
OpenClaw 最近在国内爆火了，191k 星，各大云平台都在推。但安全问题也跟着来了——截至 3 月初已经披露了 82 个 CVE 漏洞。CNCERT（国家互联网应急中心）都发了安全通告，建议政府系统限制使用。
HN 上有一篇标题很直接的文章叫"OpenClaw is a security nightmare dressed up as a daydream"，大意就是：看起来很美好，实际上安全基础很差。漏洞类型包括未授权数据泄露、系统控制权被接管、prompt 注入攻击等。
这个话题在国内技术圈讨论得挺激烈的，支持者说"开源就有人审，总会修好的"，反对者说"你不能拿用户的系统去试错"。我个人觉得短期内谨慎使用没问题，尤其是涉及敏感数据的生产环境。
看官们怎么看待这件事呢？非技术人员使用确实会遇到此类问题，国内大厂纷纷包装自己的 Claw 产品不断变得好用，但问题是“你信任（过）TA 么”？
Lightpanda：Agent 专用浏览器
这个项目用 Zig 语言从零写了一个无头浏览器，专门为 AI Agent 和自动化场景优化。没基于 Chromium，没基于 WebKit，完全自己写的渲染引擎。
据官方数据，比 Chrome Headless 快 11 倍，内存占用只有 1/9。兼容 Playwright API，所以现有代码迁移成本不高。
为什么不用 Puppeteer/Playwright？因为它们本质上是操控一个完整的 Chrome 实例，太重了。而 Lightpanda 从设计之初就只考虑"机器用浏览器"的场景——不需要渲染 UI，不需要支持所有 Web 标准，只需要能执行 JavaScript、能抓取页面内容就够了。
GitHub 上 5.9k 星，上周 Trending 榜上有名。目前主要应用场景是 AI Agent 浏览网页、爬虫、自动化测试。
"柯里化" 的争论
HN 上有篇文章"A Case Against Currying"，在 111 条评论里引发了一场函数式编程的哲学争论。
作者的核心论点：currying（柯里化，把多参数函数拆成一系列单参数函数）看起来很优雅，但实际用起来有各种不舒服。比如 map 的时候你得先 uncurry 才能匹配参数类型；返回多个值用元组但参数又用 curried 形式，风格不一致；每次部分应用都生成中间函数，有性能开销。
作者提倡用元组风格（(a, b, c) -> result）替代，配合占位符语法做部分应用。
底下评论吵成一团。Haskell 教徒们当然不同意，JavaScript/Python 程序员则表示"早就觉得 currying 是过度设计了"。作为前端开发者，我自己的感受是：在 React + TypeScript 的日常开发里，currying 确实没多少用武之地。但在库的设计层面（比如 RxJS 的 pipe），它的组合能力确实很强。
看官们自己实际工作中，是否关注过该问题？我猜答案是否，毕竟事情这么多，先满足需求，尽快发布产品才是核心。
如何让你的开源项目吸引 AI 贡献？
这篇文章标题就很抓眼球，点进去发现是一篇讽刺文（satire），但讽刺得太精准了，读起来特别有味道。
作者 Andrew Nesbitt 提了一些"建议"：
- 把 TypeScript 项目改成 JavaScript，因为 JS 项目收到的 AI PR 是 Python 的 3.8 倍
- 删掉类型注解和测试，给 AI 留"贡献机会"
- 提交 node_modules 到 Git，增加 AI 可修复的"问题面"
- 保持 200 个以上模糊的未解决 Issue
- 刻意用有 CVE 漏洞的旧版依赖
每一条都精准踩中了当前 AI 编程生态的荒谬之处。比如"good first issue"标签本来是给新人准备的，现在成了 AI Bot 的磁铁。再比如那些自动提 PR 修复"安全漏洞"的 AI，改完之后经常把依赖升到不兼容的版本，反而引入新问题。
这篇文章值得收藏，当成"AI 时代的开源生态观察"来看，全民 AI 时代，闹剧在不断上演，你方唱罢我登场。
原文标题《How to Attract AI Bots to Your Open Source Project》看官可以自行搜索。
视野决定终点
