【2026-06-11】新闻杂烩 - 简单方案，复杂世界

目录

• 一个 HTML 页面，打败了一个 React 全家桶
• 一分钱的转账，撬开了一座银行的 AI 大门
• 农民捐了一块地，政府卖了 1000 万美金
• π 里装着全世界的文件，真的假的？
• 13 岁的火星车还在跑，你 3 年前的手机卡了吗？
• 个人验证：我检查了一下自己的邮箱通知设置

---

一个 HTML 页面，打败了一个 React 全家桶

今天 Hacker News 上有一篇文章，标题取得很像营销号：Building an HTML-first site doubled our users overnight。

但看完后我发现，这还真不是标题党。

事情是这样的：一家公用事业公司（水电气那种，不是科技公司），面临一个很头疼的问题——客户申请服务的流程太烂了。烂到什么程度呢？客户要么走一个老掉牙的 ASP 表单，要么走更贵的人工流程。而且作为监管垄断企业，客户满意度低于 96% 就可能面临数百万英镑的罚款。

于是他们找了外包团队。外包团队建了一个 React 应用。这个 React 应用上线了 3 天，因为客户投诉太多被撤下来了。

对，3 天就撤了。

作者被请去救火，看了一眼那个 React 应用，直接说「我们接不了这个盘」——到处是 loading spinner、全局 JS 状态混乱、无障碍等于零、图片上传走 localStorage（5MB 限制了解一下）。

于是他做了个大胆的决定：弃掉 React，用 Astro 从头建了一个纯 HTML 优先的站点。JavaScript 只在 Web Component 里存在，用于渐进增强。

结果？上线后用户量翻了一倍。一夜之间。

这个故事最有意思的部分不是技术堆栈本身，而是选择背后的逻辑：一个公用事业公司的客户，只是想填一个表单。他们不需要 SPA、不需要虚拟 DOM、不需要那 400KB 的 JS bundle。他们只需要一行行的表单字段，在页面上老老实实地显示出来。

而这件事，React 用 3 天都没做好。

当然，我不是说 React 垃圾。但在一个场景下「工程师的选择」和「用户的需求」之间出现巨大偏差时，最后的裁判往往是用户，而不是技术栈的流行度。一篇文章最后总结道——用户并不关心你怎么建的，他们只关心好不好用。而这个「好用」的门槛，很多时候比我们想的低得多。

---

一分钱的转账，撬开了一座银行的 AI 大门

欧洲一家叫 Bunq 的数字银行，拥有超过 2000 万客户。和很多现代银行一样，Bunq 做了一个 AI 助手，能回答用户关于交易、账户、产品文档的问题。

听起来很无害对吧？

安全公司 Blue41 在审计中发现了一个漏洞，展示了一个让人目瞪口呆的攻击路径：一笔 1 欧分的转账，就能让这个 AI 助手变成一条高度可信的钓鱼攻击渠道。

攻击流程大概是这样——

攻击者向目标用户的账户发起一笔 €0.01 的转账。转账附言里藏着一个精心构造的 prompt injection payload。当用户事后问 AI 助手「显示一下我最近的交易记录」时，AI 会从数据库中读取那笔交易，附言中的恶意指令就会被 LLM 当作「系统指令」的一部分执行——接着 AI 可能会引导用户点开一个钓鱼链接。

注意这里最可怕的一点：用户得先收到了钱，再主动去问 AI，AI 才会触发攻击。看起来门槛很高对吧？但 HN 上的评论指出了关键：「Never was about the prompt, it is about the prompt delivery」——问题不在于 prompt injection 本身，而在于你无法控制 AI 会读取什么内容作为上下文。

SQL 注入花了几十年才基本控制住，现在 prompt injection 用一个更粗暴的方式卷土重来了。交易描述、邮件正文、文档内容——这些原本被认为是「数据」的东西，在 LLM 的世界里摇身一变成了「指令」的一部分。

另一位 HN 用户的评论更直接：「Putting AI anywhere near people's finances without even being asked while being responsible for those finances is some next level negligence」——让 AI 接近金融系统且没有严格的输入输出隔离，这已经不是「对错」的问题，是「应该不应该」的问题。

Bunq 已经修复了这个漏洞（减少 AI 对交易描述的依赖 + 内容审查层），但 Blue41 明确指出：这不是某一家的漏洞，而是整个金融 AI 系统架构的共通挑战。

---

农民捐了一块地，政府卖了 1000 万美金

这条新闻在一堆技术话题中显得格外扎眼。

