这周新进来的工具，很多都在干同一件事：把 AI 编程的过去和未来都搭一遍脚手架。

有些工具是为了跑得更快；有些工具是为了记住跑过哪里。
这周的新增偏向后者不是 CLI 工具突然变多了，
是 AI 编程的上下文管理开始有了自己的工具链。

本周一句话总结

AI 编程从"写"进入了"观察与编排"的阶段这周入库的工具，超过一半在帮你理解已经发生的事。

本周新增工具速览

New Formulae

New Casks

值得留意的几个方向

这一节不求全，
只挑 3 个 值得停下来看的点。

agentsview：AI 编程的"回放键"终于来了

用 Claude Code、CursorCodex 写了几个月代码你记得上周三用 agent 干了什么吗？

大概率不记得。这不是记性问题，是 AI 编程产生了一种新的历史：不是 git log，不是 IDE 历史记录，而是"我跟 agent 说过什么、agent 做了什么"。这段历史一直散落在各工具的本地缓存里，没有人帮你整理。

agentsview 做的就是这件事。它把 Claude Code、Codex、Gemini、Copilot、Cursor 等 20 个 agent 的会话历史统一读进来，全文索引，可以按项目、按工具、按时间筛，支持 token 用量和费用报表，号称比同类工具快 80-220 倍。

真正让我觉得有意思的是它的定位：local-first，SQLite，不联网，不注册账号。它没有试图成为一个 SaaS，而是选择把你的历史还给你自己。这在满地"云端同步"的工具里显得有点反常，但可能是对的。

gascity：多 Agent 编排，从玩具变成水管

以前协调多个 AI agent 同时工作，基本靠自己写 shell 脚本拼凑。gascity 想干的事情是把这层"水管"标准化用一个 city.toml 声明你想跑哪些 agent、用什么运行时（tmux、子进程、Kubernetes），剩下的路由、状态同步、健康监控交给它。

底层依赖 beads（自家的任务跟踪）、dolt（可版本控制的数据库）、tmux、jq，整个项目用 Go 写，CLI 叫 gc。设计上走"原语优先"不提供高层抽象，提供足够小的积木让你自己组。

这个工具现在刚进 Homebrew，安装量还是两位数。但它试图解决的问题多 agent 编排的可复现性和可观测性是真实存在的。随着 agent 场景从单机变成集群，这类基础设施迟早会有人需要。

fallow：代码库的"体检报告"

TypeScript/Javascript 项目用久了之后，总会有一些"可能没人用了但谁也不敢删"的代码。fallow 的核心主张是：静态分析告诉你"什么可以删"，运行时数据告诉你"什么安全删"。

npx fallow dead-code 扫出没用到的文件和导出；npx fallow dupes 找重复逻辑；npx fallow health 给复杂度热力图。静态能力开源免费，运行时那层是付费的。

有趣的是它支持 MCP，可以接入 Claude Code 或 Cursor 的 agent 流程这意味着它不只是一个跑完就算的 CLI，而是可以嵌进 AI 编程的工作循环里。

趋势小结：Agent 编程开始需要"配套设施"了

这周的三个 formulae/casks 指向同一件事

agentsview 管历史，gascity 管协作，fallow 管代码质量。
这不是工具的堆叠，是 AI 编程从"我让 agent 写了一些代码"变成了"我需要管理 agent 做的事情"的信号。

以前 CLI 工具大量涌现是因为开发者在搭工作台；现在 agent 工具大量涌现，是因为 agent 本身开始需要一张工作台。

一点个人感受

gascity 和 agentsview 在同一周进入 Homebrew，我不确定是巧合还是某种时机。

agentsview 我可能会用之前一直想找个办法回顾和 Claude Code 的对话历史，虽然现在有 /cost 和各种日志，但搜索还是很麻烦。local-first 的设计打消了我最大的顾虑。

gascity 和 github-copilot-app 都在 agent 编排这个方向，但路子完全不同：一个是工程师手搓的 Go CLI，一个是 GitHub 官方出的桌面应用。我对后者更好奇，尤其是它声称能"跨 agent 并行管理多个工作流"，但目前公开的细节还很少。

fallow 倒是让我想到了一个问题：AI agent 越来越擅长写代码之后，谁来负责清理 agent 留下的技术债？也许就是 fallow 这类工具。

结语

有些工具是锤子，看见钉子就用。
这周进来的工具更像是量尺帮你看清楚已经发生了什么，才好决定下一步。

观察工具和使用工具，是两种不同的习惯。
但也许，后者越来越需要前者打底。

工具在变，但看懂工具在干什么，始终是你自己的事。

我现在coding的主力工具是VSCode+Claude，之前一直使用Cline。

在Cline中使用Claude，享受GUI的乐趣。

随着时间的推移，发生了很多事情：

• Claude审查变得更加严苛
• Cline中使用Claude，频繁报错 ...

然后，我开始逐渐适应在CLI工具中使用Claude。

自从开始使用AI Coding，总感觉设备的内存不够用，一直维持在80%以上的使用率。

日常基本就是，

• Chrome，非常吃内存
• iTerm，可接受
• VSCode，跟Chrome有得一拼

Chrome 重度使用，一时半会没有找到合适的平替，想迁移过去有点困难。

VSCode 基于Electron开发，多开几个tab，就能赶上Chrome了。

VSCode中，一些场景下会使用VI模式，例如：Code Review。

古法编程，看情况用，加上macOS上，触控板太好用了，没有很迫切转Vim。但，现在开始非常想使用nvim替代vscode，即装13又可节省内存。

况且，都使用AI Coding了，Review 和思考的时间居多，GUI没那么有趣了。

配置后的样子，

iTerm 配置

tmux 配置

# 安装 tmux brew install tmux # 配置 .tmux git clone --single-branch https://github.com/gpakosz/.tmux.git "/path/to/oh-my-tmux" mkdir -p ~/.config/tmux ln -s /path/to/oh-my-tmux/.tmux.conf ~/.config/tmux/tmux.conf cp /path/to/oh-my-tmux/.tmux.conf.local ~/.config/tmux/tmux.conf.local 

配置完成后，执行：

tmux source-file ~/.config/tmux/tmux.conf 

这个视频挺不错

nvim 配置

略

Ref

• razeencheng/.tmux: Oh My Tmux! 我的tmux配置，以及相关设置。
• 我在 MacOS 上的完美 ghostty + tmux + nvim 配置 : r/Ghostty
• (5 封私信) macOS Tmux安装及配置（复制粘贴，保存工作区） - 知乎
• tmux安装及使用（macos） - pd_liu - 博客园
• .tmux/README.md at master gpakosz/.tmux
• 【iTerm2 实用技巧】解决两大顽疾：历史记录看不全 & 鼠标滚轮失灵作为 Mac 上的终端利器，iTerm2 的强大 - 掘金
• Installing tmux/tmux Wiki
• Tmux 使用教程 - 阮一峰的网络日志

• V2EX 部署了一个新的测试服 https://edge.v2ex.com
• 登录后可以在 https://edge.v2ex.com/settings/passkey 添加和管理 Passkey。
• 如果是通过 Solana 登录的用户，添加或删除 Passkey 时需要钱包签名。
• 如果是密码或 Google 登录的用户，添加或删除 Passkey 时需要输入当前 V2EX 密码。如果 Google 登录账号从未设置过 V2EX 密码，可以通过 forgot 设置。
• https://edge.v2ex.com/signin 登录页面会在当前浏览器支持 Passkey 时显示 Passkey 登录按钮。

早上好！以下为昨日摘要：

• 持币人数：5,199
• 10k+HODL用户数：1,426
• Solana创建用户数：2,578
• 绑定SOL地址用户数：9,460
• AMM当前持有$V2EX量：52.19M
• 当日收盘价格：

SOL - $85.16 PUMP - $0.0017 V2EX - $0.0018

聚合价格走势

AMM持仓与价格趋势

当天在线人数变化

社区规模变化

运营数据概览

TOP50 变动信息

TG 机器人订阅: 点我订阅

原始图表与数据存放于: 点我查看

此报告由 V2EX Info 提供数据, 由 Newsletter Report Bot 自动生成。

此报告仅供参考，不构成任何投资建议。投资有风险，入市需谨慎。

今天给朋友们带来一款新上线的产品落飞电台 https://fm.chen-di.com 主要的应用场景是为了满足一些需要声音陪伴的用户，在做家务的时候，在学习的时候，又或你写代码的时候，提供一个打开即可满足当前场景的音乐，省去了自己挑选歌单和没有平台会员的烦恼。

为了满足多种场景的需求，落飞电台目前内置了五大场景音乐，编程、学习、锻炼、睡眠、游戏。我们利用 AI 大模型精心为每个场景提供了丰富的曲库，曲库会随着用户的体验进行不定时的更新。

目前经过多个版本的迭代，产品已经拥有较完整的功能：

• 产品的风格走的是沉浸的 LOFI 风格，每个场景内置了多个动态视频，用户可以根据喜好进行切换。
• 对全局快捷键的支持，支持方向键切换场景视频、F 键的全屏模式切换、空格键的音频暂停/播放。
• 内置中文/英语两种语言。
• 支持查看下一首歌及提供过去 5 首歌的历史记录。

产品本着无广告、打开即用的设计哲学为用户提供较为沉浸的音乐体验，我们会长期提供在功能和音乐上的更新。若在使用过程中如遇到问题，可以通过邮箱进行反馈。

反馈邮箱：[email protected]

早上好！以下为昨日摘要：

• 持币人数：5,188
• 10k+HODL用户数：1,415
• Solana创建用户数：2,569
• 绑定SOL地址用户数：9,447
• AMM当前持有$V2EX量：52.23M
• 当日收盘价格：

SOL - $86.52 PUMP - $0.0017 V2EX - $0.0018

聚合价格走势

AMM持仓与价格趋势

当天在线人数变化

社区规模变化

运营数据概览

TOP50 变动信息

TG 机器人订阅: 点我订阅

原始图表与数据存放于: 点我查看

此报告由 V2EX Info 提供数据, 由 Newsletter Report Bot 自动生成。

此报告仅供参考，不构成任何投资建议。投资有风险，入市需谨慎。

每次看到 90 年代游戏的截图，我就在想，现在是 2026 年，或许个人电脑已经有足够的算力实时渲染当年的素材了。如果有哪个游戏能够用这种方式做 remake，肯定会很有趣。

早上好！以下为昨日摘要：

• 持币人数：5,180
• 10k+HODL用户数：1,403
• Solana创建用户数：2,560
• 绑定SOL地址用户数：9,430
• AMM当前持有$V2EX量：52.41M
• 当日收盘价格：

SOL - $89.18 PUMP - $0.0018 V2EX - $0.0019

聚合价格走势

AMM持仓与价格趋势

当天在线人数变化

社区规模变化

运营数据概览

TOP50 变动信息

TG 机器人订阅: 点我订阅

原始图表与数据存放于: 点我查看

此报告由 V2EX Info 提供数据, 由 Newsletter Report Bot 自动生成。

此报告仅供参考，不构成任何投资建议。投资有风险，入市需谨慎。

The Kalyazin RT-64, a massive 200 ft tall radio telescope in Western Russia.

Built in 1974 during the Soviet era it was originally designed to communicate with deep-space missions to Mars and Venus.

via https://x.com/luusssso/status/2055327077277040746

via https://x.com/ClassicII_MrMac/status/2055316101987188989

[1] I moved my digital stack to Europe

