LLM 审 Rust 代码，作者已实战挖出几十个问题

Rust Secure Code Working Group 负责人 Shnatsel 分享了一段很有意思的实战结论：在把 GPT-5.5 接到可运行测试、可调用 miri 的工作流之后，LLM 在审计 Rust unsafe 代码时表现得“离谱地有效”。作者说，自己已经在多个常用 crate 中找到并上报了几十个不同严重程度的问题，包括越界读写、use-after-free、数据竞争、panic safety 问题，以及 Send/Sync / aliasing 这类典型 Rust 专属坑。

这篇文章最有价值的地方，不是单纯喊“AI 很强”，而是把方法讲清楚了：先把目标收敛到容易验证、不会骚扰维护者的内存安全问题，再让模型写最小复现测试，最后用 miri / sanitizer 过滤掉假阳性。作者特别提到，Rust 的局部推理特性让这种审计方式比在 C/C++ 上更容易奏效，因为很多不变量必须在局部函数边界内得到验证，而不是埋在整条调用链里。

如果这条路继续成熟，它对 Rust 生态的意义可能不只是“多一个审计工具”，而是把过去不够经济的安全检查，逐步变成社区可以常态化做的事情。

• 原文链接：The unreasonable effectiveness of LLMs for auditing Rust code
• Reddit 讨论：r/rust 讨论帖

Aurora 浏览器引擎继续啃 YouTube，页头和播放器框都开始真正渲染出来了

作者 JohannaWeb 继续更新自己用 Rust 从头写的浏览器引擎 Aurora。这个项目不是 Chromium / WebKit 的壳，也不是简单拼装件：它自己负责把 HTML、JavaScript、CSS、layout 和 paint 串成一个真正能跑的引擎，而最近阶段性的验收标准非常硬核——能不能把 YouTube 逐步渲染出来。

这次更新里，作者重点讲了几个非常“浏览器工程味”的坑：custom elements 升级、事件传播、MutationObserver / AbortController / timer 的行为修复，以及最关键的 ShadyDOM 组合逻辑。此前 YouTube masthead logo 一直被布局成 0x0，最终定位到的是 detached logical fragments 没有被正确组合回 connected tree，导致 connected callbacks 没触发；修完之后，页面 paint path 数量从 300 以下跳到了 400+，播放器框和红色播放按钮也能画出来了。

这类项目最吸引人的地方，在于它不是“做个 demo 就停”，而是在最复杂的现代 Web 应用之一上持续验证自己的引擎假设。离“能正常刷 YouTube”还远，但现在已经不是纯概念验证，而是开始一块块啃真实浏览器行为了。

• 原文链接：Aurora browser engine made in rust programming language | The quest for youtube
• 项目仓库：JohannaWeb/Aurora

Ratatui 跑上咖啡机：作者把 ESP32 仪表盘直接做成了实体屏 UI

这个项目很讨巧，也很能体现 Rust 生态组件之间的组合力。作者把自己的咖啡机串口遥测数据接到 ESP32 上，再用 Ratatui + mousefood 把界面直接画到一块 ILI9341 小屏上，同时把数据推到 Home Assistant。也就是说，平时大家在终端里看到的 Ratatui 组件，这次被作者搬到了真正的嵌入式显示屏上。

技术上最亮眼的是它的“同一套 UI，双后端开发”思路：设备端用 SPI 驱动实体屏，主机端则通过 embedded-graphics-simulator 跑 SDL2 模拟器，靠 cargo features 在 device / simulator 之间切换。这样一来，作者可以先在笔记本上高速迭代 layout、widget 和交互，再把成熟逻辑刷进硬件，避免每次改点小东西都上板子调试。

这类项目不一定是流量最大的一类 Rust 内容，但非常适合拿来展示 Rust 在嵌入式、UI 和家庭自动化之间做“跨层复用”的能力。

• 原文链接：Ratatui rendering to a physical ILI9341 over SPI — embedded espresso-machine firmware in Rust on the ESP32
• 项目仓库：ololonly/maratui

guitar：面向巨型仓库和混乱历史的 Rust 终端 Git 客户端

作者分享了一个名叫 guitar 的 Rust 终端 Git 客户端，目标不是替代命令行所有场景，而是把“看懂历史、追回丢失提交、在超大仓库里快速穿梭”这件事做得更顺手。项目强调 topology-first 的历史视角，支持增量加载超长提交历史、reflog 恢复、branch / tag / stash / worktree 浏览，以及 diff、split view、rebase、cherry-pick、merge 等真实 Git 操作。

它最打动人的点其实是产品定位：很多 Git 工具要么偏 GUI、要么偏命令式，而 guitar 盯住的是“又快又轻，还得能应对 50 万提交级别仓库”的空档。作者特别提到 reflog 支持是自己最兴奋的部分——这对经历过 reset、rebase 或 detached HEAD 事故的人来说，确实很有吸引力。

对于经常在单仓库、长历史、复杂分支策略里打滚的人，这类工具是否能真正留下来，关键就在于交互速度和图谱理解能力。至少从作者目前公开的方向看，它已经不是普通的 TUI Git 壳子，而是在试图把“大仓库历史认知”变成一个专门的产品点。

• 原文链接：I built guitar, a fast Rust terminal Git client for huge repos and messy Git history
• 项目仓库：asinglebit/guitar
• 演示视频：guitar demo