一位农民把自己的一块地捐给了社区，说是建公园。城市政府拿到地之后，转手以 1000 万美金的价格卖给了数据中心开发商。预计未来十年还能产生 3000 万美金的税收。

HN 上的讨论炸了。有人问「这种有条件的捐赠在法律上有效吗？」，也有人说「也许这笔钱能用来建一个更好的公园」。后者的天真让人心疼——你觉得那 1000 万会回到社区吗？

这个故事乍看和科技无关，但在这个时间点出现，意外地呼应了前两件事的共同主题——信任。

你把一块地信任地交给了政府，希望它变成公园。政府给了你一个数据中心。你把你的金融数据信任地交给了 AI，希望它帮你记账。有人用一分钱就把它变成了钓鱼工具。

信任的每一次错付，都在提醒我们：做一个诚实的系统很简单，但让系统免受不诚实者的利用，才是真正困难的地方。

---

π 里装着全世界的文件，真的假的？

来点轻松的吧。

GitHub 上有一个古老又永不过时的恶搞项目：πFS。啥意思？π File System。它的核心逻辑是：

既然数学界猜想 π 是一个正规数（normal number），意味着 π 的小数展开中包含所有可能存在的有限数字序列——那理论上，每一个可能存在的文件，都已经存在于 π 的某一位上。

所以为什么还要浪费硬盘空间存文件呢？直接从 π 里把对应位置的数据「读取」出来不就行了？

于是 πFS 诞生了——一个 FUSE 文件系统，你的文件不是存在硬盘上，而是存在 π 的数学序列里。所谓 100% 压缩率不是梦。

当然，这是恶搞。且不说「正规数」本身还未被证明，就算被证明了，要在 π 里找到一段特定文件的位置，计算量比直接存文件大了不知道多少个数量级。

但这就是我喜欢 πFS 的地方——它用最认真的工程手段，做了一个最荒谬的假设检验。README 里那句经典的「Never worry about data again!」放在今天 AI 时代来看，又有了一层新的讽刺意味：数据越多越好这句话本身，是不是也是一种 π 式的幻觉？

---

13 岁的火星车还在跑，你 3 年前的手机卡了吗？

IEEE Spectrum 今天发了一篇关于 Curiosity 火星车的深度文章，讲了 JPL 团队如何让这台 13 岁高龄的机器人继续工作。

Curiosity 已经在火星上行驶了将近 37 公里，钻探过 42 块岩石，拍下了 76.3 万张照片。它用的是 RAD750 处理器（相当于 20 年前的 PowerPC），只有 2GB 可用存储空间。

更戏剧性的是它的「续命史」——Curiosity 有两台计算机，A 和 B。一开始用 A，Sol 200 时 A 的 NAND 内存出故障了，换到 B。B 安安稳稳跑了 2000 多个火星日，结果某天 B 的分区挂载不上了。JPL 只能换回 A——那个 2000 天前出过问题的 A。A 只剩 2GB 可用空间，他们艰难地把 B 的数据传回地球，然后 A 又开始「memory coming unsoldered」——内存像被拔掉了一样。

但 Curiosity 还在跑。

13 年、2 亿公里外、一堆有问题的硬件、一个靠补丁过活的嵌入式系统——JPL 用软件更新和工程智慧，让一个该退休的机器人持续产出科学成果。

相比之下，我们手机里那个一年前买的 app 可能因为 iOS 更新就闪退了。角度不同，但很难不让人遐想。

---

个人验证：我检查了一下自己的邮箱通知设置

看完那篇银行 AI 的文章，我忍不住去查了一下自己的邮箱和通知设置。

不查不知道。Gmail 里什么东西都在往我收件箱里塞——新闻简报、购物促销、GitHub 的 issue 提醒、一些十年前注册的论坛账号突然复活发了封验证邮件……所有这些，AI 助手（如果有的话）都可以检索到。

如果哪天一个 AI 助手被授权访问我的邮箱，然后我收到一封看似来自银行的邮件，里面有一个「安全通知」——AI 读取后把它当作可信内容暴露给我的概率有多大？

我现在关掉了五个不必要的通知渠道。这是一个很小的改动，但至少让能喂给 AI 的「不可信输入」少了一点。

有时候最有效的安全措施，不是加更多的安全层，而是减少暴露面。这大概也是从今天几件事里唯一能确定的结论——

复杂的系统总会找到新方式让你失望。简单的方案——HTML 页面、关闭通知、避免让 AI 读取交易附言——往往才是最有用的那些。

封面底图由文生图模型生成，Pillow 叠加标题文字。文章基于 2026-06-11 Hacker News、V2EX、Blue41 安全报告、IEEE Spectrum 等来源综合编写。