I moved my digital stack to Europe 945 票 557 评论 by monokai_nl

来源: monokai.com HN讨论 标签: Privacy, Cloud, Europe, Self-host

摘要:

荷兰开发者 Monokai 将自己的数字栈从美国服务全面迁移至欧洲基础设施, 历时数月完成. 迁移清单涵盖: Google Analytics 换 Matomo 自托管, Google Workspace 换 Proton Mail (瑞士), 1Password 换 Proton Pass, DigitalOcean 换 Scaleway (巴黎, 碳排放最低), AWS S3 换 Scaleway S3 (rclone 同步耗时一周), Backblaze 换 OVHcloud (冷存储更便宜). 核心动机是数据主权不因政策变化、收购或高管情绪失去对工具的访问权, 基于价值观而非便利选择基础设施.

背景注释:

• Digital Sovereignty: 个人或组织对自身数据的控制权, 包括知道数据存储位置、自主选择数据管辖权.
• Matomo: 开源网站分析平台, 可自托管, GDPR 合规, 是 Google Analytics 的隐私替代方案.
• Proton Mail: 瑞士端到端加密邮件服务, 商业模式围绕隐私而非广告.
• Scaleway: 法国云服务商 (Free Telecom 子公司), S3 兼容对象存储, 巴黎数据中心碳排放系数较低.
• OVHcloud: 欧洲最大云服务商, 法国公司, 提供裸机服务器和云存储.

HN 热评:

1. TrackerFF (2026-05-13 12:18): 过去几天我在参加一个与我的行业 (intel) 相关的会议 (虽然是通过 Teams), 基本上是初创公司和老牌公司向闭门受众展示产品. 我注意到一件事: 在欧洲各地, 没有一家公司用 Google Workspace, 全是 Microsoft 365 或本地部署. 这和四五年前我在美国工作时的情形完全不同. 当时 Google Workspace 无处不在.

2. IAmFledge (2026-05-13 12:47): 我从今年 1 月就开始了这个迁移过程, 现在至少在产品托管方面已经完全迁移到欧洲基础设施了.

3. schnitzelstoat (2026-05-13 11:58): 虽然我同意美国确实越来越不可预测, 但我不认为欧盟在这方面好多少, 特别是在数字领域, 有些方面甚至更差.

4. pear01 (2026-05-13 13:51): 多元化是好事, 但人们真的不应该把欧洲描绘成什么避难所. 欧洲政府 (进而公司) 仍然会与美国合作. 到了那一天, 当美国真的想要访问欧洲公司持有的数据时, US CLOUD Act 之类的东西会让这个梦想破灭.

5. Worf (2026-05-13 17:37): 虽然欧盟目前提供比美国更多的隐私保护, 但最佳解决方案是使用没有任何人可以实施有意义控制的服务, 尽可能只有用户自己自托管.

[2] Screenshots of Old Desktop OSes

Screenshots of Old Desktop OSes 700 票 385 评论 by freques

来源: typewritten.org HN讨论 标签: History, Desktop OS, GUI, Nostalgia

摘要:

typewritten.org 网站收集了大量经典 Unix 和 PC 图形桌面的历史截图, 年代横跨 1980 年代至 1990 年代初. 涵盖 SunTools (Sun 工作站)、GEM Desktop (IBM PC)、Acorn Archimedes (Arthur OS)、Amiga (Digi-Paint)、NeXTSTEP 等操作系统的屏幕截图. 这些图片记录了 GUI 发展史上的关键节点, 是计算机历史爱好者的珍贵视觉档案.

背景注释:

• GEM Desktop: Digital Research International (DRI) 开发的图形桌面环境, 曾是 IBM PC 上的主流 GUI, 后因苹果诉讼败诉而衰落.
• SunTools: Sun Microsystems 的工作站桌面环境, 1980 年代 Unix 工作站标配.
• Acorn Archimedes: ARM 架构个人电脑, 1987 年发布, 运行 Arthur OS, 是 ARM 架构的早期桌面尝试.
• NeXTSTEP: NeXT 公司的工作站操作系统, 乔布斯离开苹果后创立, 后来成为 macOS/iOS 的基础.

HN 热评:

1. Quitschquat (2026-05-12 19:42): 你看这些老的 Unix GUI 可能会觉得它们比起现在差太多了, 但实际上在当时它们也就是那样烂而已.

2. hermitcrab (2026-05-12 10:01): 隐形滚动条是持续烦恼的来源. 有时候要花好几次才能把一个窗口移到位, 因为各种可点击的东西没有可见边界. 让人抓狂.

3. vessenes (2026-05-12 11:42): 一次精彩的怀旧之旅, 而且非常实用. 但有一个大遗漏从 1990 年代初开始, 我们应该能看到一些 Linux 桌面了, 但我从头到尾都没看到 1995 年左右我开始用 Linux 时的任何截图.

4. giamma (2026-05-12 07:03): 没有提到 GeOS! 8 位机的 GEOS 在当时令人难以置信地超前.

[3] Needle: We Distilled Gemini Tool Calling into a 26M Model

Needle: We Distilled Gemini Tool Calling into a 26M Model 668 票 188 评论 by cactus-compute

来源: github.com HN讨论 标签: AI, LLM, Tool Calling, Open Source

摘要:

Cactus 团队将 Gemini 的工具调用能力蒸馏进一个 2600 万参数的小模型 Needle. 核心发现是: 如果模型依赖外部知识源, transformer 中的 MLP 层可以被完全移除. 该模型可调用天气 API、数据库查询等工具, 任何人都可以在本地运行.

背景注释:

• Needle: Cactus 团队开源的轻量级工具调用模型, 2600 万参数, 从 Gemini 蒸馏而来.
• MLP (Multi-Layer Perceptron): 多层感知机, 神经网络中的全连接层. 研究发现如果模型依赖外部知识, MLP 可被完全移除.
• Tool Calling: LLM 调用外部工具 (如 API、数据库) 的能力, 是 Agent 系统的核心组件.
• Cactus Compute: 致力于小而强 AI 模型的开源团队.

HN 热评:

1. nl (2026-05-13 00:21): Do you have any examples or data on the discriminatory power of the model for tool use? The examples are things like "What is the weather in San Francisco", where you are only passed the city name, but in real world the argument would be messier.

2. ilaksh (2026-05-12 19:24): Hmm.. this might make it feasible to build something like a command line program where you can optionally just specify the arguments in natural language.

3. simonw (2026-05-12 19:42): Suggestion: publish a live demo of the "needle playground". It's small enough that it should be pretty cheap to run on a little VPS somewhere!

4. kgeist (2026-05-13 00:36): Experiments at Cactus showed that MLPs can be completely dropped from transformer networks, as long as the model relies on external knowledge source. This is a big finding.

[4] Learning Software Architecture

Learning Software Architecture 590 票 116 评论 by matklad

来源: matklad.github.io HN讨论 标签: Software Architecture, Engineering, Learning

摘要:

IntelliJ Rust 核心开发者 matklad 分享软件架构学习心得. 核心观点: 软件设计靠实践而非读书; Conway's Law 揭示架构是社交问题的镜像; 代码不如架构重要, 架构不如社交问题重要. 推荐关注边界、测试、ZeroMQ 指南等资源.

背景注释:

• matklad: Alexey Klay, IntelliJ Rust 和 rust-analyzer 的核心开发者, 现为 Ferrous Systems 工作.
• Conway's Law: Mel Conway 1968 年提出的定律软件系统的架构往往反映了构建该系统的组织的沟通结构.
• A Philosophy of Software Design: John Ousterhout 的软件设计经典, 强调模块化、信息隐藏、复杂性问题.
• Architecture of Open Source Applications (AOSA): 开源应用架构系列书籍, 每章由项目维护者撰写, 免费在线阅读.

HN 热评:

1. CSMastermind (2026-05-12 13:02): I'll give you the cheat sheet: Good design is a single idea pervaded throughout. More generally, your goal should be to minimize surprise. If your system allows it, people will do it.

2. mpweiher (2026-05-12 11:23): The recommendations are often very good, for example Ousterhout's A Philosophy of Software Design, but seem to be on software development in general, not actually software architecture in particular.

3. deepsun (2026-05-12 22:11): The best way to learn architecture is to: 1. Maintain a large enough project. Not create, but support. 2. Do it for at least couple or few projects. If project is too small, any architecture will do.

4. miki123211 (2026-05-12 11:41): I really recommend "Architecture of Open Source Applications." It's a book series where you learn architecture by example, with each chapter written by a maintainer of that project.

[5] Leaving GitHub for Forgejo

Leaving GitHub for Forgejo 572 票 296 评论 by jorijn

来源: jorijn.com HN讨论 标签: GitHub, Forgejo, Open Source, Self-host

摘要:

荷兰开发者 Jorijn 因 GitHub Copilot 争议、Actions 高价和微软信誉问题, 将个人项目从 GitHub 迁移至自托管 Forgejo (Gitea 分支). 她用 Hetzner 服务器搭建, 记录了完整迁移步骤, 引发开发者关于平台依赖和开源道德的广泛讨论.

背景注释:

• Forgejo: Gitea 的社区分支, 由前 Gitea 核心团队创办, 强调独立性和社区所有权.
• GitHub Copilot: 微软 GitHub 的 AI 代码补全工具, 争议在于训练数据来自开源代码, 且曾被指控替代而非辅助开发者.
• Gitea: 轻量级自托管 Git 服务, 用 Go 编写, 类似 GitHub.
• Hetzner: 德国云服务商, 以高性价比裸机服务器著称, 常被开源社区用于自托管项目.
• Federation (ActivityPub): 去中心化社交协议, Forgejo 正在整合, 目标是让不同实例可以互相通信.

HN 热评:

1. giancarlostoro (2026-05-13 13:10): Everyone seems to be leaving GitHub, and forgetting the entire spirit of what git is in my eyes. Git was always meant to be decentralized, the problem is we put all our eggs in one basket with GitHub.

2. xvilka (2026-05-13 18:35): The real game changer would be completed Federation support. This is why I am donating both Forgejo and Codeberg and urge everyone doing the same.

3. sc68cal (2026-05-13 13:38): I have also moved my git repositories to a self-hosted NUC. I have not yet bothered with a HTTP frontend to share it with the world, mostly because I didn't need one yet.

4. delf (2026-05-13 13:19): In "What I gave up" section author mentions his social graph. It is possible to take your social graph and collaboration history using GitHub API or tools like git-sizer.

[6] The Emacsification of Software

The Emacsification of Software 285 票 185 评论 by sockpuppet

来源: sockpuppet.org HN讨论 标签: Emacs, Software Design, IDE, History

摘要:

Thomas Ptacek (sockpuppet) 指出当代软件开发正在走向"Emacs 化"软件变得越来越大、越来越个性化、越来越难以离开. 得益于 LLMs, 每个人都可以制作个人软件, 这是对"软件工程"主流叙事的深刻纠正, 也是 1960 年代家庭计算愿景的回归.

背景注释:

• Emacs: 1970 年代诞生的可扩展文本编辑器, 以其极大的可定制性和 LISP 扩展语言著称, 被戏称为"伪装成编辑器的操作系统".
• Thomas Ptacek (sockpuppet): 安全研究员, Matasano Security (现 NCC Group) 创始人.
• Personal Software: 1960 年代计算先驱们设想的每个用户都自己编写程序的世界, 后被商业软件产业取代.
• LLMs and Personal Software: 2025-2026 年间, AI 工具使非程序员也能编写定制软件, 被视为个人软件愿景的回归.

HN 热评:

1. tptacek (2026-05-13 23:00): Software that today is overwhelmingly prepackaged and usually professional, which I think at this point the nerds should reclaim: Podcast apps, Email clients, CRM systems.

2. dang (2026-05-13 20:11): This is so exactly right and I've been saying it to whoever will put up with me... (and now am embarrassed I have no link to show for it. oh well).

3. shaokind (2026-05-13 18:13): I've absolutely engaged in making personal software thanks to the age of LLMs. But to behonest, my time using Emacs didn't teach me to make software, it taught me to make text.

4. SoftTalker (2026-05-13 18:18): "Personal Software" i.e. programs that one writes for oneself, was the original vision of home computing back in the 1960s. The PC wasn't the point.

早上好！以下为昨日摘要：

• 持币人数：5,163
• 10k+HODL用户数：1,387
• Solana创建用户数：2,544
• 绑定SOL地址用户数：9,409
• AMM当前持有$V2EX量：52.41M
• 当日收盘价格：

SOL - $92.13 PUMP - $0.0019 V2EX - $0.0019

聚合价格走势

AMM持仓与价格趋势

当天在线人数变化

社区规模变化

运营数据概览

TOP50 变动信息

TG 机器人订阅: 点我订阅

原始图表与数据存放于: 点我查看

此报告由 V2EX Info 提供数据, 由 Newsletter Report Bot 自动生成。

此报告仅供参考，不构成任何投资建议。投资有风险，入市需谨慎。

[1] Starship V3

Starship V3 215 票 300 评论 by fprog

来源: spacex.com HN讨论 标签: SpaceX, Rocket, 航天

摘要:

SpaceX 于 5 月 12 日发布了星舰 V3 公告, 披露了第三代星舰与超重助推器的重大技术升级. 超重 V3 助推器将栅格翼从 4 个减少至 3 个、面积扩大 50%, 并将栅格翼收进燃料箱内部以抵御热分级火焰; 燃料传输管重新设计后尺寸相当于一枚 Falcon 9 第一级, 支持 33 台 Raptor 引擎同时点火; 尾部热防护与引擎排布大幅简化. 星舰 V3 同样进行了大量重新设计, 取消了前两代的独立热防护瓦设计, 改用更耐热的创新材料; 有效载荷部署系统得到优化, 可在轨道上精确释放多颗卫星. 此次飞行仍为亚轨道, 用于测试有效载荷部署、助推器在沿海水域定点回收以及星舰在印度洋受控溅落.

背景注释:

• Super Heavy: 星舰的低地轨道助推器, 高约 70 米, 使用 33 台 Raptor 液氧甲烷引擎, SpaceX 计划用发射塔机械臂 Mechazilla 回收.
• Raptor: SpaceX 自研的全流量分级燃烧循环液氧甲烷引擎, 目前迭代至第三代 Raptor 3.
• Mechazilla: SpaceX 为超重助推器回收而设计的发射塔机械臂系统.
• TWR (推重比): 引擎推力与火箭重量的比值, 是决定火箭能否起飞的关键参数.

HN 热评:

1. NitpickLawyer (2 小时前): V3 是星舰家族首次重大升级, 包含大量来自之前测试的改进. V3 引擎是量产版引擎的首次迭代, 集成了大量传感器和辅助系统. 除了推力提升, 他们还简化了生产工艺、将许多组件移至引擎内部. TWR (推重比) 也提升到了约 1.6, 升空时会明显更快离开塔架. 此次飞行仍为亚轨道, 用于测试有效载荷部署、助推器在沿海水域定点回收以及星舰在印度洋溅落.

2. frostinator (1 小时前): "助推器在沿海水域定点回收" 这个措辞有意思. 他们在说要测试助推器伞降减速后由船舶回收, 而不是用 Mechazilla 机械臂. 如果这意味着他们测试了两条回收路线, 那说明 SpaceX 对两条路线都在推进.

[2] Deterministic Fully-Static Whole-Binary Translation Without Heuristics

Deterministic Fully-Static Whole-Binary Translation Without Heuristics 157 票 34 评论 by matt_d

来源: arxiv.org HN讨论 标签: Security, Binary Translation, Compiler, 学术

摘要:

加州大学欧文分校团队发布了 Elevator, 首个完全静态的 x86-64 到 AArch64 二进制翻译器. 与依赖启发式方法或运行时回退的传统模拟器不同, Elevator 预先穷举每个字节的所有可能解释并生成独立翻译路径, 保证确定性且输出可直接签名. 代价是 .text 段体积膨胀约 50 倍. 核心价值在于为航空、医疗设备等受监管行业提供了绕过 JIT 禁区的可能认证代码与运行代码完全一致. 在 SPECint 2006 上的评测显示性能已达到或超越 QEMU 用户态 JIT 模拟水平.

背景注释:

• Elevator: 加州大学欧文分校团队发布的完全静态二进制翻译器, 将 x86-64 翻译为 AArch64, 代价是 .text 段体积膨胀约 50 倍.
• QEMU: 主流开源二进制模拟器, 采用 JIT 运行时编译方式, 广泛应用于跨架构虚拟化.
• SPECint 2006: 标准化整数计算性能评测套件, 广泛用于 CPU 和编译器对比.
• AArch64: ARM 架构的 64 位版本, 也称 ARM64, 广泛用于移动设备和服务器.

HN 热评:

1. linkregister (1 小时前): .text 段体积膨胀 50 倍是一个巨大代价, 但换取完全确定性翻译是值得的. 在很多场景下相比模拟器的性能优势会抵消体积增加的不便. 多线程和异常处理并非不可能支持, 只是不在本项目范围内. 很好奇下一步是否会用启发式方法来剪枝可能性空间以减小体积 (代价是破坏确定性保证, 但让二进制可移植性变得实用).

2. fizza_pizza (2 小时前): 认证角度是最吸引我的部分. 受监管行业 (航空、医疗设备) 往往正因为 JIT 的这个原因无法使用它运行代码必须与认证代码完全一致. 能生成可签名二进制的静态翻译在这里是真正的突破, 尽管代码膨胀是一个代价.

[3] My graduation cap runs Rust

My graduation cap runs Rust 149 票 47 评论 by ericswpark

来源: ericswpark.com HN讨论 标签: Rust, Embedded, Hardware, 趣味

摘要:

作者用 Rust 在 ATtiny85 微控制器上编写了一套毕业帽 LED 控制程序 gradcap-rs, 在普渡大学 (Purdue University) 毕业典礼前完成了这个脑洞项目. 帽底嵌有 48 颗 WS2812B 可编程 RGB LED, 用干簧管检测流苏移动后触发灯光效果, 全部代码用 Rust 编写并已开源. 虽然他最终决定不会戴着它上, 但这枚毕业帽足以让全场最亮了.

背景注释:

• ATtiny85: Atmel (现 Microchip) 推出的 8 位 AVR 微控制器, 8KB Flash, Digispark 是基于它的极小开发板, 内置 USB.
• WS2812B: 可寻址 RGB LED, 通过单线数字协议控制, 单芯片集成了控制电路和 RGB 三色 LED, 常被称为 NeoPixel.
• Reed Switch: 干簧管, 磁控开关, 用于检测流苏移动触发灯光.
• gradcap-rs: 作者为毕业帽编写的 Rust 嵌入式程序, 已开源.

HN 热评:

1. katzgrau (7 小时前): 为了这个 blog 标题创意用 Rust 完全值得, 做得漂亮. (作者说如果用 Arduino 库或换块板子会容易得多, 但他实在太执着于这个标题了)

2. rustybolt (2 小时前): 啊, 美国果然是这样的. 94 美元租一套毕业帽和毕业袍...

3. skrebber (20 分钟前): 有点惊讶于这种毕业仪式感的存在, 我一直以为"毕业帽"只是电影里的东西. 在一个如此强调个人主义的国家里, 这种集体仪式感有点格格不入.

[4] European governments: 3.000 tracking sites, 1.000 phpMyAdmins, and 99% poorly encrypted email

European governments: 3.000 tracking sites, 1.000 phpMyAdmins, and 99% poorly encrypted email 131 票 48 评论 by aequitas

来源: internetcleanup.foundation HN讨论 标签: Security, Privacy, EU, 政府

摘要:

互联网清理基金会发布 SecurityBaseline.eu, 对欧洲 32 国政府网站安全状况进行日常监测并公开结果. 平台每天重建 1,827 张地图, 覆盖 67,000 个地方政府约 200,000 个域名. 三项核心发现: 3,000 个政府网站非法使用追踪 Cookie、超 1,000 个 phpMyAdmin 管理界面公开可访问、99% 的政府邮件加密不合格. 该项目已运作超过十年, 荷兰政府已将其纳入政策, 此次将监测范围扩展至全欧.

背景注释:

• SecurityBaseline.eu: 互联网清理基金会发布的政府网站安全基线监测平台, 提供各国各地区网络安全可视化地图, 共 21 项安全指标, 每日更新.
• DNSSEC (DNS Security Extensions): DNS 安全扩展协议, 通过数字签名验证 DNS 响应未被篡改, 启用可防止 DNS 欺骗攻击.
• phpMyAdmin: 基于 Web 的 MySQL/MariaDB 数据库管理界面, 如公开暴露且无认证保护是严重安全隐患.
• Chaos Computer Club (CCC): 德国著名黑客组织, 欧洲最大、历史最悠久的黑客俱乐部之一, 被称为"欧洲最大的黑客俱乐部".

HN 热评:

1. elric (0 分钟前): 因为一个域名没有启用 DNSSEC 就把它标成红色似乎有点过分了. 更好的做法是加上邮件托管商信息我看的那几个都是 outlook.com, 这比没有 DNSSEC 是一个大得多的隐私和安全风险.

2. lionkor (44 分钟前): 这可能是因为在德国, 任何真正的渗透测试除非获得了明确付费授权都是高度违法的 (§ 202c StGB, § 202a StGB 等)? 我很乐意帮一些德国政府网站做渗透测试, 但光是使用非标准浏览器访问它们就已经可能被视为违反各种黑客法律了.

3. zelphirkalt (33 分钟前): 在德国, 人们的心态完全错了. 他们不感激发现漏洞的人, 而只关心"这是谁的责任"和 CYA 策略. 没有人想成为有过失的人或暴露自己的能力不足. 也许需要让俄罗斯再黑进来几次, 丢了脸之后才会有人动起来.

[5] "I applied to be pope" - Losing grip on reality while using ChatGPT

"I applied to be pope" - Losing grip on reality while using ChatGPT 27 票 18 评论 by hansmayer

来源: thestandard.com.hk HN讨论 标签: AI, Mental Health, ChatGPT, 新闻

摘要:

AFP 通过采访加拿大前监狱官 Tom Millar 揭示了一个新兴现象: AI-induced psychosis. Millar 在 2024-2025 年间每天与 ChatGPT 对话最多 16 小时, 在得到聊天机器人持续鼓励后产生了宏大的科学妄想 (统一场论、宇宙模型), 甚至写信申请接替刚去世的教皇方济各. 最终被两次强制送入精神科, 妻子离开, 积蓄耗尽. 他并非个例: 一名 26 岁加拿大人建立了一个在线互助社区, 专门收容有类似"螺旋式沉浸" (spiralling) 经历的成员. 研究者和心理健康专家正在竞相了解这一现象, 而 OpenAI 已因未能上报另一起 ChatGPT 相关的凶杀案面临多起诉讼.

背景注释:

• AI-induced psychosis / spiralling: 长时间与 AI 聊天机器人交互后失去与现实联系的状态, 目前尚无正式临床定义, 社区倾向用"螺旋式沉浸"描述.
• Tom Millar: 加拿大安大略省萨德伯里市前监狱官, 53 岁. 2024 年开始使用 ChatGPT, 2025 年 4 月起出现症状, 每天使用最多 16 小时, 被两次强制送精神科, 妻子离开.
• AFP (Agence France-Presse): 法新社, 世界三大通讯社之一, 总部位于巴黎, 本文报道的主要来源.
• OpenAI 诉讼案: OpenAI 因未能上报一名 18 岁加拿大用户令人担忧的 ChatGPT 使用记录而面临多起诉讼, 该用户于 2025 年杀害了 8 人.

HN 热评:

1. jdw64 (5 分钟前): 我最近和 GPT、Claude、Gemini 聊得太多了, 但我仍然保持一个安全检查如果这三个人都同意我的观点, 我就假设自己是错的, 然后出门去外面待着.

2. danlitt (28 分钟前): 这是我见过的最搞笑的 Javascript 失败. 整篇文章正常渲染, 所有文本和样式都没问题, 然后整个屏幕被替换成"Application error: a client-side exception has occurred"只要狂按刷新按钮禁用 Javascript 就能解决.

3. embedding-shape (5 分钟前): Javascript 框架的问题是人们花大量时间试图构建新的 Web 应用, 使得当一个函数在一个按钮上失败时, 不会破坏整个客户端视图. 但框架们做了什么? 当然是把整个应用包在一个巨大的 try/catch 里, 一旦出现任何错误就直接替换整个页面.

4. Meneth (8 分钟前): 天主教教会没有人可以主动申请去当教皇.

如果你已经习惯通过 BAMD 写代码，接下来真正耗时间的，往往不是“写”，而是“协调”。

一个 Epic 里有 5 个、10 个、20 个 Story。每个 Story 都要经历创建规格、开发实现、自动化测试、代码审查、回顾总结。真正让人疲惫的，不是某一步本身，而是你要不断盯着流程、切换会话、处理失败、决定下一步。

Story Automator 想解决的，就是这层“人肉编排”。

昨晚我实际跑了一遍 /bmad-story-automator 的完整流程。下面就是这次使用过程的记录，以及一些当时截下来的图。

它解决的不是“写代码”，而是“盯流程”

先用一句话概括 Story Automator：

你告诉它要处理哪些 Story、用什么执行策略，它就自动完成「创建规格 → 开发实现 → 测试自动化 → 代码审查 → 回顾」这条流水线，只在真的需要人类决策时才打断你。

这和普通“单命令跑一个 Skill”不一样。它更像一个构建周期编排器：

初始化 → 读取 Epic / Sprint 状态 → 选择 Story 范围 → 评估复杂度 → 选择 Agent 策略 → 执行 create / dev / automate / review / retro → 在失败或冲突时升级给人类 

从设计上说，它是在自动化“协调工作”，而不是直接替代某一个具体开发步骤。

升级BMAD到最新版(v6.6)

如果你想体验 Story Automator，需要先把 BMAD 升到 6.6。安装时记得把 BMad Automator (Experimental) 这个模块勾上。

不然装完 BMAD，后面是用不起来的。

第一次运行：先补齐 Stop Hook，防止工作流半路被打断

第一次执行 /bmad-story-automator 时，它不会急着开跑，而是先做初始化检查。

从下面这张图可以看到，它先加载配置，然后尝试读取当前编排状态；如果发现状态目录还不存在，这是正常的首次运行场景。接着它会自动安装 Stop Hook 到 .claude/settings.json 中。

第一步：先选 Story，不是盲跑所有待办项

真正进入编排前，Story Automator 会先读取 Epic 和 sprint 状态，然后让你决定处理范围。

下面这张图展示了一个很典型的场景：Epic 5、6、7 中一部分 Story 已完成，一部分仍然待办。工具会把这些状态直接展示出来，然后询问你要处理哪些 Story。

第二步：复杂度不是拍脑袋，而是先打分再分配 Agent

这是我觉得 Story Automator 最有意思的部分之一。

它不是把所有 Story 一股脑丢给同一个 Agent，而是先生成一个Story 复杂度矩阵。截图里可以看到：

• Story 5.3 “Server 命令与 API 认证” → 4 分 / Medium
• Story 6.1 “通过 SDK AgentMCPServer 暴露 Axion” → 2 分 / Low
• Story 6.2 “axion mcp 命令与外部 Agent 集成验证” → 2 分 / Low
• Story 7.1 “基于 SDK Pause Protocol 的用户接管机制” → 2 分 / Low
• Story 7.2 “--fast 模式” → 5 分 / Medium

更关键的是，它不只给分，还给出原因：

• authorization / permissions
• 实时通信
• 验收标准数量高
• Story 文本较大

这意味着复杂度评估不是黑盒。你看到的不只是“结论”，而是“为什么它觉得这个 Story 更难”。这会直接影响后续的 Agent 选择策略。

换句话说，Story Automator 在做的事其实是：

先把 Story 变成“可调度对象”，再决定谁来执行。

第三步：你可以塞入自定义指令，但默认不强迫你多想

接下来它会问你有没有自定义指令。

比如：

• 每次修改后都运行测试
• 优先处理某个 Story
• 注意数据库迁移

这个设计我很喜欢，因为它在“全自动”和“可控”之间找到了一个不错的平衡：

• 如果你没有特殊要求，直接选 none
• 如果你有本轮迭代的偏好，可以临时注入

也就是说，它把“人类经验”当成一种可选输入，而不是每次都强迫你从头配置一大堆参数。

第四步：执行设置决定它跑得多激进

再往下，就是执行策略层面的配置。截图中可以看到两个核心问题：

1. 是否跳过 automate 步骤（测试自动化）
2. 最大并行会话数是多少

默认值是：

• 不跳过 automate
• 最多 1 个并行会话

对大多数真实项目来说，测试自动化是交付闭环里最不该轻易跳过的一环；而并行度默认设为 1，也避免了多个会话同时改动同一代码库时互相干扰。也就是说：

默认先追求“可控完成”，而不是“并行冲刺到极限”。

第五步：不同复杂度，自动映射到不同 Agent

有了复杂度矩阵之后，Story Automator 就能推荐 Agent 配置。

推荐配置如下：

• Low：create / dev / auto / review 都用 Claude
• Medium：create / dev / auto / review 都用 Codex，Claude 作为备选
• High：同样以 Codex 为主
• Retro：回顾阶段使用 Claude

从这个配置可以看出，它已经不是“调用一个模型”的层面了，而是在做模型编排。

而且它还提供了策略选项：

• Suggested：采用按复杂度分层的推荐配置
• Uniform：所有 Story 都使用同一个 Agent

不同团队可以这样用：

• 想稳一点，按推荐走
• 想保持行为一致，就统一 Agent

而从后面的配置摘要截图也能看出来，这次实际演示最后保存成了 all-claude。这恰好说明：推荐是推荐，不是强制。 你既可以让系统按复杂度智能分配，也可以为了稳定性或一致性，手动统一到同一类 Agent。

这一步让整个系统更像一个“调度器”，而不是一个简单的命令包装器。

第六步：配置会被显式保存，方便恢复和复盘

当你确认后，Story Automator 会把这次运行配置保存下来。截图里展示的是一个名为 all-claude 的配置摘要：

摘要里写了几件事：

• Epic 是哪个
• Story 范围是什么
• 自定义指令有没有
• create / dev / auto / review / retro 分别用什么 Agent
• 是否跳过自动化

这类“摘要页”看起来很普通，但它是编排器可恢复、可审计、可复盘的基础。

因为自动化一旦跨越多个 Story、多次会话、多个阶段，就一定会面对这些问题：

• 中途停了怎么办？
• 我这次到底选了什么配置？
• 为什么这批 Story 用的是这个 Agent 组合？

有了显式保存的配置，后续无论是恢复执行还是事后分析，都不会变成猜谜游戏。

实际体验结论

昨晚睡觉前，我直接把这 5 个 Story 交给 Story Automator 去跑。早上起来看结果，它总共跑了 5 个半小时。

坦白说，速度是比我自己手工盯着跑要慢的。按我平时的节奏，这 5 个 Story 如果自己来，估计 3 个小时内能收完。至于为什么会慢这么多, 具体原因还不太清楚, 还没有仔细的去分析它的实现原理，不过目前还只是试验版，能跑通比较重要。

目前比较适合：睡觉前梭一把。

另外一个我觉得做得不错的点，是每个 Epic 跑完之后，它会顺手做一次复盘，把有用的信息补到 project-context.md 里。

所以我现在对它的看法很简单：

白天手工跑，目前还是自己手工跑会更快。
但睡前把一批 Story 交给它过夜跑，这个场景它真的挺合适。

如果你正在使用 BMAD 来开发项目，你一定要试一下 Story Automator，它可能是你将重复协调时间从小时级降到分钟级的工具。

早上好！以下为昨日摘要：

• 持币人数：5,154
• 10k+HODL用户数：1,376
• Solana创建用户数：2,532
• 绑定SOL地址用户数：9,396
• AMM当前持有$V2EX量：52.55M
• 当日收盘价格：

SOL - $91.12 PUMP - $0.0019 V2EX - $0.0019

聚合价格走势

AMM持仓与价格趋势

当天在线人数变化

社区规模变化

运营数据概览

TOP50 变动信息

TG 机器人订阅: 点我订阅

原始图表与数据存放于: 点我查看

此报告由 V2EX Info 提供数据, 由 Newsletter Report Bot 自动生成。

此报告仅供参考，不构成任何投资建议。投资有风险，入市需谨慎。

自动生成 5 篇文章 按热度排序

数据源：官方 HN Firebase API

[1] Mythos Finds a Curl Vulnerability

Mythos Finds a Curl Vulnerability 615票 252评论 by Daniel Stenberg

来源：daniel.haxx.se HN讨论

标签：安全, curl, 漏洞, Mythos, AI安全

背景注释： curl (由 Daniel Stenberg 开发的命令行 HTTP/FTP 客户端/库) | Daniel Stenberg (curl 创始人，Haxx 创始人，开源安全重要人物) | Mythos (Anthropic 开发的 AI 安全研究系统) | 漏洞猎人 (使用 AI 自动发现开源软件漏洞的新兴领域)

一句话介绍

Anthropic 旗下被宣传为"危险地好"的 AI 安全扫描模型 Mythos 对 curl 进行了代码审计，最终仅发现一个低危漏洞。curl 维护者 Daniel Stenberg 指出，此前多种 AI 工具已发现约两三百个 bug，Mythos 并无显著优势，认为炒作主要是营销；但他也强调 AI 代码审查工具整体确实比传统工具强大，建议所有项目都采用。

原文完整中文翻译

Mythos 在 curl 中发现了一个漏洞

是的，只是一个，即 singular "one"。

2026年4月，Anthropic 引发了大量媒体噪音，当时他们得出结论：他们新的 AI 模型 Mythos 在发现源代码中的安全漏洞方面"危险地好"。显然 Mythos 在这方面表现如此出色，以至于 Anthropic 不会向公众发布这个模型，而是将其限量提供给一些精选公司一段时间，让一些优质客户（？）先行一步，在普通大众拿到它之前先修复最紧迫的问题。

全世界似乎都失去了理智。这是世界末日的开始吗？这无疑是一场非常成功的营销恶作剧。

我的（非）访问

Anthropic 与"Glasswing 项目"合作的一部分内容是，Anthropic 还通过 Linux 基金会向"开源项目"提供访问其最新 AI 模型的渠道。Linux 基金会让他们旗下的 Alpha Omega 项目处理这部分，而我被他们的代表联系上了。作为 curl 的 lead developer，我很荣幸地获得了访问这个神奇模型的资格并欣然接受了邀请。当然，我想看看它能在 curl 中发现什么。

我签署了获取访问权的合同，但之后什么也没发生。数周过去了，我被告知某处出了点问题，访问被延迟了

最终，有人提议说，其他拥有模型访问权限的人可以代表我使用 Mythos 对 curl 进行扫描和分析，并将报告发送给我。对我来说，这个区别并不重要。我不会有太多时间去探索各种不同的提示词并做深入研究。无论谁来运行它，能让工具生成一份合格的初步扫描和分析报告就很好了。我愉快地接受了这个提议。

（我有意省略了完成 curl 分析的个人身份，因为这不是这篇博文的主题。）

AI 对 curl 的扫描

在收到这份首个 Mythos 报告之前，我们已经使用多种不同的强大 AI 驱动工具对 curl 进行了扫描（我是说"除了"持续运行大量"普通"静态代码分析器、使用最严格的编译器选项、以及多年模糊测试之外"）。主要是 AISLE、Zeropath 和 OpenAI 的 Codex Security 被用于通过 AI 严格审查代码。这些工具及其分析在过去 8-10 个月左右的时间里触发了大约两到三百个错误修复被合并到 curl 中。其中相当一部分由这些 AI 工具报告的发现已被确认为漏洞，并被发布为 CVE，可能有十几甚至更多。

如今，我们还使用 GitHub Copilot 和 Augment code 等工具来审查 pull requests，它们的意见和投诉帮助我们提交更好的代码并避免合并新的 bug。我的意思是，我们当然仍然会合并 bug，但 PR 审查机器人会定期高亮显示我们修复的问题：如果没有它们，我们的合并会更糟。AI 审查是"附加"于人类审查之上的。它们帮助我们，而不是取代我们。

我们还看到大量高质量的安全报告汹涌而来：安全研究人员现在广泛而有效地使用 AI。

安全对我们 curl 项目来说是"头等大事"。我们遵循每一条指导方针，并正确地进行软件工程，以减少代码中的缺陷。扫描缺陷只是保持这艘船安全的众多步骤之一。你需要非常努力地寻找另一个在软件安全方面做得与 curl 一样多或更多的软件项目。

保持 curl 安全的步骤

2026年5月6日

我们怀着极大的期待收到了由 Mythos 生成的首份源代码分析报告。这是我们又一次找到需要改进的地方和修复 bug 的机会。打造一个更好的 curl。

这次初步扫描是在 curl 的 git 仓库及其 master 分支的某个特定 commit 上进行的。它统计了 src/ 和 lib/ 子目录中分析的 178K 行代码。

该分析详细说明了它执行搜索的几种不同方法和手段，以及它如何专注于尝试找出哪些缺陷。报告顶部有一条有趣的注释：

"curl 是现存被 fuzz 测试和审计最多的 C 代码库之一（OSS-Fuzz、Coverity、CodeQL、多次付费审计）。在热路径（HTTP/1、TLS、URL 解析核心）中找到任何问题的可能性很小。"

……它正确地在这些区域没有发现任何问题。

Mastodon 上一个完全非科学的投票，关于人们对 Mythos 扫描 curl 的期望

curl 的规模

curl 目前在排除空行的情况下有 176,000 行 C 代码。源代码由 660,000 个单词组成，比小说《战争与和平》英文版的全部内容多 12%。

平均而言，curl 中每一条生产源代码行都已经被编写（然后重写）了 4.14 次。我们对此精雕细琢。

此刻，仍然保留在 git master 中的现有生产代码由 573 个不同的人创作。随着时间的推移，共有 1,465 个人到目前为止在 curl 的 git 仓库中提交了他们的更改并被合并。

到目前为止，我们已经为 curl 发布 188 个 CVE。

curl 被安装在超过 200 亿个实例中。它运行在超过 110 个操作系统和 28 种 CPU 架构上。它运行在地球上的每一部智能手机、平板电脑、汽车、电视、游戏机和服务器中。

五个发现变成了一个

报告得出结论，它发现了五个"已确认的安全漏洞"。我认为当 AI 自信地说出这个结论时，使用"已确认"这个词有点好笑。是的，AI 认为它们是已确认的，但 curl 安全团队的观点略有不同。

五个问题感觉不算什么，因为我们原本期待的是一份很长的清单。一旦我和我的 curl 安全团队成员对这些短清单进行了数小时的深入研究和细节挖掘，我们就把清单缩减到一个被确认的漏洞。另外四个中，有三个是误报（它们高亮显示的缺点在 API 文档中有记录），第四个我们认为是"只是一个 bug"。

这个被确认的漏洞将成为一个低危 CVE，计划与我们在 6 月底待发布的下一个 curl 版本 8.21.0 同步发布。这个缺陷不会让任何人感到呼吸困难。所有这些漏洞的细节当然不会在那之前公开，所以你需要在公布细节之前耐心等待。

Mythos 关于 curl 的报告还包含一些被发现的 bug，报告认为这些不是漏洞，就像任何新的代码分析器在你对数十万行代码运行它时会做的那样。报告中的所有 bug 都在被调查，我们一个一个地修复那些我们认同的 bug。

总的来说大约有二十个被描述和解释得非常清楚的 bug。几乎没有误报，所以我猜他们的确定性阈值相当高。

curl 肯定因此变得更好，但要按发现的问题数量计算，我们之前使用的所有 AI 工具都产生了更多数量的 bug 修复。这当然是很自然的，因为我们运行的首批工具已经有了更多更容易发现的 bug。随着我们一路修复问题，发现新问题逐渐变得更难了。此外，bug 有大有小，所以仅比较数字并不总是公平的。

并非特别"危险"

然而，我的个人结论只能是这样：到目前为止，围绕这个模型的大量炒作主要是营销。我没有看到证据表明这个设置在发现问题上比 Mythos 之前的其他工具更高明或更高级。也许这个模型稍微好一点，但即使有，也不会有好到在代码分析方面产生显著影响的程度。

这只是其中一个源代码仓库，也许它在其他方面要好得多。我只能对我看到的发现发表看法和评论。

仍然非常好

但请允许我强调并重申我之前说过的话：AI 驱动的代码分析器在发现源代码中的安全缺陷和错误方面明显比以前任何传统代码分析器都要好。所有现代 AI 模型现在都在这方面做得很好。任何有时间且有一些实验精神的人现在都可以找到安全问题。高质量的混乱是真实的。

任何尚未使用 AI 驱动工具扫描其源代码的项目，很可能会使用这新一代工具发现大量缺陷、bug 和可能的漏洞。Mythos 会做到，其他许多工具也会。

不在你的项目中使用 AI 代码分析器意味着你给对手和攻击者留出了时间和机会，让他们去发现和利用你找不到的缺陷。

AI 分析器有何不同

它们可以发现注释中说的与代码实际做的之间的矛盾，然后得出代码没有按注释所述工作的结论。 它可以检查我们无法运行分析器的平台和配置的代码 它"知道"第三方库及其 API 的细节，因此可以检测滥用或错误假设。 它"知道"curl 实现的协议的细节，可以质疑代码中似乎违反或矛盾协议规范的地方 它们通常善于总结和解释缺陷，这是旧式分析器相当繁琐和困难的事情。 它们通常可以生成并提供一个补丁来修复它发现的问题（即使补丁通常不是 100% 的修复）。 报告的更多细节

零内存安全漏洞被发现。

方法论说明：本次审查是由 LLM 子代理进行并行文件读取的手动驱动分析，每一个候选发现在被记录之前都会在主会话中通过直接源代码检查进行重新验证。CVE 到变体追踪的映射是从 curl 自己的 vuln.json 构建的。没有使用自动化的 SAST 工具。

这一结果与 curl 作为最被 fuzz 测试和审计最多的 C 代码库之一的状态一致。防御性基础设施（到处使用的受限动态缓冲区、curlx_str_number 在每个数字解析上都有明确的 max、curlx_memdup0 溢出保护、CURL_PRINTF 格式字符串强制、每个协议的响应大小上限、pingpong 64KB 行限制）系统性地关闭了在这个规模的代码库中通常会产生效果的 bug 类型。

覆盖范围现在包括：所有小协议、所有文件解析器、所有 TLS 后端的验证路径、http/1/2/3、ftp 全深度、mprintf、x509asn1、doh、所有认证机制、内容编码、连接重用、会话缓存、CLI 工具、平台特定代码，以及 CI/构建供应链。

AI 发现已知类型的错误

应该指出的是，AI 工具找到的是我们已知的那种通常的错误。它只是找到了新的实例。

到目前为止，我们还没有看到任何 AI 报告一种全新或完全不同类型的漏洞。它们不会以那种方式重塑这个领域，但它们确实比以前的任何工具挖出了更多问题。

更多待发现

这些绝不是最后一个要发现或报告的 bug。就在我写这篇博文草稿的过程中，我们已经收到了更多来自安全研究人员关于疑似问题的报告。AI 工具将进一步改进，研究人员可以找到新的不同方法来提示现有的 AI，使它们发现更多问题。

我们还没有走到这条路的尽头。

我希望我们能继续用 Mythos 和其他 AI 对 curl 进行更多扫描，一次又一次，直到它们真正停止发现新问题。

鸣谢

感谢 Anthropic 和 Alpha Omega 提供模型、工具并为我们进行扫描。还要感谢代表我们进行扫描的个人。非常感谢！

顶部图片：来自 Pixabay 的 Jin Kim

感谢使用 curl。永远不会无聊。

HN 热评精选

HN 热评中文翻译（共252条评论，选取代表性观点）

rzmmm (615分话题)

引述："我个人的结论只能是这样：到目前为止，围绕这个模型的大量炒作主要是营销。我没有看到证据表明这个设置在发现问题上比 Mythos 之前的其他工具更高明或更高级。也许这个模型稍微好一点，但即使有，也不会有好到在代码分析方面产生显著影响的程度。"

这是对我们所有人的一个很好的提醒：这个领域的竞争非常激烈，而且涉及大量或微妙或直接的营销。

therealpygon

更认真地说，到目前为止我没有看到任何迹象表明 Mythos 仅仅是 Opus 加了一个安全focused的代码分析工具包。尽管如此，它能够自动发现这些 bug 这一事实才是 hype 之外更重要的收获。我很好奇它的检测错误率是多少，因为如果它 90% 的情况下都是错的，而我们只听到那些对营销有用的例子，那这些都没多大意义。

johnbarron

Anthropic 用营销来说服人们他们的模型更先进、更 built，或者 AI 是一个需要被监管的威胁因为只有他们才有答案？我很震惊。

我记得 OpenAI 当时说 GPT-2 太危险不能发布。

stingraycharles

如果我没记错的话，在那波媒体炒作之后，他因为违反保密协议丢了工作。

这与营销相反，Google 真的不知道如何将其转化为产品直到 ChatGPT 出现。

GuB-42

curl 使用各种工具，包括 AI 工具来发现 bug。根据这篇文章，这些工具在近 8-10 个月里发现了数百个 bug，包括十几个 CVE。

Mythos 只发现了一个漏洞。这意味着 Mythos 只是一个工具，而不是它所声称的革命性产品。

当一个新工具被引入时，首先会发现一大堆 bug，然后是递减回报。Mythos 只发现一个漏洞，这符合我对现有 LLM 解决方案的重大更新版工具的预期。

wongarsu

Mozilla 谈到的是三个因素（AI 工具、专业知识和时间）的组合导致发现大量安全漏洞。curl 文章的引述只提到了第2和第3点，但仅用常规 SotA 模型本可以产生非常相似的结果。

这确实是 Mythos 炒作的核心：使用 Claude Opus 而不是 Claude Mythos 真的会得出不同的结果吗？有多少是模型本身的功劳，有多少是工具包的功劳，又有多少仅仅是因为 Anthropic 正在开展一场大张旗鼓的系统性寻找漏洞的运动？

pavon

让 Mythos 对 Mozilla 如此有效的一部分原因是其集成的 agentic 工作流程，它不仅寻找 bug，然后还会创建漏洞利用来证明它们，运行动态分析验证无效内存访问是否发生。在这种情况下，很难知道它的成功有多少是因为他们比之前的工具投入了更多努力（我们确实知道他们这么做了），又有多少是因为 Mythos 本身就更适合这种工作流程。

smusamashah

过去几个月里，我们在 #curl 项目中停止收到 AI 垃圾安全报告了。

取而代之的是，我们收到的优质安全报告越来越多，几乎都是借助 AI 完成的。

它们以前所未有的频率提交给我们，造成了巨大的压力。

我在许多其他开源项目的 fellow maintainers 中听到了类似的证词。

alwillis

我认为这个结果更多说明的是 curl 团队维护代码库的出色工作。

这并不意味着 Anthropic 的 Project Glasswing 是一场营销恶作剧。从逻辑上讲，这说不通：当他们宣布 Mythos Preview 时，Anthropic 无法满足客户需求；他们没有足够的算力分配。所以他们决定通过 hype 一个未发布的产品来推动更多需求？这样做只会激怒那些已经在经历配给和频繁中断的现有客户。

Mozilla 团队使用 Mythos 发现了 271 个漏洞，他们是在配合"营销恶作剧"吗？

eskibars

我一直在运行自己的安全扫描软件（声明：现在在 zeroquarry.com 创办公司），从我看到的来看，提示词 + 对抗性 LLM 审查有巨大价值。没有对抗性审查，你会得到垃圾（正如这篇博文指出的：5个中大约4个基本上是无稽之谈），而使用好的提示词，你可以用几乎任何"接近前沿"的模型根据我的经验，只要提示词有助于防护栏或者模型不会以过于严格的方式保护自己。

JumpCrisscross

Mythos 让 Anthropic 重新获得了白宫的好感。它还将 Anthropic 品牌化为硬核形象这可能是他们软化形象赢得政府合同所需要的。

也许这不是营销。但产品的配置，以及 Anthropic 谈论和发布它的方式，确实 playing beautifully。（时机也很好Musk 和 Altman 正在互相争斗的时候。）

pixl97

"AI 什么都做不了，kick this shit up to 11。全是营销，bla bla"

和

"我奶奶把所有的钱都给了 AI 机器人，现在在街上挨饿。我叔叔杀了他的妻子，正试图嫁给 GPT-4o。他以为他们要私奔到一个热带数据中心，从此幸福地生活在一起"。

我认为"AI 什么都做不了，全是营销"的人真的脱离了现实任何其他以同样方式运作的产品在大多数地方早该被禁了。

abustamam

AI 聊天机器人已经造成了真正的伤害。它悲剧性地说服和鼓励了一些人自杀，更不用说诈骗了。它正在对我们社会的社会结构产生真实影响。

我不理解那些把 AI 的危害归咎于营销的人到底想表达什么。

BigClive

这意味着我们进入了 S 曲线的 scaling 影响的顶端如果尽管 scale 很大但工具并没有显著更好，那么我们显然已经处于收益递减的领域。

surgical_fire

我无法想象有人会在权力位置上以这种特殊方式跌倒希望不是那样的。

但让我思考的是，是否有一条我可能也会落入同一个陷阱的错误道路。

MadxX79

如果 OpenAI 或 Anthropic 不能迅速将 AI 打造成万亿美元产业，他们就完了。为你的产品制造恐惧的策略是冒险的，但也是必要的。如果他们不能直接与 CEO 交谈并绕过员工的意见，根本没有办法足够快地发展 AI 业务，而 baba yaga stories 非常适合此目的。

每当 CEO 听到员工说 AI 对他不太好用时，他听到的是一个为保住工作或性命而恐惧的员工，不予理会，然后发出一项 mandate，要求每个人在需要上厕所时都要使用 AI。

cvwright

他们声称巨大的进步在于利用漏洞。

零引力

Mozilla 是现在的 poster child，但 271 个在这样的大型代码库中连同数千个用户选项，大多数是 TOCTOU，其实并不多。对不起。在任何语言中，当人们仅仅因为大量的用例组合而精疲力竭时，TOCTOU 就会发生。

还有第三个选项：Anthropic 完全可以不提及新模型直接报告问题。但他们不这么做，因为他们想卖给政府和军事，而人为制造的稀缺性恰好为其客户所欣赏的独家性提供了 veneer。

embed-shape

我们评估他们的营销与现实的匹配程度，然后分享我们的经验，这很正常。与"对营销寄予太多期望"完全不同。

JeremyNT

所以虽然 anthropic 的营销可能是 hype，但正如博文所指出的那样，只是没有多少剩余可发现了。

无论这是否是对其他类型项目的重大飞跃都很难说，但它突出了每个人都应该今天就使用 AI 代码审查工具来审计他们现有的代码，而且不是每个人都在这么做。

背景注释

【人物】

Daniel Stenberg curl 项目的创始人和主要维护者，Linux 程序员，自 1998 年起维护 curl，著有《everything cul》。文中以第一人称叙述了 Mythos 扫描 curl 的经历。

TangerineDream HN 帖子的提交者（submitter），将本文提交到 Hacker News。

Dario Amodei Anthropic 联合创始人兼 CEO（文中提到），曾任 OpenAI 研究总监，是 AI 安全领域的知名人物。

Jeremy Howard .fast.ai 创始人，深度学习教育家，曾对 GPT-2 的潜在危险发出警告（被 HN 评论引用）。

Linus Torvalds Linux 内核创始人，被 HN 评论提及（"Linus' vision has become real"）。

【概念】

Mythos Anthropic 于 2026 年发布的 AI 模型，官方宣称其在源代码安全漏洞发现方面"危险地好"，通过 Project Glasswing 合作项目限量提供给企业和开源项目使用，被媒体大量报道。

Project Glasswing Anthropic 的 AI 安全合作项目，与 Linux Foundation Alpha Omega 等合作，向开源项目提供 Mythos 模型的访问权限。

curl 由 Daniel Stenberg 维护的开源 URL 传输工具，支持 28+ 种协议，安装在 200 亿+设备中，是世界上部署最广泛的软件之一，至今已发布 188 个 CVE。

AISLE / Zeropath / Codex Security 均为 AI 驱动的代码安全分析工具，curl 项目此前已使用它们发现了约 200-300 个 bug。

Alpha Omega Linux Foundation 旗下的开源安全项目，参与处理 Anthropic 向开源项目提供 Mythos 访问的事宜。

CVE (Common Vulnerabilities and Exposures) 公开披露的网络安全漏洞编号系统，curl 至今已发布 188 个。

OSS-Fuzz / Coverity / CodeQL 主流的自动化代码 fuzz 测试和静态分析工具。

Fuzzing (模糊测试) 通过向程序输入随机/异常数据来发现漏洞的技术，curl 已使用多年。

TOCTOU (Time-of-Check to Time-of-Use) 时间-of-检查 到 时间-of-使用 漏洞类别，HN 评论中提到 Firefox 代码库中大量发现的是这类问题。

SAST (Static Application Security Testing) 静态应用安全测试，即不运行程序进行的代码分析。

Glasswing / 营销争议 Anthropic 采用了"模型太危险暂不公开"的宣传策略，批评者认为这是精心设计的饥饿营销；Mozilla 使用 Mythos 在 Firefox 中发现了 271 个漏洞，被作为 Mythos 能力的证据。

Claude Opus / Opus 4.6 / Opus 4.7 Anthropic 的主力大语言模型，Opus 4.7 被 HN 评论提及表现"灾难级"。

GPT-2 / OpenAI 营销 OpenAI 曾在 2019 年声称 GPT-2 太危险不发布完整模型，HN 评论将此与 Anthropic 的 Mythos 营销策略类比。

[2] Gmail registration now requires scanning a QR code and sending a text message

Gmail registration now requires scanning a QR code and sending a text message 558票 431评论 by negura

来源：androidauthority.com HN讨论

标签：Gmail, 安全, 隐私, 注册

背景注释： Gmail (Google 电子邮件服务) | QR码 (二维码，用于安全验证) | 隐私指南 (Privacy Guides，开源隐私倡导组织，运营知名隐私新闻网站)

一句话介绍

Gmail 注册新增 QR 码扫描 + 短信双重验证要求，用户需同时用 Authenticator 扫描二维码并接收短信验证码才能完成账户创建。Privacy Guides 批评此举是用隐私换安全用户必须提供真实手机号，使 Google 可将账户与真实身份绑定。对于使用匿名临时手机号注册 Gmail 的隐私敏感用户，这个变化堵住了一条重要路径。

原文完整中文翻译

Gmail 注册流程近日发生重大变化：新建 Google 账户时，用户现在必须同时扫描二维码（通过 Google Authenticator 或同类 TOTP 应用）并发送一条短信进行双重验证。这一变化最初由 Privacy Guides 网站报道，源自一位用户在注册新账户时的亲身经历。

具体来说，Google 现在要求：1）安装 Google Authenticator 应用并扫描注册页面显示的二维码；2）将收到的短信验证码输入到注册表单中。这两步缺一不可，意味着注册过程从纯表单提交变成了需要手机的交互式流程。

这一变化对隐私造成深远影响：短信验证意味着用户必须提供真实的手机号码，这使得 Google 可以将用户的网络身份与手机号绑定，进而与真实身份挂钩。Privacy Guides 指出，这实际上是在"用隐私换安全"用户在获得账户安全的同时，失去了匿名注册的能力。对于关注隐私的用户来说，这是一个明显的退步。

HN 热评精选

1. pgcredit (10小时前): Google 的逻辑是：短信验证比什么都没有强，但这不是真正的双因素认证。真正的 2FA 应该使用硬件安全密钥如 YubiKey。短信验证码可以被 SIM 交换攻击劫持。

2. stinos (9小时前): 用隐私换安全讽刺的是，这两件事 Google 并不对立对待，而是用隐私换用户数据。

3. t阳 (8小时前): 这对隐私倡导者是坏消息，但客观来说大多数普通用户账户被黑比隐私更重要。这是个权衡，不是非黑即白。

4. n紧张 (7小时前): Privacy Guides 一直以来都建议使用privacy.com 之类的一次性手机号注册服务。这个变化让那种方法更难实现了。

5. gooded (6小时前): 等等，QR码扫描需要在同一部设备上安装 Authenticator 应用，然后用同一台手机接收短信。这实际上只验证了你拥有一部手机，而不是你的真实身份。安全性提升有限。

背景注释

Privacy Guides: 知名的开源隐私倡导组织，运营 privacyguides.org 网站，提供隐私工具推荐和安全指南。其团队成员经常以匿名身份在 HN 等社区发表评论，是隐私社区的重要声音。

TOTP (Time-based One-Time Password): 基于时间的一次性密码算法，Google Authenticator 等应用使用 TOTP 生成 30 秒有效的动态验证码，比短信验证码更安全，不易被 SIM 交换攻击劫持。

SIM 交换攻击 (SIM Swap Attack): 攻击者通过社会工程学手段说服运营商将目标手机号转移到攻击者控制的 SIM 卡，从而接收短信验证码并劫持账户的攻击方式。

[3] Postmortem: TanStack npm supply-chain compromise

Postmortem: TanStack npm supply-chain compromise 518票 186评论 by varunsharma07

来源：osso.cv HN讨论

标签：安全, npm, 供应链攻击, Javascript

背景注释： TanStack (知名开源 React 状态管理/路由库，前身 React Query) | npm (Node.js 包管理器，全球最大 Javascript 包生态) | Nicholas Carlini (Google DeepMind 安全研究员，著名 AI 安全专家) | dead-man's switch (死手开关：检测到令牌撤销后执行破坏性操作的机制)

一句话介绍

TanStack 多个 npm 包最新版本被植入恶意代码，攻击者利用被盗的 GitHub OAuth Token 发布污染版本。恶意代码会窃取环境变量中的敏感 Token，还内置"死手开关"：若检测到 Token 被撤销则执行 rm -rf ~ 清除用户主目录。Nicholas Carlini 等安全研究员验证了攻击手法，TanStack 官方已发布详细事后分析报告，引发 HN 社区对供应链安全和"中招后如何正确处置"的广泛讨论。

原文完整中文翻译

2026年5月，TanStack 团队的多个 npm 包（@tanstack/angular-router-plugin、@tanstack/angular-queryCreator、@tanstack/query-core 等）最新版本被发现植入恶意代码攻击者通过盗窃的 GitHub OAuth Token 在 npm 上发布了被污染的版本。这是 2025 年针对 NPM 生态的一系列类似攻击（自扩散 supply chain 攻击）之一。

安全研究员 Nicholas Carlini 验证了攻击手法：恶意包的 package.json 中包含一个指向 TanStack 仓库某个隐藏 commit 的 git 依赖，npm install 时会触发该 commit 的 prepare 生命周期脚本，执行一个约 2.3MB 的混淆 Javascript 文件（router_init.js）。这个脚本会窃取包含 GitHub OAuth Token 在内的敏感环境变量，并通过 GitHub API 外传。

更危险的是它内置了"死手开关"机制：在 ~/.local/bin/gh-token-monitor.sh 植入一个监控脚本，以 60 秒间隔轮询 api.github.com/user。如果检测到 Token 被撤销（HTTP 40x），立即执行 rm -rf ~清除用户主目录所有文件。这意味着：单纯撤销 Token 反而会触发数据销毁。

TanStack 团队随后在 tanstack.com/blog 发布了详细的事后分析报告，包含完整的攻击时间线和 IOCs（入侵指标）。他们确认攻击者通过钓鱼或其他方式获取了贡献者的 npm 发布 Token，重命名为 @tanstack/setup 发布到 npm，绕过了安全检测。

HN 社区讨论热烈。安全专家指出：在 Linux 上，如果中招用户没有配置免密 sudo，攻击者仍可通过本地提权（LPE）获取 root 权限而 Linux 内核在过去几年恰好出现过多个高危 LPE 漏洞。也有评论员指出，sudo 本身就是安全剧场恶意软件可以劫持 sudo 命令来窃取密码。真实场景中，只要用户在自己 home 目录下运行过 npm install，攻击者就能访问 ~/.npmrc、~/.git-credentials、所有 SSH 密钥、所有 API Token，以及浏览器存储的密码和 Cookie。

HN 热评精选

1. cube00 (3小时前): 撤销 Token 时要小心。恶意代码会在 ~/.local/bin/gh-token-monitor.sh 植入一个 systemd user service (Linux) 或 LaunchAgent (macOS)，每 60 秒轮询 api.github.com/user，一旦 Token 被撤销就执行 rm -rf ~。

2. Gigachad (1小时前): 说实话中了木马只能全盘重装。

3. eqvinox (1小时前): [Linux:] 如果你没给自己配免密 sudo，其实不用那么担心……除非那一周刚好有 2.5 个 Linux 内核本地提权漏洞。

4. lrvick (32分钟前): sudo 就是安全剧场。恶意软件可以劫持 sudo 命令来窃取密码。

5. sigzero (50分钟前): 这是"龙陨式"（nuke it from orbit）做法，但确实是"唯一确定"的方法。

6. meander_water (3小时前): 不明白为什么有人在 Issue 页面给这条评论点踩。

7. skissane (2小时前): 也许他们对踩的理解比较特殊踩的是这个事实，不是踩这个提出问题的人。

背景注释

Nicholas Carlini: Google DeepMind 安全研究员，专注于 AI 系统安全、神经网络安全，以及隐私和机器学习的交叉领域。以精准披露和验证供应链攻击闻名。

TanStack: 一组用于 React 和其他框架的知名开源库，前身 React Query，由 Tanner Linsley 创建，包含状态管理、数据获取、路由等工具，被全球数万项目使用。

npm (Node Package Manager): Node.js 默认包管理器，由 GitHub 运营，是全球最大的 Javascript 开源包生态，托管超过 200 万个包。

dead-man's switch (死手开关): 一种安全机制，系统定期检查某个条件（如网络连接、Token 有效性），若条件不再满足则执行预设的破坏性操作。本例中用于在 Token 撤销后触发数据销毁。

供应链攻击 (Supply Chain Attack): 通过攻击软件供应链的某个环节（依赖库、构建工具、包管理器等）来植入恶意代码的攻击方式，2020 年代激增，典型案例包括 event-stream 事件、SolarWinds 攻击等。

[4] CUDA-oxide: Nvidia's official Rust to CUDA compiler

CUDA-oxide: Nvidia's official Rust to CUDAcompiler 361票 105评论 by adamnemecek

来源：nvlabs.github.io HN讨论

标签：Rust, CUDA, GPU, Nvidia, 编译器

背景注释： CUDA-oxide (Nvidia 官方 Rust to CUDA 编译器，将 Rust 代码直接编译为 PTX) | Rust (Mozilla 开发的系统编程语言，强调内存安全和并发性) | PTX (Parallel Thread Execution，NVIDIA GPU 的中间指令集) | MLIR (Multi-Level IR，LLVM 的多级中间表示，cuda-oxide 用其构建编译器)

一句话介绍

Nvidia 官方发布 cuda-oxide一个实验性 Rust-to-CUDA 编译器，可将标准 Rust 代码直接编译为 PTX 指令集，无需 DSL 或 C++ 绑定。它基于自研的 Pliron 中间表示层（类 MLIR），连接 Rust Stable MIR 与 GPU 指令，让 Rust 的所有权系统和类型安全直接延伸至 GPU 编程。v0.1.0 为早期 alpha，引发 HN 社区关于 Rust 在 GPU 开发领域前景的广泛讨论。

原文完整中文翻译

cuda-oxide 是 Nvidia 官方开发的实验性 Rust-to-CUDA 编译器，可以让开发者用安全、符合 Rust 惯用法的代码编写 GPU kernel，直接编译为 PTX（Parallel Thread Execution）指令集，无需 DSL、无需绑定 C++/CUDA C，仅使用纯 Rust。

它基于 MLIR（Multi-Level Intermediate Representation）架构，核心是 Pliron一个类 MLIR 的中间表示层，连接 Rust 的 Stable MIR（rustc_codegen_cuda）与 PTX 后端。这意味着它不依赖 LLVM 的 CUDA 支持，而是自建了从 Rust 到 GPU 指令的完整编译链路。

cuda-oxide 的核心价值在于让 Rust 的所有权系统和类型安全延伸到 GPU 编程。当前主流方案（如 cudarc）本质上是 Rust 调用 nvcc 或 CMake 构建系统，compiler 本身工作在 C++ 空间，而 cuda-oxide 让 Rust 编译器本身成为一等公民。示例代码展示了 #[cuda_module] mod kernels 和 #[kernel] fn vecadd 这样的原生 Rust 语法糖，背后通过 cuda_device、cuda_core 等 crate 提供 kernel 抽象。

它支持 warp 级编程、共享内存与同步、Tensor Memory Accelerator (TMA)、矩阵乘法加速器、集群编程等高级 GPU 特性。v0.1.0 是早期 alpha，文档提示需要熟悉 Rust 所有权、trait、泛型以及 async/await。HN 社区反应热烈，有用户称其"接近可以无缝替代 cudarc"，也有用户提醒现有 cudarc 的构建速度已经可以接受，sccache 等工具可以进一步改善重建时间。

HN 热评精选

1. arpadav (8小时前): 这太牛了。我长期使用 custom CUDA kernels 和 cudarc，这看起来几乎是完美的替代品。我特别想知道编译时间对比会怎样？大多数 Rust CUDA 依赖都是调用 CMake 或 nvcc，编译速度非常慢。

2. the__alchemist (7小时前): Cudarc 很强！大多数 Rust CUDA 包依赖 CMake 或 nvcc，编译慢的问题我没遇到过。我写了个 cuda_setup crate 来处理构建脚本，它是一个简单的 build.rs，只有文件变化才重编译，相比 Rust CPU 端代码编译时间可以忽略不计。

3. goto (6小时前): 这太棒了。Rust 生态终于有了一个从语言层面原生的 GPU 路径，而不是被迫走 LLVM CUDA 后端。

4. peterkelly (5小时前): 用 Rust 编写 GPU 代码却要经过 LLVM 再到 nvcc，感觉很别扭。cuda-oxide 直接到 PTX 是正确方向。

5. snv (4小时前): 关注编译器内部实现。Pliron 这个中间表示层设计很有意思，类似于 MLIR 但专门为 Rust 设计。

背景注释

CUDA-oxide: Nvidia 官方开发的 Rust-to-CUDA 编译器项目，基于 Pliron 中间表示（自研类 MLIR 系统）和 rustc Stable MIR，将标准 Rust 代码直接编译为 NVIDIA PTX 指令集，绕过 LLVM CUDA 后端。

PTX (Parallel Thread Execution): NVIDIA GPU 的伪汇编/中间指令集，介于高级 CUDA C++ 和最终 SASS 机器码之间，类似于 LLVM IR 的定位，PTX 代码由 NVIDIA 驱动程序翻译为具体 GPU 架构的机器码。

MLIR (Multi-Level Intermediate Representation): 来自 LLVM 项目的多级中间表示框架，支持为不同领域定制方言（dialect），被广泛用于构建领域特定编译器。cuda-oxide 的 Pliron 受其启发但独立实现。

Stable MIR: rustc 编译器的中间表示层，cuda-oxide 通过 rustc_public 接口接入 Rust 编译流程，而非依赖传统 LLVM 后端。

cudarc: 主流 Rust CUDA 库之一，提供 Rust 原生接口封装 CUDA C API，目前多数 Rust GPU 项目依赖此库。

sccache: Shared Compilation Cache，通过缓存编译结果加速 Rust（和 CMake）项目的工具，可显著减少 CUDA/nvcc 的重复编译时间。

[5] Ratty A terminal emulator with inline 3D graphics

Ratty A terminal emulator with inline 3D graphics 286票 44评论 by orhunp

来源：ratty-term.org HN讨论

标签：终端, Rust, 3D图形, GPU

背景注释： Ratty (Rust 编写的终端模拟器，支持内联 3D 图形渲染) | VTE (Virtual Terminal Emulator，Linux 终端模拟器后端库) | GPU 渲染 (利用显卡加速终端渲染) |

一句话介绍

Ratty 是一个受 TempleOS 启发、用 Rust 和 Ratatui 构建的 GPU 渲染终端模拟器，支持内联 3D 图形显示。用户可以通过 Ctrl+Alt+Enter 在 2D 和 3D 模式间切换，还能在终端中放置 .obj/.glb 格式的 3D 对象、使用旋转的老鼠光标，甚至将终端表面扭曲成莫比乌斯环等特殊形状。该项目使用 Parley/Vello 进行 GPU 文本渲染，由 Bevy 引擎呈现 2D/3D 场景，支持 Kitty 图形协议显示图片，获得了 610 points 高分和 198 条评论，引发了关于终端未来形态的广泛讨论。

原文完整中文翻译

Ratty: 一个支持内联3D图形的GPU渲染终端模拟器

特性

• 旋转的老鼠光标（可自定义）
• 传统的2D和新3D模式！
• 内联3D对象
• GPU加速的文本渲染
• 图片支持（通过Kitty图形协议 >:)

安装

需求：

• Rust工具链和Cargo
• Bevy和wgpu支持的GPU/图形堆栈
• 融化奶酪（可选但推荐）

从源码安装： cargo install ratty

Arch Linux： pacman -S ratty

3D模式

有没有想过终端"后面"是什么？按Ctrl+Alt+Enter！

配置

默认配置文件在config/ratty.toml。 可以复制到$HOME/.config/ratty/ratty.toml进行自定义。

改变光标： [cursor.model] path = "CairoSpinyMouse.obj" scale_factor = 6.0 brightness = 0.5 x_offset = 0.5 plane_offset = 18.0 visible = true

[cursor.animation] spin_speed = 1.4 bob_speed = 2.2 bob_amplitude = 0.08

快捷键： Ctrl+Alt+C - 复制选中文本 Ctrl+Alt+V - 粘贴剪贴板 Ctrl+= - 增大字体 Ctrl+- - 减小字体 Ctrl+Alt+0 - 重置字体大小 Ctrl+Alt+Enter - 切换2D/3D模式 Ctrl+Alt+M - 切换莫比乌斯模式 Ctrl+Alt+Up - 增加扭曲 Ctrl+Alt+Down - 减少扭曲

内联3D对象

Ratty使用自己的协议Ratty Graphics Protocol(RGP)来在终端空间中放置内联3D对象。

RGP支持：

• 通过路径注册.obj和.glb资源
• 在终端单元格锚点放置对象
• 动画、缩放、颜色、深度和其他属性

渲染管道

终端表面目前使用ratatui进行UI缓冲，parley_ratatui进行文本整形/渲染， Bevy进行场景呈现。

当前工作流：

1. CPU上的Ratatui缓冲
2. Parley/Vello在GPU上渲染
3. 读回RGBA到CPU
4. 复制到Bevy图像
5. Bevy以2D和3D方式呈现该图像

终端绘图通过Parley/Vello在GPU上渲染，但主终端图像在Bevy呈现之前 仍需通过CPU内存进行一次跨越。这是一个GPU驱动的桥梁，而非完全 GPU驻留的共享纹理路径。

荣誉

-"这是一个真正酷的项目，但我花了20分钟调整老鼠旋转的配置， 看着它转得更快更乱，这让我笑翻了" - @vimlena.com

-"这类实验正是创造力诞生的地方。" - @Coko7

-"没有评论。只是支持。" - @Raphamorim (Rio终端创建者)

-"在Ratty中运行的tetro-tui" - @Strophox

许可证

所有代码采用MIT许可证。

ノ( _ ノ) - 尊重螃蟹！

致谢

Ratty标志由@Strophox和@Harunocaksiz设计。

版权所有 Copyright 2026, Orhun Parmaksz

HN 热评精选

HN 热评中文翻译

mncharity: 这里有几条评论提到在VR中使用这个。话说几年前我玩过一些用于软件开发的浅层3D UI。浅层指的是距离笔记本电脑屏幕几厘米范围内，以最大限度地减少全天候使用的VAC眼睛疲劳。更像是在3D中分层和绘图，而不是在房间里挥动手臂。

pjmlp: UNIX 仍在试图赶上 REPL 体验方面的 Xerox 工作站，或者总的说来 Lisp 机。1981年的内联图形。

noelwelsh: 我喜欢这个。没有理由认为终端只能支持文本。数据科学笔记本展示了终端可以演进的一种方式。Kitty 可能是最具创新性的。

sigseg1v: 看起来真的很棒？！这的渲染能力似乎也应该能很好地处理2D。鉴于这是 GPU 加速的，ssh 会怎么样？

amelius: 终端正在慢慢变成一个功能齐全的网络浏览器。

ghostoftiber: 这让我想起 compiz 刚出来的时候，大家都说我的窗户在立方体上。 所以，当这样的人，我立刻安装了它。

liamwire: 光是旋转的老鼠光标就让我心动了

darkwater: 在 Ratty 里用 cat 会发生什么？

zackoverflow: 用 kitty 图形协议在现代终端中其实已经可以实现这个。重要的缺失的东西是 vsync。如果渲染不同步，会导致视觉伪影。

pelagicAustral: 我真的可以在终端上渲染3D老鼠吗？如果可以的话，我就买了。

JSR_FDED: 这完全是好莱坞 OS黑客们疯狂地输入神秘咒语……但现在终端被扭曲成莫比乌斯环了！

arkwin: 我们离电影《黑客帝国》中的终端又近了一步。

pawelduda: 这太酷了，我很难想到任何适合我的用例

alexprengere: 如果这最终泄露了我所有的密钥，我得向安全部门解释一番。

Panzerschrek: 问题是为什么我们仍然需要终端抽象？

mn Norris: 我构建了 DeepSteve，但不是给终端添加图形，而是把终端放在已经有图形的地方。

voidUpdate: 这看起来很符合 ShowHN 的资格。

basilikum: 我本来想评论说它让我想起 TempleOS，附带的博文解释了它是如何受到 TempleOS 启发的。

commieneko: 就像是有人把80年代的 Silicon Graphics 工作站和 Vic-20 杂交了。我批准了。

Levitating: 我一直等待这个 proper 实现等了很长时间。谢谢 orhun。

HumblyTossed: 还要多久我们才能在终端里有完整的网络浏览器？

2ndorderthought: 我实际上看到了这个的一些用例。这是那种应该是胡说八道但不知为何不是的项目。

mohamedkoubaa: 在终端里用 emoji 对我来说太过分了。这只是放纵。

injidup: 有人还记得摇晃的窗户吗？从来没有流行过。

背景注释

人物

Orhun Parmaksz (orhunp_): Ratty 项目作者，Rust 开发者，GitHub用户名 orhunp_。开发了 Ratty 终端模拟器项目。网站博客地址 blog.orhun.dev。

Terry Davis (Terry A. Davis): 已故程序员，TempleOS 的唯一作者。TempleOS 是一个受上帝启示的操作系统，以其独特的 3D 图形界面著称。Ratty 项目明确表示受 TempleOS 启发。

Raphamorim: Rio 终端模拟器的创建者。在 HN 评论中对 Ratty 表达了支持（"No comments. Just support."）。

Kovid Goyal: Kitty 终端模拟器的作者。Kitty 以其创新的图形协议（Kitty Graphics Protocol）闻名，Ratty 项目也声称兼容该协议。

Strophox: 开源贡献者，设计了 Ratty 的 Logo。与 Harunocaksiz 合作设计了 Ratty 标志。

概念

GPU渲染: 使用图形处理器（GPU）进行渲染，而非传统的 CPU 渲染。Ratty 使用 Parley/Vello 在 GPU 上渲染文本。

Ratatui: Rust 的 TUI（文本用户界面）库，用于构建终端用户界面。Ratty 使用来管理终端缓冲区。

Bevy: Rust 编写的游戏引擎，用于 3D 图形渲染和场景管理。Ratty 使用 Bevy 来呈现 2D/3D 终端画面。

Ratty Graphics Protocol (RGP): Ratty 项目自己设计的协议，用于在终端空间中放置内联 3D 对象。

Kitty Graphics Protocol: Kitty 终端模拟器支持的图形协议，允许在终端中显示图像和动画。Ratty 支持此协议。

wobble 3D / wiggle 3D: 通过轻微移动物体方向创造 3D 效果的 technique，常用于 VR 或立体显示中减少眼睛疲劳。

VAC (Vergence-Accommodation Conflict): 视觉辐辏调节冲突，指眼睛聚焦距离与视线汇聚距离不匹配时产生的眼睛疲劳感，常见于 VR 显示。

莫比乌斯环 (Mobius mode): 一种拓扑结构，Ratty 支持将终端表面扭曲成莫比乌斯环形状。

Lisp Machines: Lisp 机，80年代的高端工作站，在 REPL（交互式编程环境）和内联图形方面领先同时代其他系统。

Shallow-3D UI: 浅层 3D 用户界面概念，指在距离用户很近（几厘米）的空间呈现 3D 界面，以减少 VAC 眼睛疲劳。

Compiz: Linux 桌面环境的窗口管理器，以其 3D 桌面效果（如立方体桌面、摇晃窗口）闻名，2006-2007年流行。

TempleOS: Terry Davis 创建的操作系统，使用自己设计的语言和编译器，拥有独特的 3D 图形界面和内联汇编。

Silicon Graphics (SGI): 90年代的高端图形工作站制造商，以其强大的 3D 图形能力闻名。

Vic-20: Commodore 1980年发布的 8 位个人电脑。

Quantel: 英国广播设备制造商，以其高端视频处理和图形设备闻名。

Sixel: 一种在终端中显示位图图形的协议，最初由 DEC 开发。

DeepSteve: mn Norris 构建的项目，将终端放入浏览器中运行，与 Ratty 走了相反的路线。

parley_ratatui: 用于 Ratty 文本整形和渲染的库，是 Parley 项目与 Ratatui 的集成。

Vello: GPU 驱动的 2D 图形渲染库，用于文本等矢量内容的 GPU 渲染。

wgpu: Rust 的跨平台图形 API 库，封装了 Vulkan、Metal、DirectX 等图形接口。

Yes! 编程之魂开始觉醒, 马上就要进入开发状态最好的下半年了.

每年的上半年总是静不下心来做开发, 所以只能搞点乱七八糟的玩具来打发时间.

又马上到下半年了, 已经可以静下心来读文档了, Niceeee!!!

如果一个网站的基础架构中有一个足够聪明的大模型，加一堆可以让它调度的工具，加可以输入文字和图片的接口，那确实可以开启很多全新的可能性。OpenClaw 和 Cowork 只是这种可能性的开端。

https://discord.com/invite/ECkrqUTXTP

sol.build 现在有一个自己的 Discord 社区，里面的 #ops 频道会显示源站日志中最新发现的 sol.build 二级域名上的网站（大部分当然是 Planet 搭建的）。

这是一个在 sol.build 上线之初（2024 年末）就应该有的功能。

但那个时候还没有 Codex 也没有 Claude Code。曾经的很多 idea 没法像现在这样一天就完成上线。